[U-Boot] How does u-boot know where to put its start code?

[Rogan Dawes]

On 2011/04/20 10:29 AM, Albert ARIBAUD wrote:
> Hi Rogan,
> 
> Le 20/04/2011 09:46, Rogan Dawes a écrit :
>> On 2011/04/20 7:42 AM, Albert ARIBAUD wrote:
>>> Le 20/04/2011 04:23, Hebbar, Gururaja a écrit :
>>>> Hi,
>>>>
>>>> On Wed, Apr 20, 2011 at 02:43:23, Rogan Dawes wrote:
>>>>> Hi folks,
>>>>>
>>>>> I'm trying to understand a bit more about how u-boot creates the
>>>>> image, such that the CPU reset vector is pointing to the right piece
>>>>> of code when it is reset.
>>>>>
>>>>> i.e. my DNS323 (Orion5x) has a reset vector of 0xffff0000. But for
>>>>> the life of me, I can't find anywhere that actually references that
>>>>> value to place the start code at that point.
>>>>>
>>>>
>>>> Placing the final boot image is left to user who flashes/burns it
>>>> board. But it should be same as _TEXT_BASE (this is being removed now.
>>>> Orion5x is arm based). Also look
>>>> at<u-boot-src>\arch\arm\cpu\arm926ejs\start.S&
>>>> <u-boot-src>\arch\arm\cpu\arm926ejs\u-boot.lds for more info on how
>>>> linker is instructed to place the starting code at predefined address.
>>>>
>>>>> I'm basically trying to make sure that my CONFIG_SYS_TEXT_BASE is
>>>>> correct (the address in the flash to which I write the whole
>>>>> u-boot.bin file, right?.
>>>>>
>>>> This is passed to linker as the entry point.
>>>
>>> There is another point re: orion5x based boards: often, their designers
>>> preferred generating a linear image for U-Boot, but the fact that the
>>> vector address is at FFFF0000 makes it impossible to directly the image
>>> there because it is always greater than 64K. So the designers put some
>>> "pseudo-rom boot code" at FFFF0000 that will finally jump to an address
>>> lower in FLASH; for ED Mini V2 it is FFF90000, and that's where the
>>> U-Boot image is supposed to be flashed.
>>
>> So, is that the address that you would use for CONFIG_SYS_TEXT_BASE ?
> 
> Yes, exactly.
> 
>>> Rogan, I bet in the DNS323 case, the same applies modulo your Flash
>>> size. Try tracing through the FFFF0000 code, it should not last more
>>> than a few tens of instructions before it jumps to some absolute
>>> address.
>>
>> Do you think it would be possible to figure it out from the original
>> vendor u-boot?
> 
> Sort of: if you look up the vendor U-Boot source code and find nothing
> about 0xFFFF0000, that's a sign that it expects something else than
> U-Boot to kick in at that address.
> 
> You can also disassemble what lies at 0xFFFF0000 on your board, either
> live through JTAG or offline by running a binary extract of FFFF0000
> through objdump.

Ok, so this is what I get at 0xffff0000:

0000000: 5c10 9fe5 0060 91e5 5810 9fe5 0160 06e0  \....`..X....`..
0000010: 5410 9fe5 0100 56e1 0f00 001a 4c10 9fe5  T.....V.....L...
0000020: 0060 91e5 ff10 a0e3 0160 06e0 0100 56e3  .`.......`....V.
0000030: 0800 001a 3810 9fe5 0060 91e5 3410 9fe5  ....8....`..4...
0000040: 0160 06e0 3010 9fe5 0160 86e1 2010 9fe5  .`..0....`.. ...
0000050: 0060 81e5 0100 00ea 0000 00ea ffff ffea  .`..............
0000060: 18f0 9fe5 0000 04d0 0000 ffff 0000 8152  ...............R
0000070: 0800 04d0 2001 02d0 8080 ffff 1b82 0000  .... ...........
0000080: 0000 fdff ffff ffff ffff ffff ffff ffff  ................

Which disassembles to:

$ arm-linux-gnueabi-objdump -m arm -b binary -D mtdblock4-3

       0:       e59f105c        ldr     r1, [pc, #92]   ; 0x64
       4:       e5916000        ldr     r6, [r1]
       8:       e59f1058        ldr     r1, [pc, #88]   ; 0x68
       c:       e0066001        and     r6, r6, r1
      10:       e59f1054        ldr     r1, [pc, #84]   ; 0x6c
      14:       e1560001        cmp     r6, r1
      18:       1a00000f        bne     0x5c
      1c:       e59f104c        ldr     r1, [pc, #76]   ; 0x70
      20:       e5916000        ldr     r6, [r1]
      24:       e3a010ff        mov     r1, #255        ; 0xff
      28:       e0066001        and     r6, r6, r1
      2c:       e3560001        cmp     r6, #1
      30:       1a000008        bne     0x58
      34:       e59f1038        ldr     r1, [pc, #56]   ; 0x74
      38:       e5916000        ldr     r6, [r1]
      3c:       e59f1034        ldr     r1, [pc, #52]   ; 0x78
      40:       e0066001        and     r6, r6, r1
      44:       e59f1030        ldr     r1, [pc, #48]   ; 0x7c
      48:       e1866001        orr     r6, r6, r1
      4c:       e59f1020        ldr     r1, [pc, #32]   ; 0x74
      50:       e5816000        str     r6, [r1]
      54:       ea000001        b       0x60
      58:       ea000000        b       0x60
      5c:       eaffffff        b       0x60
      60:       e59ff018        ldr     pc, [pc, #24]   ; 0x80
      64:       d0040000        andle   r0, r4, r0
      68:       ffff0000                        ; <UNDEFINED>
instruction: 0xffff0000
      6c:       52810000        addpl   r0, r1, #0
      70:       d0040008        andle   r0, r4, r8
      74:       d0020120        andle   r0, r2, r0, lsr #2
      78:       ffff8080                        ; <UNDEFINED>
instruction: 0xffff8080
      7c:       0000821b        andeq   r8, r0, fp, lsl r2
      80:       fffd0000                        ; <UNDEFINED>
instruction: 0xfffd0000

And of course, the image that I wrote to the flash did not have this,
which explains perfectly why nothing works anymore.

Doh!

Now if I can just figure out how to write to my flash using OpenOCD, I
can hopefully recover.

Regards,

Rogan