[coreboot] Fwd: fixed-location entities in cbfs.

ron minnich rminnich at gmail.com
Thu Jun 4 21:52:12 CEST 2009

weird. That's the second time google has dropped an attachment on the
floor for me ...


---------- Forwarded message ----------
From: ron minnich <rminnich at gmail.com>
Date: Thu, Jun 4, 2009 at 12:29 PM
Subject: fixed-location entities in cbfs.
To: coreboot <coreboot at coreboot.org>

Attached are what I view as a transition plan 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.

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 at 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.

Anywhere, here it is.This will allow us to remove a lot of ldscript trickiness.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixed.diff
Type: text/x-patch
Size: 8757 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090604/86e241ee/attachment.diff>

More information about the coreboot mailing list