0da38dde4b
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 |
||
---|---|---|
.. | ||
abuild | ||
amdtools | ||
analysis | ||
cbfstool | ||
compareboard | ||
crossgcc | ||
dump_mmcr | ||
ectool | ||
getpir | ||
inteltool | ||
k8resdump | ||
kbuildall | ||
kconfig | ||
lbtdump | ||
mkelfImage | ||
mptable | ||
msrtool | ||
newconfig | ||
nrv2b | ||
nvramtool | ||
optionlist | ||
options | ||
resetcf | ||
romcc | ||
sconfig | ||
superiotool | ||
vgabios | ||
x86emu | ||
xcompile |