I realized during the discussion that there is a fundamental improvement we can make to cbfstool. This change I am detailing is compatible with existing coreboot libraries. I describe it below and attach the patch.
I have made a very simple mod to cbfstool that is compatible with the src/lib/ code in coreboot. I.e. the tool changes but the coreboot code does not.
Currently, as cbfstool manages the ROM, there are files and empty space. To allocate files, the code does, first, a walk of the headers and, if that fails, does a brute-force search of the rest of the space.
We all agree that the brute-force search is not a good idea. What I realized is that we should actually have 'empty space' as a cbfs file. This simple change greatly simplifies everything else.
But how do we get a new file? Simple: we find an empty file and use it, splitting it if necessary.
Result: all cbfs operations are now on headers, and nothing else. No walking of the ROM trying to find a header.
So I've made a slight change. Instead of an "empty space" area with no valid headers, I've made a header for the empty space.
Now creation of a new cbfs follows these steps: - set up the boot block - create a file, of type CBFS_COMPONENT_NULL, that contains the empty space. CBFS_COMPONENT_NULL was already defined in cbfs.h
Here's an example:
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs create 1048576 2048 (cbfstool) E: Unable to open (null): Bad address [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0 Alignment: 16 bytes
Name Offset Type Size 0x0 0xffffffff 1046456
Note that the EMPTY area (type CBFS_COMPONENT_NULL) consumes the file area of the cbfs archive.
So how do we create a new cbfs file in the archive?
It's easy: walk the files and find a file of type CBFS_COMPONENT_NULL, which is as large or larger than the file you are trying to create. Then you use that cbfs file. - if the cbfs file is the same size as the NULL cbfs file, then it's easy: use it - if the cbfs file is smaller than the NULL file, you split the NULL cbfs file into two parts.
note that this works in the base case: the base case is that the whole storage is CBFS_COMPONENT_NULL.
Here's an example of adding a file. [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed t [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0 Alignment: 16 bytes
Name Offset Type Size t 0x0 stage 23176 0x5ab0 0xffffffff 1023240
Note that the NULL split and got smaller. But the entire ROM is still contained by the two files. To walk this entire rom will require two FLASH accesses -- no more.
Add another file: [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed tt [rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0 Alignment: 16 bytes
Name Offset Type Size t 0x0 stage 23176 tt 0x5ab0 stage 23176 0xb560 0xffffffff 1000024 [rminnich@xcpu2 cbfstool]$
So, taking current ROMs as an example, I can reduce FLASH accesses for cbfs from (potentially) thousands to (typically) less than 10.
Note that I have changed deletion. To delete a file, we just burn the type to 0. This allows us to make a file unavailabe in FLASH without a block erase, and to put a new file of same name with, it is hoped, no block erase either.
Comments welcome. This change should be tested by anyone who can give it a try.
ron