summaryrefslogtreecommitdiff
path: root/util/cbfstool/common.h
AgeCommit message (Collapse)Author
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-13cbfstool: Don't typedef the comp_algo enumSol Boucher
Our style discourages unnecessary typedefs, and this one doesn't gain us anything, nor is it consistent with the surrounding code: there's a function pointer typedef'd nearby, but non-opaque structs aren't. BUG=chromium:482652 TEST=None BRANCH=None Change-Id: Ie7565240639e5b1aeebb08ea005099aaa3557a27 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Change-Id: I4285e6b56f99b85b9684f2b98b35e9b35a6c4cb7 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Reviewed-on: http://review.coreboot.org/10146 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-13cbfstool: Support top-aligned addresses for new-format imagesSol Boucher
The cbfstool handling of new-style FMAP-driven "partitioned" images originally disallowed the use of x86-style top-aligned addresses with the add.* and layout actions because it wasn't obvious how they should work, especially since the normal addressing is done relative to each individual region for these types of images. Not surprisingly, however, the x86 portions of the build system make copious use of top-aligned addresses, so this allows their use with new images and specifies their behavior as being relative to the *image* end---not the region end---just as it is for legacy images. Change-Id: Icecc843f4f8b6bb52aa0ea16df771faa278228d2 Signed-off-by: Sol Boucher <solb@chromium.org> Reviewed-on: http://review.coreboot.org/10136 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-13cbfstool: New image format w/ required FMAP and w/o CBFS master headerSol Boucher
These new-style firmware images use the FMAP of the root of knowledge about their layout, which allows them to have sections containing raw data whose offset and size can easily be determined at runtime or when modifying or flashing the image. Furthermore, they can even have multiple CBFSes, each of which occupies a different FMAP region. It is assumed that the first entry of each CBFS, including the primary one, will be located right at the start of its region. This means that the bootblock needs to be moved into its own FMAP region, but makes the CBFS master header obsolete because, with the exception of the version and alignment, all its fields are redundant once its CBFS has an entry in the FMAP. The version code will be addressed in a future commit before the new format comes into use, while the alignment will just be defined to 64 bytes in both cbfstool and coreboot itself, since there's almost no reason to ever change it in practice. The version code field and all necessary coreboot changes will come separately. BUG=chromium:470407 TEST=Build panther and nyan_big coreboot.rom and image.bin images with and without this patch, diff their hexdumps, and note that no locations differ except for those that do between subsequent builds of the same codebase. Try working with new-style images: use fmaptool to produce an FMAP section from an fmd file having raw sections and multiple CBFSes, pass the resulting file to cbfstool create -M -F, then try printing its layout and CBFSes' contents, add and remove CBFS files, and read and write raw sections. BRANCH=None Change-Id: I7dd2578d2143d0cedd652fdba5b22221fcc2184a Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 8a670322297f83135b929a5b20ff2bd0e7d2abd3 Original-Change-Id: Ib86fb50edc66632f4e6f717909bbe4efb6c874e5 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/265863 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10135 Tested-by: build bot (Jenkins)
2015-05-08cbfstool: Restructure around support for reading/writing portions of filesSol Boucher
The buffer API that cbfstool uses to read and write files only directly supports one-shot operations on whole files. This adds an intermediate partitioned_file module that sits on top of the buffer system and has an awareness of FMAP entries. It provides an easy way to get a buffer for an individual region of a larger image file based on FMAP section name, as well as incrementally write those smaller buffers back to the backing file at the appropriate offset. The module has two distinct modes of operation: - For new images whose layout is described exclusively by an FMAP section, all the aforementioned functionality will be available. - For images in the current format, where the CBFS master header serves as the root of knowledge of the image's size and layout, the module falls back to a legacy operation mode, where it only allows manipulation of the entire image as one unit, but exposes this support through the same interface by mapping the region named SECTION_NAME_PRIMARY_CBFS ("COREBOOT") to the whole file. The tool is presently only ported onto the new module running in legacy mode: higher-level support for true "partitioned" images will be forthcoming. However, as part of this change, the crusty cbfs_image_from_file() and cbfs_image_write_file() abstractions are removed and replaced with a single cbfs_image function, cbfs_image_from_buffer(), as well as centralized image reading/writing directly in cbfstool's main() function. This reduces the boilerplate required to implement each new action, makes the create action much more similar to the others, and will make implementing additional actions and adding in support for the new format much easier. BUG=chromium:470407 TEST=Build panther and nyan_big coreboot.rom images with and without this patch and diff their hexdumps. Ensure that no differences occur at different locations from the diffs between subsequent builds of an identical source tree. Then flash a full new build onto nyan_big and watch it boot normally. BRANCH=None Change-Id: I25578c7b223bc8434c3074cb0dd8894534f8c500 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 7e1c96a48e7a27fc6b90289d35e6e169d5e7ad20 Original-Change-Id: Ia4a1a4c48df42b9ec2d6b9471b3a10eb7b24bb39 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/265581 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10134 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08cbfstool: Add offset field to cbfstool directory's struct bufferSol Boucher
This allows calls to buffer_delete() to work on a buffer that has been buffer_seek()ed or the buffer created by a buffer_splice(). The same information could also be useful for other purposes, such as writing slices back to a file at the offset they originally occupied. BUG=chromium:470407 TEST=Attempt to perform the following sequence of buffer actions, then run it through valgrind to check for memory errors: for (int pos = 0; pos <= 3; ++pos) { struct buffer seek_test; buffer_create(&seek_test, 3, "seek_test"); if (pos == 0) { buffer_delete(&seek_test); continue; } buffer_seek(&seek_test, 1); if (pos == 1) { buffer_delete(&seek_test); continue; } buffer_seek(&seek_test, 1); if (pos == 2) { buffer_delete(&seek_test); continue; } buffer_seek(&seek_test, 1); if (pos == 3) { buffer_delete(&seek_test); continue; } } for (int pos = 0; pos <= 14; ++pos) { struct buffer slice_test; buffer_create(&slice_test, 3, "slice_test"); if (pos == 0) { buffer_delete(&slice_test); continue; } struct buffer sliced_once; buffer_splice(&sliced_once, &slice_test, 1, 2); if (pos == 1) { buffer_delete(&slice_test); continue; } if (pos == 2) { buffer_delete(&sliced_once); continue; } struct buffer sliced_twice; buffer_splice(&sliced_twice, &sliced_once, 2, 1); if (pos == 3) { buffer_delete(&slice_test); continue; } if (pos == 4) { buffer_delete(&sliced_once); continue; } if (pos == 5) { buffer_delete(&sliced_twice); continue; } struct buffer sliced_same; buffer_splice(&sliced_same, &slice_test, 1, 1); if (pos == 6) { buffer_delete(&slice_test); continue; } if (pos == 7) { buffer_delete(&sliced_once); continue; } if (pos == 8) { buffer_delete(&sliced_twice); continue; } if (pos == 9) { buffer_delete(&sliced_same); continue; } struct buffer sliced_thrice; buffer_splice(&sliced_thrice, &sliced_twice, 1, 0); if (pos == 10) { buffer_delete(&slice_test); continue; } if (pos == 11) { buffer_delete(&sliced_once); continue; } if (pos == 12) { buffer_delete(&sliced_twice); continue; } if (pos == 13) { buffer_delete(&sliced_same); continue; } if (pos == 14) { buffer_delete(&sliced_thrice); continue; } } BRANCH=None Change-Id: Id67734654a62302c0de37746d8a978d49b240505 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 00c40982a21a91a488587dd3cead7109f3a30d98 Original-Change-Id: Ie99839d36500d3270e4924a3477e076a6d27ffc8 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/267467 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10133 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08cbfstool: Simplify the common buffer_splice() function's interfaceSol Boucher
Previously, this function allowed one to pass a size of 0 in order to indicate that the entire buffer should be copied. However, the semantics of calling it this way were non-obvious: The desired behavior was clear when the offset was also 0, but what was the expected outcome when the offset was nonzero, since carrying over the original size in this case would be an error? In fact, it turns out that it always ignored the provided offset when the size was zero. This commit eliminates all special handling of 0; thus, the resulting buffer is exactly as large as requested, even if it's degenerate. Since the only consumer that actually called the function with a size of 0 was buffer_clone(), no other files required changes. Change-Id: I1baa5dbaa7ba5bd746e8b1e08816335183bd5d2d Signed-off-by: Sol Boucher <solb@chromium.org> Reviewed-on: http://review.coreboot.org/10132 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08fmaptool: Introduce the fmd ("flashmap descriptor") language and compilerSol Boucher
This adds a compiler for a language whose textual representation of flashmap regions will be used to describe the layout of flash chips that contain more than just a single CBFS. Direct integration with cbfstool (via a new command-line switch for the create action) is forthcoming but will be added separately. BUG=chromium:461875 TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for panther. Using the latter file as a reference, write a corresponding fmap.fmd file and feed it through fmaptool. Run both binary output files though the flashmap project's own flashmap_decode utility. Observe only the expected differences. BRANCH=None Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142 Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255031 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9942 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-25cbfstool: Clean up in preparation for adding new filesSol Boucher
This enables more warnings on the cbfstool codebase and fixes the issues that surface as a result. A memory leak that used to occur when compressing files with lzma is also found and fixed. Finally, there are several fixes for the Makefile: - Its autodependencies used to be broken because the target for the .dependencies file was misnamed; this meant that Make didn't know how to rebuild the file, and so would silently skip the step of updating it before including it. - The ability to build to a custom output directory by defining the obj variable had bitrotted. - The default value of the obj variable was causing implicit rules not to apply when specifying a file as a target without providing a custom value for obj. - Add a distclean target for removing the .dependencies file. BUG=chromium:461875 TEST=Build an image with cbfstool both before and after. BRANCH=None Change-Id: I951919d63443f2b053c2e67c1ac9872abc0a43ca Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 49293443b4e565ca48d284e9a66f80c9c213975d Original-Change-Id: Ia7350c2c3306905984cfa711d5fc4631f0b43d5b Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/257340 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9937 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-14CBFS: Automate ROM image layout and remove hardcoded offsetsJulius Werner
Non-x86 boards currently need to hardcode the position of their CBFS master header in a Kconfig. This is very brittle because it is usually put in between the bootblock and the first CBFS entry, without any checks to guarantee that it won't overlap either of those. It is not fun to debug random failures that move and disappear with tiny alignment changes because someone decided to write "ORBC1112" over some part of your data section (in a way that is not visible in the symbolized .elf binaries, only in the final image). This patch seeks to prevent those issues and reduce the need for manual configuration by making the image layout a completely automated part of cbfstool. Since automated placement of the CBFS header means we can no longer hardcode its position into coreboot, this patch takes the existing x86 solution of placing a pointer to the header at the very end of the CBFS-managed section of the ROM and generalizes it to all architectures. This is now even possible with the read-only/read-write split in ChromeOS, since coreboot knows how large that section is from the CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be changed on systems that place other data next to coreboot/CBFS in ROM). Also adds a feature to cbfstool that makes the -B (bootblock file name) argument on image creation optional, since we have recently found valid use cases for CBFS images that are not the first boot medium of the device (instead opened by an earlier bootloader that can already interpret CBFS) and therefore don't really need a bootblock. BRANCH=None BUG=None TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco. Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229975 Reviewed-on: http://review.coreboot.org/9620 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-04cbfstool: Clean up codeStefan Reinauer
cbfstool has diverged between coreboot upstream and the chromium tree. Bring in some of the chromium changes, in particular the useful remainders of cbf37fe (https://chromium-review.googlesource.com/176710) - fix coding style - mark unused variables explicitly unused - remove some dead code Change-Id: I354aaede8ce425ebe99d4c60c232feea62bf8a11 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/8577 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-11-04cbfstool: Add option to ignore section in add-stageFurquan Shaikh
Allow add-stage to have an optional parameter for ignoring any section. This is required to ensure proper operation of elf_to_stage in case of loadable segments with zero filesize. Change-Id: I49ad62c2a4260ab9cec173c80c0f16923fc66c79 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/7304 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-09-25cbfstool: Propogate compression errors back to the caller.Gabe Black
When compression fails for whatever reason, the caller should know about it rather than blindly assuming it worked correctly. That can prevent half compressed data from ending up in the image. This is currently happening for a segment of depthcharge which is triggering a failure in LZMA. The size of the "compressed" data is never set and is recorded as zero, and that segment effectively isn't loaded during boot. Change-Id: Idbff01f5413d030bbf5382712780bbd0b9e83bc7 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/187364 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit be48f3e41eaf0eaf6686c61c439095fc56883cec) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6960 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-12cbfstool: Fix architecture check when adding payloadStefan Reinauer
In the process of rewriting cbfstool for ARM and using a new internal API a regression was introduced that would silently let you add an ARM payload into an x86 CBFS image and the other way around. This patch fixes cbfstool to produce an error in that case again. Change-Id: I37ee65a467d9658d0846c2cf43b582e285f1a8f8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/176711 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 8f74f3f5227e440ae46b59f8fd692f679f3ada2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6879 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-03-28cbfstool: provide structure to linux payload builderAaron Durbin
This change started with tracking down a bug where the trampoline size was not being taken into account for sizing the output buffer leading to a heap corruption. I was having a hard time keeping track of what num_segments actually tracked as well as what parts were being placed in the output buffer. Here's my attempt at hopefully providing more clarity. This change doesn't crash when adding a bzImage: $ dd if=/dev/zero of=bb.bin bs=64 count=1 $ ./cbfstool tmp.rom create -s 4M -B bb.bin -m x86 -a 64 $ ./cbfstool tmp.rom add-payload -f ~/Downloads/bzImage -C "1" -n "fallback"/payload Change-Id: Ib1de1ddfec3c7102facffc5815c52b340fcdc628 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5408 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-13cbfstool: move iself() to eflheaders.cAaron Durbin
The only user of iself() was in elfheaders.c. Move it there, and make it local to the compilation unit. Change-Id: I0d919ce372f6e2fce75885fb4fcba20d985979b3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5369 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-11cbfstool: add struct buffer helper routinesAaron Durbin
There are some open-coded manipulation of the struct buffer innards in the elf parsing code. Add helper functions to avoid reaching into the struct itself. Change-Id: I0d5300afa1a3549f87f588f976184e880d071682 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5367 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-11cbfstool: add bputs() to store a byte stream to a bufferAaron Durbin
There was already a bgets() function which operates on a buffer to copy a byte stream. Provide bputs() to store a byte stream to a buffer, thus making the API symmetrical. Change-Id: I6166f6b68eacb822da38c9da61a3e44f4c67136d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5366 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-11cbfstool: add get8/put8 variants to xdr structuresAaron Durbin
In order to provide consistent usage provide the get8() and put8() callbacks to xdr operations. That way no futzing needs to be done to handle 8-bit reads and writes. Change-Id: I1233d25df67134dc5c3bbd1a84206be77f0da417 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5365 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-02-05Add an xdr function for the cbfs_file headerRonald G. Minnich
And use it in fit.c and remove one more use of htonl. Change-Id: Ibf18dcc0a7f08d75c2374115de0db7a4bf64ec1e Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: http://review.coreboot.org/5120 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-04cbfstool: Eliminate global variable "arch"Alexandru Gagniuc
Now that unused functions have been removed, the global "arch" is only used in very few places. We can pack "arch" in the "param" structure and pass it down to where it is actually used. Change-Id: I255d1e2bc6b5ead91b6b4e94a0202523c4ab53dc Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5105 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-04cbfstool: Remove more unused functions from common.cAlexandru Gagniuc
A lot of the early functions have been re-implemented in a context- centric mode, rather than relying on global variables. Removing these has the nice side-effect of allowing us to remove more global variables. Change-Id: Iee716ef38729705432dd10d12758c886d38701a8 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5104 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-04cbfstool: Hide cbfstool_offset from the global namespaceAlexandru Gagniuc
This is part of a larger effort to reduce global variable usage in cbfstool. cbfstool_offset is particularly easy to hide since it's only used in common.c . Change-Id: Ic45349b5148d4407f31e12682ea0ad4b68136711 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5102 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-03cbfstool: remove unused function create_cbfs_image()Alexandru Gagniuc
It's not used anymore. Instead, we have the better replacements cbfs_image_create() and cbfs_image_from_file(). Change-Id: I7835f339805f6b41527fe3550028b29f79e35d13 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5103 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-02Add section header parsing and use it in the mk-payload stepRonald G. Minnich
This completes the improvements to the ELF file parsing code. We can now parse section headers too, across all 4 combinations of word size and endianness. I had hoped to completely remove the use of htonl until I found it in cbfs_image.c. That's a battle for another day. There's now a handy macro to create magic numbers in host byte order. I'm using it for all the PAYLOAD_SEGMENT_* constants and maybe we can use it for the others too, but this is sensitive code and I'd rather change one thing at a time. To maximize the ease of use for users, elf parsing is accomplished with just one function: int elf_headers(const struct buffer *pinput, Elf64_Ehdr *ehdr, Elf64_Phdr **pphdr, Elf64_Shdr **pshdr) which requires the ehdr and pphdr pointers to be non-NULL, but allows the pshdr to be NULL. If pshdr is NULL, the code will not try to read in section headers. To satisfy our powerful scripts, I had to remove the ^M from an unrelated microcode file. BUG=None TEST=Build a peppy image (known to boot) with old and new versions and verify they are bit-for-bit the same. This was also fully tested across all chromebooks for building and booting and running chromeos. BRANCH=None Change-Id: I54dad887d922428b6175fdb6a9cdfadd8a6bb889 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: https://chromium-review.googlesource.com/181272 Reviewed-by: Ronald Minnich <rminnich@chromium.org> Commit-Queue: Ronald Minnich <rminnich@chromium.org> Tested-by: Ronald Minnich <rminnich@chromium.org> Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: http://review.coreboot.org/5098 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-29cbfs: fix issues with word size and endianness.Ronald G. Minnich
Add XDR functions and use them to convert the ELF headers to native headers, using the Elf64 structs to ensure we accomodate all word sizes. Also, use these XDR functions for output. This may seem overly complex but it turned out to be much the easiest way to do this. Note that the basic elf parsing function in cbfs-mkstage.c now works over all ELF files, for all architectures, endian, and word size combinations. At the same time, the basic elf parsing in cbfs-mkstage.c is a loop that has no architecture-specific conditionals. Add -g to the LDFLAGS while we're here. It's on the CFLAGS so there is no harm done. This code has been tested on all chromebooks that use coreboot to date. I added most of the extra checks from ChromeOS and they triggered a lot of warnings, hence the other changes. I had to take -Wshadow back out due to the many errors it triggers in LZMA. BUG=None TEST=Build and boot for Peppy; works fine. Build and boot for nyan, works fine. Build for qemu targets and armv8 targets. BRANCH=None Change-Id: I5a4cee9854799189115ac701e22efc406a8d902f Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: https://chromium-review.googlesource.com/178606 Reviewed-by: Ronald Minnich <rminnich@chromium.org> Commit-Queue: Ronald Minnich <rminnich@chromium.org> Tested-by: Ronald Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/4817 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-08-31Add a (b)zImage parser to cbfstoolPatrick Georgi
In the great tradition of LinuxBIOS this allows adding a kernel as payload. add-payload is extended to also allow adding an initial ramdisk (-I filename) and a command line (-C console=ttyS0). Change-Id: Iaca499a98b0adf0134e78d6bf020b6531a626aaa Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/3302 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-05cbfstool: support parsing UEFI firmware volumesStefan Reinauer
This removes the hack implemented in http://review.coreboot.org/#/c/2280 (and should make using 64bit Tiano easier, but that's not yet supported) Change-Id: Ie30129c4102dfbd41584177f39057b31f5a937fd Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2281 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05cbfstool: Use cbfs_image API for "add-*" (add-payload, add-stage, ...) commands.Hung-Te Lin
add-payload, add-stage, and add-flat-binary are now all using cbfs_image API. To test: cbfstool coreboot.rom add-stage -f FILE -n fallback/romstage -b 0xXXXX cbfstool coreboot.rom add-payload -f FILE -n fallback/pyload And compare with old cbfstool. Verified to boot on ARM(snow) and X86(qemu-i386). Change-Id: If65cb495c476ef6f9d90c778531f0c3caf178281 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2220 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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