[U-Boot] [PATCH 2/4] Use LINK_OFF to access global data

[Graeme Russ]

On Mon, Jan 4, 2010 at 7:41 AM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> Wolfgang Denk a écrit :
>> Dear Albert ARIBAUD,
>>
>> In message <4B40F8DB.1090509 at free.fr> you wrote:
>>> Hmm... PIC is interesting only if you want the same binary to run from
>>> two places, like NOR then RAM, which is the case when U-boot is the code
>>> which gets run in NOR at power-up and ends up running in RAM later.
>>
>> This scenario is interesting for a lot of other use cases, for
>> example to load the new version to some free location in RAM, verify
>> that it works, then copy it (eventually by itself) to persistent
>> storage; this is especially useful for systems when your JTAG
>> debugger does not support programming images to NAND or DataFlash or
>> SPI flash or whatever storage device is used to store the image.

This is a very interesting use-case - I hadn't though about using U-Boot
version A running at location x to bootstrap into U-Boot version B running
at location y before U-Boot version B copies itself to Flash

>
> There is a way out of this one -- I used it myself -- where you build
> both versions of U-boot, the RAM-located one and the FLASH-located one.
> You load the RAM one, run it, and it loads and flashes the FLASH one.
>
>>> For NAND-based boards, the NAND bootloader will load U-boot to RAM, and
>>> U-boot will never run from anywhere else but its intended RAM location.
>>
>> Assume you have systems with different RAM size configurations. Being
>> able to load the same image to any address is beneficial then, too.
>> [And the NAND bootstrap code often does not allow for additional code
>> as needed for example for relocation.]
>
> The U1 bootloader might be given the ability to relocate the U2 code.
> that's probably far-fetched, but when linking U2, a map file could be
> generated and a script could produce a relocation table for U1 to use.
> The table could be put in NAND along with the U2 code, so U1 might not
> need to be regenerated for every new U2 build.
>

Have a look at my x86 relocation patch series - There is no need to do
this as there is enough information left in the binary if you use the
right gcc/ld options. I have a feeling that what I have done for x86
is portable to other arches.

While the above mentioned patch series allows relocation to an arbitrary
RAM location, it does not allow loading into an abitrarty ROM location.
Considering that there is a very limited range of functions that need to
run from an arbitrary ROM location (primarily RAM init and basic console)
I think we could get away with using this LINK_OFF scheme for a minimal
set of pre-RAM functions.

>>> Why not make the same two-stage separation systematic, even on NOR-based
>>> devices and others where U-boot is currently the one executed at
>>> power-up? Split the current U-boot into a small primary bootloader (U1?)

I support the greater seperation of U-Boot into a two stage boot loader. I
find it somewhat clumsy that ROM and RAM targeted code is mixed up together
in the same source files (board.c etc). I think we may now have a unified
path for relocation (without the -mrelocatable PPC only stuff). If this is
the case, we can finish the task of making all arches relocatable and split
U-Boot cleanly down the ROM/RAM divide.

For those of us who don't care about PIC in ROM, life is easy. For those
that want full PIC, they just need to put in a little more effort into
their ROM based code in U1.

>>
>> There are many reasons: ease of porting and debugging, minimization of
>> boot time, etc.

This opens up a new option for the previously mentioned use-case. We could
totally split U1 and U2 into seperate make targets. Once you have a stable
U1/U2 you flash them onto your board and then tweak versions of U2 and load
them into a seperate location in Flash (into seperate banks to avoid erasing
your known good U1/U2). At boot, you could have a console input to load
'last known good config' if your new U2 is a complete dud.

>
> Granted you'd have some added effort there, but possibly not so much in
> the porting and boot time departments, as executing U1 then U2 would
> roughly be the same as running today's full U-Boot, and equally, porting
> effort would be split rather than duplicated.
>
>>> and a fuller secondary bootloader (U2?). U1 would initialize RAM (and a
>>> console?) and U2 would initialize everything else. Each stage would only
>>> run from a fixed location and type of memory, removing the need for PIC.
>>
>> If you use a console in U1, you will need to share a LOT of code with
>> U2 - things like printf() and all it's dependencies, most of the
>> str*() and mem*() functions, etc.  And especially for such complicted
>> and error prone actions like initializing the RAM you _do_ want to be
>> able to use a console port to print error messages and debug
>> information.
>
> Nothing prevents linking in the same source code in U1 and U2, I think.
> Of course that would make U1 bigger, but you'd need the code in there so
> that's the price to pay -- and it would be a temporary use of RAM, as
> the RAM for U1 could be reused freed when U2 comes into play.
>
>> Thsi is _exactly_ where the current design is coming from.
>
> But obviously your call for comments also calls for a revision of the
> current design, doesn't it?
>

Regards,

G