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

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

[Rogan Dawes]

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.

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?.

Thanks

Rogan

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

[Hebbar, Gururaja]

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.

> Thanks
> 
> Rogan


Regards, 
Gururaja

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

[Albert ARIBAUD]

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.

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.

>> Thanks
>>
>> Rogan

Amicalement,
-- 
Albert.

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

[Rogan Dawes]

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 ?

> 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?

Thanks

Rogan

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

[Albert ARIBAUD]

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.

> Thanks
>
> Rogan

Amicalement,
-- 
Albert.

[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

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

[Rogan Dawes]

On 2011/04/20 12:17 PM, Rogan Dawes wrote:
> Now if I can just figure out how to write to my flash using OpenOCD, I
> can hopefully recover.
> 
> Regards,
> 
> Rogan

Phew! Thanks to Albert's sloflash utility, I was finally able to get
something back into my flash, and get the board booting again. What a
relief! :-D

Now I need to solve the problem of placing the _start code at the
address of the reset vector, since I have 3 64kB sectors to play with,
but one of them is 99% empty, other than the reset vector code which
just jumps to _start.

And of course, a mainline u-boot will not fit into just 128kB.

Any thoughts on how to link u-boot to place _start or any other routine
that can jump to _start at 0xffff0000?

I had this suggestion on IRC:

            . = .;
            __u_boot_cmd_start = .;
            .u_boot_cmd : { *(.u_boot_cmd) }
            __u_boot_cmd_end = .;

            . = _start + 0x70000;
            .reset_vector_sect :
            {
                    arch/arm/cpu/arm926ejs/start.o (.reset_vector_sect)
                    *(.reset_vector_sect)
            }



    #include <asm-offsets.h>
    #include <config.h>
    #include <common.h>
    #include <version.h>

    .section    ".reset_vector_sect",#alloc, #execinstr
    _reset_vector:
        b   _start


Although I'm not sure how to interpret it :-)

Regards,

Rogan

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

[Albert ARIBAUD]

Le 22/04/2011 14:45, Rogan Dawes a ?crit :
> On 2011/04/20 12:17 PM, Rogan Dawes wrote:
>> Now if I can just figure out how to write to my flash using OpenOCD, I
>> can hopefully recover.
>>
>> Regards,
>>
>> Rogan
>
> Phew! Thanks to Albert's sloflash utility, I was finally able to get
> something back into my flash, and get the board booting again. What a
> relief! :-D
>
> Now I need to solve the problem of placing the _start code at the
> address of the reset vector, since I have 3 64kB sectors to play with,
> but one of them is 99% empty, other than the reset vector code which
> just jumps to _start.
>
> And of course, a mainline u-boot will not fit into just 128kB.
>
> Any thoughts on how to link u-boot to place _start or any other routine
> that can jump to _start at 0xffff0000?
>
> I had this suggestion on IRC:
>
>              . = .;
>              __u_boot_cmd_start = .;
>              .u_boot_cmd : { *(.u_boot_cmd) }
>              __u_boot_cmd_end = .;
>
>              . = _start + 0x70000;
>              .reset_vector_sect :
>              {
>                      arch/arm/cpu/arm926ejs/start.o (.reset_vector_sect)
>                      *(.reset_vector_sect)
>              }
>
>
>
>      #include<asm-offsets.h>
>      #include<config.h>
>      #include<common.h>
>      #include<version.h>
>
>      .section    ".reset_vector_sect",#alloc, #execinstr
>      _reset_vector:
>          b   _start
>
>
> Although I'm not sure how to interpret it :-)

Basically (the excepts are only a sketch of what is really needed) it 
amounts to manually mapping code sections, some at FFF80000 and some 
(the reset vectors first) at FFFF0000. It does not fill up the last 
sector at FFFF0000, not in this form at least, because the last sector 
would only contain the reset sector sections; you'd have to select other 
input sections to complement the reset vector ones. Plus, the generated 
binary would actually span the whole flash, from FFF80000 to FFFFxxxx, 
which is *huge*.

> Regards,
>
> Rogan


Amicalement,
-- 
Albert.