This is already the case on x86 but not on the ARM platforms, and
{read,write}[bwl] are using volatile pointers, too, so follow suit.
Change-Id: I6819df62016990e12410eaa9c3c97b8b90944b51
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The new `Makefile.payload` can be included by the Makefiles of pay-
loads for in-tree builds. The basic idea is to use libpayload's
build results without the `make install` step, and to ensure that
incremental builds work. For instance, if libpayload's code changes,
a `make` for the payload would automatically update the libpayload
build and rebuild the payload. But if there are no code changes in
libpayload, only updated files of the payload will be re-built.
The configuration of libpayload is supposed to be automatically
generated from a `defconfig` file. If this `defconfig` changes,
libpayload and the payload will be re-built.
Change-Id: If5319f1bf0bcd09964416237c5cf7f8e59f487a2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47633
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add read64 and write64 for consistency with x86.
BUG=b:178785769
Change-Id: I342e3a23201d0b804ea5ecfe47ee3e4bb516de4c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
It either doesn't exist (in-tree builds) or is the same as $_LIBDIR.
Change-Id: I9551cbfc3295d86c22a3785be7cdc0f65eeb08c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47632
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We only need `$_OBJ` in the include path for in-tree builds. Also,
curses only need special handling for those and PDCurses turned out
to need many more include paths.
Change-Id: Idd29ef33065033e26ba61b09d412d8ca3566d643
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of checking for an already fully build `libpayload.a`, we check
for the `libpayload.config` which is the actual prerequisite to start
using `lpgcc`. This will allow compilation of payload sources before or
in parallel with the build of `libpayload.a`.
Change-Id: Ic0143fefe33560af8b013ae48bbbe231b3ad46f3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Introduce a `$_OBJ` variable, that points to the build directory for
in-tree usage of `lpgcc`. If unset, the default `../build` relative
to the location of `lpgcc` is used.
Change-Id: I35112d7533d69aa51252dd2bceec010a62522403
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47629
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This should make it easier to find the correct config for in-tree
builds.
Change-Id: I08d396ae3cedc65f63c4b8865701ea123c7d56cb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47628
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Keep libpayload's xcompile in its build dir. While we are at it,
align things with the top-level version.
Having `.xcompile` in a central place led to race conditions when
multiple payloads try to build their own libpayloads in parallel.
Change-Id: I504e1862db79b368289867f7568c9169f27a1549
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The keyboard self-test is required for some devices. At least one
device (integrated keyboard in a ThinkPad X201) actually starts the
test automatically leading to spurious output and no response for
the first seconds.
We wait up to 5s for the self-test result. On failure or timeout,
the command will be repeated until the 30s init timer runs out. This
happens all in the background of the UI polling loop.
To not unnecessarily delay the boot process, we first try an oppor-
tunistic initialization which skips the self-test.
Change-Id: Ie07b31e74d06e116ac81e76309621eed39a19b49
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Will be used to time out in states that don't always advance.
Change-Id: I28235e7638d8157cedf81fd915a41d28a1fc070b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47087
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We'll process the init sequence as part of the polling loop. This
should have several advantages:
* It eases error handling, i.e. we can return to an earlier state.
* We don't have to stall initialization when a keyboard takes a
little longer.
* Generally, these keyboards can be hot-plugged (albeit not by
design).
Change-Id: I9cf5cf31eb420b3994bec20e56a72d37f3d2996e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Draining the keyboard's buffer is only possible when the keyboard
port is enabled. We should also disable input scanning before, as
the buffer could be filled again with new keystrokes otherwise.
Change-Id: Ibac9c0d04880ff4a3efda5ac53da2f9731f6602c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move the input-buffer draining into a function. It uses the low-level
i8042 API directly to avoid conflicts with changes in the high-level
keyboard API.
Change-Id: I9427c5b8be4d59c2ee3da12d6168d34590043682
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47084
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even if we are careful, it's still possible that we read spurious
data from the keyboard, e.g. keystrokes. Namely, when we send the
reset/disable command, there is a race before the command is pro-
cessed.
So we should always process data from the keyboard in a loop. We
break it, when an ACK (0xfa) or a NAK (0xfe) is received, and warn
on unexpected data unless it might be due to the mentioned race.
This also gives us the opportunity to use command-specific timeouts
which we take from Linux: 1s for the keyboard self-test (as there
are keyboards that perform the test before acking the command) and
200ms for all other commands.
Change-Id: I60a2643a8ff4b9231c63bf970c8749c97c7d8926
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some background first: The original XT keyboards used what we call
scancode set #1 today. The PC/AT keyboards introduced scancode set #2,
but for compatibility, its controller translated scancodes back to
set #1 by default. Newer keyboards (maybe all we have to deal with)
also support switching the scancode set.
This means the translation option in the controller and the scancode
set selection in the keyboard have to match. In libpayload, we only
support set #1 scancodes. So we either need the controller's trans-
lation on and set #2 selected in the keyboard, or the controller's
translation off and set #1 selected in the keyboard.
Valid configurations:
* SET #1 + XLATE off
* SET #2 + XLATE on
Both with and without the PC_KEYBOARD_AT_TRANSLATED option, we were
only configuring one of the two settings, leaving room for invalid
configurations. With this change, we try to select scancode set #2
first, which seems to be the most supported one, and configure the
controller's translation accordingly. We try to fall back to set #1
on failure.
We also keep translation disabled during configuration steps to
ensure that the controller doesn't accidentally translate confi-
guration data.
On the coreboot side, we leave the controller's translation at its
default setting, unless DRIVERS_PS2_KEYBOARD is enabled. The latter
enables the translation unconditionally. For QEMU this means that
the option effectively toggles the translation, as QEMU's controller
has it disabled by default. This probably made a lot of earlier
testing inconsistent.
Fixes: commit a95a6bf646 (libpayload/drivers/i8402/kbd: Fix qemu)
The reset introduced there effectively reverted the scancode
selection made before (because 2 is the default). It's unclear
if later changes to the code were only necessary to work
around it.
Change-Id: Iad85af516a7b9f9c0269ff9652ed15ee81700057
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change adds details about the memory map windows to translate
addresses between SPI flash space and host address space to coreboot
tables. This is useful for payloads to setup the translation using the
decode windows already known to coreboot. Until now, there was a
single decode window at the top of 4G used by all x86
platforms. However, going forward, platforms might support more decode
windows and hence in order to avoid duplication in payloads this
information is filled in coreboot tables.
`lb_spi_flash()` is updated to fill in the details about these windows
by making a call to `spi_flash_get_mmap_windows()` which is
implemented by the driver providing the boot media mapping device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I00ae33d9b53fecd0a8eadd22531fdff8bde9ee94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48185
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Provide get_mmu_ranges() for ARM64 to let payloads could get
MMU ranges for all used memory regions.
BUG=b:171858277
TEST=Build in x86, arm, arm64.
emerge-zork libpayload depthcharge
emerge-nyan libpayload depthcharge
emerge-asurada libpayload depthcharge
Signed-off-by: Meng-Huan Yu <menghuan@google.com>
Change-Id: I39b24aefc9dbe530169b272e839d0e1e7c697742
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This turns on the compiler's printf style format string checker.
BUG=b:167517417
TEST=enabled all USB controllers on volteer and fixed resulting
compiler errors when USB_DEBUG is enabled.
Change-Id: Ic94ebcbafdde8a5f79278b5635111b99af40f892
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45025
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes format string mismatch errors in the USB subsystem found by
the compiler's format string checker.
BUG=b:167517417
TEST=enabled all USB controllers on volteer and fixed resulting
compiler errors when USB_DEBUG is enabled.
Change-Id: I4dc70baefb3cd82fcc915cc2e7f68719cf6870cc
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The current timeout of 500ms is too low. For instance self-test
of the KBC integrated into IT8516E took almost 1s in tests. We
already check for presence of the KBC before the self-test. So
the timeout should only trigger on a hardware defect and we can
leave some margin.
Change-Id: I95f01a4e605a9c7deb894a71e102c3a881759bb1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47588
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Work on this mainboard was abandoned and never finished. It's not really
usable in its current state, so let's get rid of it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4cd2e2cd0ee69d9846472653a942fa074e2b924d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The OHCI header file declares various enums as follows:
enum { ... } enum_name;
Since the name is at the end, this is actually declaring a variable
called enum_name and *not* a type, which is causing a multiple
definition error in GCC 10. Move the enum_name before the opening brace
to prevent this.
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I452c0a1b118990942aa53f1e7e77f5e8378e8975
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Headers in libpayload define various structs like so:
struct struct_name { ... } __packed;
However, these header files do not include the compiler.h macro that
defines what __packed is, so they are actually defining a variable named
__packed and *not* declaring a packed struct. This leads to defining the
same variable multiple times, which was caught by GCC 10. Add compiler.h
to the compiler parameters so it is included in all files automatically.
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: Ia67182520dc94149e06fe9e03a14b3fc2ee29973
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47153
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Link time optimization is a technique for whole-program optimization.
Instead of doing code generation during compilation, the compiler saves
its intermediate representation to the object files. During the final
linking step, it will then merge all the object files together and
perform optimizations on the entire program. This can often reduce the
final binary size, but also may increase the total compilation time.
This patch introduces a Kconfig option for enabling link time
optimization in libpayload. Since libpayload does no linking of its own,
its LTO archive files will contain only IR and no generated code.
Downstream projects will need to use LTO-aware tools when manipulating
the archives (eg. gcc-ar and gcc-nm), but otherwise do not need to use
LTO themselves -- the compiler will recognize which files are LTO and
which are not, so enabling this option should mostly be "drop in".
For example, when building coreinfo.elf using tinycurses libpayload:
binary size compilation time
default 114 KiB 11.49s
LTO 95 KiB 10.36s
In this case the total compilation time was actually shorter -- despite
the final linking step taking longer, this was offset by the shorter
compilation times for each individual file (since there is no code gen
until the very end).
Change-Id: I048f2ff6298ed0d891098942e1e8b29d35487b91
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38291
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We can skip the PIT-based TSC calibration if we can derive the invariant
TSC rate from CPUID/MSR data. This is necessary if the PIT is disabled,
which is the default, for instance, on Coffee Lake CPUs.
This implementation should cover all Intel Core i processors at least.
For older processors, we fall back to the PIT calibration.
Change-Id: Ic6607ee2a8b41c2be9dc1bb4f1e23e652bb33889
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The list is incomplete and only contains what we need in the follow-up
commit. It can be extended at will.
Change-Id: Ibf8ddaf510eb513ee74af3e78da46b04802a91b9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are currently 3 different strapping ID entries in the coreboot
table, which adds overhead. The new fw_config field is also desired in
the coreboot table, which is another kind of strapping id. Therefore,
this patch deprecates the 3 current strapping ID entries (board ID, RAM
code, and SKU ID), and adds a new entry ("board_config") which provides
board ID, RAM code, SKU ID, as well as FW_CONFIG together.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I1ecec847ee77b72233587c1ad7f124e2027470bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There's no need for the global list of files to ignore, so use git's
ability to work with more local configuration.
Change-Id: I50882e6756cbc0fdfd899353cc23962544690fb3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46879
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use `bool` whenever `0` was used to indicate an error. The mixing of
different types for return values was mildly confusing and potentially
dangerous with the i8042 API close by that uses `0` for success.
Change-Id: I876bb5076c4921f36e3438f359be8ac4c09248cc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46723
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
SMMSTORE version 2 is a complete redesign of the current driver. It is
not backwards-compatible with version 1, and only one version can be
used at a time.
Key features:
* Uses a fixed communication buffer instead of writing to arbitrary
memory addresses provided by untrusted ring0 code.
* Gives the caller full control over the used data format.
* Splits the store into smaller chunks to allow fault tolerant updates.
* Doesn't provide feedback about the actual read/written bytes, just
returns error or success in registers.
* Returns an error if the requested operation would overflow the
communication buffer.
Separate the SMMSTORE into 64 KiB blocks that can individually be
read/written/erased. To be used by payloads that implement a
FaultTolerant Variable store like TianoCore.
The implementation has been tested against EDK2 master.
An example EDK2 implementation can be found here:
eb1127744a
Change-Id: I25e49d184135710f3e6dd1ad3bed95de950fe057
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The PCI bus gets already scanned while gathering system information.
Therefore, use the pacc pointer from sysinfo_t to read the device class
of PCI devices instead of rescanning the bus.
Change-Id: I4c79e71777e718f5065107ebf780ca9fdb4f1b0c
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Currently, the PCI bus gets scanned multiple times for various reasons
(e.g. to read the device class). Therefore, and in preparation to
CB:46416, introduce the pacc pointer in the sysinfo_t struct and scan
the PCI bus while gathering system information.
Change-Id: I496c5a3d78c7fb5d7c9f119a0c9a0314d54e729f
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
32-bit LBA limits drives, that have or emulate 512B sectors, to 2TiB
capacity. Therefore, enable the 64-bit support.
Change-Id: I663029a2137c5af3c77d576fe27db0b8fa7488a9
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Since the list of tested controllers is not actively maintained, enable
all AHCI controllers by default. Also, improve the readability of its
help text by adding a comma to it.
Change-Id: If30f58f8380ab599f8985e85c64510dc88e96268
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The device class is read at different places and it is read from the
hardware directly. Therefore, and in preparation to CB:46416, introduce
the device class attribute in the pci_dev struct. With this, there is
only one interaction with the hardware and it's also more user friendly.
Change-Id: I5d56be96f3f0da471246f031ea619e3df8e54cfb
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46347
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Thomas Heijligen