summaryrefslogtreecommitdiff
path: root/util/cbfstool/common.h
AgeCommit message (Collapse)Author
2009-11-21Make the kconfig-style build work in mingw:Patrick Georgi
* use relative paths in ldscript.ld and crt0_includes.h * avoid use of dd(1) in xcompile * build libregex for kconfig, if necessary * work around missing utsname on win32 * unlink targets before rename on win32 * implement (crude) mkstemp for win32 * avoid open/read/close, use fopen/fread/fclose instead * don't free certain data structures in romcc on win32 to avoid crashes (likely use-after-free()) * handle "\CRLF" and win32 style absolute paths (X:/ or X:\) in romcc * make lzma (part of cbfstool) build on XP * implement ntohl/htonl on win32 * handle CRLF in awk script * set larger stack for romcc on win32 Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4952 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-11-09Add a "locate" function cbfstool, which helps you findPatrick Georgi
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
2009-09-22* guard all mallocs in cbfstoolStefan Reinauer
* fix an issue that could lead to cbfstool writing outside of its allocated memory Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4653 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-09-14New cbfstool. Works without mmap or fork/exec andPatrick Georgi
supports fixed location files. Some parts are salvaged from the pre-commit version (esp. stage and payload creation), others are completely rewritten (eg. the main loop that handles file addition) Also adapt newconfig (we don't need cbfs/tools anymore) and fix some minor issues in the cbfstool-README. 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@4630 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1