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

1114 lines
35 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.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
*/
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
#include <inttypes.h>
#include <libgen.h>
cbfstool: compare pointer difference with ptrdiff_t value Fixes building cbfstool in 32bit environments. Change-Id: I3c94afc9c961eb8b41d1e08f4a16e5cab2a6bb8b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/10015 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-28 13:09:36 +02:00
#include <stddef.h>
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
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
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
#include <strings.h>
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
#include "common.h"
#include "cbfs_image.h"
cbfstool: Make the add action choose an aligned entries capacity This fixes an inconsistency between `cbfstool create` and `cbfstool add` that was resulting in confusing claims about the amount of free space at the end of a CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file entry by testing whether it would collide with the beginning of the *subsequent* file header; thus, if a file's end is unaligned, its reported size will not match the actual available capacity. Although deleted entries always end on an alignment boundary because `cbfstool remove` expands them to fill the available space, `cbfstool create` doesn't necessarily size a new entries region to result in an empty entry with an aligned end. This problem never resulted in clobbering important data because cbfstool would blindly reserve 64B (or the selected alignment) of free space immediately after the all-inclusive empty file entry. This change alters the way this reservation is reported: only the overhang past the alignment is used as hidden padding, and the empty entry's capacity is always reported such that it ends at an aligned address. Much of the time that went into this patch was spent building trust in the trickery cbfstool employs to avoid explicitly tracking the image's total capacity for entries, so below are two proofs of correctness to save others time and discourage inadvertent breakage: OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS empty file header is small enough that it won't cross another aligned address. OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such that its contents end on an aligned address. THM. 1: Placing a new file within an empty entry located below an existing file entry will never leave an aligned flash address containing neither the beginning of a file header nor part of a file. We can prove this by contradiction: assume a newly-added file neither fills to the end of the preexisting empty entry nor leaves room for another aligned empty header after it. Then the first aligned address after the end of the newly-inserted file... - CASE 1: ...already contains a preexisting file entry header. + Then that address contains a file header. - CASE 2: ...does not already house a file entry header. + Then because CBFS content doesn't fall outside headers, the area between there and the *next* aligned address after that is unused. + By (A), we can fit a file header without clobbering anything. + Then that address now contains a file header. THM. 2: Placing a new file in an empty entry at the very end of the image such that it fits, but leaves no room for a final header, is guaranteed not to change the total amount of space for entries, even if that new file is later removed from the CBFS. Again, we use contradiction: assume that creating such a file causes a permanent... - CASE 1: ...increase in the amount of available space. + Then the combination of the inserted file, its header, and any padding must have exceeded the empty entry in size enough for it to cross at least one additional aligned address, since aligned addresses are how the limit on an entry's capacity is determined. + But adding the file couldn't have caused us to write past any further aligned addresses because they are the boundary's used when verifying that sufficient capacity exists; furthermore, by (B), no entry can ever terminate beyond where the initial empty entry did when the CBFS was first created. + Then the creation of the file did not result in a space increase. - CASE 2: ...decrease in the amount of available space. + Then the end of the new file entry crosses at least one fewer aligned address than did the empty file entry. + Then by (A), there is room to place a new file entry that describes the remaining available space at the first available aligned address. + Then there is now a new record showing the same amount of available space. + Then the creation of the file did not result in a space decrease. BUG=chromium:473726 TEST=Had the following conversation with cbfstool: $ ./cbfstool test.image create -s 0x100000 -m arm Created CBFS image (capacity = 1048408 bytes) $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 null 1048408 $ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1 1+0 records in 1+0 records out 1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big? E: Failed to add 'toobigmed.bin' into ROM image. $ truncate -s -1 toobigmed.bin $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size toobig 0x40 raw 1048408 $ ./cbfstool test.image remove -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 BRANCH=None Change-Id: I118743e37469ef0226970decc900db5d9b92c5df Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/263962 Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/9939 Tested-by: build bot (Jenkins)
2015-04-03 18:13:04 +02:00
/* Even though the file-adding functions---cbfs_add_entry() and
* cbfs_add_entry_at()---perform their sizing checks against the beginning of
* the subsequent section rather than a stable recorded value such as an empty
* file header's len field, it's possible to prove two interesting properties
* about their behavior:
* - Placing a new file within an empty entry located below an existing file
* entry will never leave an aligned flash address containing neither the
* beginning of a file header nor part of a file.
* - Placing a new file in an empty entry at the very end of the image such
* that it fits, but leaves no room for a final header, is guaranteed not to
* change the total amount of space for entries, even if that new file is
* later removed from the CBFS.
* These properties are somewhat nonobvious from the implementation, so the
* reader is encouraged to blame this comment and examine the full proofs
* in the commit message before making significant changes that would risk
* removing said guarantees.
*/
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
/* The file name align is not defined in CBFS spec -- only a preference by
* (old) cbfstool. */
#define CBFS_FILENAME_ALIGN (16)
/* To make CBFS more friendly to ROM, fill -1 (0xFF) instead of zero. */
#define CBFS_CONTENT_DEFAULT_VALUE (-1)
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
/* Type and format */
struct typedesc_t {
uint32_t type;
const char *name;
};
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
static const struct typedesc_t types_cbfs_entry[] = {
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
{CBFS_COMPONENT_STAGE, "stage"},
{CBFS_COMPONENT_PAYLOAD, "payload"},
{CBFS_COMPONENT_OPTIONROM, "optionrom"},
{CBFS_COMPONENT_BOOTSPLASH, "bootsplash"},
{CBFS_COMPONENT_RAW, "raw"},
{CBFS_COMPONENT_VSA, "vsa"},
{CBFS_COMPONENT_MBI, "mbi"},
{CBFS_COMPONENT_MICROCODE, "microcode"},
cbfstool: add filetypes for FSP, MRC, SPC and MRC_CACHE This adds a few new file types to cbfstool. Currently these files are being added using bare hex values in the coreboot makefiles. This patch is just to make the values official and to help get rid of some confusion in the values used within the makefiles. All of these new types are roughly equivalent to raw. Change-Id: I37c4180a247136cd98080f6f7609d3cf905a62f5 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/8977 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-24 22:54:20 +01:00
{CBFS_COMPONENT_FSP, "fsp"},
{CBFS_COMPONENT_MRC, "mrc"},
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
{CBFS_COMPONENT_CMOS_DEFAULT, "cmos_default"},
{CBFS_COMPONENT_CMOS_LAYOUT, "cmos_layout"},
cbfstool: add filetypes for FSP, MRC, SPC and MRC_CACHE This adds a few new file types to cbfstool. Currently these files are being added using bare hex values in the coreboot makefiles. This patch is just to make the values official and to help get rid of some confusion in the values used within the makefiles. All of these new types are roughly equivalent to raw. Change-Id: I37c4180a247136cd98080f6f7609d3cf905a62f5 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/8977 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-24 22:54:20 +01:00
{CBFS_COMPONENT_SPD, "spd"},
{CBFS_COMPONENT_MRC_CACHE, "mrc_cache"},
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
{CBFS_COMPONENT_DELETED, "deleted"},
{CBFS_COMPONENT_NULL, "null"},
{0, NULL},
};
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
static const struct typedesc_t types_cbfs_compression[] = {
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
{CBFS_COMPRESS_NONE, "none"},
{CBFS_COMPRESS_LZMA, "LZMA"},
{0, NULL},
};
cbfs: fix issues with word size and endianness. 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-12-03 20:13:35 +01:00
static const char *lookup_name_by_type(const struct typedesc_t *desc, uint32_t type,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
const char *default_value)
{
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 i;
for (i = 0; desc[i].name; i++)
if (desc[i].type == type)
return desc[i].name;
return default_value;
}
cbfstool: Clean up code 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>
2015-03-04 00:55:03 +01:00
static const char *get_cbfs_entry_type_name(uint32_t type)
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +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
return lookup_name_by_type(types_cbfs_entry, type, "(unknown)");
}
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
/* CBFS image */
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
static size_t cbfs_calculate_file_header_size(const char *name)
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +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
return (sizeof(struct cbfs_file) +
align_up(strlen(name) + 1, CBFS_FILENAME_ALIGN));
}
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
static int cbfs_fix_legacy_size(struct cbfs_image *image, char *hdr_loc)
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
{
cbfstool: Fix incorrect CBFS free space by old cbfstool. Old cbfstool may produce CBFS image with calculation error in size of last empty entry, and then corrupts master header data when you really use every bit in last entry. This fix will correct free space size when you load ROM images with cbfs_image_from_file. Change-Id: I2ada319728ef69ab9296ae446c77d37e05d05fce Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2211 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:16:20 +01:00
// A bug in old cbfstool may produce extra few bytes (by alignment) and
// cause cbfstool to overwrite things after free space -- which is
// usually CBFS header on x86. We need to workaround that.
struct cbfs_file *entry, *first = NULL, *last = NULL;
for (first = entry = cbfs_find_first_entry(image);
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
entry && cbfs_is_valid_entry(image, entry);
cbfstool: Fix incorrect CBFS free space by old cbfstool. Old cbfstool may produce CBFS image with calculation error in size of last empty entry, and then corrupts master header data when you really use every bit in last entry. This fix will correct free space size when you load ROM images with cbfs_image_from_file. Change-Id: I2ada319728ef69ab9296ae446c77d37e05d05fce Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2211 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:16:20 +01:00
entry = cbfs_find_next_entry(image, entry)) {
last = entry;
}
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
if ((char *)first < (char *)hdr_loc &&
(char *)entry > (char *)hdr_loc) {
cbfstool: Fix incorrect CBFS free space by old cbfstool. Old cbfstool may produce CBFS image with calculation error in size of last empty entry, and then corrupts master header data when you really use every bit in last entry. This fix will correct free space size when you load ROM images with cbfs_image_from_file. Change-Id: I2ada319728ef69ab9296ae446c77d37e05d05fce Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2211 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:16:20 +01:00
WARN("CBFS image was created with old cbfstool with size bug. "
"Fixing size in last entry...\n");
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
last->len = htonl(ntohl(last->len) - image->header->align);
cbfstool: Fix incorrect CBFS free space by old cbfstool. Old cbfstool may produce CBFS image with calculation error in size of last empty entry, and then corrupts master header data when you really use every bit in last entry. This fix will correct free space size when you load ROM images with cbfs_image_from_file. Change-Id: I2ada319728ef69ab9296ae446c77d37e05d05fce Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2211 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 20:16:20 +01:00
DEBUG("Last entry has been changed from 0x%x to 0x%x.\n",
cbfs_get_entry_addr(image, entry),
cbfs_get_entry_addr(image,
cbfs_find_next_entry(image, last)));
}
return 0;
}
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
void cbfs_put_header(void *dest, const struct cbfs_header *header)
{
struct buffer outheader;
outheader.data = dest;
outheader.size = 0;
xdr_be.put32(&outheader, header->magic);
xdr_be.put32(&outheader, header->version);
xdr_be.put32(&outheader, header->romsize);
xdr_be.put32(&outheader, header->bootblocksize);
xdr_be.put32(&outheader, header->align);
xdr_be.put32(&outheader, header->offset);
xdr_be.put32(&outheader, header->architecture);
}
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
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
static void cbfs_decode_payload_segment(struct cbfs_payload_segment *output,
struct cbfs_payload_segment *input)
{
struct buffer seg = {
.data = (void *)input,
.size = sizeof(*input),
};
output->type = xdr_be.get32(&seg);
output->compression = xdr_be.get32(&seg);
output->offset = xdr_be.get32(&seg);
output->load_addr = xdr_be.get64(&seg);
output->len = xdr_be.get32(&seg);
output->mem_len = xdr_be.get32(&seg);
assert(seg.size == 0);
}
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: 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
{
struct buffer outheader;
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
outheader.data = src; /* We're not modifying the data */
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
outheader.size = 0;
header->magic = xdr_be.get32(&outheader);
header->version = xdr_be.get32(&outheader);
header->romsize = xdr_be.get32(&outheader);
header->bootblocksize = xdr_be.get32(&outheader);
header->align = xdr_be.get32(&outheader);
header->offset = xdr_be.get32(&outheader);
header->architecture = xdr_be.get32(&outheader);
}
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
int cbfs_image_create(struct cbfs_image *image,
cbfstool: Clean up code 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>
2015-03-04 00:55:03 +01:00
uint32_t architecture,
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
size_t size,
uint32_t align,
struct buffer *bootblock,
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
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: 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
struct cbfs_header header;
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
struct cbfs_file *entry;
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
int32_t *rel_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
uint32_t cbfs_len;
cbfstool: Fix initial empty space in image creation. When calculating initial CBFS empty entry space, the size of header itself must be not included (with the reserved space for entry name). This is a regression of the old cbfstool size bug. Before this fix, in build process we see: OBJCOPY cbfs/fallback/romstage_null.bin W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... And checking the output binary: cbfstool build/coreboot.pre1 print -v -v DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes) DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30 W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00. coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64 Name Offset Type Size (empty) 0x0 null 261296 DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0 After this fix, no more alerts in build process. Verified to build successfully on x86/qemu and arm/snow configurations. Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2731 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15 10:40:08 +01:00
size_t entry_header_len;
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
void *header_loc;
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
DEBUG("cbfs_image_create: bootblock=0x%x+0x%zx, "
"header=0x%x+0x%zx, entries_offset=0x%x\n",
bootblock_offset, bootblock->size,
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
header_offset, sizeof(header), 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: Make the add action choose an aligned entries capacity This fixes an inconsistency between `cbfstool create` and `cbfstool add` that was resulting in confusing claims about the amount of free space at the end of a CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file entry by testing whether it would collide with the beginning of the *subsequent* file header; thus, if a file's end is unaligned, its reported size will not match the actual available capacity. Although deleted entries always end on an alignment boundary because `cbfstool remove` expands them to fill the available space, `cbfstool create` doesn't necessarily size a new entries region to result in an empty entry with an aligned end. This problem never resulted in clobbering important data because cbfstool would blindly reserve 64B (or the selected alignment) of free space immediately after the all-inclusive empty file entry. This change alters the way this reservation is reported: only the overhang past the alignment is used as hidden padding, and the empty entry's capacity is always reported such that it ends at an aligned address. Much of the time that went into this patch was spent building trust in the trickery cbfstool employs to avoid explicitly tracking the image's total capacity for entries, so below are two proofs of correctness to save others time and discourage inadvertent breakage: OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS empty file header is small enough that it won't cross another aligned address. OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such that its contents end on an aligned address. THM. 1: Placing a new file within an empty entry located below an existing file entry will never leave an aligned flash address containing neither the beginning of a file header nor part of a file. We can prove this by contradiction: assume a newly-added file neither fills to the end of the preexisting empty entry nor leaves room for another aligned empty header after it. Then the first aligned address after the end of the newly-inserted file... - CASE 1: ...already contains a preexisting file entry header. + Then that address contains a file header. - CASE 2: ...does not already house a file entry header. + Then because CBFS content doesn't fall outside headers, the area between there and the *next* aligned address after that is unused. + By (A), we can fit a file header without clobbering anything. + Then that address now contains a file header. THM. 2: Placing a new file in an empty entry at the very end of the image such that it fits, but leaves no room for a final header, is guaranteed not to change the total amount of space for entries, even if that new file is later removed from the CBFS. Again, we use contradiction: assume that creating such a file causes a permanent... - CASE 1: ...increase in the amount of available space. + Then the combination of the inserted file, its header, and any padding must have exceeded the empty entry in size enough for it to cross at least one additional aligned address, since aligned addresses are how the limit on an entry's capacity is determined. + But adding the file couldn't have caused us to write past any further aligned addresses because they are the boundary's used when verifying that sufficient capacity exists; furthermore, by (B), no entry can ever terminate beyond where the initial empty entry did when the CBFS was first created. + Then the creation of the file did not result in a space increase. - CASE 2: ...decrease in the amount of available space. + Then the end of the new file entry crosses at least one fewer aligned address than did the empty file entry. + Then by (A), there is room to place a new file entry that describes the remaining available space at the first available aligned address. + Then there is now a new record showing the same amount of available space. + Then the creation of the file did not result in a space decrease. BUG=chromium:473726 TEST=Had the following conversation with cbfstool: $ ./cbfstool test.image create -s 0x100000 -m arm Created CBFS image (capacity = 1048408 bytes) $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 null 1048408 $ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1 1+0 records in 1+0 records out 1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big? E: Failed to add 'toobigmed.bin' into ROM image. $ truncate -s -1 toobigmed.bin $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size toobig 0x40 raw 1048408 $ ./cbfstool test.image remove -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 BRANCH=None Change-Id: I118743e37469ef0226970decc900db5d9b92c5df Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/263962 Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/9939 Tested-by: build bot (Jenkins)
2015-04-03 18:13:04 +02:00
// This attribute must be given in order to prove that this module
// correctly preserves certain CBFS properties. See the block comment
// near the top of this file (and the associated commit message).
size_t empty_header_len = cbfs_calculate_file_header_size("");
if (align < empty_header_len) {
ERROR("CBFS must be aligned to at least %zu bytes\n",
empty_header_len);
return -1;
}
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
if (buffer_create(&image->buffer, size, "(new)") != 0)
return -1;
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
if ((image->header = malloc(sizeof(*image->header))) == NULL)
return -1;
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
memset(image->buffer.data, CBFS_CONTENT_DEFAULT_VALUE, size);
// Adjust legcay top-aligned address to ROM offset.
if (IS_TOP_ALIGNED_ADDRESS(entries_offset))
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
entries_offset = size + (int32_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
if (IS_TOP_ALIGNED_ADDRESS(bootblock_offset))
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
bootblock_offset = size + (int32_t)bootblock_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
if (IS_TOP_ALIGNED_ADDRESS(header_offset))
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
header_offset = size + (int32_t)header_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
DEBUG("cbfs_create_image: (real offset) bootblock=0x%x, "
"header=0x%x, entries_offset=0x%x\n",
bootblock_offset, header_offset, entries_offset);
// Prepare bootblock
if (bootblock_offset + bootblock->size > size) {
ERROR("Bootblock (0x%x+0x%zx) exceed ROM size (0x%zx)\n",
bootblock_offset, bootblock->size, size);
return -1;
}
armv7: Prevent CBFS data overlapping bootblock. For arm/snow, current bootblock is larger than previously assigned CBFS offset and will fail to boot. To prevent this happening again in future, cbfstool now checks if CBFS will overlap bootblock. A sample error message: E: Bootblock (0x0+0x71d4) overlap CBFS data (0x5000) E: Failed to create build/coreboot.pre1.tmp. arm/snow offset is also enlarged and moved to Kconfig variable. Change-Id: I4556aef27ff716556040312ae8ccb78078abc82d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2295 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-06 05:41:49 +01:00
if (entries_offset > bootblock_offset &&
entries_offset < bootblock->size) {
ERROR("Bootblock (0x%x+0x%zx) overlap CBFS data (0x%x)\n",
bootblock_offset, bootblock->size, entries_offset);
return -1;
}
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
memcpy(image->buffer.data + bootblock_offset, bootblock->data,
bootblock->size);
// Prepare header
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
if (header_offset + sizeof(header) > size - sizeof(int32_t)) {
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
ERROR("Header (0x%x+0x%zx) exceed ROM size (0x%zx)\n",
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
header_offset, sizeof(header), 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
return -1;
}
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
image->header->magic = CBFS_HEADER_MAGIC;
image->header->version = CBFS_HEADER_VERSION;
image->header->romsize = size;
image->header->bootblocksize = bootblock->size;
image->header->align = align;
image->header->offset = entries_offset;
cbfstool: Clean up code 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>
2015-03-04 00:55:03 +01:00
image->header->architecture = architecture;
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
header_loc = (image->buffer.data + header_offset);
cbfs_put_header(header_loc, image->header);
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
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
// The last 4 byte of the image contain the relative offset from the end
// of the image to the master header as a 32-bit signed integer. x86
// relies on this also being its (memory-mapped, top-aligned) absolute
// 32-bit address by virtue of how two's complement numbers work.
assert(size % sizeof(int32_t) == 0);
rel_offset = (int32_t *)(image->buffer.data + size - sizeof(int32_t));
*rel_offset = header_offset - 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
// Prepare entries
if (align_up(entries_offset, align) != entries_offset) {
ERROR("Offset (0x%x) must be aligned to 0x%x.\n",
entries_offset, align);
return -1;
}
cbfstool: Fix initial empty space in image creation. When calculating initial CBFS empty entry space, the size of header itself must be not included (with the reserved space for entry name). This is a regression of the old cbfstool size bug. Before this fix, in build process we see: OBJCOPY cbfs/fallback/romstage_null.bin W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... And checking the output binary: cbfstool build/coreboot.pre1 print -v -v DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes) DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30 W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00. coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64 Name Offset Type Size (empty) 0x0 null 261296 DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0 After this fix, no more alerts in build process. Verified to build successfully on x86/qemu and arm/snow configurations. Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2731 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15 10:40:08 +01:00
entry_header_len = cbfs_calculate_file_header_size("");
if (entries_offset + entry_header_len > 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
ERROR("Offset (0x%x+0x%zx) exceed ROM size(0x%zx)\n",
cbfstool: Fix initial empty space in image creation. When calculating initial CBFS empty entry space, the size of header itself must be not included (with the reserved space for entry name). This is a regression of the old cbfstool size bug. Before this fix, in build process we see: OBJCOPY cbfs/fallback/romstage_null.bin W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... And checking the output binary: cbfstool build/coreboot.pre1 print -v -v DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes) DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30 W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00. coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64 Name Offset Type Size (empty) 0x0 null 261296 DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0 After this fix, no more alerts in build process. Verified to build successfully on x86/qemu and arm/snow configurations. Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2731 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15 10:40:08 +01:00
entries_offset, entry_header_len, 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
return -1;
}
entry = (struct cbfs_file *)(image->buffer.data + entries_offset);
// To calculate available length, find
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
// e = min(bootblock, header, rel_offset) where e > entries_offset.
cbfs_len = size - sizeof(int32_t);
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
if (bootblock_offset > entries_offset && bootblock_offset < cbfs_len)
cbfs_len = bootblock_offset;
if (header_offset > entries_offset && header_offset < cbfs_len)
cbfs_len = header_offset;
cbfstool: Make the add action choose an aligned entries capacity This fixes an inconsistency between `cbfstool create` and `cbfstool add` that was resulting in confusing claims about the amount of free space at the end of a CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file entry by testing whether it would collide with the beginning of the *subsequent* file header; thus, if a file's end is unaligned, its reported size will not match the actual available capacity. Although deleted entries always end on an alignment boundary because `cbfstool remove` expands them to fill the available space, `cbfstool create` doesn't necessarily size a new entries region to result in an empty entry with an aligned end. This problem never resulted in clobbering important data because cbfstool would blindly reserve 64B (or the selected alignment) of free space immediately after the all-inclusive empty file entry. This change alters the way this reservation is reported: only the overhang past the alignment is used as hidden padding, and the empty entry's capacity is always reported such that it ends at an aligned address. Much of the time that went into this patch was spent building trust in the trickery cbfstool employs to avoid explicitly tracking the image's total capacity for entries, so below are two proofs of correctness to save others time and discourage inadvertent breakage: OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS empty file header is small enough that it won't cross another aligned address. OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such that its contents end on an aligned address. THM. 1: Placing a new file within an empty entry located below an existing file entry will never leave an aligned flash address containing neither the beginning of a file header nor part of a file. We can prove this by contradiction: assume a newly-added file neither fills to the end of the preexisting empty entry nor leaves room for another aligned empty header after it. Then the first aligned address after the end of the newly-inserted file... - CASE 1: ...already contains a preexisting file entry header. + Then that address contains a file header. - CASE 2: ...does not already house a file entry header. + Then because CBFS content doesn't fall outside headers, the area between there and the *next* aligned address after that is unused. + By (A), we can fit a file header without clobbering anything. + Then that address now contains a file header. THM. 2: Placing a new file in an empty entry at the very end of the image such that it fits, but leaves no room for a final header, is guaranteed not to change the total amount of space for entries, even if that new file is later removed from the CBFS. Again, we use contradiction: assume that creating such a file causes a permanent... - CASE 1: ...increase in the amount of available space. + Then the combination of the inserted file, its header, and any padding must have exceeded the empty entry in size enough for it to cross at least one additional aligned address, since aligned addresses are how the limit on an entry's capacity is determined. + But adding the file couldn't have caused us to write past any further aligned addresses because they are the boundary's used when verifying that sufficient capacity exists; furthermore, by (B), no entry can ever terminate beyond where the initial empty entry did when the CBFS was first created. + Then the creation of the file did not result in a space increase. - CASE 2: ...decrease in the amount of available space. + Then the end of the new file entry crosses at least one fewer aligned address than did the empty file entry. + Then by (A), there is room to place a new file entry that describes the remaining available space at the first available aligned address. + Then there is now a new record showing the same amount of available space. + Then the creation of the file did not result in a space decrease. BUG=chromium:473726 TEST=Had the following conversation with cbfstool: $ ./cbfstool test.image create -s 0x100000 -m arm Created CBFS image (capacity = 1048408 bytes) $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 null 1048408 $ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1 1+0 records in 1+0 records out 1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big? E: Failed to add 'toobigmed.bin' into ROM image. $ truncate -s -1 toobigmed.bin $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size toobig 0x40 raw 1048408 $ ./cbfstool test.image remove -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 BRANCH=None Change-Id: I118743e37469ef0226970decc900db5d9b92c5df Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/263962 Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/9939 Tested-by: build bot (Jenkins)
2015-04-03 18:13:04 +02:00
// This alignment is necessary in order to prove that this module
// correctly preserves certain CBFS properties. See the block comment
// near the top of this file (and the associated commit message).
cbfs_len -= cbfs_len % align;
cbfs_len -= entries_offset + entry_header_len;
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(entry, cbfs_len, "");
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
LOG("Created CBFS image (capacity = %d bytes)\n", cbfs_len);
return 0;
}
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
int cbfs_image_from_file(struct cbfs_image *image,
const char *filename, uint32_t offset)
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
{
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
void *header_loc;
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
if (buffer_from_file(&image->buffer, filename) != 0)
return -1;
DEBUG("read_cbfs_image: %s (%zd bytes)\n", image->buffer.name,
image->buffer.size);
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
header_loc = cbfs_find_header(image->buffer.data,
image->buffer.size,
offset);
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
if (!header_loc) {
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
ERROR("%s does not have CBFS master header.\n", filename);
cbfs_image_delete(image);
return -1;
}
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
if ((image->header = malloc(sizeof(*image->header))) == NULL)
return -1;
cbfs_get_header(image->header, header_loc);
cbfs_fix_legacy_size(image, header_loc);
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
return 0;
}
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
int cbfs_copy_instance(struct cbfs_image *image, size_t copy_offset,
size_t copy_size)
{
struct cbfs_file *src_entry, *dst_entry;
struct cbfs_header *copy_header;
size_t align, entry_offset;
ssize_t last_entry_size;
size_t header_offset, header_end;
size_t cbfs_offset, cbfs_end;
size_t copy_end = copy_offset + copy_size;
align = htonl(image->header->align);
header_offset = (char *)image->header - image->buffer.data;
header_end = header_offset + sizeof(image->header);
cbfs_offset = htonl(image->header->offset);
cbfs_end = htonl(image->header->romsize);
if (copy_end > image->buffer.size) {
ERROR("Copy offset out of range: [%zx:%zx)\n",
copy_offset, copy_end);
return 1;
}
/* Range check requested copy region with header and source cbfs. */
if ((copy_offset >= header_offset && copy_offset < header_end) ||
(copy_end >= header_offset && copy_end <= header_end)) {
ERROR("New image would overlap old header.\n");
}
if ((copy_offset >= cbfs_offset && copy_offset < cbfs_end) ||
(copy_end >= cbfs_offset && copy_end <= cbfs_end)) {
ERROR("New image would overlap old one.\n");
return 1;
}
/* This will work, let's create a copy. */
copy_header = (struct cbfs_header *)(image->buffer.data + copy_offset);
*copy_header = *image->header;
copy_header->bootblocksize = 0;
/* Romsize is a misnomer. It's the absolute limit of cbfs content.*/
copy_header->romsize = htonl(copy_end);
entry_offset = align_up(copy_offset + sizeof(*copy_header), align);
copy_header->offset = htonl(entry_offset);
dst_entry = (struct cbfs_file *)(image->buffer.data + entry_offset);
/* Copy non-empty files */
for (src_entry = cbfs_find_first_entry(image);
src_entry && cbfs_is_valid_entry(image, src_entry);
src_entry = cbfs_find_next_entry(image, src_entry)) {
size_t entry_size;
if ((src_entry->type == htonl(CBFS_COMPONENT_NULL)) ||
(src_entry->type == htonl(CBFS_COMPONENT_DELETED)))
continue;
entry_size = htonl(src_entry->len) + htonl(src_entry->offset);
memcpy(dst_entry, src_entry, entry_size);
dst_entry = (struct cbfs_file *)(
(uintptr_t)dst_entry + align_up(entry_size, align));
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
if ((size_t)((char *)dst_entry - image->buffer.data) >=
copy_end) {
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
ERROR("Ran out of room in copy region.\n");
return 1;
}
}
/* Last entry size is all the room above it. */
last_entry_size = copy_end - ((char *)dst_entry - image->buffer.data)
- cbfs_calculate_file_header_size("");
if (last_entry_size < 0)
WARN("No room to create the last entry!\n")
else
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(dst_entry, last_entry_size, "");
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
return 0;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
int cbfs_image_write_file(struct cbfs_image *image, const char *filename)
{
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
assert(image && image->buffer.data);
return buffer_write_file(&image->buffer, filename);
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
int cbfs_image_delete(struct cbfs_image *image)
{
util/cbfstool: Make cbfs_image_delete() NULL-tolerant. This fixes a double free crash that occurs when a call to cbfs_image_from_file() fails in cbfs_extract() and falls though to cbfs_image_delete() with a NULL-pointer. To reproduce the crash pass the following arguments where the files passed, in fact, do not exist. As follows: ./cbfstool build/coreboot.rom extract -n config -f /tmp/config.txt Change-Id: I2213ff175d0703705a0ec10271b30bb26b6f8d0a Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5353 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-08 14:05:18 +01:00
if (image == NULL)
return 0;
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
buffer_delete(&image->buffer);
image->header = NULL;
return 0;
}
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
/* Tries to add an entry with its data (CBFS_SUBHEADER) at given offset. */
static int cbfs_add_entry_at(struct cbfs_image *image,
struct cbfs_file *entry,
uint32_t size,
const char *name,
uint32_t type,
const void *data,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
uint32_t content_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
struct cbfs_file *next = cbfs_find_next_entry(image, entry);
uint32_t addr = cbfs_get_entry_addr(image, entry),
addr_next = cbfs_get_entry_addr(image, next);
uint32_t header_size = cbfs_calculate_file_header_size(name),
min_entry_size = cbfs_calculate_file_header_size("");
uint32_t len, target;
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
uint32_t align = image->header->align;
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
target = content_offset - header_size;
if (target % align)
target -= target % align;
if (target < addr) {
ERROR("No space to hold cbfs_file header.");
return -1;
}
// Process buffer BEFORE content_offset.
if (target - addr > min_entry_size) {
DEBUG("|min|...|header|content|... <create new entry>\n");
len = target - addr - min_entry_size;
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(entry, len, "");
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
if (verbose > 1) cbfs_print_entry_info(image, entry, stderr);
entry = cbfs_find_next_entry(image, entry);
addr = cbfs_get_entry_addr(image, entry);
}
len = size + (content_offset - addr - header_size);
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(entry, len, name);
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
if (len != size) {
DEBUG("|..|header|content|... <use offset to create entry>\n");
DEBUG("before: offset=0x%x, len=0x%x\n",
ntohl(entry->offset), ntohl(entry->len));
// TODO reset expanded name buffer to 0xFF.
entry->offset = htonl(ntohl(entry->offset) + (len - size));
entry->len = htonl(size);
DEBUG("after: offset=0x%x, len=0x%x\n",
ntohl(entry->offset), ntohl(entry->len));
}
// Ready to fill data into entry.
assert(ntohl(entry->len) == size);
entry->type = htonl(type);
DEBUG("content_offset: 0x%x, entry location: %x\n",
content_offset, (int)((char*)CBFS_SUBHEADER(entry) -
image->buffer.data));
assert((char*)CBFS_SUBHEADER(entry) - image->buffer.data ==
cbfstool: compare pointer difference with ptrdiff_t value Fixes building cbfstool in 32bit environments. Change-Id: I3c94afc9c961eb8b41d1e08f4a16e5cab2a6bb8b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/10015 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-28 13:09:36 +02:00
(ptrdiff_t)content_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
memcpy(CBFS_SUBHEADER(entry), data, size);
if (verbose > 1) cbfs_print_entry_info(image, entry, stderr);
// Process buffer AFTER entry.
entry = cbfs_find_next_entry(image, entry);
addr = cbfs_get_entry_addr(image, entry);
cbfstool: Fix ability to add files at offsets near the end of empty spaces Because cbfs_add_entry_at() previously *assumed* it would have to create a trailing empty entry, it was impossible to add files at exact offsets close enough to the end of an existing empty entry that they occupied the remainder of its space. This addresses the problem by skipping the step of creating the trailing empty entry if doing so would place it at the start offset of whatever already followed the original empty section. BUG=chromium:473511 TEST=Run the following commands: $ ./cbfstool test.image create -s 0x100000 -m arm $ dd if=/dev/zero of=twok.bin bs=1 count=2048 $ ./cbfstool test.image add -t 0x50 -f twok.bin -n at_end -b 0xff7c0 $ ./cbfstool test.image add -t 0x50 -f twok.bin -n near_end -b 0xfef80 $ ./cbfstool test.image print There shouldn't be any assertions, and the output should be: test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 null 1044184 near_end 0xfef40 raw 2048 at_end 0xff780 raw 2048 BRANCH=None Change-Id: Ic8a6c3dfa4f82346a067c0804afb6c5a5e89e6c8 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 1bbd353fddc818f725e488e8f2fb6e967033539d Original-Change-Id: I15d25df80787a8e34c2237262681720203509c72 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/263809 Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/9938 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-03 05:58:26 +02:00
if (addr == addr_next)
return 0;
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: Fix ability to add files at offsets near the end of empty spaces Because cbfs_add_entry_at() previously *assumed* it would have to create a trailing empty entry, it was impossible to add files at exact offsets close enough to the end of an existing empty entry that they occupied the remainder of its space. This addresses the problem by skipping the step of creating the trailing empty entry if doing so would place it at the start offset of whatever already followed the original empty section. BUG=chromium:473511 TEST=Run the following commands: $ ./cbfstool test.image create -s 0x100000 -m arm $ dd if=/dev/zero of=twok.bin bs=1 count=2048 $ ./cbfstool test.image add -t 0x50 -f twok.bin -n at_end -b 0xff7c0 $ ./cbfstool test.image add -t 0x50 -f twok.bin -n near_end -b 0xfef80 $ ./cbfstool test.image print There shouldn't be any assertions, and the output should be: test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 null 1044184 near_end 0xfef40 raw 2048 at_end 0xff780 raw 2048 BRANCH=None Change-Id: Ic8a6c3dfa4f82346a067c0804afb6c5a5e89e6c8 Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: 1bbd353fddc818f725e488e8f2fb6e967033539d Original-Change-Id: I15d25df80787a8e34c2237262681720203509c72 Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/263809 Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/9938 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-03 05:58:26 +02:00
assert(addr < addr_next);
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
if (addr_next - addr < min_entry_size) {
cbfstool: Make the add action choose an aligned entries capacity This fixes an inconsistency between `cbfstool create` and `cbfstool add` that was resulting in confusing claims about the amount of free space at the end of a CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file entry by testing whether it would collide with the beginning of the *subsequent* file header; thus, if a file's end is unaligned, its reported size will not match the actual available capacity. Although deleted entries always end on an alignment boundary because `cbfstool remove` expands them to fill the available space, `cbfstool create` doesn't necessarily size a new entries region to result in an empty entry with an aligned end. This problem never resulted in clobbering important data because cbfstool would blindly reserve 64B (or the selected alignment) of free space immediately after the all-inclusive empty file entry. This change alters the way this reservation is reported: only the overhang past the alignment is used as hidden padding, and the empty entry's capacity is always reported such that it ends at an aligned address. Much of the time that went into this patch was spent building trust in the trickery cbfstool employs to avoid explicitly tracking the image's total capacity for entries, so below are two proofs of correctness to save others time and discourage inadvertent breakage: OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS empty file header is small enough that it won't cross another aligned address. OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such that its contents end on an aligned address. THM. 1: Placing a new file within an empty entry located below an existing file entry will never leave an aligned flash address containing neither the beginning of a file header nor part of a file. We can prove this by contradiction: assume a newly-added file neither fills to the end of the preexisting empty entry nor leaves room for another aligned empty header after it. Then the first aligned address after the end of the newly-inserted file... - CASE 1: ...already contains a preexisting file entry header. + Then that address contains a file header. - CASE 2: ...does not already house a file entry header. + Then because CBFS content doesn't fall outside headers, the area between there and the *next* aligned address after that is unused. + By (A), we can fit a file header without clobbering anything. + Then that address now contains a file header. THM. 2: Placing a new file in an empty entry at the very end of the image such that it fits, but leaves no room for a final header, is guaranteed not to change the total amount of space for entries, even if that new file is later removed from the CBFS. Again, we use contradiction: assume that creating such a file causes a permanent... - CASE 1: ...increase in the amount of available space. + Then the combination of the inserted file, its header, and any padding must have exceeded the empty entry in size enough for it to cross at least one additional aligned address, since aligned addresses are how the limit on an entry's capacity is determined. + But adding the file couldn't have caused us to write past any further aligned addresses because they are the boundary's used when verifying that sufficient capacity exists; furthermore, by (B), no entry can ever terminate beyond where the initial empty entry did when the CBFS was first created. + Then the creation of the file did not result in a space increase. - CASE 2: ...decrease in the amount of available space. + Then the end of the new file entry crosses at least one fewer aligned address than did the empty file entry. + Then by (A), there is room to place a new file entry that describes the remaining available space at the first available aligned address. + Then there is now a new record showing the same amount of available space. + Then the creation of the file did not result in a space decrease. BUG=chromium:473726 TEST=Had the following conversation with cbfstool: $ ./cbfstool test.image create -s 0x100000 -m arm Created CBFS image (capacity = 1048408 bytes) $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 null 1048408 $ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1 1+0 records in 1+0 records out 1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big? E: Failed to add 'toobigmed.bin' into ROM image. $ truncate -s -1 toobigmed.bin $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size toobig 0x40 raw 1048408 $ ./cbfstool test.image remove -n toobig $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 $ ./cbfstool test.image print test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40 alignment: 64 bytes, architecture: arm Name Offset Type Size (empty) 0x40 deleted 1048408 BRANCH=None Change-Id: I118743e37469ef0226970decc900db5d9b92c5df Signed-off-by: Sol Boucher <solb@chromium.org> Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc Original-Signed-off-by: Sol Boucher <solb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/263962 Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/9939 Tested-by: build bot (Jenkins)
2015-04-03 18:13:04 +02:00
DEBUG("No need for new \"empty\" entry\n");
/* No need to increase the size of the just
* stored file to extend to next file. Alignment
* of next file takes care of this.
*/
return 0;
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
}
len = addr_next - addr - min_entry_size;
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(entry, len, "");
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
if (verbose > 1) cbfs_print_entry_info(image, entry, stderr);
return 0;
}
int cbfs_add_entry(struct cbfs_image *image, struct buffer *buffer,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
const char *name, uint32_t type, uint32_t content_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
uint32_t entry_type;
uint32_t addr, addr_next;
struct cbfs_file *entry, *next;
uint32_t header_size, need_size, new_size;
header_size = cbfs_calculate_file_header_size(name);
need_size = header_size + buffer->size;
DEBUG("cbfs_add_entry('%s'@0x%x) => need_size = %u+%zu=%u\n",
name, content_offset, header_size, buffer->size, need_size);
if (IS_TOP_ALIGNED_ADDRESS(content_offset)) {
// legacy cbfstool takes top-aligned address.
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
uint32_t theromsize = image->header->romsize;
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
INFO("Converting top-aligned address 0x%x to offset: 0x%x\n",
cbfs: fix issues with word size and endianness. 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-12-03 20:13:35 +01:00
content_offset, content_offset + theromsize);
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
content_offset = theromsize + (int32_t)content_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
}
// Merge empty entries.
DEBUG("(trying to merge empty entries...)\n");
cbfs_walk(image, cbfs_merge_empty_entry, NULL);
for (entry = cbfs_find_first_entry(image);
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
entry && cbfs_is_valid_entry(image, entry);
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
entry = cbfs_find_next_entry(image, entry)) {
entry_type = ntohl(entry->type);
if (entry_type != CBFS_COMPONENT_NULL)
continue;
addr = cbfs_get_entry_addr(image, entry);
next = cbfs_find_next_entry(image, entry);
addr_next = cbfs_get_entry_addr(image, next);
DEBUG("cbfs_add_entry: space at 0x%x+0x%x(%d) bytes\n",
addr, addr_next - addr, addr_next - addr);
cbfstool: correct size left calculation for "empty" entries After removing a file sandwiched between two other files, that file could no longer be re-added at the same location. cbfstool tried to add the file, and a new "empty" entry, which, together, would no longer fit, so it continued checking for the next available space. Change the behavior to add the file if there is enough space for the file alone, then only add the "empty" entry if there is enough space for it. Change-Id: Iad3897dd28cf12f12ae877cfd83e1990fa7d2f0f Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4772 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-01-21 22:28:38 +01:00
/* Will the file fit? Don't yet worry if we have space for a new
* "empty" entry. We take care of that later.
*/
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
if (addr + need_size > addr_next)
continue;
// Can we simply put object here?
if (!content_offset || content_offset == addr + header_size) {
DEBUG("Filling new entry data (%zd bytes).\n",
buffer->size);
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(entry, buffer->size, name);
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
entry->type = htonl(type);
memcpy(CBFS_SUBHEADER(entry), buffer->data, buffer->size);
if (verbose)
cbfs_print_entry_info(image, entry, stderr);
// setup new entry
Correct spelling of shadow, setting and memory Change-Id: Ic7d793754a8b59623b49b7a88c09b5c6b6ef2cf0 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3768 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-07-14 00:24:31 +02:00
DEBUG("Setting new empty entry.\n");
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
entry = cbfs_find_next_entry(image, entry);
new_size = (cbfs_get_entry_addr(image, next) -
cbfs_get_entry_addr(image, entry));
cbfstool: correct size left calculation for "empty" entries After removing a file sandwiched between two other files, that file could no longer be re-added at the same location. cbfstool tried to add the file, and a new "empty" entry, which, together, would no longer fit, so it continued checking for the next available space. Change the behavior to add the file if there is enough space for the file alone, then only add the "empty" entry if there is enough space for it. Change-Id: Iad3897dd28cf12f12ae877cfd83e1990fa7d2f0f Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4772 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-01-21 22:28:38 +01:00
/* Entry was added and no space for new "empty" entry */
if (new_size < cbfs_calculate_file_header_size("")) {
DEBUG("No need for new \"empty\" entry\n");
/* No need to increase the size of the just
* stored file to extend to next file. Alignment
* of next file takes care of this.
*/
return 0;
}
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
new_size -= cbfs_calculate_file_header_size("");
DEBUG("new size: %d\n", new_size);
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(entry, new_size, "");
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
if (verbose)
cbfs_print_entry_info(image, entry, stderr);
return 0;
}
// We need to put content here, and the case is really
// complicated...
assert(content_offset);
if (addr_next < content_offset) {
DEBUG("Not for specified offset yet");
continue;
} else if (addr > content_offset) {
DEBUG("Exceed specified content_offset.");
break;
} else if (addr + header_size > content_offset) {
ERROR("Not enough space for header.\n");
break;
} else if (content_offset + buffer->size > addr_next) {
ERROR("Not enough space for content.\n");
break;
}
// TODO there are more few tricky cases that we may
// want to fit by altering offset.
DEBUG("section 0x%x+0x%x for content_offset 0x%x.\n",
addr, addr_next - addr, content_offset);
if (cbfs_add_entry_at(image, entry, buffer->size, name, type,
buffer->data, content_offset) == 0) {
return 0;
}
break;
}
ERROR("Could not add [%s, %zd bytes (%zd KB)@0x%x]; too big?\n",
buffer->name, buffer->size, buffer->size / 1024, content_offset);
return -1;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
struct cbfs_file *cbfs_get_entry(struct cbfs_image *image, const char *name)
{
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
struct cbfs_file *entry;
for (entry = cbfs_find_first_entry(image);
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
entry && cbfs_is_valid_entry(image, entry);
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
entry = cbfs_find_next_entry(image, entry)) {
if (strcasecmp(CBFS_NAME(entry), name) == 0) {
DEBUG("cbfs_get_entry: found %s\n", name);
return entry;
}
}
return NULL;
}
int cbfs_export_entry(struct cbfs_image *image, const char *entry_name,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
const char *filename)
{
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
struct cbfs_file *entry = cbfs_get_entry(image, entry_name);
struct buffer buffer;
if (!entry) {
ERROR("File not found: %s\n", entry_name);
return -1;
}
LOG("Found file %.30s at 0x%x, type %.12s, size %d\n",
entry_name, cbfs_get_entry_addr(image, entry),
get_cbfs_entry_type_name(ntohl(entry->type)), ntohl(entry->len));
if (ntohl(entry->type) != CBFS_COMPONENT_RAW) {
WARN("Only 'raw' files are safe to extract.\n");
}
buffer.data = CBFS_SUBHEADER(entry);
buffer.size = ntohl(entry->len);
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
buffer.name = strdup("(cbfs_export_entry)");
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
if (buffer_write_file(&buffer, filename) != 0) {
ERROR("Failed to write %s into %s.\n",
entry_name, filename);
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
free(buffer.name);
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
return -1;
}
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
free(buffer.name);
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
INFO("Successfully dumped the file to: %s\n", filename);
return 0;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
int cbfs_remove_entry(struct cbfs_image *image, const char *name)
{
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
struct cbfs_file *entry, *next;
size_t len;
entry = cbfs_get_entry(image, name);
if (!entry) {
ERROR("CBFS file %s not found.\n", name);
return -1;
}
next = cbfs_find_next_entry(image, entry);
assert(next);
DEBUG("cbfs_remove_entry: Removed %s @ 0x%x\n",
CBFS_NAME(entry), cbfs_get_entry_addr(image, entry));
entry->type = htonl(CBFS_COMPONENT_DELETED);
len = (cbfs_get_entry_addr(image, next) -
cbfs_get_entry_addr(image, entry));
entry->offset = htonl(cbfs_calculate_file_header_size(""));
entry->len = htonl(len - ntohl(entry->offset));
memset(CBFS_NAME(entry), 0, ntohl(entry->offset) - sizeof(*entry));
memset(CBFS_SUBHEADER(entry), CBFS_CONTENT_DEFAULT_VALUE,
ntohl(entry->len));
return 0;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
int cbfs_print_header_info(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
char *name = strdup(image->buffer.name);
assert(image && image->header);
printf("%s: %zd kB, bootblocksize %d, romsize %d, offset 0x%x\n"
cbfstool: Fix architecture check when adding payload 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>
2013-11-13 23:34:57 +01:00
"alignment: %d bytes, architecture: %s\n\n",
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
basename(name),
image->buffer.size / 1024,
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
image->header->bootblocksize,
image->header->romsize,
image->header->offset,
cbfstool: Fix architecture check when adding payload 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>
2013-11-13 23:34:57 +01:00
image->header->align,
arch_to_string(image->header->architecture));
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
free(name);
return 0;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
static int cbfs_print_stage_info(struct cbfs_stage *stage, FILE* fp)
{
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
fprintf(fp,
" %s compression, entry: 0x%" PRIx64 ", load: 0x%" PRIx64 ", "
"length: %d/%d\n",
lookup_name_by_type(types_cbfs_compression,
stage->compression, "(unknown)"),
stage->entry,
stage->load,
stage->len,
stage->memlen);
return 0;
}
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
static int cbfs_print_decoded_payload_segment_info(
struct cbfs_payload_segment *seg, FILE *fp)
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
{
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
/* The input (seg) must be already decoded by
* cbfs_decode_payload_segment.
*/
switch (seg->type) {
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
case PAYLOAD_SEGMENT_CODE:
case PAYLOAD_SEGMENT_DATA:
fprintf(fp, " %s (%s compression, offset: 0x%x, "
"load: 0x%" PRIx64 ", length: %d/%d)\n",
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
(seg->type == PAYLOAD_SEGMENT_CODE ?
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
"code " : "data"),
lookup_name_by_type(types_cbfs_compression,
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
seg->compression,
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
"(unknown)"),
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
seg->offset, seg->load_addr, seg->len,
seg->mem_len);
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
break;
case PAYLOAD_SEGMENT_ENTRY:
fprintf(fp, " entry (0x%" PRIx64 ")\n",
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
seg->load_addr);
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
break;
case PAYLOAD_SEGMENT_BSS:
fprintf(fp, " BSS (address 0x%016" PRIx64 ", "
"length 0x%x)\n",
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
seg->load_addr, seg->len);
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
break;
case PAYLOAD_SEGMENT_PARAMS:
fprintf(fp, " parameters\n");
break;
default:
fprintf(fp, " 0x%x (%s compression, offset: 0x%x, "
"load: 0x%" PRIx64 ", length: %d/%d\n",
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
seg->type,
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
lookup_name_by_type(types_cbfs_compression,
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
seg->compression,
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
"(unknown)"),
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
seg->offset, seg->load_addr, seg->len,
seg->mem_len);
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
break;
}
return 0;
}
int cbfs_print_entry_info(struct cbfs_image *image, struct cbfs_file *entry,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
void *arg)
{
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
const char *name = CBFS_NAME(entry);
struct cbfs_payload_segment *payload;
FILE *fp = (FILE *)arg;
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
if (!cbfs_is_valid_entry(image, entry)) {
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
ERROR("cbfs_print_entry_info: Invalid entry at 0x%x\n",
cbfs_get_entry_addr(image, entry));
return -1;
}
if (!fp)
fp = stdout;
fprintf(fp, "%-30s 0x%-8x %-12s %d\n",
*name ? name : "(empty)",
cbfs_get_entry_addr(image, entry),
get_cbfs_entry_type_name(ntohl(entry->type)),
ntohl(entry->len));
if (!verbose)
return 0;
DEBUG(" cbfs_file=0x%x, offset=0x%x, content_address=0x%x+0x%x\n",
cbfs_get_entry_addr(image, entry), ntohl(entry->offset),
cbfs_get_entry_addr(image, entry) + ntohl(entry->offset),
ntohl(entry->len));
/* note the components of the subheader may be in host order ... */
switch (ntohl(entry->type)) {
case CBFS_COMPONENT_STAGE:
cbfs_print_stage_info((struct cbfs_stage *)
CBFS_SUBHEADER(entry), fp);
break;
case CBFS_COMPONENT_PAYLOAD:
payload = (struct cbfs_payload_segment *)
CBFS_SUBHEADER(entry);
while (payload) {
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
struct cbfs_payload_segment seg;
cbfs_decode_payload_segment(&seg, payload);
cbfs_print_decoded_payload_segment_info(
&seg, fp);
if (seg.type == PAYLOAD_SEGMENT_ENTRY)
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
break;
util/cbfstool: Fix byte-ordering for payload type field. In https://chromium-review.googlesource.com/181272 the payload->type has been changed to big-endian (network ordering) but the cbfs_image is still parsing type as host ordering, which caused printing cbfs image verbosely (cbfstool imge print -v) to fail to find entry field and print numerous garbage output. Payload fields should be always parsed in big-endian (network ordering). BUG=none TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/200158 Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9 Reviewed-on: http://review.coreboot.org/8005 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-05-16 04:14:05 +02:00
else
cbfstool: process cbfs_payload_segment(s) in host byte order The printing routines of the cbfs_payload_segment assumed the type could be accessed in host order. Each of the fields need to be converted to the host order before inspecting the fields. In addition, this removes all the ntoh*() calls while processing the cbfs_payload_segment structures. cbfstool would crash adding entries or just printing entries containing a payload when -v was passed on the command line. Change-Id: Iff41c64a99001b9e3920e2e26828c5fd6e671239 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/6498 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <gaumless@gmail.com>
2014-08-05 17:48:20 +02:00
payload ++;
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
}
break;
default:
break;
}
return 0;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
int cbfs_print_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
cbfs_print_header_info(image);
printf("%-30s %-10s %-12s Size\n", "Name", "Offset", "Type");
cbfs_walk(image, cbfs_print_entry_info, NULL);
return 0;
}
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
int cbfs_merge_empty_entry(struct cbfs_image *image, struct cbfs_file *entry,
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
unused void *arg)
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
{
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
struct cbfs_file *next;
uint32_t type, addr, last_addr;
type = ntohl(entry->type);
if (type == CBFS_COMPONENT_DELETED) {
// Ready to be recycled.
type = CBFS_COMPONENT_NULL;
entry->type = htonl(type);
}
if (type != CBFS_COMPONENT_NULL)
return 0;
next = cbfs_find_next_entry(image, entry);
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
while (next && cbfs_is_valid_entry(image, next)) {
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
type = ntohl(next->type);
if (type == CBFS_COMPONENT_DELETED) {
type = CBFS_COMPONENT_NULL;
next->type = htonl(type);
}
if (type != CBFS_COMPONENT_NULL)
return 0;
addr = cbfs_get_entry_addr(image, entry);
last_addr = cbfs_get_entry_addr(
image, cbfs_find_next_entry(image, next));
// Now, we find two deleted/empty entries; try to merge now.
DEBUG("join_empty_entry: combine 0x%x+0x%x and 0x%x+0x%x.\n",
cbfs_get_entry_addr(image, entry), ntohl(entry->len),
cbfs_get_entry_addr(image, next), ntohl(next->len));
cbfstool: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
cbfs_create_empty_entry(entry,
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
(last_addr - addr -
cbfs_calculate_file_header_size("")),
"");
DEBUG("new empty entry: length=0x%x\n", ntohl(entry->len));
next = cbfs_find_next_entry(image, entry);
}
return 0;
}
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_walk(struct cbfs_image *image, cbfs_entry_callback callback,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
void *arg)
{
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 count = 0;
struct cbfs_file *entry;
for (entry = cbfs_find_first_entry(image);
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
entry && cbfs_is_valid_entry(image, entry);
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
entry = cbfs_find_next_entry(image, entry)) {
count ++;
if (callback(image, entry, arg) != 0)
break;
}
return count;
}
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
static int cbfs_header_valid(struct cbfs_header *header, size_t size)
{
if ((ntohl(header->magic) == CBFS_HEADER_MAGIC) &&
((ntohl(header->version) == CBFS_HEADER_VERSION1) ||
(ntohl(header->version) == CBFS_HEADER_VERSION2)) &&
(ntohl(header->romsize) <= size) &&
(ntohl(header->offset) < ntohl(header->romsize)))
return 1;
return 0;
}
struct cbfs_header *cbfs_find_header(char *data, size_t size,
uint32_t forced_offset)
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
{
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
size_t offset;
int found = 0;
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
int32_t rel_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
struct cbfs_header *header, *result = NULL;
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
if (forced_offset < (size - sizeof(struct cbfs_header))) {
/* Check if the forced header is valid. */
header = (struct cbfs_header *)(data + forced_offset);
if (cbfs_header_valid(header, size))
return header;
return NULL;
}
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
// Try finding relative offset of master header at end of file first.
rel_offset = *(int32_t *)(data + size - sizeof(int32_t));
offset = size + rel_offset;
DEBUG("relative offset: %#zx(-%#zx), offset: %#zx\n",
(size_t)rel_offset, (size_t)-rel_offset, offset);
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
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
if (offset >= size - sizeof(*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
!cbfs_header_valid((struct cbfs_header *)(data + offset), size)) {
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
// Some use cases append non-CBFS data to the end of the ROM.
DEBUG("relative offset seems wrong, scanning whole image...\n");
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
offset = 0;
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
}
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
for (; offset + sizeof(*header) < size; offset++) {
header = (struct cbfs_header *)(data + offset);
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
if (!cbfs_header_valid(header, 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
continue;
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
if (!found++)
result = 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
}
CBFS: Automate ROM image layout and remove hardcoded offsets 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>
2014-11-10 22:14:24 +01:00
if (found > 1)
// Top-aligned images usually have a working relative offset
// field, so this is more likely to happen on bottom-aligned
// ones (where the first header is the "outermost" one)
WARN("Multiple (%d) CBFS headers found, using the first one.\n",
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
found);
return result;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
struct cbfs_file *cbfs_find_first_entry(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
assert(image && image->header);
return (struct cbfs_file *)(image->buffer.data +
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
image->header->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
}
struct cbfs_file *cbfs_find_next_entry(struct cbfs_image *image,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
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
uint32_t addr = cbfs_get_entry_addr(image, entry);
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
int align = image->header->align;
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
assert(entry && cbfs_is_valid_entry(image, 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
addr += ntohl(entry->offset) + ntohl(entry->len);
addr = align_up(addr, align);
return (struct cbfs_file *)(image->buffer.data + addr);
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
uint32_t cbfs_get_entry_addr(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
assert(image && image->buffer.data && entry);
return (int32_t)((char *)entry - image->buffer.data);
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
int cbfs_is_valid_entry(struct cbfs_image *image, struct cbfs_file *entry)
{
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
return (entry &&
(char *)entry >= image->buffer.data &&
(char *)entry + sizeof(entry->magic) <
image->buffer.data + image->buffer.size &&
memcmp(entry->magic, CBFS_FILE_MAGIC,
sizeof(entry->magic)) == 0);
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: clean up source code The following changes were made: - order commands and options definitions alphabetically - do not report errors at cbfs_image_from_file() call sites - the error is reported by the function itself - remove the unused parameter in cbfs_create_empty_entry() prototype BRANCH=storm BUG=none TEST=compiled cbfstool, built a storm image, observed that the image still boots Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8 Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237560 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-24 00:59:57 +01:00
int cbfs_create_empty_entry(struct cbfs_file *entry,
size_t len, const char *name)
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
{
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
memset(entry, CBFS_CONTENT_DEFAULT_VALUE, sizeof(*entry));
memcpy(entry->magic, CBFS_FILE_MAGIC, sizeof(entry->magic));
entry->type = htonl(CBFS_COMPONENT_NULL);
entry->len = htonl(len);
entry->checksum = 0; // TODO Build a checksum algorithm.
entry->offset = htonl(cbfs_calculate_file_header_size(name));
memset(CBFS_NAME(entry), 0, ntohl(entry->offset) - sizeof(*entry));
strcpy(CBFS_NAME(entry), name);
memset(CBFS_SUBHEADER(entry), CBFS_CONTENT_DEFAULT_VALUE, len);
return 0;
}
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
/* Finds a place to hold whole data in same memory page. */
static int is_in_same_page(uint32_t start, uint32_t size, uint32_t page)
{
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
if (!page)
return 1;
return (start / page) == (start + size - 1) / page;
}
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
/* Tests if data can fit in a range by given offset:
* start ->| header_len | offset (+ size) |<- end
*/
static int is_in_range(uint32_t start, uint32_t end, uint32_t header_len,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
uint32_t offset, uint32_t size)
{
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
return (offset >= start + header_len && offset + size <= end);
}
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
int32_t cbfs_locate_entry(struct cbfs_image *image, const char *name,
cbfstool: Fix cbfs_image.c - The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-26 20:51:36 +01:00
uint32_t size, uint32_t page_size, uint32_t align)
{
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
struct cbfs_file *entry;
size_t need_len;
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
uint32_t addr, addr_next, addr2, addr3, offset, header_len;
/* Default values: allow fitting anywhere in ROM. */
if (!page_size)
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
page_size = image->header->romsize;
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
if (!align)
align = 1;
if (size > page_size)
ERROR("Input file size (%d) greater than page size (%d).\n",
size, page_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: 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
if (page_size % image->header->align)
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
WARN("%s: Page size (%#x) not aligned with CBFS image (%#x).\n",
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
__func__, page_size, image->header->align);
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
/* TODO Old cbfstool always assume input is a stage file (and adding
* sizeof(cbfs_stage) for header. We should fix that by adding "-t"
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
* (type) param in future. For right now, we assume cbfs_stage is the
* largest structure and add it into header size. */
assert(sizeof(struct cbfs_stage) >= sizeof(struct cbfs_payload));
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
header_len = (cbfs_calculate_file_header_size(name) +
sizeof(struct cbfs_stage));
need_len = header_len + size;
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
// Merge empty entries to build get max available space.
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
cbfs_walk(image, cbfs_merge_empty_entry, NULL);
/* Three cases of content location on memory page:
* case 1.
* | PAGE 1 | PAGE 2 |
* | <header><content>| Fit. Return start of content.
*
* case 2.
* | PAGE 1 | PAGE 2 |
* | <header><content> | Fits when we shift content to align
* shift-> | <header>|<content> | at starting of PAGE 2.
*
* case 3. (large content filling whole page)
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
* | PAGE 1 | PAGE 2 | PAGE 3 |
* | <header>< content > | Can't fit. If we shift content to
* |trial-> <header>< content > | PAGE 2, header can't fit in free
* | shift-> <header><content> space, so we must use PAGE 3.
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 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
* The returned address can be then used as "base-address" (-b) in add-*
* commands (will be re-calculated and positioned by cbfs_add_entry_at).
* For stage targets, the address is also used to re-link stage before
* being added into CBFS.
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
*/
for (entry = cbfs_find_first_entry(image);
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
entry && cbfs_is_valid_entry(image, entry);
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
entry = cbfs_find_next_entry(image, entry)) {
uint32_t type = ntohl(entry->type);
if (type != CBFS_COMPONENT_NULL)
continue;
addr = cbfs_get_entry_addr(image, entry);
addr_next = cbfs_get_entry_addr(image, cbfs_find_next_entry(
image, entry));
if (addr_next - addr < need_len)
continue;
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
offset = align_up(addr + header_len, align);
if (is_in_same_page(offset, size, page_size) &&
is_in_range(addr, addr_next, header_len, offset, 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
DEBUG("cbfs_locate_entry: FIT (PAGE1).");
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
return offset;
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
}
addr2 = align_up(addr, page_size);
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
offset = align_up(addr2, align);
if (is_in_range(addr, addr_next, header_len, offset, 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
DEBUG("cbfs_locate_entry: OVERLAP (PAGE2).");
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
return offset;
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 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
/* Assume page_size >= header_len so adding one page will
* definitely provide the space for header. */
assert(page_size >= header_len);
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
addr3 = addr2 + page_size;
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
offset = align_up(addr3, align);
if (is_in_range(addr, addr_next, header_len, offset, 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
DEBUG("cbfs_locate_entry: OVERLAP+ (PAGE3).");
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
return offset;
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
}
}
return -1;
}