Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
funman:
--- Quote from: tobi-lu on July 31, 2008, 06:50:52 PM ---Aah I didn't see your edit till now ^^ I've been watching here all the time for you to post some news ;D
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---So far we can address all the firmware file, not only the firmware block !!
--- End quote ---
That's great news!
--- End quote ---
Well it needs double checking, because I tried putting some code to be executed in a padding block, and my checks failed.
The whole sleep loop is 5 instructions = 5 * 32 bits, so I decided to check each of the 5 words (which I knew) before branching to that offset, i.e.
if(instruction1==read_instruction1 && instruction2==read_instriction2 ...) jump_to_sleep();
boot_now();
but the clip was always booting immediately so it was not reading the correct code ...
I verified that I was reading at the file offset - 0x400 (firmware header) so I don't know what happened.
So I wanted to verify the 1st word: 0xdeadbeef, to be sure I was in the padding block.
--- Quote from: tobi-lu on July 31, 2008, 06:50:52 PM ---
--- Quote from: funman on July 31, 2008, 07:43:04 AM ---Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..
--- End quote ---
Well, if it is possible, why not... you don't want to brick your player, do you? ;) So being careful is never wrong.
--- End quote ---
But I recompiled/upgraded too quickly and I miss something ....
the code ran was:
--- Code: ---
ldr r3, =0x30400
ldr r2, [r3] /* load the word we are checking */
ldr r1, =0x38100000 /* verify that it's a pointer to the OF (0x138) */
cmp r1,r2
beq boot1
### missing r1 assignement ### damn !!
b boot
boot1:
mov r1,#0x500000 /* ~ 5 seconds */
b boot
boot: /* sleep loop */
subs r1, r1, #1
bne boot
ldr pc, original_entry #jump to OF
--- End code ---
I added the "b boot" because I was tired waiting for my sansa to boot but I forgot to fill r1 which holds the number of seconds to wait !!
It could be any 32 bits value, and according to echo `$((0xffffffff/0x500000*5))` I can wait for an hour or more before seeing my clip lcd screen enlight ...
I hope there isn't something like a watchdog timer which resets the device, will see tomorrow if it's bricked or not (else I will have to explore my room for the ticket).
<edit>It works !! It took more than one hour to boot but I got my Clip back and could put the original firmware on it, the adventure continue</edit>
Also I tried to not increase the firmware block size (there is code in mkasmboot to handle that but since all the firmware files I have seen have the same size, I prefer not to try...) so I had to comment some code ;)
If you want to experiment, be VERY careful because there is no easy way to recover your sansa (except with JTAG maybe..).
Something I looked into was to try to get some random bit and conditionally branch on OF when it's 1.
That way if your code is broken, you have 1 chance out of 2 to boot the OF and update it.
I tried reading from the registers but my tests always gave the same value (maybe there is some code ran before the sansa firmware which initializes them, or they are initialized when the hardware is powered, I don't know)
tobi-lu:
Hi!
I just don't manage to get a successful cmp, my e250 always waits 5secs before starting.
This is what i have done:
* Take the unmodified firmware file e200pa.bin (from http://daniel.haxx.se/sansa/v2/e200/e200v203.01.16a.zip)
* Open it in a hex editor
* Go to 4 bytes before the last checksum: address 0xEFFFF8 in firmware file
* Substract 0x400 from this value --> 0xEFFBF8
* Write this into test.S: .equ MAGICOFF, 0x00effbf8
* Edit firmware file at address 0xEFFFF8 to say 74 6F 62 69 (the value i've chosen)
* Now here comes the problem: what should I write into MAGICVAL? According to what you told me in jabber, it should be 0xf6479626. But that doesn't work, I have to wait 5 sec...
Can you tell me ehat I am doing wrong?
Thanks
Tobi
daniel_at:
Hey guys!
Cool to see some FW-hackers starting to get it started here. I'am not that used to ARM's and that stuff. But if someone wants to try a live session via IM with me, I am able to try various stuff on my E280 - because I can reliable unbrick it, if something went wrong. (As described in my earlier posts)
So testing new code could be faster and less nerve-racking.
My timezone is MESZ (UTC+2) and im quite often online... just conntact me via PM, than we can exchange IM-addresses (prefered Jabber).
Daniel
funman:
--- Quote from: tobi-lu on July 31, 2008, 09:24:03 PM ---
* Edit firmware file at address 0xEFFFF8 to say 74 6F 62 69 (the value i've chosen)
* Now here comes the problem: what should I write into MAGICVAL? According to what you told me in jabber, it should be 0xf6479626. But that doesn't work, I have to wait 5 sec...
--- End quote ---
The ARM CPU is little endian, so when you read a value from memory, the bytes are read in a
"reverse order" : least significant byte first.
When you edit the file with an hex editor your will see 74 6F 62 69
But the value (MAGICVAL) is 69 62 6F 74
Tell us if that works :)
tobi-lu:
Well, I've tried it, and also tried to put the magic value to another position in the file...
But it didn't work :(
daniel_at, can you please try this on your e280? Should be the same as with my e250, but who knows ^^
And have you seen my pm? If it didn't arrive for some reason, you can also find my jabber id in my profile (under YIM).
bye
Tobi
//edit:
I've been experimenting quite a lot now... My result is that it's NOT possible to access anything outside the firmware block using this method. The very last thing I can access is the 00 00 00 00 at 0x1DE18, which is right at the beginning of the first library.
I think the library starts exactly at 0x1de1c, and not at 0x1de00 as calculated by 0x400 + 0x200 * firmware_size_multiplier.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version