Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to support booting a GNU/Linux payload on non x86, the FIT format
should be used, as it is the defacto standard on ARM.
Due to greater complexity of FIT it is not converted to simple ELF format.
Add support for autodecting FIT payloads and add them as new CBFS_TYPE 'fit'.
The payload is included as is, with no special header.
The code can determine the type at runtime using the CBFS_TYPE field.
Support for parsing FIT payloads in coreboot is added in a follow on
commit.
Compression of FIT payloads is not supported, as the FIT sections might be
compressed itself.
Starting at this point a CBFS payload/ can be either of type FIT or SELF.
Tested on Cavium SoC.
Change-Id: Ic5fc30cd5419eb76c4eb50cca3449caea60270de
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This reverts commit 717ba74836.
This breaks seabios and a few other payloads. This is not
ready for use.
Change-Id: I48ebe2e2628c11e935357b900d01953882cd20dd
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/26310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, adding a payload to CBFS using the build system, the warning
below is shown.
W: Unknown type 'payload' ignored
Update payload type from "simple elf" to "simple_elf" and rename the
word "payload" to "simple_elf" in all Makefiles.
Fixes: 4f5bed52 (cbfs: Rename CBFS_TYPE_PAYLOAD to CBFS_TYPE_SELF)
Change-Id: Iccf6cc889b7ddd0c6ae04bda194fe5f9c00e495d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26240
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In preparation of having FIT payloads, which aren't converted to simple ELF,
rename the CBFS type payload to actually show the format the payload is
encoded in.
Another type CBFS_TYPE_FIT will be added to have two different payload
formats. For now this is only a cosmetic change.
Change-Id: I39ee590d063b3e90f6153fe655aa50e58d45e8b0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds '-p' to the 'add' command. It allows the add
command to specify the size of the padding added with the file
being added. This is useful to reserve an extra space in case
the file is too big to be relocated.
BUG=b:68660966
BRANCH=none
TEST=emerge-fizz coreboot &&
cbfstool image.bin add -n ecrw -f EC_RW.bin -p 0x10 ...
Verify image.bin has extra space in the file header.
Change-Id: I64bc54fd10a453b4da467bc69d9590e61b0f7ead
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/22239
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
cbfs-compression-tool provides a way to benchmark the compression
algorithms as used by cbfstool (and coreboot) and allows to
pre-compress data for later consumption by cbfstool (once it supports
the format).
For an impression, the benchmark's results on my machine:
measuring 'none'
compressing 10485760 bytes to 10485760 took 0 seconds
measuring 'LZMA'
compressing 10485760 bytes to 1736 took 2 seconds
measuring 'LZ4'
compressing 10485760 bytes to 41880 took 0 seconds
And a possible use for external compression, parallel and non-parallel
(60MB in 53 files compressed to 650KB on a machine with 40 threads):
$ time (ls -1 *.* |xargs -n 1 -P $(nproc) -I '{}' cbfs-compression-tool compress '{}' out/'{}' LZMA)
real 0m0.786s
user 0m11.440s
sys 0m0.044s
$ time (ls -1 *.* |xargs -n 1 -P 1 -I '{}' cbfs-compression-tool compress '{}' out/'{}' LZMA)
real 0m10.444s
user 0m10.280s
sys 0m0.064s
Change-Id: I40be087e85d09a895b1ed277270350ab65a4d6d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18099
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This patch adds functionality to compile a C data structure into a raw
binary file, add it to CBFS and allow coreboot to load it at runtime.
This is useful in all cases where we need to be able to have several
larger data sets available in an image, but will only require a small
subset of them at boot (a classic example would be DRAM parameters) or
only require it in certain boot modes. This allows us to load less data
from flash and increase boot speed compared to solutions that compile
all data sets into a stage.
Each structure has to be defined in a separate .c file which contains no
functions and only a single global variable. The data type must be
serialization safe (composed of only fixed-width types, paying attention
to padding). It must be added to CBFS in a Makefile with the 'struct'
file processor.
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since fit.c is the only caller of this function move it out of common.c
and into fit.c.
Change-Id: I64cc31a6d89ee425c5b07745ea5ca9437e2f3fcf
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14949
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add functionality to cbfstool to generate file attributes
for position and alignment constraints. This new feature
can be activated with the -g option and will generate,
once the option has been enabled, additional attributes
for the files where position, xip or alignment was specified.
Change-Id: I3db9bd2c20d26b168bc7f320362ed41be349ae3a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/12967
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The constant for ppc64 is 'hotstuff'. For many reasons.
Note that line 2894 of elf.h is not indented. This is because in the
original the line begins with a space. Checkpatch rejects that.
Checkpatch also rejects changing the space to a tab because that makes
it more than 80 chars. I rejected breaking the line because it makes it
even less readable. All the changes forced by checkpatch make the code
less readable.
Herman Hollerith would be proud.
Change-Id: I21f049fe8c655a30f17dff694b8f42789ad9efb7
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/12711
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
They allow optimizing a verification of a whole CBFS image by only
dealing with the headers (assuming you choose to trust the hash
algorithm(s)).
The format allows for multiple hashes for a single file, and cbfstool
can handle them, but right now it can't generate such headers.
Loosely based on Sol's work in http://review.coreboot.org/#/c/10147/,
but using the compatible file attribute format. vboot is now a hard
dependency of the build process, but we import it into the tree for
quite a while now.
Change-Id: I9f14f30537d676ce209ad612e7327c6f4810b313
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11767
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Let's move x86 style bootblocks (and later the others) and the master header
into the CBFS structure. Prepare for this by adding file types.
Change-Id: I1b4149c7f3b8564ee358a2c18ba91e6a7a6797da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11627
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We had two mappings of filetype IDs to strings. We shouldn't.
Change-Id: I08e478b92f3316139f14294e50ede657c7d5fb01
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11626
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
According to https://gcc.gnu.org/gcc-4.6/changes.html it's only in gcc 4.6,
not 4.5, which I mistakenly believed.
Change-Id: I8212e7921bd9d1436a0ba491cbe6c4d473228956
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11476
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Tested-by: build bot (Jenkins)
This isn't required for correct execution, and doesn't need to be tested
on every single compiler out there.
Since GCC < 4.5 has no idea about _Static_assert, hide it there. Our
build tests will make sure that the test is run before changes are
submitted to master.
Change-Id: I4141f4aa23b140d2d1017ca7b4dace5aa7db0c04
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11475
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Currently, compression is only allowed at subheader level (e.g. cbfs_stage,
cbfs_payload_segment). This change adds compression field to each file's
header so that any cbfs file can be compressed.
With the necessary additions in coreboot and libpayload, the following sample
code can load a compressed file:
const char *name = "foo.bmp";
struct cbfs_file *file = cbfs_get_file(media, name);
void *dst = malloc(ntohl(file->uncompressed_size));
dst = cbfs_get_file_content(media, name, type, file, dst);
cbfs_stage and cbfs_payload_segment continue to support compression at
subheader level because stages and payloads have to be decompressed to the load
address, which is stored in the subheader. For these, file level compression
should be turned off.
Change-Id: I9a00ec99dfc68ffb2771bb4a3cc5ba6ba8a326f4
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a generic structure, not unlike the cbtables design, based on which we
can build specialized TLV data structures.
Change-Id: I98a75eef19f049ad67d46cdc2790949dcd155797
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
So far it's still unused, but its purpose will change:
It will become an offset to another structure that contains additional file
attributes.
This change is compatible because the binary format doesn't change and so far
the field was always set to 0, which can serve nicely as 'unused' field.
Change-Id: I2dafb06866713d43a236556f9492641526270837
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Lock down its size and document some of the fields
Change-Id: I09fd6c80185345da0ae17d0f4498b50995fd1ec5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10927
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
It's not like we _ever_ changed it, so drop the option and make cbfstool
use the default. always.
Change-Id: Ia1b99fda03d5852137a362422e979f4a4dffc5ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10918
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On Windows systems, structs can be packed gcc style or ms style.
Make sure we use the same one (gcc style) in our user space tools
that we use in coreboot.
Change-Id: I7a9ea7368f77fba53206e953b4d5ca219ed4c12e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10794
Tested-by: build bot (Jenkins)
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>
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)
This adds a few new file types to cbfstool. Currently these
files are being added using bare hex values in the coreboot
makefiles. This patch is just to make the values official and
to help get rid of some confusion in the values used within the
makefiles.
All of these new types are roughly equivalent to raw.
Change-Id: I37c4180a247136cd98080f6f7609d3cf905a62f5
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8977
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
cbfstool has diverged between coreboot upstream and the chromium tree.
Bring in some of the chromium changes, in particular the useful remainders
of cbf37fe (https://chromium-review.googlesource.com/176710)
- fix coding style
- mark unused variables explicitly unused
- remove some dead code
Change-Id: I354aaede8ce425ebe99d4c60c232feea62bf8a11
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8577
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Specify a CBFS architecture value for MIPS and allow cbfstool to make
use of it.
Original-Change-Id: I604d61004596b65c9903d444e030241f712202bd
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/207971
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 7c4df61715df3767673841789d02fe5d1bd1d4a0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib30524f5e7e8c7891cb69fc8ed8f6a7e44ac3325
Reviewed-on: http://review.coreboot.org/8519
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The aarch64 is not really an arm variant, it's sufficiently
different that it can be considered (for purposes of cbfs, certainly)
to be a new architecture.
Add a constant in cbfs.h and strings to correspond to it.
Note that with the new cbfstool support that we added earlier,
the actual use of aarch64 ELF files actually "just works" (at
least when tested earlier).
Change-Id: Ib4900900d99c9aae6eef858d8ee097709368c4d4
Reviewed-on: https://chromium-review.googlesource.com/180221
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit f836e14695827b2667804bc1058e08ec7b297921)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6896
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
The printing routines of the cbfs_payload_segment assumed the type
could be accessed in host order. Each of the fields need to be
converted to the host order before inspecting the fields. In addition,
this removes all the ntoh*() calls while processing the
cbfs_payload_segment structures.
cbfstool would crash adding entries or just printing entries
containing a payload when -v was passed on the command line.
Change-Id: Iff41c64a99001b9e3920e2e26828c5fd6e671239
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
The magic number mismatch was introduced by commit a8a133
(Add section header parsing and use it in the mk-payload step).
Change-Id: I73b0adb969816e9d130f19f48e175c57124e2f3a
Signed-off-by: Wei Hu <wei@aristanetworks.com>
Reviewed-on: http://review.coreboot.org/5528
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
elfparsing.h serves as the header to working with the elf
parser. Additionally, only include what is needed by the other
files. Many had no reason to be including elf.h aside from fixing
compilation problems when including cbfs.h.
Change-Id: I9eb5f09f3122aa18beeca52d2e4dc2102d70fb9d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5370
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
And use it in fit.c and remove one more use of htonl.
Change-Id: Ibf18dcc0a7f08d75c2374115de0db7a4bf64ec1e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5120
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When I changed mkpayload, I did not realize we had a duplicate
block of code in the linux payload code. Have it use the same
header generator as the standard payload code does.
Change-Id: Ie39540089ce89b704290c89127da4c7b051ecb0e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5115
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Now that unused functions have been removed, the global "arch" is only
used in very few places. We can pack "arch" in the "param" structure
and pass it down to where it is actually used.
Change-Id: I255d1e2bc6b5ead91b6b4e94a0202523c4ab53dc
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5105
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A lot of the early functions have been re-implemented in a context-
centric mode, rather than relying on global variables. Removing these
has the nice side-effect of allowing us to remove more global
variables.
Change-Id: Iee716ef38729705432dd10d12758c886d38701a8
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5104
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This completes the improvements to the ELF file parsing code. We can
now parse section headers too, across all 4 combinations of word size
and endianness. I had hoped to completely remove the use of htonl
until I found it in cbfs_image.c. That's a battle for another day.
There's now a handy macro to create magic numbers in host byte order.
I'm using it for all the PAYLOAD_SEGMENT_* constants and maybe
we can use it for the others too, but this is sensitive code and
I'd rather change one thing at a time.
To maximize the ease of use for users, elf parsing is accomplished with
just one function:
int
elf_headers(const struct buffer *pinput,
Elf64_Ehdr *ehdr,
Elf64_Phdr **pphdr,
Elf64_Shdr **pshdr)
which requires the ehdr and pphdr pointers to be non-NULL, but allows
the pshdr to be NULL. If pshdr is NULL, the code will not try to read
in section headers.
To satisfy our powerful scripts, I had to remove the ^M from an unrelated
microcode file.
BUG=None
TEST=Build a peppy image (known to boot) with old and new versions and verify they are bit-for-bit the same. This was also fully tested across all chromebooks for building and booting and running chromeos.
BRANCH=None
Change-Id: I54dad887d922428b6175fdb6a9cdfadd8a6bb889
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181272
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5098
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Process CBFS ROM image by new cbfs_image API.
To verify, run "cbfstool coreboot.rom print -v" and compare with old cbfstool.
Change-Id: I3a5a9ef176596d825e6cdba28a8ad732f69f5600
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2206
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Current cbfstool implementation is relying on global variables to pass processed
data, and the calculation of address is based on x86 architecture (ex, always
assuming 0x0000 as invalid address), not easy to be used on platforms without
top-aligned memory mapping. This CL is a first step to start a new cbfstool
without global variables, and to prevent assuming memory layout in x86 mode.
The first published APIs are for reading and writing existing CBFS ROM image
files (and to find file entries in a ROM file).
Read cbfs_image.h for detail usage of each API function.
Change-Id: I28c737c8f290e51332119188248ac9e28042024c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2194
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Show what's in a stage or payload. This will let people better understand
what's in a stage or payload.
Change-Id: If6d9a877b4aedd5cece76774e41f0daadb20c008
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2176
Tested-by: build bot (Jenkins)
The 'VERSION' in CBFS header file is confusing and may conflict when being used
in libpayload.
Change-Id: I24cce0cd73540e38d96f222df0a65414b16f6260
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2098
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is an initial re-factoring of CBFS code to enable multiple
architectures. To achieve a clean solution, an additional field
describing the architecture has to be added to the master header.
Hence we also increase the version number in the master header.
Change-Id: Icda681673221f8c27efbc46f16c2c5682b16a265
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1944
Tested-by: build bot (Jenkins)
- Adding more and more optional and non-optional parameters
bloated cbfstool and made the code hard to read with a lot
of parsing in the actual cbfs handling functions. This change
switches over to use getopt style options for everything but
command and cbfs file name.
- This allows us to simplify the coreboot Makefiles a bit
- Also, add guards to include files
- Fix some 80+ character lines
- Add more detailed error reporting
- Free memory we're allocating
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7
Reviewed-on: http://review.coreboot.org/1800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Nico Huber