[coreboot] LAR TODO
c-d.hailfinger.devel.2006 at gmx.net
Thu Feb 21 00:06:39 CET 2008
On 20.02.2008 20:17, Patrick Georgi wrote:
> Am Dienstag, den 19.02.2008, 16:48 +0100 schrieb Patrick Georgi:
>> How about doing segments per file (like right now), and simply
>> prepending their data "section" with the load address (as they already
>> get special treatment anyway).
> Follow up to this issue: the first bytes would also be compressed
> (otherwise we have a special case again).
> Currently the decoding routines only decode a whole file, but at least
> lzma is capable of stopping after a given number of output bytes. The
> only remaining issue is that the actual starting position for the
> decode is then 4 bytes below the intended loading position.
Sorry, that's just horrible(TM). I'd expect that as a emergency band-aid
hack if the header format was crap, but the header format makes such
runtime hacks unnecessary.
> Just decoding the first 4 bytes into some scratch space probably won't
> work (easily) because the lz-family uses decompressed data as
> dictionary space..
> This could be solved by ordering the segments by the lar tool to be
> highest-start-address-first, but this detail would have to be
> documented in a way that no-one will ever stumble over "weird 4 byte
> memory corruption" without quickly figuring out what's going on.
This guarantees we will never be unemployed because people will hire us
to understand random crashes in the code. Or they will move to another
codebase. Being too clever is bad. Having hidden side effects is so
badbadbad that I lack the words to describe it.
Please remember the problem we're trying to solve: Preserving entry
point and load address over an unpack/repack cycle. That is a pure LAR
userspace archiver problem and modifying any firmware code is not a path
to a viable solution.
More information about the coreboot