Rockbox Development > New Ports

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

<< < (50/386) > >>

funman:
great !!!

Can you test this one which will allocate the biggest size possible (0x100 * 0x200 = 128KB) for the firmware block ?

If it's fine I'll test it on the Clip and ask someone to commit the patch

EDIT: attached corrected patch

atomikpunk:
Hey oh one second, the biggest possible should be 0xFF since the firmware header allocates 1 byte for the "firmware size" field... :)

fragilematter:
The output is 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 - 0x00020000
New firmware size - 0x00020000
Bootloader size - 0x00000074
New padded size - 0x00020000
original firmware entry point: 0x00000128
New entry point: 0x0001d820
--- End code ---

But, unfortunately, it still needs some work. The inserted code works ok, but the firmware freezes after completing the sansa logo animation.
It's almost midnight so I won't try to recover it now, it's time for me to get some sleep.

I'll check back tomorrow as soon as I get back home. Cheers!

atomikpunk: thanks for the try, but I was quicker :D
OTOH, holding the power button for a few seconds to power the e200 off works  even if the firmware is messed up.

funman:

--- Quote from: atomikpunk on September 02, 2008, 04:21:43 PM ---Hey oh one second, the biggest possible should be 0xFF since the firmware header allocates 1 byte for the "firmware size" field... :)

--- End quote ---
I would think it is rather 1 word, but it should be checked indeed.

Try using 0xFF as the new size instead of 0x100 (3 occurences) in the last patch,
or increase the shift value in the first patch.

Note: this should be tried on several firmware versions to ensure it works flawlessly.

fragilematter and sucitrams thanks for testing :)

EDIT: the patch was wrong, it wouldn't shift the library blocks (memmove() case not made, as show fragilematter's output). I updated it, can you retest?

atomikpunk:
Maybe you are right, I did look back at the wiki to refresh my memory (no pun intended) and saw that this "multiplier" is aligned on a 4 bytes border, so it could indeed be a dword. But again, I'd have a look at the OF to see if there are hardcoded addresses that could be messed up with a displacement.

Another interesting test would be to know where the ROM is located in memory and if we can access library blocks directly from the at-boot CPU memory map or if we need to configure something before being able to do so...

Anyhow, that's it for tonight :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page