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

[Wolfgang Denk]

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.

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

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

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

Thsi is _exactly_ where the current design is coming from.

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

No, of course not. This is a complicated issue, where it's easy to
overlook one thing or another, so every comment is appreciated.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Randal said it would be tough to do in sed. He didn't say  he  didn't
understand  sed.  Randal  understands sed quite well. Which is why he
uses Perl. :-)         - Larry Wall in <7874 at jpl-devvax.JPL.NASA.GOV>