Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
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 ;D).
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:
--- Quote from: atomikpunk on September 28, 2008, 10:50:53 PM ---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.
--- End quote ---
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: ---STM.. SP!,...,LR
LDM.. SP!,...,PC
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version