coreboot-kgpe-d16/util/cbfstool/cbfs_image.c

1071 lines
33 KiB
C
Raw Normal View History

/*
* 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
*/
#include <inttypes.h>
#include <libgen.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "common.h"
#include "cbfs_image.h"
/* 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)
/* Type and format */
struct typedesc_t {
uint32_t type;
const char *name;
};
static const struct typedesc_t types_cbfs_entry[] = {
{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"},
{CBFS_COMPONENT_FSP, "fsp"},
{CBFS_COMPONENT_MRC, "mrc"},
{CBFS_COMPONENT_CMOS_DEFAULT, "cmos_default"},
{CBFS_COMPONENT_CMOS_LAYOUT, "cmos_layout"},
{CBFS_COMPONENT_SPD, "spd"},
{CBFS_COMPONENT_MRC_CACHE, "mrc_cache"},
{CBFS_COMPONENT_DELETED, "deleted"},
{CBFS_COMPONENT_NULL, "null"},
{0, NULL},
};
static const struct typedesc_t types_cbfs_compression[] = {
{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,
const char *default_value)
{
int i;
for (i = 0; desc[i].name; i++)
if (desc[i].type == type)
return desc[i].name;
return default_value;
}
static const char *get_cbfs_entry_type_name(uint32_t type)
{
return lookup_name_by_type(types_cbfs_entry, type, "(unknown)");
}
/* CBFS image */
static int cbfs_calculate_file_header_size(const char *name)
{
return (sizeof(struct cbfs_file) +
align_up(strlen(name) + 1, CBFS_FILENAME_ALIGN));
}
static int cbfs_fix_legacy_size(struct cbfs_image *image, char *hdr_loc)
{
// 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);
entry && cbfs_is_valid_entry(image, entry);
entry = cbfs_find_next_entry(image, entry)) {
last = entry;
}
if ((char *)first < (char *)hdr_loc &&
(char *)entry > (char *)hdr_loc) {
WARN("CBFS image was created with old cbfstool with size bug. "
"Fixing size in last entry...\n");
last->len = htonl(ntohl(last->len) - image->header->align);
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;
}
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);
}
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);
}
void cbfs_get_header(struct cbfs_header *header, const void *src)
{
struct buffer outheader;
outheader.data = (void *)src; /* We're not modifying the data */
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);
}
int cbfs_image_create(struct cbfs_image *image,
uint32_t architecture,
size_t size,
uint32_t align,
struct buffer *bootblock,
int32_t bootblock_offset,
int32_t header_offset,
int32_t entries_offset)
{
struct cbfs_header header;
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;
uint32_t cbfs_len;
size_t entry_header_len;
void *header_loc;
DEBUG("cbfs_image_create: bootblock=0x%x+0x%zx, "
"header=0x%x+0x%zx, entries_offset=0x%x\n",
bootblock_offset, bootblock->size,
header_offset, sizeof(header), entries_offset);
if (buffer_create(&image->buffer, size, "(new)") != 0)
return -1;
if ((image->header = malloc(sizeof(*image->header))) == NULL)
return -1;
memset(image->buffer.data, CBFS_CONTENT_DEFAULT_VALUE, size);
// Adjust legcay top-aligned address to ROM offset.
if (IS_TOP_ALIGNED_ADDRESS(entries_offset))
entries_offset += (int32_t)size;
if (IS_TOP_ALIGNED_ADDRESS(bootblock_offset))
bootblock_offset += (int32_t)size;
if (IS_TOP_ALIGNED_ADDRESS(header_offset))
header_offset += (int32_t) size;
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;
}
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;
}
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)) {
ERROR("Header (0x%x+0x%zx) exceed ROM size (0x%zx)\n",
header_offset, sizeof(header), size);
return -1;
}
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;
image->header->architecture = architecture;
header_loc = (image->buffer.data + header_offset);
cbfs_put_header(header_loc, image->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
// 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;
// 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;
}
entry_header_len = cbfs_calculate_file_header_size("");
if (entries_offset + entry_header_len > size) {
ERROR("Offset (0x%x+0x%zx) exceed ROM size(0x%zx)\n",
entries_offset, entry_header_len, size);
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);
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;
cbfs_len -= entries_offset + align + entry_header_len;
cbfs_create_empty_entry(entry, cbfs_len, "");
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)
{
void *header_loc;
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);
if (!header_loc) {
ERROR("%s does not have CBFS master header.\n", filename);
cbfs_image_delete(image);
return -1;
}
if ((image->header = malloc(sizeof(*image->header))) == NULL)
return -1;
cbfs_get_header(image->header, header_loc);
cbfs_fix_legacy_size(image, header_loc);
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));
if (((char *)dst_entry - image->buffer.data) >= copy_end) {
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
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;
}
int cbfs_image_write_file(struct cbfs_image *image, const char *filename)
{
assert(image && image->buffer.data);
return buffer_write_file(&image->buffer, filename);
}
int cbfs_image_delete(struct cbfs_image *image)
{
if (image == NULL)
return 0;
buffer_delete(&image->buffer);
image->header = NULL;
return 0;
}
/* 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,
uint32_t content_offset)
{
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;
uint32_t align = image->header->align;
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;
cbfs_create_empty_entry(entry, len, "");
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);
cbfs_create_empty_entry(entry, len, name);
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 ==
content_offset);
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);
assert(addr < addr_next);
if (addr_next - addr < min_entry_size) {
DEBUG("No space after content to keep CBFS structure.\n");
return -1;
}
len = addr_next - addr - min_entry_size;
cbfs_create_empty_entry(entry, len, "");
if (verbose > 1) cbfs_print_entry_info(image, entry, stderr);
return 0;
}
int cbfs_add_entry(struct cbfs_image *image, struct buffer *buffer,
const char *name, uint32_t type, uint32_t content_offset)
{
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.
uint32_t theromsize = image->header->romsize;
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);
content_offset += theromsize;
}
// 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);
entry && cbfs_is_valid_entry(image, entry);
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);
/* Will the file fit? Don't yet worry if we have space for a new
* "empty" entry. We take care of that later.
*/
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);
cbfs_create_empty_entry(entry, buffer->size, name);
entry->type = htonl(type);
memcpy(CBFS_SUBHEADER(entry), buffer->data, buffer->size);
if (verbose)
cbfs_print_entry_info(image, entry, stderr);
// setup new entry
DEBUG("Setting new empty entry.\n");
entry = cbfs_find_next_entry(image, entry);
new_size = (cbfs_get_entry_addr(image, next) -
cbfs_get_entry_addr(image, entry));
/* 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;
}
new_size -= cbfs_calculate_file_header_size("");
DEBUG("new size: %d\n", new_size);
cbfs_create_empty_entry(entry, new_size, "");
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;
}
struct cbfs_file *cbfs_get_entry(struct cbfs_image *image, const char *name)
{
struct cbfs_file *entry;
for (entry = cbfs_find_first_entry(image);
entry && cbfs_is_valid_entry(image, entry);
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,
const char *filename)
{
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);
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
buffer.name = (char *)"(cbfs_export_entry)";
if (buffer_write_file(&buffer, filename) != 0) {
ERROR("Failed to write %s into %s.\n",
entry_name, filename);
return -1;
}
INFO("Successfully dumped the file to: %s\n", filename);
return 0;
}
int cbfs_remove_entry(struct cbfs_image *image, const char *name)
{
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;
}
int cbfs_print_header_info(struct cbfs_image *image)
{
char *name = strdup(image->buffer.name);
assert(image && image->header);
printf("%s: %zd kB, bootblocksize %d, romsize %d, offset 0x%x\n"
"alignment: %d bytes, architecture: %s\n\n",
basename(name),
image->buffer.size / 1024,
image->header->bootblocksize,
image->header->romsize,
image->header->offset,
image->header->align,
arch_to_string(image->header->architecture));
free(name);
return 0;
}
static int cbfs_print_stage_info(struct cbfs_stage *stage, FILE* fp)
{
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;
}
static int cbfs_print_decoded_payload_segment_info(
struct cbfs_payload_segment *seg, FILE *fp)
{
/* The input (seg) must be already decoded by
* cbfs_decode_payload_segment.
*/
switch (seg->type) {
case PAYLOAD_SEGMENT_CODE:
case PAYLOAD_SEGMENT_DATA:
fprintf(fp, " %s (%s compression, offset: 0x%x, "
"load: 0x%" PRIx64 ", length: %d/%d)\n",
(seg->type == PAYLOAD_SEGMENT_CODE ?
"code " : "data"),
lookup_name_by_type(types_cbfs_compression,
seg->compression,
"(unknown)"),
seg->offset, seg->load_addr, seg->len,
seg->mem_len);
break;
case PAYLOAD_SEGMENT_ENTRY:
fprintf(fp, " entry (0x%" PRIx64 ")\n",
seg->load_addr);
break;
case PAYLOAD_SEGMENT_BSS:
fprintf(fp, " BSS (address 0x%016" PRIx64 ", "
"length 0x%x)\n",
seg->load_addr, seg->len);
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",
seg->type,
lookup_name_by_type(types_cbfs_compression,
seg->compression,
"(unknown)"),
seg->offset, seg->load_addr, seg->len,
seg->mem_len);
break;
}
return 0;
}
int cbfs_print_entry_info(struct cbfs_image *image, struct cbfs_file *entry,
void *arg)
{
const char *name = CBFS_NAME(entry);
struct cbfs_payload_segment *payload;
FILE *fp = (FILE *)arg;
if (!cbfs_is_valid_entry(image, entry)) {
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) {
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)
break;
else
payload ++;
}
break;
default:
break;
}
return 0;
}
int cbfs_print_directory(struct cbfs_image *image)
{
cbfs_print_header_info(image);
printf("%-30s %-10s %-12s Size\n", "Name", "Offset", "Type");
cbfs_walk(image, cbfs_print_entry_info, NULL);
return 0;
}
int cbfs_merge_empty_entry(struct cbfs_image *image, struct cbfs_file *entry,
void *arg)
{
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);
while (next && cbfs_is_valid_entry(image, next)) {
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));
cbfs_create_empty_entry(entry,
(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;
}
int cbfs_walk(struct cbfs_image *image, cbfs_entry_callback callback,
void *arg)
{
int count = 0;
struct cbfs_file *entry;
for (entry = cbfs_find_first_entry(image);
entry && cbfs_is_valid_entry(image, entry);
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)
{
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;
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
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");
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
}
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))
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;
}
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",
found);
return result;
}
struct cbfs_file *cbfs_find_first_entry(struct cbfs_image *image)
{
assert(image && image->header);
return (struct cbfs_file *)(image->buffer.data +
image->header->offset);
}
struct cbfs_file *cbfs_find_next_entry(struct cbfs_image *image,
struct cbfs_file *entry)
{
uint32_t addr = cbfs_get_entry_addr(image, entry);
int align = image->header->align;
assert(entry && cbfs_is_valid_entry(image, entry));
addr += ntohl(entry->offset) + ntohl(entry->len);
addr = align_up(addr, align);
return (struct cbfs_file *)(image->buffer.data + addr);
}
uint32_t cbfs_get_entry_addr(struct cbfs_image *image, struct cbfs_file *entry)
{
assert(image && image->buffer.data && entry);
return (int32_t)((char *)entry - image->buffer.data);
}
int cbfs_is_valid_entry(struct cbfs_image *image, struct cbfs_file *entry)
{
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);
}
int cbfs_create_empty_entry(struct cbfs_file *entry,
size_t len, const char *name)
{
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;
}
/* 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)
{
if (!page)
return 1;
return (start / page) == (start + size - 1) / page;
}
/* 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,
uint32_t offset, uint32_t size)
{
return (offset >= start + header_len && offset + size <= end);
}
int32_t cbfs_locate_entry(struct cbfs_image *image, const char *name,
uint32_t size, uint32_t page_size, uint32_t align)
{
struct cbfs_file *entry;
size_t need_len;
uint32_t addr, addr_next, addr2, addr3, offset, header_len;
/* Default values: allow fitting anywhere in ROM. */
if (!page_size)
page_size = image->header->romsize;
if (!align)
align = 1;
if (size > page_size)
ERROR("Input file size (%d) greater than page size (%d).\n",
size, page_size);
if (page_size % image->header->align)
WARN("%s: Page size (%#x) not aligned with CBFS image (%#x).\n",
__func__, page_size, image->header->align);
/* TODO Old cbfstool always assume input is a stage file (and adding
* sizeof(cbfs_stage) for header. We should fix that by adding "-t"
* (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));
header_len = (cbfs_calculate_file_header_size(name) +
sizeof(struct cbfs_stage));
need_len = header_len + size;
// Merge empty entries to build get max available space.
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)
* | 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.
*
* 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.
*/
for (entry = cbfs_find_first_entry(image);
entry && cbfs_is_valid_entry(image, entry);
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;
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)) {
DEBUG("cbfs_locate_entry: FIT (PAGE1).");
return offset;
}
addr2 = align_up(addr, page_size);
offset = align_up(addr2, align);
if (is_in_range(addr, addr_next, header_len, offset, size)) {
DEBUG("cbfs_locate_entry: OVERLAP (PAGE2).");
return offset;
}
/* Assume page_size >= header_len so adding one page will
* definitely provide the space for header. */
assert(page_size >= header_len);
addr3 = addr2 + page_size;
offset = align_up(addr3, align);
if (is_in_range(addr, addr_next, header_len, offset, size)) {
DEBUG("cbfs_locate_entry: OVERLAP+ (PAGE3).");
return offset;
}
}
return -1;
}