[U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Albert ARIBAUD]

Le 19/11/2010 12:11, Wolfgang Denk a écrit :
> Dear Sebastien Carlier,
>
> In message<sebastien.carlier at f67ce90ecc8846695b88fb9ac74f99d56979b90a>  you wrote:
>>
>> I am still not getting why the code needs to be split this way, rather
>> than being a continuous segment followed by an environment sector.
>> Whether the environment sector is in the middle of the binary or
>> immediately after the binary does not make a difference (does it?), so
>> the motivation must be something else...
>
> The used flash chips are so-called bootom boot sector types; using two
> chips in 16 bit config in parallel (to get a 32 bit bus) we see this
> flash layout:
>
>    Sector Start Addresses:
>    40000000   RO   40008000   RO   4000C000   RO   40010000   RO   40020000   RO
>    40040000   RO   40060000 E      40080000 E      400A0000 E      400C0000 E
>    400E0000 E      40100000 E      40120000 E      40140000 E      40160000 E
>    40180000 E      401A0000 E      401C0000 E      401E0000 E      40200000 E
>    40220000 E      40240000 E      40260000 E      40280000 E      402A0000 E
>    402C0000 E      402E0000 E      40300000 E      40320000 E      40340000 E
>    40360000 E      40380000 E      403A0000 E      403C0000 E      403E0000 E
>
> So erase block sizes are 32 k, 16 k, 16 k, 64 k, 128 k, 128 k, 128 k, ...
>
> With a normal configuration, U-Boot code wouild occupy all the small
> sectors, and we would have to waste two of the 128 kB blocks for
> environment plus redundant copy.
>
> It makes a lot sense to me to reserve a "gap" in the U-Boot image and
> put the environment instead into the two 16 kB sectors starting at
> 40008000 and 4000C000.
>
> The linker script squeezes as many as possible objects into the first
> 32 kB ssector, then creates a gap for the environment, and ten
> continues to place the remaining objects starting at offset 40010000.
>
> That's what we call "embedded environment", because it sits right in
> the middle of the U-Boot image.

There is a variant of this problem with many ARM boards, those based on 
Marvell SoCs for instance, which have a start address at 0xFFFF0000 -- 
that's a 64K block the usage of which we want to maximize.

I had a general solution to this by, in summary, building a linear 
u-boot, then splitting the binary when flashing, and have the copy loop 
in the startup stitch back the parts. However, this solution did not 
work well with relocation, and may not necessarily be applicable to 
non-ARM archs. However, now that we have a (mostly) stabilized 
relocation mechanism, I'll dig again into this solution.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.