[coreboot] cbfs XIP patch

Myles Watson mylesgw at gmail.com
Tue May 5 17:36:54 CEST 2009

On Tue, May 5, 2009 at 9:33 AM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, May 5, 2009 at 8:26 AM, Patrick Georgi <patrick at georgi-clan.de> wrote:
>> 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.
> Thanks, I see it now.
> So this scenario requires that we have two cbfs file headers, and data
> somewhere else, not necessarily contiguous with the
> header. Does the cbfstool currently create this kind of image?
I don't think so.

I think CBFS requires the header to be contiguous with the data.  We
could change it, but that seems like a fundamental redesign.

It would be easier to walk if all the headers were contiguous.


More information about the coreboot mailing list