You can build your new toolchain with:
$ cd util/crossgcc/
$ ./buildgcc -d /opt/cross -p x86_64-elf -j 16
or
$ make crossgcc-x64
Change-Id: I8eb584166294578d2b33c63e94ed3aca9b5de4f4
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8668
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ia90f967a4988214c719f374a49233bb6fade11b0
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8481
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If not derived it's possible it defines
inconsistent timestamps which differ from each other.
Change-Id: I090fdce4c4c1c24135ec72818eecb69e168df565
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8617
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
They don't contain any useful information and
also block us from having reproducible builds.
Change-Id: Ib03887f6a548230de9f75fb308c73a800e180c48
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8616
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Moving the routines that create build.h into a script offers
several advantages. We can create more complex functions to
run and we don't have to deal with both bash and Make at the same
time.
This script combines what is currently in Makefile.inc with a
couple of updates.
- Update how it determines whether to use git for the timestamp
- Move the git revision string generation inside the routine
that checks to see if we have git.
- Add a timeout for the domain name check.
Change-Id: I93c131e8d01a0099eb13db720fa865c627985750
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8428
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Our Mediawiki instance doesn't accept the old txt format anymore.
Change-Id: I94b9f5366900ec8e192abab3ed716dbced4fc4f7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8567
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
GCC's build system is sometimes confused by our build system's
configuration: make crossgcc failed, while
util/crossgcc/buildgcc -p armv7-a-eabi didn't.
Make sure the GCC build system runs independently from
ours by breaking any ties.
Change-Id: I563e17b22127bc8c83ebfb17252184a3b6e0e58b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8545
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch introduces support for building a MIPS cross compiler
targetting little endian machines by default.
Original-Change-Id: I116f6f431cdf80f5f5f58d2743357a9f70a7347d
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/207970
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit d6c9603c41b3d11400cee7b5b409203af0632aa2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I543cd2276d2f63ed2036a1c1259c9a07cb8a4ba8
Reviewed-on: http://review.coreboot.org/8518
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The following changes are included.
Changes in version 1.0.3:
- Fixed mpc_pow, see
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2014-October/001315.html
- #18257: Switched to libtool 2.4.5.
Changes in version 1.0.2:
- Fixed mpc_atan, mpc_atanh for (+-0, +-1), see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994#c7
- Fixed mpc_log10 for purely imaginary argument, see
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2012-September/001208.html
Upgrading also fixes the issue, where for example running `make crossgcc-arm`
ails as MPC cannot be built.
Building MPC 1.0.1 ... failed
As it worked for others, it turns out that I had a release archive for
MPC 1.0.1 cached from October 2014, which was generated incorrectly, so
that `./configure` and `Makefile` are missing.
$ LANG=C ls -l util/crossgcc/tarballs/mpc-1.0.1.tar.gz
-rw-r--r-- 1 joey joey 224232 Oct 19 2013 util/crossgcc/tarballs/mpc-1.0.1.tar.gz
$ md5sum util/crossgcc/tarballs/mpc-1.0.1.tar.gz
22a27bee89616dca4d654fc579a816e5 util/crossgcc/tarballs/mpc-1.0.1.tar.gz
$ md5sum mpc-1.0.1.tar.gz # downloaded today
b32a2e1a3daa392372fbd586d1ed3679 mpc-1.0.1.tar.gz
So upgrade to MPC 1.0.3 as the release archive as of today contains the
needed files.
$ md5sum util/crossgcc/tarballs/mpc-1.0.3.tar.gz
d6a1d5f8ddea3abd2cc3e98f58352d26 util/crossgcc/tarballs/mpc-1.0.3.tar.gz
Change-Id: Ibfd02a9b362b12361b210d512420b87caebb0fdf
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
TEST:Run `make crossgcc-arm` and observe `Building MPC 1.0.3 ... ok`.
Reviewed-on: http://review.coreboot.org/8521
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix up commit 1b6e7a67 (Updates to the board status script) adding this
comment before running `cbfstool` by moving it to a more appropriate place.
Change-Id: Iff79ed44e8e5ced55f2345407d1668858098ebe4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8491
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This tells abuild that it can in fact build arm64
images.
Change-Id: I47695372053513ca039e118776aa904ea0afa21d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8474
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Add the flags used by the Nvidia makefile and use HOSTCC
to build cbootimage. Note that adding -g makes the BCT
very large, so leave that flag out.
Change-Id: I4431efffdfdcbd030665b26f5b799352e38d1f95
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8411
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If one needs raw binary files, .bin extension cannot
be used due to settings in .gitignore. This patch
allows to use .hex files. To avoid lint checks on these
files, exclude the .hex extension from the test.
Change-Id: I4b503229d63694c48cce12ca8cd33ea58172af01
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/8403
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
From git's point of view submodules are a weird third thing between file
and directory. Avoid trying to apply file handling on a directory.
Change-Id: Ibbc9c28e1657d96413c5fb08705d30e25171254d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8372
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Carefully staging to enable checkpatch for coreboot contributions.
The biggest offender of the rules enforced by checkpatch I have found so
far is ... Oh, you guessed it? It's checkpatch itself.
Change-Id: Iaacbcd52c3bc22b083a24127a3ea17a7cc706245
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8417
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It doesn't provide any useful information.
Change-Id: I13e68d443bbcadea45b8fbcc262ceb9deb3e2e61
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8380
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Peter Stuge <peter@stuge.se>
coreboot toolchain.inc uses the ARCH_SUPPORTED variable set
by xcompile. This change allows for consistent naming in the
toolchain.inc generated variables.
Change-Id: Iafed06cf2d19a533f99e10b76aca82adc3e09fa8
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8235
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This patch brings the cbmem utility in line with the recent change to
coreboot's device tree binding. Since trying to find the right node to
place this binding has been so hard (and still isn't quite agreed upon),
and because it's really the more correct thing to do, this code searches
through the device tree for the 'coreboot' compatible property instead
of looking up a hardcoded path. It also provides bullet-proof
'#address-cells' handling that should work for any endianness and size.
BUG=chrome-os-partner:29311
TEST=Ran cbmem -c and cbmem -t on Nyan_Big. Also straced the to make
sure everything looks as expected. 'time cbmem -t' = ~35ms shows that
there is no serious performance problem from the more thorough lookup
code.
Original-Change-Id: I806a21270ba6cec6e81232075749016eaf18508b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/204274
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit 3e64e28f684e60e8b300906c1abffee75ec6a5c2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0a0a4f69330d3d8c5c3ea92b55f5dde4d43fca65
Reviewed-on: http://review.coreboot.org/8141
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remove the arch check for each stage as the arch for different stages can be
different based on the SoC. e.g.: Rush has arm32-based romstage whereas
arm64-based ramstage
BUG=None
BRANCH=None
TEST=Compiles successfully for nyan, link and rush
Original-Change-Id: I561dab5a5d87c6b93b8d667857d5e181ff72e35d
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/205761
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 6a6a87b65fcab5a7e8163258c7e8d704fa8d97c3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ic412d60d8a72dac4f9807cae5d8c89499a157f96
Reviewed-on: http://review.coreboot.org/8179
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For arm64, the machine type is arm64 in cbfstool, however it was displayed as
aarch64 in help message. This patch corrects it.
BUG=None
BRANCH=None
TEST=None
Original-Change-Id: I0319907d6c9d136707ed35d6e9686ba67da7dfb2
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/204379
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 1f5f4c853efac5d842147ca0373cf9b5dd9f0ad0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I00f51f1d4a9e336367f0619910fd8eb965b69bab
Reviewed-on: http://review.coreboot.org/8144
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I3bb5dc23885af8c992456ee5e4bd374cd4b813bf
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8049
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In https://chromium-review.googlesource.com/181272 the payload->type has been
changed to big-endian (network ordering) but the cbfs_image is still parsing
type as host ordering, which caused printing cbfs image verbosely
(cbfstool imge print -v) to fail to find entry field and print numerous
garbage output.
Payload fields should be always parsed in big-endian (network ordering).
BUG=none
TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly
Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200158
Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9
Reviewed-on: http://review.coreboot.org/8005
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.
BUG=none
TEST=manual
. the new firmware still displays proper CBMEM table entry descriptions:
coreboot table: 276 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
. running make in util/cbmem still succeeds
Original-Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199791
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5217446a536bb1ba874e162c6e2e16643caa592a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0d839316e9697bd3afa0b60490a840d39902dfb3
Reviewed-on: http://review.coreboot.org/7938
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
make called within make prints 'Entering directory'
cruft which confuses the architecture support test.
Silence it.
Change-Id: I7ce7e0ff49e9317fe736ed80f5f18186d416ae63
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7968
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
They create output in an obsolete form, are not actively maintained,
and the quality of the output is not better than randomly copy
pasting from other boards. These tools are no longer of any practical
value. remove them.
Change-Id: I49d7c5c86b908e08a3d79a06f5cb5b28cea1c806
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5158
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
nct6776f and nct6776d are just two package variants containing the same die
Change-Id: I4d319fa0e791e66ad04857dede2fdfc8e42dd45a
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/7806
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
change default values according to the datasheet in revision 1.2
Change-Id: Iec1d55dd7b906a7a41940f3f8e42413922883efd
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/7805
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Windows requires O_BINARY when opening a binary file. Otherwise
\n characters get expanded to \r\n and <ctrl>z is treated as
end of file. For compatibility with non-Windows hosts, the patch
defines O_BINARY if it is not already defined.
Change-Id: I04cd609b644b1edbe9104153b43b9996811ffd38
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7789
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Windows requires the 'b' (binary) flag when using fopen to open a
binary file. Otherwise \n characters get expanded to \r\n and <ctrl>z
is treated as end of file.
Change-Id: I3b85e4f9a8f7749801a39154881fe2eedd33f9b8
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7790
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Scott Duplichan provided a win32 related fix that
we want to use.
Change-Id: I791b470f9f6c5bf140fc190d290741f35f05d254
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7827
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
A leading double slash can result when $DESTDIR/$TARGETDIR is expanded
in the libelf portion of buildgcc. The leading double slash causes buildgcc to fail when run from Windows/Msys2. Replace $DESTDIR/$TARGETDIR
with $DESTDIR$TARGETDIR to avoid the problem.
Change-Id: Ide2bae41c07c1566f80104c3a2e2acab53de0d17
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7788
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
It's not useful in quiet mode, and is very distracting.
Change-Id: I59dc8caa22b66980560d5afb76eae801efaa29ad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/124
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We already have aarch64 targets. Extend the "all" target.
Change-Id: I74d9bf5123695318c15b73c89f170f3ebb20aa80
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7729
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
- add a 'quiet' mode that only prints important messages
- add vendor/mainboard to all strings printed
With quiet on, multithreaded looks like this:
skipping google/storm because we're missing compilers for (arm armv4 armv7)
iwill/dk8_htx built successfully. (took 5s)
jetway/j7f2 built successfully. (took 6s)
iwill/dk8x built successfully. (took 8s)
iwill/dk8s2 built successfully. (took 8s)
jetway/j7f4k1g5d built successfully. (took 10s)
With quiet off, single threaded now looks like this:
Building intel/emeraldlake2
Creating config file for intel/emeraldlake2...
intel/emeraldlake2 (blobs, ccache)
intel/emeraldlake2 config created.
Compiling intel/emeraldlake2 image...
intel/emeraldlake2 built successfully. (took 5s)
And quiet off multithreaded looks like this:
Building iwill/dk8_htx
Creating config file for iwill/dk8_htx...
iwill/dk8_htx (blobs, ccache)
intel/mohonpeak config created.
Compiling intel/mohonpeak image on 1 cpu...
intel/minnowmax config created.
--- snip ---
intel/mtarvon built successfully. (took 4s)
Building iwill/dk8s2
Creating config file for iwill/dk8s2...
iwill/dk8s2 (blobs, ccache)
intel/mohonpeak built successfully. (took 5s)
Building iwill/dk8x
Change-Id: Ib7b9a625d77bb8e0663afc00d7133e415866ecec
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7716
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
abuild, inteltool, and superiotool's manpages still referenced reporting
bugs to tracker.coreboot.org. Remove that url and change the message
to point to the coreboot mailing list instead.
Change-Id: I7a85bc2b36ccdb7f3798a39a08345c1a02a67e65
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7712
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
While it may not be the best way theoretically as theoretically only one
of clones may fail if clones are not perfect, in practice there is more
variance between e.g. different X60 variants than between most of the clones,
yet we put all X60 variants together.
Also in most cases we don't even have a way to tell the clones apart.
Change-Id: I786aeed55300026fae0d9f0497d0c830a9f5e452
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7564
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit b4b9eb39 (x86: provide infrastructure to backup default SMM
region) introduced the new CBMEM type `CBMEM_ID_SMM_SAVE_SPACE`, but
did not add its name `SMM BACKUP` to the utility `cbmem`, causing the
following output, when running `cbmem` on a system making
use of `BACKUP_DEFAULT_SMM_REGION`.
7. 07e9acee 7f7e5000 00010000
Fix that by adding the name `SMM BACKUP` to the struct
`cbmem_id_to_name`.
Change-Id: Ib24088c07af4daf6b7d8d5854283b5faa2ad6503
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/7176
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The call site expects them to be.
Change-Id: Ic05fc5831f5743d94fe617dfb3b9e329f01866d1
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7621
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Fixes crash occurring when 'nvramtool -a' tried to free a prematurely
freed pointer. (Tested on x60)
malloc() is correct because the pointer is accessed outside the calling
function. The pointer is freed in the parent function list_cmos_entry().
Change-Id: I1723f09740657f0f0d9e6954bd6d11c0a3820a42
Signed-off-by: Andrew Engelbrecht <sudoman@ninthfloor.org>
Reviewed-on: http://review.coreboot.org/7620
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The libelf build system doesn't support the
DESTDIR variable. Work around by mangling prefix
when installing.
Change-Id: I3a56eb2bf919bcb9b586b945dce26a02dbaff931
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7613
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There isn't a history of broken clang compilers yet
so let's give it a chance.
Change-Id: Iddb63700e3850116313c1ddee69111f936191055
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7607
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This allows easy creation of redistribuable binary.
Change-Id: I12a82d509cd4bd46baeb4f4066e509c69301ab95
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7565
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
.bin is the most convenient format for storing SPDs and since it's
not text format, whitespace check is useless and gives false positives.
Change-Id: I8a7569eac8a1dfbffabe166a38e4dd3e895fdef1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7567
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Fixes regression caused by commit 405304ac
(cbfstool: Add option to ignore section in add-stage)
Change-Id: If9e3eea9ab2c05027f660d0057a635abf981b901
Signed-off-by: Francis Rowe <info@gluglug.org.uk>
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7545
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds the crosstools-aarch64 and crossgcc-aarch64
make rules to create a toolchain (with or without gdb)
for AArch64 targets.
Also adapt xcompile, since it's aarch64-elf.
Change-Id: I6fbe09d44ee8b8493d3cd8dbbba869b409e311f7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7527
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
gcc 4.9.2 fails on our tree right now. We should clean that
up and test before we make it the reference version.
Also, the AMD K8/Fam10 issue we had last year, for which
Vladimir provided an "untested" fix (which is in,
commit a6c29fe684), isn't
reproducible: I boot-tested an unpublished AMD K8 board
with coreboot built with gcc 4.8.3.
(Disclaimer: since the old issue depended on compiler
decisions on register allocation, any change to code
or compiler could mix up things in semi-random ways.)
Change-Id: I8f1460a8da2c9e2d581482b22a4824b10b8987fa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7526
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Otherwise rename() fails when used across filesystem
boundaries.
Change-Id: I22a62310f0e46ac9cfee50b7e9eeed93536ed409
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7504
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
It contains a number of fixes to bugs found
by Coverity Scan.
Change-Id: I362a069afd37783f59d8831e44ae885e8490819e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7392
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is required to run abuild parallely with clang
without the canonical coreboot toolchain installed.
Change-Id: Iea56d3f552d50ab6e762afa134091b0d8e38792c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7369
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add IDs of some SNB and Haswell chips; use more descriptive names.
Add PCIEXBAR and PXPEPBAR read support for SNB/IVB/Haswell.
Change-Id: I16753bf90061fc2065b813b1c2169e7b7bcc89e8
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/7360
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Mathias Krause <minipli@googlemail.com>
If we find multiple LPC controllers, we want to tell the user that we'll
ignore all but the first. However, we use 'dev' in the message (the
current device found) instead of 'sb' (the one we want to use).
Fix the message by using 'sb' and break the loop right away in this
case. It's sufficient to tell the user once which LPC controller we'll
use.
Change-Id: Ibd27e40525fabe8c63b112691ad49fd994c70a48
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/7342
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Change-Id: I408614e743ab6f0f447b327c01d8f4dacf787124
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6692
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
It never worked.
Change-Id: Ic68614bb8ed481babf54b4f9d8db00635755f4d1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7324
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Actually abort if a cross compiler is missing, but also handle
subarchitectures (currently: armv4 and armv7 for arm)
properly.
Change-Id: Idf37fb029178df6f2ac029466c66aaa2010bdbd2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7297
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Allow add-stage to have an optional parameter for ignoring any section. This is
required to ensure proper operation of elf_to_stage in case of loadable segments
with zero filesize.
Change-Id: I49ad62c2a4260ab9cec173c80c0f16923fc66c79
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/7304
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Change cbfs-mkstage to use parsed elf instead of calling elf_headers. That
allows us to have access to the complete elf including the string table.
Change-Id: Ie767d28bdf41af38d1df0bce54bc0ada45123136
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/7303
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Nicolas Reinecke was noticing that in my Lenovo T410s logs the GPIO*3
settings were missing. This led to some investigation and this patch, thanks!
Change-Id: I7ba28aa00d10f988a7fe81e61d2e216b54a11006
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/7239
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
This is a copy of the tool provided by the vendor. It adds a
header which tells the early stage loader where to load the next phase
blob for execution. It is going to be used to encapsulate the
bootblock.
Usage of this tool is as follows:
ipqheader.py <base-addr> <input-file> <output-file>
Old-Change-Id: I448c006719f4f3dd5a6716ff2e47f7fc275c805e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193494
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 201630f8637eb627f0894ecd7bceb31017244ad4)
Make ipqheader.py executable
Modify the utility to become a Linux executable. While at it, fix the
program name reported by error messages.
Old-Change-Id: I25061d43fdea72655a696deb9e494e9c7382f670
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193495
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit bbbf69c754aa3b6a1bf17ab3ced1c739c3ee0688)
ipq8064: SBL headers must have 4 byte aligned blob sizes
It turns out that for SBL3 to load the next phase, the sizes in the
MBN header must be 4 byres aligned. This change makes sure that this
requirement is enforced.
Old-Change-Id: Ia64f04bb281ae772b060d2f7713c98dd348972ba
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196167
(cherry picked from commit fa6a52a07cb87ecf2538a6b0d47605d79104e4cc)
Add proper license to the ipqheader tool
This patch adds a vanilla BSD 3-Clause license.
Original-Change-Id: I9da7176e670b598808ef5be2461b6105a4c5f6c5
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225783
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Tested-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit a0c47a8d74f1ac131c91e978b6d68bbcfaa52c37)
Squashed 4 commits for the ipqheader util.
Change-Id: I144c01947a89e1348a06aa82590e972e2ec31247
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/6976
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Add support for creating ARM rmodules. There are 3 expected
relocations for an ARM rmodule:
- R_ARM_ABS32
- R_ARM_THM_PC22
- R_ARM_THM_JUMP24
R_ARM_ABS32 is the only type that needs to emitted for relocation
as the other 2 are relative relocations.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vbootstub for ARM device.
Original-Change-Id: I0c22d4abca970e82ccd60b33fed700b96e3e52fb
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190922
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a642102ba7ace5c1829abe7732199eda6646950a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib3b3c90ebb672d8d6a537df896b97dc82c6186cc
Reviewed-on: http://review.coreboot.org/7204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The LZMA compression algorithm, currently the only one available, will fail
if you ask it to write more data to the output than you've given it space for.
The code that calls into LZMA allocates an output buffer the same size as the
input, so if compression increases the size of the output the call will fail.
The caller(s) were written to assume that the call succeeded and check the
returned length to see if the size would have increased, but that will never
happen with LZMA.
Rather than try to rework the LZMA library to dynamically resize the output
buffer or try to guess what the maximal size the data could expand to is, this
change makes the caller simply print a warning and disable compression if the
call failed for some reason.
This may lead to images that are larger than necessary if compression fails
for some other reason and the user doesn't notice, but since compression
errors were ignored entirely until very recently that will hopefully not be
a problem in practice, and we should be guaranteed to at least produce a
correct image.
Original-Change-Id: I5f59529c2d48e9c4c2e011018b40ec336c4fcca8
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/187365
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit b9f622a554d5fb9a9aff839c64e11acb27785f13)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Change-Id: I5f59529c2d48e9c4c2e011018b40ec336c4fcca8
Reviewed-on: http://review.coreboot.org/6958
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
sizeof(char[]-type+1) isn't very useful. Since one of
the strings is constant, we also don't need to use
strncmp that string's length. While at it, str*cmp don't
return booleans, so check for value instead of faux bools.
Change-Id: Iebb194a60eac454dafeade75f135df92068cf4ab
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6988
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We don't support them, they won't ever pass the build test,
so no need to report an error.
Change-Id: I2409a79f3c0d66a79b0e065e6b9ebf62d0359b3e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7121
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This didn't work for a while, and we don't _really_ need it.
Change-Id: I952243f30e985e7577cd511f40957066db6dd3c5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7120
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since commit c0199078 (cbmem utility: Find actual CBMEM area) [1], at least on
the Lenovo X201, X230 and X60, printing the CBMEM table of contents did
not work. It still worked on the ASRock E350M1 though.
$ sudo /src/coreboot/util/cbmem/cbmem -l --verbose # Lenovo X60t
Looking for coreboot table at 0
Mapping 1MB of physical memory at 0x0.
Found!
coreboot table entry 0x11
Found forwarding entry.
Unmapping 1MB of virtual memory at 0xb74dc000.
Looking for coreboot table at 7f6c4000
Mapping 1MB of physical memory at 0x7f6c4000.
Found!
coreboot table entry 0xc8
coreboot table entry 0x01
Found memory map.
coreboot table entry 0x03
coreboot table entry 0x04
coreboot table entry 0x05
coreboot table entry 0x06
coreboot table entry 0x07
coreboot table entry 0x08
coreboot table entry 0x09
coreboot table entry 0x0a
coreboot table entry 0x16
Found timestamp table.
cbmem_addr = 7f7dd000
coreboot table entry 0x17
Found cbmem console.
cbmem_addr = 7f7de000
Unmapping 1MB of virtual memory at 0xb74dc000.
No coreboot CBMEM area found!
The address of the boot info record has to be used for checking, that reading
takes place in the bounds of the boot info record.
$ sudo ~/src/coreboot/util/cbmem/cbmem -l # Lenovo X60
CBMEM table of contents:
ID START LENGTH
[…]
Big thanks to David and Stefan for their help.
[1] http://review.coreboot.org/2117
Change-Id: I1eb09a6445d9ea17e1e16b6866dece74315d3c73
Found-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/7093
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Originally the utility cbmem was just used for reading out the time
stamps and was later extented. The removed comment is currently at the
wrong place and `cbmem` does much more now, so that the comment is just
removed.
Change-Id: Ief1d7aef38a4b439e3e224e6e6c65f7aa57f821f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/7091
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
RISCV is a new architecture. This change simply setups up xcompile
to detect and use RISCV compilers if they are found.
Change-Id: Iad1a88ef2e3c8dd1e601549aeca26fb29b2bc7ae
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7023
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It's not been needed for years, is definitely not needed now
that cbfstool parses bzImages, and its presence keeps confusing
people.
Also, rewrite history. We never mentioned mkelfimage in the
documentation. Never, ever, ever.
Change-Id: Id96a57906ba6a423b06a8f4140d2efde6f280d55
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7021
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In order to enumerate CPU devices that are non-x86 (read: no lapic)
provide a generic 'cpu' device.
Change-Id: Ifeafdad8076935c3448784e6958117002509acbf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6824
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It brings in useless dependencies, a weird autotools
configuration, and tons of pain everywhere.
Instead just build things ourselves.
Change-Id: I67f06e711cb9dcd594363bc1a4f99d3273074549
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6986
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When compression fails for whatever reason, the caller should know about it
rather than blindly assuming it worked correctly. That can prevent half
compressed data from ending up in the image.
This is currently happening for a segment of depthcharge which is triggering
a failure in LZMA. The size of the "compressed" data is never set and is
recorded as zero, and that segment effectively isn't loaded during boot.
Change-Id: Idbff01f5413d030bbf5382712780bbd0b9e83bc7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187364
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit be48f3e41eaf0eaf6686c61c439095fc56883cec)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6960
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently, rmodules with 0 relocations are not allowed. Fix this by skipping
addition of .rmodules section on 0 relocs.
Change-Id: I7a39cf409a5f2bc808967d2b5334a15891c4748e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/6774
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934)
This patch is essentially a squash of aarch64 changes made by
these patches:
d955885 coreboot: Rename coreboot_ram stage to ramstage
a492761 cbmem console: Locate the preram console with a symbol instead of a sect
96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3
3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry
ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage
25fd2e9 aarch64: Remove CAR definitions from early_variables.h
65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM
9484873 aarch64: Change default exception level to EL2
7a152c3 aarch64: Fix formatting of exception registers dump
6946464 aarch64: Implement basic exception handling
c732a9d aarch64/foundation-armv8: Basic bootblock implementation
3bc412c aarch64: Comment out some parts of code to allow build
ab5be71 Add initial aarch64 support
The ramstage support is the only portion that has been tested
on actual hardware. Bootblock and romstage support may require
modifications to run on hardware.
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6915
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Furquan Shaikh <furquan@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>
In the process of rewriting cbfstool for ARM and using
a new internal API a regression was introduced that would
silently let you add an ARM payload into an x86 CBFS image
and the other way around. This patch fixes cbfstool to
produce an error in that case again.
Change-Id: I37ee65a467d9658d0846c2cf43b582e285f1a8f8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176711
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 8f74f3f5227e440ae46b59f8fd692f679f3ada2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6879
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Install the BL1 and set up the checksum in the Makefile instead of relying on
post processing. Import the exynos checksum script, split it in two and
simplify it significantly. Stop putting the CBFS header in the midst of the
bootblock so that it can be checksummed before CBFS is put together. Stop
saving space for it and leaving an anchor in the bootblock which nobody looks
for.
Change-Id: Icbb5a5914ece60b2827433b6dc29d80db996ea6c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179229
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit aa3a416705517c0a6ddfdeb19905ac8cafb33df1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Furquan Shaikh