If the unpacking was interrupt by Ctrl-C, probably part of
an archive is unpacked. If we run buildgcc again, the
incomplete folder would be and skipped.
We can create a file to tell the script the unpacking is done.
Change-Id: Id9eb74d119e22b62c70dca9b38a92c3dbdf0f64c
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Make boards take less vertical space, and link to board pages
Change-Id: Ifdd062a15191809b75422416c874161d9114363d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4493
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
These were terribly under-documented
Change-Id: I285ea083110d87076281e81065f5f38d0c688358
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4491
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We use junit style output these days.
Change-Id: I4110ec10bf0e9f4354ee08e7e1c5a81ae605fee0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4484
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
USE_XARGS mode builds n boards in parallel (with 1 CPU each) instead of
building 1 board with n CPUs.
This requires the main build system to work under such circumstances.
Change-Id: Ib4571a78dfe78fd61ae5b26c18be9745bd8b3d52
Reviewed-on: http://review.coreboot.org/4485
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This makes USE_XARGS-abuild unhappy due to races
Change-Id: I1237468366c7f8af7eacd572c2bd32df9a3d58ca
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4486
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The numbers alone are hard to parse, so add
some timestamp names to make it easier to read.
Change-Id: Ie32d3e7ca759bd15e7c160bdd829dec19943e6cb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65333
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4314
Tested-by: build bot (Jenkins)
On ARM the timestamps are already in micro seconds, so
no need to convert them.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If7363b0703e144bde62d9dab4ba845e1ace5bd18
Reviewed-on: https://gerrit.chromium.org/gerrit/63991
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4313
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's a start...
Change-Id: Ibdb0b64ab0349df58bcad5ce553bf0dbec636925
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4483
Tested-by: build bot (Jenkins)
This also adds an option -x/--hexdump to dump the whole
CBMEM area for debugging.
Change-Id: I244955394c6a2199acf7af78ae4b8b0a6f3bfe33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62287
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4312
Tested-by: build bot (Jenkins)
on ARM the CBMEM utility requires the procfs entry
/proc/device-tree/firmware/coreboot/coreboot-table
provided by the FDT (dynamically created by depthcharge
at the moment)
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If5f961afb23791af6f32dd4fc9a837a1aa41b70e
Reviewed-on: https://gerrit.chromium.org/gerrit/59322
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The update-fit command takes in a parameter for number of slots
in the FIT table. It then processes the microcobe blob in cbfs
adding those entries to the FIT table. However, the tracking of
the number of mircocode updates was incremented before validating
the update. Therefore, move the sanity checking before an increment
of the number of updates.
Change-Id: Ie8290f53316b251e500b88829fdcf9b5735c1b0e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50319
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4161
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit b8ad224 changed the memory address in lb_cbmem_ref coreboot
table entries from a pointer to a uint64_t. This change was introduced
to make the cbmem utility work on both 32bit and 64bit userland.
Unfortunately, this broke the cbmem utility running on older versions
of coreboot because they were still providing a 32bit only field for
the address while the cbmem utility would now take the following 4
bytes as upper 32bits of a pointer that can obviously not be
mmapped. This change checks if the size of the lb_cbmem_ref structure
provided by coreboot is smaller than expected, and if so, ignore the
upper 32bit of the address read.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If4c8e9b72b2a38c961c11d7071b728e61e5f1d18
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The field wasn't initialized in RAM first and later overwritten in a somewhat
twisted way (that relied on the size field coming after the tag field in the
struct).
Change-Id: Ibe931b297df51e3c46ae163e059338781f5a27e2
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4087
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This moves an ugly comment closer to where it is applicable and also
adds a visual break between the commands which gather data and the
part of the script that finishes up. I'm usually not fan of banner
comments, but it seemed to help in my totally subjective opinion.
I was thinking about how to break the part that uploads results into
a separate function, but there are enough variables that are re-used
from earlier parts that the tradeoff probably isn't worth it.
Change-Id: If888329911c4de3b907cdf5973695c707bbb02fe
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4051
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This allows the command wrappers to delete files if the command
fails. In particular, it delets empty or otherwise useless files
that are generated if a non-fatal command fails.
Change-Id: If26d7b4d7500f160edd1cc2a8b6218792fefae8b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4050
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds cmd_nonfatal() for commands which are considered
non-essential and can be expected to fail safely. This can be used,
for example, to gather data that is generated when using non-standard
utilities or coreboot config options.
Change-Id: Ie43944d2eb73f9aae1c30c3a204cfc413e11d286
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4049
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is really only a cosmetic change, but is intended to make it
slightly easier to remember to update the help menu whenever
options change.
Change-Id: I58b5012309229d08da138a01c7cd1c5096423179
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4048
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Clobbering output is only really useful when debugging the script.
Since we're only using short options, let's save 'c' for something
more important.
Change-Id: If87a70fdc0cd006818d1736c40f9984dfec663a9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the first major re-work for the board status script.
Summary:
- Added a command to the getrevision.sh script to retrieve tagged
revision.
- Results are placed in a dynamically generated temporary location.
This makes it easy to do multiple trial runs and avoids polluting
the coreboot directory.
- Results are stored in a directory with the following form:
<vendor>/<mainboard>/<tagged_revision>/<timestamp>/
Vendor and mainboard are obtained from CONFIG_MAINBOARD_DIR so that
hierarchy is consistent between coreboot and board-status.
- The results directory is used as the commit message.
- board-status repository is checked out automatically if results are
to be uploaded.
TODO:
- Add ability to run commands which may fail. Currently we assume
any failure should terminate the script, but some commands can be
made optional.
Successfully uploaded first result to board-status repository. See
http://review.coreboot.org/gitweb?p=board-status.git;a=summary .
Change-Id: Icba41ccad4e6e6ee829b8092a2459c2d72a3365b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4039
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Arrays are indexed 0..(number_of_element-1).
Change-Id: I2157e74340568636d588113d1d2d8cae50082da2
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4089
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This just moves stuff to be more clear about the purpose of
the script. Other suggestions are welcome.
Change-Id: Ic6095fd4eb347daa5a03eff21b5952d2d42a6bfd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4038
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The tools for aarch64 on ubuntu are called
aarch64-linux-gnu-*
The type is
elf64-littleaarch64
This now finds the right files for building on aarch64
This has only been tested on ubuntu saucy; the aarch64 toolchain
is in a very ill-defined state on most distros.
Change-Id: Ic1bbd40f0d72384d6e80287b850686292a252918
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4035
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The whitespaces make "git commit" failed.
lint-stable-003-whitespace
Check for superfluous whitespace in the tree
========
test failed:
File util/status/status.sh has lines ending with whitespace.
========
Change-Id: I52fc5ae3e5aa81dac098b36d2479e4d10325a09b
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4032
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This reports relevant bits of information about a machine which is
running coreboot. This also includes a script to get revision info
from git, which we may want to split out into another patch.
A remote target can be specified since it is likely that the machine
used to develop the code is not the same machine being developed for.
The remote host must be set up for non-interactive root login.
Example: sh util/status/status.sh -r gizmoboard -u
Change-Id: Ief0a85faca2ec9ce2d270e1e5b09e74836ab0c97
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4021
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some editors like gedit create auxiliary files ending with a
tilde '~'. As these are not checked into the Git repository, do
not check these for whitespace errors.
Change-Id: I2c4cf00f9d623be73ea3bbb7b2da4f1e1900c8e9
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3952
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
SeaBIOS’ Makefile requires cpp (C Preprocessor) to build. Modify
the xcompile script to search for cpp program path, and pass it to
SeaBIOS’ `Makefile.inc`. Also pass the program path for as (GNU assembler).
This is needed, so the crossgcc toolchain to build the SeaBIOS payload
under Mac OSX. OSX ships a cpp program, but it works differently
from GNU CPP, so we need to override it.
Change-Id: If996ffbb76ec4bd16079b54b41f3fac07bfe25be
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3896
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
`util/lint/lint-stable-002-build-dir-handling` always overwrites your
current `config.h` and `auto.conf` when the pre-commit hook is run. It
can be very confusing when your configuration is suddenly broken. So fix
it by not using the default build directory.
Change-Id: If2bbc97ac2f12a8203a3769d813386a023f93dd6
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3593
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
gcc 4.8.x has issues with using ebp, which broke some builds,
so downgrade. The problem also manifested elsewhere, so it's
not necessarily our fault.
While at it, gcc complained about "armv7a" where it seems to
expect "armv7-a".
Change-Id: I6f0c35f49709cb41022475bb47116c12ab1c7ee3
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3930
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This simplifies debugging and also fixes an issue when build directories
are kept between buildgcc runs for different architectures.
Change-Id: I5badccd3368e3014680da3eedb607119fff8fa7f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3929
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Clean whitespace errors that have gotten past lint-stable-003-whitespace
and gerrit review.
Change-Id: Id76fc68e9d32d1b2b672d519b75cdc80cc4f1ad9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3920
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The rule "-perm +111 -prune" matched any searchable directory
and did not recursively find files in them. The use of "+mode"
for -perm is deprecated.
Change-Id: I1b43f89ee9ab37928e56104b0f07241ff84b84c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3921
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It wasn't even hooked up to the build system anymore.
Change-Id: I4b962ffd945b39451e19da3ec2f7b8e0eecf2e53
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3892
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
In the great tradition of LinuxBIOS this allows adding
a kernel as payload. add-payload is extended to also
allow adding an initial ramdisk (-I filename) and a
command line (-C console=ttyS0).
Change-Id: Iaca499a98b0adf0134e78d6bf020b6531a626aaa
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3302
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
acpica-unix-20130626 doesn't use bin32 and bin64 to save the objects
any more.
Change-Id: I419ecc987e2adcd860a8ad1bf2f6b5c4dd40fd8a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/3885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This simplifies storing SeaBIOS parameters in CBFS.
Change-Id: I301644ba0d7a9cb5917c37a3b4ceddfa59e34e77
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3733
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The raw CPUID is useful for matching the directories under 'src/cpu/intel'
and is not easy to find out otherwise because it is most often decoded
already. The decoded values are not obviously hexadecimal so prepend
them with 0x to make sure they are unambiguous.
The output differences look like this:
- CPU: Processor Type: 0, Family 6, Model 25, Stepping 2
+ CPU: ID 0x20652, Processor Type 0x0, Family 0x6, Model 0x25, Stepping 0x2
Change-Id: Id47f0b00f8db931f0000451c8f63ac1e966442c4
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3788
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Tested-by: build bot (Jenkins)
This is a trivial patch moving cpuid() call after reading argv
so that verbose is set.
Change-Id: Ic621191ef650495614a041413c1a0f707d4469e6
Signed-off-by: Benoît Legat <benoit.legat@gmail.com>
Reviewed-on: http://review.coreboot.org/3627
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The .dependencies rule did not use the CPPFLAGS variable which led
to funny behavior: a spurious termination message the first time
(after checkout/make distclean) one executes make. Afterwards the
(wrongly) empty .dependencies file hides the problem and the binary
is created anyway.
$ make
cbmem.c:37:34: fatal error: boot/coreboot_tables.h: No such file or directory
compilation terminated.
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cc cbmem.o -o cbmem
$ make
make: Nothing to be done for `all'.
$ make clean
rm -f cbmem *.o *~
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cc cbmem.o -o cbmem
$ make distclean
rm -f cbmem *.o *~
rm -f .dependencies
$ make
cbmem.c:37:34: fatal error: boot/coreboot_tables.h: No such file or directory
compilation terminated.
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cc cbmem.o -o cbmem
I fixed that by adding the CPPFLAGS variable to the .dependencies recipe, just
like Stefan Reinauer did in Chromium (Ia9d2e10a3ef122f30d681d16c2291eb108ead835),
hence the split sign-off for this tiny change. :)
Change-Id: Icd11b146ad762cbdf9774630b950f70e1253a072
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3548
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
abuild checks the path for toolchains prior to building a
mainboard. It didn't check xgcc/, which would be picked up
by the coreboot make, and fail to build when it shouldn't.
Change-Id: If0ca4238e8c57a6b015fdad623ccdbf237ef1ba6
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/3350
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This new tool called `ifdfake` just creates an empty Intel Firmware
Descriptor (IFD) and writes the IFD signature plus the section layout
given on the command line.
usage: ifdfake [(-b|-m|-g|-p) <start>:<end>]... <output file>
-b | --bios <start>:<end> BIOS region
-m | --me <start>:<end> Intel ME region
-g | --gbe <start>:<end> Gigabit Ethernet region
-p | --platform <start>:<end> Platform Data region
-h | --help print this help
<start> and <end> bounds are given in Bytes, the <end> bound is inclusive.
All regions must be multiples of 4K in size and 4K aligned.
The descriptor region always resides in the first 4K.
An IFD created with ifdfake won't work as a replacement for a real IFD.
Never try to flash such an IFD to your board!
The output of ifdfake can be utilized to build an image with just the
later added sections (like coreboot itself) being valid. The resulting
image can then be partially written to a machines flash ROM to just
update coreboot (i.e. the BIOS section).
Change-Id: I925b47cab5c6d490a79d684bdd7a7a45ac442640
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3523
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are no files to build left under AMD nortbridge/x/root_complex
directories. For some cases, even the Kconfig file was no longer sourced.
Remove all such references and empty files.
For devicetree.cb treat component paths with "/root_complex" in them valid
even when the directory does not exists. This is because AMD boards us this
dummy chip component as the root node in their devicetree.cb.
The generated devicetree file static.c remains unchanged.
Change-Id: I9278ebb50a83cebbf149b06afb5669899a8e4d0b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3434
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Also, add pretty printing of Westmere's DMI registers (tested on my t410s
by staring at non-zero output values :)
Apparently Nehalem does not have a MEMBAR? But there are some
documented memory controller control registers in PCI configuration
space... left out for now.
The PCIEXBAR is not documented publicly AFAICT, but there is
a similar register on a device on bus 0xFF. phcoder might know more...
Change-Id: I5faadb6e4f701728f5290276c02809b4993bd86d
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3505
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
e4e8e090fa does add support for QM57,
but there are many more that should work with that code(?).
Does not explode on...
CPU: Processor Type: 0, Family 6, Model 25, Stepping 2
Northbridge: 8086:0044 (1st generation (Westmere family) Core Processor)
Southbridge: 8086:3b0f (QS57)
Change-Id: I85e15ba45678a5bd635415a7a8d69c05bff8f7ef
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3321
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This is spkmodem receiver counterpart.
Change-Id: Id27d32608502029fb6fcc8154f508811bf5ca77b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3411
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
While some of the case .. break statement actually weren't needed,
too are, since otherwise the option parsing loop hangs.
Exit conditions for that endless loop: "--" or no more arguments,
in line with GNU command line parsing rules.
Change-Id: I0dbc35e530fb8c93a0f7de05ac47f325555ad4a4
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3418
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Added support for Intel Atom cpu to msrtool
Fixed a cut&paste error in nehalem msr bits definition
It has been tested with a N455 cpu and msrtool output can be review at:
http://www.trillion01.com/coreboot/msrtool_atom.txt
Change-Id: I0ecf455b559185e2d16fa1a655bf021efc2ef537
Signed-off-by: Olivier Langlois <olivier@olivierlanglois.net>
Reviewed-on: http://review.coreboot.org/3351
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
viatool is a utility for extracting useful for extracting certain configuration
bits on VIA chipsets and CPUs. It is a fork of inteltool.
viatool is currently focused on "quirks". Quirks are device configurations that
cannot be accessed directly. They are implemented as hierarchical configurations
in the PCI or memory address spaces (index/data register pairs). Such
configurations refer to hardware parameters that are board specific. Those
parameters would otherwise be difficult to extract from a system running the
vendor's firmware.
viatool also preserves inteltool's MSR dumps. VIA CPU and Intel CPU MSRs are
nearly identical.
Change-Id: Icbd39eaf7c7da5568732d77dbf2aed135f835754
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1430
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Bash case statements are terminated with ';;'.
Unlike C, bash case statements will not continue to the next case. No 'break' is needed.
Change-Id: I62e7e91f3223ac4052728a1ca12a4681af0dc036
Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-on: http://review.coreboot.org/3330
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use PRIx64 to print a u64 instead of "llx". Fixes the following error:
cbmem.c: In function 'parse_cbtable':
cbmem.c:135:2: error: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type 'u64' [-Werror=format=]
Change-Id: Ibc2bf8597cb86db5b2e71fba77ec837a08c5e3d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
buildgcc has many wrong choices, and two right ones,
but you would never guess that. It's even more
frustrating when it spends lots of time building a
full tool chain and you find out it's not the one you
wanted and, still worse, you've forgotten what it does want
and, even worse, it won't f-ing tell you what the two
right choices are!.
Have it tell you when you've done something wrong, and have it
make reasonable decisions when you say things like
-p arm
instead of
-p armv7a-eabi
This change lowers my blood pressure 10 points.
Change-Id: I44a59d7cb7a6260894d8bcb692a693ed25681ff8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3292
Tested-by: build bot (Jenkins)
Properly check the dependency of choices as a group.
Also fix that sym_check_deps() correctly terminates the dependency loop
error check (otherwise it would continue printing the dependency chain).
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
Change-Id: I0c98760dd0f55cf2ff70c53e0b014288b59574c8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3290
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Fix reversal of dlg.border.atr and dlg.dialog.atr for draw_box()
Makes the inputbox look like expected
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
Change-Id: I596915aab0204ef0e392fefa56fad8e25204e207
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3289
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As choice dependency are now fully checked, it's quite easy to add support
for named choices. This lifts the restriction that a choice value can only
appear once, although it still has to be within the same group,
but multiple choices can be joined by giving them a name.
While at it I cleaned up a little the choice type logic to simplify it a
bit.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
Change-Id: If0f00d1783907d606220cda5307b8960d3bfc38d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3291
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
right now this is just a fake option to get rid of ifdefs in
coreboot's code.
Change-Id: I59233f3c1d266b4e716a5921e9db298c7f96751d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3225
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This option has never had much if any use. It solved a problem over 10
years ago that resulted from an argument over the value or lack thereof
of including all the debug strings in a coreboot image. The answer is
in: it's a good idea to maintain the capability to print all messages,
for many reasons.
This option is also misleading people, as in a recent discussion, to
believe that log messges are controlled at build time in a way they are
not. For the record, from this day forward, we can print messages at all
log levels and the default log level is set at boot time, as directed by
DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and
if you are having trouble override it in CMOS and get more messages.
Besides, a quick glance shows it's always set to max (9 in this case) in
the very few cases (1) in which it is set.
Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3188
Tested-by: build bot (Jenkins)
We write CMOS data to 128 byte files, which is a problem
when using them later-on (eg. as part of a coreboot image)
where nvramtool assumes them to be 256 byte, and so data
corruption occurs.
Change-Id: Ibc919c95f6d522866b21fd313ceb023e73d09fb9
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3186
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update crossgcc to use gcc 4.7.3
The resulting coreboot.rom is not runtime tested (any volunteers?).
Drop the texinfo patch, rename the armv7a patch.
Some Linux distributions have moved on to gcc 4.8,
under certain circumstances this version can't (cross-)compile gcc 4.7.2
Bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56927
Change-Id: Id8ce5f86c34e1a0900d44dc6ae4e81cb9548ecc2
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/3112
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
cbmem currently fails to build due to `-Werror` and the following
warning.
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cbmem.c: In function ‘map_memory’:
cbmem.c:87:2: error: format ‘%zx’ expects argument of type ‘size_t’, but argument 2 has type ‘off_t’ [-Werror=format]
[…]
Casting the argument of type `off_t` to `intmax_t` and using the
length modifier `j`
$ man 3 printf
[…]
j A following integer conversion corresponds to an intmax_t or uintmax_t argument.
[…]
instead of `z` as suggested in [1] and confirmed by stefanct and
segher in #coreboot on <irc.freenode.net>, gets rid of this warning
and should work an 32-bit and 64-bit systems, as an `off_t` fits
into `intmax_t`.
[1] http://www.pixelbeat.org/programming/gcc/int_types/
Change-Id: I1360abbc47aa1662e1edfbe337cf7911695c532f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3083
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When building inteltool with Clang, it warns about the following.
$ clang --version
Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang make
[…]
clang -O2 -g -Wall -W -c -o pcie.o pcie.c
pcie.c:297:40: warning: signed shift result (0xFF0000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
pciexbar_phys = pciexbar_reg & (0xff << 28);
~~~~ ^ ~~
pcie.c:301:41: warning: signed shift result (0xFF8000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
pciexbar_phys = pciexbar_reg & (0x1ff << 27);
~~~~~ ^ ~~
pcie.c:305:41: warning: signed shift result (0xFFC000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
pciexbar_phys = pciexbar_reg & (0x3ff << 26);
~~~~~ ^ ~~
3 warnings generated.
[…]
Specifying the length by using the suffix `0xffULL` fixes these issues
as now enough bits are available.
These issues were introduced in commit 1162f25a [1].
commit 1162f25a49
Author: Stefan Reinauer <stepan@coresystems.de>
Date: Thu Dec 4 15:18:20 2008 +0000
Patch to util/inteltool:
* PMBASE dumping now knows the registers.
* Add support for i965, i975, ICH8M
* Add support for Darwin OS using DirectIO
[1] http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=1162f25a49e8f39822123d664cda10fef466b351
Change-Id: I7b9a15b04ef3bcae64e06266667597d0f9f07b79
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3015
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now users can use a different compiler from GCC like Clang by for example
doing `CC=clang make`.
Change-Id: I664a36df79f7496a56d89bdb61948b2eda33a6b4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3082
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In [1] Idwer Vollering noted, that the type `u64` is not portable so
on his FreeBSD system, the following warning is shown.
$ clang -O2 -Wall -W -I/usr/local/include -c -o amb.o amb.c
amb.c:441:22: error: use of undeclared identifier 'u64'
ambconfig_phys = ((u64)pci_read_long(dev16, 0x4c) << 32) |
The type `uint64_t` seems to be defined also on FreeBSD, so using this
fixes the warning.
Note, this warning is not reproducable with Debian Sid/unstable for
example. I have no idea why though.
[1] http://review.coreboot.org/#/c/3015/
Change-Id: Ic22f4371114b68ae8221d84a01fef6888d43f365
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3086
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently on a 32-bit system cbmem fails to build due to `-Werror`
and the following warning.
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
[…]
cbmem.c: In function ‘parse_cbtable’:
cbmem.c:135:2: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘u64’ [-Werror=format]
cc1: all warnings being treated as errors
[…]
Using the length modifier `ll` instead of `l` gets rid of this
warning.
Change-Id: Ib2656e27594c7aaa687aa84bf07042933f840e46
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3084
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Cppcheck warns about a memory leak, present since adding romtool,
which was renamed to cbfstool, in commit 5d01ec0f.
$ cppcheck --version
Cppcheck 1.59
[…]
[cbfs-mkstage.c:170]: (error) Memory leak: buffer
[…]
Indeed the memory pointed to by `buffer` is not freed on the error path,
so add `free(buffer)` to fix this.
Change-Id: I6cbf82479027747c800c5fe847f20b779e261ef4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3069
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The URL to acpica-unix-20121114 has changed, update the URL.
Change-Id: I1c8c228094f19455af3682f36f1990586fe3934c
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/3070
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Current code outputs the whole cbmemc buffer even if only part of
it is really used. Fix it to output only the used part and notify
the user if the buffer was too small for the required data.
Change-Id: I68c1970cf84d49b2d7d6007dae0679d7a7a0cb99
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2991
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The LZMA glue code in cbfstool was recently rewritten from C++
to plain C code in:
commit aa3f7ba36e
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Thu Mar 28 16:51:45 2013 -0700
cbfstool: Replace C++ code with C code
Reviewed-on: http://review.coreboot.org/3010
In the progress of doing so, the stream position for the
input stream and output stream was not reset properly. This
would cause LZMA producing corrupt data when running the
compression function multiple times.
Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3040
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This fixes at least one warning on my machine where "llx" is replaced by PRIx64.
Change-Id: Iee3e5027d327d4d5f8e6d8b2d53d051f74bfc354
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3024
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Cppcheck [1], a static code analysis tool, warns about the
following.
$ cppcheck --version
Cppcheck 1.59
$ cppcheck --enable=all .
[…]
Checking cpu.c...
[cpu.c:951]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[cpu.c:962]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[…]
And indeed, `core` is an unsigned integer and `man 3 printf` tells
the following about conversion specifiers.
d, i The int argument is converted to signed decimal notation. […]
o, u, x, X
The unsigned int argument is converted to unsigned octal (o), unsigned decimal (u), or unsigned hexadecimal (x and X)
notation.
So use `u` and Cppcheck does not complain anymore.
[1] http://cppcheck.sourceforge.net/
Change-Id: If8dd8d0efe75fcb4af2502ae5100e3f2062649e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3026
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Nico Huber spotted [1], that commit (4d6ab4e2) [1] updating
superiotools’s `README` with the Git command line
superiotool: Update README with Git repository URL and directory location
missed, that after `git clone` one sitll has to change into
the cloned directory.
So prepend the path with `coreboot/` to fix that. The same error
happened in the commit (e1ea5151) for libpayload [2]
libpayload: Update README with Git repository URL and directory location
and is fixed in this patch too.
[1] http://review.coreboot.org/#/c/3019/
[2] http://review.coreboot.org/2228
Change-Id: Ib6e8b678af6276556a40ccfd52ae35ca7e674455
Reported-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3021
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When building inteltool under x86-32, the following warnings are
shown.
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
Nico Huber commented the following [1].
I don't see those warnings because I build for x86-64. I guess
they could be fixed by casting to `ptrdiff_t` (from stddef.h)
instead of `uint64_t`.
And indeed, using `ptrdiff_t` fixes the warning. But as Stefan
Reinauer commented in [2], `intptr_t` is more appropriate as this
is just a pointer and no pointer difference.
So `intptr_t` is taken, which fixes these issues warned about too.
These warnings were introduced in commit »inteltool: Add support for
dumping AMB registers« (4b7b320f) [3].
[1] http://review.coreboot.org/#/c/2996/1//COMMIT_MSG
[2] http://review.coreboot.org/#/c/3002/1/util/inteltool/amb.c
[3] http://review.coreboot.org/525
Change-Id: I2ea1a31dc1e3db129e767d6a9e0433fd75a77d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3002
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When buidling inteltool with GCC, the following warning is printed.
$ make
[…]
gcc -O2 -g -Wall -W -c -o memory.o memory.c
memory.c: In function ‘print_mchbar’:
memory.c:287:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
[…]
This was introduced in commit »inteltool: Add support for H65 Express
chipset« (c7fc4422) [1].
Address this warning, by using `%llx` instead of `%lx`.
[1] http://review.coreboot.org/1258
Change-Id: I4f714edce7e8b405e1a7a417d02fa498322c88a8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2994
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Tested-by: build bot (Jenkins)
cbfstool was using a C++ wrapper around the C written LZMA functions.
And a C wrapper around those C++ functions. Drop the mess and rewrite
the functions to be all C.
Change-Id: Ieb6645a42f19efcc857be323ed8bdfcd9f48ee7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3010
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The help text says --machine, but the code
actually checked for --arch. Fix it!
Change-Id: Ib9bbf758b82ef070550348e897419513495f154b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3009
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Allow to override the variables `CC`, `INSTALL`, `PREFIX`,
`CFLAGS` and `LDFLAGS`. Though append `-lpci -lz` to `LDFLAGS`.
This way for example a different compiler can easily be used.
CC=clang make
As a side note, Clang in contrast to GCC does *not* issue the
following warnings.
$ clang --version
Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
These are only shown under 32-bit and not 64-bit
$ uname -m
i686
and are going to be fixed in a separate patch.
Change-Id: Id75dea081ecb35390f283520a7e5dce520f4c98d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2996
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the power management register definitions for Intel's Cougar
Point and Panther Point platform controller hubs (PCH). The definitions
are actually a subset of the older ICH10R registers: I've added just
those that are mentioned in the public specifications in [1] and [2].
I've tested dumping with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: Ia6945fe96cd96b568ed5191e91dbba5556e1ee95
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2985
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the PCI IDs of Intel's Cougar Point and Panther Point platform
controller hubs (PCH) to the dumping of the root complex configuration
under the root complex base address (RCBA). Those PCHs are handled exactly
as the older ICHs which can be seen in [1] and [2]. I've tested dumping
with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I2296caae57e614171300362d41715deecec77762
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2986
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This way for example a different compiler can easily be used.
CC=clang make
Change-Id: I50b83554fd4826d00d87e60a30eb1f6a88834397
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2935
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds the GPIO register definitions for Intel's Cougar Point and
Panther Point platform controller hubs (PCH). All information is taken
from the public specifications in [1] and [2]. I've tested it with an
H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I31711e24f852e68b3c113e3bd9243dc7e89ac197
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2961
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds correspondings #defines for the PCI IDs of the LPC device on
Intel's Cougar Point and Panther Point platform controller hubs. Those
will be used more in later commits.
I've checked all those IDs against the specification updates [1] and [2].
[1] Intel 6 Series Chipset and Intel C200 Series Chipset Specification
Update
Document-Number: 324646-019
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH)
Family - Datasheet Specification Update
Document-Number: 326777-010
Change-Id: Ibef5a30d283c568c345eb8d8149723e7a3049272
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2960
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If you have a recent version of texinfo installed, building the reference
toolchain fails with the following error:
(in util/crossgcc/build-gcc/crossgcc-build.log)
[...]/gcc-4.7.2/gcc/doc/cppopts.texi:806: @itemx must follow @item
Looks like a warning-became-an-error problem in texinfo, to me. Fix that by
making every erroneous @itemx an @item.
Change-Id: I685ae1ecfee889b7c857b148cfab7411a10e7ecd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2939
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Add support for filling in the Firmware Interface Table.
For now it only supports adding microcode entries.
It takes 2 options:
1. Name of file in cbfs where the mircocode is located
2. The number of empty entries in the table.
Verified with go firmware tools. Also commented out updating
microcode in the bootblock. When romstage runs, the CPUs indicate
their microcode is already loaded.
Change-Id: Iaccaa9c226ee24868a5f4c0ba79729015d15bbef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2712
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
- The read-only structures are const now
- cosmetic fixes
- put { on a new line for functions
- move code after structures
Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2922
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
In commit e820e5cb3a titled
"Make xcompile support multiple architectures" the LINKER_SUFFIX
variable was introduced to bypass gold if the bfd linker was
available. However, the LINKER_SUFFIX wasn't honored when
the compiler evironment variables were set. Fix the original
intention.
Change-Id: I608f1e0cc3d0bea3ba1e51b167d88c66d266bceb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2879
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When calculating initial CBFS empty entry space, the size of header itself must
be not included (with the reserved space for entry name). This is a regression
of the old cbfstool size bug.
Before this fix, in build process we see:
OBJCOPY cbfs/fallback/romstage_null.bin
W: CBFS image was created with old cbfstool with size bug.
Fixing size in last entry...
And checking the output binary:
cbfstool build/coreboot.pre1 print -v -v
DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes)
DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30
W: CBFS image was created with old cbfstool with size bug.
Fixing size in last entry...
DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00.
coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64
Name Offset Type Size
(empty) 0x0 null 261296
DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0
After this fix, no more alerts in build process.
Verified to build successfully on x86/qemu and arm/snow configurations.
Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbfstool usage change:
"-a" for "cbfstool locate" can specify base address alignment.
To support putting a blob in aligned location (ex, microcode needs to be aligned
in 0x10), alignment (-a) is implemented into "locate" command.
Verified by manually testing a file (324 bytes) with alignment=0x10:
cbfstool coreboot.rom locate -f test -n test -a 0x10
# output: 0x71fdd0
cbfstool coreboot.rom add -f test -n test -t raw -b 0x71fdd0
cbfstool coreboot.rom print -v -v
# output: test 0x71fd80 raw 324
# output: cbfs_file=0x71fd80, offset=0x50, content_address=0x71fdd0+0x144
Also verified to be compatible with old behavior by building i386/axus/tc320
(with page limitation 0x40000):
cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
# output: 0x44
cbfstool coreboot.rom locate -f x.bin -n romstage -P 0x40000 -a 0x30
# output: 0x60
Change-Id: I78b549fe6097ce5cb6162b09f064853827069637
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2824
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
cbfstool usage change:
The "-a" parameter for "cbfstool locate" is switched to "-P/--page-size".
The "locate" command was used to find a place to store ELF stage image in one
memory page. Its argument "-a (alignment)" was actually specifying the page size
instead of doing memory address alignment. This can be confusing when people are
trying to put a blob in aligned location (ex, microcode needs to be aligned in
0x10), and see this:
cbfstool coreboot.rom locate -f test.bin -n test -a 0x40000
# output: 0x44, which does not look like aligned to 0x40000.
To prevent confusion, it's now switched to "-P/--page-size".
Verified by building i386/axus/tc320 (with page limitation 0x40000):
cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
# output: 0x44
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Change-Id: I0893adde51ebf46da1c34913f9c35507ed8ff731
Reviewed-on: http://review.coreboot.org/2730
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Zheng Bao