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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
