On Mon, May 4, 2009 at 8:55 PM, Myles Watson mylesgw@gmail.com wrote:
Attached. This patch lets us create XIP stages for cbfs.
I'd like to see the picture of what you're imagining here. I thought CBFS was designed to grow in only one direction. Are you going to have to add components in a certain order to make this work? I don't see where you're padding or inserting blank areas.
no, cbfs files can be sparse. There is nothing in the design that requires that all entries be contiguous. In fact, given that remove exists, cbfs has to allow holes.
The padding is implicit in the way the fs code works. The code allocates a ROM image that is the size of the actual ROM, and initializes that ROM image with empty values. To add a file, it simply installs a cbfs file header at a location that is aligned with rom->header->align. The header has a type and a length.
All that this XIP code patch does is allow cbfs to install a cbfs file in the archive at an offset such that XIP will work for that file. That's it. It's a very simple addition.
There is actually no change to the find code in src/lib, in fact; that code also walks all of rom, in strides of 'align'. If we ever worry that 16 bytes is too small an increment we can change it at the command line, when we create a cbfs archive.
And, no, you don't have to add components in any particular order. The only requirement, in fact, is that XIP components have room to fit. That's about it.
ron