On Tue, May 5, 2009 at 9:33 AM, ron minnich <[email protected]> wrote: > On Tue, May 5, 2009 at 8:26 AM, Patrick Georgi <[email protected]> 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. Myles -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
