[coreboot] cbfs XIP patch

[Patrick Georgi]

Am 05.05.2009 09:48, schrieb Carl-Daniel Hailfinger:
> On 05.05.2009 09:42, Patrick Georgi wrote:
>> Am 05.05.2009 06:55, schrieb ron minnich:
>>> There is actually no change to the find code in src/lib, in fact; that
>>> code also walks all of rom, in strides of 'align'. If we ever worry
>>> that 16 bytes is too small an increment we can change it
>>> at the command line, when we create a cbfs archive.
>> In that case, I'll have to revert a change made to lib/cbfs.c to walk
>> the chain of files (instead of a brute force walk through the whole
>> image). SeaBIOS will have to do likewise.
>>
>> And that means, that we either need some cache about file locations in
>> the readers, or certain operations will be very expensive (eg. SeaBIOS
>> looking for all kind of pci*roms)
>
> Doesn't zerofill solve that problem?
No, esp. with XIP images, we have no idea where images start and end. We 
have to look through the entire image for that.

I have some code for a "next" field that builds a chain without relying 
on "offset" and "len" (as the current chain walker do). That helps with 
a scenario like having two option roms right after another at the 
beginning of the ROM.
The current walker would be confused by that. (it always looks for the 
next file header after the current file's data)

The "next" field has the disadvantage that we can't simply hot-update 
anymore, as we'd have to change data (instead of merely adding it).

And solutions like "use the 'unwritten bytes' marker (eg. 0xffffffff) as 
end-of-chain identifier", so it can be overwritten feel quite unclean, too.


Patrick