Remove former Intel employee from maintainers of Braswell SoC.
Add 3mdeb and Eltan representatives as Braswell SoC maintainers.
Also mark Braswell SoC as maintained.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Id815db60e3718bf141abcc7923ea073bbab4a516
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Piotr Król <piotr.krol@3mdeb.com>
Intel Braswell P-UNIT is missing in pci_devs.h
Add PUNIT device, function and device ID
BUG=N/A
TEST=Facebook FBG-1701 booting Embedded Linux
Change-Id: I80c87c8964b3ba830571e0c03c424b67729a0c1a
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31711
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new Pantheon sku-id for loading vbt-pantheon.bin
BUG=b:78663963
BRANCH=firmware-nami-10775.B
TEST=Boots to OS and display comes up.
Change-Id: Icd56905e1e04de6f307393ae23f741b93ff23a4c
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31747
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We want to publish "arcada_ish.bin" as the fw name for Integrated
Sensor Hub (ISH) so the kernel shim loader code can use it to
construct the correct path in /lib/firmware/intel for the firmware
load process.
BUG=b:122722008
TEST=Verify that shim loader CLs use new value when constructing
firmware path
Change-Id: I6299de82566a3bad8521f8158bb047d5c1ff0cf8
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We want to be able to specify the firmware variant suffix
in the devicetree.cb configuration for particular firmware
builds. This driver allows us to specify the firmware_variant
property in the device tree and have it populate a _DST table
in the SSDT ACPI table for the ISH device, thus making the
suffix available to the kernel (See crrev.com/c/1433482 for kernel
change that uses the value)
BUG=b:122722008
TEST=decompile DDST table and verify that new firmware-variant value
is present. Also verfied that kernel can access this new field using
the shim loader kernel CLs
Change-Id: Id8be986185282521aee574027503eaf8968e1508
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
The __pci_driver and __cpu_driver uses variable length arrays which are
constructed by the linker at build-time.
The linker always place the structs at 16-byte boundary, as per
"System V ABI". That's not a problem on x86, as the struct is exactly
16 Bytes in size. On other platforms, like x86_64 it breaks, because the
default data alignment isn't SysV compatible.
Set -malign-data=abi to make x86_64 gcc use the SysV psABI.
Fixes broken __pci_driver and __cpu_driver on x86_64.
Change-Id: I2491d47ed03dcfd8db110dfb181b2c5281449591
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30116
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are two known reverse-engineered ways to manage battery
thresholds.
This patch implements them and adds a way to enable them for
different mainboards.
Tested on W530 with 4.18.3-gentoo kernel and X220 with 4.20.11.
Works fine with new Linux userspace API for controlling battery
thresholds, available since 4.17.
(/sys/class/power_supply/BAT0/charge_(start|stop)_threshold).
The new API is supported by TLP (you might need to set NATACPI_ENABLE=1
in /etc/tlp.conf).
tpacpi-bat works fine too.
Signed-off-by: Alexey Kharlamov <der@2-47.ru>
Signed-off-by: Evgeny Zinoviev <me@ch1p.com>
Change-Id: I2a90f9e9b32462b8a5e9bc8d3087ae0fea563ea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/23178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.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>
Inlining here allows the check for (dev != NULL) to be
optimised and evaluated just once inside the calling
function body.
Change-Id: I0b5b4f4adb8eaa483a31353324da19917db85f4a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Based on not publicly available IT8613E Preliminary Specification V0.3.
Change-Id: Iec99d4d998f645dbad9c803d6d5477580b0bccc4
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31620
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change adds support for the SuperIO chip IT8613E. This chip uses
FANs 2-5 and has SmartGuardian always enabled (no ON/OFF control) so
it relies on support in common ITE code. LDNs were taken from IT8613E
Preliminary Specification V0.3.
Change-Id: I73c083b7019163c1203a5aabbef7d9d8f5ccb16a
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This is a great check, but unfortunately it's currently not effective
because most uses of IS_ENABLED() do not have whitespace in front of
them (they're mostly used as part of an if (IS_ENABLED(...)) condition).
This patch makes the linter a little more generous in what it considers
in scope to avoid these false negatives in the future.
Change-Id: I2296410c73cd6e918465c90db33e782936bec0f9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31746
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This IS_ENABLED(XXX) line should've clearly been IS_ENABLED(CONFIG_XXX).
This patch can fix that. However, I don't have (and don't plan to
acquire) an affected system to test, so approve at your own risk (or
let me know if I should just remove that check instead).
Change-Id: I79a0fca65853798ee45c3779b437864ba3cf2b1e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31745
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This IS_ENABLED(XXX) line should've clearly been IS_ENABLED(CONFIG_XXX).
This patch fixes the issue. Not tested on a real board, but looking at
the affected code paths suggests that this will result in no effective
change anywhere (since CAR should already be torn down by the time this
is called on FSP1.0 boards, so do_car_migrate_variables() would have
immediately exited anyway).
Change-Id: I74e0ed4d04471ee521ff5c69a74a6f4c949e5847
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31744
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>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
For Chrome OS (or vboot), The PRESERVE flags should be applied on
following sections:
RO_PRESERVE, RO_VPD, RW_PRESERVE, RW_ELOG, RW_NVRAM, RW_SMMSTORE,
RW_VPD, RO_FSG (b:116326638), SI_GBE (chromium:936768),
SI_PDR (chromium:936768)
With the new PRESERVE flag, we don't need RO_PRESERVE and RW_PRESERVE in
the future. But it's still no harm to use it if there are multiple
sections all needing to be preserved.
BUG=chromium:936768
TEST=Builds google/eve and google/kukui inside Chrome OS source tree.
Also boots successfully on eve and kukui devices.
Change-Id: I6664ae3d955001ed14374e2788d400ba5fb9b7f8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31709
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When updating firmware, it is very often that we may want to preserve
few sections, for example vital product data (VPD) including serial
number, calibration data and cache. A firmware updater has to hard-code
the section names that need to be preserved and is hard to maintain.
A better approach is to specify that in FMAP area flags (the `area_flag`
field) using FMAP_AREA_PRESERVE. With this patchset, a FMD parser flag
"PRESERVE" is introduced and will be converted to FMAP_AREA_PRESERVE
when generating FMAP data (by fmap_from_fmd.c).
For example, The FMD statement:
RO_VPD(PRESERVE)@0x0 16k
will generate an FMAP firmware section that:
area_name = "RO_VPD"
area_offset = 0
area_size = 16384
area_flags = FMAP_AREA_PRESERVE
BUG=chromium:936768
TEST=make; boots on x86 "google/eve" and arm "google/kukui" devices
Manually added 'PRESERVE' to some FMD files, and verify (by running
fmap.py) the output coreboot.rom has FMAP_AREA_PRESERVE set
Change-Id: I51e7d31029b98868a1cab0d26bf04a14db01b1c0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31707
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The recent toolchain update also updated binutils, which has a new
relocation type, introduced with commit bd7ab16b
(x86-64: Generate branch with PLT32 relocation).
Add support for R_X86_64_PLT32, which is handled as R_X86_64_PC32.
Add comment explaining the situation.
Fixes build error on x86_64.
Change-Id: I81350d2728c20ac72cc865e7ba92319858352632
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31468
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Qemu does not have a real CAR but postcar stage is still useful
for testing the stage.
The postcar stage is also mandatory for x86_64 to setup
pagetables for x86_64 ramstage.
Do not set up MTRRs, as qemu ignores them anyways.
Tested on qemu-i440fx and qemu-q35.
Change-Id: I6638534d99fde312e55b6a6be8c95e4cb25cca80
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The idea of "annotation" for firmware sections was pretty flexible, but
in future we will want multiple attributes applied to same area. For
example, indicate the section must be preserved when updating firmware
so serial number or MAC address can be preserved.
The solution here is to extend annotation so it can take multiple
identifiers (flags) in a row. For example, to declare a 64KB COREBOOT
section as CBFS using annotation:
COREBOOT(CBFS)@0x0 64k
If there's a new flag "PRESERVE" indicating the section must be
preserved before update, we can declare it following CBFS flag:
COREBOOT(CBFS PRESERVE)@0x0 64k
The flags are directly parsed in fmd_parser, and stored in an union
flashmap_flags. Output modules can choose to ignore or process the
flags.
Currently the only supported flag is "CBFS" (for backward compatible
with annotation). There will be more new flags in follow up patches.
BUG=chromium:936768
TEST=make; boots on x86 "google/eve" and arm "google/kukui" devices
Change-Id: Ie2d99f570e6faff6ed3a4344d6af7526a4515fae
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31706
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
git diff needed to emit diffs without prefix (e.g. a/ and b/) for
clang-format-diff to be able to work.
Also require that the test succeeds, but note that it only runs on
trees whitelisted in $(top)/.clang-format-scope.
Change-Id: I7e9a32eb9281b5cb0b45506a206500fd1d315372
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31654
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
80 chars + 2 tabs was the compromise we got to in the last round of
discussion.
Change-Id: I9293a69d1bea900da36501cde512004d0695ad37
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Intel Braswell SoC contains SMBus controller but no support
is available for this controller.
This controller is compatible with the Intel SMBus support in the
southbridge common directory.
To be able using smbus support from the Intel common directory
the smbus.c is moved outside SOUTHBRIDGE_INTEL_COMMON
dependency block.
Use SOUTHBRIDGE_INTEL_COMMON_SMBUS to include support.
BUG=N/A
TEST= Facebook FBG-1710 LCD panel
Change-Id: Ie3d4f657558a1aed21b083ef5cad08ea96e629c3
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Apollo Lake has four GPIO communities each with a single group named
after the physical location of the pads (I guess): North West, North,
West and South West.
Also add some logic to be able to tag the default function of a pad
(with an asterisk before its name). This seems easier to review in the
tables, but we could also encode the number of the default explicitly
instead.
Used Intel documents:
- 334817-001 (datasheet vol. 1)
- 334819-001 (datasheet vol. 3)
Change-Id: I5cd687fdc1d2ae81f2e948178bf319897b47f031
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Felix Singer <migy@darmstadt.ccc.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The function (preprocessor macro) we need is defined
in <endian.h> not <swab.h>.
Change-Id: I3a86c7050bf853e3a56a15421132240e19f40912
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31704
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Fixes indirect includes that would break with followup work.
Change-Id: I37ca01b904a0b422a4d09475377e755e167a6ab3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
These resolved to <device/oprom/include/io.h> which
included <arch/io.h> that we really wanted.
Change-Id: I9aa0bdf34cd1d53e20b4494c7986f0878f4fd840
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31693
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable the support for providing a MAC address for a dock to use based on
the VPD values set in the platform.
BUG=b:123925776
TEST=tested on sarien by setting VPD values and observing the string
returned by the AMAC() method:
> vpd -i RO_VPD -s "ethernet_mac0"="AA:AA:AA:AA:AA:AA"
> vpd -i RO_VPD -s "dock_mac"="BB:BB:BB:BB:BB:BB"
1) Test with no policy set, returns "dock_mac"
ACPI Debug: "VPD region RW did not verify"
ACPI Debug: "Found VPD KEY dock_mac = BB:BB:BB:BB:BB:BB"
ACPI Debug: "MAC address returned from VPD: BB:BB:BB:BB:BB:BB"
ACPI Debug: "AMAC = _AUXMAC_#BBBBBBBBBBBB#"
2) Test with policy set to "builtin", returns nothing
> vpd -i RW_VPD -s "dock_passthru"="builtin"
ACPI Debug: "Found VPD KEY dock_passthru = builtin" [AMAC returns Zero]
3) Test with policy set to "ethernet_mac0"
> vpd -i RW_VPD -s "dock_passthru"="ethernet_mac0"
ACPI Debug: "Found VPD KEY dock_passthru = ethernet_mac0"
ACPI Debug: "Found VPD KEY ethernet_mac0 = AA:AA:AA:AA:AA:AA"
ACPI Debug: "MAC address returned from VPD: AA:AA:AA:AA:AA:AA"
ACPI Debug: "AMAC = _AUXMAC_#AAAAAAAAAAAA#"
4) Test with policy set to "dock_mac"
> vpd -i RW_VPD -s "dock_passthru"="dock_mac"
ACPI Debug: "Found VPD KEY dock_passthru = dock_mac"
ACPI Debug: "Found VPD KEY dock_mac = BB:BB:BB:BB:BB:BB"
ACPI Debug: "MAC address returned from VPD: BB:BB:BB:BB:BB:BB"
ACPI Debug: "AMAC = _AUXMAC_#BBBBBBBBBBBB#"
Change-Id: I90474e264cc433c0fd1a4b0dbaf98e5f74180d54
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/31670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
This change adds support for providing a MAC address that can be used
by the OS network drivers to change the MAC address that a NIC uses.
The Realtek r8152 driver in the Linux kernel supports a MAC address
passthru feature which can result in the dock ethernet port using the
same MAC address that is assigned to the internal NIC. This is done
by calling an ACPI method at \_SB.AMAC() which returns a formatted
string containing the MAC address for the dock to use.
The Linux kernel implementation can be found at
drivers/net/usb/r8152.c:vendor_mac_passthru_addr_read()
This is implemented specifically for Chrome OS as it relies on VPD
to determine the MAC address to supply.
The policy which controls where the dock MAC address comes from is
written into RW_VPD property "dock_passthru":
"dock_mac" or empty: Use MAC address from RO_VPD value "dock_mac"
"ethernet_mac0": Use MAC address from RO_VPD value "ethernet_mac0"
"builtin": existing dock MAC address (return nothing)
The MAC address in VPD is the standard format AA:BB:CC:DD:EE:FF and
it must be converted into the string format expected by the OS which
involves some string manipulation which ACPI is not great at handling.
BUG=b:123925776
TEST=this was tested on a sarien board by setting the VPD keys to
their expected values and observing if the AMAC() method returns the
expected string.
Change-Id: I3335e5d924155431e299844e2aaace62168294e0
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/31669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
This ACPI device presents an interface that allows other ACPI devices
or methods to read VPD strings. The VPDF() method is provided the
VPD partition to look in, and the name of the VPD key to find and it
will return the VPD string if it exists.
For example: VPD.VPDF ("RO", "serial_number")
BUG=b:123925776
TEST=this was tested on a sarien platform by adding ACPI code that
searches for a VPD key and returns the value it finds, and then setting
that VPD string from the OS with the Chrome OS 'vpd' utility to ensure
the ACPI method returns the correct value.
Change-Id: I4668f66d7f7f364ac8c3b064d406b24135abb0f6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/31668
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Store the memory address of VPD region start and length for the memory
mapped RO_VPD and RW_VPD into GNVS so they can be used by ACPI code.
BUG=b:123925776
TEST=boot on sarien and verify VPD start/length in GNVS
Change-Id: I39073a9d78f5ff60bfe088860c087a5167f05fdf
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/31667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Frans Hendriks