It is nearly trivial.
Signed-off-by: Myles Watson<mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4279 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Tested to booting linux with qemu.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Myles Watson<mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4276 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Change sizes from unsigned int to int.
Clean up some usage and parameter checking.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4262 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
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 has lots of problems from a
performance and correctness standpoint.
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.
So cbfs creation looks like this:
- 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
So how do we create a new file?
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 file.
- if the file is the same size as the NULL file, then it's easy: take it
- if the file is smaller than the NULL file, you split the NULL 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.
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.
Index: fs.c
Changes for readability and cleanliness. Move common blobs of code to functions.
New function: rom_alloc,which allocates files by finding NULL files and using/splitting.
Other changes as needed to support this usage.
Index: util.c
Creating a cbfs archive now requires creation of a NULL file covering the file system space.
Index: cbfs.h
Add a DELETED file type with value 0. Any file can be marked deleted by zero its type; this is a
FLASH-friendly definition for all known FLASH types.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
I think it is a step in the right direction. Could you add the
function prototype to cbfstool.h?
Acked-by: Myles Watson <mylesgw@gmail.com>
(I added the prototype)
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4261 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I didn't try to remove "defined but not used" warnings because there are too
many ifdefs to be sure I wouldn't break something.
For shadowed variable declarations I renamed the inner-most variable.
The one in src/pc80/keyboard.c might need help. I didn't change the
functionality but it looks like a bug.
I boot tested it on s2892 and abuild tested it.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4240 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
anything that was there. For ck804 or mcp55-based machines that was the
romstrap.
The fix is simple:
1. Put the master cbfs record above the bootblock instead of on it.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4209 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
caused a seg fault, sometimes executed somewhere else. Also add an error if
the algorithm is unknown.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ward Vandewege <ward@gnu.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4198 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cbfstool extract [FILE] [NAME]
It also factors out the csize calculation in rom_add, and fixes rom_delete so
that it can handle deleting the last entry.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4144 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4114 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I noticed this before sed, but forgot to change it back after sed.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It's all sed here. romfs->cbfs, ROMFS->CBFS, romtool->cbfstool
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4110 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Myles Watsonmylesgw