PMC supports messages that can be used for configuring the USB
Type-C Multiplexer/Demultiplexer.
BUG=b:151646486
TEST=Booted to kernel on volteer board and verified PMC and Mux
agent devices identification.
Change-Id: I00c5f929b2eea5de3f8eba794dbe9b36c8083c52
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add a knob for mainboards to request disablement of the SPI
flash ROM sharing in the chipset. The chipset allows the board
to share the SPI flash bus and needs a pin to perform the request.
If the board design does not employ SPI flash ROM sharing then it's
imperative to ensure this option is selected, especially if the
pin is being utilized by something else in the board design.
BUG=b:153502861
Change-Id: I60ba852070dd218c4ac071b6c1cfcde2df8e5dce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2146445
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@google.com>
Tested-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
If a Picasso platform wants to use GPIO 67 it must disable ROM sharing.
Otherwise ROM access is incredibly slow.
BUG=b:153502861
TEST=Build trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia9ab3803a2f56f68c1164bd241fc3917a3ffcf2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Update interrupt setting based on latest FSP(3163.01)
Reference:
https://github.com/otcshare/CCG-TGL-Generic-SiC/blob/TGL.3163.01/
ClientOneSiliconPkg/IpBlock/Itss/LibraryPrivate/PeiItssPolicyLib/
PeiItssPolicyLibVer2.c
BUG=b:155315876
BRANCH=none
TEST=Build with new FSP(3163.01) and boot OS and login OS console
in ripto/volteer. Without this change, we can't login due to mismatch
interrupt setting between asl and fsp setting.
Cq-Depend: chrome-internal:2944102
Cq-Depend: chrome-internal:2939733
Cq-Depend: chrome-internal:2943140
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: Ibf70974b8c4f63184d576be3edd290960b023b1e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40872
Reviewed-by: Dossym Nurmukhanov <dossym@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Due to refactoring of Serial IO code in FSP v3163 onwards we need to
set SerialIoUartDebugMode UPD in FSP-M to SkipInit so that SerialIoUart
initialization is skipped in FSP. This makes sure that SerialIo
initialization in coreboot is not changed by FSP.
BUG=b:155315876
BRANCH=none
TEST=build and boot tglrvp/ripto/volteer and check UART debug logs
Cq-Depend: chrome-internal:2944102
Cq-Depend: chrome-internal:2939733
Cq-Depend: chrome-internal:2943140
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I8ba4b9015fa25a84b6b99419ce4d413c9d9daa44
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40899
Reviewed-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The latest Intel FSP advertises xHCI v1.2 chipset support, so update
libpayload to include that version. No critical changes were identified
in review of the xHCI v1.2 spec, and booting from USB works with the
included change as expected.
BUG=b:155315876
TEST=booting from multiple USB sticks/hubs with the latest Intel FSP
that advertises xHCI v1.2
Change-Id: I236fed9beef86ff5e1bf7962d882fdae5817a1ff
Signed-off-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41039
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Librem SKL/KBL boards do not have an exposed serial port interface.
Set board Kconfig so that a default built image with Tianocore payload
is bootable and doesn't hang due to trying to send data over a
non-existant serial port.
Test: build/boot librem 13v4 with board defaults + Tianocore
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I4c3f8a3c1726f804957b06b437b399291854a3f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reorder Kconfig selects alphabetically, and select the correct SoC
for each variant (even though it currently makes no difference).
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I46f651a530ef0ed617dd1f3eee077e84279a40f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40913
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the same variant dirs are used by multiple versions of the
same board, drop the v2/v3 labels.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: Id913e31ab52043e49769be9d3ebf6e71ecb0c856
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40912
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Since the variants' devicetrees are almost identical, convert to
using an overridetree setup for simplicity.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I3dac62a649e12ea2498d3ecafe03fd0d62af5f2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Update the documentation now that CB:32705 is merged.
Change-Id: I9845c0750ec4016188478154610400d1b8556793
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40775
Reviewed-by: Marcello Sylvester Bauer <sylv@sylv.io>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Per the schematics, SRCCLKREQ2# is used for the NVMe and should be
enabled. Enable CLKREQ for PCIe RP9, and adjust comments to indicate
correct value used per schematic.
Test: build/boot Librem 15v3 with NVMe drive, verify drive identified
properly and no errors in boot log.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I159cb7ce1f5195d95c0229490c3bbde26edbd375
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
SataSpeedLimit was set to 3Gbps to work around issues which are now
known to be the result of incorrect FSP behavior. Since SataPwrOptEnable
is now set at the SoC level and ensures the SIR registers are correctly
programmed, we can re-enable 6Gbps operation without errors.
Test: build/boot Librem 13v2 with both m.2 and 2.5" SATA drives,
check dmesg for errors.
Change-Id: I3565dc063724ad288ef92361942fcdc14daac17e
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40909
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For unknown reasons FSP skips a whole bunch of SIR (SATA Initialization
Registers) when SataPwrOptEnable=0, which currently is the default in
coreboot and FSP. Even if FSP's default was 1, coreboot would reset it.
This can lead to all sorts of problems and errors, for example:
- links get lost
- only 1.5 or 3 Gbps instead of 6 Gbps
- "unaligned write" errors in Linux
- ...
At least on two boards (supermicro/x11-lga1151-series/x11ssm-f and
purism/librem13v2) SATA is not working correctly and showing such
symptoms.
To let FSP correctly initialize the SATA controller, enable the option
SataPwrOptEnable statically. There is no valid reason to disable it,
which might break SATA, anyway.
Currently, there are no reported issues on CML and CNL, so a change
there could not be tested reliably. SKL/KBL was tested successfully
without any noticable downsides. Thus, only SKL gets changed for now.
Change-Id: I8531ba9743453a3118b389565517eb769b5e7929
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40877
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add DisableHeciRetry to the chip config and parse it in romstage.
Change-Id: I460b51834c7de42e68fe3d54c66acd1022a3bdaf
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40756
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Since commit 402fe20e (mb/up/squared: Add mainboard) the UP2's eMMC
maximum host speed was reduced to DDR50, because HS200 showed I/O errors
in the host kernel. We found out that with EDK2 master the correct
Host Speed could not be set properly during EDK2 platform init.
Therefore eMMC would not show up for boot device selection.
This commit sets the eMMC MaxHostSpeed to the designed max value of the
used eMMC on the UP2 board and furthermore drops the override from the
ramstage.c. It's already set in the devicetree.cb.
Though CRC errors are still visible in EDK II debug logs, no other
negative effects have been observed.
Signed-off-by: Patrik Tesarik <mail@patrik-tesarik.de>
Change-Id: I8d53204d8a776efd560fbdea918f83e180813179
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In CSE Firmware Custom SKU, CSE region is logically divided into
2 boot partitions. These boot partitions are represented by BP1(RO),
BP2(RW). With CSE Firmware Custom SKU, CSE can boot from either
RO(BP1) or RW(BP2).
The CSE Firmware Custom SKU layout appears as below:
------------- -------------------- ---------------------
|CSE REGION | => | RO | RW | DATA | => | BP1 | BP2 | DATA |
------------- -------------------- ---------------------
In order to support CSE FW update to RW region, below APIs help coreboot
to get info about the boot partitions, and allows coreboot to set CSE
to boot from required boot partition (either RO(BP1) or RW(BP2)).
GET_BOOT_PARTITION_INFO - Provides info on available partitions in the CSE
region. The API provides info on boot partitions like start/end offsets
of a partition within CSE region, and their version and partition status.
SET_BOOT_PARTITION_INFO - Sets CSE's next boot partition to boot from.
With the HECI API, firmware can notify CSE to boot from RO(BP1) or RW(BP2)
on next boot.
As system having CSE Firmware Custom SKU, boots from RO(BP1) after G3,
so coreboot sets CSE to boot from RW(BP2) in normal mode and further,
coreboot ensure CSE to boot from whichever is selected boot partition
if system is in recovery mode.
BUG=b:145809764
TEST=Verified on hatch
Change-Id: Iaa62409c0616d5913d21374a8a6804f82258eb4f
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Make vboot verification code accessible in only verstage.
Vboot verification code in vboot_logic.c is being used
in verstage. Due to support function vboot_save_data(),
so core functionality in vboot_logic.c is made available in romstage.
The patch decouples the support function frm vboot_logic.c to
limit itself to verstage.
BUG=b:155544643
TEST=Verified on hatch
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: Id1ede45c4dffe90afcef210eabaa657cf92a9335
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
The git checkout hint introduced in cb:36343 does not get printed but
executed instead. Escape the single-quotes to fix this.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I1277c3788a141b25cd9f22ec0476ee56b64aea4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The check for changed files, introduced in cb:36343 does not work
(anymore?) due to the quotes. Thus, drop them.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Ie126e3d604990b2346f1f004f912080104e2789d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The index of MEM_STRAPS will be migrated from per DRAM part number to
per DRAM characteristic therefore one index mapped to a single SPD
binary can represent to multiple DRAM part numbers as long as their
characteristic is the same for DRAM controller to support. In this case,
the real DRAM part number would be provisioned in the CBI instead of SPD
in the factory flow. As a result, we need to extract DRAM part number
from CBI.
BUG=b:152019429
BRANCH=None
TEST=1. provision dram_part_num field of CBI
2. check DRAM part number is correct in SMBIOS for memory device
Change-Id: I40780a35e04efb279591e9db179cb86b5e907c0d
Signed-off-by: Marco Chen <marcochen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
It is only used with the Lenovo-specific H8 EC code.
Change-Id: If3b209a9ab82a07ce7b4450d8a0b62a1ca86a95c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
It was always defined to the same value, and only used twice.
Change-Id: I2736eb7ea2cf15475f7bb99d7d12450730eb8be0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40864
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is only used with the Lenovo-specific H8 EC code.
Change-Id: I596d4d19277555894ab728e32a44e34a5a21e21d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Also remove an extra star in comment.
Change-Id: I2ef938573e75022dcb31c935dde7d3055e7a53f0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40802
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There's no reason not to.
Change-Id: I12c9e0f66c437d8add5c4096fd2a5e747d082799
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It declares a function that was either never or no longer implemented.
Change-Id: I714d39374519bff1afb94870d0e84f57db619a1f
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40958
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This code is needed in romstage, not ramstage.
Change-Id: Ic38c3c50fb135fba582864a242348ec29cec2991
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In order to the Kconfigs in the same directory where the corresponding
code lives, this change moves ACPI_BERT to arch/x86/Kconfig and
following configs to acpi/Kconfig:
ACPI_CPU_STRING
ACPI_HAVE_PCAT_8259
ACPI_NO_PCAT_8259
HAVE_ACPI_TABLES
BUG=b:155428745
Change-Id: I289565f38e46bd106ff89685aaf8f57e53d9827a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40932
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that all ACPI header files are moved to src/include/acpi, this
change updates the #ifdef to __ACPI_${FILENAME}__.
BUG=b:155428745
Change-Id: Id24ee35bac318278871a26f98be7092604de01c0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This change moves all ACPI table support in coreboot currently living
under arch/x86 into common code to make it architecture
independent. ACPI table generation is not really tied to any
architecture and hence it makes sense to move this to its own
directory.
In order to make it easier to review, this change is being split
into multiple CLs. This is change 5/5 which moves the addition of ACPI
table related files from arch/x86/Makefile.inc to acpi/Makefile.inc.
BUG=b:155428745
Change-Id: I8143fd37357aeb0561516450adddc6714d539ada
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40940
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change moves all ACPI table support in coreboot currently living
under arch/x86 into common code to make it architecture
independent. ACPI table generation is not really tied to any
architecture and hence it makes sense to move this to its own
directory.
In order to make it easier to review, this change is being split into
multiple CLs. This is change 4/5 which gets rid of the placeholder
header files that were added to temporarily include acpi/ header files
from arch/header files.
BUG=b:155428745
Change-Id: If6e8580c3c6433f9239e06a1dc7ba661b3f597e5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The SVID functionality is not used on this mainboard. Turn it off.
Change-Id: Iea891975b32d24f54edec9d8c36391ec60a37d0c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
SB-TSI is specific to AMD platforms, but this is an Intel board.
Change-Id: I5eb7e3bc920103279dfca3a9ec14a41666404993
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40738
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The board uses the pin for Deep S5, but the code was setting 3VSBSW.
Change-Id: I81c865358002e6af500658efea851ab8c8202950
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40737
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 moves all ACPI table support in coreboot currently living
under arch/x86 into common code to make it architecture
independent. ACPI table generation is not really tied to any
architecture and hence it makes sense to move this to its own
directory.
In order to make it easier to review, this change is being split into
multiple CLs. This is change 3/5 which basically is generated by
running the following command:
$ git grep -iIl "arch/acpi" | xargs sed -i 's/arch\/acpi/acpi\/acpi/g'
BUG=b:155428745
Change-Id: I16b1c45d954d6440fb9db1d3710063a47b582eae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This change moves all ACPI table support in coreboot currently living
under arch/x86 into common code to make it architecture
independent. ACPI table generation is not really tied to any
architecture and hence it makes sense to move this to its own
directory.
In order to make it easier to review, this change is being split into
multiple CLs. This is change 2/5 which moves the contents of
arch/x86/include/arch/acpi*.h files into include/acpi/acpi*.h and
updates the arch header files to include acpi header files. These are
just temporary placeholders and will be removed later in the series.
BUG=b:155428745
Change-Id: I9acb787770b7f09fd2cbd99cb8d0a6499b9c64b3
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This change moves all ACPI table support in coreboot currently living
under arch/x86 into common code to make it architecture
independent. ACPI table generation is not really tied to any
architecture and hence it makes sense to move this to its own directory.
In order to make it easier to review, this change is being split into
multiple CLs. This is change 1/5 which moves .c files from arch/x86 to
acpi/.
The only acpi files that are still retained under arch/x86 are:
a. acpi_s3.c: This doesn't really deal with ACPI tables. Also, there
are some assumptions in there about SMM which will have to be resolved
if this file needs to be moved to common code.
b. acpi_bert_storage.c/bert_storage.h: This file is currently written
specifically with x86 in mind. So, not moving the file for now.
Motivation for this change: Not all stages on Picasso SoC are targeted
for the same architecture. For example, verstage (if runs before
bootblock) will be targeted for non-x86. This makes it difficult to
add device tree to verstage which would be required to get to SoC
configs from the tree. This is because the device tree on x86
platforms currently contains a lot of devices that require ACPI
related enums and structs (like acpi_gpio, acpi_pld, acpi_dp and so
on). Hence, this change removes all ACPI table support out of
arch/x86.
BUG=b:155428745
Change-Id: Icc6b793c52c86483a8c52e0555619e36869a869e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
These boards have the same issue as [27272]:
Currently, two power buttons are exposed in ACPI, and detected by the
operating system.
> As per the ACPI specification, there are two types of power button
> devices:
> 1. Fixed hardware power button
> 2. Generic hardware power button
>
> Fixed hardware power button is added by the OSPM if POWER_BUTTON flag
> is not set in FADT by the BIOS. This device has its programming model
> in PM1x_EVT_BLK. All ACPI compliant OSes are expected to add this
> power button device by default if the power button FADT flag is not
> set.
>
> On the other hand, generic hardware power button can be used by
> platforms if fixed register space cannot be used for the power button
> device. In order to support this, power button device object with HID
> PNP0C0C is expected to be added to ACPI tables. Additionally,
> POWER_BUTTON flag should be set to indicate the presence of control
> method for power button.
>
> [i440BX] mainboards implemented the generic hardware power button in
> a broken manner i.e. power button object with HID PNP0C0C is added to
> ACPI however none of the boards set POWER_BUTTON flag in FADT. This
> results in Linux kernel adding both fixed hardware power button as
> well as generic hardware power button to the list of devices present
> on the system. Though this is mostly harmless, it is logically
> incorrect and can confuse any userspace utilities scanning the ACPI
> devices.
Hardware tests on the P2B-LS shows the generic hardware power button
is not working anyway - with FADT power button flag set, the board
could not power off with the button.
This change removes the generic hardware power button from all P2B
mainboards and relies completely on the fixed hardware power button.
TEST=Booted on P2B-LS, Linux detects only fixed hardware power
button, button still powers off.
[27272]: https://review.coreboot.org/27272
Change-Id: I0f5b7aaf32366360de3cce58cd742651a2bb46ba
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40007
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add VBT file, and override use via Kconfig since all Reef variants
use the same VBT file.
VBT extracted from firmware in ChromeOS recovery image.
Test: built/boot google/reef w/FSP display init
Change-Id: I31156ec7371c0443719fdd9ddac6ed4960c83767
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40926
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since the variants' devicetrees are almost identical, convert to
using an overridetree setup for simplicity.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I07fb5a09e578bf299081b26e010317385a6c5f7f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Keith Hui