Commit Graph

54 Commits

Author SHA1 Message Date
Patrick Georgi 26774f2b72 Make the kconfig-style build work in mingw:
* 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-21 19:54:02 +00:00
Patrick Georgi 0da38dde4b Add a "locate" function cbfstool, which helps you find
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-11-09 17:18:02 +00:00
Stefan Reinauer 853270af39 * guard all mallocs in cbfstool
* 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-22 15:55:01 +00:00
Patrick Georgi b7b56dd8fb New cbfstool. Works without mmap or fork/exec and
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
2009-09-14 13:29:27 +00:00