Age | Commit message (Collapse) | Author |
|
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>
|
|
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: I5b93e5321e470f19ad22ca2cfdb1ebf3b340b252
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4659
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
The ram_media.c file is being compiled, however the
global functions were not exposed through a header.
Change-Id: I4588fbe320c29051566cef277bf4d20a83abf853
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56642
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4194
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Prettier in real-world payloads (ie. FILO)
Change-Id: I9ed968fe527c5d46090e707e2d89b7406a43662e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3887
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
For reasons explained in a previous CL, it might be necessary to "load" a file
from CBFS in place. The loading code in CBFS was, however, zeroing the area of
memory the stage was about to be loaded into. When the CBFS data is located
elsewhere this works fine, but when it isn't you end up clobbering the data
you're trying to load. Also, there's no reason to zero memory we're about to
load something into or have just loaded something into. This change makes it
so that we only zero out the portion of the memory between what was
loaded/decompressed and the final size of the stage in memory.
Change-Id: If34df16bd74b2969583e11ef6a26eb4065842f57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3579
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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>
|
|
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>
|
|
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)
|
|
libcbfs was using printf for size_t typed variables. However, printf
did not support printing those. This patch fixes the issue, removing
the warning when compiling ram_media.c
libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]
libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat]
Change-Id: Iaf6e723f9a5b0a61a39d3125036fee9853e37ba8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2904
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change "ERROR" to "WARNING" -- not finding the indicated file is usually
not a fatal error.
Change-Id: I0600964360ee27484c393125823e833f29aaa7e7
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2833
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Three issues:
1. the hardcoded dereferenced pointer at 0xfffffffc
2. "RAM media" has no idea about ROM relative addresses
3. off-by-one in RAM media: it's legal to request 4 bytes from 0xfffffffc
Change-Id: I671ac12d412c71dc8e8e6114f2ea13f58dd99c1d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2624
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
Cherry-picking CBFS fix from http://review.coreboot.org/#/c/2292/
For x86, the old CBFS search behavior was to bypass bootblock and we should keep
that. This will speed up searching if a file does not exist in CBFS.
For arm, the size in header is correct now so we can remove the hack by
CONFIG_ROM_SIZE.
Change-Id: I286ecda73bd781550e03b0b817ed3fb567d6b8d7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2458
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
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>
|
|
Change-Id: Ic3164fbffd8da6bd9d506d80e425ad89efc0f1af
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2144
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
The endianness of an architecture is now set up automatically using Kconfig
and some common code. The available conversion functions were also expanded
to go to or from a particular endianness. Those use the abbreviation le or be
for little or big endian.
Built for Stumpy and saw coreinfo cbfs support work which uses network
byte order. Used the functions which convert to little endian to implement an
AHCI driver. The source arch is also little endian, so they were effectively
(and successfully) inert.
Change-Id: I3a2d2403855b3e0e93fa34f45e8e542b3e5afeac
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/1719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Two new functions allow switching the CBFS functions from using RAM
or ROM, with ROM as default.
Change-Id: I04d67ad622d25c5728ae9a63f5b8a3dc9bbacce6
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/550
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I66e535f77e513dbfa5fc906ecf288193af78ae62
Signed-off-by: Florian Zumbiehl <florz@florz.de>
Reviewed-on: http://review.coreboot.org/369
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Keep in sync with coreboot's version.
Change-Id: I8a253446bd3b2ce9d05c6076a3f49f0260ecd5f9
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/158
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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>
|