summaryrefslogtreecommitdiff
path: root/util/cbfstool/common.h
AgeCommit message (Collapse)Author
2013-02-05cbfstool: Add buffer management API.Hung-Te Lin
Many functions in cbfstool need to deal with a memory buffer - both location and size. Right now it's made by different ways: for ROM image using global variable (romsize, master_header); and in cbfs-* using return value for size and char** to return memory location. This may cause bugs like assuming incorrect return types, ex: uint32_t file_size = parse(); // which returns "-1" on error if (file_size <= 0) { ... And the parse error will never be caught. We can simplify this by introducing a buffer API, to change unsigned int do_something(char *input, size_t len, char **output, ...) into int do_something(struct buffer *input, struct buffer *output, ...) The buffer API will be used by further commits. Change-Id: Iaddaeb109f08be6be84c6728d72c6a043b0e7a9f Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2205 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-01cbfstool: Make endian detection functions to work without prior setup.Hung-Te Lin
The 'host_bigendian' variable (and functions relying on it like ntohl/htonl) requires host detection by calling static which_endian() first -- which may be easily forgotten by developers. It's now a public function in common.c and doesn't need initialization anymore. Change-Id: I13dabd1ad15d2d6657137d29138e0878040cb205 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2199 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-02-01cbfstool: move flat-binary parsing to cbfs-mkpayload.Hung-Te Lin
The ELF parsing and payload building in add-flat-binary command should be isolated just like mkpayload and mkstage. Since the add-flat-binary command creates a payload in the end , move payload processing to cbfs-mkpayload.c. To test: cbfstool coreboot.rom add-flat-binary -f u-boot.bin -n fallback/payload \ -l 0x100000 -e 0x100020 To verify, get output from "cbfstool coreboot.rom print -v": fallback/payload 0x73ccc0 payload 124920 INFO: code (no compression, offset: 0x38, load: 0x1110000, length:..) Change-Id: Ia7bd2e6160507c0a1e8e20bc1d08397ce9826e0d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2197 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-01cbfstool: Add -v (verbose) output.Hung-Te Lin
Add -v (verbose) to every command, and allow printing debug messages. Revise logging and debugging functions (fprintf(stderr,...), dprintf...) and verbose message printing with following macros: ERROR(xxx): E: xxx WARN(xxx) W: xxx LOG(xxx) xxx INFO(...) INFO: xxx (only when runs with -v ) DEBUG(...) DEBUG: xxx (only when runs with more than one -v) Example: cbfstool coreboot.rom print -v cbfstool coreboot.rom add -f file -n file -t raw -v -v Normal output (especially for parsing) should use printf, not any of these macros (see usage() and cbfs_locate(), cbfs_print_directory() for example). Change-Id: I167617da1a6eea2b07075b0eb38e3c9d85ea75dc Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2196 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-01-04cbfstool: Fix warnings on OS XStefan Reinauer
Most hton and noth functions are already available through the system headers we include on OS X, causing the compiler to warn about duplicate definitions. Change-Id: Id81852dfc028cf0c48155048c54d431436889c0e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2106 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2012-11-30Add multi-architecture support to cbfstoolDavid Hendricks
This is an initial re-factoring of CBFS code to enable multiple architectures. To achieve a clean solution, an additional field describing the architecture has to be added to the master header. Hence we also increase the version number in the master header. Change-Id: Icda681673221f8c27efbc46f16c2c5682b16a265 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/1944 Tested-by: build bot (Jenkins)
2012-11-12cbfstool: Rework to use getopt style parametersStefan Reinauer
- Adding more and more optional and non-optional parameters bloated cbfstool and made the code hard to read with a lot of parsing in the actual cbfs handling functions. This change switches over to use getopt style options for everything but command and cbfs file name. - This allows us to simplify the coreboot Makefiles a bit - Also, add guards to include files - Fix some 80+ character lines - Add more detailed error reporting - Free memory we're allocating Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7 Reviewed-on: http://review.coreboot.org/1800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-08cbfstool: add offset parameter to create commandStefan Reinauer
CBFS allows coreboot rom images that are only partially covered by the filesystem itself. The intention of this feature was to allow EC / ME / IMC firmware to be inserted easily at the beginning of the image. However, this was never implemented in cbfstool. This patch implements an additional parameter for cbfstool. If you call cbfstool like this: cbfstool coreboot.rom create 8192K bootblock.bin 64 0x700000 it will now create an 8M image with CBFS covering the last 1M of that image. Test: cbfstool coreboot.rom create 8192K bootblock.bin 64 0x700000 creates an 8M image that is 7M of 0xff and 1M of CBFS. Change-Id: I5c016b4bf32433f160b43f4df2dd768276f4c70b Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1708 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-18cbfstool: provide a prototype for remove_file_from_cbfsMathias Krause
To complement commit e1bb49e (Add a "remove" command to cbfstool) and fix a compiler warning provide a prototype for remove_file_from_cbfs. Change-Id: Ied8eac956de5fed3f9d82ce1e911ee1fec52db15 Signed-off-by: Mathias Krause <minipli@googlemail.com> Reviewed-on: http://review.coreboot.org/1235 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2011-10-24Various fixes to cbfstool.Stefan Reinauer
- add ntohll and htonll (as coreboot parses 64bit fields now) - use the same byte swapping code across platforms - detect endianess early - fix lots of warnings - Don't override CFLAGS in Makefile Change-Id: Iaea02ff7a31ab6a95fd47858d0efd9af764a3e5f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/313 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-01-13Add "cbfstool extract" function.Aurelien Guillaume
It dumps everything you ask for, but you might not get what you expect if the file is compressed or otherwise converted (eg. payloads in SELF format). (Originally it would only extract "raw" files. This is a change by me, as filetypes are commonly used to differentiate raw data files --Patrick) Signed-off-by: Aurelien Guillaume <aurelien@iwi.me> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Patrick Georgi <patrick.georgi@secunet.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6250 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-06-24fix return value checks of cbfstool's writeromStefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5644 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-24print the known cbfs types in cbfstool "usage"Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5487 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
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