The work may be incomplete, we only have an emulation
power8 at the moment in the tree.
Change-Id: Icdaa0995c8610dcc636923cc79b8455dfaeaa057
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
Drop 'include <string.h>' when it is not used and
add it when it is missing.
Also extra lines removed, or added just before local includes.
Change-Id: Iccac4dbaa2dd4144fc347af36ecfc9747da3de20
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
We were used to set the same values in the system and board tables.
We'll keep the mainboard values as defaults for the system tables,
so nothing changes unless somebody overrides the system table hooks.
Change-Id: I3c9c95a1307529c3137647a161a698a4c3daa0ae
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
In the current state of the tree we do not utilise the
mechanism of having per-device overrides for PCI bus
ops.
This change effectively inlines all PCI config accessors
for ramstage as well.
Change-Id: I11c37cadfcbef8fb5657dec6d620e6bccab311a4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
By changing the signatures we do not need to define
PCI config accessors separately for ramstage.
Change-Id: I9364cb34fe8127972c772516a0a0b1d281c5ed00
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
In case PCI_IO_CFG_EXT=n parameter 'reg' was not
properly truncated to 8 bits and it would overflow
to dev.fn part of the register.
A similar thing could happen with 'dev' but that
value originates from PCI_DEV() macro unlike 'reg'.
Change-Id: Id2888e07fc0f2b182b4633a747c1786e5c560678
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31847
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By design only 'reg' parameter can have the two least-
significant bits set. As 'reg' is often a constant,
'0xCFC + (reg & 3)' resolves to an immediate value
already at buildtime, unlike (addr & 3) which depends
of a constant (but non-immediate) value of 'dev' in
ramstage.
Change-Id: I6e729fe800c92b1ce4994ad2b4203072fa75a958
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31754
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sorting makes only sense if there are at least two entries available.
Change-Id: If40638bf1fe24dcff4b7839967445fb4218184f8
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
One could understand 'where' as bus, device, function
or register. Make it clear it is register.
Change-Id: I95d0330ba40510e48be70ca1d8f58aca66c8f695
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch is a raw application of
find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g'
Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Create the way of adding the discrete VGA OpROM at config UI (alternative to
./cbfstool ./cb.rom add -f vgabios_dgpu.bin -n pci1002,6663.rom -t optionrom )
DGPU options are accessible only if CONFIG_VGA_BIOS is enabled.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I0a7bf0fe95c833cf3df0c7cb20fc27b6ab218c5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch adds timestamp for "end of romstage" with postcar if platform
has selected postcar as dedicated stage.
If postcar stage doesn't exist then "end of romstage" timestamp will get
call while starting of ramstage as exist today.
TEST=It's been observed that "end of romstage" timestamp doesn't appear
in "cbmem -t" log when ramstage is not getting executed. As part of this fix
"end of romstage" timestamp is showing in "cbmem -t" log on Intel platform
where POSTCAR is a dedicated stage.
Change-Id: I17fd89296354b66a5538f85737c79145232593d3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds dedicated timestamp value for postcar stage.
TEST=Able to see "start of postcar" and "end of postcar" timestamp
while executing cbmem -t after booting to chrome console.
> cbmem -t
951:returning from FspMemoryInit 20,485,324 (20,103,067)
4:end of romstage 20,559,235 (73,910)
100:start of postcar 20,560,266 (1,031)
101:end of postcar 20,570,038 (9,772)
Change-Id: I084f66949667ad598f811d4233b4e639bc4c113e
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Until now the TCPA log wasn't working correctly.
* Refactor TCPA log code.
* Add TCPA log dump fucntion.
* Make TCPA log available in bootblock.
* Fix TCPA log formatting.
* Add x86 and Cavium memory for early log.
Change-Id: Ic93133531b84318f48940d34bded48cbae739c44
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29563
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Make GDT a separate table and don't reuse GDT descriptor as unused
first field of GDT.
Required for separate x86_64 GDT descriptor, pointing to the same
GDT.
Tested on qemu.
Change-Id: I513329b67d49ade1055bc07cf7b93ff2e0131e0b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31769
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fail builds if MRC blobs pool heap would get corrupted
by CAR relocatable data from coreboot proper.
Add runtime logging how much pool was required.
Change-Id: Ibc771b592b35d77be81fce87769314fe6bb84c87
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31150
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MMIO operations are arch-agnostic so the include
path should not be arch/.
Change-Id: I0fd70f5aeca02e98e96b980c3aca0819f5c44b98
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31691
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Provide clean separation for PCI and PNP headers,
followup will also move PNP outside <arch/io.h>.
Change-Id: I85db254d50f18ea34a5e95bc517eac4085a5fafa
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31690
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Since ACPI v2.c, this field is access_size.
Currently, coreboot is using ACPI v3,so we can drop '.resv' field.
Change-Id: I7b3b930861669bb05cdc8e81f6502476a0568fe0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/31701
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
A default is a build-time static value, fallback. Return
value does not depend of input parameter.
Change-Id: I43ae28f465fb46391519ec97a2a50891d458c46d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31679
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the bus parameter, we do not use it.
It would still be possible to do per-bus selection
by evaluating the bus number, but currently we do
not have need for that either.
Change-Id: I09e928b4677d9db2eee12730ba7b3fdd8837805c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Having different signatures for the PCI config accessors
prevents them from having the same name in different
stages.
For now, work around this using __SIMPLE_DEVICE__.
Change-Id: I20f56cfe3ac7dc4421e62a99ca91f39a857c0ccf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
As we are running ACPI v3.0, references to older
than v3.0 are removed.
Change-Id: I0cce0035ed2b952d59cc1a4a9e6017dae67ef6db
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/31689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
INT_MODEL defined in ACPI 1.0 and renamed to reserved since V 2.0.
The value for this field is zero but 1 is allowed to maintain
compatibility with ACPI 1.0.
So set this value to zero as we are using greater version than ACPI 1.0.
Change-Id: I910ead4e5618c958a7989f4c309a3a4bb938e31a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/29986
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: David Guckian
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot performs MP-Init in a parallel way. That leads to the fact
that the order, in which the CPUs are woken up, can vary from boot to
boot. The creation of the MADT table just parses the devicetree and
takes the CPUs reported there as it is for creating the single local
APIC entries. Therefore, the OS will see different order of CPUs.
There are CPUs out there (like Apollo Lake for example) which have
shared caches on core-level and if the order is random this can end up
in assigning cores to different tasks or even OSes (in a virtual
environment) which uses the same cache. This in turn will produce
performance penalties across these distributed tasks/OSes.
Though there is a way to discover the core- and cache-topology it will
in the end be necessary to take the APIC-ID into account. To simplify
it, one can achieve the same output by sorting the APIC-IDs in an
ascending order. This will lead to the fact that CPUs that share a given
cache will be reported right next to each other in the MADT.
Change-Id: Ida74f9f00a4e2a03107a2124014403de60462735
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/31545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Fix up the logic of when to include VBOOT2_WORK symbols on x86,
which are only needed when VBOOT_STARTS_IN_BOOTBLOCK is enabled.
Also correct the value of the __PRE_RAM__ macro in the case that
VBOOT_STARTS_IN_ROMSTAGE is selected. In this case, DRAM is
already up and verstage should not be considered pre-ram.
BUG=b:124141368, b:124192753
TEST=Build locally for eve
TEST=util/lint/checkpatch.pl -g origin/master..HEAD
TEST=util/abuild/abuild -B -e -y -c 50 -p none -x
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ie51e8f93b99ab230f3caeede2a33ec8b443e3d7a
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/31541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
When <symbols.h> was first introduced, it only declared a handful of
regions and we didn't expect that too many architectures and platforms
would need to add their own later. However, our amount of platforms has
greatly expanded since, and with them the need for more special memory
regions. The amount of code duplication is starting to get unsightly,
and platforms keep defining their own <soc/symbols.h> files that need
this as well.
This patch adds another macro to cut down the definition boilerplate.
Unfortunately, macros cannot define other macros when they're called, so
referring to region sizes as _name_size doesn't work anymore. This patch
replaces the scheme with REGION_SIZE(name).
Not touching the regions in the x86-specific <arch/symbols.h> yet since
they don't follow the standard _region/_eregion naming scheme. They can
be converted later if desired.
Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current implementation was designed for x86_32, so don't
attempt to compile it on x86_64 until it is fixed.
Fixes compilation error on x86_64.
Change-Id: Ibd87dc2979f6d45a988119c06c5f9e61b3e86171
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/31467
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* Adding separate targets for 32bit and 64bit qemu
* Using the riscv64 toolchain for 32bit builds requires setting -m elf32lriscv
* rv32/rv64 is currently configured with ARCH_RISCV_RV32/RV64 and not per stage.
This should probably be changed later.
TEST=Boots to "Payload not loaded." on 32bit qemu using the following commands:
util/riscv/make-spike-elf.sh build/coreboot.rom build/coreboot.elf
qemu-system-riscv32 -M virt -m 1024M -nographic -kernel build/coreboot.elf
Change-Id: I35e59b459d1770df10b51fe9e77dcc474d7c75a0
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/c/31253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
To make PCI driver side arch-agnostic, function
declarations have to be in symmetrical header
file locations.
From the driver side, the correct file to include
is now <device/pci_ops.h>
Change-Id: I8076a4867fd7472beaae0a021dcf0d9c7c905871
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It is expected that method of accessing PCI configuration
register space via memory-mapped region is arch-agnostic.
Change-Id: Ide6baa00d611953aeb324be0d3561f464395c5eb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are defined for __SIMPLE_DEVICE__ when PCI
enumeration has not happened yet. These should not
really try to probe devices other than those on bus 0.
It's hard to track but there maybe cases of southbridge
being located on bus 2 and available for configuration, so
I rather leave the code unchanged. Just move these out of
arch/io.h because they cause build failures if one attempts
to include <arch/pci_ops.h> before <arch/io.h>.
There are two direct copies for ROMCC bootblocks to
avoid inlining them elsewhere.
Change-Id: Ida2919a5d83fe5ea89284ffbd8ead382e4312524
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having SYSTEM_TYPE_DETACHABLE and SYSTEM_TYPE_TABLET use
PM_MOBILE have them use PM_TABLET instead.
Change-Id: If0ce51e522d36420ecd5b51bdfec6cca11c00333
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/31277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These are more common system types and in some cases it is important
to know when a device is a convertible or a tablet or detachable
instead of just a laptop.
This change will select the appropriate SMBIOS enclosure type based
on the selected system type.
This is important for the Intel Virtual Button driver as it does a
check on the SMBIOS enclosure type and only enables the tablet mode
events if it is set to convertible:
https://patchwork.kernel.org/patch/10236253/
Change-Id: I148ec2329a1dd38ad55c60ba277a514c66376fcc
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/31206
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
After CL:31122, we can finally define a memory type specific for BL31,
to make sure BL31 is not loaded on other reserved area.
Change-Id: Idbd9a7fe4b12af23de1519892936d8d88a000e2c
Signed-off-by: Ting Shen <phoenixshen@google.com>
Reviewed-on: https://review.coreboot.org/c/31123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The ACPI spec has an asl example for _PLD in the form:
Name (_PLD, Package (0x01) { ToPLD (PLD_Revision = 0x2) })
When I ported this to acpigen and diffed the results I noticed that
the binary blob was no longer provided within a package. The ACPI
spec (section 6.1.8 in version 6.2) defines _PLD as "a variable-length
Package containing a list of Buffers". This commit changes
acpigen_write_pld to use a package (the one existing caller I found
isn't wrapping the result in a package so it doesn't look like
it was intended for the callers of acpigen_write_pld to be responsible
for using a package.
BUG=none
BRANCH=none
TEST=Verified that after this change a package is use and the result
of acpigen matches what was used in the original asl.
Change-Id: Ie2db63c976100109bfe976553e52565fb2d2d9df
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31162
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
If an acpi_dp table has children but no properties then acpi_dp_write()
will write out a properties UUID and package that contains no properties.
The existing function will avoid writing out a UUID and empty package
when no children exist, but it seems to assume that properties will
always be used. With this change properties are handled in a manner
akin to children so that a UUID and package are only written if
properties exist.
BUG=none
BRANCH=none
TEST=Confirmed that prior to this change a UUID and empty package was
present for a device that had children but no properties. Verified that
after this change the UUID and empty package are no longer present but
the child UUID and package are still present.
Change-Id: I6f5597713a1e91ca26b409f36b3ff9eb90a010af
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The allocation is not required before romstage,
so it can be just another CAR_GLOBAL instead of
polluting the linker script.
Change-Id: I0738a655f6cc924fbed92ea630f85406e3f58c0b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31191
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The structure is placed inside CBMEM, one should
use types with fixed size. Seems we prefer to
prepare for 64-bit builds even for MMIO pointers.
Change-Id: I60382664a53650b225abc1f77c87ed4e121d429e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We need sizeof(struct ehci_dbg_info) of 88 but only
reserved 64 bytes. If usbdebug_hw_init() was called
late in romstage, for some builds it would corrupt
CAR_GLOBALs like console_inited variable and stop
logging anything.
Also change pointer initialisation such that
glob_dbg_info will hit garbage collection for
PRE_RAM stages.
Change-Id: Ib49fca781e55619179aa8888e2d859560e050876
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Also show hart id in trap information for easier debugging.
Change-Id: I20acf86e1af111600c158295ae03b2167838d127
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/c/31201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
1. Simplify payload code and convert it to C
2. Save the FDT pointer to HLS (hart-local storage).
3. Don't use mscratch to pass FDT pointer as it is used for exception handling.
Change-Id: I32bf2a99e07a65358a7f19b899259f0816eb45e8
Signed-off-by: Xiang Wang <wxjstz@126.com>
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/c/31179
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, selflock_check() verifies that the binary is loaded in an
usable RAM area.
Extend its functionality so we can also check that BL31 is loaded in
a manually reserved area, and fail early if the range is not protected.
Change-Id: Iecdeedd9e8da67f73ac47d2a82e85b306469a626
Signed-off-by: Ting Shen <phoenixshen@google.com>
Reviewed-on: https://review.coreboot.org/c/31122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is spotted using ./util/lint/kconfig_lint
To work around the issue, rename the prefix from `CONFIG_` to `CONF_`.
Change-Id: Ia31aed366bf768ab167ed5f8595bee8234aac46b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/31049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This is spotted using "./util/lint/kconfig_lint"
While at it, do the check in C and not the preprocessor.
Change-Id: Icfda267936a23d9d14832116d67571f42f685906
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/31050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
ARCH_RISCV_RV{32,64} will now select ARCH_RISCV.
Change-Id: Ia7a1a8f0bfab20e91b8429dd6dd3e9a4180a0a5b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Hug <philipp@hug.cx>
RISCV parts can be created with any one of four CPU modes enabled,
with or without PMP, and with either 32 or 64 bit XLEN.
In anticipation of parts to come, create the Kconfig variables for these
architecture attributes.
Change-Id: I32ee51b2a469c7684a2f1b477bdac040e972e253
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30348
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When rmodule is loaded CPU stack alignment is only guaranteed
to 4kiB. Implementation of cpu_info() requires that each
CPU sees its stack aligned to CONFIG_STACK_SIZE.
Add one spare CPU for the stack reserve, such that alignment can
be enforced runtime.
Change-Id: Ie04956c64df0dc7bb156002d3d4f2629f92b340e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/26302
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This was used to check romcc-built bootblock and romstage
agree about the location of 16-bit entrypoint. There was
no need to customize it as bootblock size requirement did
not grow. Just check for a fixed location at 4 GiB - 4 KiB.
With C_ENVIRONMENT_BOOTBLOCK we can have a proper symbol
for the purpose, since it appears in the same compilation
unit. It will adjust if C_ENV_BOOTBLOCK_SIZE changes.
Change-Id: I93f3c37e78ba587455c804de8c57e7e06832a81f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Clearing the EBDA was introduced with b4aaaa "Prepare the BIOS data
areas before device init." which states that the purpose of setting up
these area's is just to make sure they are sane. On the S3 path doing
this is not needed and can even thrash data set up by payloads (mostly
SeaBIOS) that used that memory.
Change-Id: I9c54156bd8247e8a34dec6edc27cfc2d33cde595
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/30789
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
PCI_ADDR() is tightly coupled with different setup_resource_map()
variants so move the declaration away from global namespace.
In the implementation of setup_resource_map() use the bottom
12 bits as the register mask like the other variants do already.
Change-Id: Iadedfe993621a4458ce8f12c5e98c8cee537d2db
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30784
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Build with TSC_CONSTANT_RATE must fail when this function
is not implemented for the platform. Weak implementation
causes division by zero in timer_monotonic_get() and
turns udelay() into no delay.
Change-Id: Id3b105ea3aac37cd0cba18ce2fb06d87a055486f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Link walkfcbfs.S in the C_ENVIRONMENT_BOOTBLOCK case and also in the
romstage.
This is useful for cbfs access in pre-CAR environments.
Change-Id: I9a17cdf01c7cbc3c9ac45ed1f075731f3e32f64b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/30681
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Have same usage of registers with romcc bootblock
and C_ENVIRONMENT_BOOTBLOCK.
Change-Id: Ibfa80e40f0b736a904abf4245fc23efc0cdc458d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The EHCI hardware needs to be initialized only once during CAR stages.
Some exception need to be made when a blob messes with the EHCI
hardware. To achieve this add a fixed location in the car.ld linker
script such that the ehci debug information can be shared across CAR
stages.
Currently this means only romstage and bootblock, but verstage can
also be hooked up later on.
Tested on google/peppy: Both the bootblock and the romstage properly
output console.
Change-Id: I78e20a172fd5cc81f366d580f3cce57b9545d7a2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Also remove global ramstage-y += get_bus_conf.c, this is
specific to amdfam10.
Change-Id: I49b604ebff6bcfe85518b2c3896ab798c3c7878d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Definitions of these types are arch-agnostic. Shared device
subsystem files cannot include arch/pci_ops.h for ARM
and arch/io.h for x86.
Change-Id: I6a3deea676308e2dc703b5e06558b05235191044
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/29947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Use of device_t is deprecated.
Change-Id: Ie05869901ac33d7089e21110f46c1241f7ee731f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/30047
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add symbols for the non C_ENVIRONMENT_BOOTBLOCK builds
and use them for stack guards.
Change-Id: Ib622eacb161d9a110d35a7d6979d1b601503b6f4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The same file was replicated three times for certain
soc/intel bootblocks, yet there are no indications or need to do
chipset-specific initialisation.
There is no harm in storing the TSC values in MMX registers
even when they would not be used.
Change-Id: Iec6fa0889f5887effca1d99ef830d383fb733648
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Platforms with SSE=y or SSE2=y will invoke romcc with -mcpu=k7.
This implicitly enabled romcc to consume MMX registers, if XMM
set was consumed first.
Explicitly tell romcc not to clobber MMX set.
Change-Id: I37f1d6ea01873036712dfbb32bb1dcd5d769e85d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Remove all cases in code where we tested for
EARLY_CBMEM_INIT or LATE_CBMEM_INIT being set.
This also removes all references to LATE_CBMEM_INIT
in comments.
Change-Id: I4e47fb5c8a947d268f4840cfb9c0d3596fb9ab39
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/26827
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Quoting from the RISC-V Privileged Architecture manual version 1.10,
chapter 3.1.11:
The FS and XS fields use the same status encoding as shown in Table
3.3, with the four possible status values being Off, Initial, Clean,
and Dirty.
Status FS Meaning XS Meaning
0 Off All off
1 Initial None dirty of clean, some on
2 Clean None dirty, some clean
3 Dirty Some dirty
Change-Id: If0225044ed52215ce64ea979d120014e02d4ce37
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/c/28987
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
They are hopefully stable enough by now.
TEST=Building with for emulation/spike-riscv with BUILD_TIMELESS,
with and without this patch, results in the same coreboot.rom.
Change-Id: Ie6747c7eeea6cd8fd2138c5ba535a08c5add9038
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/c/30164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Philipp Hug <philipp@hug.cx>
This patch introduces 3 helper function for cpuid(1) :
1. cpu_get_cpuid() -> to get processor id (from cpuid.eax)
2. cpu_get_feature_flags_ecx -> to get processor feature flag (from cpuid.ecx)
3. cpu_get_feature_flags_edx -> to get processor feature flag (from cpuid.edx)
Above 3 helper functions are targeted to replace majority of cpuid(1)
references.
Change-Id: Ib96a7c79dadb1feff0b8d58aa408b355fbb3bc50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/30123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Use CONFIG_CPU_MAX which defaults to 1 instead of CONFIG_RISCV_HART_NUM.
The default value of CONFIG_RISCV_HART_NUM was 0 and cause a jump to address 0.
Add a die() call to fail gracefully.
Change-Id: I4e3aa09b787ae0f26a4aae375f4e5fcd745a0a1e
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/c/29993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Xiang Wang <wxjstz@126.com>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
We alwas define uint64_t as unsigned long long, even on x86_64.
Fix PRIu64 to match the definition of the datatype, to prevent
compilation errors when compiling for x86_64.
Change-Id: I7b10a18eab492f02d39fc2074b47f5fdc7209f3d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/30002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Linux kernel can use the ACPI _PLD group information to
determine peer ports. Currently to define the group information
the devicetree must provide a complete _PLD structure. This
change pulls the group information into a separate structure that
can be defined in devicetree. This makes it easier to set for
USB devices in devicetree that do not need a full custom PLD.
This was tested on a sarien board with the USB devices defined
by verifying that the USB 2/3 ports are correctly identified
with their peer in sysfs.
Change-Id: Ifd4cadf0f6c901eb3832ad4e1395904f99c2f5a0
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/29998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
POWER8 is a specific implementation of ppc64, which is by now outdated
(POWER9 has been on the market for a while). Rename arch/power8/ to
potentially cover a wider range of hardware.
TEST=Toolchains built before/after this commit can build coreboot for
emulation/qemu-power8 from before/after this commit.
Change-Id: I2d6f08b12a9ffc8a652ddcd6f24ad85ecb33ca52
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/c/29943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
This removes CEIL_DIV and div_round_up() altogether and
replace it by DIV_ROUND_UP defined in commonlib/helpers.h.
Change-Id: I9aabc3fbe7834834c92d6ba59ff0005986622a34
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/29847
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
CBFS used to have a special region for the x86 bootblock, which also
contained a pointer to a CBFS master header, which describes the
layout of the CBFS.
Since we adopted other architectures, we got rid of the bootblock region
as a separate entity and add the x86 bootblock as a CBFS file now.
The master header still exists for compatibility with old cbfstool
versions, but it's neatly wrapped in either the bootblock file or in a
file carefully crafted at the right location (on all other architectures).
All the layout information we need is now available from FMAP, a core
part of a contemporary coreboot image, even on x86, so we can just use
the generic master header locator in src/lib/cbfs.c and get rid of the
special version.
Among the advantages: the x86 header locator reduced the size of the
CBFS by 64 bytes assuming that there's the bootblock region of at least
that size - this breaks assumptions elsewhere (eg. when walking CBFS in
cbfs_boot_locate() because the last file, the bootblock, will exceed the
CBFS region as seen by coreboot (since it's CBFS - 64bytes).
TEST=emulation/qemu-q35 still boots
Change-Id: I6fa78073ee4015d7769ed588dc67f9b019d42d07
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reported-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/29801
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
According to newest TCG ACPI Specification for Family 1.2 and 2.0
Version 1.2, Revision 8, TPM2 ACPI table has two more fields LAML and LASA.
Update the table structure definition, create the log area for TPM2 in
coreboot tables and fill the missing fields in TPM2 table. TPM2 should be
now probed well in SeaBIOS rel-1.12.0 or master.
Tested on apu2 with Infineon SLB9665 TT2.0.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ie482cba0a3093aae996f7431251251f145fe64f3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/29800
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Field 'OEMID' & "OEM Table ID" are related to DSDT table
not to mainboard.
So use macro to set them respectvely to "COREv4" and
"COREBOOT".
Change-Id: I060e07a730e721df4a86128ee89bfe168c69f31e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/29790
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: David Guckian
Initially, I wanted to move only the Kconfig DISPLAY_MTRRS into the
"Debug" menu. It turned out, though, that the code looks rather generic.
No need to hide it in soc/intel/.
To not bloat src/Kconfig up any further, start a new `Kconfig.debug`
hierarchy just for debug options.
If somebody wants to review the code if it's 100% generic, we could
even get rid of HAVE_DISPLAY_MTRRS.
Change-Id: Ibd0a64121bd6e4ab5d7fd835f3ac25d3f5011f24
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/29684
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Current implementation works by luck as DCACHE area is actually RAM and
stack can grow and use that RAM outside of the area.
* Set DCACHE_BSP_STACK_SIZE to 0x4000.
* Add an assert to make sure it is set to a sane value on all platforms.
Change-Id: I71f9d74d89e4129cdc4a850acc4fc1ac90e5f628
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/29611
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change 76ab2b7 ("arch/x86: allow global .bss objects without
CAR_GLOBAL") allowed use of global .bss objects and hence moved around
the macros resulting in car_active returning 0 even for those boards
where CAR is actually active but do not require global migration. This
resulted in boards getting stuck when doing a reset in verstage because
the code flow incorrectly assumed that there was no CAR active and
hence triggered a cache invalidate.
This change fixes the above issue by returning 1 for car_active if
ENV_CACHE_AS_RAM is set even if global migration is not required.
BUG=b:109717603
TEST=Verified that board reset does not trigger cache invalidate in
verstage and does not result in board hang.
Change-Id: I182f3e4277c57d6c50f7fcac2be72514896b3c61
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/29555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peichao Li <peichao.wang@bitland.corp-partner.google.com>
Reviewed-by: Nick Chen <nickchen@ami.corp-partner.google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Now postcar is a standalone stage give it a
proper type.
Change-Id: Ifa6af9cf20aad27ca87a86817e6ad0a0d1de17c8
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/29545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Fixes building vb2lib for postcar. Since postcar is an x86ism, add the
Kconfig options only for x86.
Change-Id: Ib92436bc7270c24689dcf01a47f0c6fe7661814b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/29395
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since S3 resume sometimes breaks when trying to find the wakeup vector,
it is useful to log whether it errors or not. Since it is an error,
print it as such.
Change-Id: Ib006c4a213c0da180018e5fbf7a47d6af66f8bc4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/29449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Each stage performs some basic initialization (stack, HLS etc) and then
call smp_pause to enter the single-threaded state. The main work of each
stage is executed in a single-threaded state, and the multi-threaded
state is restored by call smp_resume while booting the next stage.
Change-Id: I8d508c3d0f65a022010e74f8edad7ad2cfdc7dee
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/29024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philipp Hug <philipp@hug.cx>
See https://doc.coreboot.org/arch/riscv/ we know that we need to execute
smp_pause at the start of each stage and smp_resume at the end of each
stage.
Change-Id: I6f8159637bfb15f54f0abeb335de2ba6e9cf82fb
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/29023
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Romstage is where DRAM comes online. Therefore, allow
raw CAR_GLOBAL object access in all cache-as-ram stages
that are not romstage. In practice, this should be a nop.
However, the explicit check for romstage is clearer.
Change-Id: I31454c05029140a946ef663b8fa1b2fa6a788154
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/29401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
For platforms utilizing CONFIG_NO_CAR_GLOBAL_MIGRATION there's
no need to automatically migrate globals. Because of this it's
possible to automatically allow for uninitialized global variables
which reside in the .bss section without needing to decorate those
objects with CAR_GLOBAL.
Change-Id: Icae806fecd936ed2ebf0c13d30ffa07c77a95150
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/29359
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Just disable the timer interrupt and notify supervisor.
To receive another timer interrupt just set timecmp and
enable machine mode timer interrupt again.
TEST=Run linux on sifive unleashed
Change-Id: I5d693f872bd492c9d0017b514882a4cebd5ccadd
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/29340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Pointer to opcode increases by unit uint16_t not byte.
Change-Id: I2986ca5402ad86d80e0eb955478bfbdc5d50e1f5
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/29339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
* Distinguish between TPM 1.2 and 2.0
ACPI table support
* Add TPM2 table support for TIS interface only
Change-Id: I030c7ea744bcfe61ebef8d66d1295273b5dccda5
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/29181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The selfboot function was changed at some point to take a parameter
which meant "check the allocated descriptors to see if they target
regions of real memory."
The region check had to be buried deep in the last step of loading since
that is where those descriptors were created and used.
An issue with the use of the parameter was that it was not possible
for compilers to easily divine whether the check code was used,
and it was hence possible for the code, and its dependencies, to be
compiled in even if never used (which caused problems for the
rampayload code).
Now that bounce buffers are gone, we can hoist the check code
to the outermost level. Further, by creating a selfload_check
and selfload function, we can make it easy for compilers
to discard unused code: if selfload_check is never called, all
the code it uses can be discarded too.
Change-Id: Id5b3f450fd18480d54ffb6e395429fba71edcd77
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/29259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This change does the following:
1. Adds a helper macro ACPI_IRQ_CFG that can be used by all other
ACPI_IRQ* macros to initialize acpi_irq structure.
2. Provides ACPI_IRQ_WAKE* versions to allow board to define an irq as
wake capable.
BUG=b:117553222
Change-Id: Ic53c6019527bbd270806897247f547178cd1ad3c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/29187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It's very common across many x86 silicon vendors, so place it in
`arch/x86/`.
Change-Id: I06c27afa31e5eecfdb7093c02f703bdaabf0594c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds the new, faster architectural register accessors to
libpayload that were already added to coreboot in CB:27881. It also
hardcodes the assumption that coreboot payloads run at EL2, which has
already been hardcoded in coreboot with CB:27880 (see rationale there).
This means we can drop all the read_current/write_current stuff which
added a lot of unnecessary helpers to check the current exception level.
This patch breaks payloads that used read_current/write_current
accessors, but it seems unlikely that many payloads deal with this stuff
anyway, and it should be a trivial fix (just replace them with the
respective _el2 versions).
Also add accessors for a couple of more registers that are required to
enable debug mode while I'm here.
Change-Id: Ic9dfa48411f3805747613f03611f8a134a51cc46
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/29017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Bounce buffers used to be used in those cases where the payload
might overlap coreboot.
Bounce buffers are a problem for rampayloads as they need malloc.
They are also an artifact of our x86 past before we had relocatable
ramstage; only x86, out of the 5 architectures we support, needs them;
currently they only seem to matter on the following chipsets:
src/northbridge/amd/amdfam10/Kconfig
src/northbridge/amd/lx/Kconfig
src/northbridge/via/vx900/Kconfig
src/soc/intel/fsp_baytrail/Kconfig
src/soc/intel/fsp_broadwell_de/Kconfig
The first three are obsolete or at least could be changed
to avoid the need to have bounce buffers.
The last two should change to no longer need them.
In any event they can be fixed or pegged to a release which supports
them.
For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the
value needed in 1999 for the 32-bit Linux kernel, the original ramstage)
to 0xe00000 (14 Mib) which will put the non-relocatable x86
ramstage out of the way of any reasonable payload until we can
get rid of it for good.
14 MiB was chosen after some discussion, but it does fit well:
o Fits in the 16 MiB cacheable range coreboot sets up by default
o Most small payloads are well under 14 MiB (even kernels!)
o Most large payloads get loaded at 16 MiB (especially kernels!)
With this change in place coreboot correctly still loads a bzImage payload.
Werner reports that the 0xe00000 setting works on his broadwell systems.
Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/28647
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These codes are written by me based on the privileged instruction set.
I tested it by qemu/riscv-probe.
Change-Id: I2e9e0c94e6518f63ade7680a3ce68bacfae219d4
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/28569
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
coreboot does not set up virtual memory anymore.
Change-Id: I231af07b2988e8362d1cdd606ce889fb31136ff1
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/28831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently src/mainboard/*/romstage.c is mandatory for compiling,
this makes having the file present even though there is nothing to
initialize in romstage on the mainboard side. Eliminate the need to
have empty romstage.c files using the wildcard function.
BUG=None
BRANCH=None
TEST= build cannonlake_rvp after removing the romstage.c file.
Change-Id: Id6335a473d413d1aa89389d3a3d174ed4a1bda90
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/28849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Clang doesn't understand -march=riscv64imac and -mcmodel=medany, so
don't use them when running the clang static analyzer. On the other
hand, __riscv and __riscv_xlen need to be defined in order to select
some macros in src/arch/riscv/include/arch/encoding.h. __riscv_flen
selects the floating-point paths in src/arch/riscv/misaligned.c.
-mabi is moved with -march for consistency.
A complete list of preprocessor definitions on RISC-V can be found at
https://github.com/riscv/riscv-toolchain-conventions#cc-preprocessor-definitions
With this commit, scan-build produces a useful result on RISC-V.
Change-Id: Ia2eb8c3c2f7eb5ddd47db24b8e5fcd6eaf6c5589
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/28713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
After emulating an instruction in the misaligned load/store handler, we
need to increment the program counter by the size of instruction.
Otherwise the same instruction is executed (and emulated) again and again.
While were at it: Also return early in the unlikely case that the
faulting instruction is not 16 or 32 bits long, and be more explicit
about the return values of fetch_*bit_instruction.
Tested by Philipp Hug, using the linuxcheck payload.
Fixes: cda59b56ba ("riscv: update misaligned memory access exception handling")
Change-Id: Ie2dc0083835809971143cd6ab89fe4f7acd2a845
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/28617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The device tree now supports 'hidden' and the status can be found in
`struct device.hidden`. A new acpi_device_status() will return the
expected setting of STA from a `struct device`.
BUG=b:72200466
BRANCH=eve
TEST=Builds and boots properly on device eve
Change-Id: I6dc62aff63cc3cb950739398a4dcac21836c9766
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/28567
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
XS is a read-only field of mstatus. Unable to be write. So remove this code.
Change-Id: I3ad6b0029900124ac7cce062e668a0ea5a8b2c0e
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/28357
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are 8 possible BERT context errors, with table ctx_names being a
table to print their names. Thus the table is supposed to have 8 elements,
and indeed it has 8 lines... but some lines are missing commas, and when
compiling it becomes a 5 element table. Add the commas at the appropriate
places.
BUG=b:115719190
TEST=none.
Change-Id: I04a2c82a25fe5f334637053ef81fa6daffb5b9c5
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/28607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Daniel Kurtz <djkurtz@google.com>
On the FU540 the bootblock runs on a core without lesser privilege
modes, so the medeleg/mideleg CSRs are not implemented on that core,
leading to a CPU exception when these CSRs are accessed.
Configure medeleg/mideleg only if the misa register indicates that
S-mode is implemented on the executing RISC-V core.
Change-Id: Idad97e42bac2ff438dd233a5d125f93594505d63
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/25791
Reviewed-by: Xiang Wang <wxjstz@126.com>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Johanna Schander <coreboot@mimoja.de>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only execute coreboot on hart 0 until synchronisation between hart's is ready.
Change-Id: I2181e79572fbb9cc7bee39a3c2298c0dae6c1658
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/28605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The RISC-V Privileged Architecture specification defines the Machine
Time Registers (mtime and mtimecmp) in section 3.1.15.
Makes it possible to use the generic udelay.
The timer is enabled using RISCV_USE_ARCH_TIMER for the lowrisc,
sifive and ucb soc.
Change-Id: I5139601226e6f89da69e302a10f2fb56b4b24f38
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/27434
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make it uniform as other architectures also include it in io.h
Change-Id: I62c2d909c703f01cdaabdaaba344f82b6746f094
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/28601
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a __always_inline macro that wraps __attribute__((always_inline))
and replace current users with the macro, excluding files under
src/vendorcode.
Change-Id: Ic57e474c1d2ca7cc0405ac677869f78a28d3e529
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/28587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@google.com>
Support for more situations: floating point, compressed instructions,
etc. Add support for redirect exception to S-Mode.
Change-Id: I9983d56245eab1d458a84cb1432aeb805df7a49f
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27972
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Add a interface, which is implemented by SoC.
Change-Id: I5524732f6eb3841e43afd176644119b03b5e5e27
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/28372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Create a structure for the Boot Error Record Table, and a generic
table generator function.
BUG=b:65446699
TEST=inspect BERT region, and dmesg, on full patch stack. Use test
data plus a failing Grunt system.
Change-Id: Ibeef4347678598f9f967797202a4ae6b25ee5538
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/28472
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add the proper table revision level for the Boot Error Record Table.
BUG=b:65446699
TEST=inspect BERT region, and dmesg, on full patch stack. Use test
data plus a failing Grunt system.
Change-Id: Ib4596fe8c0dd2a4e2e98df3a1bb60803c48d0256
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/28471
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add code for generating the region pointed to in an ACPI Boot Error
Record Table.
The BERT region must be reported as Reserved to the OSPM, so this
code calls out to a system-specific region locator. cbmem is
reported as type 16 and is not usable for the BERT region.
Events reported via BERT are Generic Error Data, and are constructed
as follows (see ACPI and UEFI specs for reference):
* Each event begins with a Generic Error Status Block, which may
contain zero or more Generic Data Entries
* Each Generic Data Entry is identifiable by its Section Type field,
and the data structures associated are also in the UEFI spec.
* The GUIDs are listed in the Section Type field of the CPER
Section Descriptor structure. BERT doesn't use this structure
but simply uses its GUIDs.
* Data structures used in the Generic Data Entry are named as
Error Sections in the UEFI spec.
* Some sections may optionally include a variable number of
additional structures, e.g. an IA32/X64 processor error
can report error information as well as machine contexts.
It is worth noting that the Linux kernel (as of v4.4) does not attempt
to parse IA32/X64 sections, and opts to hexdump them instead.
BUG=b:65446699
TEST=inspect BERT region, and dmesg, on full patch stack. Use test
data plus a failing Grunt system.
Change-Id: I54826981639b5647a8ca33b8b55ff097681402b9
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/28470
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Remove unused acpi_get_chromeos_acpi_info (see CB:28190)
- Make function naming in gnvs.h consistent (start with "chromeos_")
BUG=b:112288216
TEST=compile and run on eve
Change-Id: I5b0066bc311b0ea995fa30bca1cd9235dc9b7d1b
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/28406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add ACPI Platform Error Interfaces definitions that will be used
for building a BERT table region in a subsequent patch. Two tables
are defined: the Generic Error Status Block, Generic Error Data
Entry.
For reference, see the ACPI specification 6.2-A tables 381 and 382.
BUG=b:65446699
TEST=inspect BERT region, and dmesg, on full patch stack. Use test
data plus a failing Grunt system.
Change-Id: Ib9f4e506080285a7c3de6a223632c6f70933e66c
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/28469
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
We already explicitly generated a dependencies file for the romcc
bootblock. Though, as it has its own rule and isn't registered
to any of our object-file classes, the dependencies file wasn't
included automatically.
Change-Id: I441cf229312dff82f377dcb594939fb85c441eed
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/28442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
RAMSTAGE will revoke CAR/scratchpad, so stack and exception handling
needs to be moved to ddr memory. So add a assembly file to do this.
Change-Id: I58aa6ff911f385180bad6e026d3c3eace846e37d
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/28384
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Highest two bits of misa can be used to check machine length. Add code
to support this.
Change-Id: I3bab301d38ea8aabf2c70437e179287814298b25
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Must to set MXR, when needs to read the page which is execution-only.
So make this change.
Change-Id: I19519782fe791982a8fbd48ef33b5a92a3c48bfc
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/28394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
BOOTBLOCK/ROMSTAGE run in CAR/scratchpad. When RAMSTAGE begins
execution will enable cache, then CAR will disappear. So the
Stack will be separated.
Change-Id: I37a0c1928052cabf61ba5c25b440363b75726782
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/28383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
These RISC-V ABIs defined by GCC : ilp32 ilp32d ilp32f lp64 lp64d lp64f.
Through this we know that the length of the long's bit is equal to pointer.
So update this code. This's more flexible.
Change-Id: I16e1a2c12c6034df75dc360b65acb1b6affec49b
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27768
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some ACPI interfaces introduced by Chrome or coreboot do not
need drivers outside ChromeOS, for example Chrome EC or
coreboot table; or will be probed by direct ACPI calls (instead
of trying to find drivers by device IDs).
These interfaces should be set to hidden so non-ChromeOS systems,
for example Windows, won't have problem finding driver.
Interfaces changed:
- coreboot (BOOT0000), only used by Chrome OS / Linux kernel.
- Chrome OS EC
- Chrome OS EC PD
- Chrome OS TBMC
- Chrome OS RAMoops
BUG=b:72200466
BRANCH=eve
TEST=Boot into non-ChromeOS systems (for example Windows)
and checked ACPI devices on UI.
Change-Id: I9786cf9ee07b2c3f11509850604f2bfb3f3e710a
Signed-off-by: David Wu <David_Wu@quanta.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/1078211
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Trybot-Ready: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/28333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the MADT table version to sync with the FADT table version.
All current coreboot FADT tables are set to ACPI_FADT_REV_ACPI_3_0
and the MADT should be set to match.
This error was found by running FWTS:
FAILED [MEDIUM] SPECMADTFADTRevisions: Test 2, MADT revision is not in sync with
the FADT revision; MADT 1 expects FADT 3.0 but found 4.0 instead.
BUG=b:112476331
TEST-Run FWTS
Change-Id: If5ef53794ff80dd21f13c247d17c2a0e9f9068f2
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/28256
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Use a single function to set ACPI table versions. This allows us
to keep revisions synced to the correct levels for coreboot. This
is a partial fix for the bug:
FAILED [MEDIUM] SPECMADTFADTRevisions: Test 2, MADT revision is not
in sync with the FADT revision; MADT 1 expects FADT 3.0 but found 4.0
instead.
BUG=b:112476331
TEST-Run FWTS
Change-Id: Ie9a486380e72b1754677c3cdf8190e3ceff9412b
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/28276
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since we can retrieve the address of ACPI GNVS directly
from CBMEM_ID_ACPI_GNVS, there is no need to store and
update a pointer separately.
TEST=Compile and run on Eve
Signed-off-by: Joel Kitching <kitching@google.com>
Change-Id: I59f3d0547a4a724e66617c791ad82c9f504cadea
Reviewed-on: https://review.coreboot.org/28189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The romstage main() entry point on arm64 boards is usually in mainboard
code, but there are a handful of lines that are always needed in there
and not really mainboard specific (or chipset specific). We keep arguing
every once in a while that this isn't ideal, so rather than arguing any
longer let's just fix it. This patch moves the main() function into arch
code with callbacks that the platform can hook into. (This approach can
probably be expanded onto other architectures, so when that happens this
file should move into src/lib.)
Tested on Cheza and Kevin. I think the approach is straight-forward
enough that we can take this without testing every board. (Note that in
a few cases, this delays some platform-specific calls until after
console_init() and exception_init()... since these functions don't
really take that long, especially if there is no serial console
configured, I don't expect this to cause any issues.)
Change-Id: I7503acafebabed00dfeedb00b1354a26c536f0fe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/28199
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix the following Error:
FAILED [LOW] AMLAsmASL_MSG_SERIALIZED_REQUIRED: Test 1, Assembler remark in line
142
Line | AML source
--------------------------------------------------------------------------------
00139|
00140| Scope (\_SB.PCI0.IGFX)
00141| {
00142| Method (_ROM, 2, NotSerialized) // _ROM: Read-Only Memory
| ^
| Remark 2120: Control Method should be made Serialized (due to creation of named objects within)
00143| {
00144| OperationRegion (ROMS, SystemMemory, 0xCD520000, 0xFE00)
00145| Field (ROMS, AnyAcc, NoLock, Preserve)
================================================================================
ADVICE: (for Remark #2120, ASL_MSG_SERIALIZED_REQUIRED): A named object is
created inside a non-serialized method - this method should be serialized. It is
possible that one thread enters the method and blocks and then a second thread
also executes the method, ending up in two attempts to create the object and
causing a failure.
Use the acpigen_write_method_serialized() to correct the error.
BUG=b:112476331
TEST=Run FWTS.
Change-Id: I145c3c3103efb4a02b4e02dd177f4bf50a2c7b3e
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/28124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This change adds 2 methods for Conginuous Performance Control that was
added in ACPI 5.0 and expanded twice in later versions. One function
will create a global table based on a provided struct, while the other
function is used to add a _CPC method in each processor object.
Change-Id: I8798a4c72c681b960087ed65668f01b2ca77d2ce
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/28066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
All of the callers to acpigen_write_register() also make calls to
acpigen_write_resourcetemplate_[header|footer](). This change introduces
acpigen_write_register_resource() to unify all of those trio of calls
into one. I also made the input parameter const.
Change-Id: I10b336acf9f03c423bee9dc38955b1617e11c025
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/27672
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is a confusingly named section in cbmem called vdat.
This section holds a data structure called chromeos_acpi_t,
which exposes some system information to the Chrome OS
userland utility crossystem.
Within the chromeos_acpi_t structure, there is a member
called vdat. This (currently) holds a VbSharedDataHeader.
Rename the outer vdat to chromeos_acpi to make its purpose
clear, and prevent the bizarreness of being able to access
vdat->vdat.
Additionally, disallow external references to the
chromeos_acpi data structure in gnvs.c.
BUG=b:112288216
TEST=emerge-eve coreboot, run on eve
CQ-DEPEND=CL:1164722
Change-Id: Ia74e58cde21678f24b0bb6c1ca15048677116b2e
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/27888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since commit 372d0ff1d1 (arch/arm64: mmu: Spot check TTB memory
attributes), we already check the memory attributes that the TTB region
is mapped with to avoid configuration mistakes that cause weird issues
(because the MMU walks the page tables with different memory attributes
than they were written with). Unfortunately, we only checked
cachability, but the security state attribute is just as important for
this (because it is part of the cache tag, meaning that a cache entry
created by accessing the non-secure mapping won't be used when trying to
read the same address through a secure mapping... and since AArch64 page
table walks are cache snooping and we rely on that behavior, this can
lead to the MMU not seeing the new page table entries we just wrote).
This patch adds the check for security state and cleans up that code a
little.
Change-Id: I70cda4f76f201b03d69a9ece063a3830b15ac04b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/28017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Accesses to architectural registers should be really fast -- they're
just registers, after all. In fact, the arm64 architecture uses them for
some timing-senstive uses like the architectural timer. A read should be:
one instruction, no data dependencies, done.
However, our current coreboot framework wraps each of these accesses
into a separate function. Suddenly you have to spill registers on a
stack, make a function call, move your stack pointer, etc. When running
without MMU this adds a significant enough delay to cause timing
problems when bitbanging a UART on SDM845.
This patch replaces all those existing functions with static inline
definitions in the header so they will get reduced to a single
instruction as they should be. Also use some macros to condense the code
a little since they're all so regular, which should make it easier to
add more in the future. This patch also expands all the data types to
uint64_t since that's what the actual assembly instruction accesses,
even if the register itself only has 32 bits (the others will be ignored
by the processor and set to 0 on read). Arm regularly expands registers
as they add new bit fields to them with newer iterations of the
architecture anyway, so this just prepares us for the inevitable.
Change-Id: I2c41cc3ce49ee26bf12cd34e3d0509d8e61ffc63
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When we first created the arm64 port, we weren't quite sure whether
coreboot would always run in EL3 on all platforms. The AArch64 A.R.M.
technically considers this exception level optional, but in practice all
SoCs seem to support it. We have since accumulated a lot of code that
already hardcodes an implicit or explicit assumption of executing in EL3
somewhere, so coreboot wouldn't work on a system that tries to enter it
in EL1/2 right now anyway.
However, some of our low level support libraries (in particular those
for accessing architectural registers) still have provisions for
running at different exception levels built-in, and often use switch
statements over the current exception level to decide which register to
access. This includes an unnecessarily large amount of code for what
should be single-instruction operations and precludes further
optimization via inlining.
This patch removes any remaining code that dynamically depends on the
current exception level and makes the assumption that coreboot executes
at EL3 official. If this ever needs to change for a future platform, it
would probably be cleaner to set the expected exception level in a
Kconfig rather than always probing it at runtime.
Change-Id: I1a9fb9b4227bd15a013080d1c7eabd48515fdb67
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CNTFRQ_EL0 is a normal AArch64 architectural register like hundreds of
others that are all accessed through the raw_(read|write)_${register}()
family of functions. There's no reason why this register in particular
should have an inconsistent accessor, so replace all instances of
set_cntfrq() with raw_write_cntfrq_el0() and get rid of it.
Change-Id: I599519ba71c287d4085f9ad28d7349ef0b1eea9b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Within procedure arch_write_tables, the pointer "rom_table_end" is updated
every time a table is created. However, after creating last table, pointer
rom_table_end is not used, though it is updated. Add a "(void)rom_table_end;"
at the end to avoid the static analysis error.
BUG=b:112253891
TEST=Build and boot grunt.
Change-Id: I8a34026795c7f0d1bb86c5f5c0469d40aa53994a
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/27958
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
cache_sync_instructions() has been superseded by
arch_program_segment_loaded() and friends for a while. There are no uses
in common code anymore, so let's remove it from <arch/cache.h> for all
architectures.
arm64 still has an implementation and one reference, but they are not
really needed since arch_program_segment_loaded() does the same thing
already. Remove them.
Leave it in arm(32) since there are several references (including in SoC
code) that I don't feel like tracking down and testing right now.
Change-Id: I6b776ad49782d981d6f1ef0a0e013812cf408524
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
coreboot payloads expect to be entered with MMU disabled on arm64. The
usual path via Arm TF already does this, so let's align the legacy path
(without Secure Monitor) to do the same.
Change-Id: I18717e00c905123d53b27a81185b534ba819c7b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
src/arch/riscv/stages.c is an entry of romstage/ramstage, and does not
needs to be bootblock.
src/arch/riscv/id.S src/arch/riscv/id.ld is used to generate some
compile/board/time information, which is repeated with src/lib/version.c
Change-Id: Ic736b378e24df387584c5f86a2b04078fc55723d
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27557
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When I tried to compile the RISC-V code (202e7d4f3c), I found some errors:
`PRIu64` is undefined
src/arch/riscv/timestamp.c does not exist
Currently RISC-V does not have the implementation and use of timestamp,
so I temporarily delete the code related to timestamp in the Makefile.
And define PRIu64.
Change-Id: I7f1a0793113bce7c1411e39f102cf20dbadda5d6
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This code was copied from x86. It is not needed for RISC-V.
Change-Id: If6c3bfdc4090e45d171e68a28d27c38dabe91687
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27544
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix regression introduced in commit f18dc5c7
"Add TCPA logging functionality":
Introduced TCPA log got overwritten in acpi.c of x86/arch, due to
CBMEM name collision. Use a different cbmem name to have two independent
TCPA logs.
Change-Id: Iac63ac26989080a401aac2273265a263a3fdec56
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/27726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Add Kconfig options to not build the Arm Trusted Firmware, but use
a precompiled binary instead. To be used on platforms that do not
have upstream Arm Trusted Firmware support and useful for development
purposes.
It is recommended to use upstream Arm Trusted Firmware where possible.
Change-Id: I17954247029df627a3f4db8b73993bd549e55967
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/27559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Add support for SMBIOS table 'IPMI Device Information' and use it on
HP Compaq 8200 Elite SFF.
Tested on HP Compaq 8200. dmidecode prints the table and sensors-detect scans
for IPMI compatible devices.
Change-Id: I66b4c4658da9d44941430d8040384d022d76f51e
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/25386
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This was updating flags for ALL architectures, not just riscv.
That was bad, and gave us errors, although they weren't fatal for
some reason:
i386-elf-gcc: error: missing argument to '-mcmodel='
i386-elf-gcc: error: missing argument to '-march='
i386-elf-gcc: error: missing argument to '-mabi='
This issue started from commit 5fed693a (riscv: add support for
modifying compiler options)
Add comments to the other 'endif' statements since they're now
surrounded by a global ifeq
Change-Id: Ifa12ad98b04a5ac36148609ccdf46ca427fc5a27
Signed-off-by: Martin Roth <martin@coreboot.org>
Reviewed-on: https://review.coreboot.org/27535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add an interface to support cache as ram.
Initialize stack pointer for each hart.
Change-Id: Ic3920e01dd1a7f047a53de57250589000a111409
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Each HART of a SoC like fu540 supports a different ISA. In order for the
coreboot's code can run on each core, need to modify the compile options.
So add this code.
Change-Id: Ie33edc175e612846d4a74f3cbf7520d4145cb68b
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Replicate directory layout from x86 for SMP.
Change-Id: I27aee55f24d96ba9e7d8f2e6653f6c9c5e85c66a
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27355
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support to check ISA extension for RISC-V.
Change-Id: I5982fb32ed1dd435059edc6aa0373bffa899e160
Signed-off-by: Xiang Wang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philipp Hug <philipp@hug.cx>
GCC pre-defined some macros for detecting ISA extensions.
We should use these macros to detect ISA features.
Change-Id: I5782cdd1bf64b0161c58d789f46389dccfe44475
Signed-off-by: XiangWang <wxjstz@126.com>
Reviewed-on: https://review.coreboot.org/27300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Useful for debugging or for cases where we need to enter SMM.
Probably should be moved to commonlib or libpayload.
Change-Id: I7a9cc626dae9a7751034615ef409eebc6035f5c3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/25193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add DMAR RMRR table entry and helper functions, using the existing
DRHD functions as a model. As the DRHD device scope (DS) functions
aren't DRHD-specific, genericize them to be used with RMRR tables as
well. Correct DRHD bar size to match table entry in creator function,
as noted in comments from patchset below.
Adapted from/supersedes https://review.coreboot.org/25445
Change-Id: I912b1d7244ca4dd911bb6629533d453b1b4a06be
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/27269
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Kyösti Mälkki