coreboot-kgpe-d16/util/cbfstool/fs.c

480 lines
13 KiB
C
Raw Normal View History

/*
* cbfstool
*
* Copyright (C) 2008 Jordan Crouse <jordan@cosmicpenguin.net>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
*/
#include <string.h>
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 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
2009-05-08 21:23:00 +02:00
#include <stdlib.h>
#include "cbfstool.h"
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 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
2009-05-08 21:23:00 +02:00
int namelen(const char *name)
{
return ALIGN(strlen(name) + 1, 16);
}
/**
* Given a name, return the header size for that name.
* @param name The name
* @returns The header size given that name
*/
int headersize(const char *name)
{
return sizeof(struct cbfs_file) + namelen(name);
}
/**
* Given a name, set it into the header in a standard way
* @param file the cbfs file
* @param name The name
*/
void setname(struct cbfs_file *file, const char *name)
{
memset(CBFS_NAME(file), 0, namelen(name));
strcpy((char *)CBFS_NAME(file), name);
}
/**
* Given a name, size, and type, set them into the header in a standard way.
* Special case of size of -1: set the size to all of ROM
* @param rom The rom
* @param c The cbfs file
* @param name The name
* @param size The size
* @param type The type
* @returns Always 0 for now
*/
int rom_set_header(struct rom *rom, struct cbfs_file *c, const char *name, int size, int type)
{
unsigned int csize;
csize = headersize(name);
strcpy(c->magic, COMPONENT_MAGIC);
/* special case -- if size is -1, means "as much as you can"
* it's usually only used in init.
*/
if (size < 0)
size = rom->fssize - csize;
c->len = htonl(size);
c->offset = htonl(csize);
c->type = htonl(type);
setname(c, name);
return 0;
}
int nextfile(struct rom *rom, struct cbfs_file *c, int offset)
{
return ALIGN(offset + ntohl(c->len),
ntohl(rom->header->align));
}
This is transition code for cbfs to implement cbfs files at fixed addresses. I call this transitional as the approach I am taking is to add capability to cbfstool but not change code in a way that will break existing usages. Later, once we're sure nothing has broken, we can start to smooth the edges. Right now, fixed address file are only supported via the add command. There is one additional command syntax, so, example: cbfstool add rom romstrap optionrom 0xffffd000 Will add the file to that fix location for a romstrap. The assumption is that the ROM is based at the end of a 32-bit address space. As you can see from the code, that assumption can easily be over-ridden, if we ever need to, with a command option. Here is one example output result. rminnich@xcpu2:~/src/bios/coreboot-v2/util/cbfstool$ ./cbfstool x.cbf print x.cbf: 1024 kB, bootblocksize 32768, romsize 1048576, offset 0x0 Alignment: 16 bytes Name Offset Type Size h 0x0 optionrom 251 0x130 free 917120 h3 0xdffe0 optionrom 251 0xe0110 free 97960 The way this is implemented is pretty simple. I introduce a new operator, split, that splits an unallocated area into two unallocated areas. Then, allocation merely becomes a matter of 0, 1, or 2 splits: 0 split -- the free area is the exact fit 1 splits -- need to split some off the front or back 2 splits -- need to split off BOTH the front and back I think you'll be able to see what I've done. I call this transitional because, in the end state, we only need one allocate function; for now I've left two in, to make sure I don't break compatibilty. Why I like this better than ldscript approach: I like having the ROMSTRAP located by cbfs, not linker scripts. For one thing, it makes romstrap visible as a first class object. I think I would have latched onto a problem I was having much more quickly had I remembered the ROMSTRAP. It gets lost in the linker scripts. At this point, we should be able to start removing special ROMSTRAP location code from linker scripts. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-06-08 05:33:57 +02:00
/* split
* split is a basic primitive in cbfs. Over time, it should be the main operator
* used to allocate space. For now for testing we are only using it in the
* fixed-address allocation.
* Split takes a cbfs_file and splits it into two pieces, as determined
* by the size of the file desired. Split only makes sense on CBFS_COMPONENT_NULL
* files -- splitting real files is an error, but no checking is done.
* @param file cbfs_file to split
* @param size Size of the file desired.
* @returns pointer to a cbfs_file stuct.
*/
static struct cbfs_file *split(struct rom *rom, struct cbfs_file *file, int size)
{
struct cbfs_file *newfile = NULL;
unsigned long align = ntohl(rom->header->align);
unsigned long nextoffset, truncoffset;
unsigned long offset = ROM_OFFSET(rom, file);
/* figure out the real end of this file, and hence the size */
/* compute where the next file is */
nextoffset = ALIGN(offset + ntohl(file->len) + headersize(""), align);
/* compute where the end of this new file might be */
truncoffset = ALIGN(offset + size + headersize(""), align);
/* If there is more than align bytes difference, create a new empty file */
/* later, we can add code to merge all empty files. */
if (nextoffset - truncoffset > align) {
unsigned int csize;
csize = headersize("");
newfile = (struct cbfs_file *)ROM_PTR(rom, truncoffset);
rom_set_header(rom, newfile, "",
nextoffset - truncoffset - csize, CBFS_COMPONENT_NULL);
file->len = htonl(size);
}
return newfile;
}
/**
* rom_alloc_fixed
* Given a rom, walk the headers and find the first header of type
* CBFS_COMPONENT_NULL that is >= the desired size and
* contains the (address, length) desired.
* If the CBFS_COMPONENT_NULL is 'align' bytes > size,
* create a new header of CBFS_COMPONENT_NULL following the file.
* The 'len' structure member of the desired file is initialized, but
* nothing else is.
* Simple algorithm: walk until we find an empty file that contains our area,
* and then allocate out of it.
* @param rom The rom
* @param size the size of the file needed
* @returns pointer to a cbfs_file struct.
*/
struct cbfs_file * rom_alloc_fixed(struct rom *rom, const char *name, unsigned long start, unsigned long size, int type)
{
/* walk the rom and find an empty file with a base > base,
* and a large enough size
*/
unsigned long base, end, alen, baseoff;
unsigned int offset = ntohl(rom->header->offset);
int ret = -1;
struct cbfs_file *c = NULL;
unsigned long align = ntohl(rom->header->align);
/* compute a base that is aligned to align */
base = TRUNCATE(start, align);
/* have to leave room for a header! */
base -= headersize(name);
/* get an offset for that base */
baseoff = base - rom->rombase;
end = ALIGN(start + size, align);
alen = end - base;
while (offset < rom->fssize) {
c = (struct cbfs_file *)ROM_PTR(rom, offset);
if (!strcmp(c->magic, COMPONENT_MAGIC)) {
if (c->type != CBFS_COMPONENT_NULL) {
offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
align);
continue;
}
/* could turn this into a function. */
/* is the start of this file < our desired start? */
if (offset > baseoff)
break;
/* Is this file big enough for our needs? */
if (ntohl(c->len) >= alen){
ret = offset;
break;
}
offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
align);
} else {
fprintf(stderr, "Corrupt rom -- found no header at %d\n", offset);
exit(1);
}
}
if (ret < 0)
return NULL;
/* we have the base offset of our location, and we have the offset for the file we are going to
* split. Split it.
*/
if (baseoff > offset)
c = split(rom, c, baseoff - offset - headersize(""));
/* split off anything left at the end that we don't need */
split(rom, c, size);
c->len = htonl(size);
strcpy(c->magic, COMPONENT_MAGIC);
c->offset = htonl(headersize(name));
c->type = htonl(type);
setname(c, name);
return ((struct cbfs_file *)ROM_PTR(rom, ret));
}
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 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
2009-05-08 21:23:00 +02:00
/**
* rom_alloc
* Given a rom, walk the headers and find the first header of type
* CBFS_COMPONENT_NULL that is >= the desired size.
* If the CBFS_COMPONENT_NULL is 'align' bytes > size,
* create a new header of CBFS_COMPONENT_NULL following the file.
* The 'len' structure member of the desired file is initialized, but
* nothing else is.
* @param rom The rom
* @param size the size of the file needed
* @returns pointer to a cbfs_file struct.
*/
struct cbfs_file * rom_alloc(struct rom *rom, const char *name, unsigned long size, int type)
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 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
2009-05-08 21:23:00 +02:00
{
/* walk the rom and find an empty file with a base > base, and a large enough size */
unsigned int offset = ntohl(rom->header->offset);
int ret = -1;
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 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
2009-05-08 21:23:00 +02:00
struct cbfs_file *c = NULL;
unsigned long nextoffset, truncoffset;
struct cbfs_file *newfile = NULL;
while ((offset + size) < rom->fssize) {
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 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
2009-05-08 21:23:00 +02:00
c = (struct cbfs_file *)ROM_PTR(rom, offset);
if (!strcmp(c->magic, COMPONENT_MAGIC)) {
if (c->type != CBFS_COMPONENT_NULL) {
offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
ntohl(rom->header->align));
continue;
}
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 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
2009-05-08 21:23:00 +02:00
/* Is this file big enough for our needs? */
if (ntohl(c->len) >= size){
ret = offset;
break;
}
offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
ntohl(rom->header->align));
} else {
fprintf(stderr, "Corrupt rom -- found no header at %d\n", offset);
exit(1);
}
}
if (ret < 0)
return NULL;
/* figure out the real end of this file, and hence the size */
/* compute where the next file is */
nextoffset = ALIGN(ret + ntohl(c->len) + headersize(name),
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 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
2009-05-08 21:23:00 +02:00
ntohl(rom->header->align));
/* compute where the end of this new file might be */
truncoffset = ALIGN(ret + size + headersize(name),
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 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
2009-05-08 21:23:00 +02:00
ntohl(rom->header->align));
/* If there is more than align bytes difference, create a new empty file */
/* later, we can add code to merge all empty files. */
if (nextoffset - truncoffset > ntohl(rom->header->align)) {
unsigned int csize;
csize = headersize("");
newfile = (struct cbfs_file *)ROM_PTR(rom, truncoffset);
rom_set_header(rom, newfile, "",
nextoffset - truncoffset - csize, CBFS_COMPONENT_NULL);
} else truncoffset = nextoffset;
c->len = htonl(size);
strcpy(c->magic, COMPONENT_MAGIC);
c->offset = htonl(headersize(name));
c->type = htonl(type);
setname(c, name);
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 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
2009-05-08 21:23:00 +02:00
return ((struct cbfs_file *)ROM_PTR(rom, ret));
}
struct cbfs_file *rom_find(struct rom *rom, int offset)
{
while (offset < rom->fssize) {
struct cbfs_file *c =
(struct cbfs_file *)ROM_PTR(rom, offset);
if (!strcmp(c->magic, COMPONENT_MAGIC))
return c;
offset += ntohl(rom->header->align);
}
return NULL;
}
struct cbfs_file *rom_find_first(struct rom *rom)
{
return rom_find(rom, ntohl(rom->header->offset));
}
struct cbfs_file *rom_find_next(struct rom *rom, struct cbfs_file *prev)
{
unsigned int offset = ROM_OFFSET(rom, prev);
return rom_find(rom, offset +
ALIGN(ntohl(prev->offset) + ntohl(prev->len),
ntohl(rom->header->align)));
}
struct cbfs_file *rom_find_empty(struct rom *rom)
{
unsigned int offset = ntohl(rom->header->offset);
unsigned int ret = ntohl(rom->header->offset);
while (offset < rom->fssize) {
struct cbfs_file *c =
(struct cbfs_file *)ROM_PTR(rom, offset);
if (!strcmp(c->magic, COMPONENT_MAGIC)) {
offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
ntohl(rom->header->align));
ret = offset;
} else
offset += ntohl(rom->header->align);
}
return (ret < rom->fssize) ?
(struct cbfs_file *)ROM_PTR(rom, ret) : NULL;
}
struct cbfs_file *rom_find_by_name(struct rom *rom, const char *name)
{
struct cbfs_file *c = rom_find_first(rom);
while (c) {
if (!strcmp((char *)CBFS_NAME(c), name))
return c;
c = rom_find_next(rom, c);
}
return NULL;
}
int rom_used_space(struct rom *rom)
{
struct cbfs_file *c = rom_find_first(rom);
unsigned int ret = 0;
while (c) {
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 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
2009-05-08 21:23:00 +02:00
int type;
type = ntohl(c->type);
if ((c->type == CBFS_COMPONENT_DELETED) ||
(c->type == CBFS_COMPONENT_NULL))
continue;
ret += ROM_OFFSET(rom, c) + ntohl(c->offset) + ntohl(c->len);
c = rom_find_next(rom, c);
}
return ret;
}
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 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
2009-05-08 21:23:00 +02:00
/**
* delete an item. This is a flash-friendly version -- it just blows the
* type to 0. Nothing else is changed.
* N.B. We no longer shuffle contents of ROM. That will come later.
* @param rom The rom
* @param name Name of file to remove.
* @return -1 on error, 0 if a file was set to deleted.
*/
int rom_remove(struct rom *rom, const char *name)
{
struct cbfs_file *c = rom_find_by_name(rom, name);
if (c == NULL) {
ERROR("Component %s does not exist\n", name);
return -1;
}
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 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
2009-05-08 21:23:00 +02:00
c->type = CBFS_COMPONENT_DELETED;
void *n = rom_find_next(rom, c);
int clear;
if (n != NULL) {
memcpy(c, n, rom->fssize - ROM_OFFSET(rom, n));
clear = ROM_OFFSET(rom, n) - ROM_OFFSET(rom, c);
}
else { /* No component after this one. */
unsigned int csize;
csize = sizeof(struct cbfs_file) + ALIGN(strlen(name) + 1, 16);
clear = ntohl(c->len) + csize;
memcpy(c, ((void*)c) + clear,
rom->fssize - (ROM_OFFSET(rom, c)+clear));
}
/* Zero the new space, which is always at the end. */
memset(ROM_PTR(rom, rom->fssize - clear), 0, clear);
return 0;
}
int rom_extract(struct rom *rom, const char *name, void** buf, int *size )
{
struct cbfs_file *c = rom_find_by_name(rom, name);
if (c == NULL) {
ERROR("Component %s does not exist\n", name);
return -1;
}
*size = ntohl(c->len);
*buf = ((unsigned char *)c) + headersize(name);
return 0;
}
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 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
2009-05-08 21:23:00 +02:00
/**
* Add a new file named 'name', of type 'type', size 'size'. Initialize that file
* with the contents of 'buffer'.
* @param rom The rom
* @param name file name
* @param buffer file data
This is transition code for cbfs to implement cbfs files at fixed addresses. I call this transitional as the approach I am taking is to add capability to cbfstool but not change code in a way that will break existing usages. Later, once we're sure nothing has broken, we can start to smooth the edges. Right now, fixed address file are only supported via the add command. There is one additional command syntax, so, example: cbfstool add rom romstrap optionrom 0xffffd000 Will add the file to that fix location for a romstrap. The assumption is that the ROM is based at the end of a 32-bit address space. As you can see from the code, that assumption can easily be over-ridden, if we ever need to, with a command option. Here is one example output result. rminnich@xcpu2:~/src/bios/coreboot-v2/util/cbfstool$ ./cbfstool x.cbf print x.cbf: 1024 kB, bootblocksize 32768, romsize 1048576, offset 0x0 Alignment: 16 bytes Name Offset Type Size h 0x0 optionrom 251 0x130 free 917120 h3 0xdffe0 optionrom 251 0xe0110 free 97960 The way this is implemented is pretty simple. I introduce a new operator, split, that splits an unallocated area into two unallocated areas. Then, allocation merely becomes a matter of 0, 1, or 2 splits: 0 split -- the free area is the exact fit 1 splits -- need to split some off the front or back 2 splits -- need to split off BOTH the front and back I think you'll be able to see what I've done. I call this transitional because, in the end state, we only need one allocate function; for now I've left two in, to make sure I don't break compatibilty. Why I like this better than ldscript approach: I like having the ROMSTRAP located by cbfs, not linker scripts. For one thing, it makes romstrap visible as a first class object. I think I would have latched onto a problem I was having much more quickly had I remembered the ROMSTRAP. It gets lost in the linker scripts. At this point, we should be able to start removing special ROMSTRAP location code from linker scripts. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-06-08 05:33:57 +02:00
* @param address base address. 0 means 'whereever it fits'
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 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
2009-05-08 21:23:00 +02:00
* @param size Amount of data
* @param type File type
* @returns -1 on failure, 0 on success
*/
This is transition code for cbfs to implement cbfs files at fixed addresses. I call this transitional as the approach I am taking is to add capability to cbfstool but not change code in a way that will break existing usages. Later, once we're sure nothing has broken, we can start to smooth the edges. Right now, fixed address file are only supported via the add command. There is one additional command syntax, so, example: cbfstool add rom romstrap optionrom 0xffffd000 Will add the file to that fix location for a romstrap. The assumption is that the ROM is based at the end of a 32-bit address space. As you can see from the code, that assumption can easily be over-ridden, if we ever need to, with a command option. Here is one example output result. rminnich@xcpu2:~/src/bios/coreboot-v2/util/cbfstool$ ./cbfstool x.cbf print x.cbf: 1024 kB, bootblocksize 32768, romsize 1048576, offset 0x0 Alignment: 16 bytes Name Offset Type Size h 0x0 optionrom 251 0x130 free 917120 h3 0xdffe0 optionrom 251 0xe0110 free 97960 The way this is implemented is pretty simple. I introduce a new operator, split, that splits an unallocated area into two unallocated areas. Then, allocation merely becomes a matter of 0, 1, or 2 splits: 0 split -- the free area is the exact fit 1 splits -- need to split some off the front or back 2 splits -- need to split off BOTH the front and back I think you'll be able to see what I've done. I call this transitional because, in the end state, we only need one allocate function; for now I've left two in, to make sure I don't break compatibilty. Why I like this better than ldscript approach: I like having the ROMSTRAP located by cbfs, not linker scripts. For one thing, it makes romstrap visible as a first class object. I think I would have latched onto a problem I was having much more quickly had I remembered the ROMSTRAP. It gets lost in the linker scripts. At this point, we should be able to start removing special ROMSTRAP location code from linker scripts. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-06-08 05:33:57 +02:00
int rom_add(struct rom *rom, const char *name, void *buffer, unsigned long address, int size, int type)
{
struct cbfs_file *c;
int csize;
if (rom_find_by_name(rom, name)) {
ERROR("Component %s already exists in this rom\n", name);
return -1;
}
This is transition code for cbfs to implement cbfs files at fixed addresses. I call this transitional as the approach I am taking is to add capability to cbfstool but not change code in a way that will break existing usages. Later, once we're sure nothing has broken, we can start to smooth the edges. Right now, fixed address file are only supported via the add command. There is one additional command syntax, so, example: cbfstool add rom romstrap optionrom 0xffffd000 Will add the file to that fix location for a romstrap. The assumption is that the ROM is based at the end of a 32-bit address space. As you can see from the code, that assumption can easily be over-ridden, if we ever need to, with a command option. Here is one example output result. rminnich@xcpu2:~/src/bios/coreboot-v2/util/cbfstool$ ./cbfstool x.cbf print x.cbf: 1024 kB, bootblocksize 32768, romsize 1048576, offset 0x0 Alignment: 16 bytes Name Offset Type Size h 0x0 optionrom 251 0x130 free 917120 h3 0xdffe0 optionrom 251 0xe0110 free 97960 The way this is implemented is pretty simple. I introduce a new operator, split, that splits an unallocated area into two unallocated areas. Then, allocation merely becomes a matter of 0, 1, or 2 splits: 0 split -- the free area is the exact fit 1 splits -- need to split some off the front or back 2 splits -- need to split off BOTH the front and back I think you'll be able to see what I've done. I call this transitional because, in the end state, we only need one allocate function; for now I've left two in, to make sure I don't break compatibilty. Why I like this better than ldscript approach: I like having the ROMSTRAP located by cbfs, not linker scripts. For one thing, it makes romstrap visible as a first class object. I think I would have latched onto a problem I was having much more quickly had I remembered the ROMSTRAP. It gets lost in the linker scripts. At this point, we should be able to start removing special ROMSTRAP location code from linker scripts. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-06-08 05:33:57 +02:00
if (address)
c = rom_alloc_fixed(rom, name, address, size, type);
else
c = rom_alloc(rom, name, size, type);
if (c == NULL) {
ERROR("There is not enough room in this ROM\n");
return -1;
}
csize = sizeof(struct cbfs_file) + ALIGN(strlen(name) + 1, 16);
int offset = ROM_OFFSET(rom, c);
if (offset + csize + size > rom->fssize) {
ERROR("There is not enough room in this ROM for this\n");
ERROR("component. I need %d bytes, only have %d bytes avail\n",
csize + size, rom->fssize - offset);
return -1;
}
strcpy(c->magic, COMPONENT_MAGIC);
c->len = htonl(size);
c->offset = htonl(csize);
c->type = htonl(type);
memset(CBFS_NAME(c), 0, ALIGN(strlen(name) + 1, 16));
strcpy((char *)CBFS_NAME(c), name);
memcpy(((unsigned char *)c) + csize, buffer, size);
return 0;
}
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 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
2009-05-08 21:23:00 +02:00