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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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.