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

[atomikpunk]

*puts nose in big book*

Don't read it too fast like I did (it was too easy)

[MarcGuay]

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.

I can't tell if this has been confirmed yet but the chip in the bottom right of this photo:



Looks like a newer version of the SD controller in the e200v1's:



and the SD c100's

[atomikpunk]

Well on the clip there doesn't seem to be any "translation" chip on the PCB, though I suspect it to be inserted in the AMS SoC. In fact, you will notice that the SoC is labelled with Sandisk markings so I suspect that Sandisk bought the AMS die, and added some more logic to it to support SD-interfaced NANDs. Which would in fact also explain the "spare registers for metal ECO redesign" usage...

Any comments on that? Anyone with experience in dies and chip customization?

[daniel_at]

Just wanted to note: the term 'eco' (as you have found in the datasheet in conjunction with the sd-access) ppbl. stand for engineering change order - so it is indeed _very_ likely that sansa has added some more logic into the SoC.

http://en.wikipedia.org/wiki/Engineering_Change_Order

Daniel

[funman]

Hi

I noticed OF will set the bit2 of the CCU_SPARE1 register if C1 pin reads #1, and clear the same bit2 if C1 reads #0, probably C1 is #1 when the SD-NAND interface chip is present.

On the Clip C1 was #1 when I tried it, could you check the value on E200 ?

