summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2020-05-04mb/purism/librem_skl: Fix CLKREQ for 15v3 NVMeMatt DeVillier
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>
2020-05-04mb/purism/librem_skl: drop SataSpeedLimit restrictionMatt DeVillier
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>
2020-05-04soc/intel/skl: always enable SataPwrOptEnableMichael Niewöhner
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>
2020-05-04soc/intel/cannonlake: Add DisableHeciRetry to configChristian Walter
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>
2020-05-04mb/up/squared: Fix eMMC speed for UP2 with EDK2Patrik Tesarik
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>
2020-05-04soc/intel/common/block/cse: Add boot partition related APIsSridhar Siricilla
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>
2020-05-04security/vboot: Limit vboot verification code access to only verstageSridhar Siricilla
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>
2020-05-04mb/google/dedede: Read DRAM part number from CBIMarco Chen
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>
2020-05-04mb/**/dsdt.asl: Drop unused BRIGHTNESS_{UP,DOWN}Angel Pons
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>
2020-05-04treewide: Drop ACPI_VIDEO_DEVICE macroAngel Pons
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>
2020-05-04mb/**/dsdt.asl: Drop unused ACPI_VIDEO_DEVICEAngel Pons
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>
2020-05-04nb/intel/i945/memmap: Convert to 96 characters line lengthElyes HAOUAS
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>
2020-05-04asus/p2b: Enable IDE and UDMA for all variantsKeith Hui
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>
2020-05-04nb/intel/i440bx: Ready raminit for S3 resume pathKeith Hui
Change-Id: I77e95850af82a5684ba10841260db021f5de1e8b Signed-off-by: Keith Hui <buurin@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40960 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-04nb/intel/i440bx: Use SPDX for remaining filesKeith Hui
Change-Id: I0d28f1fc835fc05b4fc3ab891e9e6e340848aa49 Signed-off-by: Keith Hui <buurin@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40959 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-04nb/intel/i440bx: Drop northbridge.hKeith Hui
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>
2020-05-04nb/intel/i440bx: Resolve a SMP-raminit TODOKeith Hui
Change-Id: I0087294bccee079368c93ba8986873a5e65593b0 Signed-off-by: Keith Hui <buurin@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40957 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-04sb/intel/i82371eb: Move wakeup code to romstageKeith Hui
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>
2020-05-02soc/amd/picasso: Select CHROMEOS_RAMOOPS_DYNAMICFurquan Shaikh
For boards that select CHROMEOS, select CHROMEOS_RAMOOPS_DYNAMIC by default. BUG=b:155345589 Change-Id: Id215f3a2c8d1e9e713a628283af9586a1f117ef4 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40949 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-02acpi: Update sata files to be more aligned with rest of acpi filesFurquan Shaikh
This change moves sata.h to include/acpi/acpi_sata.h to align with the rest of the acpi header files in include/acpi. BUG=b:155428745 Change-Id: I3f97e5c12535a331d7347c0ecad00b07b5f13f37 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40933 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-05-02acpi: Remove acpi_ from filenamesFurquan Shaikh
This change drops acpi_ prefix from filenames under src/acpi/. BUG=b:155428745 Change-Id: Iadda2b848701367e51f4f74706154f7e36a87df6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40941 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-02acpi: Reorganize ACPI configsFurquan Shaikh
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>
2020-05-02acpi: Make header #ifdefs consistentFurquan Shaikh
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>
2020-05-02acpi: Move ACPI table support out of arch/x86 (5/5)Furquan Shaikh
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>
2020-05-02acpi: Move ACPI table support out of arch/x86 (4/5)Furquan Shaikh
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>
2020-05-02mb/asus/p8h61-m_pro: Disable SVID LDNAngel Pons
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>
2020-05-02mb/asus/p8h61-m_pro: Disable SB-TSI base addressAngel Pons
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>
2020-05-02mb/asus/p8h61-m_pro: Fix function of pin 70Angel Pons
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>
2020-05-02acpi: Move ACPI table support out of arch/x86 (3/5)Furquan Shaikh
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>
2020-05-02acpi: Move ACPI table support out of arch/x86 (2/5)Furquan Shaikh
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>
2020-05-02acpi: Move ACPI table support out of arch/x86 (1/5)Furquan Shaikh
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>
2020-05-02mb/asus/p2b*: Get rid of power button deviceKeith Hui
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>
2020-05-02mb/google/reef: Add and use VBTMatt DeVillier
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>
2020-05-02mb/purism/librem_bdw: Convert to use override devicetreeMatt DeVillier
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>
2020-05-02mb/purism/librem_bdw: Clean up 15v2 devicetreeMatt DeVillier
The Librem 15v2 only uses SATA ports 0/1, so the DTLE settings for ports 2/3 have no consequence. Drop them to make overridetree conversion cleaner. Signed-off-by: Matt DeVillier <matt.devillier@puri.sm> Change-Id: I4145feecb389be90f317249426e58752c03aef76 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40914 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-02mainboard/google/kahlee: Add hook for early wlan rst gpio initKevin Chiu
Base on the grunt board schematic, gpio70 is an alternative way for wlan rst. Add hook for variants to override default state. BUG=b:154357210,b:154848243 BRANCH=master TEST=emerge-grunt coreboot Signed-off-by: Kevin Chiu <Kevin.Chiu@quantatw.com> Change-Id: Ic3f1c016357dd5090e6adedf96e7593abff29a0c Reviewed-on: https://review.coreboot.org/c/coreboot/+/40944 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2020-05-02payloads/seabios: Add Hardware IRQ KconfigMatt DeVillier
Certain boards require SeaBIOS' HARDWARE_IRQ option to be deselected in order for the platform to boot. Add a Kconfig to allow selection of HARDWARE_IRQ enablement, and write to SeaBIOS' .config file in cases where it needs to be disabled. Deselect the option for google/rambi variants so they boot with boards defaults. Test: build/boot google/clapper, verify board boots vs hanging at boot menu prompt. Change-Id: I23e9b30d2d1042c86bd10f134d6fe361edaf8cb2 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39869 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-02intel/stm: Drop now unneeded `num_cpus` paramEugene D Myers
Suggested by Nico Huber in CB:38766 Change-Id: Ib8a340f17a12951bc6bc67e3093046575e7b0e46 Signed-off-by: Eugene D Myers <cedarhouse@comcast.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40438 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-02intel/stm: Place resource list right below MSEGEugene D Myers
Suggested by Nico Huber in CB:38765. This placement makes the address calculation simpler and makes its location indepedent of the number of CPUs. As part of the change in the BIOS resource list address calculation, the `size` variable was factored out of the conditional in line 361, thus eliminating the else. Change-Id: I9ee2747474df02b0306530048bdec75e95413b5d Signed-off-by: Eugene D Myers <cedarhouse@comcast.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40437 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-02mb/google/reef: add default non-ChromeOS FMAPMatt DeVillier
Add a FMAP which supports SMMSTORE and non-ChromeOS payloads, since Apollo Lake-based devices like Reef cannot use an automatically-generated FMAP due to strict layout requirements. Change-Id: If570f92f4f81c0e29777c87756fc5e45af549064 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40907 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-02mb/supermicro/x11: drop DeepSx config from devicetreeMichael Niewöhner
Drop the DeepSx config as it's unsupported and disabled for the boards. Change-Id: I91cd15b26a41f376561630cf45ffa192745eae84 Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40858 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-02nb/intel/i440bx: Clean up register_values tableKeith Hui
The table of initial i440BX register values has a bitmask that allows preserving certain bits as they are programmed. This feature has been unused since day one and probably will never be used. So drop it. Drop DRB, RPS, PGPOL registers from the table as they will be programmed during RAM init. These two reductions combined saved ~104 bytes. Drop unneeded SDRAMC "+0". Slightly compact a comment block. TEST=Boot tested on asus/p2b-ls, i440bx config did not change Change-Id: I020f616455bb671fe284993a488beb6386a03d0d Signed-off-by: Keith Hui <buurin@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40391 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2020-05-02arch/x86: Change power_res_dev_states[] to be static const * constFurquan Shaikh
This change makes power_res_dev_states[] to be static const * const as complained by Jenkins. BUG=b:155428745 Change-Id: Ice2fff6ab3bcd72a059bc905b7462a681f2e6aaf Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40935 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-02cpu: Add a helper function cpu_get_lapic_addrFurquan Shaikh
This change adds a helper function cpu_get_lapic_addr() that returns LOCAL_APIC_ADDR for x86. It also adds a weak default implementation which returns 0 if platform does not support LAPIC. This is being done in preparation to move all ACPI table support in coreboot out of arch/x86. BUG=b:155428745 Change-Id: I4d9c50ee46804164712aaa22be1b434f800871ec Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40929 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2020-05-02src/acpi: Drop Kconfig option ACPI_SATA_GENERATORFurquan Shaikh
ACPI_SATA_GENERATOR is currently used to include sata.c in ramstage. However, there is no need to guard this inclusion using a separate Kconfig. All other files that deal with ACPI tables are included based on the state of HAVE_ACPI_TABLES. This change includes sata.c in ramstage if HAVE_ACPI_TABLES is selected. If the ACPI function isn't used, linker will optimize it out. BUG=b:155428745 Change-Id: I9a319cfe7c3f973b15ccbd0f13bd1ed07571a398 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40928 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-01soc/amd/picasso: add sd/emmc0 configuration to chip.hAaron Durbin
In order to isolate mainboard code from direct FSPS manipulation allow sd/emmc0 configuration to be supplied by devicetree.cb. BUG=b:153502861 Change-Id: I2569ccccd638faaf2c9ac68fe582ecb9fa967d9f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2146439 Commit-Queue: Aaron Durbin <adurbin@google.com> Tested-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40876 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-01soc/amd/picasso: Add FSP support for including AGESAMarshall Dawson
AMD has rewritten AGESA (now at v9) for direct inclusion into UEFI build environments. Therefore, unlike the previous Arch2008 (a.k.a. v5), it can't be built without additional source, e.g. by combining with EDK II, and it has no entry points for easily building it into a legacy BIOS. AGESA in coreboot now relies on the FSP 2.0 framework published by Intel and uses the existing fsp2_0 driver. * Add fsp_memory_init() to romstage.c. Although Picasso comes out of reset with DRAM alive, this call is added to maximize compatibility and facilitate internal development. Future work may look at removing it. AGESA reports the memory map to coreboot via HOBs returned from fsp_memory_init(). * AGESA currently sets up MTRRs, as in most older generations. Take ownership back immediately before running ramstage. * Remove cbmem initialization, as the FSP driver handles this. * Add chipset_handle_reset() for compatibility. * Top of memory is determined by the FSP driver checking the HOBs passed from AGESA. Note that relying on the TOM register happens to be misleading when UMA is below 4GB. BUG=b:147042464 TEST=Boot trembyle to payload Change-Id: Iecb3a3f2599a8ccbc168b1d26a0271f51b71dcf0 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34423 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-01src/soc/amd/picasso: Add methods to save and restore MTRRsRaul E Rangel
FSP AGESA overrides the MTRRs that coreboot set up. Until this is fixed we need to save and restore the MTRRs to undo what AGESA did. Once AGESA is fixed, we can delete these files. BUG=b:155426691, b:147042464 TEST=Boot trembyle and see MTRRs being modified Saving Variable MTRR 0: Base: 0x00000000 0xff000005, Mask: 0x0000ffff 0xff000800 Saving Variable MTRR 1: Base: 0x00000000 0x08070006, Mask: 0x0000ffff 0xffff0800 Saving Variable MTRR 2: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000 Saving Variable MTRR 3: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000 Saving Variable MTRR 4: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000 Saving Variable MTRR 5: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000 Saving Variable MTRR 6: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000 Saving Variable MTRR 7: Base: 0x00000000 0x00000000, Mask: 0x00000000 0x00000000 Saving Fixed MTRR 0: 0x00000000 0x00000000 Saving Fixed MTRR 1: 0x00000000 0x00000000 Saving Fixed MTRR 2: 0x00000000 0x00000000 Saving Fixed MTRR 3: 0x00000000 0x00000000 Saving Fixed MTRR 4: 0x00000000 0x00000000 Saving Fixed MTRR 5: 0x00000000 0x00000000 Saving Fixed MTRR 6: 0x00000000 0x00000000 Saving Fixed MTRR 7: 0x00000000 0x00000000 Saving Fixed MTRR 8: 0x00000000 0x00000000 Saving Fixed MTRR 9: 0x00000000 0x00000000 Saving Fixed MTRR 10: 0x00000000 0x00000000 Saving Default Type MTRR: 0x00000000 0x00000800 Saving SYS_CFG: 0x00000000 0x00000800 ... MSR 0x200 was modified: 0x00000000 0x00000006 MSR 0x201 was modified: 0x0000ffff 0x80000800 MSR 0x202 was modified: 0x00000000 0x80000006 MSR 0x203 was modified: 0x0000ffff 0xc0000800 MSR 0x204 was modified: 0x00000000 0xc0000006 MSR 0x205 was modified: 0x0000ffff 0xf0000800 MSR 0x250 was modified: 0x06060606 0x06060606 MSR 0x258 was modified: 0x06060606 0x06060606 SYS_CFG was modified: 0x00000000 0x00740000 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I6048b25bd8a32904031ca23953f9726754b5a294 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40922 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-01soc/intel/xeon_sp/cpx: Implement hide/unhide P2SB traditional danceAndrey Petrov
Perform the P2SB hide/unhide trick. This is needed so that BAR0 (0xfd000000) is not reclaimed by resource allocator, since it can not deal with a device that does not exist (hidden). Signed-off-by: Andrey Petrov <anpetrov@fb.com> Change-Id: I5db0ae4e31d72ba86efba5728b2afc68d3180d5d Reviewed-on: https://review.coreboot.org/c/coreboot/+/40921 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
2020-05-01soc/intel/xeon_sp/cpx: Enable common P2SBAndrey Petrov
Use common P2SB driver. This is needed to address a problem when enumerator does not see p2sb device (since it is hidden) but it is active and BAR is decoded. Change-Id: I9cb821a5684f15f1e1486872bf806a6ee3d0676f Signed-off-by: Andrey Petrov <anpetrov@fb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40920 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 11:47:55 +0000