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@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.
ron
weird. That's the second time google has dropped an attachment on the floor for me ...
ron
---------- Forwarded message ---------- From: ron minnich rminnich@gmail.com Date: Thu, Jun 4, 2009 at 12:29 PM Subject: fixed-location entities in cbfs. To: coreboot coreboot@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@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.
ron
Am 04.06.2009 21:52, schrieb ron minnich:
Anywhere, here it is.This will allow us to remove a lot of ldscript trickiness.
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
On Sun, Jun 7, 2009 at 7:45 AM, Patrick Georgipatrick@georgi-clan.de wrote:
Am 04.06.2009 21:52, schrieb ron minnich:
Anywhere, here it is.This will allow us to remove a lot of ldscript trickiness.
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
Committed revision 4351.
-
Patrick Georgi -
ron minnich