clang requires some additional options to disable warnings which
can be handled by xcompile.
Also drop the hard coded clang compilers in Makefile
Change-Id: I0f12f755420f315127e6d9adc00b1246c6e7131b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7612
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of fetching libgcc's location and required compiler flags on every
individual build, do it once in xcompile.
Change-Id: Ie5832fcb21710c4cf381ba475589d42ce0235f96
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/10425
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This uses the availability of CONFIG_* variables in .xcompile and tests for
compilers in xcompile so that the build system doesn't need to probe them.
Change-Id: I359ad6245d2527efa7e848a9b38f5f194744c827
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/10424
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is in preparation of adding support for clang to xcompile.
Change-Id: I518d077f134610082b0939b1525682f2289eec34
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10423
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
crossgcc builds gmp, whose build system normally optimises for the hardware
it's built on. That may give a minor performance boost but has the downside
that the compiler becomes non-portable and may break on other systems due to
illegal instructions.
Setting CFLAGS to some reasonable value prevents gmp's configure script from
choosing CPU specific -mtune flags (which may enable optimizations that only
run on CPUs with the same feature set).
Enabling "fat" builds make the build system add all optimized assembler
routines and makes the selection of the right one a runtime decision instead
of deciding at compile time.
Change-Id: I72d20627270baa082cd02ebb4c9a09cd23f30f8c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10412
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbfs_get_file_content was replaced with cbfs_boot_map_with_leak but
36f8d27ea9 failed to get it into account.
Change-Id: I0c7840043b2ea6abaf8e70f4bf1a63c96aedebc1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10403
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Previously I tried to see if Linux think that port 0x60 is in use by keyboard.
Unfortunately it always thinks that it is. Instead just base off real input
busses used.
Change-Id: I4bb744938f623d29f38396165a1694fee78c3d32
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10376
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
It was reversed between Lenovo and non-Lenovo cases.
Change-Id: I52c3b928abda2851e97ec0b40b7da5c5191217f5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10374
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Apple is named Apple Inc in DMI but is "apple" in coreboot naming.
For other vendors we should follow similar pattern.
Change-Id: I7975b19faaf942c5bd44a704bcee994815499ceb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10372
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This allow an easy creation of standalone "autoport pack".
Change-Id: Ibe9e38aa3b4bbd7260104e1c2a11630790ff4d2f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10370
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This should be able to generate bootable ports for sandy/ivy, possible with
minor fixes. Howto is in readme.md
Change-Id: Ia126cf0939ef2dc2cdbb7ea100d2b63ea6b02f28
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7131
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Change-Id: Ibc06b17f48f72d5f9931437ffce020023ece2445
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10328
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Follow up for commit b890a12, some contributions brought
back a number of FSF addresses, so get rid of them again.
Change-Id: I0ac0c957738ce512deb0ed82b2219ef90d96d46b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10322
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
We updated the source files, but not the precompiled results.
Change-Id: I49634409d01c8d7cf841944e01d36571ae66c0ac
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10296
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Because new images place the bootblock in a separate region from the
primary CBFS, performing an update-fit operation requires reading an
additional section and choosing a different destination for the write
based on the image type. Since other actions are not affected by these
requirements, the logic for the optional read and all writing is
implemented in the cbfs_update_fit() function itself, rather than
relying on the main() function for writing as the other actions do.
Change-Id: I2024c59715120ecc3b9b158e007ebce75acff023
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10137
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Useful for autoport and other gfx-related developpement.
Change-Id: I1fc0952bc30ab15cd39a4f0c00649714dcf318f3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10276
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Currently, when the remote master branch of the board-status
repository changes between cloning and pushing, `git push origin`
fails.
This race condition happens quite often with REACTS testing commits at
the same time on different systems.
If that happens, just download the objects and refs from the
board-status repository and rebase the local changes on it. Try that
three times before exiting with an error message.
Change-Id: I628ebce54895f44be6232b622d56acbcc421b847
Helped-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Helped-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10262
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Fix up commit 1b6e7a67 (Updates to the board status script) forgetting
to put `echo` in front of the string.
Change-Id: I7d4dfcc62545dfee2073410ba47489318a9bf5c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10265
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Instead of writing to the source tree (which we should generally avoid),
copy the pre-generated files (from lex and yacc) to $(objutil). Adapt
include paths and rules so they're found.
Change-Id: Id33be6d1dccf9a1b5857a29c55120dcc8f8db583
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10252
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
While logical, make's handling of multiple targets in a rule isn't
intuitive, and was done wrong in cbfstool's Makefile.
%.c %.h: %.l encourages make to run the rule twice, once to
generate the .c file, once for the .h file. Hilarity ensues.
Change-Id: I2560cb34b6aee5f4bdd764bb05bb69ea2789c7d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10251
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These names will skip the lint-whitespace tests.
Change-Id: If4ac1f8e11fd0ac62f09696f2704477b6eb30046
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10212
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
add handling of PCI IDs for Broadwell-U/Wildcat Point LP,
using same functions as Haswell-U/Lynx Point LP
Change-Id: I1094cbdace3c73f0f85c2e27c676b877b1a04bfe
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/10209
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Our style discourages unnecessary typedefs, and this one doesn't gain
us anything, nor is it consistent with the surrounding code: there's
a function pointer typedef'd nearby, but non-opaque structs aren't.
BUG=chromium:482652
TEST=None
BRANCH=None
Change-Id: Ie7565240639e5b1aeebb08ea005099aaa3557a27
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Change-Id: I4285e6b56f99b85b9684f2b98b35e9b35a6c4cb7
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10146
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The cbfstool handling of new-style FMAP-driven "partitioned" images
originally disallowed the use of x86-style top-aligned addresses with
the add.* and layout actions because it wasn't obvious how they should
work, especially since the normal addressing is done relative to each
individual region for these types of images. Not surprisingly,
however, the x86 portions of the build system make copious use of
top-aligned addresses, so this allows their use with new images and
specifies their behavior as being relative to the *image* end---not
the region end---just as it is for legacy images.
Change-Id: Icecc843f4f8b6bb52aa0ea16df771faa278228d2
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10136
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These new-style firmware images use the FMAP of the root of knowledge
about their layout, which allows them to have sections containing raw
data whose offset and size can easily be determined at runtime or when
modifying or flashing the image. Furthermore, they can even have
multiple CBFSes, each of which occupies a different FMAP region. It is
assumed that the first entry of each CBFS, including the primary one,
will be located right at the start of its region. This means that the
bootblock needs to be moved into its own FMAP region, but makes the
CBFS master header obsolete because, with the exception of the version
and alignment, all its fields are redundant once its CBFS has an entry
in the FMAP. The version code will be addressed in a future commit
before the new format comes into use, while the alignment will just be
defined to 64 bytes in both cbfstool and coreboot itself, since
there's almost no reason to ever change it in practice. The version
code field and all necessary coreboot changes will come separately.
BUG=chromium:470407
TEST=Build panther and nyan_big coreboot.rom and image.bin images with
and without this patch, diff their hexdumps, and note that no
locations differ except for those that do between subsequent builds of
the same codebase. Try working with new-style images: use fmaptool to
produce an FMAP section from an fmd file having raw sections and
multiple CBFSes, pass the resulting file to cbfstool create -M -F,
then try printing its layout and CBFSes' contents, add and remove CBFS
files, and read and write raw sections.
BRANCH=None
Change-Id: I7dd2578d2143d0cedd652fdba5b22221fcc2184a
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 8a670322297f83135b929a5b20ff2bd0e7d2abd3
Original-Change-Id: Ib86fb50edc66632f4e6f717909bbe4efb6c874e5
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265863
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10135
Tested-by: build bot (Jenkins)
The rules didn't actually trigger to rebuild the parser.
Change-Id: Id51aaa9816b069204c119622d60f7b728b762cad
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10168
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
They're essentially collected on a stack before they're
parsed. So we push them backwards, then parse them in
the correct order.
Change-Id: Ibf29559389cd19f260d67bae8e0b5ef9f4f58d91
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10169
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Change-Id: Iaec748b4bdbb5da287520fbbd7c3794bf664eff6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10161
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Sol Boucher <solb@chromium.org>
Fine tune the following two checks:
- Check for incorrect file permissions
This one had a linux path hard coded, so it would choke on
some commits unnecessarily.
- FILE_PATH_CHANGES seems to not be working correctly. It will
choke on added / deleted files even if the MAINTAINERS file
is touched. Hence, switch from WARN to CHK (as WARN currently
blocks commits as well)
Change-Id: I9fccfbd75e94f420de45cf8b58071e3198065cf3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10123
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The fmd compiler now processes "(CBFS)" annotations, distilling them
into a comma-separated list of the names of sections containing
CBFSes. This list is the only thing printed to standard output to
enable easy capture and machine consumption by other tools.
Additionally, the ability to generate a tiny header with a define for
the primary CBFS's size is implemented and can be requested via a
new command-line switch.
Here's an example of how to use the new features:
$ ./fmaptool -h layout.h layout_arm_8192.fmd layout.fmap 2>/dev/null
FW_MAIN_A,FW_MAIN_B,COREBOOT
The hypothetical fmd file contains three sections annotated as (CBFS),
the names of which are printed to standard output. As before, a binary
FMAP file named layout.fmap is created; however, because the command
was invoked with -h, a header #define ing the offset of its FMAP
section (i.e. where it will be relative to the base of flash once the
boot image is assembled) is also generated.
BUG=chromium:470407
TEST=Verify that fmd files without a "COREBOOT" section or with one
that isn't annotated as "(CBFS)" are not accepted. Ensure that the
list of CBFS sections matches the descriptor file's annotations and
is led by the "COREBOOT" section. Invoke with the header generation
switch and check that output file for reasonableness.
BRANCH=None
Change-Id: I496dd937f69467bfd9233c28df59c7608e89538f
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 9227698adecf675770b2983380eb570676c2b5d2
Original-Change-Id: I8b32f6ef19cabe2f6760106e676683c4565bbaad
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262956
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9967
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The tool now makes use of the ERROR() macros from common.h.
Change-Id: Ie38f40c65f7b6d3bc2adb97e246224cd38d4cb99
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10048
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The buffer API that cbfstool uses to read and write files only directly supports
one-shot operations on whole files. This adds an intermediate partitioned_file
module that sits on top of the buffer system and has an awareness of FMAP
entries. It provides an easy way to get a buffer for an individual region of a
larger image file based on FMAP section name, as well as incrementally write
those smaller buffers back to the backing file at the appropriate offset. The
module has two distinct modes of operation:
- For new images whose layout is described exclusively by an FMAP section, all
the aforementioned functionality will be available.
- For images in the current format, where the CBFS master header serves as the
root of knowledge of the image's size and layout, the module falls back to a
legacy operation mode, where it only allows manipulation of the entire image
as one unit, but exposes this support through the same interface by mapping
the region named SECTION_NAME_PRIMARY_CBFS ("COREBOOT") to the whole file.
The tool is presently only ported onto the new module running in legacy mode:
higher-level support for true "partitioned" images will be forthcoming. However,
as part of this change, the crusty cbfs_image_from_file() and
cbfs_image_write_file() abstractions are removed and replaced with a single
cbfs_image function, cbfs_image_from_buffer(), as well as centralized image
reading/writing directly in cbfstool's main() function. This reduces the
boilerplate required to implement each new action, makes the create action much
more similar to the others, and will make implementing additional actions and
adding in support for the new format much easier.
BUG=chromium:470407
TEST=Build panther and nyan_big coreboot.rom images with and without this patch
and diff their hexdumps. Ensure that no differences occur at different locations
from the diffs between subsequent builds of an identical source tree. Then flash
a full new build onto nyan_big and watch it boot normally.
BRANCH=None
Change-Id: I25578c7b223bc8434c3074cb0dd8894534f8c500
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 7e1c96a48e7a27fc6b90289d35e6e169d5e7ad20
Original-Change-Id: Ia4a1a4c48df42b9ec2d6b9471b3a10eb7b24bb39
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265581
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10134
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This allows calls to buffer_delete() to work on a buffer that has been
buffer_seek()ed or the buffer created by a buffer_splice(). The same
information could also be useful for other purposes, such as writing
slices back to a file at the offset they originally occupied.
BUG=chromium:470407
TEST=Attempt to perform the following sequence of buffer actions, then run it
through valgrind to check for memory errors:
for (int pos = 0; pos <= 3; ++pos) {
struct buffer seek_test;
buffer_create(&seek_test, 3, "seek_test");
if (pos == 0) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 1) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 2) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 3) {
buffer_delete(&seek_test);
continue;
}
}
for (int pos = 0; pos <= 14; ++pos) {
struct buffer slice_test;
buffer_create(&slice_test, 3, "slice_test");
if (pos == 0) {
buffer_delete(&slice_test);
continue;
}
struct buffer sliced_once;
buffer_splice(&sliced_once, &slice_test, 1, 2);
if (pos == 1) {
buffer_delete(&slice_test);
continue;
}
if (pos == 2) {
buffer_delete(&sliced_once);
continue;
}
struct buffer sliced_twice;
buffer_splice(&sliced_twice, &sliced_once, 2, 1);
if (pos == 3) {
buffer_delete(&slice_test);
continue;
}
if (pos == 4) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 5) {
buffer_delete(&sliced_twice);
continue;
}
struct buffer sliced_same;
buffer_splice(&sliced_same, &slice_test, 1, 1);
if (pos == 6) {
buffer_delete(&slice_test);
continue;
}
if (pos == 7) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 8) {
buffer_delete(&sliced_twice);
continue;
}
if (pos == 9) {
buffer_delete(&sliced_same);
continue;
}
struct buffer sliced_thrice;
buffer_splice(&sliced_thrice, &sliced_twice, 1, 0);
if (pos == 10) {
buffer_delete(&slice_test);
continue;
}
if (pos == 11) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 12) {
buffer_delete(&sliced_twice);
continue;
}
if (pos == 13) {
buffer_delete(&sliced_same);
continue;
}
if (pos == 14) {
buffer_delete(&sliced_thrice);
continue;
}
}
BRANCH=None
Change-Id: Id67734654a62302c0de37746d8a978d49b240505
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 00c40982a21a91a488587dd3cead7109f3a30d98
Original-Change-Id: Ie99839d36500d3270e4924a3477e076a6d27ffc8
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/267467
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10133
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, this function allowed one to pass a size of 0 in order to
indicate that the entire buffer should be copied. However, the
semantics of calling it this way were non-obvious: The desired
behavior was clear when the offset was also 0, but what was the
expected outcome when the offset was nonzero, since carrying over the
original size in this case would be an error? In fact, it turns out
that it always ignored the provided offset when the size was zero.
This commit eliminates all special handling of 0; thus, the resulting
buffer is exactly as large as requested, even if it's degenerate.
Since the only consumer that actually called the function with a size
of 0 was buffer_clone(), no other files required changes.
Change-Id: I1baa5dbaa7ba5bd746e8b1e08816335183bd5d2d
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10132
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The only operation performed on this struct turned out to be sizeof...
Change-Id: I619db60ed2e7ef6c196dd2600dc83bad2fdc6a55
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10131
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patches a memory leak on every struct cbfs_image creation that
was introduced by c1d1fd850e. Since that
commit, the CBFS master header has been copied to a separate buffer so
that its endianness could be fixed all at once; unfortunately, this
buffer was malloc()'d but never free()'d. To address the issue, we
replace the structure's struct cbfs_header * with a struct cbfs_header
to eliminate the additional allocation.
Change-Id: Ie066c6d4b80ad452b366a2a95092ed45aa55d91f
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10130
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The function hadn't been updated to account for the fact that we now
copy an endianness-corrected CBFS master header into a separate buffer
from the CBFS data: it still performed pointer arithmetic accross the
two buffers and wrote the copied buffer into the image without
restoring the original endianness.
Change-Id: Ieb2a001f253494cf3a90d7e19cd260791200c4d3
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10122
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the recent rename of documentation -> Documentation, the
checkpatch.pl script broke. Fix the tree check, and change the
user visible output of "kernel" to coreboot.
Change-Id: I34f538d4436e468b1c91eb36aa2f60a2a3308111
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10125
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds a compiler for a language whose textual representation of flashmap
regions will be used to describe the layout of flash chips that contain more
than just a single CBFS. Direct integration with cbfstool (via a new
command-line switch for the create action) is forthcoming but will be added
separately.
BUG=chromium:461875
TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for
panther. Using the latter file as a reference, write a corresponding
fmap.fmd file and feed it through fmaptool. Run both binary output files
though the flashmap project's own flashmap_decode utility. Observe only
the expected differences.
BRANCH=None
Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142
Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255031
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9942
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is being fixed in a separate commit so we can diff against the
library as it existed in its own repo.
Change-Id: Id87cd8f4e015a5ed7dd8a19302cc22ab744fefe8
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10141
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
flashmap was developed in a separate repository until now.
Import the files from the 2012 version of the project [1].
[1] https://code.google.com/p/flashmap
BUG=chromium:461875
TEST=None
BRANCH=None
Change-Id: Ida33f81509abc1cf2e532435adbbf31919d96bd8
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: f44e1d1864babe244f07ca49655f0b80b84e890d
Original-Change-Id: Ibf191d34df738449c9b9d7ebccca3d7f4150d4d3
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254801
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9940
Tested-by: build bot (Jenkins)
This fixes an inconsistency between `cbfstool create` and `cbfstool add` that
was resulting in confusing claims about the amount of free space at the end of a
CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file
entry by testing whether it would collide with the beginning of the *subsequent*
file header; thus, if a file's end is unaligned, its reported size will not
match the actual available capacity. Although deleted entries always end on an
alignment boundary because `cbfstool remove` expands them to fill the available
space, `cbfstool create` doesn't necessarily size a new entries region to result
in an empty entry with an aligned end.
This problem never resulted in clobbering important data because cbfstool would
blindly reserve 64B (or the selected alignment) of free space immediately after
the all-inclusive empty file entry. This change alters the way this reservation
is reported: only the overhang past the alignment is used as hidden padding, and
the empty entry's capacity is always reported such that it ends at an aligned
address.
Much of the time that went into this patch was spent building trust in the
trickery cbfstool employs to avoid explicitly tracking the image's total
capacity for entries, so below are two proofs of correctness to save others time
and discourage inadvertent breakage:
OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS
empty file header is small enough that it won't cross another aligned address.
OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such
that its contents end on an aligned address.
THM. 1: Placing a new file within an empty entry located below an existing file
entry will never leave an aligned flash address containing neither the beginning
of a file header nor part of a file.
We can prove this by contradiction: assume a newly-added file neither fills to
the end of the preexisting empty entry nor leaves room for another aligned
empty header after it. Then the first aligned address after the end of the
newly-inserted file...
- CASE 1: ...already contains a preexisting file entry header.
+ Then that address contains a file header.
- CASE 2: ...does not already house a file entry header.
+ Then because CBFS content doesn't fall outside headers, the area between
there and the *next* aligned address after that is unused.
+ By (A), we can fit a file header without clobbering anything.
+ Then that address now contains a file header.
THM. 2: Placing a new file in an empty entry at the very end of the image such
that it fits, but leaves no room for a final header, is guaranteed not to change
the total amount of space for entries, even if that new file is later removed
from the CBFS.
Again, we use contradiction: assume that creating such a file causes a
permanent...
- CASE 1: ...increase in the amount of available space.
+ Then the combination of the inserted file, its header, and any padding
must have exceeded the empty entry in size enough for it to cross at
least one additional aligned address, since aligned addresses are how
the limit on an entry's capacity is determined.
+ But adding the file couldn't have caused us to write past any further
aligned addresses because they are the boundary's used when verifying
that sufficient capacity exists; furthermore, by (B), no entry can ever
terminate beyond where the initial empty entry did when the CBFS was
first created.
+ Then the creation of the file did not result in a space increase.
- CASE 2: ...decrease in the amount of available space.
+ Then the end of the new file entry crosses at least one fewer aligned
address than did the empty file entry.
+ Then by (A), there is room to place a new file entry that describes the
remaining available space at the first available aligned address.
+ Then there is now a new record showing the same amount of available space.
+ Then the creation of the file did not result in a space decrease.
BUG=chromium:473726
TEST=Had the following conversation with cbfstool:
$ ./cbfstool test.image create -s 0x100000 -m arm
Created CBFS image (capacity = 1048408 bytes)
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 null 1048408
$ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1
1+0 records in
1+0 records out
1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big?
E: Failed to add 'toobigmed.bin' into ROM image.
$ truncate -s -1 toobigmed.bin
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
toobig 0x40 raw 1048408
$ ./cbfstool test.image remove
-n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
BRANCH=None
Change-Id: I118743e37469ef0226970decc900db5d9b92c5df
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e
Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263962
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9939
Tested-by: build bot (Jenkins)
Add a Linux style MAINTAINERS file and the get_maintainer.pl
script from the Linux kernel source (adapted to work in the
coreboot source tree)
Change-Id: I983e30c20c371d238cfa7c0a074587b731387c63
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10021
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
We have discussed dropping lbtdump since 2007, since it was obsoleted
by lxbios (nowadays aka nvramtool) back then.
http://www.coreboot.org/pipermail/coreboot/2007-August/024188.html
Well, it's only eight years later.
Change-Id: I5242118cd3763d1b8c4bdc6f023cf93ae1b5b85d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10121
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility is AMD SC520 specific (and AMD SC520 support has been
dropped from coreboot)
Change-Id: I8ebd52c2e6af113d2110c106f88fdd7c0a672c98
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility was useful on older VIA Epia-M boards, which we
have dropped from the tree a while ago. Hence drop the utility
as well.
Change-Id: Ie0d6303f4f4cfb6b21cd90696c60e124f0a5f4d8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10119
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The Kconfig option list generator was broken by two different changes
to the project in the last few years:
- the switch to git from svn
- allowing wild card includes in Kconfig
Change-Id: I6bc5024a04958e9718d2e3a3a3bb6d69d4277eb6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10115
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This tool has had its own repository since a long time:
https://code.google.com/p/i915tool/
Drop the obsolete copy we kept in the tree.
Change-Id: Idee4ea3423453f6ced6e95c0bd2e45d95ca61851
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10114
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility links in coreboot code, and has been broken for a long
time. These changes get it to compile again.
Change-Id: I69445a8b3cbfc9a2b560c68b8de2e080837ec502
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10112
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility was only used to debug the initial ARM Chromebook bringup,
but it's not really useful anymore.
Change-Id: Icff0a80f244adae3c35a8430c54de9e415fbd7d0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10111
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
OpenBSD refuses to implement it due to security concerns,
so use glob instead.
Change-Id: I7531cfe91deff240f7874d94d5acb340b87e51b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10028
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The file have been updated to warn wiki users to edit
the page as it is generated by a bot.
Change-Id: I5802ff8c7986c0fd93adf58e2353df81de9c2b75
Signed-off-by: David Englund <public@beloved.name>
Reviewed-on: http://review.coreboot.org/8682
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Patrick Georgi <pgeorgi@google.com>
Currently `xcompile` generates `.xcompile` with the following at the
top.
# platform agnostic and host tools
IASL:=iasl
HOSTCC:=gcc
The assignment `:=` doesn’t allow to override the variable. So use `?=`
instead so the host compiler can be passed to coreboot.
HOSTCC=gcc-5 make
Note, that this is just a hack, as the existence of `gcc` is checked
beforehand.
Change-Id: Iebf3e43eb7eaffa7cf0efe97710d9feb3fe2a989
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/9457
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If the buildgcc is interrupt by Ctrl-C, probably part of
an archive is downloaded. If we run buildgcc again, the
incomplete archive would be considered as cached file
and skipped.
We check file hashes to see if the file is complete. If test
is failed, we need to delete the partially-downloaded file
and download it again.
sha1sum is quite different among the distributions.
Only Linux, Cygwin, Darwin have been tested.
Once new archive is deployed, a new checksum would be created,
which should be uploaded along with the script buildgcc.
Change-Id: Ibb1aa25a0374f774e1e643fe5e698de7bf7cc418
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4511
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Commit 0e53931f (cbfstool: Clean up in preparation for adding new
files) split out the flags and introduced the variable `LINKFLAGS`.
Rename it to `LDFLAGS` which is more commonly used.
Change-Id: Ib6299f8ef5cf30dbe05bfae36f30ae4371f0a738
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10064
Tested-by: build bot (Jenkins)
Reviewed-by: Sol Boucher <solb@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
People were confused about the 'missing toolchain', so
improve the error message.
Change-Id: Icaee338aeedce2255bcfdafe5407c9df02ad9c4a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10036
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Add additional FSP timestamp values to cbmem.h and specify values for
the existing ones. Update cbmem.c with the FSP timestamp values and
descriptions.
BRANCH=none
BUG=None
TEST=Build for Braswell and Skylake boards using FSP 1.1.
Change-Id: I835bb090ff5877a108e48cb60f8e80260773771b
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10025
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Since FreeBSD doesn't have libdl, these errors are shown:
- config.log: /usr/bin/ld: cannot find -ldl
- crossgcc-build.log: configure: error: C compiler cannot create executables
Conditionally pass the presence of libdl in LDFLAGS.
Change-Id: I79c48da7e6700a4606c9e0c1314241db8997d3f3
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/2342
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When installing git hooks through $(MAKE) gitconfig,
make knows itself (and is a GNU make). So let it splice
itself into hooks where necessary by replacing %MAKE%.
Change-Id: Iaf778bfa3f17a8fe31312f871571ed89a9de5385
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10018
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
No need to enforce GNU versions for them.
Change-Id: Ieeb43298331fbefbcc1e230d41a90e9df56993eb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It now assumes that origin points to the official repo (while there may
be more) and doesn't assume anymore that there's a user ID that needs to
be pruned (although it is, if present).
Change-Id: Id4c5ee2cb7c08e997eaba1c750097a2e2bf51af5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10016
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fixes building cbfstool in 32bit environments.
Change-Id: I3c94afc9c961eb8b41d1e08f4a16e5cab2a6bb8b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/10015
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The mips toolchain used by coreboot so far comes from Chrome OS chroot
and is built explicitly for little endian code generation.
Other flavors of MIPS toolchain usually generate big endian code by
default and require command line options to switch to little endian
mode.
This patch adds another variable to the set of compiler flags examined
to determine compiler compatibility. This results in adding another
nested for loop in test_architecture(). To avoid the need to break
from different levels of nesting, processing of the successful case is
taken out from test_architecture().
With this change the Mentor Graphics provided mips GCC toolchain is
accepted by xcompile, resulting in the following output:
ARCH_SUPPORTED+=mips
SUBARCH_SUPPORTED+=mips mipsel
CC_mips:=mips-linux-gnu-gcc
CFLAGS_mips:= -Wno-unused-but-set-variable -fno-stack-protector -Wl,--build-id=none -mno-abicalls -fno-pic -EL
CPP_mips:=mips-linux-gnu-cpp
AS_mips:=mips-linux-gnu-as
LD_mips:=mips-linux-gnu-ld
NM_mips:=mips-linux-gnu-nm
OBJCOPY_mips:=mips-linux-gnu-objcopy
OBJDUMP_mips:=mips-linux-gnu-objdump
READELF_mips:=mips-linux-gnu-readelf
STRIP_mips:=mips-linux-gnu-strip
AR_mips:=mips-linux-gnu-ar
Change-Id: I4da384b366880929693c59dc0e1c522b35c41bea
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9997
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Declaring function variables local improves bash scripts' robustness.
Cosmetic changes among other things include renaming variables from
plural to singular and vice versa as appropriate, and replacing spaces
with tabs.
Tested by confirming that sorted output generated by
util/xcompile/xcompile is the same before and after the change.
Change-Id: I7305b3a4e45478ed3653b7d915dde4f83965f6c1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9996
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The new -Og optimization level is only available in gcc version 4.8
or higher. Clang fails on this too as of now (with "invalid integral
value 'g' in '-Og'"). The gain of this does not outweigh this
limitation at all. The flag was added in 0e53931.
Change-Id: I2b2dfc786369653d768f25be94b53329451ae1b4
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/9999
Tested-by: build bot (Jenkins)
Reviewed-by: Sol Boucher <solb@chromium.org>
This test outlives its usefulness and only slows down commits.
We can now be confident that out-of-tree builds work because
some of our automated builders do them regularly.
Change-Id: I7c27e613ddd16f7bacbd4e232596b8a76e0c3301
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9988
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
bzip2 --version |grep -c will wait for input on stdin. ./buildgcc will hang because of this.
Add `cat /dev/null |` close the stdin.
Change-Id: I2a8b08a4d90ca7a89705923d5b68ba6ac13f29b3
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9605
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I16e7c376fe6d79676734df325ac61449bb2d0871
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9982
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Because cbfs_add_entry_at() previously *assumed* it would have to create a
trailing empty entry, it was impossible to add files at exact offsets close
enough to the end of an existing empty entry that they occupied the remainder
of its space. This addresses the problem by skipping the step of creating the
trailing empty entry if doing so would place it at the start offset of whatever
already followed the original empty section.
BUG=chromium:473511
TEST=Run the following commands:
$ ./cbfstool test.image create -s 0x100000 -m arm
$ dd if=/dev/zero of=twok.bin bs=1 count=2048
$ ./cbfstool test.image add -t 0x50 -f twok.bin -n at_end -b 0xff7c0
$ ./cbfstool test.image add -t 0x50 -f twok.bin -n near_end -b 0xfef80
$ ./cbfstool test.image print
There shouldn't be any assertions, and the output should be:
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 null 1044184
near_end 0xfef40 raw 2048
at_end 0xff780 raw 2048
BRANCH=None
Change-Id: Ic8a6c3dfa4f82346a067c0804afb6c5a5e89e6c8
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 1bbd353fddc818f725e488e8f2fb6e967033539d
Original-Change-Id: I15d25df80787a8e34c2237262681720203509c72
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263809
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9938
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This enables more warnings on the cbfstool codebase and fixes the
issues that surface as a result. A memory leak that used to occur
when compressing files with lzma is also found and fixed.
Finally, there are several fixes for the Makefile:
- Its autodependencies used to be broken because the target for
the .dependencies file was misnamed; this meant that Make
didn't know how to rebuild the file, and so would silently
skip the step of updating it before including it.
- The ability to build to a custom output directory by defining
the obj variable had bitrotted.
- The default value of the obj variable was causing implicit
rules not to apply when specifying a file as a target without
providing a custom value for obj.
- Add a distclean target for removing the .dependencies file.
BUG=chromium:461875
TEST=Build an image with cbfstool both before and after.
BRANCH=None
Change-Id: I951919d63443f2b053c2e67c1ac9872abc0a43ca
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 49293443b4e565ca48d284e9a66f80c9c213975d
Original-Change-Id: Ia7350c2c3306905984cfa711d5fc4631f0b43d5b
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/257340
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9937
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This reverts commit d555d5a2b5.
It produces too much clutter, and is not particularly useful.
Change-Id: I62268a215a22a5cc76a10cdcfcae86349b466963
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/9990
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Patrick Georgi <pgeorgi@google.com>
Add the option to add a release year to each mainboard to
get a sense of how old the hardware is.
Change-Id: Id43c80fdf8bf65241b2be92678616d1774529f8c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/9945
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
By design, the imd library still provdes dynamic growth so that
feature is consistent. The imd-based cbmem packs small allocations
into a larger entry using a tiered imd. The following examples show
the reduced fragmentation and reduced memory usage.
Before with dynamic cbmem:
CBMEM ROOT 0. 023ff000 00001000
aaaabbbb 1. 023fe000 00001000
aaaabbbc 2. 023fd000 00001000
aaaabbbe 3. 023fc000 00001000
aaaacccc 4. 023fa000 00002000
aaaacccd 5. 023f9000 00001000
ROMSTAGE 6. 023f8000 00001000
CONSOLE 7. 023d8000 00020000
COREBOOT 8. 023d6000 00002000
After with tiered imd:
IMD ROOT 0. 023ff000 00001000
IMD SMALL 1. 023fe000 00001000
aaaacccc 2. 023fc000 00001060
aaaacccd 3. 023fb000 000007cf
CONSOLE 4. 023db000 00020000
COREBOOT 5. 023d9000 00002000
IMD small region:
IMD ROOT 0. 023fec00 00000400
aaaabbbb 1. 023febe0 00000020
aaaabbbc 2. 023feba0 00000040
aaaabbbe 3. 023feb20 00000080
ROMSTAGE 4. 023feb00 00000004
Side note: this CL provides a basis for what hoops one needs to
jump through when there are not writeable global variables on
a particular platform in the early stages.
Change-Id: If770246caa64b274819e45a26e100b62b9f8d2db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9169
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
abuild -x (we're running out of letters) builds with CHROMEOS enabled.
Change-Id: Ie9abd8aa999dd339aab113ff28c16671b2a17845
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9966
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
abuild only created compile.status for successful builds,
but sometimes it's helpful to easily identify all failed
builds of a full run:
$ grep -l failed coreboot-builds/*/compile.status
Change-Id: Ic90280fb2e8cff1f8f558a2e67ffad741beddbdf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9964
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Some compilers and linkers require a strict order or fail to find
all symbols.
Change-Id: I3f44bec1f0e21e7313a751fbc99c61c1aa9b7cf1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9962
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
secimage is a tool which adds a header and signature to the binary
first loaded by the soc. ARM core frequency is set to 1 Ghz.
BUG=chrome-os-partner:36421
BRANCH=broadcom-firmware
TEST=booted b0 board
Change-Id: Ia08600d45c47ee4f08d253980036916e44b0044a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36284d1b242c26b0b5aac2894f7ed1790da1ef15
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/197155
Original-Reviewed-by: Scott Branden <sbranden@broadcom.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Original-Tested-by: Daisuke Nojiri <dnojiri@google.com>
Original-Change-Id: Iaddd24006b368c8f37e075cb51e151e985029f3b
Original-Reviewed-on: https://chromium-review.googlesource.com/264417
Reviewed-on: http://review.coreboot.org/9914
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The following changes were made:
- order commands and options definitions alphabetically
- do not report errors at cbfs_image_from_file() call sites - the
error is reported by the function itself
- remove the unused parameter in cbfs_create_empty_entry() prototype
BRANCH=storm
BUG=none
TEST=compiled cbfstool, built a storm image, observed that the image
still boots
Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8
Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237560
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The previous patch introduced a bug where the new added case statement
was missing the break. There was no problem testing, because an
unrelated parameter structure field was being modified as a result.
BRANCH=storm
BUG=none
TEST=compiles and runs
Change-Id: Iaeb328048f61ffd57057ebce47f2ac8e00fc5aac
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 27ecc130569e4252e4627052f617130a2017c645
Original-Change-Id: Ib3e6c4c2b5c37588c612b8ab2672f6845c1b4ecb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239598
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
The new command allows to create a file where the original CBFS image
is duplicated at a different offset.
The required options of the new command are -D, the offset where the
copy CBFS header is placed, and -s, the size of the new CBFS copy.
When a CBFS is copied, the bootblock area of the source CBFS is
ignored, as well as empty and deleted files in the source CBFS. The
size of the destination CBFS is calculated as the rombase size of the
source CBFS less the bootblock size.
The copy instance can be created in the image only above the original,
which rules out the use of this new command for x86 images. If
necessary, this limitation could be addressed later.
As with other cbfstool commands, unless explicitly specified the
lowest CBFS instance in the image is considered the source. If
necessary, the user can specify the source CBFS using the -H option.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=run multiple cbfstool commands on a storm image:
$ cd /tmp
$ cp /build/storm/firmware/image.serial.bin storm.bin
$ cbfstool storm.bin print
storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x8700 raw 416
ddr.mbn 0x8900 raw 25836
rpm.mbn 0xee40 raw 78576
tz.mbn 0x22180 raw 85360
fallback/verstage 0x36f40 stage 41620
fallback/romstage 0x41240 stage 19556
fallback/ramstage 0x45f00 stage 25579
config 0x4c340 raw 2878
fallback/payload 0x4cec0 payload 64811
u-boot.dtb 0x5cc40 (unknown) 2993
(empty) 0x5d840 null 75608
$ cbfstool storm.bin copy -D 0x420000
E: You need to specify -s/--size.
$ cbfstool storm.bin copy -D 0x420000 -s 0x70000
$ cbfstool storm.bin print
W: Multiple (2) CBFS headers found, using the first one.
storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x8700 raw 416
ddr.mbn 0x8900 raw 25836
rpm.mbn 0xee40 raw 78576
tz.mbn 0x22180 raw 85360
fallback/verstage 0x36f40 stage 41620
fallback/romstage 0x41240 stage 19556
fallback/ramstage 0x45f00 stage 25579
config 0x4c340 raw 2878
fallback/payload 0x4cec0 payload 64811
u-boot.dtb 0x5cc40 (unknown) 2993
(empty) 0x5d840 null 75608
cbfstool storm.bin print -H 0x420000
storm.bin: 8192 kB, bootblocksize 0, romsize 4784128, offset 0x420040
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x420040 raw 416
ddr.mbn 0x420240 raw 25836
rpm.mbn 0x426780 raw 78576
tz.mbn 0x439ac0 raw 85360
fallback/verstage 0x44e880 stage 41620
fallback/romstage 0x458b80 stage 19556
fallback/ramstage 0x45d840 stage 25579
config 0x463c80 raw 2878
fallback/payload 0x464800 payload 64811
u-boot.dtb 0x474580 (unknown) 2993
(empty) 0x475180 null 110168
$ cbfstool storm.bin remove -n config -H 0x420000
$ cbfstool storm.bin copy -H 0x420000 -D 0x620000 -s 0x70000
$ cbfstool storm.bin print -H 0x620000
storm.bin: 8192 kB, bootblocksize 0, romsize 6881280, offset 0x620040
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x620040 raw 416
ddr.mbn 0x620240 raw 25836
rpm.mbn 0x626780 raw 78576
tz.mbn 0x639ac0 raw 85360
fallback/verstage 0x64e880 stage 41620
fallback/romstage 0x658b80 stage 19556
fallback/ramstage 0x65d840 stage 25579
fallback/payload 0x663c80 payload 64811
u-boot.dtb 0x673a00 (unknown) 2993
(empty) 0x674600 null 113112
$ cbfstool /build/storm/firmware/image.serial.bin extract -n fallback/payload -f payload1
[..]
$ cbfstool storm.bin extract -H 0x620000 -n fallback/payload -f payload2
[..]
$ diff payload1 payload2
Change-Id: Ieb9205848aec361bb870de0d284dff06c597564f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b8d3c1b09a47ca24d2d2effc6de0e89d1b0a8903
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Change-Id: I227e607ccf7a9a8e2a1f3c6bbc506b8d29a35b1b
Original-Reviewed-on: https://chromium-review.googlesource.com/237561
Reviewed-on: http://review.coreboot.org/9742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There potentially could be multiple CBFS instances present in the
firmware image. cbfstool should be able to operate on any of them, not
just the first one present.
To accomplish that, allow all CBFS commands to accept the -H parameter
(which specifies the exact CBFS header location in the image).
If this parameter is specified, the image is not searched for the CBFS
header, only the specified location is checked for validity, If the
location is valid, it is considered to be the CBFS header, if not -
the tool exits with an error status.
Note, that default behavior of the tool does not change.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=run the following experiments:
- examined an image with three CBFS instances, was able to print all
of them.
- built a rambi coreboot image and tried the following (cbfstool output abbreviated):
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print
coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
alignment: 64 bytes, architecture: x86
Name Offset Type Size
cmos_layout.bin 0x700000 cmos_layout 1164
...
(empty) 0x7ec600 null 77848
$ \od -tx4 -Ax /build/rambi/firmware/coreboot.rom | tail -2
7ffff0 fff67de9 000000ff fff6dfe9 fffff650
800000
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff650
coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
alignment: 64 bytes, architecture: x86
Name Offset Type Size
cmos_layout.bin 0x700000 cmos_layout 1164
...
(empty) 0x7ec600 null 77848
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff654
E: /build/rambi/firmware/coreboot.rom does not have CBFS master header.
E: Could not load ROM image '/build/rambi/firmware/coreboot.rom'.
$
Change-Id: I64cbdc79096f3c7a113762b641305542af7bbd60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 86b88222df6eed25bb176d653305e2e57e18b73a
Original-Change-Id: I486092e222c96c65868ae7d41a9e8976ffcc93c4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237485
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This check verifies that all mainboard vendors
and boards have a Kconfig.name entry.
Change-Id: I3ed3bfa0d3f78e55a8d54918f5f3f29f51068e48
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9707
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa
Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234063
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9608
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
With the Storm image layout reworked, the very first blob read out of
NOR SPI flash by the IPQ8064 maskrom is supposed to be a concatenation
of three binaries: one to run on RPM, another one to run on AP, and
the third one - the actual coreboot bootblock.
This layout allows to greatly reduce the size and complexity of the
two first blobs, as they do not need to include the SPI driver.
The first binary in the input file list starts with the combined
header, describing the rest of the blob. This utility copies the first
input file into output, updating the combined header with the total
size of the concatenated binaries.
The second and third binaries in the combined image are required to be
aligned at 256 byte offsets in the file as counted from the end of
the combined header. The new utility allows to concatenate two or
three files, always expecting the first file to be prepended by the
combined header.
For further reference below is the utility's help message:
mbncat.py: [-v] [-h] [-o Output MBN] sbl1 sbl2 [bootblock]
Concatenates up to three mbn files: two SBLs and a coreboot bootblock
-h This message
-v verbose
-o Output file name, (default: sbl-ro.mbn)
BRANCH=none
BUG=chrome-os-partner:34161
TEST=run the new utility and compare the result with the output of
the vendor provided tool. The output files are exactly the same.
Change-Id: I1d3b3634ecc3f46ea88adb9b6c4fbfc017cc06ac
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 94008340bc5eaf19d286b3feaa4091e5c5e285aa
Original-Change-Id: I00724f7c75703fc90d7971c3cb337c33ca96f2b5
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232047
Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9572
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When only one argument is passed on the command line, consider this
argument the name of the BIMG formatted file, and verify its
integrity.
Update the help/usage text to match new behavior.
BRANCH=none
BUG=none
TEST=when the corrupted coreboot BIMG image is passed as the only
argument, this utility reports the problem. With the build fixed,
the check passes without errors (the second invocation below).
$ build/util/bimgtool/bimgtool /build/urara/firmware/coreboot.rom.serial
Data header CRC mismatch at 0
$ build/util/bimgtool/bimgtool /build/urara/firmware/coreboot.rom.serial
$
Change-Id: I9f0672caa38e3d27917471fc5137ede4ca466e9a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3e631c311dbf2fb04714e437f95c41629155527f
Original-Change-Id: Ie56f87f99838891d8e341d7989c614efbcabe0cd
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227522
Original-Reviewed-by: Zdenko Pulitika <zdenko.pulitika@imgtec.com>
Original-Tested-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/9452
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Patrick Georgi