GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/payloads/libpayload/libcbfs/cbfs_core.c

365 lines
11 KiB
C
Raw Normal View History

libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
/*
* This file is part of the libpayload project.
*
* Copyright (C) 2011 secunet Security Networks AG
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
* Copyright (C) 2013 Google, Inc.
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
/* The CBFS core requires a couple of #defines or functions to adapt it to the
* target environment:
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
*
* CBFS_CORE_WITH_LZMA (must be #define)
* if defined, ulzma() must exist for decompression of data streams
*
cbfs: Add LZ4 in-place decompression support for pre-RAM stages This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-29 22:51:35 +02:00
* CBFS_CORE_WITH_LZ4 (must be #define)
* if defined, ulz4f() must exist for decompression of data streams
*
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
* ERROR(x...)
* print an error message x (in printf format)
*
* LOG(x...)
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
* print a message x (in printf format)
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
*
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
* DEBUG(x...)
* print a debug message x (in printf format)
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
*
*/
libpayload: cbfs: Require input size and output size for cbfs_decompress Currently, cbfs_decompress() calls ulzma() and ulz4f() for LZMA/LZ4 decompression. These two functions don't accept input/output size as parameters. We can make cbfs_decompress more robust by calling ulzman() and ulz4fn() instead. This could prevent us from overflowing destination buffer. BUG=none BRANCH=none TEST=boot into kernel on Kukui with COMPRESSED_PAYLOAD_LZMA / COMPRESSED_PAYLOAD_LZ4. Change-Id: Ibe617825bd000ed618791d8e3c5f65bbbd5f7e33 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
2019-02-27 08:29:15 +01:00
#include <libpayload.h>
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
#include <cbfs.h>
#include <string.h>
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
#include <sysinfo.h>
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
/* returns a pointer to CBFS master header, or CBFS_HEADER_INVALID_ADDRESS
* on failure */
const struct cbfs_header *cbfs_get_header(struct cbfs_media *media)
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02: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
int32_t rel_offset;
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
const struct cbfs_header *header;
struct cbfs_media default_media;
if (media == CBFS_DEFAULT_MEDIA) {
media = &default_media;
if (init_default_cbfs_media(media) != 0) {
libpayload: libcbfs: Fix legacy CBFS API, typos get_cbfs_header expects CBFS_HEADER_INVALID_ADDRESS (0xffffffff) instead of NULL when something is wrong. Also, fix typo. Change-Id: Ibe56c9eab3b9fdfc6d0b14bc848ca75f3a4fc2f1 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2455 Tested-by: build bot (Jenkins) Reviewed-by: Peter Stuge <peter@stuge.se>
2013-02-19 17:59:21 +01:00
ERROR("Failed to initialize default media.\n");
return CBFS_HEADER_INVALID_ADDRESS;
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
}
}
media->open(media);
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 (!media->read(media, &rel_offset, (size_t)(0 - sizeof(int32_t)),
sizeof(int32_t))) {
ERROR("Could not read CBFS master header offset!\n");
return CBFS_HEADER_INVALID_ADDRESS;
}
header = media->map(media, (size_t)rel_offset, sizeof(*header));
DEBUG("CBFS header at %#zx (-%#zx from end of image).\n",
(size_t)rel_offset, (size_t)-rel_offset);
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
media->close(media);
if (header == CBFS_MEDIA_INVALID_MAP_ADDRESS) {
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
ERROR("Failed to load CBFS header from %#zx(-%#zx)\n",
(size_t)rel_offset, (size_t)-rel_offset);
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
return CBFS_HEADER_INVALID_ADDRESS;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
if (CBFS_HEADER_MAGIC != ntohl(header->magic)) {
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
ERROR("Could not find valid CBFS master header at %#zx(-%#zx): "
"magic %#.8x vs %#.8x.\n", (size_t)rel_offset,
(size_t)-rel_offset, CBFS_HEADER_MAGIC,
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
ntohl(header->magic));
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
if (header->magic == 0xffffffff) {
ERROR("Maybe ROM is not mapped properly?\n");
}
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
return CBFS_HEADER_INVALID_ADDRESS;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
return header;
}
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
static int get_cbfs_range(uint32_t *offset, uint32_t *cbfs_end,
struct cbfs_media *media)
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
{
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
const struct cbfs_header *header;
libpayload: Allow non-default CBFS media CBFS requests were always fulfilled using the CBFS specified in cbtables. That's a great policy when default requests are sought, but not so great when the user deliberately asked for something else. So check if they want default CBFS media information, otherwise ignore cbtables data. BUG=chromium:445938 BRANCH=none TEST=none Change-Id: I01b63049eebfba6f467808ac84ef77385840c204 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 621c916ab14c0de4bae3dde09c05060c4f3c63c5 Original-Change-Id: Ia4a8848fd7db9d9a2bf9f5c226566fe3936ff543 Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/308520 Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/12232 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-10-23 20:25:03 +02:00
if (media == CBFS_DEFAULT_MEDIA &&
lib_sysinfo.cbfs_offset && lib_sysinfo.cbfs_size) {
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
*offset = lib_sysinfo.cbfs_offset;
*cbfs_end = *offset + lib_sysinfo.cbfs_size;
return 0;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
libpayload: get cbfs offset & size for default media from lib_sysinfo This change revives the path which was made inert by CL:308520. When media == CBFS_DEFAULT_MEDIA, cbfs_get_file replaces it with a pointer to a default media. Thus, get_cbfs_range does not set cbfs offset & size from lib_sysinfo. BUG=chrome-os-partner:47772 BRANCH=tot TEST=Tested on Jerry and Glados Change-Id: I012f7871336dd24b8eada5c96c4d72117921b0d2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 279ba344788b4ba85f500e6cfcca8199af6d0a89 Original-Change-Id: I7f0798881519026a23d0801d0a790332ab878ff0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/313205 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12583 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19 18:10:41 +01:00
/* read offset and size from cbfs master header */
DEBUG("Read CBFS offset & size from master header\n");
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
header = cbfs_get_header(media);
if (header == CBFS_HEADER_INVALID_ADDRESS)
return -1;
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
// Logical offset (for source media) of first file.
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
*offset = ntohl(header->offset);
*cbfs_end = ntohl(header->romsize);
payloads: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find payloads/ -type f | \ xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I883b03b189f59b5d998a09a2596b0391a2d5cf33 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31775 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:55:15 +01:00
#if CONFIG(LP_ARCH_X86)
cbfs: Fix overwalk on file scan A bootblock overwalk was occuring when deriving the actual length, the bootblock size was not taken into account and bootblock size was not aligned. Resolved merge conflict. Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f Signed-off-by: Steven Sherk <steven.sherk@se-eng.com> Reviewed-on: https://gerrit.chromium.org/gerrit/65989 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Steve Sherk <ssherk70@gmail.com> Tested-by: Steve Sherk <ssherk70@gmail.com> (cherry picked from commit 20b0ba479b01755fbdc7f3dd9214e8af923402ba) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6539 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-14 22:55:57 +02:00
// resolve actual length of ROM used for CBFS components
// the bootblock size was not taken into account
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
*cbfs_end -= ntohl(header->bootblocksize);
cbfs: Fix overwalk on file scan A bootblock overwalk was occuring when deriving the actual length, the bootblock size was not taken into account and bootblock size was not aligned. Resolved merge conflict. Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f Signed-off-by: Steven Sherk <steven.sherk@se-eng.com> Reviewed-on: https://gerrit.chromium.org/gerrit/65989 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Steve Sherk <ssherk70@gmail.com> Tested-by: Steve Sherk <ssherk70@gmail.com> (cherry picked from commit 20b0ba479b01755fbdc7f3dd9214e8af923402ba) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6539 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-14 22:55:57 +02:00
// fine tune the length to handle alignment positioning.
// using (bootblock size) % align, to derive the
// number of bytes the bootblock is off from the alignment size.
libpayload: assume cbfs file alignment is 64 byte Change-Id: I8dfd8fbd452ce92fbca2cf095bc5e43e4a26969d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10920 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-14 22:29:04 +02:00
if ((ntohl(header->bootblocksize) % CBFS_ALIGNMENT))
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
*cbfs_end -= (CBFS_ALIGNMENT -
libpayload: assume cbfs file alignment is 64 byte Change-Id: I8dfd8fbd452ce92fbca2cf095bc5e43e4a26969d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10920 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-14 22:29:04 +02:00
(ntohl(header->bootblocksize) % CBFS_ALIGNMENT));
cbfs: Fix overwalk on file scan A bootblock overwalk was occuring when deriving the actual length, the bootblock size was not taken into account and bootblock size was not aligned. Resolved merge conflict. Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f Signed-off-by: Steven Sherk <steven.sherk@se-eng.com> Reviewed-on: https://gerrit.chromium.org/gerrit/65989 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Steve Sherk <ssherk70@gmail.com> Tested-by: Steve Sherk <ssherk70@gmail.com> (cherry picked from commit 20b0ba479b01755fbdc7f3dd9214e8af923402ba) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6539 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-14 22:55:57 +02:00
else
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
*cbfs_end -= 1;
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
#endif
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
return 0;
}
/* public API starts here*/
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
struct cbfs_handle *cbfs_get_handle(struct cbfs_media *media, const char *name)
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
{
const char *vardata;
uint32_t offset, cbfs_end, vardata_len;
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
struct cbfs_file file;
struct cbfs_handle *handle = malloc(sizeof(*handle));
if (!handle)
return NULL;
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
libpayload: get cbfs offset & size for default media from lib_sysinfo This change revives the path which was made inert by CL:308520. When media == CBFS_DEFAULT_MEDIA, cbfs_get_file replaces it with a pointer to a default media. Thus, get_cbfs_range does not set cbfs offset & size from lib_sysinfo. BUG=chrome-os-partner:47772 BRANCH=tot TEST=Tested on Jerry and Glados Change-Id: I012f7871336dd24b8eada5c96c4d72117921b0d2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 279ba344788b4ba85f500e6cfcca8199af6d0a89 Original-Change-Id: I7f0798881519026a23d0801d0a790332ab878ff0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/313205 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12583 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19 18:10:41 +01:00
if (get_cbfs_range(&offset, &cbfs_end, media)) {
ERROR("Failed to find cbfs range\n");
libpayload: cbfs: Fix minor memory leak in some edge cases cbfs_get_handle() allocates memory for a handle and doesn't free it if it errors out later, leaving the memory permanently leaked. Fix. Change-Id: Ide198105ce3ad6237672ff152b4490c768909564 Reported-by: Coverity Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16207 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-12 21:50:42 +02:00
free(handle);
libpayload: get cbfs offset & size for default media from lib_sysinfo This change revives the path which was made inert by CL:308520. When media == CBFS_DEFAULT_MEDIA, cbfs_get_file replaces it with a pointer to a default media. Thus, get_cbfs_range does not set cbfs offset & size from lib_sysinfo. BUG=chrome-os-partner:47772 BRANCH=tot TEST=Tested on Jerry and Glados Change-Id: I012f7871336dd24b8eada5c96c4d72117921b0d2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 279ba344788b4ba85f500e6cfcca8199af6d0a89 Original-Change-Id: I7f0798881519026a23d0801d0a790332ab878ff0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/313205 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12583 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-11-19 18:10:41 +01:00
return NULL;
}
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
if (media == CBFS_DEFAULT_MEDIA) {
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
media = &handle->media;
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
if (init_default_cbfs_media(media) != 0) {
ERROR("Failed to initialize default media.\n");
libpayload: cbfs: Fix minor memory leak in some edge cases cbfs_get_handle() allocates memory for a handle and doesn't free it if it errors out later, leaving the memory permanently leaked. Fix. Change-Id: Ide198105ce3ad6237672ff152b4490c768909564 Reported-by: Coverity Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16207 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-12 21:50:42 +02:00
free(handle);
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
return NULL;
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
} else {
memcpy(&handle->media, media, sizeof(*media));
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
}
DEBUG("CBFS location: 0x%x~0x%x\n", offset, cbfs_end);
cbfs_core.c: make cfbs searches even less verbose The cbfs core code would print out the name of the file it is searching for and when it is found would print out the name again. This contributes to a lot of unnecessary messages in a functioning payload’s output. Change this message to a DEBUG one so that it will only be printed when CONFIG_DEBUG_CBFS is enabled. Change-Id: Ib238ff174bedba8eaaad8d1d452721fcac339b1a Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3208 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-06 23:51:39 +02:00
DEBUG("Looking for '%s' starting from 0x%x.\n", name, offset);
cbfs: Fix overwalk on file scan A bootblock overwalk was occuring when deriving the actual length, the bootblock size was not taken into account and bootblock size was not aligned. Resolved merge conflict. Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f Signed-off-by: Steven Sherk <steven.sherk@se-eng.com> Reviewed-on: https://gerrit.chromium.org/gerrit/65989 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Steve Sherk <ssherk70@gmail.com> Tested-by: Steve Sherk <ssherk70@gmail.com> (cherry picked from commit 20b0ba479b01755fbdc7f3dd9214e8af923402ba) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6539 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-14 22:55:57 +02:00
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
media->open(media);
cbfs: read cbfs offset and size from sysinfo This change allows libpayload to read cbfs offset and size from sysinfo. Legacy way of locating cbfs reagion is still supported in case sysinfo doesn't store the offset and the size. BUG=none BRANCH=master TEST=tested on samus and smaug Change-Id: I86434fd249467e7c90d59d6b82f0e6c514bc2d05 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 548a74b7a0758c3f9ba6809425d0fb9c6a5e9d7c Original-Change-Id: I190d5545a65228483204bf1aa1cbf5a80db31ae0 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/296993 Original-Commit-Ready: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11557 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-09-02 19:53:13 +02:00
while (offset < cbfs_end &&
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
media->read(media, &file, offset, sizeof(file)) == sizeof(file)) {
if (memcmp(CBFS_FILE_MAGIC, file.magic,
sizeof(file.magic)) != 0) {
libpayload: assume cbfs file alignment is 64 byte Change-Id: I8dfd8fbd452ce92fbca2cf095bc5e43e4a26969d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10920 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-14 22:29:04 +02:00
uint32_t new_align = CBFS_ALIGNMENT;
if (offset % CBFS_ALIGNMENT)
new_align += CBFS_ALIGNMENT -
(offset % CBFS_ALIGNMENT);
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
ERROR("ERROR: No file header found at 0x%xx - "
"try next aligned address: 0x%x.\n", offset,
offset + new_align);
offset += new_align;
continue;
}
libpayload: rename cbfs variable from name to vardata The dynamically sized region after struct cbfs_file doesn't contain only the file name anymore. Change-Id: I3241cb2f0cbec3fcf4d3c27d638e2847e43f4761 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11676 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-10 00:07:45 +02:00
vardata_len = ntohl(file.offset) - sizeof(file);
DEBUG(" - load entry 0x%x variable data (%d bytes)...\n",
offset, vardata_len);
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
// load file name (arbitrary length).
libpayload: rename cbfs variable from name to vardata The dynamically sized region after struct cbfs_file doesn't contain only the file name anymore. Change-Id: I3241cb2f0cbec3fcf4d3c27d638e2847e43f4761 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11676 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-10 00:07:45 +02:00
vardata = (const char*)media->map(
media, offset + sizeof(file), vardata_len);
if (vardata == CBFS_MEDIA_INVALID_MAP_ADDRESS) {
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
ERROR("ERROR: Failed to get filename: 0x%x.\n", offset);
libpayload: rename cbfs variable from name to vardata The dynamically sized region after struct cbfs_file doesn't contain only the file name anymore. Change-Id: I3241cb2f0cbec3fcf4d3c27d638e2847e43f4761 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11676 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-10 00:07:45 +02:00
} else if (strcmp(vardata, name) == 0) {
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
int file_offset = ntohl(file.offset),
file_len = ntohl(file.len);
cbfs_core.c: make cfbs searches even less verbose The cbfs core code would print out the name of the file it is searching for and when it is found would print out the name again. This contributes to a lot of unnecessary messages in a functioning payload’s output. Change this message to a DEBUG one so that it will only be printed when CONFIG_DEBUG_CBFS is enabled. Change-Id: Ib238ff174bedba8eaaad8d1d452721fcac339b1a Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3208 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-06 23:51:39 +02:00
DEBUG("Found file (offset=0x%x, len=%d).\n",
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
offset + file_offset, file_len);
libpayload: rename cbfs variable from name to vardata The dynamically sized region after struct cbfs_file doesn't contain only the file name anymore. Change-Id: I3241cb2f0cbec3fcf4d3c27d638e2847e43f4761 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11676 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-10 00:07:45 +02:00
media->unmap(media, vardata);
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
media->close(media);
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
handle->type = ntohl(file.type);
handle->media_offset = offset;
handle->content_offset = file_offset;
handle->content_size = file_len;
handle->attribute_offset =
ntohl(file.attributes_offset);
return handle;
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
} else {
libpayload: make searching for a file less verbose The cbfs core code would print out all unmatched file names when searching for a file. This contributes to a lot of unnecessary messages in the boot log. Change this message to a DEBUG one so that it will only be printed when CONFIG_DEBUG_CBFS is enabled. Change-Id: I34c747e0d3406351318abf70994dbc0bb3fa6c01 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3164 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com> Tested-by: build bot (Jenkins)
2013-05-01 15:40:13 +02:00
DEBUG(" (unmatched file @0x%x: %s)\n", offset,
libpayload: rename cbfs variable from name to vardata The dynamically sized region after struct cbfs_file doesn't contain only the file name anymore. Change-Id: I3241cb2f0cbec3fcf4d3c27d638e2847e43f4761 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11676 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-10 00:07:45 +02:00
vardata);
media->unmap(media, vardata);
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
}
// Move to next file.
libpayload: cbfs: fix infinite loop in cbfs_get_{handle,attr} cbfs_get_handle() and cbfs_get_attr() are both looping over elements to find a particular one. Each element header contains the element's length, which is used to compute the next element's offset. Invalid or corrupted CBFS files could lead to infinite loops where the offset would remain constant across iterations, due to 0-length elements or integer overflows in the computation of the next offset. This patch makes both functions more robust by adding a check that ensure offsets are strictly monotonic. Instead of infinite looping, the functions are now printing an ERROR and returning a NULL value. Change-Id: I440e82fa969b8c2aacc5800e7e26450c3b97c74a Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com> Found-by: Mayhem Reviewed-on: https://review.coreboot.org/c/coreboot/+/39177 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-03-01 05:03:54 +01:00
uint32_t next_offset = offset + ntohl(file.len) + ntohl(file.offset);
if (next_offset % CBFS_ALIGNMENT)
next_offset += CBFS_ALIGNMENT - (next_offset % CBFS_ALIGNMENT);
// Check that offset is strictly monotonic to prevent infinite loop
if (next_offset <= offset) {
ERROR("ERROR: corrupted CBFS file header at 0x%x.\n", offset);
break;
}
offset = next_offset;
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
}
media->close(media);
cbfs_core.c: make cfbs searches even less verbose The cbfs core code would print out the name of the file it is searching for and when it is found would print out the name again. This contributes to a lot of unnecessary messages in a functioning payload’s output. Change this message to a DEBUG one so that it will only be printed when CONFIG_DEBUG_CBFS is enabled. Change-Id: Ib238ff174bedba8eaaad8d1d452721fcac339b1a Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3208 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-06 23:51:39 +02:00
LOG("WARNING: '%s' not found.\n", name);
libpayload: cbfs: Fix minor memory leak in some edge cases cbfs_get_handle() allocates memory for a handle and doesn't free it if it errors out later, leaving the memory permanently leaked. Fix. Change-Id: Ide198105ce3ad6237672ff152b4490c768909564 Reported-by: Coverity Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16207 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-12 21:50:42 +02:00
free(handle);
libpayload: New CBFS to support multiple firmware media sources. Upgrade CBFS in libpayload to use new media-based implementation from coreboot ( http://review.coreboot.org/#/c/2182/ ). Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still supported, although the recommended way is to use new CBFS API. To migrate your existing x86 payload source: - Change cbfs_find to cbfs_get_file - Change cbfs_find_file to cbfs_get_file_content - Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument. Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH); => char *jpeg_data = cbfs_get_file_content( CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH); The legacy setup_cbfs_from_{ram,flash} is also supported, although the better equivalent is to make a new media instance: struct cbfs_media ram_media; init_cbfs_ram_media(&ram_media, start, size); char *data = cbfs_get_file_content(&ram_media, "myfile", my_type); Verified by being successfully linked with filo. Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2191 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-01-25 05:42:40 +01:00
return NULL;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
void *cbfs_get_contents(struct cbfs_handle *handle, size_t *size, size_t limit)
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
{
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
struct cbfs_media *m = &handle->media;
size_t on_media_size = handle->content_size;
int algo = CBFS_COMPRESS_NONE;
void *ret = NULL;
size_t dummy_size;
if (!size)
size = &dummy_size;
struct cbfs_file_attr_compression *comp =
cbfs_get_attr(handle, CBFS_FILE_ATTR_TAG_COMPRESSION);
if (comp) {
algo = ntohl(comp->compression);
DEBUG("File '%s' is compressed (alg=%d)\n", name, algo);
*size = ntohl(comp->decompressed_size);
/* TODO: Implement partial decompression with |limit| */
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
if (algo == CBFS_COMPRESS_NONE) {
libpayload: cbfs: Check decompressed size when loading files After loading compressed files in CBFS, we should check the decompressed size is equal to the expected size. This might help us detect file content corruption or compressor/decompressor bugs. BUG=none BRANCH=none TEST=manually (we can still boot into kernel on Kukui, and verify that loading files from CBFS still works by seeing ChromiumOS firmware screen). Change-Id: Ia756cc5477670dd0d1d8aa59d4160ab4233c6795 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31564 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-26 14:41:52 +01:00
if (limit != 0 && limit < on_media_size)
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
on_media_size = limit;
libpayload: cbfs: Check decompressed size when loading files After loading compressed files in CBFS, we should check the decompressed size is equal to the expected size. This might help us detect file content corruption or compressor/decompressor bugs. BUG=none BRANCH=none TEST=manually (we can still boot into kernel on Kukui, and verify that loading files from CBFS still works by seeing ChromiumOS firmware screen). Change-Id: Ia756cc5477670dd0d1d8aa59d4160ab4233c6795 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31564 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-26 14:41:52 +01:00
*size = on_media_size;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
void *data = m->map(m, handle->media_offset + handle->content_offset,
on_media_size);
if (data == CBFS_MEDIA_INVALID_MAP_ADDRESS)
return NULL;
libpayload: allow compression at file header level Decompression is handled transparently within cbfs_get_file_content: const char *name = "foo.bmp"; void *dst = cbfs_get_file_content(media, name, type, NULL); To keep things consistent, a couple of API changes were necessary: - cbfs_get_file_content always returns a copy of the data, even for uncompressed files. It's the callers responsibility to free the memory. - same for cbfs_load_payload and cbfs_find_file. - cbfs_load_optionrom doesn't take a "dest" argument anymore but always returns a copy of the data, for compressed and uncompressed files. Like with cbfs_get_file_content, the caller is responsible to free it. It also decompresses based on extended file attributes instead of the cbfs_optionrom subheader that libpayload specified but that (AFAIK) nobody ever used, given that there's not even tooling for that. Change-Id: If959e3dff9b93c6ae45ec7358afcc7840bc17218 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10938 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-07-10 00:07:45 +02:00
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
ret = malloc(*size);
libpayload: cbfs: Check decompressed size when loading files After loading compressed files in CBFS, we should check the decompressed size is equal to the expected size. This might help us detect file content corruption or compressor/decompressor bugs. BUG=none BRANCH=none TEST=manually (we can still boot into kernel on Kukui, and verify that loading files from CBFS still works by seeing ChromiumOS firmware screen). Change-Id: Ia756cc5477670dd0d1d8aa59d4160ab4233c6795 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31564 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-26 14:41:52 +01:00
if (ret != NULL) {
size_t final_size = cbfs_decompress(algo, data, on_media_size,
ret, *size);
if (final_size != *size) {
ERROR("Expect %zu bytes but got %zu bytes after "
"decompression.\n", *size, final_size);
free(ret);
ret = NULL;
}
libpayload: allow compression at file header level Decompression is handled transparently within cbfs_get_file_content: const char *name = "foo.bmp"; void *dst = cbfs_get_file_content(media, name, type, NULL); To keep things consistent, a couple of API changes were necessary: - cbfs_get_file_content always returns a copy of the data, even for uncompressed files. It's the callers responsibility to free the memory. - same for cbfs_load_payload and cbfs_find_file. - cbfs_load_optionrom doesn't take a "dest" argument anymore but always returns a copy of the data, for compressed and uncompressed files. Like with cbfs_get_file_content, the caller is responsible to free it. It also decompresses based on extended file attributes instead of the cbfs_optionrom subheader that libpayload specified but that (AFAIK) nobody ever used, given that there's not even tooling for that. Change-Id: If959e3dff9b93c6ae45ec7358afcc7840bc17218 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10938 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-07-10 00:07:45 +02:00
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
m->unmap(m, data);
return ret;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
void *cbfs_get_file_content(struct cbfs_media *media, const char *name,
int type, size_t *sz)
libpayload: bring in file attribute support from cbfstool This comes from cbfstool (GPL) into libpayload (BSD-l), but I could have just as well written it in libpayload first. Change-Id: I86baefe5c299125a4733fa20523efd5d06de7182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11675 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-16 18:53:40 +02:00
{
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
void *ret = NULL;
struct cbfs_handle *handle = cbfs_get_handle(media, name);
libpayload: bring in file attribute support from cbfstool This comes from cbfstool (GPL) into libpayload (BSD-l), but I could have just as well written it in libpayload first. Change-Id: I86baefe5c299125a4733fa20523efd5d06de7182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11675 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-16 18:53:40 +02:00
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
if (!handle)
libpayload: bring in file attribute support from cbfstool This comes from cbfstool (GPL) into libpayload (BSD-l), but I could have just as well written it in libpayload first. Change-Id: I86baefe5c299125a4733fa20523efd5d06de7182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11675 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-16 18:53:40 +02:00
return NULL;
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
if (handle->type == type)
ret = cbfs_get_contents(handle, sz, 0);
else
ERROR("File '%s' is of type %x, but we requested %x.\n", name,
handle->type, type);
free(handle);
return ret;
libpayload: bring in file attribute support from cbfstool This comes from cbfstool (GPL) into libpayload (BSD-l), but I could have just as well written it in libpayload first. Change-Id: I86baefe5c299125a4733fa20523efd5d06de7182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11675 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-16 18:53:40 +02:00
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
void *cbfs_get_attr(struct cbfs_handle *handle, uint32_t tag)
libpayload: bring in file attribute support from cbfstool This comes from cbfstool (GPL) into libpayload (BSD-l), but I could have just as well written it in libpayload first. Change-Id: I86baefe5c299125a4733fa20523efd5d06de7182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11675 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-16 18:53:40 +02:00
{
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
struct cbfs_media *m = &handle->media;
uint32_t offset = handle->media_offset + handle->attribute_offset;
uint32_t end = handle->media_offset + handle->content_offset;
struct cbfs_file_attribute attr;
void *ret;
libpayload: bring in file attribute support from cbfstool This comes from cbfstool (GPL) into libpayload (BSD-l), but I could have just as well written it in libpayload first. Change-Id: I86baefe5c299125a4733fa20523efd5d06de7182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11675 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-16 18:53:40 +02:00
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
/* attribute_offset should be 0 when there is no attribute, but all
* values that point into the cbfs_file header are invalid, too. */
if (handle->attribute_offset <= sizeof(struct cbfs_file))
libpayload: bring in file attribute support from cbfstool This comes from cbfstool (GPL) into libpayload (BSD-l), but I could have just as well written it in libpayload first. Change-Id: I86baefe5c299125a4733fa20523efd5d06de7182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11675 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-16 18:53:40 +02:00
return NULL;
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
m->open(m);
while (offset + sizeof(attr) <= end) {
if (m->read(m, &attr, offset, sizeof(attr)) != sizeof(attr)) {
ERROR("Failed to read attribute header %#x\n", offset);
m->close(m);
return NULL;
}
if (ntohl(attr.tag) != tag) {
libpayload: cbfs: fix infinite loop in cbfs_get_{handle,attr} cbfs_get_handle() and cbfs_get_attr() are both looping over elements to find a particular one. Each element header contains the element's length, which is used to compute the next element's offset. Invalid or corrupted CBFS files could lead to infinite loops where the offset would remain constant across iterations, due to 0-length elements or integer overflows in the computation of the next offset. This patch makes both functions more robust by adding a check that ensure offsets are strictly monotonic. Instead of infinite looping, the functions are now printing an ERROR and returning a NULL value. Change-Id: I440e82fa969b8c2aacc5800e7e26450c3b97c74a Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com> Found-by: Mayhem Reviewed-on: https://review.coreboot.org/c/coreboot/+/39177 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-03-01 05:03:54 +01:00
uint32_t next_offset = offset + ntohl(attr.len);
// Check that offset is strictly monotonic to prevent infinite loop
if (next_offset <= offset) {
ERROR("ERROR: corrupted CBFS attribute at 0x%x.\n", offset);
m->close(m);
return NULL;
}
offset = next_offset;
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
continue;
}
ret = m->map(m, offset, ntohl(attr.len));
if (ret == CBFS_MEDIA_INVALID_MAP_ADDRESS) {
ERROR("Failed to map attribute at %#x\n", offset);
m->close(m);
return NULL;
}
return ret;
libpayload: provide cbfs_file_find_attr() cbfs_file_find_attr(file, tag) finds the first attribute of file with the given tag. Change-Id: I78ee3b996b4b086605244c5d7d57ef7e3fc1db47 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11678 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-17 20:45:52 +02:00
}
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
m->close(m);
libpayload: provide cbfs_file_find_attr() cbfs_file_find_attr(file, tag) finds the first attribute of file with the given tag. Change-Id: I78ee3b996b4b086605244c5d7d57ef7e3fc1db47 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11678 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-17 20:45:52 +02:00
libpayload: cbfs: Add cbfs_handle API for more fine-grained accesses The libpayload CBFS APIs are pretty old and clunky, primarily because of the way the cbfs_media struct may or may not be passed in and may be initialized inside the API calls in a way that cannot be passed back out again. Due to this, the only real CBFS access function we have always reads a whole file with all metadata, and everything else has to build on top of that. This makes certain tasks like reading just a file attribute very inefficient on non-memory-mapped platforms (because you always have to map the whole file). This patch isn't going to fix the world, but will allow a bit more flexibility by bolting a new API on top which uses a struct cbfs_handle to represent a found but not yet read file. A cbfs_handle contains a copy of the cbfs_media needed to read the file, so it can be kept and passed around to read individual parts of it after the initial lookup. The existing (non-media) legacy API is retained for backwards compatibility, as is cbfs_file_get_contents() (which is most likely what more recent payloads would have used, and also a good convenience wrapper for the most simple use case), but they are now implemented on top of the new API. TEST=Booted Oak, made sure that firmware screens and software sync worked okay. Change-Id: I269f3979e77ae691ee9d4e1ab564eff6d45b7cbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14810 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-12 23:40:57 +02:00
return NULL;
libpayload: provide cbfs_file_find_attr() cbfs_file_find_attr(file, tag) finds the first attribute of file with the given tag. Change-Id: I78ee3b996b4b086605244c5d7d57ef7e3fc1db47 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11678 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-17 20:45:52 +02:00
}
libpayload: cbfs: Require input size and output size for cbfs_decompress Currently, cbfs_decompress() calls ulzma() and ulz4f() for LZMA/LZ4 decompression. These two functions don't accept input/output size as parameters. We can make cbfs_decompress more robust by calling ulzman() and ulz4fn() instead. This could prevent us from overflowing destination buffer. BUG=none BRANCH=none TEST=boot into kernel on Kukui with COMPRESSED_PAYLOAD_LZMA / COMPRESSED_PAYLOAD_LZ4. Change-Id: Ibe617825bd000ed618791d8e3c5f65bbbd5f7e33 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
2019-02-27 08:29:15 +01:00
size_t cbfs_decompress(int algo, const void *src, size_t srcn, void *dst,
size_t dstn)
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
{
libpayload: cbfs: Require input size and output size for cbfs_decompress Currently, cbfs_decompress() calls ulzma() and ulz4f() for LZMA/LZ4 decompression. These two functions don't accept input/output size as parameters. We can make cbfs_decompress more robust by calling ulzman() and ulz4fn() instead. This could prevent us from overflowing destination buffer. BUG=none BRANCH=none TEST=boot into kernel on Kukui with COMPRESSED_PAYLOAD_LZMA / COMPRESSED_PAYLOAD_LZ4. Change-Id: Ibe617825bd000ed618791d8e3c5f65bbbd5f7e33 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
2019-02-27 08:29:15 +01:00
size_t len;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
switch (algo) {
case CBFS_COMPRESS_NONE:
libpayload: cbfs: Require input size and output size for cbfs_decompress Currently, cbfs_decompress() calls ulzma() and ulz4f() for LZMA/LZ4 decompression. These two functions don't accept input/output size as parameters. We can make cbfs_decompress more robust by calling ulzman() and ulz4fn() instead. This could prevent us from overflowing destination buffer. BUG=none BRANCH=none TEST=boot into kernel on Kukui with COMPRESSED_PAYLOAD_LZMA / COMPRESSED_PAYLOAD_LZ4. Change-Id: Ibe617825bd000ed618791d8e3c5f65bbbd5f7e33 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
2019-02-27 08:29:15 +01:00
len = MIN(srcn, dstn);
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
memcpy(dst, src, len);
CBFS: Change the signature of cbfs_decompress. Instead of returning 0 on success and -1 on error, return the decompressed size of the data on success and 0 on error. The decompressed size is useful information to have that was being thrown away in that function. Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3578 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-07-01 13:57:37 +02:00
return len;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
#ifdef CBFS_CORE_WITH_LZMA
case CBFS_COMPRESS_LZMA:
libpayload: cbfs: Require input size and output size for cbfs_decompress Currently, cbfs_decompress() calls ulzma() and ulz4f() for LZMA/LZ4 decompression. These two functions don't accept input/output size as parameters. We can make cbfs_decompress more robust by calling ulzman() and ulz4fn() instead. This could prevent us from overflowing destination buffer. BUG=none BRANCH=none TEST=boot into kernel on Kukui with COMPRESSED_PAYLOAD_LZMA / COMPRESSED_PAYLOAD_LZ4. Change-Id: Ibe617825bd000ed618791d8e3c5f65bbbd5f7e33 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
2019-02-27 08:29:15 +01:00
return ulzman(src, srcn, dst, dstn);
cbfs: Add LZ4 in-place decompression support for pre-RAM stages This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-29 22:51:35 +02:00
#endif
#ifdef CBFS_CORE_WITH_LZ4
case CBFS_COMPRESS_LZ4:
libpayload: cbfs: Require input size and output size for cbfs_decompress Currently, cbfs_decompress() calls ulzma() and ulz4f() for LZMA/LZ4 decompression. These two functions don't accept input/output size as parameters. We can make cbfs_decompress more robust by calling ulzman() and ulz4fn() instead. This could prevent us from overflowing destination buffer. BUG=none BRANCH=none TEST=boot into kernel on Kukui with COMPRESSED_PAYLOAD_LZMA / COMPRESSED_PAYLOAD_LZ4. Change-Id: Ibe617825bd000ed618791d8e3c5f65bbbd5f7e33 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
2019-02-27 08:29:15 +01:00
return ulz4fn(src, srcn, dst, dstn);
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
#endif
default:
libpayload: cbfs: Require input size and output size for cbfs_decompress Currently, cbfs_decompress() calls ulzma() and ulz4f() for LZMA/LZ4 decompression. These two functions don't accept input/output size as parameters. We can make cbfs_decompress more robust by calling ulzman() and ulz4fn() instead. This could prevent us from overflowing destination buffer. BUG=none BRANCH=none TEST=boot into kernel on Kukui with COMPRESSED_PAYLOAD_LZMA / COMPRESSED_PAYLOAD_LZ4. Change-Id: Ibe617825bd000ed618791d8e3c5f65bbbd5f7e33 Signed-off-by: You-Cheng Syu <youcheng@google.com> Reviewed-on: https://review.coreboot.org/c/31606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
2019-02-27 08:29:15 +01:00
ERROR("tried to decompress %zu bytes with algorithm "
"#%x, but that algorithm id is unsupported.\n",
srcn, algo);
CBFS: Change the signature of cbfs_decompress. Instead of returning 0 on success and -1 on error, return the decompressed size of the data on success and 0 on error. The decompressed size is useful information to have that was being thrown away in that function. Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3578 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-07-01 13:57:37 +02:00
return 0;
libpayload: Add liblzma, libcbfs Add cbfs core from coreboot into libpayload, and to support lzma decode, add coreboot's lzma code, too. Carl-Daniel agreed to relicense the lzmadecode wrapper as BSD-l, solving licensing problems. Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/115 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marcj303@gmail.com>
2011-07-21 15:43:14 +02:00
}
}