[coreboot] cbfs XIP patch
patrick at georgi-clan.de
Tue May 5 17:26:39 CEST 2009
Am 05.05.2009 17:12, schrieb ron minnich:
> On Tue, May 5, 2009 at 12:59 AM, Patrick Georgi<patrick at georgi-clan.de> wrote:
>> 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)
> I am missing the point. Are they two cbfs files or ... if they are two
> cbfs files, then there is no problem.
> The case that the option ROMs are not part of cbfs? Or there are two option
> ROMs in one CBFS file?
Consider the following case: The system has _two_ images it requires at
fixed addresses right after another. We don't process these images (eg.
EC firmware) ourselves, but have to take care that they're at the right
spot (similar to your XIP stuff).
We want to keep the images as two entries in cbfs (as they have
different release cycles)
The layout would look like this:
file1-data | file2-data
The current algorithm in coreboot and seabios says to walk the chain by
taking the current cbfs_file address, adding the offset (so you're at
the beginning of the file in question), and adding the file length (so
you're at the first byte after the file in question). There, the current
algorithm expects a new cbfs_file header.
But there's already file2's data in the way. Oops.
With the next field, we decouple the file location and the cbfs_file
location completely. offset/len point to the file data, next points to
the next header.
More information about the coreboot