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

[Albert ARIBAUD]

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.

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.

>> 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?) 
> 
> There are many reasons: ease of porting and debugging, minimization of
> boot time, etc.

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?

Amicalement,
-- 
Albert.