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>
Julius Werner