Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
mcuelenaere:
--- Quote from: funman on March 24, 2009, 01:54:36 PM ---...
I could succesfully use blx (armv5t) and strd (armv5e) instructions, but not ssat (armv6) so the CPU is armv5E/T
...
--- End quote ---
I'm not sure if you already know, but you can identify an ARM cpu by reading out cp15 register 0 (see this for more info).
FlynDice:
I attached a diff to this post that displays the contents of the p15 registers in the HW debug page.
http://forums.rockbox.org/index.php?topic=14064.msg147056#msg147056
Edit: But now that I think about that you have no lcd to read....
funman:
I can "display" numbers by flashing the button led (2 blinks = bit 1, 1 blink = bit 0)
Thanks mcuelenaere, I will use this method
Other news: the i2c register 0x20 (AS3514_SYSTEM) reads "revision 4" and I can shutdown the Clip by clearing the bit 0
FlynDice : about the MMU I have some remarks:
* The real size is 0x1000 (16kb aligned)
* You should use (RAM_ORIG + MEM*0x100000 - TTB_SIZE) for the position
* You should update plugin.lds app.lds & boot.lds to remove TTB_SIZE from the RAM size
pbxy :
I try to use OF "hijacking" to find the required LCD bits:
* Keep a copy of the compressed OF in RAM
* Boot "rockbox" which decompresses the OF
* Put a 2nd "rockbox" somewhere else in RAM
* Modify the OF to branch to our 2nd "rockbox" and run itWhen I got it working, I hope to use printf() (since the LCD initialization has already been done) and then remove function calls one by one to see which are mandatory.
Keep updated!
EDIT:
The Clipv2 CPU is a ARM926EJ-S (Java able!) so it suggests a AS3530 AS3531 or AS3536 SoC like we thought. I'll request the datasheets from AMS and hope that they answer!
Here is the cp15 id register value: 0x41069265
EDIT2:
I think it would be a AS3531 since AS3530 & AS3536 are advertised as "audio/video" able, but we can't know until we get the datasheet for them.
FlynDice:
--- Quote from: funman on March 25, 2009, 06:50:49 AM ---FlynDice : about the MMU I have some remarks:
* The real size is 0x1000 (16kb aligned)
* You should use (RAM_ORIG + MEM*0x100000 - TTB_SIZE) for the position
* You should update plugin.lds app.lds & boot.lds to remove TTB_SIZE from the RAM size
--- End quote ---
Ok, thanks, real life is getting in the way a bit here but I'll try to spend some time on this later tonight. Do you have any insight on the problems this causes while trying to mount disks in main.c init()? (by coincidence that was the same spot that was failing on your first sd-banks patch) Domonoky mentioned there could be a conflict with dma and cacheable memory.
EDIT: Let me preface this by saying I'm learning all this on the fly so to speak, so feel free to correct my ignorance without bruising any ego.
The TTB_SIZE of 0xfff I used was simply the figure the OF uses in it's scheme to write 0x1000 tags into the table. But I'm having trouble wrapping my head around it's actual size. I was thinking the size was 0x4000. It seems the OF uses a 0x4000 value as it places the table at 0x307fc000 and the gigabeats use this 0x4000 value also. But I could certainly be convinced otherwise...
funman:
Myself i'm still learning and I think you know more than me on the MMU subject ;)
The documents specify the size should be a multiple of 0x4000 (16kb) and the position aligned on 16kb.
The OF loop use <= 0xfff to loop over the 0x4000 bytes (0x1000 words : you'll surely notice a lsls r0, r0, #2 to shift between word position & byte position)
--
Good news : I have now access to the LCD on Clipv2 (I updated the ticket with a new patch, pay attention to _backlight_on() which holds the required i2c registers modifications).
pbxy I hope it will help you to find the last buttons.
I had to skip system_init() to have display at all.
Now on the similarities & differences with Clipv1/AS3525:
* DMA code looks the same
* LCD code is the same, except the hardware bits
* Button code looks the same, except the hardware bits (to be confirmed by pbxy)
* VIC code looks different (perhaps pl192?)
* Memory code looks the same
* i2c code is the same, but the registers are different (at least SYSTEM 0x20 register is the same)
* SD code is different, and pl18? documentation on ARM.com has vanished?
* I didn't look at I2S/pcm code but I expect it to be not much different (and quite simple to RE if it is)
* CCU/CGU registers appear to be quite identical but extended, the AMS datasheet would definitely help (I requested docs for AS3530 AS3531 AS3536 yesterday)
--
EDIT:
I forgot to mention that I think the memory problems could be related to clock frequencies.
For example the external memory clock (extmem_clk) must not be higher than 90MHz, and the peripheral clock (pclk) not higher than 65MHz.
But pclk = extmem_clk OR extmem_clk/2
So we can have at maximum:
extmem_clk = 90MHz & pclk = 45MHz OR
extmem_clk = 65MHz & pclk = 65MHz.
I'm still not sure of which settings the OF use exactly ..
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version