The architecture information has been added to the folders to
build archives for crossgcc. We need to change the .gitignore
to keep ignoring them.
Change-Id: Ic18685e507f1b09088120eee6047d49141e29906
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4513
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Since a long time GRUB 2 is a viable payload alternative to SeaBIOS and
FILO. So make it easy for coreboot users to use GRUB 2 as a payload by
integrating it into coreboot’s build system, so it can be selected in
Kconfig.
As the last GRUB 2 release 2.00 is too old and has several bugs when
used as a coreboot payload only allow to build GRUB 2 master until a new
GRUB release is done. The downside is, that accidental breakage in
GRUB’s upstream does not affect coreboot users.
Currently the GRUB 2 payload is built with the default modules which
results in an uncompressed size of around 730 kB. Compressed it has a
size of 340 kB, so it should be useable with 512 kB flash ROMs.
Tested with QEMU.
Change-Id: Ie75d5a2cb230390cd5a063d5f6a5d5e3fab6b354
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4058
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
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)
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>
- Development friendly files (tags, clang_complete)
- Cross-compile stuff (xgcc, tarballs)
This patch was originally written by Stefan.
Change-Id: I4229414c94ee04a4f38a748369c4ac90fda57aea
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/2128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Coreboot and u-boot create a table of timestamps which allows to see
the boot process performance. The util/cbmem/cbmem.py script allows to
access the table after ChromeOS boots up and display its contents on
the console. The problem is that shipping images do not include Python
interpreter, so there is no way to access the table on a production
machine.
This change introduces a utility which is a Linux app displaying the
timestamp table. Conceivably the output of this utility might be
included in one of the ChromeOS :/system sections, so it was attempted
to write this procedure 'fail safe', namely reporting errors and not
continuing processing if something goes wrong.
Including of coreboot/src .h files will allow to keep the firmware
timestamp implementation and this utility in sync in the future.
Test:
. build the utility (run 'make' while in chroot in util/cbmem)
. copy `cbmem' and 'cbmem.py' to the target
. run both utilities (limiting cbmem.py output to 25 lines or so)
. observe that the generated tables are identical (modulo rounding
up of int division, resulting in 1 ns discrepancies in some
cases)
localhost var # ./cbmem
18 entries total:
1:62,080
2:64,569 (2,489)
3:82,520 (17,951)
4:82,695 (174)
8:84,384 (1,688)
9:131,731 (47,347)
10:131,821 (89)
30:131,849 (27)
40:132,618 (769)
50:134,594 (1,975)
60:134,729 (134)
70:363,440 (228,710)
75:363,453 (13)
80:368,165 (4,711)
90:370,018 (1,852)
99:488,217 (118,199)
1000:491,324 (3,107)
1100:760,475 (269,150)
localhost var # ./cbmem.py | head -25
time base 4249800, total entries 18
1:62,080
2:64,569 (2,489)
3:82,520 (17,951)
4:82,695 (174)
8:84,384 (1,688)
9:131,731 (47,347)
10:131,821 (89)
30:131,849 (27)
40:132,618 (769)
50:134,594 (1,975)
60:134,729 (134)
70:363,440 (228,710)
75:363,453 (13)
80:368,165 (4,711)
90:370,018 (1,852)
99:488,217 (118,199)
1000:491,324 (3,107)
1100:760,475 (269,150)
Change-Id: I013e594d4afe323106d88e7938dd40b17760621c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1759
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds...
- generated documentation files
- all kinds of stuff in the util subdirectories
Change-Id: I47ab6d239aae725f54413f03424f40002ac5a275
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/1572
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
KDE editors love to create tons of backup files every time a file is
edited. This makes it very hard to get useful information from git status
and very easy to commit the wrong stuff. Add those to the gitignore list.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Change-Id: I2fbb907f21d85d6994caa8bbe32c4e9814b5f4b4
Reviewed-on: http://review.coreboot.org/1423
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
don't remove calls to `flatten()' and `correct_coalesce_conflicts()',
since they (probably) have side effects.
Change-Id: I78fc4163b3f5f1f5f3c5153f9559c22e11e8344d
Signed-off-by: Bernhard Urban <lewurm@gmail.com>
Reviewed-on: http://review.coreboot.org/605
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Edward O'Callaghan