EDIT: The exact same code is used in the e200 firmware (read C1, store the value in ram (the offset where the first nand/sd structure is stored - #8, use this value to clear/set the bit in the spare register).
However as fragilematter showed here C1 is #0 , maybe because the chip used in the e200 and the clip is different ?

Maybe with good eyes you can also see if there is a connection between C1 and a chip near the NAND ?

Mine are too weak to notice anything on the little Clip (and we didn't find any visible SD chip anyway)


EDIT2: I posted a patch on FS#9396 which uses a stage2 written in C.
I hope it attracts more hackers and make our code less error prone

[atomikpunk]

Hi peeps,

I haven't posted in a while but as usual, things are still going on under the hood. funman wrote a nice C-version of his stage1/2 bootloader, we both still try to make that (damn) flash interface to work, and beside I started looking at building an LCD driver (because sometimes one need to look at something else than disassembled code ).

funman: almost everything in your C-version seems to be alright except that the return instruction from _start that seems to compile as a BX instruction, which may be wrong since both our crt0.S and stage2.c are ARM code... I'll have a look back at it tomorrow.

[funman]

funman: almost everything in your C-version seems to be alright except that the return instruction from _start that seems to compile as a BX instruction, which may be wrong since both our crt0.S and stage2.c are ARM code... I'll have a look back at it tomorrow.

Looks normal: BX Rm switches to Thumb mode if and only if Rm[0] == 1
Since the instruction we are coming from is aligned on 2, no problem.

Note on my computer it doesn't use BX but:

Code: [Select]

STM.. SP!,...,LR
LDM.. SP!,...,PC
Of course we assume that the gcc used to  build the bootloader has no bugs, the produced binary could brick your device definitely if it was the case.

Maybe for the final bootloader, we will make gcc output assembly code, check that the code is correct manually and maybe optimize the size of the code a bit, to remove any doubt.

On a side note, kugel found yesterday on his Fuze that gpio A3 is #1 when the device is powered over usb, so A3 can be used as a recovery on Fuze, E200, Clip.
C200 and M200 owners, any volunteer for testing on your model ?

P.S. I'm waiting for your LCD code

[atomikpunk]

Just a quick note to say that I looked at a disassembled binary produced by our toolchain and it looks fine at first sight, good job!

[linuxstb]

I have a plan to deal with the problem of inserting a Rockbox bootloader into the OF, whilst maintaining a reliable dual-boot feature.

However, this is based on the theory that the firmware image we're patching is not in fact stored in the 128KB internal ROM of the AS3525, but that the internal ROM stores a standard AMS bootloader (this seems to be referred to as "C21" in the datasheet), which loads the OF from the NAND flash into RAM and then executes it.

I haven't been following this forum thread closely, but the SansaV2Firmware wiki page seems to suggest that the main firmware image is stored in ROM - but as far as I can see this is indeed Read-Only Memory - i.e. there is no way to update the contents.

The idea is simply to compress the main firmware block of the OF.  UCL compression (used in Rockbox for the older Archos devices to compress flash-ROM images) is ideal for this, and I have a found a thumb version of the UCL decompress function which is only 180 bytes long.

My test firmware is m300a-1.1.17A.bin for the Clip.  The main firmware block is 119808 bytes (119336 bytes for the OF, plus 472 bytes of padding).  The 119336 bytes of the OF compresses to 77753 bytes with UCL.

The idea is to build a new main firmware block as follows:

Bytes 0-41582 would store our Bootloader, linked to run from address 0x0
Bytes 41583-119335 would contain the UCL-compressed version of the OF
Bytes 119336-119808 would contain a function to decompress the OF "in-place" and run it by branching to 0x0

Our bootloader would need to check for a keypress, and if pressed (or not pressed), then branch to the "ucl_decompress" function.  Otherwise, it would just continue running.

No RAM outside the area used by the OF would be touched, so assuming no bugs, this should be safe...

Does this sound feasible to those of you that have hacked the V2 more than me?  Is the assumption that the OF is already running in RAM a valid one?

[kugel.]

Well, the fact that you can write a firmware directly to the NAND (as in dd'ing it onto the device, not letting the player update itself -- the recovery method of the e200v2) which is then used directly after the next boot implies that it's loaded from NAND to RAM, doesn't it?

Or did I get something wrong here?

I like your idea. It sounds definitely feasible to me.

[funman]

Very good idea linuxstb!

And your theory is indeed confirmed.
I remember testing this by writing to the memory and reading back and the values didn't match, but I probably messed up my test.

This time I'll attach my code (test.S for svn checkout) so others can proof-read and test it.

It confirms that we can write to the memory, and I also checked the CCU_MEMMAP register : it indicates that RAM is mapped at offset 0x0

I'll try to assemble the parts needed for using your method and call for e200 testers to be sure just to be sure

Also I think we could measure the size we gain on different firmware versions to get the maximum.

EDIT: here are the sizes we can use for our bootloader (padding was not taken into account):
clip v01.01.17 40756 bytes
clip v01.01.18 41247 bytes
clip v01.01.20 41430 bytes
clip v01.01.29 41934 bytes
fuze v01.01.11 38746 bytes (note : strings on the file reports V4.0.45A, could it be because the firmware is more modern ?)
e200 v03.01.16 41727 bytes

So that means ~40 kB (plus the padding of the firmware block, less the button check and the decompressing function), quite enough for now

[atomikpunk]

Hi peeps,

well I started coding the LCD driver for the clip. But coding it in C makes it quite big though I doubt it would be much smaller coding it directly in assembly. So yeah, I'd be very interested if you (funman? linuxstb?) get to make a "decompilable" OF that would lend us some space

The LCD driver would be helpful for debugging purposes but I doubt we will leave it in the first "stage" once we're there. I guess we will load it from the NAND which will leave us with much more playing space...

[linuxstb]

So that means ~40 kB (plus the padding of the firmware block, less the button check and the decompressing function), quite enough for now

And of course we can also ucl-compress our bootloader, which should take it up to about 60-70KB...

This should be enough for a full Rockbox bootloader, which are typically about 40-60KB.  So this would seem to be a long-term solution.

EDIT: I have now committed to SVN my first attempt at adapting mkamsboot to do this.  Please can all interested people look at this code, compile and disassemble it.  It's NOT safe to run yet, but I committed it so other people can see it and help review it.

[funman]

The actual code (revision 18676) is confirmed to NOT work.

If you want to debug it you can use skyeye arm emulator.

I use the following skyeye.conf:

Code: [Select]

cpu: arm920t
mach: at91rm92

mem_bank: map=M, type=RW, addr=0x00000000, size=0x00050000, file=./fw.bin
mem_bank: map=M, type=R, addr=0x00100000, size=0x00010000
mem_bank: map=M, type=RW, addr=0xc0000000, size=0x00200000
mem_bank: map=M, type=RW, addr=0x20000000, size=0x000f0000
mem_bank: map=M, type=RW, addr=0xc0200000, size=0x00500000
mem_bank: map=M, type=RW, addr=0xc0700000, size=0x01900000
mem_bank: map=I, type=RW, addr=0xfffa0000, size=0x00060000

load_addr:base=0x20000000, mask=0xFFFF
with fw.bin being the patched firmware block.

skyeye expects an elf program, I use the following to start execution of our firmware:

Code: [Select]

int _start(void) {

    asm volatile( "mov r0, #0" );
    asm volatile( "bx r0" );

loop: goto loop; /* remove the asm statements to put skyeye in an infinite loop */

    return 0;
}
Note, to use gdb with skyeye, use the -d option of skyeye and connect to the running gdbserver like you would do on any other remote gdb (use a gdb built for arm of course).

[pedrov]

Hi all,

I borrowed a JTAG usb interface from my firm (it looks like this : http://www.iar.com/website1/1.0.1.0/369/1/index.php), and I have a sansav2 e2xy model. I would like to know if I could help you on the port, but I don't have any experience on hardware tweaking. IIRC, atomikpunk already succeeded in connecting a JTAG interface on the device. Any advice ?

Regards,