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

[Hillshum]

I'm only on in afternoons (UTC-6 till daylight wasting ends, then UTC-7).

[funman]

Now that we exchanged our IM we'll get in touch, I hope better doc attracts new hackers

As for the bootloader, I'm still blocked on the nand driver

I had a look at various drivers (in rockbox, Linux and U-Boot) and especially at the patches for U-Boot & Linux mentioned in this post http://forums.rockbox.org/index.php?topic=14064.msg117283#msg117283

I also read the ONFI 1.0 & 2.0 specifications (http://www.onfi.org)

But I can not get the signal that the NAND is ready for operation

I attach my stage2.S , if you run it it will just blink the led forever, so I advise you to not use it.

Reverse engineering the OF shows no direct references to the nand registers, but atomipunk found a location in the code where these registers are calculated (by an offset to the base address) and stored in RAM, to be later used by other routines.

This renders analyzing & understanding how the OF interacts with the NAND quite complex.

Note that the patches for Linux have still not been applied, maybe they were buggy or written for a target different from the SansaV2 ? (like in AS3525-1 or AS3525-2)

We could try to contact AMS and ask them for the Linux patches, maybe they have evolved since the patches sent to the linux-arm mailing list.


NEW POST:

I have found new buttons for the Clip:

• b2 is the 'home' button
• b1 is the 'volume down' button, once you have configured b4 & b5 as OUTPUT

The list is growing up

[atomikpunk]

After (much) hacking into the firmware, I found it very hard to find any NAND registers references, and a lot too much SD interface registers references. As my analysis went by, I bended more and more to the idea that the flash could be in fact accessed using the SD interface instead of the NAND interface we previously suspected.

And after re-reading some docs on Daniel's site, I found out that v1 e200 players used the SD interface for the (primary) flash. So well I'll invest more time now on the SD interface as it seems to be the most promising avenue at the moment.

That's no big news for today except that on the analysis side, it is much clearer now what we're looking for

Just a reminder: once we're able to load a custom firmware from the flash, we're free for _much_ more hacking since it'll be much easier to drop firmware files on the player and test stuff. So that's pretty much the last tricky part before things goes more roundly.

[funman]

Very good news !

Now we can continue study the OF with a clearer mind and start writing a SD driver.

I think that we must use the SD driver with the nand base address instead of the sd mci base address to access the nand, SanDisk may have wired the ams3525 differently.

Or maybe we must use the SD base address and load a specific "bank" to access the nand chip, testing will tell ...

Also don't forget when we have access to the raw nand content we must write a minimal fat32 driver to fit in the bootloader, but I hope the fat32 filesystem is quite simple.

Back to hacking

[Bagder]

Also don't forget when we have access to the raw nand content we must write a minimal fat32 driver to fit in the bootloader, but I hope the fat32 filesystem is quite simple.

Rockbox already has all the fat32 filesystem code you need of course...

[fragilematter]

It's fat16 in fact, so we can get rid of the fat32 support and make a smaller driver

[kugel.]

Are you sure it's fat16 for all v2s? I have a doubt that a 8GB Fuze uses fat16.

Also, I seem to remember that for the e200v1, fat16 was possible for <= 4GB versions, but 6 and 8GB ones used (of course) fat32.

As for the minimalistic fat driver: I think it's worth looking into existing code for already supported targets, especially if the SD interface is to be used, just like e/c200v1 series.

[funman]

Rockbox already has all the fat32 filesystem code you need of course...

I am not sure it fits in the 1kB of our code segment, aside with the sd driver, so I think we must go we the minimum.
I don't know filesystems but I think we can remote at least write support, recursive directories traversal, and maybe more ..

I built rockbox bootloaders for other targets and they are not very smaller than the rockbox code (without applications) and are definitely too big for the actual room.

By the way do you know if MMC (SD) and NAND flash are driven by the same driver with different base addreses for the registers in SansaV1 ?

[caladan]

Atomikpunk must be right with that SD driver. We should have thought about it earlier, texts in sw indicate clearly that all directories are seen in mmc:\
I wonder how dangerous it would be, but maybe we should try to use the same values as those used in v1 to access registers.

[funman]

I wonder how dangerous it would be, but maybe we should try to use the same values as those used in v1 to access registers.

The OF clearly show different values: it shows that the SD controller is the ARM PL180

[atomikpunk]

Hi again peeps,

Yeah I'm wondering, anyone knows more than I do about "metal ECO redesign"? Because the only way everything we've found about the NAND SD interface up to now suppose that a "spare" register, described as being "used for metal ECO redesign if needed" is used just prior to using the NAND flash register as we would with the Arm PrimeCell PL180... And this is quite surprising since this register should not have been like the PL180 at all, so this is what makes me think that the NAND registers on the sandisk AMS3525 SoC could have been "upgraded" with a second PL180 interface which would be selectable by using one of those spare register...

As for the FAT driver, well yes, we would need a very compact and truncated version, simply allowing one to find a specified file name and read it. We probably wouldn't need directory support, write support nor anything like that. The idea is to load a minimal bootloader that can load a full-blown rockbox firmware from the NAND, nothing fancy since we are quite short (for the moment?) on code space. And about this limitation, we should think about switching to thumb mode soon...

funman: I did some more analysis tonight and found that the NAND supply voltage is 3.0V, selected in the power register using the power value 0xA. In fact, the formula is: voltage = 2.0V + power_value * 0.1V.

About your try to work with the flash, maybe you can send me your code so I can take a look?

Have fun peeps, more to come when we'll have more time

[dan_a]

Rockbox already has all the fat32 filesystem code you need of course...

I am not sure it fits in the 1kB of our code segment, aside with the sd driver, so I think we must go we the minimum.
I don't know filesystems but I think we can remote at least write support, recursive directories traversal, and maybe more ..

I've just done a very simple stripping out of the write functions from fat.c, and that reduced its size when compiled from 22k down to 9.7k.  Getting down to 1k including the SD driver will be quite challenging.

[Bagder]

Regarding the need for small code sizes.

Can't we just decide on a part of the OF that we can "sacrifice" (at least for now) and overwrite with bootloader code and jump to that from the tiny snippet we inject?

[funman]

Not really since we only have 128kB in ROM and e200 testers showed that we can't use the last bytes of the ROM, but only the last bytes of the 0x200 bytes block of the firmware

EDIT: I forgot to mention that the code in ROM contains the basis of OF and I think we just can't 'sacrifice' this code.

If we modify the parts past 128kB, they stay on NAND and are loaded afterwards by the code present in the ROM.
Maybe the Sandisk logo we see at boot can be modified to contain code? 128x64 / 8 = 1 more kB

But I don't even know if it's in ROM or in upper parts of the OF.

EDIT2 (I shouldn't press Post that fast):
I have thought about something else in the last days: if full FAT support can not be made, we could use a tool to modify the filesystem, and then in our bootloader assume a fixed location on the hard disk for the firmware (i.e. allocate a file at the very beginning of the partition for our rockbox firmware).

EDIT3 : or we can partition the disk and put a magic word in the first partition, so we know exactly at which offset to look for our firmware : much simpler because we avoid FAT

[atomikpunk]

I know this may look a bit stubborn (ok, it is a lot...) but what about trying your mkamsboot patch (see this message) not using 0x100 blocks of 0x200 bytes, but 0xFF blocks instead. Because I really feel like the "firmware block size" field may be a byte and not a word...

As for the sandisk logo, well in the m200 version it was in a (far away) library block, so probably the same for all V2s. This means nope, not available until the NAND is accessed...

As for the filesystem hacks, well yes that could work. I'd rather go with a "more elegant" approach if we can, but that could do the trick. We must take care however not to overwrite the firmware (that is located somewhere on the NAND).