summaryrefslogtreecommitdiff
path: root/util/cbfstool/util.c
diff options
context:
space:
mode:
authorRonald G. Minnich <rminnich@gmail.com>2009-06-08 03:33:57 +0000
committerRonald G. Minnich <rminnich@gmail.com>2009-06-08 03:33:57 +0000
commit6ce41c06ccdf1c80600ef4cf8e140f928b09d754 (patch)
treef80df8e3ebddadf14070382474fabcd494561ed2 /util/cbfstool/util.c
parentd64f403f8eeb2da55472d9f6f65b657c063414ed (diff)
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
Diffstat (limited to 'util/cbfstool/util.c')
-rw-r--r--util/cbfstool/util.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/util/cbfstool/util.c b/util/cbfstool/util.c
index f77b74634b..e1da4cb6fc 100644
--- a/util/cbfstool/util.c
+++ b/util/cbfstool/util.c
@@ -158,6 +158,11 @@ int open_rom(struct rom *rom, const char *filename)
}
rom->size = ntohl(rom->header->romsize);
+ /* compute a 32-bit value of rombase.
+ * This does the right thing on 64-bit machines.
+ */
+ rom->rombase = 0-rom->size;
+ rom->rombase &= 0xffffffff;
rom->fssize = rom->size - ntohl(rom->header->bootblocksize);
return 0;