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

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4B4100F3.8080507 at free.fr> you wrote:
>
> > 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.

Of course this works, but this is then _another_ image, which was not
tested yet. This is bad both from the administration point of view
(need of two differently built images), and bad for the nerves (as you
install an untested 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.]
> 
> 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.

Keep in mind that U1 often has to fit in as little memory as 4 KB or
so...

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

Creating twobig parts (U1 and U2) is bad for the overal flash memory
footprint, and for the boot time. And usually iut doesn;t work at all
on NAND etc.

> But obviously your call for comments also calls for a revision of the 
> current design, doesn't it?

Sure.

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
Things are not as simple as they seem at first.        - Edward Thorp