Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
fragilematter:
Okay, the led pin is the same on e200v2's also, it blinks them quite nicely. The only difference is that A3 is USB, not hold, so it only triggers when you start the sansa by plugging it into a usb port.
Anyhow, great finding, it will make my life easier as I'll test the other GPIOs.
Edit: funman, thanks for the warning, but it seems I was lucky. Anyhow, even if it went bad, I've got nand access to recover it ;)
atomikpunk:
Hi peeps,
hehe sorry I may have added the comments after compiling the code, my fault :)
Yes funman, there seem to be a library loading routine somewhere in the firmware block. I don't fully understand it yet but it is pretty that this routine loads a library block somewhere into RAM. I'll have a closer look and see if I can understand the flash mapping. It seems that the flash is directly accessed in the CPU memory map, not using the dedicated AMS3525 NAND interface(?).
But if you can find how to directly access the filesystem that would be THE finding of the day as we could load anything we want and would not be limited by the firmware size anymore :)
Edit: be careful when trying to output to GPIO pins, most should be safe but we don't know how they are connected and putting a 1 or 0 to a pin that isn't supposed to be driven this way could damage circuitry...
funman:
Hola fellow supporters of sansaV2 port :)
Some more informations today:
The library memory mappings overlap with each other.
I loaded acp_decoder and mp3_decoder and they shared a common area, that means only one can be loaded at a time.
That seems logic considering the small amount of RAM on the clip: 2Mbits
While writting a pattern search, I came on big problem: my code was 2 instructions too long to fit in the firmware block.
I couldn't reduce it, so I had a look at other firmwares: the firmware v17 (instead of latest v29) has the biggest room for code:
The firmware fills up 0x28 bytes in the last 0x200 bytes block, that leaves us with 0xD8 (216) bytes
We'll leave with this while a e200 owner flashes a modified firmware with firmware block's size incremented by 0x200, and following blocks shifted by 0x200.
mkamsboot.c should do this for you, but you should check if modifying the whole file size is ok, or if you have to remove 0x200 bytes from the end of the file (I'm not sure if it's padding or not)
For pattern testing, I want the device to do an infinite loop into 2 different states:
1 which blinks the led for ever
1 which lights the led; and do an infinite loop
light on / light blinking is our boolean for pattern found / not found; but I have trouble leaving the LED on.
I'll probably get some fresh air and return to it ;)
See you
fragilematter:
Well, you could probably engineer a image that I could dd directly to my e200v2 if space is a problem. I don't know how much we can assume that the code form the clips is similar to the e200s, the led was a lucky break.
Oh, and the firmware image and bridging the pads definitely works, I've managed to guide sucitrams into repairing his sansa by dd-ing the first ~30MB from my dump. He reported that his sansa wasn't doing anything that indicated it was running, and we got it to work again from the first try.
saratoga:
If you can flash and recovery anything using the pad trick, maybe its time to think about replacing the OF with a simple bootloader.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version