the following patch was just integrated into master:
commit e05c1eac44443f566af3909831328806bb8cd49a
Author: zbao <fishbaozi(a)gmail.com>
Date: Wed Aug 5 23:10:05 2015 -0400
buildgcc: Get the clean and correct uname on Cygwin
Running `uname` on Cygwin gets "CYGWIN_NT-6.1-WOW" instead of "Cygwin".
We need to fix the $UNAME on Cygwin.
Change-Id: I540bfc52089951006fd0e20bb9893a3d891df9e1
Signed-off-by: Zheng Bao <zheng.bao(a)amd.com>
Signed-off-by: Zheng Bao <fishbaozi(a)gmail.com>
Reviewed-on: http://review.coreboot.org/11124
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
See http://review.coreboot.org/11124 for details.
-gerrit
Zheng Bao (zheng.bao(a)amd.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11124
-gerrit
commit 0ae65aac63cb2dd4e44bfa927e5982e13a3d91aa
Author: zbao <fishbaozi(a)gmail.com>
Date: Wed Aug 5 23:10:05 2015 -0400
buildgcc: Get the clean and correct uname on Cygwin
Running `uname` on Cygwin gets "CYGWIN_NT-6.1-WOW" instead of "Cygwin".
We need to fix the $UNAME on Cygwin.
Change-Id: I540bfc52089951006fd0e20bb9893a3d891df9e1
Signed-off-by: Zheng Bao <zheng.bao(a)amd.com>
Signed-off-by: Zheng Bao <fishbaozi(a)gmail.com>
---
util/crossgcc/buildgcc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/crossgcc/buildgcc b/util/crossgcc/buildgcc
index 590e1f8..cfe881b 100755
--- a/util/crossgcc/buildgcc
+++ b/util/crossgcc/buildgcc
@@ -94,7 +94,7 @@ cyan='\033[0;36m'
CYAN='\033[1;36m'
NC='\033[0m' # No Color
-UNAME=$(uname)
+UNAME=$(uname | grep -iq cygwin && echo Cygwin || uname)
normalize_dirs()
{
Zheng Bao (zheng.bao(a)amd.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11123
-gerrit
commit 13b766691091cc73636de4a1f30f2f3b8162bdd7
Author: zbao <fishbaozi(a)gmail.com>
Date: Wed Aug 5 23:15:54 2015 -0400
buildgcc: Deal with gmp on 32bit Cygwin on 64bit host
Similar to what the below change says,
(
http://review.coreboot.org/10792
commit ddb8f808940899240411282d0feb1e2f65ef43a9
Author: Patrick Georgi <patrick(a)georgi-clan.de>
Date: Sat Jul 4 17:45:54 2015 +0200
buildgcc: Deal with gmp on 32bit Linux on 64bit CPUs
GMP is overeager to detect 64bit ABIs even if the entire running codebase is
32bit (but on a 64bit CPU). Enforce a 32bit build in that situation.
)
building GMP can not detect Cygwin is 32bit either if the
host which Cygwin is running is 64bit. We set ABI=32
in that case.
Change-Id: Ic53d75defebbe902325eb07f3d8631b2a53245ef
Signed-off-by: Zheng Bao <zheng.bao(a)amd.com>
Signed-off-by: Zheng Bao <fishbaozi(a)gmail.com>
---
util/crossgcc/buildgcc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/crossgcc/buildgcc b/util/crossgcc/buildgcc
index cfe881b..eaeafcf 100755
--- a/util/crossgcc/buildgcc
+++ b/util/crossgcc/buildgcc
@@ -622,7 +622,7 @@ if [ $UNAME = "Darwin" ]; then
if $CC -v 2>&1 | grep -q LLVM; then
CC=llvm-gcc
fi
-elif [ $UNAME = "Linux" ]; then
+elif [ $UNAME = "Linux" -o $UNAME = "Cygwin" ]; then
# gmp is overeager with detecting 64bit CPUs even if they run
# a 32bit kernel and userland.
if [ "$(uname -m 2>/dev/null)" = "i686" ]; then
Marc Jones (marc.jones(a)se-eng.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/10741
-gerrit
commit 9ba9df22bd3105f3a3532b608d4c556c9a9bb210
Author: Furquan Shaikh <furquan(a)google.com>
Date: Fri Nov 14 11:57:00 2014 -0800
documentation: Add documentation for timestamp library
[pg: removed discussion of timestamp internals that isn't current anymore in
favor of some notes for users: when to run which function, what _not_ to do.
Also moved to markdown-ish layout. Will do further style cleanups later.]
BUG=chrome-os-partner:32973
BRANCH=None
TEST=None
Change-Id: I6ea7237f2fa749ce3a493f378f9937e642f3b678
Signed-off-by: Marc Jones <marc.jones(a)se-eng.com>
Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org>
Original-Commit-Id: 97e2a3ebd9552c2a91d9ea62be515059428631cb
Original-Change-Id: I4b184ffad6fcd93d63343a9bca34ad013e9d4263
Original-Signed-off-by: Furquan Shaikh <furquan(a)google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229861
Original-Tested-by: Furquan Shaikh <furquan(a)chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan(a)chromium.org>
---
Documentation/timestamp.md | 200 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 200 insertions(+)
diff --git a/Documentation/timestamp.md b/Documentation/timestamp.md
new file mode 100644
index 0000000..3a4c73b
--- /dev/null
+++ b/Documentation/timestamp.md
@@ -0,0 +1,200 @@
+Table of Contents
+=================
+Introduction
+ Transition from cache to cbmem
+
+Data structures used
+ cache_state
+ table
+ entries
+
+Function APIs
+ timestamp_init
+ timestamp_add
+ timestamp_add_now
+ timestamp_sync
+
+Use / Test Cases
+ Case 1: Timestamp Region Exists
+ Case 2: No timestamp region, fresh boot, cbmem_initialize called after
+ timestamp_init
+ Case 3: No timestamp region, fresh boot, cbmem_initialize called before
+ timestamp_init
+ Case 4: No timestamp region, resume, cbmem_initialize called after
+ timestamp_init
+ Case 5: No timestamp region, resume, cbmem_initialize called before
+ timestamp_init
+
+
+Introduction
+============
+The aim of the timestamp library is to make it easier for different boards
+to save timestamps in cbmem / stash (until cbmem is brought up) by
+providing a simple API to initialize, add and sync timestamps. In order
+to make the timestamps persistent and accessible from the kernel, we
+need to ensure that all the saved timestamps end up in cbmem under
+the CBMEM_ID_TIMESTAMP tag. However, until the cbmem area is available,
+the timestamps can be saved to a SoC-defined \_timestamp region or in a
+local stage-specific stash. The work of identifying the right location for
+storing timestamps is done by the library and is not exposed to the user.
+
+Working of timestamp library from a user perspective can be outlined in
+the following steps:
+1. Initialize the base time and reset cbmem timestamp area
+2. Start adding timestamps
+
+Behind the scenes, the timestamp library takes care of:
+1. Identifying the correct location for storing timestamps (cbmem or timestamp
+ region or local stash).
+2. Once cbmem is up, ensure that all timestamps are synced from timestamp
+ region or local stash into the cbmem area.
+3. Add a new cbmem timestamp area based on whether a reset of the cbmem
+ timestamp region is required or not.
+
+Transition from cache to cbmem
+------------------------------
+To move timestamps from the cache to cbmem (and initialize the cbmem area in
+the first place), we use the CBMEM_INIT_HOOK infrastructure of coreboot.
+
+When cbmem is initialized, the hook is called, which creates the area,
+copies all timestamps to cbmem and disables the cache.
+
+After such a transition, timestamp_init() must not be run again.
+
+
+Data structures used
+====================
+The main structure that maintains information about the timestamp cache is:
+struct __attribute__((__packed__)) timestamp_cache {
+ uint16_t cache_state;
+ struct timestamp_table table;
+ struct timestamp_entry entries[MAX_TIMESTAMP_CACHE];
+};
+
+cache_state
+-----------
+The state of the cache is maintained by cache_state attribute which can
+be any one of the following:
+
+enum {
+ TIMESTAMP_CACHE_UNINITIALIZED = 0,
+ TIMESTAMP_CACHE_INITIALIZED,
+ TIMESTAMP_CACHE_NOT_NEEDED,
+};
+
+By default, if the cache is stored in local stash (bss area), then
+it will be reset to uninitialized state. However, if the cache is
+stored in timestamp region, then it might have garbage in any of the
+attributes. Thus, if the timestamp region is being used by any board, it is
+initialized to default values by the library.
+
+Once the cache is initialized, its state is set to
+CACHE_INITIALIZED. Henceforth, the calls to cache i.e. timestamp_add
+know that the state reflected is valid and timestamps can be directly
+saved in the cache.
+
+Once the cbmem area is up (i.e. call to timestamp_sync_cache_to_cbmem),
+we do not need to store the timestamps in local stash / timestamp area
+anymore. Thus, the cache state is set to CACHE_NOT_NEEDED, which allows
+timestamp_add to store all timestamps directly into the cbmem area.
+
+
+table
+-----
+This field is represented by a structure which provides overall
+information about the entries in the timestamp area:
+
+struct timestamp_table {
+ uint64_t base_time;
+ uint32_t max_entries;
+ uint32_t num_entries;
+ struct timestamp_entry entries[0]; /* Variable number of entries */
+} __attribute__((packed));
+
+It indicates the base time for all timestamp entries, maximum number
+of entries that can be stored, total number of entries that currently
+exist and an entry structure to hold variable number of entries.
+
+
+entries
+-------
+This field holds the details of each timestamp entry, upto a maximum
+of MAX_TIMESTAMP_CACHE which is defined as 16 entries. Each entry is
+defined by:
+
+struct timestamp_entry {
+ uint32_t entry_id;
+ uint64_t entry_stamp;
+} __attribute__((packed));
+
+entry_id holds the timestamp id corresponding to this entry and
+entry_stamp holds the actual timestamp.
+
+
+For timestamps stored in the cbmem area, a timestamp_table is allocated
+with space for MAX_TIMESTAMPS equal to 30. Thus, the cbmem area holds
+base_time, max_entries (which is 30), current number of entries and the
+actual entries represented by timestamp_entry.
+
+
+Function APIs
+=============
+
+timestamp_init
+--------------
+This function initializes the timestamp cache and should be run as early
+as possible. On platforms with SRAM, this might mean in bootblock, on
+x86 with its CAR backed memory in romstage, this means romstage before
+memory init.
+
+timestamp_add
+-------------
+This function accepts from user a timestamp id and time to record in the
+timestamp table. It stores the entry in the appropriate table in cbmem
+or _timestamp region or local stash.
+
+
+timestamp_add_now
+-----------------
+This function calls timestamp_add with user-provided id and current time.
+
+
+Use / Test Cases
+================
+
+The following cases have been considered while designing the timestamp
+library. It is important to ensure that any changes made to this library satisfy
+each of the following use cases:
+
+Case 1: Timestamp Region Exists (Fresh Boot / Resume)
+-----------------------------------------------------
+
+In this case, the library needs to call timestamp_init as early as possible to
+enable the timestamp cache. Once cbmem is available, the values will be
+transferred automatically.
+
+All regions are automatically reset on initialization.
+
+Case 2: No timestamp region, fresh boot, cbmem_initialize called after timestamp_init
+-------------------------------------------------------------------------------------
+
+timestamp_init will set up a local cache. cbmem must be initialized before that
+cache vanishes - as happens when jumping to the next stage.
+
+Case 3: No timestamp region, fresh boot, cbmem_initialize called before timestamp_init
+--------------------------------------------------------------------------------------
+
+This case is not supported right now, just don't call timestamp_init after
+cbmem_initialize. (Patches to make this more robust are welcome.)
+
+Case 4: No timestamp region, resume, cbmem_initialize called after timestamp_init
+---------------------------------------------------------------------------------
+
+We always reset the cbmem region before using it, so pre-suspend timestamps
+will be gone.
+
+Case 5: No timestamp region, resume, cbmem_initialize called before timestamp_init
+----------------------------------------------------------------------------------
+
+We always reset the cbmem region before using it, so pre-suspend timestamps
+will be gone.
the following patch was just integrated into master:
commit 74234ebd7b6029ef5a3f65dbdef17784a35055c6
Author: Marc Jones <marc.jones(a)se-eng.com>
Date: Sun Jul 19 16:20:41 2015 -0600
vendorcode: Fixup AGESA PI Kconfig variables
The *_SELECTED Kconfig variables are not needed with the
options contained within "if CPU_AMD_AGESA_BINARY_PI"
introduced in e4c17ce8. It also removes the need to
source and select the default prior to selecting the
AGESA source or AGESA PI option.
Change-Id: Iffa366f575f7f155bd6c7e7ece2a985f747c83be
Signed-off-by: Marc Jones <marc.jones(a)se-eng.com>
Reviewed-on: http://review.coreboot.org/10981
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
See http://review.coreboot.org/10981 for details.
-gerrit
Marc Jones (marc.jones(a)se-eng.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/10981
-gerrit
commit 290799ddc81caf1405eeefab2f27d56d71f903df
Author: Marc Jones <marc.jones(a)se-eng.com>
Date: Sun Jul 19 16:20:41 2015 -0600
vendorcode: Fixup AGESA PI Kconfig variables
The *_SELECTED Kconfig variables are not needed with the
options contained within "if CPU_AMD_AGESA_BINARY_PI"
introduced in e4c17ce8. It also removes the need to
source and select the default prior to selecting the
AGESA source or AGESA PI option.
Change-Id: Iffa366f575f7f155bd6c7e7ece2a985f747c83be
Signed-off-by: Marc Jones <marc.jones(a)se-eng.com>
---
src/vendorcode/amd/Kconfig | 36 +-----------------------------------
src/vendorcode/amd/pi/Kconfig | 29 +++++++++++------------------
2 files changed, 12 insertions(+), 53 deletions(-)
diff --git a/src/vendorcode/amd/Kconfig b/src/vendorcode/amd/Kconfig
index 9720c79..3c66eaf 100644
--- a/src/vendorcode/amd/Kconfig
+++ b/src/vendorcode/amd/Kconfig
@@ -21,8 +21,6 @@ if CPU_AMD_PI
menu "AMD Platform Initialization"
-source src/vendorcode/amd/pi/Kconfig
-
choice
prompt "AGESA source"
default CPU_AMD_AGESA_BINARY_PI if CPU_AMD_PI
@@ -50,39 +48,7 @@ config CPU_AMD_AGESA_OPENSOURCE
endchoice
if CPU_AMD_AGESA_BINARY_PI
-
-config AGESA_BINARY_PI_PATH_DEFAULT_SELECTED
- bool
- default n
-
-config AGESA_BINARY_PI_PATH
- string "AGESA PI directory path"
- default AGESA_BINARY_PI_PATH_DEFAULT if AGESA_BINARY_PI_PATH_DEFAULT_SELECTED
- help
- Specify where to find the AGESA headers and binary file
- for AMD platform initialization.
-
-config AGESA_BINARY_PI_FILE_DEFAULT_SELECTED
- bool
- default n
-
-config AGESA_BINARY_PI_FILE
- string "AGESA PI binary file name"
- default AGESA_BINARY_PI_FILE_DEFAULT if AGESA_BINARY_PI_FILE_DEFAULT_SELECTED
- help
- Specify the binary file to use for AMD platform initialization.
-
-config AGESA_BINARY_PI_LOCATION_DEFAULT_SELECTED
- bool
- default n
-
-config AGESA_BINARY_PI_LOCATION
- string "AGESA PI binary address in ROM"
- default AGESA_BINARY_PI_LOCATION_DEFAULT if AGESA_BINARY_PI_FILE_DEFAULT_SELECTED
- help
- Specify the ROM address at which to store the binary Platform
- Initialization code.
-
+source src/vendorcode/amd/pi/Kconfig
endif
endmenu
diff --git a/src/vendorcode/amd/pi/Kconfig b/src/vendorcode/amd/pi/Kconfig
index 4f7a952..5919b6b 100644
--- a/src/vendorcode/amd/pi/Kconfig
+++ b/src/vendorcode/amd/pi/Kconfig
@@ -27,35 +27,28 @@
if CPU_AMD_PI_00630F01 || CPU_AMD_PI_00730F01 || CPU_AMD_PI_00660F01
-config AGESA_BINARY_PI_DEFAULTS # dummy
- def_bool y
- select AGESA_BINARY_PI_LOCATION_DEFAULT_SELECTED
- select AGESA_BINARY_PI_PATH_DEFAULT_SELECTED
- select AGESA_BINARY_PI_FILE_DEFAULT_SELECTED
-
-config AGESA_BINARY_PI_PATH_DEFAULT
- string
+config AGESA_BINARY_PI_PATH
+ string "AGESA PI directory path"
default "3rdparty/blobs/pi/amd/00630F01" if CPU_AMD_PI_00630F01
default "3rdparty/blobs/pi/amd/00730F01" if CPU_AMD_PI_00730F01
default "3rdparty/blobs/pi/amd/00660F01" if CPU_AMD_PI_00660F01
help
- The default binary file name to use for AMD platform initialization.
+ Specify where to find the AGESA headers and binary file
+ for AMD platform initialization.
-config AGESA_BINARY_PI_FILE_DEFAULT
- string
+config AGESA_BINARY_PI_FILE
+ string "AGESA PI binary file name"
default "FP3/AGESA.bin" if CPU_AMD_PI_00630F01
default "FT3b/AGESA.bin" if CPU_AMD_PI_00730F01
default "FP4/AGESA.bin" if CPU_AMD_PI_00660F01
help
- The default binary file name to use for AMD platform initialization.
+ Specify the binary file to use for AMD platform initialization.
-config AGESA_BINARY_PI_LOCATION_DEFAULT
- hex
- default 0xFFE00000 if CPU_AMD_PI_00630F01
- default 0xFFE00000 if CPU_AMD_PI_00730F01
- default 0xFFE00000 if CPU_AMD_PI_00660F01
+config AGESA_BINARY_PI_LOCATION
+ string "AGESA PI binary address in ROM"
+ default 0xFFE00000
help
- The default ROM address at which to store the binary Platform
+ Specify the ROM address at which to store the binary Platform
Initialization code.
endif
Zheng Bao (zheng.bao(a)amd.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11123
-gerrit
commit 80c12eb3501fc1f22c570a2e7e872136a76bf065
Author: zbao <fishbaozi(a)gmail.com>
Date: Wed Aug 5 09:00:26 2015 -0400
buildgcc: Deal with gmp on 32bit Cygwin on 64bit host
Similar to what the below change says,
http://review.coreboot.org/10792
building GMP can not detect Cygwin is 32bit if the
host which Cygwin is running is actually 64bit. Let ABI=32
if that happens.
And running `uname` on Cygwin gets "CYGWIN_NT-6.1-WOW"
instead of "Cygwin". Fix the $UNAME.
Change-Id: Ic53d75defebbe902325eb07f3d8631b2a53245ef
Signed-off-by: Zheng Bao <zheng.bao(a)amd.com>
Signed-off-by: Zheng Bao <fishbaozi(a)gmail.com>
---
util/crossgcc/buildgcc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/util/crossgcc/buildgcc b/util/crossgcc/buildgcc
index 590e1f8..b4eb69e 100755
--- a/util/crossgcc/buildgcc
+++ b/util/crossgcc/buildgcc
@@ -94,7 +94,7 @@ cyan='\033[0;36m'
CYAN='\033[1;36m'
NC='\033[0m' # No Color
-UNAME=$(uname)
+UNAME=$(uname | grep -iq cygwin && echo Cygwin || uname);
normalize_dirs()
{
@@ -622,7 +622,7 @@ if [ $UNAME = "Darwin" ]; then
if $CC -v 2>&1 | grep -q LLVM; then
CC=llvm-gcc
fi
-elif [ $UNAME = "Linux" ]; then
+elif [ $UNAME = "Linux" -o $UNAME = "Cygwin" ]; then
# gmp is overeager with detecting 64bit CPUs even if they run
# a 32bit kernel and userland.
if [ "$(uname -m 2>/dev/null)" = "i686" ]; then
Francis Rowe (info(a)gluglug.org.uk) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11122
-gerrit
commit 1e2112041908366ef500b6b4df28ae147a9aeb11
Author: Francis Rowe <info(a)gluglug.org.uk>
Date: Tue Aug 4 22:48:24 2015 +0100
northbridge/gm45/raminit.c: enable GS45 high-performance mode
The datasheets for GS45 describe a high- and low-performance mode
for different CPUs. Coreboot currently disables GS45 altogether,
but forcing coreboot to treat high-performance GS45 as GM45 makes
the X200S and X200 Tablet boot if it has the right CPU type.
Hardcode-enable GS45 high-performance mode in coreboot, passing it
off as GM45. This is known to work with all CPUs except the SU
(low performance) models.
Change-Id: I6c5ab4d352c049ed907c7b727e9310f290fd3aa8
Signed-off-by: Francis Rowe <info(a)gluglug.org.uk>
---
3rdparty/blobs | 2 +-
src/northbridge/intel/gm45/raminit.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/3rdparty/blobs b/3rdparty/blobs
index 61d663e..34b0926 160000
--- a/3rdparty/blobs
+++ b/3rdparty/blobs
@@ -1 +1 @@
-Subproject commit 61d663e39bc96530900c3232ccea7365ab9dad0b
+Subproject commit 34b09265063c19ea5d61bd5a2f057b47b5aa2232
diff --git a/src/northbridge/intel/gm45/raminit.c b/src/northbridge/intel/gm45/raminit.c
index 9c4fecd..9f5aa06 100644
--- a/src/northbridge/intel/gm45/raminit.c
+++ b/src/northbridge/intel/gm45/raminit.c
@@ -108,8 +108,8 @@ void get_gmch_info(sysinfo_t *sysinfo)
printk(BIOS_SPEW, "GMCH: GS40\n");
break;
case GMCH_GS45:
- printk(BIOS_SPEW, "GMCH: GS45, using low power mode by default\n");
- sysinfo->gs45_low_power_mode = 1;
+ printk(BIOS_SPEW, "GMCH: GS45, using high performance mode by default\n");
+ sysinfo->gs45_low_power_mode = 0;
break;
case GMCH_PM45:
printk(BIOS_SPEW, "GMCH: PM45\n");
@@ -1692,7 +1692,7 @@ void raminit(sysinfo_t *const sysinfo, const int s3resume)
{
const dimminfo_t *const dimms = sysinfo->dimms;
const timings_t *const timings = &sysinfo->selected_timings;
- const int sff = sysinfo->gfx_type == GMCH_GS45;
+ const int sff = (sysinfo->gfx_type == GMCH_GS45) && (sysinfo->gs45_low_power_mode == 1);
int ch;
u8 reg8;
the following patch was just integrated into master:
commit fb82ebe9065e2160e662aee490d749ac31388fa6
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Tue Aug 4 11:14:17 2015 -0700
x86: Make sure boot device is mapped below 4G
On x86-64 the current way of calculating the base address
of the boot device (SPI flash) gets an unwanted sign extension,
making it live somewhere at the end of 64bit address space.
Enforce rom_base to be at the upper end of the 4G address space.
Change-Id: Ia81e82094d3c51f6c10e02b4b0df2f3e1519d39e
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Reviewed-on: http://review.coreboot.org/11121
Reviewed-by: Aaron Durbin <adurbin(a)chromium.org>
Tested-by: build bot (Jenkins)
See http://review.coreboot.org/11121 for details.
-gerrit