[coreboot] cbfs XIP patch

Patrick Georgi 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 mailing list