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

Albert ARIBAUD
2010-11-19T11:40:05Z

Le 19/11/2010 12:11, Wolfgang Denk a ?crit :
> Dear Sebastien Carlier,
>
> In message<sebastien.carlier@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.