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

[Albert ARIBAUD <albert.aribaud@free.fr>]

Wolfgang Denk a ?crit :

> I think as follows:
> 
> In the past, the majority of systems supported by U-Boot where
> booting from NOR flash or other memory devices. This made it easy to
> use common code (like library functions) both before and after
> relocation to the final location in RAM. For your current changes
> this means that we have a large number of places where we have to add
> this LINK_OFF stuff. This makes the code harder to read, much harder
> to understand (especially if it's not working during the initial
> bringup on new hardware), and harder to debug in general.
> 
> If I try to see trends in the development of U-Boot I notice a
> growing number of systems that boot from NAND flash, DataFlash or
> that come with on-chip ROM code to load images from SDCard and other
> storage media. Such systems cannot make real benefit from the
> original design of U-Boot, as here U-Boot is inherently a
> second-stage boot loader which gets loaded by some other means. Even
> for NAND booting systems where we have the NAND boot code included
> within the U-Boot source tree we often cannot share much of the code
> between the primary and the secondary loader stages as there are
> usually tight restrictions on the maximum size for the primary loader
> image. Here a sharper separation of "primary" and "secondary" boot
> code within U-Boot would be benefical.
> 
> I feel (but this is really just a feeling, and I definitely would like
> to hear what others think about this!) your PIC changes would be (or
> have been) useful for the former usage mode, but they come at a pretty
> heavy cost as they are really invasive to the code.  For the second
> usage mode they are not usable, or at least not useful.  This makes me
> wonder if we really should continue to work in this direction.
> 
> Comments welcome...
> 
> Best regards,
> 
> Wolfgang Denk

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.

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.

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

Comment given off the top of my head, so feel free to open fire. :)

Amicalement,
-- 
Albert.