PDA ramblings...

Ian Molton 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
   2100 startup.bmp

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
it through.

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
are black)
  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 mailing list