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

[Albert ARIBAUD]

Wolfgang Denk a écrit :
> 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).

Well, testing the FLASH version of U-boot will require that you flash 
it, right? Based on the hypothesis that JTAG cannot flash, then you have 
no choice but to flash it some other way.

What I did with U-boot in this case (worse yet: in a case where I did 
*not* have JTAG equipment at all) was to start from a u-boot with a 
proven low level init code, build it for RAM by disabling the low level 
code, test its flashing capability on unused sectors of FLASH, and once 
validated, build it also for FLASH. That was risky, but if you cannot 
flash with anything but U-boot, there was little else I could do.

>>>> 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 it is tightly limited then it cannot take the console code with 
itself, so it'll have to fetch it from NAND before being able to log 
anything. And for that, it needs RAM access. so basically it won't be 
able to log RAM activation when it happens (unless you think of loading 
extra code in IRAM, but if there is IRAM, it probably contains U1 at 
this stage). Better have a thoroughly JTAG-tested minimal U1 which does 
not log (or if logging is required, U1 logs to a buffer, and U2 will 
print the log once started, a bit like Linux early logging).

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

Then there could be a three-part split: U1, U2 and Ulib. Link them all 
as relocatable code, and let U1's core load and relocate Ulib, and U2's 
core relocate its own references to U1's loaded Ulib location. Easily 
said, I know, but we're still in brainstorming stage here so let's give 
it a look. Agreed, this three-way split is going to cost some extra 
execution time but it could keep overall footprint minimal.

Amicalement,
-- 
Albert.