Le 19/11/2010 12:11, Wolfgang Denk a écrit :
Dear Sebastien Carlier,
In messagesebastien.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,