out a suitable address to put a XIP stage to.
Specifically, you pass it the file (to get its filesize), its filename
(as the header has a variable length that depends on it), and the
granularity requirement it has to fit in (for XIP).
The granularity is MTRR-style: when you request 0x10000, cbfstool looks
for a suitable place in a 64kb-aligned 64kb block.
cbfstool simply prints out a hex value which is the start address of a
suitably located free memory block. That value can then be used with
cbfs add-stage to store the file in the ROM image.
It's a two-step operation (instead of being merged into cbfs add-stage)
because the image must be linked twice: First, with some bogus, but safe
base address (eg. 0) to figure out the target address (based on file
size). Then a second time at the target address.
The work flow is:
- link file
- cbfstool locate
- link file again
- cbfstool add-stage.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4929 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
0da38dde4b