GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/util/cbfstool/cbfs_image.h

208 lines
9.1 KiB
C
Raw Normal View History

cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
/*
* CBFS Image Manipulation
*
* Copyright (C) 2013 The Chromium OS Authors. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#ifndef __CBFS_IMAGE_H
#define __CBFS_IMAGE_H
#include "common.h"
#include "cbfs.h"
/* CBFS image processing */
struct cbfs_image {
struct buffer buffer;
cbfstool: New image format w/ required FMAP and w/o CBFS master header 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-03-18 20:36:27 +01:00
/* An image has a header iff it's a legacy CBFS. */
bool has_header;
/* Only meaningful if has_header is selected. */
cbfstool: Fix leak in cbfs_image struct initialization This patches a memory leak on every struct cbfs_image creation that was introduced by c1d1fd850ee7b8e52bd2ea5064fab68ac0c27098. Since that commit, the CBFS master header has been copied to a separate buffer so that its endianness could be fixed all at once; unfortunately, this buffer was malloc()'d but never free()'d. To address the issue, we replace the structure's struct cbfs_header * with a struct cbfs_header to eliminate the additional allocation. Change-Id: Ie066c6d4b80ad452b366a2a95092ed45aa55d91f Signed-off-by: Sol Boucher <solb@chromium.org> Reviewed-on: http://review.coreboot.org/10130 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-06 00:40:15 +02:00
struct cbfs_header header;
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
};
cbfstool: Factor out compression algorithm list Parse compression algorithm arguments using a single list. Change-Id: Idc5b14a53377b29964f24221e42db6e09a497d48 Signed-off-by: Sol Boucher <solb@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb Original-Signed-off-by: Sol Boucher <solb@chromium.org> Reviewed-on: http://review.coreboot.org/10931 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-08 06:00:05 +02:00
/* Given the string name of a compression algorithm, return the corresponding
* enum comp_algo if it's supported, or a number < 0 otherwise. */
int cbfs_parse_comp_algo(const char *name);
cbfstool: Add support for hashes as file metadata They allow optimizing a verification of a whole CBFS image by only dealing with the headers (assuming you choose to trust the hash algorithm(s)). The format allows for multiple hashes for a single file, and cbfstool can handle them, but right now it can't generate such headers. Loosely based on Sol's work in http://review.coreboot.org/#/c/10147/, but using the compatible file attribute format. vboot is now a hard dependency of the build process, but we import it into the tree for quite a while now. Change-Id: I9f14f30537d676ce209ad612e7327c6f4810b313 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/11767 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-01 15:54:04 +02:00
/* Given the string name of a hash algorithm, return the corresponding
* id if it's supported, or a number < 0 otherwise. */
int cbfs_parse_hash_algo(const char *name);
cbfstool: add code to serialize the header using the new xdr functions This change adds a header serialization function. Programmers can thus just set up a header as needed, without worrying about forgetting if and how to use the [hn]to[hn]* functions. In the long term, we will work to remove swab.h, i.e. we need to get to the point where programmers don't have to try to remember [hn]to[nh]* and where it goes. To date, even the best programmers we have have made an error with those functions, and those errors have persisted for 6 or 7 years now. It's very easy to make that mistake. BUG=None TEST=Build a peppy image and verify that it's bit for bit the same. All chromebooks use this code and build and boot correctly. BRANCH=None Change-Id: I0f9b8e7cac5f52d0ea330ba948650fa0803aa0d5 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: https://chromium-review.googlesource.com/181552 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/5100 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-06 17:38:15 +01:00
/* Given a pointer, serialize the header from host-native byte format
* to cbfs format, i.e. big-endian. */
void cbfs_put_header(void *dest, const struct cbfs_header *header);
cbfstool: Deserialize CBFS master header when reading image Rather than using [hn]to[nh] whenever accessing a member of the CBFS header, deserialize the header when opening the CBFS image. The header is no longer a pointer inside the CBFS buffer, but a separate struct, a copy of the original header in a host-friendly format. This kills more of the ntohl usage. Change-Id: I5f8a5818b9d5a2d1152b1906249c4a5847d02bac Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5121 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-05 08:10:08 +01:00
/* Or deserialize into host-native format */
cbfstool: Clean up in preparation for adding new files 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-03-06 00:38:03 +01:00
void cbfs_get_header(struct cbfs_header *header, void *src);
cbfstool: add code to serialize the header using the new xdr functions This change adds a header serialization function. Programmers can thus just set up a header as needed, without worrying about forgetting if and how to use the [hn]to[hn]* functions. In the long term, we will work to remove swab.h, i.e. we need to get to the point where programmers don't have to try to remember [hn]to[nh]* and where it goes. To date, even the best programmers we have have made an error with those functions, and those errors have persisted for 6 or 7 years now. It's very easy to make that mistake. BUG=None TEST=Build a peppy image and verify that it's bit for bit the same. All chromebooks use this code and build and boot correctly. BRANCH=None Change-Id: I0f9b8e7cac5f52d0ea330ba948650fa0803aa0d5 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: https://chromium-review.googlesource.com/181552 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/5100 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-06 17:38:15 +01:00
cbfstool: New image format w/ required FMAP and w/o CBFS master header 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-03-18 20:36:27 +01:00
/* Populates a CBFS with a single empty entry filling all available space
* (entries_size bytes). If image's header field is already present, its
* contents will be used to place an empty entry of the requested length at the
* appropriate position in the existing buffer; otherwise, if not has_header,
* the first entries_size bytes of buffer will be filled exclusively with the
* single empty entry (and no CBFS master header).
* Returns 0 on success, otherwise nonzero. */
int cbfs_image_create(struct cbfs_image *image, size_t entries_size);
cbfstool: Use cbfs_image API for "create" command. Usage Changes: To support platforms with different memory layout, "create" takes two extra optional parameters: "-b": base address (or offset) for bootblock. When omitted, put bootblock in end of ROM (x86 style). "-H": header offset. When omitted, put header right before bootblock, and update a top-aligned virtual address reference in end of ROM. Example: (can be found in ARM MAkefile): cbfstool coreboot.rom create -m armv7 -s 4096K -B bootblock.bin \ -a 64 -b 0x0000 -H 0x2040 -o 0x5000 Verified to boot on ARM (Snow) and X86 (QEMU). Change-Id: Ida2a9e32f9a459787b577db5e6581550d9d7017b Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2214 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-29 02:45:12 +01:00
/* Creates an empty CBFS image by given size, and description to its content
cbfstool: Restructure around support for reading/writing portions of files 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-03-25 21:40:08 +01:00
* (bootblock, align, header location, starting offset of CBFS entries).
cbfstool: Use cbfs_image API for "create" command. Usage Changes: To support platforms with different memory layout, "create" takes two extra optional parameters: "-b": base address (or offset) for bootblock. When omitted, put bootblock in end of ROM (x86 style). "-H": header offset. When omitted, put header right before bootblock, and update a top-aligned virtual address reference in end of ROM. Example: (can be found in ARM MAkefile): cbfstool coreboot.rom create -m armv7 -s 4096K -B bootblock.bin \ -a 64 -b 0x0000 -H 0x2040 -o 0x5000 Verified to boot on ARM (Snow) and X86 (QEMU). Change-Id: Ida2a9e32f9a459787b577db5e6581550d9d7017b Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2214 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-29 02:45:12 +01:00
* The output image will contain a valid cbfs_header, with one cbfs_file
* entry with type CBFS_COMPONENT_NULL, with max available size.
cbfstool: New image format w/ required FMAP and w/o CBFS master header 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-03-18 20:36:27 +01:00
* Only call this if you want a legacy CBFS with a master header.
* Returns 0 on success, otherwise nonzero. */
int cbfs_legacy_image_create(struct cbfs_image *image,
uint32_t arch,
uint32_t align,
struct buffer *bootblock,
uint32_t bootblock_offset,
uint32_t header_offset,
uint32_t entries_offset);
cbfstool: Use cbfs_image API for "create" command. Usage Changes: To support platforms with different memory layout, "create" takes two extra optional parameters: "-b": base address (or offset) for bootblock. When omitted, put bootblock in end of ROM (x86 style). "-H": header offset. When omitted, put header right before bootblock, and update a top-aligned virtual address reference in end of ROM. Example: (can be found in ARM MAkefile): cbfstool coreboot.rom create -m armv7 -s 4096K -B bootblock.bin \ -a 64 -b 0x0000 -H 0x2040 -o 0x5000 Verified to boot on ARM (Snow) and X86 (QEMU). Change-Id: Ida2a9e32f9a459787b577db5e6581550d9d7017b Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2214 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-29 02:45:12 +01:00
cbfstool: Restructure around support for reading/writing portions of files 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-03-25 21:40:08 +01:00
/* Constructs a cbfs_image from a buffer. The resulting image contains a shallow
* copy of the buffer; releasing either one is the legal way to clean up after
* both of them at once. Always produces a cbfs_image, but...
* Returns 0 if it contains a valid CBFS, non-zero if it's unrecognized data. */
int cbfs_image_from_buffer(struct cbfs_image *out, struct buffer *in,
uint32_t offset);
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
cbfstool: New image format w/ required FMAP and w/o CBFS master header 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-03-18 20:36:27 +01:00
/* Create a duplicate CBFS image. Returns 0 on success, otherwise non-zero.
* Will not succeed on new-style images without a master header. */
cbfstool: Use buffer over offset/size pair for cbfs_copy_instance This allows adding support for FMAP based cbfstool copy more easily. BUG=chromium:445938 Change-Id: I72e7bc4da7d27853e324400f76f86136e3d8726e Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/12787 Tested-by: build bot (Jenkins)
2015-11-20 19:22:50 +01:00
int cbfs_copy_instance(struct cbfs_image *image, struct buffer *dst);
cbfstool: add a command to duplicate a cbfs instance The new command allows to create a file where the original CBFS image is duplicated at a different offset. The required options of the new command are -D, the offset where the copy CBFS header is placed, and -s, the size of the new CBFS copy. When a CBFS is copied, the bootblock area of the source CBFS is ignored, as well as empty and deleted files in the source CBFS. The size of the destination CBFS is calculated as the rombase size of the source CBFS less the bootblock size. The copy instance can be created in the image only above the original, which rules out the use of this new command for x86 images. If necessary, this limitation could be addressed later. As with other cbfstool commands, unless explicitly specified the lowest CBFS instance in the image is considered the source. If necessary, the user can specify the source CBFS using the -H option. BRANCH=storm BUG=chrome-os-partner:34161, chromium:445938 TEST=run multiple cbfstool commands on a storm image: $ cd /tmp $ cp /build/storm/firmware/image.serial.bin storm.bin $ cbfstool storm.bin print storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700 alignment: 64 bytes, architecture: arm Name Offset Type Size cdt.mbn 0x8700 raw 416 ddr.mbn 0x8900 raw 25836 rpm.mbn 0xee40 raw 78576 tz.mbn 0x22180 raw 85360 fallback/verstage 0x36f40 stage 41620 fallback/romstage 0x41240 stage 19556 fallback/ramstage 0x45f00 stage 25579 config 0x4c340 raw 2878 fallback/payload 0x4cec0 payload 64811 u-boot.dtb 0x5cc40 (unknown) 2993 (empty) 0x5d840 null 75608 $ cbfstool storm.bin copy -D 0x420000 E: You need to specify -s/--size. $ cbfstool storm.bin copy -D 0x420000 -s 0x70000 $ cbfstool storm.bin print W: Multiple (2) CBFS headers found, using the first one. storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700 alignment: 64 bytes, architecture: arm Name Offset Type Size cdt.mbn 0x8700 raw 416 ddr.mbn 0x8900 raw 25836 rpm.mbn 0xee40 raw 78576 tz.mbn 0x22180 raw 85360 fallback/verstage 0x36f40 stage 41620 fallback/romstage 0x41240 stage 19556 fallback/ramstage 0x45f00 stage 25579 config 0x4c340 raw 2878 fallback/payload 0x4cec0 payload 64811 u-boot.dtb 0x5cc40 (unknown) 2993 (empty) 0x5d840 null 75608 cbfstool storm.bin print -H 0x420000 storm.bin: 8192 kB, bootblocksize 0, romsize 4784128, offset 0x420040 alignment: 64 bytes, architecture: arm Name Offset Type Size cdt.mbn 0x420040 raw 416 ddr.mbn 0x420240 raw 25836 rpm.mbn 0x426780 raw 78576 tz.mbn 0x439ac0 raw 85360 fallback/verstage 0x44e880 stage 41620 fallback/romstage 0x458b80 stage 19556 fallback/ramstage 0x45d840 stage 25579 config 0x463c80 raw 2878 fallback/payload 0x464800 payload 64811 u-boot.dtb 0x474580 (unknown) 2993 (empty) 0x475180 null 110168 $ cbfstool storm.bin remove -n config -H 0x420000 $ cbfstool storm.bin copy -H 0x420000 -D 0x620000 -s 0x70000 $ cbfstool storm.bin print -H 0x620000 storm.bin: 8192 kB, bootblocksize 0, romsize 6881280, offset 0x620040 alignment: 64 bytes, architecture: arm Name Offset Type Size cdt.mbn 0x620040 raw 416 ddr.mbn 0x620240 raw 25836 rpm.mbn 0x626780 raw 78576 tz.mbn 0x639ac0 raw 85360 fallback/verstage 0x64e880 stage 41620 fallback/romstage 0x658b80 stage 19556 fallback/ramstage 0x65d840 stage 25579 fallback/payload 0x663c80 payload 64811 u-boot.dtb 0x673a00 (unknown) 2993 (empty) 0x674600 null 113112 $ cbfstool /build/storm/firmware/image.serial.bin extract -n fallback/payload -f payload1 [..] $ cbfstool storm.bin extract -H 0x620000 -n fallback/payload -f payload2 [..] $ diff payload1 payload2 Change-Id: Ieb9205848aec361bb870de0d284dff06c597564f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b8d3c1b09a47ca24d2d2effc6de0e89d1b0a8903 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Change-Id: I227e607ccf7a9a8e2a1f3c6bbc506b8d29a35b1b Original-Reviewed-on: https://chromium-review.googlesource.com/237561 Reviewed-on: http://review.coreboot.org/9742 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 04:26:54 +01:00
util/cbfstool: add 'compact' command While assembling CBFS images within the RW slots on Chrome OS machines the current approach is to 'cbfstool copy' from the RO CBFS to each RW CBFS. Additional fixups are required such as removing unneeded files from the RW CBFS (e.g. verstage) as well as removing and adding back files with the proper arguments (FSP relocation as well as romstage XIP relocation). This ends up leaving holes in the RW CBFS. To speed up RW CBFS slot hashing it's beneficial to pack all non-empty files together at the beginning of the CBFS. Therefore, provide the 'compact' command which bubbles all the empty entries to the end of the CBFS. Change-Id: I8311172d71a2ccfccab384f8286cf9f21a17dec9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13479 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-27 00:08:56 +01:00
/* Compact a fragmented CBFS image by placing all the non-empty files at the
* beginning of the image. Returns 0 on success, otherwise non-zero. */
int cbfs_compact_instance(struct cbfs_image *image);
util/cbfstool: Add "expand" command to make CBFS span an fmap region vboot images come with multiple regions carrying CBFS file systems. To expedite hashing (from slow flash memory), the FW_MAIN_* regions are truncated since they typically have pretty large unused space at the end that is of no interest. For test purposes it can be useful to re-engage that space, so add a command that creates a new empty file entry covering that area (except for the last 4 bytes for the master header pointer, as usual). BUG=b:65853903 BRANCH=none TEST=`cbfstool test.bin expand -r FW_MAIN_A` creates a new empty file of the expected size on a Chrome OS firmware image. Change-Id: I160c8529ce4bfcc28685166b6d9035ade4f6f1d1 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/21598 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-09-19 14:39:58 +02:00
/* Expand a CBFS image inside an fmap region to the entire region's space.
Returns 0 on success, otherwise non-zero. */
int cbfs_expand_to_region(struct buffer *region);
util/cbfstool: Add "truncate" command It does the opposite to "expand", removing a trailing empty file from CBFS. It also returns the size of the CBFS post processing on stdout. BUG=b:65853903 BRANCH=none TEST=`cbfstool test.bin truncate -r FW_MAIN_A` removes the trailing empty file in FW_MAIN_A. Without a trailing empty file, the region is left alone (tested using COREBOOT which comes with a master header pointer). Change-Id: I0c747090813898539f3428936afa9d8459adee9c Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/21608 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-09-20 11:59:18 +02:00
/* Truncate a CBFS by removing a trailing "empty" file if it exists.
Returns 0 on success, otherwise non-zero and passes the CBFS' remaining
size in the size argument. */
int cbfs_truncate_space(struct buffer *region, uint32_t *size);
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
/* Releases the CBFS image. Returns 0 on success, otherwise non-zero. */
int cbfs_image_delete(struct cbfs_image *image);
cbfstool: Use cbfs_image API for "extract" command. Change the "extract" command to use cbfs_export_entry API. Nothing changed in its usage. To verify, run "cbfstool coreboot.rom extract -f blah -n blah" and check if the raw type file is correctly extracted. Change-Id: I1ed280d47a2224a9d1213709f6b459b403ce5055 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2207 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:29:49 +01:00
/* Returns a pointer to entry by name, or NULL if name is not found. */
struct cbfs_file *cbfs_get_entry(struct cbfs_image *image, const char *name);
cbfstool: add unprocessed flag for file exporting Add an unprocessed flag (-U) which modifies how files are exported. In the case of a compressed raw file, extract without decompressing. In the case of a stage or payload, extract without decompressing or converting to an ELF. This can be useful for verifying the integrity of a stage or payload, since converting to an ELF may not be a deterministic process on different platforms or coreboot versions. BUG=b:111577108 TEST=USE=cb_legacy_tianocore emerge-eve edk2 coreboot-utils chromeos-bootimage cd /build/eve/firmware /build/eve/usr/bin/cbfstool image.bin extract -r RW_LEGACY \ -n payload -f /tmp/payload_1 -U START=$((16#`xxd -s 20 -l 4 -p tianocore.cbfs`)) SIZE=$((16#`xxd -s 8 -l 4 -p tianocore.cbfs`)) dd if=tianocore.cbfs skip=$START count=$SIZE bs=1 > /tmp/payload_2 diff /tmp/payload_1 /tmp/payload_2 rm /tmp/payload_1 /tmp/payload_2 Change-Id: I351d471d699daedd51adf4a860661877f25607e6 Signed-off-by: Joel Kitching <kitching@chromium.org> Reviewed-on: https://review.coreboot.org/29616 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-08-09 11:49:52 +02:00
/* Exports an entry to external file. If do_processing is true, file contents
* will be decompressed, and also turned into an ELF if appropriate.
cbfstool: Use cbfs_image API for "extract" command. Change the "extract" command to use cbfs_export_entry API. Nothing changed in its usage. To verify, run "cbfstool coreboot.rom extract -f blah -n blah" and check if the raw type file is correctly extracted. Change-Id: I1ed280d47a2224a9d1213709f6b459b403ce5055 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2207 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:29:49 +01:00
* Returns 0 on success, otherwise (ex, not found) non-zero. */
int cbfs_export_entry(struct cbfs_image *image, const char *entry_name,
cbfstool: add unprocessed flag for file exporting Add an unprocessed flag (-U) which modifies how files are exported. In the case of a compressed raw file, extract without decompressing. In the case of a stage or payload, extract without decompressing or converting to an ELF. This can be useful for verifying the integrity of a stage or payload, since converting to an ELF may not be a deterministic process on different platforms or coreboot versions. BUG=b:111577108 TEST=USE=cb_legacy_tianocore emerge-eve edk2 coreboot-utils chromeos-bootimage cd /build/eve/firmware /build/eve/usr/bin/cbfstool image.bin extract -r RW_LEGACY \ -n payload -f /tmp/payload_1 -U START=$((16#`xxd -s 20 -l 4 -p tianocore.cbfs`)) SIZE=$((16#`xxd -s 8 -l 4 -p tianocore.cbfs`)) dd if=tianocore.cbfs skip=$START count=$SIZE bs=1 > /tmp/payload_2 diff /tmp/payload_1 /tmp/payload_2 rm /tmp/payload_1 /tmp/payload_2 Change-Id: I351d471d699daedd51adf4a860661877f25607e6 Signed-off-by: Joel Kitching <kitching@chromium.org> Reviewed-on: https://review.coreboot.org/29616 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-08-09 11:49:52 +02:00
const char *filename, uint32_t arch, bool do_processing);
cbfstool: Use cbfs_image API for "extract" command. Change the "extract" command to use cbfs_export_entry API. Nothing changed in its usage. To verify, run "cbfstool coreboot.rom extract -f blah -n blah" and check if the raw type file is correctly extracted. Change-Id: I1ed280d47a2224a9d1213709f6b459b403ce5055 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2207 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:29:49 +01:00
cbfstool: Use cbfs_image api for "add" command. The "add" command is compatible with all legacy usage. Also, to support platforms without top-aligned address, all address-type params (-b, -H, -l) can now be ROM offset (address < 0x8000000) or x86 top-aligned address (address > 0x80000000). Example: cbfstool coreboot.rom add -f config -n config -t raw -b 0x2000 cbfstool coreboot.rom add -f stage -n newstage -b 0xffffd1c0 Verified boot-able on both ARM(snow) and x86(QEMU) system. Change-Id: I485e4e88b5e269494a4b138e0a83f793ffc5a084 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2216 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-29 03:24:00 +01:00
/* Adds an entry to CBFS image by given name and type. If content_offset is
* non-zero, try to align "content" (CBFS_SUBHEADER(p)) at content_offset.
cbfstool: Support top-aligned addresses for new-format images 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-07 11:39:22 +02:00
* Never pass this function a top-aligned address: convert it to an offset.
cbfstool: Use cbfs_image api for "add" command. The "add" command is compatible with all legacy usage. Also, to support platforms without top-aligned address, all address-type params (-b, -H, -l) can now be ROM offset (address < 0x8000000) or x86 top-aligned address (address > 0x80000000). Example: cbfstool coreboot.rom add -f config -n config -t raw -b 0x2000 cbfstool coreboot.rom add -f stage -n newstage -b 0xffffd1c0 Verified boot-able on both ARM(snow) and x86(QEMU) system. Change-Id: I485e4e88b5e269494a4b138e0a83f793ffc5a084 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2216 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-29 03:24:00 +01:00
* Returns 0 on success, otherwise non-zero. */
int cbfs_add_entry(struct cbfs_image *image, struct buffer *buffer,
cbfstool: don't pass header_size as separate argument (part 2) It's already present inside struct cbfs_file Change-Id: Ic9682e93c3d208e2ed458940e4a9f9f5a64b6e98 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/11333 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-25 22:27:57 +02:00
uint32_t content_offset, struct cbfs_file *header);
cbfstool: Use cbfs_image api for "add" command. The "add" command is compatible with all legacy usage. Also, to support platforms without top-aligned address, all address-type params (-b, -H, -l) can now be ROM offset (address < 0x8000000) or x86 top-aligned address (address > 0x80000000). Example: cbfstool coreboot.rom add -f config -n config -t raw -b 0x2000 cbfstool coreboot.rom add -f stage -n newstage -b 0xffffd1c0 Verified boot-able on both ARM(snow) and x86(QEMU) system. Change-Id: I485e4e88b5e269494a4b138e0a83f793ffc5a084 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2216 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-29 03:24:00 +01:00
cbfstool: Use cbfs_image API for "remove" command. To delete a component (file) from existing CBFS ROM image. To test: cbfstool coreboot.rom remove -n fallback/romstage # and compare with old cbfstool output result. Change-Id: If39ef9be0b34d8e3df77afb6c9f944e02f08bc4e Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2208 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:38:40 +01:00
/* Removes an entry from CBFS image. Returns 0 on success, otherwise non-zero. */
int cbfs_remove_entry(struct cbfs_image *image, const char *name);
cbfstool: factor out creating a cbfs file header We will want to create headers that live outside the final image at some point (eg. to build the file before we even know where to place it). Change-Id: Ie4c0323df8d5be955aec3621b75309e8f11fae49 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/11219 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-12 09:20:11 +02:00
/* Create a new cbfs file header structure to work with.
Returns newly allocated memory that the caller needs to free after use. */
struct cbfs_file *cbfs_create_file_header(int type, size_t len,
const char *name);
cbfstool: Use cbfs_image API for "locate" command. To support platforms without top-aligned address mapping like ARM, "locate" command now outputs platform independent ROM offset by default. To retrieve x86 style top-aligned virtual address, add "-T". To test: cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T # Example output: 0xffffdc10 Change-Id: I474703c4197b36524b75407a91faab1194edc64d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2213 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:46:02 +01:00
/* Initializes a new empty (type = NULL) entry with size and name in CBFS image.
* Returns 0 on success, otherwise (ex, not found) non-zero. */
cbfstool: Make cbfs_create_empty_entry build a more complete header Pass the file type into it instead of creating an entry, then modifying the header field again after the fact. Change-Id: I655583218f5085035b0f80efff7f91a66b5b296e Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/11218 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-12 09:12:06 +02:00
int cbfs_create_empty_entry(struct cbfs_file *entry, int type,
cbfstool: Use cbfs_image API for "locate" command. To support platforms without top-aligned address mapping like ARM, "locate" command now outputs platform independent ROM offset by default. To retrieve x86 style top-aligned virtual address, add "-T". To test: cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T # Example output: 0xffffdc10 Change-Id: I474703c4197b36524b75407a91faab1194edc64d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2213 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:46:02 +01:00
size_t len, const char *name);
cbfstool locate: Implement alignment switch --align/-a cbfstool usage change: "-a" for "cbfstool locate" can specify base address alignment. To support putting a blob in aligned location (ex, microcode needs to be aligned in 0x10), alignment (-a) is implemented into "locate" command. Verified by manually testing a file (324 bytes) with alignment=0x10: cbfstool coreboot.rom locate -f test -n test -a 0x10 # output: 0x71fdd0 cbfstool coreboot.rom add -f test -n test -t raw -b 0x71fdd0 cbfstool coreboot.rom print -v -v # output: test 0x71fd80 raw 324 # output: cbfs_file=0x71fd80, offset=0x50, content_address=0x71fdd0+0x144 Also verified to be compatible with old behavior by building i386/axus/tc320 (with page limitation 0x40000): cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000 # output: 0x44 cbfstool coreboot.rom locate -f x.bin -n romstage -P 0x40000 -a 0x30 # output: 0x60 Change-Id: I78b549fe6097ce5cb6162b09f064853827069637 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2824 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-19 05:24:43 +01:00
/* Finds a location to put given content by specified criteria:
* "page_size" limits the content to fit on same memory page, and
* "align" specifies starting address alignment.
cbfstool: Use cbfs_image API for "locate" command. To support platforms without top-aligned address mapping like ARM, "locate" command now outputs platform independent ROM offset by default. To retrieve x86 style top-aligned virtual address, add "-T". To test: cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T # Example output: 0xffffdc10 Change-Id: I474703c4197b36524b75407a91faab1194edc64d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2213 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:46:02 +01:00
* Returns a valid offset, or -1 on failure. */
cbfstool: provide metadata size to cbfs_locate_entry() The cbfs_locate_entry() function had a hack in there which assumed a struct cbfs_stage data was being added in addition to the struct cbfs_file and name. Move that logic out to the callers while still maintaining the logic for consistency. The only impacted commands cbfs_add and cbfs_locate, but those are using the default 'always adding struct cbfs_stage' in addition to cbfs_file + name. Eventually those should be removed when cbfs_locate is removed as cbfs_add has no smarts related to the cbfs file type provided. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi. Change-Id: I2771116ea1ff439ea53b8886e1f33e0e637a79d4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11668 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-15 19:50:14 +02:00
int32_t cbfs_locate_entry(struct cbfs_image *image, size_t size,
size_t page_size, size_t align, size_t metadata_size);
cbfstool: Use cbfs_image API for "locate" command. To support platforms without top-aligned address mapping like ARM, "locate" command now outputs platform independent ROM offset by default. To retrieve x86 style top-aligned virtual address, add "-T". To test: cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T # Example output: 0xffffdc10 Change-Id: I474703c4197b36524b75407a91faab1194edc64d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2213 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:46:02 +01:00
cbfstool: Use cbfs_image API for "print" command. Process CBFS ROM image by new cbfs_image API. To verify, run "cbfstool coreboot.rom print -v" and compare with old cbfstool. Change-Id: I3a5a9ef176596d825e6cdba28a8ad732f69f5600 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2206 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:15:49 +01:00
/* Callback function used by cbfs_walk.
* Returns 0 on success, or non-zero to stop further iteration. */
typedef int (*cbfs_entry_callback)(struct cbfs_image *image,
struct cbfs_file *file,
void *arg);
/* Iterates through all entries in CBFS image, and invoke with callback.
* Stops if callback returns non-zero values.
* Returns number of entries invoked. */
int cbfs_walk(struct cbfs_image *image, cbfs_entry_callback callback, void *arg);
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
/* Primitive CBFS utilities */
/* Returns a pointer to the only valid CBFS header in give buffer, otherwise
* NULL (including when multiple headers were found). If there is a X86 ROM
* style signature (pointer at 0xfffffffc) found in ROM, it will be selected as
* the only header.*/
cbfstool: allow user to explicitly specify header location There potentially could be multiple CBFS instances present in the firmware image. cbfstool should be able to operate on any of them, not just the first one present. To accomplish that, allow all CBFS commands to accept the -H parameter (which specifies the exact CBFS header location in the image). If this parameter is specified, the image is not searched for the CBFS header, only the specified location is checked for validity, If the location is valid, it is considered to be the CBFS header, if not - the tool exits with an error status. Note, that default behavior of the tool does not change. BRANCH=storm BUG=chrome-os-partner:34161, chromium:445938 TEST=run the following experiments: - examined an image with three CBFS instances, was able to print all of them. - built a rambi coreboot image and tried the following (cbfstool output abbreviated): $ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000 alignment: 64 bytes, architecture: x86 Name Offset Type Size cmos_layout.bin 0x700000 cmos_layout 1164 ... (empty) 0x7ec600 null 77848 $ \od -tx4 -Ax /build/rambi/firmware/coreboot.rom | tail -2 7ffff0 fff67de9 000000ff fff6dfe9 fffff650 800000 $ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff650 coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000 alignment: 64 bytes, architecture: x86 Name Offset Type Size cmos_layout.bin 0x700000 cmos_layout 1164 ... (empty) 0x7ec600 null 77848 $ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff654 E: /build/rambi/firmware/coreboot.rom does not have CBFS master header. E: Could not load ROM image '/build/rambi/firmware/coreboot.rom'. $ Change-Id: I64cbdc79096f3c7a113762b641305542af7bbd60 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 86b88222df6eed25bb176d653305e2e57e18b73a Original-Change-Id: I486092e222c96c65868ae7d41a9e8976ffcc93c4 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237485 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/9741 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:10:12 +01:00
struct cbfs_header *cbfs_find_header(char *data, size_t size,
uint32_t forced_offset);
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
/* Returns the first cbfs_file entry in CBFS image by CBFS header (no matter if
* the entry has valid content or not), otherwise NULL. */
struct cbfs_file *cbfs_find_first_entry(struct cbfs_image *image);
/* Returns next cbfs_file entry (no matter if its content is valid or not), or
* NULL on failure. */
struct cbfs_file *cbfs_find_next_entry(struct cbfs_image *image,
struct cbfs_file *entry);
/* Returns ROM address (offset) of entry.
* This is different from entry->offset (pointer to content). */
uint32_t cbfs_get_entry_addr(struct cbfs_image *image, struct cbfs_file *entry);
cbfstool: New image format w/ required FMAP and w/o CBFS master header 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-03-18 20:36:27 +01:00
/* Returns 1 if valid new-format CBFS (without a master header), otherwise 0. */
int cbfs_is_valid_cbfs(struct cbfs_image *image);
/* Returns 1 if valid legacy CBFS (with a master header), otherwise 0. */
int cbfs_is_legacy_cbfs(struct cbfs_image *image);
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
/* Returns 1 if entry has valid data (by checking magic number), otherwise 0. */
cbfstool: Fix crash on image without bootblock in end of ROM. On platforms with CBFS data filling end of ROM image without bootblock in the end (ex, ARM), calculation of "next valid entry" may exceed ROM image buffer in memory and raise segmentation fault when we try to compare its magic value. To fix this, always check if the entry address is inside ROM image buffer. Verified to build and boot successfully on qemu/x86 and armv7/snow. Change-Id: I117d6767a5403be636eea2b23be1dcf2e1c88839 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2330 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-09 03:38:55 +01:00
int cbfs_is_valid_entry(struct cbfs_image *image, struct cbfs_file *entry);
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
cbfstool: Use cbfs_image API for "print" command. Process CBFS ROM image by new cbfs_image API. To verify, run "cbfstool coreboot.rom print -v" and compare with old cbfstool. Change-Id: I3a5a9ef176596d825e6cdba28a8ad732f69f5600 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2206 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:15:49 +01:00
/* Print CBFS component information. */
int cbfs_print_directory(struct cbfs_image *image);
util/cbfstool: add machine parseable print In order to more easily process the output of 'cbfstool print' with other tools provide a -k option which spits out the tab-separated header and fields: Name Offset Type Metadata Size Data Size Total Size ALIGN_UP(Offset + Total Size, 64) would be the start of the next entry. Also, one can analzye the overhead and offsets of each file more easily. Example output (note: tabs aren't in here): $ ./coreboot-builds/sharedutils/cbfstool/cbfstool test.serial.bin print -r FW_MAIN_A -k Performing operation on 'FW_MAIN_A' region... Name Offset Type Metadata Size Data Size Total Size cmos_layout.bin 0x0 cmos_layout 0x38 0x48c 0x4c4 dmic-2ch-48khz-16b.bin 0x500 raw 0x48 0xb68 0xbb0 dmic-2ch-48khz-32b.bin 0x10c0 raw 0x48 0xb68 0xbb0 nau88l25-2ch-48khz-24b.bin 0x1c80 raw 0x48 0x54 0x9c ssm4567-render-2ch-48khz-24b.bin 0x1d40 raw 0x58 0x54 0xac ssm4567-capture-4ch-48khz-32b.bin 0x1e00 raw 0x58 0x54 0xac vbt.bin 0x1ec0 optionrom 0x38 0x1000 0x1038 spd.bin 0x2f00 spd 0x38 0x600 0x638 config 0x3540 raw 0x38 0x1ab7 0x1aef revision 0x5040 raw 0x38 0x25e 0x296 font.bin 0x5300 raw 0x38 0x77f 0x7b7 vbgfx.bin 0x5ac0 raw 0x38 0x32f8 0x3330 locales 0x8e00 raw 0x28 0x2 0x2a locale_en.bin 0x8e40 raw 0x38 0x29f6 0x2a2e u-boot.dtb 0xb880 mrc_cache 0x38 0xff1 0x1029 (empty) 0xc8c0 null 0x64 0xadf4 0xae58 fallback/ramstage 0x17740 stage 0x38 0x15238 0x15270 (empty) 0x2c9c0 null 0x64 0xd2c4 0xd328 fallback/payload 0x39d00 payload 0x38 0x12245 0x1227d cpu_microcode_blob.bin 0x4bf80 microcode 0x60 0x17000 0x17060 (empty) 0x63000 null 0x28 0x37cf98 0x37cfc0 Change-Id: I1c5f8c1b5f2f980033d6c954c9840299c6268431 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13475 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-26 22:35:34 +01:00
int cbfs_print_parseable_directory(struct cbfs_image *image);
cbfstool: Use cbfs_image API for "print" command. Process CBFS ROM image by new cbfs_image API. To verify, run "cbfstool coreboot.rom print -v" and compare with old cbfstool. Change-Id: I3a5a9ef176596d825e6cdba28a8ad732f69f5600 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2206 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:15:49 +01:00
int cbfs_print_header_info(struct cbfs_image *image);
int cbfs_print_entry_info(struct cbfs_image *image, struct cbfs_file *entry,
void *arg);
cbfstool: Use cbfs_image API for "locate" command. To support platforms without top-aligned address mapping like ARM, "locate" command now outputs platform independent ROM offset by default. To retrieve x86 style top-aligned virtual address, add "-T". To test: cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T # Example output: 0xffffdc10 Change-Id: I474703c4197b36524b75407a91faab1194edc64d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2213 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:46:02 +01:00
/* Merge empty entries starting from given entry.
* Returns 0 on success, otherwise non-zero. */
int cbfs_merge_empty_entry(struct cbfs_image *image, struct cbfs_file *entry,
void *arg);
cbfstool: expose cbfs_calculate_file_header_size() Headers vary in size soon, and more places need to be able to calculate their size. Change-Id: I30761bb9da0756418993dee21d8fa18cf3174c40 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/11214 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-11 15:10:02 +02:00
/* Returns the size of a cbfs file header with no extensions */
size_t cbfs_calculate_file_header_size(const char *name);
cbfstool: add extended file attributes for cbfs_file cbfs_file_first_attr(struct cbfs_file *) and cbfs_file_next_attr(struct cbfs_file *, struct cbfs_file_attribute *) help navigate through extended attributes. cbfs_add_file_attr(header, tag, size) adds a new file attribute to header. Change-Id: I325965286c44f31abd95df684d340cebb0e68b75 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10934 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-15 20:49:00 +02:00
/* Given a cbfs_file, return the first file attribute, or NULL. */
struct cbfs_file_attribute *cbfs_file_first_attr(struct cbfs_file *file);
/* Given a cbfs_file and a cbfs_file_attribute, return the attribute that
* follows it, or NULL. */
struct cbfs_file_attribute *cbfs_file_next_attr(struct cbfs_file *file,
struct cbfs_file_attribute *attr);
/* Adds to header a new extended attribute tagged 'tag', sized 'size'.
* Returns pointer to the new attribute, or NULL on error. */
struct cbfs_file_attribute *cbfs_add_file_attr(struct cbfs_file *header,
uint32_t tag,
uint32_t size);
cbfstool: Add support for hashes as file metadata They allow optimizing a verification of a whole CBFS image by only dealing with the headers (assuming you choose to trust the hash algorithm(s)). The format allows for multiple hashes for a single file, and cbfstool can handle them, but right now it can't generate such headers. Loosely based on Sol's work in http://review.coreboot.org/#/c/10147/, but using the compatible file attribute format. vboot is now a hard dependency of the build process, but we import it into the tree for quite a while now. Change-Id: I9f14f30537d676ce209ad612e7327c6f4810b313 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/11767 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-01 15:54:04 +02:00
/* Adds an extended attribute to header, containing a hash of buffer's data of
* the type specified by hash_type.
* Returns 0 on success, -1 on error. */
int cbfs_add_file_hash(struct cbfs_file *header, struct buffer *buffer,
enum vb2_hash_algorithm hash_type);
cbfstool: Add cbfs_image new CBFS image manipulation API. Current cbfstool implementation is relying on global variables to pass processed data, and the calculation of address is based on x86 architecture (ex, always assuming 0x0000 as invalid address), not easy to be used on platforms without top-aligned memory mapping. This CL is a first step to start a new cbfstool without global variables, and to prevent assuming memory layout in x86 mode. The first published APIs are for reading and writing existing CBFS ROM image files (and to find file entries in a ROM file). Read cbfs_image.h for detail usage of each API function. Change-Id: I28c737c8f290e51332119188248ac9e28042024c Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2194 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 18:56:17 +01:00
#endif