Am 05.05.2009 17:12, schrieb ron minnich:
On Tue, May 5, 2009 at 12:59 AM, Patrick Georgipatrick@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.
Patrick