SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[mcuelenaere]

...

I could succesfully use blx (armv5t) and strd (armv5e) instructions, but not ssat (armv6) so the CPU is armv5E/T

...

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 it

When 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]

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

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 ..

[pbxy]

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).

Great work!
(Rockbox logo on clipv2.)

pbxy I hope it will help you to find the last buttons.

It did! Used as keypad inputs are D0:2 as you said, outputs are D3:5.
Compared to the v1, column switching works the other way around: All 3 output pins are high except the one for the wanted column.
An input pins reads 0 when the corresponding button is pressed.

I needed to add a few nops after switching a column to get reliable results from button_read_device().
Without the delay, eg. VOL_UP and DOWN were reported when just DOWN was pressed.

With the attached button-clip.c every button except for HOLD gets detected.
I printed out all GPIO pin states on the display but nothing changes when hold is pressed.

[j8048188]

• SD code is different, and pl18? documentation on ARM.com has vanished?

Was it on the website before? If so, where did you go to get it?
I may be able to find a cache of the page.

[mc2739]

For any tester with an e200v2, I have opened FS#10043 for updates to the lcd driver.

These updates enable inverse video, upside down mode, and lcd standby. Also, some unneeded GPIO setting code was removed.

Please post any comments or results on the Flyspray task.

Thanks

[funman]

With the attached button-clip.c every button except for HOLD gets detected.
I printed out all GPIO pin states on the display but nothing changes when hold is pressed.

Isn't hold on A3 like on Clipv1 ? I'll have to test, but I remember seeing it on A3 in the OF.

saratoga:
Are you sure your armv5 instruction isn't data or 2 thumb instructions ?
You should check register c0 of cp15 to be sure of the CPU used.

By the way I should get a Clipv1 within a few days (sent today).

And also: AMS answered (in french!) and sent me a NDA before sending me the AS3536 datasheet.
Now I just wait their answer about AS3530 & AS3531, because AS3530 & AS3536 have built in hardware H264 decoders (expensive, especially for the patents licences); this is why I think the Clipv2 is AS3531 based, but having all the documents couldn't harm in determining the exact SoC used.

j8048188:
I still have the document, but I was hoping to see if the SD registers matched with a newer PrimeCell controller : it seems ARM doesn't build new SD controllers.

By the way : here are some SD registers I found:
0xC6070000 = sd registers base
    + 0x00 = power?
    + 0x28 = argument
    + 0x2c = cmd
    + 0x30 = resp0
    + 0x34 = resp1
    + 0x38 = resp2
    + 0x3C = resp3
    + 0x40 = status (irq status?)
    + 0x44 = clear (irq clear?)
    + 0x100 = fifo

command register bits:
bits 5:0 = command
bit 6    = response
bit 7    = long response
bit 31   = command enable/command active ?

I had a look at Linux (2.6.28) source but couldn't find any controller matching those.

[funman]

With the attached button-clip.c every button except for HOLD gets detected.
I printed out all GPIO pin states on the display but nothing changes when hold is pressed.

Isn't hold on A3 like on Clipv1 ? I'll have to test, but I remember seeing it on A3 in the OF.

You have to set A7 direction out, set pin A7, wait a little bit (I used for(i=0;i<50;i++) asm volatile("nop"); ) , read A3; unset pin A7 and set the direction to input to read power button.

Now the buttons are complete!

I tried quickly to access the SD, I could send some commands but with some trouble:

• The CID & CSD registers are reverted, and are sent in the same order even if I switch SEND_CSD & SEND_CID command : it indicates 0x1E9E00 blocks
• I can't get out of IDENT mode (and I don't know the registers modifications needed prior DMA transfer)
• If I reset all the peripherals, I can't even get past the power up phase

So I think I'll just wait the documents from AMS.. it should save much pain

[FlynDice]

I believe I've gotten rockbox to boot with the mmu functioning on my e280v2 but have no test to actually prove it.  I updated the mmu patch at http://www.rockbox.org/tracker/task/10048 and kugel did a little housekeeping for me(thanks).  I tracked the problem down to a conflict between cached memory and dma transfers.  Then I looked at the gigabeat fx and saw they were doing a range invalidate on the dcache there so I tried it and lo and behold it works, well sort of.  Playback is broken for me but the ui runs very snappily.  I think there's still a lot of fixing here but I think this points in the right direction.  Someone who understand things better than I do should take a look and see what they think.  I have just made the 2 1MB sections at 0x00000000 and 0x30000000 writeback cacheable to mimic the OF.  Also the code is all available from mmu-arm.S.  I got it to work with those functions and added some bus control functions from the OF to that file.  Check it out and see what you think, I know kugel at least is not convinced it's actually working.

[kugel.]

Codecs are worse than before, from what I've noticed.

I think a good way to test the mmu would be to map the IRAM behind RAM, so 0x38000000 or so (edit *.lds accordingly), if that turns out working, then it must be running.

[FlynDice]

I'm already in so far over my head my ears are starting to hurt but here goes nuthin...

  Where's the 8 MB of ram documented if anywhere?   Was that just figured out along the way somewhere?  I see the 320 K TRAM I'm assuming is IRAM and the ROM for the bootloader.  I know from looking at the code that the 8 MB(or 2MB I guess for lowmem) of ram is there and its at 0x30000000.  And then we have the internal SD and the microsd.  Are the 2 sd cards accessed through the mpmc is that what's going on?  I've been scanning the memory map at the end of the datasheet trying to make all this fit together in my head before diving into the virtual address and physical address mapping party.  Do I have this all right so far.

 Please help correct my misconceptions before I waste a lot of time on this.

[funman]

The 8MB of RAM are "documented" in the OF SDRAM initialisation (setting of MPMC_DYNAMIC_CONFIG_0)

320kB TRAM is what we call IRAM, but not the bootloader ROM! The ROM is 128 kB at 0x80000000.

The 2 SD cards are accessed via the MMC/SD controller ARM PrimeCell PL180, nothing to do with MPMC !
PL180 controller for internal SD is at 0xC8000000
PL180 controller for SD Slot is at 0xC8020000

Hope that helps !

[kugel.]

Very little progress. It builds and runs the bootloader, but most/some buttons and display don't work. Thus, the main build doesn't really work too.

If you intend to help development (e.g. by doing actual coding or original firmware disassemling, or donating a player), then we welcome you. But if you don't please do not ask for status in this thread.