Rockbox Development > New Ports

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

<< < (49/386) > >>

sucitrams:
dd says, that there is no space left. dmesg shows 1024MB.

fragilematter:
Maybe it's somehow connected to the fact that I can't read more than 113.4MB from my sansa. Either that or you've damaged your nand/usb controller or something else from your player.

Perhaps you could try this (it's not directly related but it might help): sometimes the sansa lags when connected to the usb, and linux's usb stack keeps waiting for it. I found that it helps running a lsusb, it somehow makes the player to respond and connect properly to the usb.

funman:
sucitrams you still have hope: the recovery mode is present.

leave it for one day or two, and try again to put the OF
Now at least we know that we must only use the recovery mode to put safe firmwares

In the meantime I attach a diff for mkamsboot.c which will keep the total file size, while shifting the content after the firmware block.

The firmware produced passes my various checks at being a normal firmware, but only testing will confirm if it's usable or not.

Note: the patch could be extended to reserve maximum size (128kB firmware block) and check for bootloader size, I will do that if this first patch works

atomikpunk:
Well I don't want to look like giving lessons or anything because I'm as curious as you guys, but I thought we would discuss the modified firmware before flashing it to a device :'(

Did you add a dummy 0x200 bytes and update the firmware header? If not, then the firmware can't do anything good... It looks for the library blocks 0x200 bytes earlier each time, which happen to be in the DEADBEEF area most of the time (if not all). So the firmware looks at a wrong header, which gives it wrong addresses where to load the data to, wrong addresses of executable routines, wrong addresses of variables, etc. So in short, the CPU writes about anything anywhere, which results in crashed player.

And if fact, I don't know if my memory fails me but I think I saw absolute routine addresses at some places in the firmware, so anything moved and bam...

However, if you still can load up the "recovery mode" with a firmware like this, it definitely confirms that this mode's code is located somewhere else than in the firmware and is good news. So I guess that with some work, the device should be unbrickable.

fragilematter:
I quickly tested the patched mkamsboot.c

The output was this:

--- Code: ---gcc -o amsinfo -W -Wall amsinfo.c
gcc -o mkamsboot -W -Wall mkamsboot.c
arm-elf-as -o test.o test.S
test.S: Assembler messages:
test.S:0: Warning: end of file not at end of a line; newline inserted
arm-elf-ld -e 0 -o test.elf test.o
arm-elf-objcopy -O binary test.elf test.bin
./mkamsboot e200pF.bin test.bin patched.bin
Original firmware size - 0x0001d81c
Padded firmware size - 0x0001da00
Shifted by 1 blocks
Bootloader size - 0x00000074
New padded size - 0x0001da00
original firmware entry point: 0x00000128
New entry point: 0x0001d820
--- End code ---

Flashed successfully, all the functionality is there (I didn't to a thorough test, but it seems OK) and the inserted test.s code also works.

I think sucitrams tried to directly dd a firmware update image to the nand, but, as I've shown earlier, the firmware update expands the firmware to 30MB, or at least it appears that way on my nand dumps.

Navigation

[0] Message Index

[#] Next page

[*] Previous page