spyro at f2s.com
Sat Feb 1 15:57:37 PST 2003
Well, I was SO sure I had [guessed] it. but I hadnt. damn
After lazily not-quite-reverse engineering the bootloader, I found a
location (0x90049d00) which I was SURE was mapped to screen memory.
ah well. I suppose I will just need to stop guessing and ACTUALLY
reverse engineer some code.
Well, lets see now...
strings gives me this little gem (among others)...
206c Loading image (PPSH)
2090 Accelent Systems Inc.
20a8 Copyright (c) 1997-2002
the strings at 20a8 and 2090 are printed on the startup screen, so this
could be useful...
lets see now:
searching the bootloader dissassembly gives us:
46b8: 90002090 mulls r0, r0, r0
46bc: 900020a8 andls r2, r0, r8, lsr #1
which is interesting...
the RAM on PXA250 based devices is mapped in at 0xa0000000, so this
suggests that the MMU has been switched on at this point, and that the
bootloader (which we know has been copied from flash at 0x0 to RAM at
0xa0000000) has had its RAM mapped to virtual address 0x90000000 (there
are numerous hints that this is the case in the code).
so, we now need to find any reads of the addresses 0x46b8 and 0x46bc.
lets see now...
4628: e59f208c ldr r2, [pc, #8c] ; 46bc
462c: e3e04000 mvn r4, #0 ; 0x0
4630: e3a03000 mov r3, #0 ; 0x0
4634: e58d4000 str r4, [sp]
4638: e3a01001 mov r1, #1 ; 0x1
463c: e3a00001 mov r0, #1 ; 0x1
4640: eb000ac7 bl 7164 <__data_start+0x7164>
4644: e59f206c ldr r2, [pc, #6c] ; 46b8
4648: e3a03000 mov r3, #0 ; 0x0
464c: e3a01001 mov r1, #1 ; 0x1
4650: e58d4000 str r4, [sp]
4654: e3a00002 mov r0, #2 ; 0x2
4658: eb000ac1 bl 7164 <__data_start+0x7164>
what we have here is a read of 0x46bc into r2, so r2 now is a pointer to
the string (a virtual address). Then a few other registers are set up,
r4 pushed onto the stack (why?!) and a function is called at 0x7164.
after this, the same sequence is repeated, but for the other address.
Pretty conclusive - this is the code that is writing the text onto the
so, the next task is to disassemble the code at 0x7164 and try to trace
what do we know?
well, r1 is 1 in both cases.
r2 is a pointer to string, in both cases.
r3 is 0 in both cases.
r0 is 1 in the first case, and two in the second.
r4 is certainly 0 in the first instance, but not garaunteed to be
in the second.
My guess is that:
r0 = y position
r1 = x position
r2 = string to print.
r3 = text colour (this can possibly be verified searching for the
'Programming flash' string, which is printed in red, unlike these which
r4 = ????
Well, perhaps tomorrow I will have a crack at the print function at
0x7164. see what it can tell me.
Getting there, slowly...
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-chat' in the subject header of the message
More information about the lfs-chat