2009-03-31 13:57:36 +02:00
|
|
|
/*
|
2009-04-14 02:08:34 +02:00
|
|
|
* cbfstool
|
2009-03-31 13:57:36 +02:00
|
|
|
*
|
|
|
|
|
* 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
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _ROMTOOL_H_
|
|
|
|
|
#define _ROMTOOL_H_
|
|
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <arpa/inet.h>
|
2009-04-14 02:08:34 +02:00
|
|
|
#include "cbfs.h"
|
2009-03-31 13:57:36 +02:00
|
|
|
|
|
|
|
|
/* Definitions */
|
|
|
|
|
|
|
|
|
|
/* Structures */
|
|
|
|
|
|
|
|
|
|
struct rom {
|
|
|
|
|
unsigned char *name;
|
|
|
|
|
unsigned char *ptr;
|
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
|
|
|
/* this will *almost* *always* be 0-rom->size, save for some really
|
|
|
|
|
* misdesigned systems (which have existed)
|
|
|
|
|
*/
|
|
|
|
|
unsigned long rombase;
|
2009-03-31 13:57:36 +02:00
|
|
|
|
|
|
|
|
int fd;
|
|
|
|
|
int size;
|
|
|
|
|
int fssize;
|
|
|
|
|
|
2009-04-14 02:08:34 +02:00
|
|
|
struct cbfs_header *header;
|
2009-03-31 13:57:36 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Macros */
|
|
|
|
|
|
|
|
|
|
#define ROM_OFFSET(_r, _c) ((unsigned int) ((unsigned char *) (_c) - (_r)->ptr))
|
|
|
|
|
|
|
|
|
|
#define ROM_PTR(_r, _o) ((_r)->ptr + (_o))
|
|
|
|
|
#define ROM_WRITEL(_r, _o, _v) do { *((unsigned int *) ROM_PTR((_r), (_o))) = (_v); } while(0)
|
|
|
|
|
#define ROM_READL(_r, _o) *((unsigned int *) (ROM_PTR((_r), (_o))))
|
|
|
|
|
|
2009-04-14 02:08:34 +02:00
|
|
|
#define ERROR(err, args...) fprintf(stderr, "(cbfstool) E: " err, ##args)
|
|
|
|
|
#define WARN(err, args...) fprintf(stderr, "(cbfstool) W: " err, ##args)
|
2009-03-31 13:57:36 +02:00
|
|
|
#define VERBOSE(str, args...) printf(str, ##args)
|
|
|
|
|
|
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
|
|
|
#define TRUNCATE(_v, _a) ( (_v) & ~( (_a) - 1 ) )
|
2009-03-31 13:57:36 +02:00
|
|
|
#define ALIGN(_v, _a) ( ( (_v) + ( (_a) - 1 ) ) & ~( (_a) - 1 ) )
|
|
|
|
|
|
|
|
|
|
/* Function prototypes */
|
|
|
|
|
|
|
|
|
|
/* util.c */
|
2009-05-17 01:05:20 +02:00
|
|
|
void flashinit(void *ptr, size_t len);
|
2009-03-31 13:57:36 +02:00
|
|
|
int open_rom(struct rom *rom, const char *filename);
|
|
|
|
|
int create_rom(struct rom *rom, const unsigned char *filename, int size,
|
2009-05-01 00:45:41 +02:00
|
|
|
const char *bootblockname, int bootblocksize,
|
2009-04-25 14:39:04 +02:00
|
|
|
int align);
|
2009-03-31 13:57:36 +02:00
|
|
|
int size_and_open(const char *filename, unsigned int *size);
|
|
|
|
|
int copy_from_fd(int fd, void *ptr, int size);
|
|
|
|
|
int get_size(const char *size);
|
|
|
|
|
int add_bootblock(struct rom *rom, const char *filename);
|
|
|
|
|
|
|
|
|
|
/* fs.c */
|
|
|
|
|
|
2009-05-08 21:39:15 +02:00
|
|
|
struct cbfs_file *rom_find(struct rom *rom, int offset);
|
2009-04-14 02:08:34 +02:00
|
|
|
struct cbfs_file *rom_find_first(struct rom *);
|
|
|
|
|
struct cbfs_file *rom_find_next(struct rom *, struct cbfs_file *);
|
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 *, unsigned long address, int 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
|
|
|
int rom_set_header(struct rom *rom, struct cbfs_file *c,
|
|
|
|
|
const char*name, int size, int type);
|
2009-05-08 21:39:15 +02:00
|
|
|
int rom_extract(struct rom *rom, const char *name, void **buf, int *size);
|
2009-03-31 13:57:36 +02:00
|
|
|
int rom_remove(struct rom *rom, const char *name);
|
2009-05-08 21:39:15 +02:00
|
|
|
int rom_used_space(struct rom *rom);
|
2009-03-31 13:57:36 +02:00
|
|
|
int rom_exists(struct rom *rom);
|
|
|
|
|
|
|
|
|
|
#endif
|