This change drops internal pulls for dalboz reference configured on pads
which already have external pull-ups in hardware.
GPIO_0(PWR_BTN_L): Pulled up to PP3300_A
GPIO_2(WAKE_L): Pulled up to PP3300_A
GPIO_10: Unused. Changed to PAD_NC.
GPIO_11(EC_IN_RW_OD): Pulled up to PP3300_A
GPIO_12(USI_INT_ODL): Pulled up to PP3300_A
GPIO_16(USB_OC0_L): Pulled up to PP3300_A
GPIO_17(USB_OC1_L): Pulled up to PP3300_A
GPIO_21(EMMC_CMD): Pulled up to PP1800_S0
GPIO_22(EC_FCH_SCI_ODL): Pulled up to PP3300_A
GPIO_31(EC_AP_INT_ODL): Pulled up to PP1800_A
GPIO_32: Unused. Changed to PAD_NC.
GPIO_113(I2C2_SCL): Pulled up to PP3300_S0
GPIO_114(I2C2_SDA): Pulled up to PP3300_S0
GPIO_129(KBRST_L): Pulled up to PP1800_S0
GPIO_92(CLK_REQ0_L): Pulled up to PP3300_S0
GPIO_115(CLK_REQ1_L): Pulled up to PP3300_S0
GPIO_116(CLK_REQ2_L): Pulled up to PP3300_S0
BUG=b:154351731
Change-Id: I62e9dbac7a55efa1e055983a7c126168ee516151
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change drops internal pulls for trembyle reference configured on pads
which already have external pull-ups in hardware.
GPIO_0(PWR_BTN_L): Pulled up to PP3300_A
GPIO_2(WAKE_L): Pulled up to PP3300_A
GPIO_10: Unused. Changed to PAD_NC.
GPIO_12(USI_INT_ODL): Pulled up to PP3300_A
GPIO_16(USB_OC0_L): Pulled up to PP3300_A
GPIO_17(USB_OC1_L): Pulled up to PP3300_A
GPIO_21(EMMC_CMD): Pulled up to PP3300_A
GPIO_22(EC_FCH_SCI_ODL): Pulled up to PP3300_A
GPIO_31(EC_AP_INT_ODL): Pulled up to PP1800_A
GPIO_90: Unused. Changed to PAD_NC.
GPIO_113(I2C2_SCL): Pulled up to PP3300_S0
GPIO_114(I2C2_SDA): Pulled up to PP3300_S0
GPIO_129(KBRST_L): Pulled up to PP1800_S0
GPIO_130(EC_IN_RW_OD): Pulled up to PP3300_S0
GPIO_92(CLK_REQ0_L): Pulled up to PP3300_S0
GPIO_115(CLK_REQ1_L): Pulled up to PP3300_S0
GPIO_132(CLK_REQ4_L): Pulled up to PP3300_S0
BUG=b:154351731
Change-Id: Id84b801e019eede7ef543c24aac968f3ef99b3fd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43526
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the ACPI specification, version 6.3:
Accesses to the PM1 status registers are done through byte or word
accesses.
The same is said about the PM1 Enable registers. Therefore, reporting
dword-sized access is wrong and means nothing anyway. Since some other
platforms use word-sized access, use word everywhere for consistency.
Tested on Asus P8Z77-V LX2 with Linux 5.7.6 and Windows 10 at the end of
the patch train, both operating systems are able to boot successfully.
Change-Id: I6f85c9a4126f37ab2a193c3ab50a6c8e62cf6515
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43432
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All supported x86 chips select HAVE_CF9_RESET, and also use 0xcf9 as
reset register in FADT. How unsurprising. We might as well use that
information to automatically fill in the FADT accordingly. So, do it.
To avoid having x86-specific code under arch-agnostic `acpi/`, create a
new optional `arch_fill_fadt` function, and override it for x86 systems.
Tested on Asus P8Z77-V LX2 with Linux 5.7.6 and Windows 10 at the end of
the patch train, both operating systems are able to boot successfully.
Change-Id: Ib436b04aafd66c3ddfa205b870c1e95afb3e846d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
They are ignored if the ACPI_FADT_WBINVD flag is set, which is required
on current ACPI versions and only maintained for ACPI 1.0 compatibility.
Tested on Asus P8Z77-V LX2 with Linux 5.7.6 and Windows 10 at the end of
the patch train, both operating systems are able to boot successfully.
Change-Id: Ief1219542ba71d18153b64180e0ff60bd1e7687b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Looks like some preparation is needed before reset. However, Picasso
also needs some special handling and still selects this option without
selecting HAVE_CF9_RESET_PREPARE. So, just add HAVE_CF9_RESET for now.
Change-Id: I0c6da9a43a28dbee916fd6bda9ae380ebd619edf
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43388
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead, just flip the desired bits using bitwise operations. As this is
initially zero, the resulting value is the same. This allows flags to be
set from anywhere regardless of execution order.
Tested on Asus P8Z77-V LX2 with Linux 5.7.6 and Windows 10 at the end of
the patch train, both operating systems are able to boot successfully.
Change-Id: Icfd580a20524936cd0adac574331b09fb2aea925
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43387
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both `acpi_fill_fadt` and `soc_fill_fadt` set many FADT fields. Since
the latter runs later, the values programmed in it overwrite any other
values. Drop unused assignments and consolidate everything in a single
function. Use `acpi_fill_fadt` as it is mandatory (no weak definition).
Change-Id: Ia8248f20dae2b93426f309605bb2076592b08df4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43386
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to Intel Order Number 290562 (PIIX4 datasheet), 0xcf9 is the
reset register, and setting bits 1 and 2 will result in a hard reset.
Change-Id: Id5ada6a10b2269d51908c6a5fd7745ef6c33a29a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The PM2_CNT register block is not present on this southbridge, as per
Intel Document 290744 (ICH4 datasheet). Also, the ACPI specification,
version 6.3, section 4.8.1.3 (PM2 Control Register), says:
This register block is optional, if not supported its block pointer and
length contain a value of zero.
Since the FADT struct defaults to zero in coreboot, we don't need to do
anything to indicate PM2_CNT is not supported. So, drop unneeded values.
Also delete a comment about `pm2_cnt_len`, which said that the right
value differs from zero. Looks like that comment was wrong instead.
Change-Id: Icbb32f5db7b368c764b3477c40f8ae9c788df5ee
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43383
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PM2_CNT register block is not present on this southbridge, according
to comments on the code. As per the ACPI specification, version 6.3,
section 4.8.1.3 (PM2 Control Register):
This register block is optional, if not supported its block pointer and
length contain a value of zero.
Since the FADT struct defaults to zero in coreboot, we don't need to do
anything to indicate PM2_CNT is not supported. So, drop unneeded values.
Change-Id: Ib3ff0fd9e0725f61c38e60ba56b95e6e77b0b1ed
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43382
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PM2_CNT register block is no longer needed, as explained in some
comments. While they may have been copy-pasted around a lot, they are at
least true for Hudson, and it makes sense to assume that they are true
for newer chipsets as well. As per the ACPI specification, version 6.3,
section 4.8.1.3 (PM2 Control Register):
This register block is optional, if not supported its block pointer and
length contain a value of zero.
Since the FADT struct defaults to zero in coreboot, we don't need to do
anything to indicate PM2_CNT is not supported. So, drop unneeded values.
Change-Id: Iabc7985c84aabe40ad98fdc9fc6ccbbab0a516c1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43381
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
None of the currently-supported chips has PM1b_EVT nor PM1b_CNT event
register blocks. According to the ACPI specification, version 6.3,
sections 4.8.1.1 and 4.8.1.2 (PM1 Event/Control Registers):
If the PM1b_EVT_BLK is not supported, its pointer contains a value of
zero in the FADT.
If the PM1b_CNT_BLK is not supported, its pointer contains a value of
zero in the FADT.
Since the FADT struct defaults to zero in coreboot, we don't need to do
anything with PM1b for now. So, drop unneeded writes to PM1b fields.
Tested on Asus P8Z77-V LX2 with Linux 5.7.6 and Windows 10 at the end of
the patch train, both operating systems are able to boot successfully.
Change-Id: Iff788b2ff17ba190a8dd9b0b540f1ef059a1a0ea
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43380
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
None of the currently-supported chips has a GPE1 block. The ACPI spec,
version 6.3, section 4.8.1.6 (General-Purpose Event Registers) says:
If a generic register block is not supported then its respective
block pointer and block length values in the FADT table contain zeros.
Since the FADT struct defaults to zero in coreboot, we don't need to do
anything with GPE1 for now. So, drop the unneeded writes to GPE1 fields.
Tested on Asus P8Z77-V LX2 with Linux 5.7.6 and Windows 10 at the end of
the patch train, both operating systems are able to boot successfully.
Change-Id: Iefc4bbc6e16fac12e0a9324d5a50b20aad59a6cd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43379
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add configs for USB 3.1 Gen2 EV settings so that people can set the
EV settings per board in device tree.
BUG=b:150515720
BRANCH=none
TEST=build coreboot and fsp with enabled fw_debug.
Flashed to puff and checked the log.
All usb configs were set correctly.
Signed-off-by: Jamie Chen <jamie.chen@intel.com>
Change-Id: Id4860665619095139c329565d433d9eb495cac02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39448
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that libgfxinit has been fixed, trying to enable the Analog port no
longer hangs the system, nor fills the monitor with unreadable garbage.
Tested with linear framebuffer, displays correctly on a 1920x1080 VGA
monitor. Scaling also works when a smaller HDMI monitor is connected as
well. Legacy VGA text mode is also functional on either monitor, too.
Change-Id: Ie2f88edcb7ed1984adebf2af23195767af13654c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43560
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This brings in 4 new commits:
* c0db994 common/Makefile.inc: Factor out generation TLAs
* 3f86b0b Move `PSR_Off` out of `Power_And_Clocks_Haswell`
* 450c24c haswell: Make VGA on FDI work
* 3318bf2 Drop generation suffix from `Power_And_Clocks`
Change-Id: I023b0c2bb403b3a9c9fe575a78cd2cf2f20b112a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
* Move most mainboard/system76 ACPI code to ec/system76
* Move drivers/system76_ec to ec/system76
* Include system76_ec.c when CONSOLE_SYSTEM76 is set
* Fix inclusion of system76 EC code
* Default CONSOLE_SYSTEM76_EC to n
* addw2: fix SSD2 clkreq
The DPTF._OSC method incorrectly assumed that all available UUIDs would
be present in the IDSP package, but this is not always the case. Instead
of matching an incoming UUID against an index into IDSP, search the IDSP
package for the matching UUID.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I718b6abe09152647b14f7c1405b2d0d20035726b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The previous DPTF patch train missed the proper scope operator around
all of the TSR options. Without this, the optional GTSH and/or _STR
Methods end up in the wrong scope.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I9298c442c047c5f7f606574d900057a7c004b47f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43458
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the initial DPTF refactor, the scope of the TCPU device was
incorrectly set as \_SB, instead of \_SB.PCI0. However, because of the
way that the acpi_inject_dsdt() callback currently works (it injects
contents before the dsdt.aml file), the Scope where the TCPU
device lives (\_SB.PCI0) doesn't exist yet. Therefore, to avoid playing
games with *when* things are defined in the DSDT, switch to defining all
of the DPTF devices in the SSDT.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ia4922b4dc6544d79d44d39e6ad18c6ab9fee0fd7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43529
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While the DPTF refactor was in progress, TSR3 was added to volteer's
dptf.asl file, and I forgot to update the devicetree with TSR3 as well.
Also missed a swap in the passive policies of TSR0 and TSR1. This patch
fixes those.
BUG=b:149722146
TEST=boot volteer, dump SSDT & DSDT, verify TSR3._STA returns 0xF
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I71bc798492ec45bb1e2f8d779e6829db52ef4499
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43528
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Deepika Punyamurtula <deepika.punyamurtula@intel.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Vilboz requires a different HID than rest of the zork variants. Hence,
this change sets the HID to AMDI1015 for I2S machine device in vilboz
overridetree.cb.
BUG=b:157708581
Change-Id: Ibae343f21cf8f0c782dc8a461f69172bf0da7eba
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43545
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change switches zork devices to use the newly added
i2s_machine_dev driver in devicetree rather than passing
dmic_select_gpio in SoC config.
BUG=b:157708581
Change-Id: I76c633694cbfb454c081ab2a4af4765bfbbae16b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds a new driver for AMD I2S machine device. Currently,
this device is added as part of `acp_fill_ssdt()` in Picasso, but with
addition of this driver, this device can be added just like any other
device in the devicetree.
BUG=b:157708581
Change-Id: I49d1a867d7941397acca1054632b6ad855a021de
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change increases the maximum length of device path string to 40
characters to accommodate growing hierarchy of devices.
TEST=Ensured that "\_SB.PCI0.LPCB.EC0.CREC.TUN0.RT58" is correctly
added to SSDT.
Change-Id: Id2ef71a32b26e366b56c652942a247de4889544a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change drops _INI and OSFL methods under \_SB since they are not doing
anything useful. _INI only calls OSFL and OSFL initializes OSVR if not
already initialized and returns OSVR value. However, OSVR is not used
anywhere and hence both these functions can be dropped.
BUG=b:153879530
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I4f3e1c93a855006cc115087fded20bfb76c1133e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43515
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Global variable `PMOD` that stores the interrupt mode used by OS is
required by all mainboards. This change moves the variable definition to
globalnvs.asl under picasso.
Additionally, ACPI spec says that BIOS should assume interrupt mode as PIC
until _PIC() method is called by OS. Thus, this change also updates the
default value of PMOD as 0 i.e. PIC mode.
BUG=b:153879530
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I731c03d965882281a7a23f55894451210ba72274
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43514
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPIO_9 is associated with gevent 22. Correct all the misconfigurations
and use macros for clarity as to what bit offset is being used instead
of open coding things.
BUG=b:161205804
Change-Id: Ic4cfd62763d72d12a55f89585f24e07df6af0f4f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43516
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, the code and data in psp_verstage is ~59K. Adding the code
to save vbnv to the SPI rom increases that to 66K.
Getting rid of VERSTAGE_SIZE allows verstage to grow as it needs to.
BUG=b:161366241
TEST=Build & Boot Morphius with VBOOT_VBNV_CMOS_BACKUP_TO_FLASH enabled
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Ic6853b70073f9e781fc10402a2a47c9c8e0d49d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43486
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Extend the local APIC timer delay so that it can be started,
and waited for, independently.
Add an EOI so that more than one APIC timer interrupt is possible.
Previous to this, because there was no EOI, the first timer
interrupt the CPU took was also the last it would take --
apic_delay would only work one time.
Change-Id: Ib11aeee5b7da81287166ac68fc327e7ae62d1b84
Signed-off-by: Ronald G Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
On zork, bootblock is part of RW firmware in non-recovery mode, so PCIe
GPIOs can be configured early on in bootblock rather than waiting until
romstage. This change moves the call to variant_pcie_gpio_configure() to
happen in bootblock and drops romstage.c file.
BUG=b:154351731
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ic515304f35fe5623d58d6000efcb11fb9039e137
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43476
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
gpio_set_stage_rom table is now configuring only PCIe related GPIOs in
romstage. This change moves the configuration of PCIe related GPIOs to
variant_pcie_gpio_configure() to keep all the configuration for WiFi and
non-WiFi PCIe pads in one place. It also drops the function
variant_romstage_gpio_table() as it is unused.
BUG=b:154351731
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib1c41ba141dce6b52b6e0a250a3aa07c296068aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43475
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the power and reset GPIO configuration for non-PCIe devices is
dropped from romstage GPIO table, the tables for pre-v3 and v3 version of
schematics are exactly same. So, this change drops the duplicate table and
also removes the check for v3 schematics when configuring the pads in
romstage.
BUG=b:154351731
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I67ca9f587c3f47912393ebaf38badcc9d76cc393
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently the common soc code automatically selects
POWER_STATE_DEFAULT_ON_AFTER_FAILURE which making other mainboard
options unselectable.
However, there're some cases that power state should change to different
states after reapplying power.
Make POWER_STATE_DEFAULT_ON_AFTER_FAILURE default y but do not select it
in soc code so that we can disable it and select other options in the
mainboard code.
Tested on OCP Delta Lake.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: Ifa853d81ee9477d2440ceaa67b2bd6b863ee52c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Implement sending POST start/end command to BMC.
TEST=Read POST command log in OpenBMC,
if command received successfully, message may show as below,
root@bmc-oob:~# cat /var/log/messages |grep -i "POST"
2020 May 28 13:21:22 bmc-oob. user.info fby3-v2020.20.2:
ipmid: POST Start Event for Payload#1
2020 May 28 13:21:25 bmc-oob. user.info fby3-v2020.20.2:
ipmid: POST End Event for Payload#1
root@bmc-oob:~#
Signed-off-by: TimChu <Tim.Chu@quantatw.com>
Change-Id: I38b512ee97c0eda6ba54482a448ef9ffc27b4ddb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41993
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We typically call checkpatch.pl through make lint which properly adds
the option to tell checkpatch that our lines may be 96 columns long.
However there's one mention of calling checkpatch directly and that
confuses people with complaints about overly long lines that exceed
80 columns.
The lint test that runs checkpatch (and with the right options)
can also be used on a per-directory basis, so offer that instead.
Change-Id: If21e925d2d2394c876724a44b0e23c9b2744c56b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43450
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This pin has been removed from recent revisions (or at least moved to a
pin that's not controlled like a normal GPIO). It has also never been
used on older ones (I think?). The same GPIO is now used as a SKU ID
pin, so make sure we're not incorrectly configuring it as an output
(although sku_id() overrides that later anyway, but it's still
incorrect).
BUG=b:160754995
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I6e0d56e230d0bef172d7b78cc48263e9b6f059de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43471
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Philip Chen <philipchen@google.com>
Reviewed-by: Bob Moragues <moragues@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This information is redundant since it's already specified in
baseboard/devicetree_trembyle.cb or baseboard/devicetree_dalboz.cb
domain 0 is still required because sconfig uses it as an identity anchor
to match devicetree and overridetree.
BUG=b:157580724
TEST=Boot zork, usb functional
Change-Id: I3c3c1c2410166b99599d7343fae3ee756f4da321
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43437
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Up until now we have no way of adding transparency into our firmware
screens. Add set_blend() and clear_blend() functions to store alpha
value and rgb values to calculate alpha blending in
calculate_colors().
BUG=b:144969091,b:160839199
BRANCH=puff
TEST=dut-control power_state:rec
press ctrl-d
Ensure background is dimmed when dialog pops up
Change-Id: I95468f27836d34ab80392727d726a69c09dc168e
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
If the AP actually needs to write to the TPM, then it is important and
the TPM should commit those changes to NVMEM immediately in case there
is an unexpected power loss (e.g. from a USB-C port partner reset upon
cold reboot request).
BRANCH=none
BUG=b:160913048
TEST=Verify that puff will no longer reboot loop when coreboot writes a
new Hmir (Hash mirror) in the TPM
Change-Id: I9597a55891d11bdf040d70f38b4c5a59c7888b8a
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43414
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SataPortsEnableDitoConfig Enable DEVSLP Idle Timeout settings DmVal and
DitoVal. SataPortsDmVal and SataPortsDitoVal helps to determine when to
enter Device Sleep. Device Sleep enables the host bus adapter (HBA) to
assert the DEVSLP signal as soon as there are no commands outstanding
to the device and the port specific Device Sleep idle timer has expired.
Device Sleep Idle Timeout values (PxDEVSLP.DITO and PxDEVSLP.DM) are
port specific timeout values used by the HBA for determining when to
assert the DEVSLP signal. They provides a mechanism for the HBA to apply
a programmable amount of hysteresis so as to prevent the HBA from
asserting the DEVSLP signal too quickly which may result in undesirable
latencies. This patch is created based on Intel Tiger Lake Processor
PCH Datasheet with Document number:575857 and Chapter number:12.
* PxDEVSLP.DM -> SataPortsDmVal: Enable SATA Port DmVal DITO multiplier.
Default is 15.
* PxDEVSLP.DITO -> SataPortsDitoVal: Enable SATA Port DmVal DEVSLP Idle Timeout
(DITO), Default is 625ms.
BUG=b:151163106
BRANCH=None
TEST=Build and boot volteer and TGL RVP.
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Change-Id: I6a824524738a9e0609f54bea9d892b4a42a1d3db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42214
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
0xc50, 0xc52, 0xc6f don't exist on Picasso. The PCI config space
registers define SATA and OHCI which are at the wrong bus locations.
I just remove the whole section since it's not used. We never access the
PCIe Error region, or the PM2 region either.
BUG=b:153001807, b:154756391
TEST=Build Trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I98aee09770f1df9f553c94580c1ee00c06a9cec1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The ACPI specification, version 2.0 says:
_BFS is an optional control method.
So, remove them. They have been copy-pasted around quite a bit, and do
not do anything useful. Plus, it's deprecated in later ACPI versions.
Change-Id: I9ef21f231dd6051d410ac3a0fe554908409c2fa7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43443
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Forgetting to add the #pragma pack() at the end of the header file can
lead to hard to debug breakage, so get rid of the #pragma pack usage and
add a __packed to the structs that need to be packed which has less
possibly unwanted side effects.
Since commit d44221f9c8 coreboot always
includes commonlib/compiler.h which provides __packed.
TEST=Timeless build results in identical binary.
Change-Id: Icc53168f4fbc3a63a859f686b18e7023d225f8d2
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add USB ports, USB user-facing camera and USB bluetooth to devicetree.
USB ports 4 and 5 are duplicated for picasso and dali.
BUG=b:158096224
TEST=Boot Trembyle and Dalboz, Dump acpi tables
Change-Id: Icf8628d91e27a3afdc5fd67a53b44089c809da87
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Split zork baseboard devicetree between dalboz and trembyle.
The devicetree is simply duplicated, no other changes in this commit.
BUG=b:158096224
TEST=Build coreboot for zork
Signed-off-by: Rob Barnes <robbarnes@google.com>
Change-Id: I5b26770790092c69db9567fa4337edd21a6ed809
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Screen flickered on VT2 on some devices after idle a period of time.
Remove SSR (1/8) setting for SA to default SSR (1/2), screen flicking
issue disappeared, and didn't affect acoustic noise much.
Because CB:38212 (commit eae254e) caused this issue.
BUG=b:160754994
TEST=build dratini, observe that screen flick issue disapppered
Change-Id: I9e81c2f15dd6babfa360eee213fc4ab6310c7455
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43284
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SaGv needs to be enabled for only QS. On ES2, we are seeing system
instability.
BUG=b:159198381
TEST=Tested for boot. Power and performance tests were run with
volteer2 with qs setup. System showed stability.
Tested for boot stability on on delbin.
Change-Id: I1bce3b9f837fb19ba5a20ae31750a73474a86788
Signed-off-by: Shreesh Chhabbi <shreesh.chhabbi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Configure volteer2 and delbin, the two variants currently using
preQS or QS silicon, to use CSE Lite.
BUG=b:158140797
TEST=cd to volteer's asset_generation folder, execute
"./gen_all_variant_images.sh" and verify that all variant
images are produced.
Change-Id: I5e444529b090d82094b9da0df2648ea4cdb2888e
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Extract DRAM info from AMD_FSP_DMI_HOB and store it as mem_info in
cbmem with id CBMEM_ID_MEMINFO. Subsquently extract mem_info objects
from cbmem to build SMBIOS type 17 tables.
BUG=b:148277751,b:160947978
TEST=dmidecode -t 17
BRANCH=none
Change-Id: Iacedbb017d19516674070f89ba0aa217f55383e3
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
CB:43224 ("mb/google/zork: Add helpers for v3 schematics and wifi
power enable") added helper functions for determining if a board uses
v3 schematics. However, it introduced a regression by adding a wrong
check for variant_uses_v3_schematics() in variant_audio_update(). This
change fixes the check to ensure that dmic_gpio is updated when
variant is not using v3 schematics.
BUG=b:161141258,b:161128964
TEST=Verified on trembyle that trackpad works again (it was broken
because of the regression).
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I0e6ad844f68cface7b545f1547bd94470c30dde4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43415
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the woomax variant of the zork reference board by copying
the template(coreboot-zork/util/mainboard/google/trembyle)
files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.1.1).
BUG=b:158343602
BRANCH=None
TEST=emerge-zork coreboot
Signed-off-by: Kane Chen <kane_chen@pegatron.corp-partner.google.com>
Change-Id: I0bb8ce1851f4064d24e48fd8957e2f9fe1e80b53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change SPI speed from 66MHz, mode 1-1-2 to 100MHz mode 1-2-2.
“1-2-2" means command, address and data are transmitted
through 1 wire, 2 wire and 2 wire, respectively.
BUG=b:160603142
TEST=Boot on trembyle, verify register settings.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I14f96e3c085126c70e64ef3a3f5b7b54ce6cbffe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43306
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As with other macros, convert PAD_CFG0_ROUTE_* to PAD_IRQ_ROUTE() to
make the code in gpio_defs.h cleaner.
Tested with BUILD_TIMELESS=1, Kontron COMe-mAL10 on T10-TNI carrierboard
does not change.
Change-Id: Iadc9c4b3c96ae04c56d060cb060737a8eba7f165
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41034
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Converts PAD_CFG0_RX_POL_* macros to PAD_RX_POL() to make the code
cleaner and reduce the length of the macro.
Tested with BUILD_TIMELESS=1, Kontron COMe-mAL10 on T10-TNI carrierboard
does not change.
Change-Id: I09a048fd38ccb994f53c8829c549bc2b368fa546
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41033
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Converts PAD_CFG0_TRIG_ * macros to PAD_TRIG() to make the code cleaner
and reduce the length of the macro, which is often used.
Tested with BUILD_TIMELESS=1, Kontron COMe-mAL10 & T10-TNI carrierboard
does not change.
Change-Id: I9e1b4118fd6c6f0d58ee38a743aa8c27535f0dd9
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41032
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Current the common soc code automatically selects PCIEXP_CLK_PM and
PCIEXP_L1_SUB_STATE which breaks booting Windows with a PCIE NVIDIA
graphics card attached on mainboards that do not have a CLKREQ# signal.
This is commonly used on server and workstations boards where the
additional power savings of L1 substate are not required.
Make the PCIEXP_CLK_PM and PCIEXP_L1_SUB_STATE default y but do not
select it anymore by the soc code, thus we can disable it in the
mainboard code.
Tested on CFL with Windows 10.
Change-Id: I025e13d6d8183256647e4c034e31bafa235f7eb7
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41696
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Share "EC in RW" GPIO with depthcharge. Also we define the CONFIGS
needed CHROME, CHROME_EC and use the chrome lid and recovery.
BUG=None
BRANCH=None
TEST=Build and boot TGL RVP. Check recovery works with
crossystem recovery_request.
Change-Id: I1e88200e3f8418e5b0ab39ac65ed1b3545ce111e
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Platform HOBs (in particular IIO_UDS and MemoryMap HOBs) are of HOB type
HOB_TYPE_GUID_EXTENSION, therefore they do not have resource structure.
Remove the erroneous code related to resource structure.
Remove unnecessary function prototypes from header files, and define them
as static in hob_display.c.
Since we have the HOB pointer, there is not need to search HOB by GUID.
Remove unnecessary calling of fsp_find_extension_hob_by_guid().
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Reddy Chagam <anjaneya.chagam@intel.com>
Change-Id: Ib99bce39e6eb2aeb95242dfba36774653bbe91fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43335
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Read VPD variable 'fsp_log_enable' to decide enabling FSP log or not.
With VPD_RW_THEN_RO, VPD_RW takes precedence over VPD_RO, and
would be set to enabled if both places cannot find it.
Tested=On OCP Delta Lake, use vpd to create and set fsp_log_enable
and verified the results are expected.
Change-Id: I0b3463acedd90e8e17f7e4eedc2fab63644f87e1
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: insomniac <insomniac@slackware.it>
CPX-SP FSP ww28 release adds UPDs to allow enablement of VT-d and VMX.
Also update IIO UDS HOB definition file accordingly.
Intel CPX-SP FSP has been using FSPM_CONFIG intead of FSP_M_CONFIG.
Other Intel FSPs have been using FSP_M_CONFIG. The feedback from Intel
is that they will converge to use FSPM_CONFIG over time. So both will
co-exist for some time. Today coreboot common code expects FSP_M_CONFIG.
Accomodate this situation in FspmUpd.h.
The CPX-SP soc code is updated accordingly.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: If6d0a041eaad9eb2f811e74d219fff1cc38e95a4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43315
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
On ChromeOS systems with a serial-enabled BIOS and vboot writing a new
firmware image to the Chrome EC, it was possible for the TCO watchdog
timer to trip 2 times before tco_configure() was called in romstage.
This caused an extra reboot of the system (at a rather inopportune time)
and because the EC didn't perform a full reset, the system boots into
recovery mode.
This patch moves the call to tco_configure() for Tiger Lake from
romstage to bootblock, in order to make sure the TCO watchdog timer is
halted before vboot_sync_ec() runs in romstage. It should be harmless to
configure the TCO device earlier in the boot flow.
BUG=b:160272400
TEST=boot Volteer (to a non-recovery kernel!) with a freshly imaged EC
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Iefdc2c861ab8b5fde7f736c04149be7de7b3ae0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43313
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
IRQ 10 and IRQ 11 are valid for all southbridges using this code, as per
their respective datasheets. So, add them for the sake of completeness.
Change-Id: Ib4504861ed316a95b9735e0ed79f108f18071b3b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43158
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds Type-C Intel Input Output Manager(IOM) device with HID
INTC1072. It provides MMIO range from 0xfbc10000 with size 0x1600.
Intel Input Output Manager(IOM) kernel driver reads relevant
information such as Type-C port status (whether a device is connected
to a Type-C port or not) and the activity type on the Type-C ports
(such as USB, Display Port, Thunderbolt) using this memory resource.
BUG=b:156016218
TEST=Able to detect USB, TBT and USB4 on Volteer.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ic733e831643bda6e052edf797ba0e6206eb4ddd3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41762
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Rajmohan Mani <rajmohan.mani@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds Type-C IO Manageability engine base address and size.
Tigerlake EDS(#575681) section 3.4.3 describes host bridge
REGBAR(MCHBAR) + 7110h for IOM REGBAR with size 1600h. IOM has a
port ID 0xc1. MCHBAR is programmed with 0xfedc0000. IOM REGBAR is
determined from mmio (MCHBAR + 0x7110), which has value 0xfb000000.
IOM has base address 0xfbc10000 from IOM REGBAR + (0xc1 << 16).
BUG=🅱️156016218
TEST=Built and booted on Volteer.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I70d88ba318087f7acacd1ee84609c9db5b65f907
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41759
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Rajmohan Mani <rajmohan.mani@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Upstream does not require it. From the repository readme:
"Note: When cloning submodule repos, '--recursive' option is not recommended.
EDK II itself will not use any code/feature from submodules in above submodules.
So using '--recursive' adds a dependency on being able to reach servers we do not
actually want any code from, as well as needlessly downloading code we will not use."
Change-Id: I0c5d6dd6e5070720870fc22b2476c6fe8dc7fd40
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43063
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
We only want to return an ACPI name for a USB port if the controller
physically has the port. This has the desired side effect of making the
usb_acpi driver skip generating an ACPI node for a device which has
no port. This prevents writing an invalid SSDT table which the OS then
complains about.
BUG=b:154756391, b:158096224
TEST=Boot picasso trembyle and verify HS05, HS06 and SS05 are no longer
generated. Also checked the logs and saw the devices being ignored.
\_SB.PCI0.LPCB.EC0.CREC.TUN0: Cros EC I2C Tunnel at GENERIC: 0.0
\_SB.PCI0.LPCB.EC0.CREC.MSTH: Cros EC I2C Tunnel at GENERIC: 1.0
\_SB.PCI0.LPCB.EC0.CREC.ECA0: Cros EC audio codec at GENERIC: 0.0
\_SB.PCI0.PBRA.XHC0.RHUB.HS01: Left Type-C Port at USB2 port 0
\_SB.PCI0.PBRA.XHC0.RHUB.HS02: Left Type-A Port at USB2 port 1
\_SB.PCI0.PBRA.XHC0.RHUB.HS03: Right Type-A Port at USB2 port 2
\_SB.PCI0.PBRA.XHC0.RHUB.HS04: Right Type-C Port at USB2 port 3
xhci_acpi_name: USB2 port 4 does not exist on xHC PCI: 03:00.3
xhci_acpi_name: USB2 port 5 does not exist on xHC PCI: 03:00.3
\_SB.PCI0.PBRA.XHC0.RHUB.SS01: Left Type-C Port at USB3 port 0
\_SB.PCI0.PBRA.XHC0.RHUB.SS02: Left Type-A Port at USB3 port 1
\_SB.PCI0.PBRA.XHC0.RHUB.SS03: Right Type-A Port at USB3 port 2
\_SB.PCI0.PBRA.XHC0.RHUB.SS04: Right Type-C Port at USB3 port 3
xhci_acpi_name: USB3 port 4 does not exist on xHC PCI: 03:00.3
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia645380bea74f39fd94e2f9cbca3fcd4d18a878e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43354
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is some boilerplate required to iterate over the USB supported
protocol structs. Encapsulate all the in a method to make the callers
simpler.
BUG=b:154756391
TEST=Built test trembyle.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I401f10d242638b0000ba697573856d765333dca0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43352
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There's no generic way to tell whether a mainboard has an EC or not.
Making Kconfig symbols for these options seems overkill, too. So, just
put them on the devicetree. Also, drop unnecessary assignments when the
board's current value is zero, as the struct defaults to zero already.
Change-Id: If2ebac5fcab278c97dfaf8adc9d1e125888acafe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43129
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Current code only cares whether the PCH is LP or not. However, MRC wants
to differentiate between desktop and non-LP mobile platforms as well. As
the PCH is soldered onto the mainboard, add a facility to retrieve which
platform coreboot is running on by checking the PCH's LPC device ID. The
only user of the `pch_silicon_type` function is the `pch_is_lp` function
so replace the former with the new `get_pch_platform_type` function. The
function needs to be defined in both romstage and ramstage where PCI ops
have different signatures, hence the two copies.
Change-Id: Ib6276e0069eaa069a365faf6ae02dd934307d36c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43123
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This Kconfig symbol allows doubling the memory's refresh rate, assuming
that the MRC actually cares about it. It is disabled by default except
on the mainboards which explicitly enabled this setting in `pei_data`.
Change-Id: I6318dad0350d1c506c67f9d117d0ae8dad871281
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Several of these includes are no longer necessary. Get rid of them.
Since "raminit.h" already includes "pei_data.h", we can omit including
the latter for brevity's sake.
Change-Id: Ia7e9dadf87114ca9ea4761b89909ea035cdfc38a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43121
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All mainboards have a non-zero SPD address to implemented DIMM slots.
Knowing this, it is possible to compute the MRC slot population masks
automatically instead of hardcoding the values on each mainboard.
Change-Id: Ia8f369dd1228d53d64471e48700e870e01e77837
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43119
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These settings are the same on all boards. Since the other boards
currently overwrite the struct contents, it doesn't make a difference.
To ease review, the same settings will be dropped from other boards in
separate commits, one board at a time.
Change-Id: I500b7a1d7d97c6976e0c7c10ca491d3875cae22b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43109
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
The DxxIR (Device xx Interrupt Route) registers in RCBA are 16-bit wide,
so do not use 32-bit operations to program them.
Note that the DxxIP (Device xx Interrupt Pin) registers are 32-bit, so
using 32-bit operations on them is correct.
Change-Id: I9699b98d5fcd26b2c710bf018f16acc65dcb634e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Instead of using function pointers, we can use weak functions. So, drop
the pointer from `romstage_params`, leaving `pei_data` as the only
remaining member. This will be cleaned up in a follow-up commit.
Change-Id: I3b17d21ea7a650734119a5cab4892fcb158b589d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The current value of 0x1000 would overlap the first PCI bridge IO
window. As we commonly reserve IO range 0x0 .. 0x1000 for LPC and
integrated device use, change SMBUS_IO_BASE to 0x400. This is the
prevalent value among Intel southbridges, too.
Change-Id: I5c299f001f9012d6766b155a2f5def5cff6e88d1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43023
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This function is called at the end of `romstage_common`. Only one board
makes use of it, the Lenovo ThinkPad T440p. To preserve behavior, call
it after `romstage_common` has done nearly everything.
Change-Id: I35742879e737be4f383a0e36aecc6682fc9df058
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43094
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This provides the functionality to provide the GPE to the pci_xhci
driver.
BUG=b:154756391, b:160651028
TEST=Dump ACPI tables and verify GPE is set. Also dump SMI regs and
verify GPE is set. Resume using a USB keyboard.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ice7203831a1f65ed32f3a6392fe02c4b17d42617
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We can use xhci_for_each_ext_cap to inspect the xHC so we generate the
correct number of device nodes.
Scope (\_SB.PCI0.PBRA)
{
Device (XHC1)
{
Name (_ADR, 0x0000000000000004) // _ADR: Address
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x1F,
0x03
})
Device (RHUB)
{
Name (_ADR, Zero) // _ADR: Address
Device (HS01)
{
Name (_ADR, 0x01) // _ADR: Address
}
Device (HS02)
{
Name (_ADR, 0x02) // _ADR: Address
}
Device (SS01)
{
Name (_ADR, 0x03) // _ADR: Address
}
}
Name (_S0W, Zero) // _S0W: S0 Device Wake State
Name (_S3W, 0x04) // _S3W: S3 Device Wake State
Name (_S4W, 0x04) // _S4W: S4 Device Wake State
}
}
BUG=b:154756391
TEST=Boot trembyle and look at ACPI table. See all xHCI nodes.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I44ebaef342e45923bc181ceebef882358d33f0d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41900
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Data fabric devices are PCI devices which support PCI configuration
space but do not require any MMIO/IO resources. This change adds a PCI
driver for the data fabric devices which only provides device
operations for adding node to SSDT and returning the ACPI name for the
device.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3da9287db5febf1a1d7eb1dfbed9f1348f80a588
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds a driver pcie_gpp.c which provides device_operations
for external and internal PCIe GPP bridges. These device operations
include standard PCI bridge operations as well as operations for
generating ACPI node for the device and returning appropriate ACPI
name for it.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I9f8809c2735bdc09435deda91a570c89e71e8062
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's useful to see the stack when an exception happens so you can see
the variables on the stack, and also manually recreate the back trace.
If you need to recreate the back trace, you will need to add
-fno-omit-frame-pointer to the CFLAGS.
BUG=b:159081993
TEST=Caused an exception and saw the stack dumped. Then I manually
recreated the back trace.
0xcc6fff6c: 0xcc6ce02e <- 0xcc6ce02e is in dev_initialize
0xcc6fff68: 0xcc6fff88 <-- frame 1
0xcc6fff64: 0x00000005
0xcc6fff60: 0x000000dc
0xcc6fff5c: 0x00000000
0xcc6fff58: 0x00000200
0xcc6fff54: 0x00000000
0xcc6fff50: 0x00000400
0xcc6fff4c: 0xcc6d72d4 <- 0xcc6d72d4 is in setup_default_ebdad
0xcc6fff48: 0xcc6fff68 <-ebp
0xcc6fff44: 0x00000005
0xcc6fff40: 0xcc6f571c <-esp
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I3822ea7aa23202ecc98612850402eeb4b1f7b5ef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Zork devices shut down the i2c controllers in S3 to save power. On
resume, they need to be enabled in verstage before being accessed or
the system hangs.
BUG=b:160834101
TEST=Resume works with psp_verstage.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I7b8c7e12847876dab4ca74d67d3c41e63d7727cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43334
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When entering S3, zork shuts down the i2c controllers to save power.
On resume, we need to re-enable i2c before accessing them, so we need
to map the AOAC registers in verstage.
BUG=b:160834101
TEST=psp_verstage works after resume.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Ia8aa4923898a50f2202b6ca8434cee61a5918e91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43333
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sort them by stage execution order, then alphabetically. Place more
complex rules at the end.
Tested with BUILD_TIMELESS=1, Roda RK9 remains identical.
Change-Id: Ieadda7c264e0288a212b73febbe9f73351cc4de4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42649
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sort them by stage execution order, then alphabetically. Place more
complex rules at the end.
Tested with BUILD_TIMELESS=1, Intel DG43GT remains identical.
Change-Id: I1b36d6c0b2e615938272d65456cf10be54f66c38
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42648
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SMM_LOCK bit isn't in SMM_MASK_MSR, but in HWCR_MSR, so move it
there. The soc/amd/* code itself uses the bit definition when accessing
HWCR_MSR, so SMM_LOCK was just below the wrong MSR definition.
Also remove SMM_LOCK from comment about masking bits in SMM_MASK_MSR,
since that bit isn't in that MSR.
TEST=Checked the code and the corresponding BKDG/PPR.
Change-Id: I2df446f5a9e11e1e7c8d10256f3c2803b18f9088
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43309
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The kernel requires the display oprom is loaded and ran
in order for the kernel to not panic. Therefore, select the
correct settings such that normal mode works for Chrome OS.
BUG=b:160560510
TEST=Boot Trembyle in developer mode and normal mode
Change-Id: Ia6bcc99f8880a45818f959a957660c2c43b1bfdf
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The old values were completely out of whack. Use the same settings as
vendor firmware. The SUPERIO_NUVOTON_NCT6776_COM_A option overwrites
configured settings, so drop it from Kconfig to prevent conflicts.
Change-Id: I9743741518adc153d594ccae65298c7dcc8a88d1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Instead of passing around a pointer to an array, just write the relevant
registers directly. Note that intel/baskingridge used spaces to indent
line continuations and had to be replaced with tabs to quell Jenkins.
Change-Id: Ifa06a2ab24da9b8c6aac6480542fa32d04f6d6fe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch improves the image resampling (scaling) code in CBGFX to use
the Lanczos algorithm that is widely considered the "best" resampling
algorithm (e.g. also the first choice in Python's PIL library). It is of
course much more elaborate and therefore slower than bilinear
resampling, but a lot of the difference can be made up with
optimizations, and the resulting code was found to still produce
acceptable speeds for existing Chrome OS UI use cases (on an Arm
Cortex-A55 device, time to scale an image to 1101x593 went from ~88ms to
~275ms, a little over 3x slowdown). Nevertheless, if this should be too
slow for anyone there's also an option to tune it down a little, but
still much better than bilinear (same operation was ~170ms with this).
Example images (scaled up by a factor of 7):
Old (bilinear): https://i.imgur.com/ytr2n4Z.png
New (Lanczos a=3): https://i.imgur.com/f0vKluM.png
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idde6f61865bfac2801ee4fff40ac64e4ebddff1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42792
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
struct fraction is slooooooooooow. This patch adds a simple 64-bit
(32-bits integral, 32-bits fractional) fixed-point math API that is
*much* faster (observed roughly 5x speed-up) when doing intensive
graphics operations. It is optimized for speed over accuracy so some
operations may lose a bit more precision than expected, but overall it's
still plenty of bits for most use cases.
Also includes support for basic trigonometric functions with a small
lookup table.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id0f9c23980e36ce0ac0b7c5cd0bc66153bca1fd0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Remove I2C4 since it is a slave device used for USB-C mux control
and should not be included with the other master devices.
BUG=b:160624619 b:160292546
TEST=EC can communicate with AP mux I2C4 slave
Change-Id: Idaad618e90d6264d881dc66628cf581a856c231d
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43263
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds following two helper functions:
1. variant_uses_v3_schematics() - Check whether the variant is using
v3 version of schematics.
2. variant_has_active_low_wifi_power() - Check whether the variant is
using active low power enable for WiFi.
In addition to this, Kconfig options are reorganized to add two new
configs - VARIANT_SUPPORTS_PRE_V3_SCHEMATICS and
VARIANT_SUPPORTS_WIFI_POWER_ACTIVE_HIGH. This allows the helper
functions to return `true` early without checking for board version.
Eventually, when a variant decides to drop support for pre-v3
schematics, it can be dropped from selecting
VARIANT_SUPPORTS_PRE_V3_SCHEMATICS. Similarly, when the variant
decides to drop support for active high power enable for WiFi, it can
be dropped from selecting VARIANT_SUPPORTS_WIFI_POWER_ACTIVE_HIGH.
Change-Id: I62851299e8dd7929a8e1e9a287389abd71c7706c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43224
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Perform the same operations as the RCBA reg script did, but directly
writing the corresponding registers. Some of these operations could be
simplified, but it is not done on this commit to ease verification.
Change-Id: I4c3177ab14ca9bfa2e8d11c27fb249850183eee5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
The "normalized" boot mode is only used in a single place, so there's no
need to use a variable. Also, reword the associated comment, which seems
to be unnecessarily vague: the hardcoded assumptions are inside the MRC.
Change-Id: I260d10f231f5de765d2675416d7047717d391d8f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Use C-style comments, drop unneeded newlines, add missing commas for
consistency and relocate a comment to match the code.
Tested with BUILD_TIMELESS=1, Getac P470 remains identical.
Change-Id: I37fffb60944c35dfb5e0491bb023babfcf2c6a73
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43177
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use C-style comments, drop an unneeded newline, add missing commas for
consistency and relocate a comment to match the code.
Tested with BUILD_TIMELESS=1, Roda RK9 does not change.
Change-Id: I3f91d1b57eb5530c8adcf5f682e73747435f0d47
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43172
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The timestamp functionality is not yet added for psp_verstage, so
temporarily remove it until that's completed. That work is being
tracked by bug 154142138.
BUG=b:154142138
TEST=Build & Boot psp_verstage on trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I020619e3615ce92dedbe868104d2bfd83cb7caa9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42381
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The AMD firmware package created by amdfwtool contains pointers to the
various binaries and settings. When these are moved to the RW-A & RW-B
regions, the packages need to be recreated for the new addresses.
TEST=Build & boot trembyle. See that we're booting from the correct
region.
BUG=b:158124527
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I0d50968b6ab4b3ab51f8c9bc66c56e141ef728ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The AMD firmware package created by amdfwtool contains pointers to the
various binaries and settings. This means that we need different copies
of the package in each region.
This change allows for the different files in each of the 3 vboot
regions.
BUG=b:158124527
TEST=Build trembyle; see the correct versions of the files getting
built into the RW-A & RW-B regions.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I45ff69dbc2266a67e05597bbe721fbf95cf41777
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This is the main code for building coreboot's verstage as a userspace
application to run on the PSP. It does a minimal setup of hardware,
then runs verstage_main. It uses hardware hashing to increase the speed
and will directly reboot into recovery mode if there are any failures.
BUG=b:158124527
TEST=Build & boot trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ia58839caa5bfbae0408702ee8d02ef482f2861c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
It already looks for them, so let's use the result instead
of blindly defaulting to gcc/g++, except when not building an image
(but run kconfig or tests) because we don't use xcompile in those cases.
Change-Id: I3e50c70a609f1903a925610928f8779c191040d8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43145
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
If there's a host compiler in XGCCPATH, it's likely the same
relatively-current version we use for coreboot, and it's a well-known
quantity, so let's prefer that over alternatives by default.
In addition, look for the C++ host compiler as well.
Change-Id: If50341df169a476899b5a5ffd4c4fb6d21c3f4ac
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43144
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable long mode in SMM handler.
x86_32 isn't affected by this change.
As the rsm instruction used to leave SMM doesn't restore MSR registers,
drop back to protected mode after running the smi_handler and restore
IA32_EFER MSR (which enables long mode support) to previous value.
NOTE: This commit does NOT introduce a new security model. It uses the
same page tables as the remaining firmware does.
This can be a security risk if someone is able to manipulate the
page tables stored in ROM at runtime. USE FOR TESTING ONLY!
Tested on Qemu Q35.
Change-Id: I8bba4af4688c723fc079ae905dac95f57ea956f8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35681
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The host bridge register definitions haven't changed from Sandy Bridge
to Haswell, according to the datasheets. However, coreboot's ACPI code
is not the same. Looks like Haswell values are wrong, so correct them.
Change-Id: Ib099575b5cc5e7d468db51f382a15b8aac3eedea
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
No other architecture in libpayload outputs anything in the main entry
routine. Let alone an exception test which looks like a real exception
to the normal user and is most likely really misleading. Silence the
startup code.
Change-Id: I6e49f24ad46ce578a4bb111c2d623ca4470a1866
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43126
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add VPD variables for enabling/disabling FRB2 watchdog timer and setting
the timer countdown value. By default it would start the timer and
trigger hard reset when it's expired. The timer is expected to be
stopped later by payload or OS.
Tested on OCP Delta Lake.
Change-Id: I3ce3bdc24a41d27eb1877655b3148ba02f7f5497
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
The tlbimvaa operation (invalidate unified TLB by MVA, all address
space identifiers) is only available on armv7 processors that support
Multiprocessing Extensions. When used on processors that do not support
the extensions it causes an "undefined instruction" exception.
This patch changes the MMU table entry filling code to use the tlbimva
(invalidate unified TLB entry by MVA and address space identifier)
operation for invalidating TLB entries, which is supported on all armv7
processors.
As address space identifiers are not used in TLB entries in coreboot
(all entries are set as global), these two operations can safely be
used interchangeably. The ASID value supplied to the operation is not
checked for global TLB entries.
More information as well as the data formats for the tlbimvaa and
tlbimva operations are detailed in the "ARM Architecture Reference
Manual ARMv7-A" edition, issue "C.c" page B4-1747.
TEST: Booted Beaglebone Black (my current in progress port)
Change-Id: Ie7dfb4adab20dc7eecb1b20aa2ee6355215a1521
Signed-off-by: Sam Lewis <sam.vr.lewis@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
ec_fill_dptf_helpers() is used to generate all of the "helper" methods
that DPTF requires. A system with a Chrome EC is typically in charge
of fan PWM control as well as battery charging, so if DPTF needs to
manipulate those, then it requires Methods provided by the EC.
BUG=b:143539650
TEST=compiles
Change-Id: Ib30072d1d0748b31bcab240a0fd0e2f12d34aaa4
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41894
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When converting to override trees in commit c1dc2d5e68 (mb/lenovo/t60:
Switch to override tree), some device nodes were missed. These are
essential, as `chip` configuration data is always tied to device
nodes. The resulting `static.c` contained multiple copies of the
`chip` configuration structs, but the wrong ones were hooked up.
The therefore missing configuration of the clock gen led to general
instability, especially with SMP under Linux (probably due to the
attempt to enter lower C states on an idle core). Passing `maxcpus=1`
to the Linux kernel served as a workaround.
Change-Id: I6c26d633d1860cf9a5415994444e75ae1c2e59ad
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43150
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change disables Thunderbolt PCIe root ports bus master before
handing over to payload in order to mitigate the threat from the
unauthorized external DMA. In this state, the PCIe root ports would
be considered as trusted to not forward any DMA transactions to
downstream endpoint devices.
BUG=b:141609884
TEST=Verified PCIe resource has been allocated properly and USB behind
Thunderbolt dock is enumerated successfully.
Change-Id: I9650b9dd4df1f9bee53ae3737b7bf60b2ef8017b
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
At this moment, Vilboz board version is 1 and it
according to v3+ schematics, however WiFi power enable
is active high. This change sets
VARIANT_MIN_BOARD_ID_V3_SCHEMATICS for Vilboz as 1
and VARIANT_MIN_BOARD_ID_WIFI_POWER_ACTIVE_LOW as 2.
BUG=b:160547115
BRANCH=None
TEST=flash the bios to vilboz DUT and test WIFI module
Signed-off-by: peichao.wang <peichao.wang@bitland.corp-partner.google.com>
Change-Id: I9699bb839a801ab7d14c38b971ec28e3a322a997
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Two usb Type-C ports under the actual mux device. Each port has its own
ACPI device entry. These nodes are the ones that the USB Type-C
port/connector device will refer to in order to configure the mux.
TEST=Verified the scope of PMC.MUX CONx in the SSDT on Tigerlake RVP
board.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I7210e00cebe16a5fb8417ac23abad98e574e0982
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42953
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Volteer world-facing camera has a privacy LED and it is supposed
to be turned on only when the camera is being used. But the LED
is always on and this is to fix the issue.
RCAM_SNR_PWR_EN (RearCAMera_SeNsoR_PoWeR_ENable) GPIO, which
controls the world-facing camera LED, was not in the power-up
and power-down sequence definitions and this caused the issue.
BUG=b:160341981
BRANCH=none
TEST=Build and boot volteer proto 2 board. Start a camera app
and check the world-facing camera LED is only turned on only when
the camera is working.
Signed-off-by: Daniel Kang <daniel.h.kang@intel.com>
Change-Id: I564690baffddfdd0f998525992643aaf16ba4b02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42985
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Daniel H Kang <daniel.h.kang@intel.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
\_SB.DPTF.IDSP adverties to the DPTF daemon which policies the
implementation supports. Added a new acpigen function to figure out
which policies are used, and fills out IDSP appropriately.
Change-Id: Idf67a23bf38de4481c02f98ffb27afb8ca2d1b7b
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
DPTF has several options on how to control the fan (fine-grained speed
control, minimum speed change in percentage points, and whether or not
the DPTF device should notify the Fan if it detects low speed).
Individual TSRs can also set GTSH, which is the amount of hysteresis
inherent in the measurement, either from circuitry (if analog), or in
firmware (if digital).
BUG=b:143539650
TEST=compiles
Change-Id: I42d789d877da28c163e394d7de5fb1ff339264eb
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41891
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change adds support for emitting the PPCC table, which describes
the ranges available as knobs for DPTF to tune. It can support min/max
power, min/max time window for averaging, and the minimum adjustment size
(granularity or step size) of each power limit. The current implementation
only supports PL1 and PL2.
BUG=b:143539650
TEST=compiles
Change-Id: I67e80d661ea5bb79980ef285eca40c9a4b0f1849
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41890
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change adds support for generating the _FPS table for the DPTF Fan
object. The table describes different levels of fan activity that may be
applied to the system in order to actively cool it. The information
includes fan speed at a (rough) percentage level, fan speed in RPM,
potential noise level in centibels, and power in mA.
BUG=b:143539650
TEST=compiles
Change-Id: I5591eb527f496d0c4c613352d2a87625d47d9273
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41889
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change generates the DPTF TCHG.PPSS table in the SSDT. This table
describes different charging rates which are available to use. DPTF
can pick different rates in order to passively cool (or not) the
system.
BUG=b:143539650
TEST=compiles
Change-Id: I6df6bfbac628fa4e4d313e38b8e6c53fce70a7f2
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds support for DPTF Critical Policies, which are consist
of Method definitions only. They are `_CRT` and `_HOT`, which are
defined as temperature thresholds that, when exceeded, will execute a
graceful suspend or a graceful shutdown, respectively.
BUG=b:143539650
TEST=compiles
Change-Id: I711ecdcf17ae8f6e653f33069201da4515ace85e
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41887
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds support for emitting the Thermal Relationship Table, as
well as _PSV Methods, which together form the basis for DPTF Passive
Policies.
BUG=b:143539650
TEST=compiles
Change-Id: I82e1c9022999b0a2a733aa6cd9c98a850e6f5408
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In this DPTF implementation, the participant device objects are written
into the DSDT with only minimal Names attached (_HID/_ADR, _STA, _UID,
PTYP, and _STR). All other Methods & Names will be written into the
SSDT. If a device is not used in any policy, then its _STA is set to
return 0 ("off").
BUG=b:143539650
TEST=Compiles.
Change-Id: Ief69a57adce9ee0b19056ce6a11ed8a5b51b3f87
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Based on schematic and gpio table of terrador, generate gpio settings
and overridetree.cb for terrador.
BUG=b:156435028,b:151978872
TEST=FW_NAME=terrador emerge-volteer coreboot chromeos-bootimage
Verify that the image-terrador.bin is generated successfully.
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Change-Id: I4bf9081b034bc4cd566dde45586be8309cdbb4a3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42302
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds memory parts used by variant terrador to
mem_list_variant.txt and generates DRAM IDs allocated to these parts.
Added memory
1. MT53E512M64D4NW-046 WT:E
2. MT53E1G64D8NW-046 WT:E
BUG=b:159195585,b:152936481,b:156435028
TEST="emerge-volteer coreboot chromeos-bootimage", flash terrador and
verify terrador boots to kernel.
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Change-Id: Ia14f76e9cb0df64961d46f4b61b39439e56f6a8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41995
Reviewed-by: Zhuohao Lee <zhuohao@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `ENABLE_SMBUS_METHODS` symbol is not defined anywhere, so this code
isn't even being tested. So, throw it into the bitbucket before it rots
any further. If anyone needs that code ever again, it's in git history.
Change-Id: I22e3f1ad54e81f811c9660d54f3765f3c6b83f01
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Enable HotPlug for the PCIe root port that the SD express is on so the
OS can re-train the link without needing a reboot if it goes down
unexpectedly at runtime.
BUG=b:156879564
BRANCH=master
TEST=enable HotPlug on Volteer Root Port 7 (SD express) and check in
linux that it is identified as a HotPlug capable root port
Signed-off-by: Nick Chen <nick_xr_chen@wistron.corp-partner.google.com>
Change-Id: Ie9d427dd297567f06123119a670b5ed2e1f73701
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42897
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A regression sneaked in with 18a8ba41cc (arch/x86: Remove RELOCATABLE_
RAMSTAGE). We want to call load_relocatable_ramstage() on x86, and
cbfs_prog_stage_load() on other architectures. But with the current
code the latter is also called on x86 if the former succeeded. Fix
that and also balance the if structure to make it more obvious.
TEST=qemu-system-x86_64 boots to payload again.
Change-Id: I5b1db5aac772b9b3a388a1a8ae490fa627334320
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43142
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PS/2 keyboard and mouse devices are declared twice in the DSDT, once
in mainboard and once in southbridge. It would appear in Windows
Device Manager as two PS/2 keyboards and two PS/2 mouses, all with
resource conflicts. This change drops the declaration from mainboard.
The issue was discovered when this setup was copied for p8z77-m and
being boot tested.
Change-Id: I746a960aaf3992acbcb6a7364641fc4fd12002d2
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41225
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As the booting the system can be delayed for a noticeable amount of
time, often 60 seconds is the default, this is not a debug message.
Chose log level BIOS_INFO.
Change-Id: I941792148820c0e1d3fbc80197125fee8cedf09f
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Based on schematic and gpio table of voxel, generate gpio settings
and overridetree.cb for voxel.
BUG=b:157879197,b:155062762
TEST=FW_NAME=voxel emerge-volteer coreboot chromeos-bootimage
Verify that the image-voxel.bin is generated successfully.
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Change-Id: I49c1923e63d87f11de362fd893905ac2f1137bba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
log2(1) is 0 and log2(0) is -1. If we have the int64_t 0xffffffff then
log2(0xffffffff >> 31) = log2(0x1) = 0, so the current reduction code
would not shift. That's a bad idea, though, since 0xffffffff when
interpreted as an int32_t would become a negative number.
We need to always shift one more than the current code does to get a
safe reduction. This also means we can get rid of another compare/branch
since -1 is the smallest result log2() can return, so the shift can no
longer go negative now.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib1eb6364c35c26924804261c02171139cdbd1034
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The USB-C SBU and HSL orientation configuration depends on the USB
daughterboard used on the system. This patch adds an additional
configuration for supporting passive USB daughterboards using "probe"
directives to select the appropriate configuration at runtime.
BUG=b:158673460
TEST=verified active USB DBs enumerate at USB3 speeds in linux
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Change-Id: Ia4bd97de8f974531f97469a5e47ecf4d948beca9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Upcoming builds of boten will use 16 MiB SPI ROM. So create a legacy
Boten variant to support the builds that use 32 MiB SPI ROM.
BUG=None
TEST=Build the boten and boten_legacy variant.
Cq-Depend: TBD
Change-Id: Idf7732768aa7fbf2281a4cbf47b7b5b4f8ef51da
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Upcoming builds of drawcia will use 16 MiB SPI ROM. So create a legacy
Drawcia variant to support the builds that use 32 MiB SPI ROM.
BUG=None
TEST=Build the drawcia and drawcia_legacy variant.
Cq-Depend: TBD
Change-Id: Ifb5a4778abe38a396e35963a3270b0d3cc9809e0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42960
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Since coreboot is initializing uart for debug logs, fsp should not reinitialize it.
Thus we need to set FSP UPD to skip Uart init in FSP and use settings done by coreboot
BUG=None
BRANCH=None
TEST=FSP is able to push debug logs on UART with this setting
Cq-Depend: TBD
Change-Id: I0fda2ace3b1f63159e9809d6a3044a3bad452f07
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Skip sending MboxBiosCmdSxInfo for sleep states other than S3. The
PSP only acts on S3 and ignores all others. As a result, the command
register is not cleared upon return and coreboot reports a timeout.
BUG=b:153622879
TEST=Use halt from command line, verify command skipped.
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: Ic47b8507e29e4c53898e88fb46e532b71df87d07
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change drops the check for ENV_RAMSTAGE in mainboard_ec_init()
since it is included only in ramstage. Also, the content of
ramstage_ec_init() is moved into mainboard_ec_init().
Change-Id: I282fb07a80f4de6064a544f6dd58e8f973a597b9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43118
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
mainboard_ec_init() does nothing in any stage other than ramstage. So,
this change drops the call to mainboard_ec_init() from
romstage.c. Additionally, it also drops ec.c from romstage and
verstage.
Change-Id: Iae0be4d678b0780cf532000a6c0fff1bce333c0e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43117
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change drops the inclusion of codec.asl in DSDT for `GOOG0013`
device and instead uses the newly added Chrome EC audio codec driver
for filling in the device node in SSDT.
TEST=Verified that following node gets generated:
Scope (\_SB.PCI0.LPCB.EC0.CREC)
{
Device (ECA0)
{
Name (_HID, "GOOG0013") // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_DDN, "Cros EC audio codec") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
}
Change-Id: I3e626ce01a3735ac2c966c0e95310be4c828b241
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43042
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds driver for audio codec device (HID `GOOG0013`) living
behind Chrome EC. This driver generates the required ACPI node for the
codec device. In a later change, GOOG0013 device will be dropped
the .asl file.
Change-Id: Ib2759eac60265ef81df70af1d4f1f72bd9d987e8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43041
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With devicetree listing drivers/pc80/tpm, it is compulsory
to have the corresponding driver included in the build.
Followup work will drop the associated weak function
declaration that util/sconfig currently generates.
Change-Id: Ife8deb2c973ab7c7b820244b6f72efd3b56570ae
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43047
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For historical reasons, Windows has issues with certain names being
used for files and directories, 'con' or 'CON' being one of
them. Therefore, rename the pmc_mux/con driver to pmc_mux/conn in
order to work around this issue.
TEST=built volteer (only user of this driver as of now)
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ia78dc4efe647c96a7169a3b95fc3b8944d052c83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Fix a typo to use CONFIG_DISPLAY_HOBS instead of CONFIG_DISPLAY_HOB.
Build hob display into romstage, in addition to ramstage.
Memory map HOB data is a big structure. Update the soc_display_memmap_hob()
to assist trouble shooting of FSP interface.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Iece745fe21d11b4a470ba8318201bb6e68c5da26
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42841
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new LB_TAG_PLATFORM_BLOB_VERSION for FSP version, it would
add Intel FSP version to coreboot table LB_TAG_PLATFORM_BLOB_VERSION
when PLATFORM_USES_FSP2_0 is selected.
Tested=On OCP Delta Lake, with an updated LinuxBoot payload cbmem utility
can see "LB_TAG_PLATFORM_BLOB_VERSION": "2.1-0.0.1.120"
Change-Id: I92a13ca91b9f66a7517cfd6784f3f692ff34e765
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41809
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
These changes are in accordance with the documentation:
[*] page 208-209
Intel(R) 64 and IA-32 Architectures, Software Developer’s Manual,
Volume 4: Model-Specific Registers. May 2019.
Order Number: 335592-070US
Tested on OCP Tioga Pass and Delta Lake.
Change-Id: I8c2eac055a065c06859a3cb7b48ed59f15ae2fc4
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42901
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's necessary to run IPMI commands in romstage for writing error SEL
such as memory initialization error SEL, and also for other usages
such as starting FRB2 timer, OEM commands, etc.
Add CONFIG_BMC_KCS_BASE for BMC KCS port address that can be used
across romstage and ramstage.
Change-Id: Ie3198965670454b123e570f9056673fdf515f52b
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40234
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A UPD HybridStorageMode allows a platform to dynamically configure the
PCIe strap configuration required if an Optane device is connected.
The strap configuration is done by HECI commands between FSP and CSE to
override the default PCIe strap value, and the updated strap value is
stored in SPI RW data to be used on the next boot.
CSE Lite supports the strap override when running on CSE RW partition,
while CSE RO partition does not support it because CSE RO is not allowed
to access SPI RW data. The strap override failure on CSE RO causes FSP
not initializing PCH Clkreq and PCIe port mapping and this results NVMe
and Optane initialization failure.
By disabling HybridStorageMode in case of CSE RO boot, NVMe detection is
done by the default PCIe configuration and Optane is detected as a
single NVMe storage device on CSE RO boot in recovery mode. Both NVMe
and Optane devices detection as well as OS installation to these storage
devices are verified on CSE RO boot in recovery mode.
BUG=b:158643194
TEST=boot and verified with tglrvp and volteer in recovery mode
Cq-Depend: chrome-internal:3100721
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Change-Id: I5397cfc007069debe3701bf1e38e81bd17a29f0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42282
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The eSPI polarity macros were reversed. Those are fixed so adjust
the corresponding values related to the correct expectations of
the IRQ path: eSPI virtual wire IRQs are active level high. The EC
sends active level high virtual wire IRQs. The default interrupt
encodings in ACPI for P2/S devices are active edge high. Therefore,
there is no need to override anything.
BUG=b:157984427
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia28d82cd9e432df98839f68bac4eae4447455e53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
eSPI interrupts are active level high. The eSPI polarity register
in the chipset inverts incoming signals if the corresonding bit
is 0 in the register. Therefore, all active high (edge or level)
virtual wire interrupts need to ensure they are not inverted.
And really the sender of the interrupts should be conforming to the
the eSPI spec. As such inverting any signals should not be necessary,
but this register in the chipset allows for fixing up those misbehaviors.
BUG=b:157984427
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7346bb0484506d96d7ab2e6d046ffa0571683a48
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Originally, there was problem with PC Engines apu1 platform
which returned serial number value as -64. It was caused by wrong
value of dev->bus->secondary.
Source of the problem is in Porting.h header file. It contains
'#pragma pack(1)' which affects struct device. As mainboard.c
uses different binary layout because of this attribute,
reference dev->bus->secondary lands at wrong memory address.
This patch reorder includes and put <AGESA.h> and <AMD.h>
at the end of list, making struct device consistent.
As a result bus number value in device's structure is correct
and hence serial number.
TEST=`dmidecode -t 2` command in Linux Debian
Signed-off-by: Piotr Kleinschmidt <piotr.kleinschmidt@3mdeb.com>
Change-Id: I5e8690d100b38ac7889395d375c0ff32bdefda0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42512
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reflow lines, correct coding style and align struct members, among
other things. As raminit is very large, handle it on a follow-up.
Tested with BUILD_TIMELESS=1, packardbell/ms2290 does not change.
Change-Id: I343edf1bc2a5ac20ff0aa6de4486e685ce430737
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42701
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the generation of I2SM ACPI device from static asl
file to runtime generation by ACP device driver. dmic_select_gpio is
set to match version 3+ of Trembyle and Dalboz schematics. In order to
maintain backward compatibility, dmic_select_gpio is updated at
runtime using variant_audio_update for board versions that are prior
to version 3 of reference schematics.
The only difference from static generation is that the device I2SM is
added under ACPD (i.e. ACP device) instead of CREC (Chrome EC
device). It does not make any functional difference from the kernel
perspective.
BUG=b:157603026
TEST=Verified that the following device gets generated in SSDT:
Scope (\_SB.PCI0.PBRA.ACPD)
{
Device (I2SM)
{
Name (_HID, "AMDI5682") // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_DDN, "I2S machine driver") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x000D
}
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"dmic-gpios",
Package (0x04)
{
\_SB.PCI0.PBRA.ACPD.I2SM,
Zero,
Zero,
Zero
}
}
}
})
}
}
Verified audio via speakers and mic input.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I5d1602c7f719eef9487ddea68e429d27408f9a76
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2253638
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As per ACPI spec, GpioIo does not have any polarity associated with
it. Linux kernel uses `active_low` argument within GPIO _DSD property
to allow BIOS to indicate if the corresponding GPIO should be treated
as active low. Thus, if GPIO has active high polarity or if it does
not have any polarity associated with it, then the `active_low`
argument is supposed to be set to 0.
Having a `polarity` field in acpi_gpio seems confusing because GPIOs
might not always have polarity associated with them. Example, in case
of DMIC-select GPIO where 0 means select DMIC0 and 1 means select
DMIC1, there is no polarity associated with the GPIO. Thus, it would
be clearer for mainboard to use macros without having to specify a
particular polarity. In order to enable mainboards to provide GPIO
information without polarity for GpioIo usage, this change also adds
`ACPI_GPIO_OUTPUT` and `ACPI_GPIO_INPUT` macros.
BUG=b:157603026
Change-Id: I39d2a6ac8f149a74afeb915812fece86c9b9ad93
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds helper macros for initializing acpi_gpio fields
for GpioIo/GpioInt objects. This allows dropping some redundant code
for each macro to set the structure fields.
Change-Id: Id0a655468759ed3035c6c1e8770e37f1275e344e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42967
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Proposal for gpio_regulator usage in ACPI never got accepted upstream
for Linux kernel. So, the gpio_regulator driver in coreboot remains
unused. This change drops this unused driver.
Change-Id: Ia1e0ae4f955b9ffc8346d957f755499419d8cbc7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ACPI code was not masking off the correct bits for publishing
the SPI bar to the OS.
It resulted in a dmesg messagelike:
system 00:00: [mem 0xfec10002-0xfec11001] has been reserved
And /proc/iomem entry
fec10002-fec11001 : pnp 00:00
These addresses are wrong because they are including bits of a
register that are not a part of the address.
Moreover, the code does not publish the eSPI register area either.
The eSPI registers live at 0x10000 added to the SPI bar. Lastly,
both regions are less than a page so only report a page of usage
for each.
Stoney Ridge's SPI bar register defines the address as 31:6 while
Picasso's SPI bar register defines the address as 31:8. Use Picasso's
valid mask for both cases because no one is assigning addresses
that are aligned to less than 256 bytes.
With the fixes, dmesg reports:
system 00:00: [mem 0xfec10000-0xfec10fff] has been reserved
system 00:00: [mem 0xfec20000-0xfec20fff] has been reserved
And /proc/iomem indicates:
fec10000-fec10fff : pnp 00:00
fec20000-fec20fff : pnp 00:00
BUG=b:160290629
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I130b5ad26d9e13b44c25fbb35a05389f9e8841ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42959
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Add support for Sphinx 3.0+
* Add backward support for Sphinx 1.8 and older
* Make sphinxcontrib ditaa an optional extension
* Allow SPHINXOPTS to be set from command line
* Add sphinx and sphinx-lint to top level Makefile
Change-Id: If10aef51dc426445cb742aad13b19ee7fe169c51
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41492
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, EC wake signal (GPIO_24) is configured early on in
romstage. However, there is no need for that since EC wake is not
really required to be configured until ramstage. This change moves
GPIO_24 configuration to happen in ramstage.
BUG=b:159832123
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I6949dcd7c866df2fa028c7b2e7f347cec988e309
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42952
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates the pad configurations for wake lines as
follows:
1. Pen eject wake signal needs to be configured as PAD_WAKE i.e. wake
using GPIO controller block. This is because pen eject signal is not
dual routed and the trigger filtering is set by the kernel driver
differently for S0 and S3 wake. Hence, it cannot use SCI GEVENT and
instead has to fall back to using GPIO controller wake.
2. All other wake signals (EC, trackpad, fingerprint) need to be
configured as SCI. This allows OS to enable/disable wake from these
sources if required. Example: powerd disables wake from trackpad when
in tablet mode. Hence, all other wake sources use SCI.
BUG=b:159832123
TEST=Verified wake using pen eject and EC.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id8cd5926f223db51a689ed8948040b8070cf1680
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42951
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, northbridge BARs are 32-bit values. We don't have any use
case for BARs above 4 GiB in early stages, so handling possibly 64-bit
values seems unnecessary, which currently is a noisy way to write zero.
Tested with BUILD_TIMELESS=1, packardbell/ms2290 remains identical.
Change-Id: I93d1740b961f6a5962757d9a1e960b3f1014a0c6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This function was copy-pasted, comments included, from Sandy Bridge.
However, it is only called with 0x0044 as the northbridge's PCI ID.
Therefore, `bridge_silicon_revision() & BASE_REV_MASK` will always
evaluate to 0x40, which never equals `BASE_REV_SNB`, that is, 0x00.
As the condition is always false, treat this code as dead and drop it.
Following a similar reasoning, all direct comparisons against SNB
steppings will always be true, because `bridge_silicon_revision()`
returns at least 0x40 which is always larger than either `SNB_STEP_D0`
or `SNB_STEP_D1`. So, drop all but the code path that is actually used.
Change-Id: I5219a6af3df98ed77c9c4abfb9a63c2ebf8171bb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When building a configuration that requires futility (e.g. Chrome OS
builds), pkg-config and libcrypto are required. Since vboot's build
system isn't the most helpful about it, test ourselves and fail out
with some actionable message.
Tested:
- configs that don't need futility don't test for pkg-config, so it's
not required for them.
- failing pkg-config test leads to the message
- working pkg-config test leads to a successful build
Fixes https://ticket.coreboot.org/issues/242
Change-Id: I103ce5115284352e0a3a7fdcf8b427f56ce15ba7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Vboot determines openssl through pkgconfig, so pointing its build
system to /bin/true makes the build not break unless it needs to use
valid information about openssl.
Vboot's use of openssl is only for some special features, mostly around
PKCS key format parsing and not needed by cbfstool. While cbfstool
can link vboot, it can't link with openssl because openssl's license
is deliberately incompatible with the GPL.
Change-Id: Ia3825f9625a1964d7cefc47ab3c3a8250ceefafb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
A late change went into v3+ of reference schematics which inverted
EN_PWR_WIFI to meet PCIe reset/power timings for WiFi device. This is
incorporated into v3.51+ for Trembyle reference and v3.2+ for Dalboz
reference. However, some variants are built with v3+ reference
schematics, but without the inversion of EN_PWR_WIFI polarity. Thus,
we need to add support for following combinations:
1. Pre-v3 Schematics
2. V3+ Schematics
3. V3+ Schematics + Active low wifi power
This change adds a new Kconfig
`VARIANT_MIN_BOARD_ID_WIFI_POWER_ACTIVE_LOW` that sets the minimum
board ID that has EN_PWR_WIFI active low in hardware. Variants that
missed this change in V3+ integration (berknip and vilboz) have board
IDs set to VARIANT_MIN_BOARD_ID_V3_SCHEMATICS + 1. For others, this
defaults to VARIANT_MIN_BOARD_ID_V3_SCHEMATICS.
BUG=b:159749536
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib8da7fba5f4a518a51b203d6a01a9551e261d8b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change moves variant_sleep_gpio_table() definition to dalboz and
trembyle references to allow each to make their own changes.
BUG=b:159749536, b:159453643
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I15b19cea05f1a540c56b6bc0507306d2348ac17f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change moves PCIE_RST1_L deassertion to happen as part of
variant_pcie_power_reset_configure() instead of
variant_romstage_entry() since romstage is guaranteed to run 100ms+
after PP3300_NVME is enabled. This is one of the first things that
coreboot on x86 does as part of early mainboard configuration.
Additionally, this change also drops deassertion of PCIE_RST0_L on bid
1 for dalboz since PCIE_RST0_L is already deasserted much earlier in
the boot flow.
BUG=b:152582706
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib734aa6ff664268e68388b1997ddce676504f8d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2261996
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit-Queue: Aaron Durbin <adurbin@google.com>
Tested-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change configures PCIE_RST1_L as GPO driven low on the sleep
path. This is required to keep PERST# asserted to devices until
coreboot deasserts it on S3 resume path. Without this change, on S3
resume, PCIE_RST1_L gets deasserted sooner than required resulting in
violation of PCIe reset timings.
With this change, the behavior of PCIE_RST1_L is as follows:
1. GPIO27 is configured as NF (PCIE_RST1_L) in coreboot
bootblock/romstage and driven high.
2. On S3 entry, GPIO27 is configured as GPO driven low.
* Boot out of G3: Timing should be met since GPIO_27 is pulled down by
default until coreboot configures it.
* S3 resume: Timing should be met since GPIO_27 is configured as GPO
low and it retains state across S3 entry/exit. So, should be low
until coreboot configures it.
* Warm reset: Timing should be met since it is configured as NF. So,
hardware guarantees the reset timing as seen in "warm reset.jpg" in
#46.
BUG=b:152582706
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia0ad1522edc438fd054d927ef4a2ab5c27329c00
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2261116
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a W/A to avoid a communication issue with CSE Lite over Heci
interface. This will help to avoid boot failures with CSE Lite until
the permanent fix is available.
BUG=b:159884143
TEST=build and boot volteer with serial and non-serial image
Change-Id: Ib136a2154b36c63c7147bbcfbf1ca7beac3a5685
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42790
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update fixes build issues with host GCC 10.
Other changes:
https://acpica.org/node/177https://acpica.org/node/178https://acpica.org/node/179https://acpica.org/node/181
acpinames utility removed:
"Removed support for the acpinames utility. The acpinames was a simple
utility used to populate and display the ACPI namespace without executing
any AML code. However, ACPICA now supports executable opcodes outside of
control methods. This means that executable AML opcodes such as If and
Store opcodes need to be executed during table load. Therefore, acpinames
would need to be updated to match the same behavior as the acpiexec
utility and since acpiexec can already dump the entire namespace (via the
'namespace' command), we no longer have the need to maintain acpinames."
Change-Id: Ibd995561ca53458b04f87cee5693850c0d90d3d6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38907
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
in some m/b+BOE panel(G2 TS), G2 TS may still have chance to lost even
rst delay time already meets spec definition: 10us (minimum).
Restore G2 TS RST delay time to 50ms, we could have G2 TS working fine
on those specific m/b+BOE(G2 TS) panel.
BUG=b:159510906
BRANCH=master
TEST=emerge-zork coreboot
boot with G2 TS, make sure G2 TS is functional
Change-Id: Ic629c6c61572ab564def8893ce8d78dfb37d4590
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change adds Platform-Wide _OSC capabilities for native USB4
support. There is Engineering Change Request (ECR) with _OSC addition
for OSPM USB support. ACPI section 6.2.11.1.13 is modified with bit 18
as native USB4 support. The OS sets this bit to indicate support for
an OSPM-native USB4 Connection Manager which handles USB4 connection
events and link management. The OS use the _OSC mechanism and the bit
defined in this ECR to obtain configuration and connection management
capabilities of USB4 connections. This change also fixs the byte index
for the DWord-addressable field CDW3 from the capabilities buffer.
BUG=b:140645231
TEST=Check Type C device all ports connection/enumeration with SW CM.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I1b561ea5a0a6b440cca3152cc150f31abf7766ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42821
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
due to overridetree.cb set disable_xhci_lfps_pm = 0,
need correct condition expression to let function work.
BUG=b:155955302
BRANCH=octopus
TEST=build coreboot with DisableXhciLfpsPM being set to 1 and flash
the image to the device. Run following command to check if
bits[7:4] is set 0:
>iotools mmio_read32 "XHCI MMIO BAR + 0x80A4"
Signed-off-by: Kenneth Chan <kenneth.chan@quanta.corp-partner.google.com>
Change-Id: Ia047c75611a35aafd15f2481bf64049e13d4a2ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42860
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Henry Sun <henrysun@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current implementation of acpi_dp_write() frees the node after it
has written it.
If the structure contains a ACPI_DP_TYPE_CHILD then a recursive call to
acpi_dp_write() frees the child and then frees it again when returning
from the call. This results in a double free.
Split the implementation into two steps, one that ones and one that
frees. This is easier to understand and fixes the bug.
Note: This likely has no effect in coreboot since it doesn't seem to
have a proper free() implementation. But it might gain one one day.
BUG=none
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: Ife3917af10bc35a3c3eee38d8292f927ef15409d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42892
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change clears interrupt and wake status for a pad when
configuring it. This ensures that stale interrupts/wake notifications
are flushed out and do not cause spurious wakes in future suspends.
BUG=b:159944426
Change-Id: Ia4ebd975312a4136f1d0690d7af7372615e31f0f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42877
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`flags` field of soc_amd_gpio structure is set only for SCI and SMI
configurations. This change adds a new helper macro
PAD_CFG_STRUCT_FLAGS that allows setting of all soc_amd_gpio members
including `flags` field. This can be used directly by PAD_SCI and
PAD_SMI. For all other pad configurations, PAD_CFG_STRUCT macro uses
PAD_CFG_STRUCT_FLAGS with flags set to 0. This allows dropping of
redundant parameter 0 for flags for all other pad configurations.
BUG=b:159944426
Change-Id: I835b62f5502375ffc4215548b51338a67546d699
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42876
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, for Stoneyridge and Picasso mainboards, pads that are
configured for SCI/SMI/WAKE need to have multiple entries in the
configuration table - one for PAD_GPI and other for the special
configuration that is required. This requires a very specific ordering
of pads within the table and is prone to errors because of conflicting
params provided to the different entries for the same pad. This also
does not work very well with the concept of override GPIOs where the
entry in base table is overridden with the first matched entry from
the override table.
This change updates the way GPIO configuration is handled for special
routing like SCI/SMI/WAKE/DEBOUNCE by setting the control field of
soc_amd_gpio structure in the macros performing these
configurations. Also, program_gpios() is updated to perform a write to
GPIO control register instead of read-modify-write. This is because
mainboard is expected to provide only a single configuration entry for
each pad within a given table. Thus, there is no need to preserve
earlier configuration.
Mainboards that were providing multiple entries for a single pad are
updated accordingly.
BUG=b:159944426
Change-Id: I3364dc2982d66c4e33c2b4e6b0b97641ebea27f0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42875
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some codepaths want to set selected bits of a hardware register
to match those of a given variable in memory. Provide a helper
function for this purpose and use it in gpio_set(),
gpio_input_pulldown() and gpio_input_pullup().
This change also adds GPIO_PULL_MASK and updates GPIO_OUTPUT_MASK to
include all bits dealing with pull and output respectively.
Change-Id: I4413d113dff550900348a44f71b949b7547a9cfc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42688
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds helper macro PAD_CFG_STRUCT for setting the fields
of `soc_amd_gpio`. Additionally, macros are added for different
operations i.e. pull, output, trigger, int_enable, event_trigger,
wake_enable, debounce, etc. All GPIO configuration macros are updated
to use PAD_CFG_STRUCT instead of setting the fields directly.
BUG=b:159944426
Change-Id: I03535d2da0c05f72c4163fa30d72f9c6df44908b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42872
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change renames GPIO macros as follows:
1. Pad filtering macros are renamed to GPIO_TRIGGER_ and
GPIO_ACTIVE_. This determines the filtering applied on the input
signal at the pad.
2. Interrupt enabling macros are renamed to GPIO_INT_ENABLE_.
_INT_ is dropped from pad filtering macros because the filtering
applies to the input signal irrespective of how it is routed. It is
applied at the pad not only for GPIO interrupts but also for other
routes i.e. SCI, SMI, etc.
BUG=b:159944426
Change-Id: Id0ad770be77409aaaae4cc135945e2815ce97030
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42870
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`soc_amd_gpio` structure uses a flag field to store additional
information about GPIO configuration that does not end up directly in
the GPIO control register. However, the naming for these flags is not
consistent across event triggers and special configurations. This
change updates the flag names to be consistent (starting with
GPIO_FLAG_*) and adds some helper functions for GPIO events.
In the following CLs, more changes will be made to drop some of the
special flags which are not really required.
BUG=b:159944426
Change-Id: Idca795c3e594eb956d297d5ba5d08f75b5563ee5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42869
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In some rare cases it seems that make tries to build
$(objgenerated)/assembly.inc before the build-dirs target has finished,
and so assembly.inc can't be written. Enforce that build-dirs is done
before assembly.inc starts.
BUG=chromium:1098215
BRANCH=none
TEST=none
Change-Id: Ib141ea45a43836cfdde0059523c331fe5286b06d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Align support for enable wake-on-usb attach/detach as was
introduced in Skylake in
`commit 3bfe3404df32ca226c624be0435c640bf1ebeae7`.
This adds the USB Wake Enable Setup (UWES) ASL blocks
required to inform the OS about plug wake events bits
being set in the PORTSCN register configured by devicetree.
BUG=b:159187889
BRANCH=none
TEST=none
Change-Id: I6c63d226e5acadff04486c8a6764fb715a0ac051
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This enables Thermal Control Circuit (TCC) activation feature to set
tcc_offset value to new value in devicetree.
BUG=None
BRANCH=None
TEST=Built for dedede platform and verified the MSR value
Change-Id: I58e4fa362f20efeef84e06e64d70ee7c4f9554d6
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This enables Thermal Control Circuit (TCC) activation feature to set
tcc_offset to new value in devicetree.
BUG=None
BRANCH=None
TEST=Built for volteer platform and verified the MSR value.
Change-Id: I36b0d6aad4be8a9cbb145dcd66d65235d3f6ac35
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Commit 0013623 (mb/google/dragonegg: remove abandoned project) dropped
this mainboard because it is no longer in development nor used. However,
the associated documentation remained. Rest in pieces, Dragonegg. ;-;
Change-Id: Idd2ee716717132ba3fa237ae97f34686007d3685
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds a separate blobs repository for Qualcomm blobs,
analogous to the existing AMD blobs. Qualcomm's binary licenses allow
files to be redistributed and used by anyone, but they explicitly
require the user to agree to the license terms when just *downloading*
the binary (even if they're not using them to build any firmware). Some
community members do not like to have to agree to licenses for files
they're not actually using, so we are keeping these files separate from
the main blobs repository and adding an extra Kconfig to make sure the
user is aware of and must explicitly agree to this before downloading
these files.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I247746c1b633343064c9f32ef1556000475d6c4a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add CpuReplacementCheck to chip options to control UPD FSPM
SkipCpuReplacementCheck from devicetree.
This UPD allows platforms with soldered down SoC to skip CPU
replacement check to avoid a forced MRC traning.
TEST=boot and verified with volteer
Change-Id: Ic5782723ac3a204f2af657fac9944fb41fc03f4d
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42788
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Coverity detects dereferencing pointers that might be "NULL" when
calling acpigen_write_scope and acpigen_write_device. Add sanity
check for both of scope and name to prevent NULL pointer dereference.
Found-by: Coverity CID 1429981
TEST=Built and boot up to kernel.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Iea3801585e8c294fb889a8137b534bb932696025
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42836
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Coverity detects dereferencing pointers that might be "NULL" when
calling acpigen_write_scope and acpigen_write_device. Add sanity
check for both of scope and name to prevent NULL pointer dereference.
Found-by: Coverity CID 1429979, 1429982
TEST=Built and boot up to kernel.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: If17d12861f562dc0d6c98a5c91a9d3c0360ca2c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42835
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A follow-up patch will add Cereme which is a Mandolin variant.
Beware that the name of the EC firmware image is changed from mchp.bin
to EC_mandolin.bin.
TEST=Mandolin still boots into Linux live system.
Change-Id: Ifee91306756f8a4152a6a0224e172dae7eac8f7a
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42785
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Although on ThinkPads with Panther Point PCH the usb port inside wwan
socket is usually wired to XHCI, it has actually no SuperSpeed lines,
so maybe it is okay to disable SuperSpeed capabilities, and wire them
to EHCI #2 by making use of XUSB2PRM and USB3PRM.
This applies to both variants of x230.
Change-Id: Ia8d27be84e4dbfa0efed506b9fc010e7f4d6ba23
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41505
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code is based on autoport and that for X230. Major differences are:
- Only one DDR3 slot
- HM77 PCH
- M.2 socket instead of mini PCIe
- No docking
- No TPM
Tested:
- CPU i5-3337U
- 8GiB SO-DIMM
- Camera
- PCIe and USB2 on M.2 slot with A key for WLAN
- SATA and USB2 (no SuperSpeed components) on M.2 slot with B key for WWAN
- On board SDHCI connected to PCIe
- USB3 ports
- libgfxinit-based graphics init
- NVRAM options for North and South bridges
- Sound
- ThinkPad EC
- S3
- Linux 4.9 within Debian GNU/Linux stable, loaded from SeaBIOS.
Untested:
- Touch screen, which is said to work under ubuntu but not debian.
Change-Id: Id59cdc5479aaf70809dd1ca613056263661455eb
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41390
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
pmc_set_acpi_mode() should run after Chrome EC dealt with all host event
bits, like SMI mask (otherwise the FAFT firmware_FWScreenCloseLid test
will fail).
BUG=b:153249055
TEST=FW_NAME=malefor emerge-volteer coreboot chromeos-bootimage
Change the GBB flag to 0x140 then check SMI mask during depthcharge
phase, make sure it's 0x0000000000000001.
Signed-off-by: William Wei <wenxu.wei@bitland.corp-partner.google.com>
Change-Id: Icfff5cc5550f23938343e4d26ef76093bb9cf7c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The previous Intel CPX-SP FSP release was ww20 release.
The ww22 release fixs issues related to FSP_NV_STORAGE HOB. The end of end
flow of using memory training data to generate FSP_NV_STORAGE HOB and
using memory training data passed from bootloader to skip memory
training, works now. This saves 8 minutes of boot time (with FSP verbose
logging enabled on DeltaLake server).
This release also adds UPD parameters to support IIO bifuration.
The ww24 release has following updates:
a. Removed a number of unnecessary UPD parameters, such as mmiolSize,
mmiolBase, OemHookPostTopologyDiscovery, OemGetResourceMapUpdate.
b. Added UPD parameters to support PCIe ports configuration.
c. Updated IIO_UNIVERSAL_DATA HOB, each stack now has mmio base/limit
fields, in addition to PCIe resource memory base/limit fields.
With ww24 release, the issue with PCIe link training persists. On YV3
config A, the onboard NIC card has x4 connection to port 2D. This
NIC device is not recognized by FSP.
Corresponding soc/intel/xeon_sp/cpx change is made:
* There are changes in PLATFORM_DATA structure, so hob_display.c
is updated.
* There are changes in UPD parameters, so romstage.c is updated.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I70762b377a057d0fca7806f485cce8d479fb5baa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41903
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix potential overflow when multiplying integers in transform_vector().
This issue is causing the absolute coordinate of the bottom right corner
of the box to be incorrectly calculated for draw_rounded_box(), which is
used in menu UI to clear the previous screen.
In addition, check the lower bound in within_box().
BRANCH=none
BUG=b:146399181, b:159772149
TEST=emerge-puff libpayload
TEST=Previous screen is cleared properly for menu UI
Change-Id: I57845f54e18e5bdbd0d774209ee9632cb860b0c2
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42770
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If VPD_SMBIOS_VERSION is selected, it would read VPD_RO variable that can
override SMBIOS type 0 version.
One special scenario of using this feature is to assign a BIOS version to
a coreboot image without the need to rebuild from source.
VPD_SMBIOS_VERSION default is n.
Tested=On OCP Delta Lake, dmidecode -t 0 can see the version being updated
from VPD.
Change-Id: Iee62ed900095001ffac225fc629b3f2f52045e30
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: insomniac <insomniac@slackware.it>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This enables to configure the Thermal Control Circuit (TCC) activation
value to new value as tcc_offset in degree Celcius. It prevents any
abrupt thermal shutdown while running heavy workload. This helps to
take early thermal throttling action before CPU temperature reaches
maximum operating temperature TjMax value. Also, cleanup local functions
from previous intel soc specific code base like for apollolake, broadwell,
skylake and cannonlake.
BUG=None
BRANCH=None
TEST=Built for volteer platform and verified the MSR value.
Change-Id: I37dd878902b080602d70c5c3c906820613ea14a5
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This also makes the calling of the eMMC GPIO mux setup function
conditional on PICASSO_LPC_IOMUX instead of AMD_LPC_DEBUG_CARD which
only makes the selection of PICASSO_LPC_IOMUX user-configurable.
Change-Id: Ic49a668f82fbc1b851c07d312b543d2889fe4734
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42842
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Both Dali and Pollock chips have less PCIe, USB3 and DisplayPort
connectivity. While Dali can either be fused-down PCO or RV2 silicon,
Pollock is always RV2 silicon.
Since we have all boards using this code in tree right now,
soc_is_dali() can be renamed and generalized to soc_is_reduced_io_sku().
Change-Id: I9eb57595da6f806305552128b0c077ceeb7c4661
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42833
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change allows mainboard to configure different wakeup routes that
can be used by a GPIO key:
1. SCI: This is selected when SCI route is used to wake the system. It
results in _PRW property being exposed in ACPI tables.
2. GPIO IRQ: This is selected when GPIO controller wake is used to
wake the system. It is typically used when the input signal is not
dual routed and the GPIO controller block is not capable of applying
filters for IRQ and wake separately. In this case, _PRW is not exposed
in ACPI tables for the key device.
3. Disabled: No wakeup supported.
Based on these wakeup routes, gpio_keys_add_child_node() is updated to
expose _PRW and _DSD properties for wakeup appropriately.
Additionally, the change updates mainboards that were already using
gpio_keys to set wakeup_route attribute correctly and renames "wake"
to "wake_gpe" to make the usage clear.
BUG=b:159942427
Change-Id: Ib32b866b5f0ca559ed680b46218454bdfd8c6457
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
All Intel southbridges with SPI perform this write. Put it inside a
function in common code. Use a different name to avoid a name clash.
As it is only one statement, make it inline so that it can be defined
on the header itself. It is only called once per southbridge anyway.
Change-Id: I3c284d6cffd22949d50b4c4f9846ceaef38d7cda
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42660
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This reverts commit 1408798637.
Reason for revert: Causing backlight issues in device. Will reland after more debugging to figure out the root cause.
BUG=b:159370566
BRANCH=None
TEST=boot up device and make sure when kernel is booted, backlight comes up.
Change-Id: I643854c6c805d262539bbb482808e8c322059a49
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently, Reset Power Cycle Duration is set with default value (4s).
This adds around ~5 seconds of delay during power cycle or global reset.
So, this patch sets PchPmPwrCycDur (Reset Power Cycle Duration) to 1s
to minimize the delay.
Delay with Power Cycle or Global Reset:
Existing behaviour:
S0->S5 -> [ ~5 seconds delay ] -> S5->S0
With the patch:
S0->S5 -> [ ~2 seconds delay ] -> S5->S0
Also, correct the comment mentioned for PchPmSlpAMinAssert.
The value(3) defined for PchPmSlpAMinAssert triggers signal assertion width
to 98ms not 2s.
Test=Verified on Hatch and Puff boards
BUG=b:158634281
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I368c6716a92e06903a872f9e87ae0698eab95bdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42441
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is to enable Intel ME communication interface HECI1 by
devicetree for PAVP with CSE Lite.
BUG=b:159615125
TEST=Build and boot volteer. Run lspci and check pcie device
00:16.0 Communication controller: Intel Corporation Device a0e0
Change-Id: I68eb51c6a0af77982c060767993265764a2bc926
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This reverts commit 4883252912.
Almost everything in <amdblocks/acpimmio_map.h> is invalid for PSP as
it does not have the same view of memory space.
The prototypes xx_set/get_bar() are only valid for PSP as x86 cores
will use the constant mapping defined in <amdblocks/acpimmio_map.h>
The selected MMIO base address model depends of the architecture the
stage is built for and, to current knowledge, nothing else. So
the guards should have been with ENV_X86 vs ENV_ARM and not about
CONFIG(VERSTAGE_BEFORE_BOOTBLOCK).
For the ENV_ARM stage builds, <arch/io.h> file referenced in the
previously added mmio_util_psp.c file has not been added to the tree.
So there was some out-of-order submitting, which did not get caught
as the build-testing of mixed-arch stages has not been incorporated
into the tree yet.
The previously added file mmio_util_psp.c is also 90% redundant with
mmio_util.c.
Change-Id: I1d632f52745bc6cd3c3dbddb1ea5ff9ba962c2e8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42486
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add PchPmPwrCycDur to chip options to control the UPD FSPS PchPmPwrCycDur
from devicetree. The UPD determines the minimum time a platform will stay
in reset during host partition reset with power cycle or global reset.
This patch also ensures configured PchPmPwrCycDur value doesn't violate
the PCH EDS specification.
TEST=Verified on Hatch and Puff boards
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I55e836c78fab34e34d57b04428a1498b7dc7174b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Not all FSPs based on FSP 2.1 supports the feature of external PPI
interface pulled in via FSP_PEIM_TO_PEIM_INTERFACE.
Deselect FSP_PEIM_TO_PEIM_INTERFACE when PLATFORM_USES_FSP2_1 is
selected.
Update Kconfig of SOCs affected (icelake, jasperlake, tigerlake).
Change-Id: I5df03f8bcf15c9e05c9fd904a79f740260a3aed7
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
This patch includes (edk2/edk2-stable202005) all required headers
for edk2-stable202005 quarterly EDK2 tag from EDK2 github project
using below command:
>> git clone https://github.com/tianocore/edk2.git vedk2-stable202005
Only include necessary header files.
MdePkg/Include/Base.h was updated to avoid compilation errors through
safeguarding definitions for MIN, MAX, NULL, ABS, ARRAY_SIZE.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I3172505d9b829647ee1208c87623172f10b39310
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42239
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Chrome OS ACPI code has always used a legacy PNP ID "GGL0001" for
the ID. This is technically valid but we have an official ACPI ID
now so I allocated "GOOG0016" for an ID and we can eventually retire
the legacy PNP ID.
This is being discussed on LKML as part of an effort to upstream the
Chrome OS ACPI kernel driver: https://lkml.org/lkml/2020/4/13/315
Change-Id: I2e41fe419113b327618f8f98058ef7af657f2532
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
For type 3, override chassis asset_tag_number with smbios_mainboard_asset_tag()
and add two functions that can override chassis version and serial_number.
For type 4 add smbios_processor_serial_number() to override serial_number.
Tested on OCP Tioga Pass.
Change-Id: I80c6244580a4428fab781d760071c51c7933abee
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Implemented according to IPMI "Platform Management FRU Information
Storage Definition" specification v1.0 for reading FRU data Chassis
Info Area.
Tested on OCP Tioga Pass.
Change-Id: Ieb53c20f8eb4b7720bf1fe349e6aaebaa4c37247
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40306
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Support display of CPX-SP specific HOBs (when CONFIG_DISPLAY_HOBS
is selected, and UPD parameters (when CONFIG_DISPLAY_UPD_DATA is selected).
Such display is used for FSP debugging purpose. It adds small
amount of boot time.
Some UPD display log excerpts:
UPD values for SiliconInit:
0x04: BifurcationPcie0
0x03: BifurcationPcie1
Some HOB display log excerpts:
=== FSP HOBs ===
0x758df000: hob_list_ptr
0x758df000, 0x00000038 bytes: HOB_TYPE_HANDOFF
0x758df038, 0x00000028 bytes: HOB_TYPE_MEMORY_POOL
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Reddy Chagam <anjaneya.chagam@intel.com>
Change-Id: I42dd519103cc604d4cfee858f4774bd73c979e77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41348
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the configuration of PCIE_RST0_L as native
function to happen in early GPIO table. This ensures that the PERST#
signal is deasserted as soon as possible when the system comes out
of sleep state in case the sleep path asserted/deasserted the PERST#
as GPIO out.
A big difference in functionality with this change is that PCIE_RST0_L
signal is now configured as part of RO, which should be fine since
all PCIe devices have a second AUX_RESET_L signal or use PCIE_RST1_L
to control the actual reset to the device.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I21a9c25b5a8a6d502cdb79cbe0dbad6ef98d6d63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42739
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change replaces variant_wifi_romstage_gpio_table() with
variant_pcie_power_reset_configure() to handle the reset and power
sequencing for WiFi devices pre- and post- v3 version of schematics.
These are the requirements that need to be satisfied:
1. As per PCI Express M.2 Specification Revision 3.0,
Version 1.2, Section 3.1.4 "Power-up Timing", PERST# should stay
disabled until `TPVPGL` time duration after device power has
stabilized. Value of TPVPGL is implementation specific.
2. For Intel WiFi chip, it is known to get into a bad state if the
above requirement is violated and hence requires a power cycle.
3. On pre-v3 schematics:
- For both dalboz and trembyle references, GPIO42 drives
WIFI_AUX_RESET_L which is pulled up to PP3300_WIFI.
- For both dalboz and trembyle references, PP3300_WIFI is controlled
using GPIO29. This pad gets pulled high by default on PWRGOOD
because of internal pull-up. But, at RESET# it is known to have a
glitch. When GPIO29 gets pulled high, it causes WIFI_AUX_RESET_L to
be pulled high as well. This violates the PCIe power sequencing
requirements. Hence, for pre-v3 schematics on both dalboz and
trembyle, following sequence needs to be followed:
a. Assert WIFI_AUX_RESET_L.
b. Disable power to WiFi.
c. Wait 10ms to allow WiFi power to go low.
d. Enable power to WiFi.
e. Wait 50ms as per PCIe specification.
f. Deassert WIFI_AUX_RESET_L.
4. On v3 schematics:
- For trembyle: WIFI_AUX_RESET_L is driven by GPIO86 which has an
internal PU as well as an external PU to PP3300_WIFI.
- For dalboz: WIFI_AUX_RESET is driven by GPIO29. This is active
high and has an internal PU. It also has an external 1K PD to
overcome internal PU.
- For both dalboz and trembyle references, PP3300_WIFI is
controlled by GPIO42 which has an internal PU and external
PD. Trembyle schematics have a comment saying strong PD of 2.2K but
the stuffed resistor is a weak one (499K). ON dalboz, it uses a
weak PD (which doesn't look correct and instead should be a strong
PD just like trembyle). Having a strong PD ensures that the WiFi
power is kept disabled when coming out of G3 until coreboot
configures GPIO42 as high.
- Thus, for v3 schematics, following sequence needs to be followed:
a. Assert WIFI_AUX_RESET{_L} signal.
b. Enable power to WiFi.
c. Wait 50ms as per PCIe specification.
d. Deassert WIFI_AUX_RESET{_L} signal.
BUG=b:157686402, b:158257076
TEST=Verified that QCA and AX200 cards both continue working. Tested
QCA on Dalboz and Trembyle. Tested AX200 on morphius.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I532131ee911d5efb5130d8710f3e01578f6c9627
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42738
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates variant_romstage_gpio_table() and
variant_wifi_romstage_gpio_table() to support v3 version of schematics
for dalboz and trembyle reference designs. gpio_set_stage_rom and
gpio_set_wifi are divided into two groups:
a) Pre-v3 (GPIO table for pre v3 schematics):
* gpio_set_stage_rom_pre_v3
* gpio_set_wifi_pre_v3
b) v3 (GPIO table for v3+ schematics):
* gpio_set_stage_v3
* gpio_set_wifi_v3
Currently, both _v3 is a copy of _pre_v3, but will be updated in
follow-up CLs to make it easier to identify what changed from _pre_v3
to _v3.
BUG=b:157088093, b:154676993, b:157098434, b:157165628, b:157744136, b:157743835
TEST=Compiles
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I444875d93100c2f2abdb6dec4312861fd89d9b78
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2251390
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42721
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the GPIOs that need to be configured for early
access in coreboot to early_gpio_table[] in
gpio_baseboard_common.c. These GPIOs include:
* Pads to talk to EC
* Pads to talk to TPM
* Pads to talk to serial console
These should be configured in the first stage that runs coreboot
i.e. in case of VBOOT_STARTS_BEFORE_BOOTBLOCK, it should be done as
part of verstage (which starts on PSP), else it should be done as part
of bootblock (which is the first stage that runs on x86).
This change drops GPIO_137 from early_gpio_table since that is not
really required in early stages.
BUG=b:154351731
TEST=Verified that trembyle still boots.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ifbdbb02cbfc65ddb68f0ae75cf4b1f2ea1656b91
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2252709
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Align support for enable wake-on-usb attach/detach as was
introduced in Skylake in
`commit 3bfe3404df32ca226c624be0435c640bf1ebeae7`.
BUG=b:159187889
BRANCH=none
TEST=none
Change-Id: Ie63e4f1fcdea130f8faed5c0d34a6a96759946b6
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42716
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The host bridge's resources covering bus numbers assumed
256 buses were being decoded. However, MMCONFIG was only
covering 64 buses. This results in Linux complaining:
acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000
[bus 00-3f] only partially covers this bridge
When retrieving the host bridge's resources fix up the
bus numbers to utilize MMCONF_BUS_NUMBER Kconfig. I couldn't
keep IASL from complaining when trying to do this statically.
BUG=b:158874061
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ief1901743e2c99f583ef0181490d493d23734f64
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
1) Based on malefor schematics, disable unused I2C port, USB port, TBT
PCIe
2) Add audio device to the tree
BUG=b:150653745, b:154973095
TEST=FW_NAME=malefor emerge-volteer coreboot chromeos-bootimage
Boot to kernel and check the devices' function worked properly.
Signed-off-by: William Wei <wenxu.wei@bitland.corp-partner.google.com>
Change-Id: I9ce465705e8b8f67ddbc9e4eb06c5a8bfac65fcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42246
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the volteer2 variant of the volteer reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.1.1).
Modified to alphabetize and update to duplicate latest volteer changes
currently in the review and merge pipeline.
Added the following missing files from the variants/volteer2/ folder:
- gpio.c
- include/variant/acpi/dptf.asl
- acpi/mipi_camera.asl
- Makefile.inc
- memory/dram_id.generated.txt
- memory/Makefile.inc
- memory/mem_list_variant.txt
- overridetree.cb
BUG=b:159135047
BRANCH=None
TEST=util/abuild/abuild -p none -t google/volteer -x -a
make sure the build includes GOOGLE_VOLTEER2
Change-Id: I987c72b83dc993af248a753a2caa56be0f26c1ad
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42605
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The dmesg shows unresolved symbol CDW1 with AE_NOT_FOUND error after
booting to kernel. Fix the error by properly creating the buffer field
CDW1 to cover all errors scenarios.
BUG=b:140645231
TEST=Verified no AE_NOT_FOUND error related to \_SB.OSC.CDW1.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ibfe677f87736ce1930e06b9cd649791977116012
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42693
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 9550e97 [acpi: correct the processor devices scope] changed
the default CPU scope from _PR to _SB, but the default prefix in
Stoneyridge's Kconfig was missed, leading to ACPI errors for
'AE_NOT_FOUND for object \_PR.P00n.' Fix the default prefix and
eliminate the errors reported in dmesg.
Test: boot Linux w/5.3 kernel on google/liara, check for errors
Change-Id: I5611b6836062a0a9f90036d7fe40cd98bd730af3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Create the delbin variant of the volteer reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.1.1).
BUG=b:158797761
BRANCH=None
TEST=util/abuild/abuild -p none -t google/volteer -x -a
make sure the build includes GOOGLE_DELBIN
Signed-off-by: Zhuohao Lee <zhuohao@chromium.org>
Change-Id: Icf5fc6b9cc6a7c47e52103b2d396bcddb26adf50
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42709
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Create the wyvern variant of the puff reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.1.1).
BUG=b:158269582
BRANCH=None
TEST=util/abuild/abuild -p none -t google/hatch -x -a
make sure the build includes GOOGLE_WYVERN
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Id7a090058d2926707495387f7e90b3b8ed83dac7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42551
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the faffy variant of the puff reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.1.1).
V.2: Manually modified to keep Kconfig sorted.
BUG=b:157448038
BRANCH=None
TEST=util/abuild/abuild -p none -t google/hatch -x -a
make sure the build includes GOOGLE_FAFFY
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Change-Id: I5f14c2d6144ce3c2e48488ca81f31b3c04dc5fb9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42717
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The assumption up to this point was that if the system had an x86
processor, verstage would be running on the x86 processor. With running
verstage on the PSP, that assumption no longer holds true, so exclude
pieces of code that cause problems for verstage on the PSP.
This change will add these files to verstage only if the verstage
architecture is X86 - either 32 or 64 bit.
BUG=b:158124527
TEST=Build and boot on Trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I797b67394825172bd44ad1ee693a0c509289486b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42062
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are two touch screen controllers on the Palkia device.
One is on the lid; another is on the base. To support
the different control path (for example: turning off the base's
touch event when we don't want to use it however still keeping
the lid's touch event), we use the different gpio pins to control
the second touch. As a result, we need to modify the devicetree
to adopt this change. With this change, we can control the
primary and secondary touch screen controller respectively.
BUG=b:149714955
TEST=lid/base touch screen works correctly
Change-Id: I1f896e334e51c78300af724cbef8d57641ae5612
Signed-off-by: Zhuohao Lee <zhuohao@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Here we consolidate some of the mainboard.c duplication between
Puff and it's variants.
Customizations can be done later via introducing a devicetree
parameterisation.
BUG=b:154071868
BRANCH=none
TEST=none
Change-Id: I75c2de7ae8efd544d800bc77e34e667c3afa4b01
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42672
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Picasso's BERT region should not have been moved to cbmem in commit
901cb9c "soc/amd/picasso: Move BERT region to cbmem". This
causes an error of "APEI: Can not request [] for APEI BERT registers.
FSP has been modified to set aside a requested region size for BERT,
simiar to TSEG. Remove the cbmem reservation and locate the region
by searching for the HOB.
BUG=b:136987699
TEST=Check that BERT is allocated
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: I20e99390141986913dd45c2074aa184e992c8ebb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42530
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For consistency with other Intel southbridges, we rename this function
to `i82801ix_lpc_setup`.
Tested with BUILD_TIMELESS=1, Roda RK9 does not change.
Change-Id: Id8b3bcc9174277e085868866a1b5d90b5c51201a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Having speparate types for the status register with three and four block
protection bits respectively doesn't really make sense, it's the same
size either way just a different representation, so one union type will
do.
This allows us to de-duplicate the status register read in
winbond_get_write_protection as well as removing another layer of union
in 'struct status_regs'.
Change-Id: Ie99b98fb6762c8d84d685b110cfc2fd5458b702e
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42111
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove an unneccessary comment and group the variant_early_gpio_table
together based on GPIO group.
Changed static variable name gpio_table to override_gpio_table to be
more descriptive.
BUG=none
TEST="emerge-volteer coreboot chromeos-bootimage", flash and boot
volteer to kernel.
Change-Id: Iabe810df1e5a3df35e3543ab81b9fdb6f76c223a
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42577
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the following volteer-specific devices from baseboard's
devicetree.cb into volteer's overridetree.cb file:
- Goodix Touchscreen
- ELAN Touchscreen
- ELAN Touchpad
- SAR0 Proximity Sensor
Adjust the other variant's overridetree.cb files to correspond to
the changes made to the baseboard's devicetree.cb in this change.
BUG=b:159241303, b:154646959
TEST='emerge-volteer coreboot chromeos-bootimage', flash and boot
volteer to kernel and verify that the trackpad works.
Change-Id: I30f8266ec87a7cde293c84d3e687d133207b8d59
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42550
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
With the stub video_console_init() removed from depthcharge in
CL:2241493, depthcharge will fail to compile:
payloads/libpayload/gdb/stub.c:76: undefined reference to
`video_console_init'
Since video_console_init() is meant to be implemented in
libpayload, libpayload should be consistent with itself by not calling
this function when it's not implemented (i.e., when !LP_VIDEO_CONSOLE).
Therefore, initialize video console only if LP_VIDEO_CONSOLE is set.
BRANCH=none
BUG=none
TEST=USE="menu_ui" emerge-gale depthcharge
Change-Id: Ic45f9073330258cb77301003484ec525b2404180
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42505
Reviewed-by: Joel Kitching <kitching@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The pass through mode (SW CM) RTD3 is not supported until QS platform.
D3Cold is needed to be disabled along with upstream TBT firmware
signed_TGL_HR_4C_A0_rev6_pre4_SW_CM_PM_support_ENG_VER_perst_check_fix.
This temporary patch will need to be reverted once PM RTD3 support is
validated on QS platform.
BUG=b:159050315
TEST=Verfiy PM S0ix along with upstream TBT firmware.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I98ed991e4185abf1f3168e33b099e0e97c9075f6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42504
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Divya Sasidharan <divya.s.sasidharan@intel.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using guidance from Intel, a new set of power limits (PL1, PL2 & PL4)
are available for TGL-U. They are dependent upon the SKU of the CPU
that the mainboard is running on. Volteer is updated here to use these
new limits.
To accomplish this, the SoC chip config's power_limits_config member
was expanded to an array, which can be indexed by POWER_LIMITS_*_CORE
macros. Just before power limits are applied, the correct set of them
is chosen from the array based on System Agent PCI ID. Therefore, a
TGL board should have two sets of power limits available in the
devicetree.
BUG=b:152639350
TEST=On a Volteer SKU4 (4-core), verified the following console output:
CPU PL1 = 15 Watts
CPU PL2 = 60 Watts
CPU PL4 = 105 Watts
Change-Id: I18a66fc3aacbb3ab594b2e3d6e2a4ad84c10d8f0
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42436
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
This allows the kernel to runtime suspend these devices and properly
shut them down. If a tty is not used, the kernel will disable the
device.
I omitted UART0 because the PSP will not power the controller before
accessing it. This causes PSP boot failures. See b/158772504. We also
can't enable UART0 D3 until we stop using the mmio kernel command line
`console=uart,mmio32,0xfedc9000`. The kernel will suspend the UART
controller before it notices that the mmio address matches ttyS0. This
causes the kernel to fail writing to the UART. So we need to move over
to `console=ttyS0`.
BUG=b:153001807, b:157617092, b:157858890, b:158772504
TEST=Boot trembyle and see I2C devices entering and exiting D3.
* See the UART devices entering D3
* Made sure the i2c peripherals were still functional.
* Ran suspend stress test for 40+ iterations.
[ 0.349094] power-0362 __acpi_power_on : Power resource [FUR1] turned on
[ 0.350627] power-0362 __acpi_power_on : Power resource [FUR2] turned on
[ 0.352094] power-0362 __acpi_power_on : Power resource [FUR3] turned on
[ 0.353626] power-0362 __acpi_power_on : Power resource [I2C2] turned on
[ 0.376980] power-0362 __acpi_power_on : Power resource [PRIC] turned on
[ 0.399997] power-0362 __acpi_power_on : Power resource [PRIC] turned on
[ 0.401953] power-0362 __acpi_power_on : Power resource [I2C3] turned on
[ 0.403460] power-0362 __acpi_power_on : Power resource [I2C4] turned on
[ 0.483646] power-0418 __acpi_power_off : Power resource [I2C4] turned off
[ 1.028404] power-0418 __acpi_power_off : Power resource [I2C3] turned off
[ 1.448426] power-0418 __acpi_power_off : Power resource [I2C2] turned off
[ 5.308094] power-0418 __acpi_power_off : Power resource [FUR1] turned off
[ 5.340833] power-0418 __acpi_power_off : Power resource [FUR2] turned off
[ 5.382041] power-0418 __acpi_power_off : Power resource [FUR3] turned off
[ 5.423861] power-0362 __acpi_power_on : Power resource [I2C3] turned on
[ 6.698225] power-0362 __acpi_power_on : Power resource [I2C2] turned on
[ 6.856573] power-0418 __acpi_power_off : Power resource [I2C3] turned off
[ 8.246970] power-0418 __acpi_power_off : Power resource [I2C2] turned off
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I04c4a729d4cb9772ab78586fdbb695b450cc1600
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42473
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add RW_MRC_CACHE flash region to hold MRC cache data.
With memory training skipped for subsequent reboots, the boot
time is reduced by 8 minutes on OCP Delta Lake server, when
FSP verbose logging is turned on.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I27ed00100e1ea9e29b0e71ea5a8397cd550e193a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42025
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
OCP Delta Lake server is a one socket server platform powered by
Intel Cooper Lake Scalable Processor.
The Delta Lake server is a blade of OCP Yosemite V3 multi-host
sled.
TESTED=Successfully booted on both YV3 config A Delta Lake server
and config C Delta Lake server. The coreboot payload is Linux kernel
plus u-root as initramfs. Below are the logs of ssh'ing into a
config C deltalake server:
jonzhang@devvm2573:~$ ssh yv3-cth
root@ip's password:
Last login: Mon Apr 20 21:56:51 2020 from
[root@dhcp-100-96-192-156 ~]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 52
On-line CPU(s) list: 0-51
...
[root@dhcp-100-96-192-156 ~]# cbmem
34 entries total:
0:1st timestamp 28,621,996
40:device configuration 178,835,602 (150,213,605)
...
Total Time: 135,276,123,874,479,544
[root@dhcp-100-96-192-156 ~]# cat /proc/cmdline
root=UUID=f0fc52f2-e8b8-40f8-ac42-84c9f838394c ro crashkernel=auto selinux=0 console=ttyS1,57600n1 LANG=en_US.UTF-8 earlyprintk=serial,ttyS0,57600 earlyprintk=uart8250,io,0x2f8,57600n1 console=ttyS0,57600n1 loglevel=7 systemd.log_level=debug
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Reddy Chagam <anjaneya.chagam@intel.com>
Change-Id: I0a5234d483e4ddea1cd37643b41f6aba65729c8e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
There's a useless check with both branches doing the same: enabling RC6
and disabling RC6p. In past, this condition would enable RC6p in IVB but
not on SNB. Then, at some point, RC6p was considered unstable and was
disabled, but the condition remained.
It's not needed so let's remove it.
Change-Id: I926bb682d1b9d21185048224490b966c33204b6a
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
TGL RVP and Volteer use ov8856 camera module from different vendors.
TGL RVP from Foxlink and Volteer from Sunny. ov8856 sensor is identical
for the two modules but VCM and EEPROM are different. Originally,
Volteer ACPI was set to align with Sunny module, GT9679. But it turned
out GT9679 is compatible with Foxlink's DW9768. So Volteer camera ACPI
configuration doesn't need to keep GT9679.
BUG=b:158188369
BRANCH=none
TEST=Build and boot volteer proto 2 board. Start a camera app
and check user-facing camera functionalities.
Signed-off-by: Daniel Kang <daniel.h.kang@intel.com>
Change-Id: I792608f86a59b16545dfa4edf6508de7a444bb26
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42048
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Daniel H Kang <daniel.h.kang@intel.corp-partner.google.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
This change updates platform.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for volteer.
Change-Id: I248f5e9a1e3ba4f6426167f0406073252cc6513a
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42506
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In waddledee and waddledoo, discrete & integrated BT signals are routed to
different USB ports. In all the other variant boards, discrete &
integrated BT signals are routed to the same USB port (port 8 - index 7).
Re-configure the USB devices accordingly.
Also device configuration in override tree are applied only if there is a
matching device in base devicetree. So configure all the USB devices in
base devicetree and turn them off.
BUG=b:154064148
TEST=Ensure that the SSDT contains the ACPI objects for enabled USB
devices.
Change-Id: I1b8bf7f4db1d2661f310bf4874428a6d1de222c6
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42554
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most LAPIC registers are 32bit, and thus the use of long is valid on
x86_32, however it doesn't work on x86_64.
* Don't use long as it is 64bit on x86_64, which breaks interrupts
in QEMU and thus SeaBIOS wouldn't time out the boot menu
* Get rid of unused defines
* Get rid of unused atomic xchg code
Tested on QEMU Q35 with x86_64 enabled: Interrupts work again.
Tested on QEMU Q35 with x86_32 enabled: Interrupts are still working.
Tested on Lenovo T410 with x86_64 enabled.
Change-Id: Iaed1ad956d090625c7bb5cd9cf55cbae16dd82bd
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36777
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We are currently relying on the assumption that the amdcompress tool
will zero out the bss section. Instead of relying on this assumption,
lets explicitly clear it.
The implementation was copied from assembly_entry.S.
BUG=b:147042464
TEST=Cold boot trembyle and also s3 resume trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifb4f4cc6932dd4c3c92d4e7647569f9a0c69ea4c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change is required so we have a defined entry point on S3. Without
this, the S3_RESUME_EIP_MSR register could in theory be written to
later which would be a security risk.
BUG=b:147042464
TEST=Resume trembyle and see bootblock start.
coreboot-4.12-512-g65779ebcf73f-dirty Thu Jun 4 22:38:17 UTC 2020 smm starting (log level: 8)...
SMI# #6
SMI#: SLP = 0x0c01
Chrome EC: Set SMI mask to 0x0000000000000000
Chrome EC: Set SCI mask to 0x0000000000000000
Clearing pending EC events. Error code EC_RES_UNAVAILABLE(9) is expected.
EC returned error result code 9
SMI#: Entering S3 (Suspend-To-RAM)
PSP: Prepare to enter sleep state 3... OK
SMU: Put system into S3/S4/S5
Timestamp - start of bootblock: 18446744070740509170
coreboot-4.12-512-g65779ebcf73f-dirty Thu Jun 4 22:38:17 UTC 2020 bootblock starting (log level: 8)...
Family_Model: 00810f81
PMxC0 STATUS: 0x200800 SleepReset BIT11
I2C bus 3 version 0x3132322a
DW I2C bus 3 at 0xfedc5000 (400 KHz)
Timestamp - end of bootblock: 18446744070804450274
VBOOT: Loading verstage.
FMAP: area COREBOOT found @ c75000 (3715072 bytes)
CBFS: Locating 'fallback/verstage'
CBFS: Found @ offset 61b80 size cee4
PROG_RUN: Setting MTRR to cache stage. base: 0x04000000, size: 0x00010000
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4b0b0d0d576fc42b1628a4547a5c9a10bcbe9d37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Add DW9768 VCM device and add its entry in the OV8856's _DSD
to allow the V4L2 driver to use the VCM functionality.
Also add ACPI entries for AT24 NVM device, this will enumerated
as a generic NVM device and not part of the V4L2 framework.
BUG=b:155285666
BRANCH=None
TEST=Build and able to see DW9768 and AT24 getting listed I2C3 lanes
and able to capture image using world facing camera.
Change-Id: I19e4a4107c5bc9d96f718d654df50e2705b98c03
Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Fix Puff and its variants to not shutdown the AP before the cr50 reboot.
This is the same approach that Sarien do to remain on during a cr50
cycle.
BUG=b:154071064
BRANCH=none
TEST=none
Change-Id: I5f92b4f769654b67c10c91e4cc7b2bce785e302f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42497
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Here we consolidate some of the dptf.asl duplication between
Puff and it's variants. Customizations can be done later
either as a direct copy or preferably via introducing a #define.
BUG=b:154071868
BRANCH=none
TEST=none
Change-Id: I35fa1e152adb5f04fb6ef1bd2448376cf9f37980
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Commit 86ba0d73f3 added VBIOS support for
Raven2 silicon and changed the VBIOS file names to the format including
the PCI device revision number. Upstream SeaBIOS expects the file to
have only the PCI vendor and device IDs in the CBFS file name, so it
doesn't find the VBIOS any more after that patch got applied. This patch
adds the path and CBFS file name to include the Picasso VBIOS a second
time under the CBFS file name SeaBIOS expects.
This is a workaround and not a clean solution, but avoids breakage.
It's separated from the rest of the Mandolin support, so it can just be
reverted after a proper fix is implemented.
https://chromium-review.googlesource.com/2015963/ in combination with a
links file in CBFS might solve the issue for most of the cases, but it's
not sure yet if for all, so a proper fix might require more than that.
BUG=b:153675508
Change-Id: I4d9042615965b6a2d9255c194cf23368264ffe54
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42433
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 0148fcb4 [Combine Broadwell Chromeboxes using variant board scheme]
incorrectly flipped the mic pin configs for verb NIDs 0x18 and 0x19,
so set them back to the correct values, which match the original
Chromium sources (where the NID identifiers in the pin config comments
were reversed, which was the source of the confusion originally.
Test: build/boot guado variant, verify mic attached to 3.5mm jack functional
Change-Id: I65b813c8f801303682762ce5a7446e07af117b9f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42518
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 0558d0c [mb/google/beltino/**/hda_verb.c: Correct pin configs]
incorrectly flipped the mic pin configs for verb NIDs 0x18 and 0x19,
so set them back to the correct values, which match the original
Chromium sources (where the NID identifiers in the pin config comments
were reversed, which was the source of the confusion originally.
Test: build/boot panther and zako variants, verify mic attached
to 3.5mm jack functional
Change-Id: I172a0bb299049d113a0272ee9c790b25b6242cad
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42499
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
fch_apic_routing is used as name of an array that init_tables()
populates with the APIC IRQ routing information. Also the fch_pirq array
where fch_apic_routing was used as struct name contains the IRQ mapping
for both PIC and APIC mode, so rename it to fch_irq_routing.
Change-Id: Iba7a2416c6e07cde1b8618bdabf31b00e3ca4dd1
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The PIC and APIC IRQ routing tables are pre-populated with PIRQ_NC in
init_tables(), so the fch_pirq table entries where both IRQ numbers are
set to fch_pirq are redundant and can be removed.
Change-Id: I0d9b4f25e12a66cf86d1ad541955c3d2fe336c5a
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This change adds support for SW CM. Add Operating System Capabilities
(_OSC) method to enable USB/DisplayPort/Inter-domain USB4 Internet
Protocol tunneling and enable PCIe tunneling as well. Remove Connect
Topology(CNTP) command because kernel driver directly works with SW CM
Thunderbolt firmware. Update _DSD method for USB4 support across XHCI
and PCIe root ports.
BUG=b:140645231
TEST=Check Type C device all ports connection/enumeration with SW CM.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I859c5075882e40d7be30d4ba88cc825886712b74
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Rename dptf.asl to dptf_common.asl under soc/intel/common/acpi path
to avoid any kind of confusion with another dptf.asl file under
soc/intel/common/acpi/dptf path. Sometime it's confusing to have
two dptf.asl files just one directory apart.
BUG=None
BRANCH=None
TEST=Build and boot on volteer system
Change-Id: I23d93719e23c0b7659ccb23e5d0868f879bc162c
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add unique new acpi device ids for dptf for Tiger Lake soc based platforms
and update volteer speficic dsdt.asl file accordingly. The Linux kernel
driver expects these new acpi device ids for dptf functionalities.
BUG=None
BRANCH=None
TEST=Build and boot on volteer system
Change-Id: I7dbb812c0fc0f5084c98cf2752ce7ddce8e4d50e
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42040
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Move uart_platform_base and uart_platform_refclk to their own
compilation unit to avoid preprocessor usage. The newly created
compilation unit is only added to the build when PICASSO_CONSOLE_UART
is selected.
Change-Id: I56911addc8c000a0772156e5166720867cdd26fe
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42517
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Kconfig 4.17 started using the $(..) syntax for environment variable
expansion while we want to keep expansion to the build system.
Older Kconfig versions (like ours) simply drop the escapes, not
changing the behavior.
While we could let Kconfig expand some of the variables, that only
splits the handling in two places, making debugging harder and
potentially messing with reproducible builds (e.g. when paths end up
in configs), so escape them all.
Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
The APU2 was using the soc/amd/common functions to do GPIO reads and
writes. The functions that were being used are getting eliminated in
the SOC directory, but since the APU isn't using the rest of that code
(as it's not using the rest of the SOC codebase), it proved to be
problematic to use the updated functions.
The solution I've put in place here is to pull everything needed for the
GPIO reads & writes into the gpio_ftns.c & h files.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ied39c114bdf3637977d21f56fd7db428c52e4706
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The option to have amdfw outside of CBFS used dd to write amdfw at a
given location overwriting anything that was there before, which may
cause the build to fail due to the FMAP header being overwritten
resulting in a not too obvious error that the image is a legacy image
without FMAP header.
Mandolin was the only board using this functionality, but I fixed the
placement of components in the flash image there, so that amdfw can just
be placed in CBFS avoiding those problems.
Change-Id: I0f3abab9d3939da43e1681d5cfe2c8d494402acf
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42438
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use LZ4 compression technique to compress FSP-S. This provides some
SPI ROM space savings (~36 KiB) in each CBFS. FSP-M is XIP and hence not
compressed. LZ4 is chosen over LZMA since the decompression saves
~25 ms for an extra overhead of ~1KiB.
LZ4 Compression:
fsps.bin 0xe6fc0 fsp 254262 LZ4 (290816 decompressed)
LZ4 Decompression:
17:starting LZ4 decompress (ignore for x86) 712,361 (1,072)
18:finished LZ4 decompress (ignore for x86) 750,695 (38,334)
LZMA Compression:
fsps.bin 0xe6fc0 fsp 253415 LZMA (290816 decompressed)
LZMA Decompression:
15:starting LZMA decompress (ignore for x86) 707,696 (1,150)
16:finished LZMA decompress (ignore for x86) 767,763 (60,067)
BUG=b:158034451
TEST=Build and boot volteer mainboard.
Change-Id: I91e33eb7b688b5383f3a0075a28ac21250314973
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42444
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use LZ4 compression technique to compress FSP-S. This provides some
SPI ROM space savings(~60 KiB) in each CBFS. FSP-M is XIP and hence not
compressed. LZ4 is chosen over LZMA since the decompression saves
~50 ms for an extra overhead of ~1.5 KiB.
LZ4 Compression:
fsps.bin 0xa9fc0 fsp 203423 LZ4 (262144 decompressed)
LZ4 Decompression:
17:starting LZ4 decompress (ignore for x86) 433,550 (1,154)
18:finished LZ4 decompress (ignore for x86) 461,620 (28,069)
LZMA Compression:
fsps.bin 0xa9fc0 fsp 202132 LZMA (262144 decompressed)
LZMA Decompression:
15:starting LZMA decompress (ignore for x86) 478,448 (1,174)
16:finished LZMA decompress (ignore for x86) 557,725 (79,277)
BUG=b:158034451
TEST=Build and boot waddledoo mainboard.
Change-Id: I416b1d91d7f4836b1e9c641b0fe07b39876364ba
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Use LZMA compression technique to compress FSP-S. This provides some
SPI ROM space savings(~27 KiB) in each CBFS. FSP-M is XIP and hence not
compressed. LZMA is chosen over LZ4 since it provides extra space
savings of ~1 KiB for the decompression overhead of ~7 ms.
LZMA Compression:
fsps.bin 0xd1fc0 fsp 190132 LZMA (217088 decompressed)
LZMA Decompression:
15:starting LZMA decompress (ignore for x86) 343,289 (417)
16:finished LZMA decompress (ignore for x86) 373,922 (30,632)
LZ4 Compression:
fsps.bin 0xd1fc0 fsp 191310 LZ4 (217088 decompressed)
LZ4 Decompression:
17:starting LZ4 decompress (ignore for x86) 345,676 (581)
18:finished LZ4 decompress (ignore for x86) 369,101 (23,424)
BUG=b:158034451
TEST=Build and boot helios mainboard.
Change-Id: Ic0d0d81c81eaa365f3dbfdd2e00ac76cea287387
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42446
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Upcoming variant boards will use 16 MiB SPI ROM. So add support for 16
MiB flash map descriptor.
BUG=b:155107866,b:152981693
TEST=Build different variant boards. Ensure that waddledoo which is using
32 MiB SPI ROM boots.
Cq-Depend: chrome-internal:3107306
Change-Id: I8a6868da3280a662ff3a30623804ff135e6cbfbc
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Remove unused cannonlake dptf.asl file and cleanup defines from apollolake
dptf.asl file as per soc/intel/common/acpi code changes for dptf.
BUG=None
BRANCH=None
TEST=Build and boot on the system
Change-Id: I4c8bf2bd5da9d5881e7690bff34816b19dd96072
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This reverts commit d5f1e0f973.
Reason for revert: FSP-S is now fixed to not touch the SPI
configuration registers. Thus, coreboot does not need to reconfigure
SPI after FSP-S has run.
BUG=b:153506142
TEST=Verified that SPI configuration registers look the same before
and after FSP-S has run. em100 works fine without any additional
changes in coreboot to reconfigure SPI.
Change-Id: I4832e62e0331aa39abe0cca7725915262bb2cf83
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Justin Frodsham <justin.frodsham@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If a UCSI event comes in when the EC is in S0ix mode then the kernel
driver attempts a transaction but fails and this can leave the system
in an unexpected state where the only wake source is the power button.
This change will not notify the UCSI driver if the EC is in S0ix mode
and instead keep track of the event and send it on resume.
BUG=b:157923800
TEST=tested on drallion system:
1. Put drallion system into suspend
2. Attach power supply
3. Ensure the system can wake with keypress
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I43acb089385d9b41ac955f053e409daad67423f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Temporary workaround for S0ix issues related to FSP's handling of 0 value.
When IomTypeCPortPadCfg is 0 FSP completely skips any flow related to this
value which seems to be causing issues with s0ix.
This is still being debugged and a final solution will be made when available
BUG=b:159151238
TEST=flash image with workaround to volteer and verify that s0ix
cycles correctly.
Change-Id: Id79dd1c49958389cdb666b3760abd821bc1973a8
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42268
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Shreesh Chhabbi <shreesh.chhabbi@intel.corp-partner.google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change includes uart.c in bootblock, romstage, ramstage and
verstage unconditionally because this file is handling more than just
the UART console configuration. This allows boards to take advantage
of picasso_uart_mmio_ops even if PICASSO_UART is not selected.
uart_platform_base and uart_platform_refclk mustn't be provided if
PICASSO_UART is unset, so add an #if around those functions.
BUG=b:158346697
TEST=Mandolin builds again.
Change-Id: If1173034b0d2ed32f77241768e1e8abb208aac3a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42339
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for enabling/disabling PCIe hot-plug via
a chip config option PcieRpHotPlug, which is copied to the corresponding
FSP-S UPD.
BUG=b:156879564
BRANCH=none
TEST=Boot Volteer/RVP with FSP log and check hotplug enabled/disabled
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I4c0187644b6ca9735f1b159e110e3466af14ff71
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41794
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add CFL defaults for VR TDC config and provide Iccmax for additional Xeon
CPUs tested on the Prodrive/Hermes board.
Based on the following Intel documents:
* Document Number 570805 (XEON E EDS Vol 1)
* Document Number 337344 (CFL Datasheet Vol 1)
* Document Number 571264 (CFL CNP PDG)
Change-Id: I681de076318fb647c44cc8b8c42eb297018cc540
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40856
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Read the PCH Strap Length field in FLMAP1 as described in the
"SPI Programming Guide" and print the number of fields specified there.
This code dumps the following straps:
* Intel GM45: 8 straps
* Intel C216: 72 straps
* Intel C240: 360 straps
Add a new function to easily set PCH straps, which is useful for debugging.
Change-Id: Ieb7891b214d82c984379794de9b3fe1a6d0d3466
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
When Linux is booted, the kernel reports
"do_IRQ: 1.55 No irq handler for vector"
So far it comes with payloads SeaBIOS and depthcharge, not with
Grub. We assume Grub does something to avoid this problem.
AMD bug tracker system (JIRA PLAT-21393) says the APs can not be set
EXTINT delivery mode.
In Intel 64 and IA-32 Architectures Software Developer’s Manual volume
3A, see chapter 10.5.1 Local Vector Table, it says:
"The APIC architecture supports only one ExtINT source in a system,
usually contained in the compatibility bridge. Only one processor in the
system should have an LVT entry configured to use the ExtINT delivery
mode."
Tested on mandolin (Picasso) board, the error in dmesg is gone.
The bug 153677727 has two parts.
1. Soft lockup
2. do_IRQ 1.55.
The soft lockup issued has been fixed by
https://review.coreboot.org/c/coreboot/+/41128
BUG=b:153677727
TEST=mandolin
Change-Id: I2956dcaad87cc1466deeca703748de33390b7603
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42219
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The call made at mp_ops.post_mp_init() generally
uses four different names. Unify these with followups.
smm_southbridge_enable(SMI_EVENTS)
smm_southbridge_enable_smi()
hudson_enable_smi_generation()
enable_smi_generation()
Furthermore, some platforms do not enable power button
SMI early. It may be preferred to delay the enablement,
but fow now provide global_smi_enable_no_pwrbtn() too.
Change-Id: I6a28883ff9c563289b0e8199cd2ceb9acd6bacda
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
LGA775 CPUs can have at most 4 threads, and Eaglelake supports them.
As this socket is also used by other chipsets, temporarily place this
symbol into the northbridge scope until all chipsets are factored out.
Change-Id: I6e01363d995e135815cc70779e0cd5baf806cf60
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41841
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The assumption up to this point was that if the system had an x86
processor, verstage would be running on the x86 processor. With running
verstage on the PSP, that assumption no longer holds true, so exclude
pieces of code that cause problems for verstage on the PSP.
As a generalization, remove all-y for CONFIG_ARCH_xx guarded
makefiles.
BUG=b:158124527
TEST=Build and boot on Trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ia7dcfed699ee1c0cd5a5250431c5f05bf6d8b9c7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add the AMD supplied code (modified to work with GCC) to the vendorcode
directory. Verstage will be running on the PSP as a userspace
application under the bootloader, which is what bl_uapp signifies.
AMD is still working on documentation for the entire PSP userspace
application interface.
BUG=b:158124527
TEST=Build & boot psp_verstage on Trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ie740c89afe2277eff279fc5c94f88ffd43a78a37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Because the PSP maps the MMIO addresses that are used to non-
deterministic addresses, the accesses need to be able to find
the address at runtime.
BUG=b:158124527
TEST=Build & boot with Trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I68305e0f31956c57bfdee42025bdfe938703e82d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42061
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Exclude pieces of console code from the vboot if running before
bootlock. The PSP verstage code will re-implement some of
these in its own code.
BUG=b:123887623
TEST=Build with following patches
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ifc9fb0810e0816fe0a68e52287eda6145043a619
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41815
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For AMD's family 17h, verstage can run as a userspace app in the PSP
before the X86 is released. The flags for this have been made generic
to support any other future systems that might run verstage before
the main processor starts.
Although an attempt has been made to make things somewhat generic,
since this is the first and currently only chip to support verstage
before bootblock, there are a number of options which might ultimately
be needed which have currently been left out for simplicity. Examples
of this are:
- PCI is not currently supported - this is currently just a given
instead of making a separate Kconfig option for it.
- The PSP uses an ARM v7 processor, so that's the only processor that
is getting updated for the verstage-before-bootblock option.
BUG=b:158124527
TEST=Build with following patches
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I4849777cb7ba9f90fe8428b82c21884d1e662b96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41814
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
A looong time ago when cache_as_ram.S was built into romstage,
the stage was also linked twice. First at a fixed low address
and then again relocated at the final execute-in-place address.
Change-Id: Ic624feef6794f2c24e38459a45583d84fc07a484
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When adding XIP stages on x86, the -P parameter was used to
pass a page size that covers the entire file to add. The same
can now be achieved with --pow2page and we no longer need to
define a static Konfig for the purpose.
TEST: Build asus/p2b and lenovo/x60 with "--pow2page -v -v" and
inspect the generated make.log files. The effective pagesize is
reduced from 64kB to 16kB for asus/p2b giving more freedom
for the stage placement inside CBFS. Pagesize remained at 64kB
for lenovo/x60.
Change-Id: I5891fa2c2bb2d44077f745619162b143d083a6d1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For add-stage command, --pow2page is equivalent of passing
-P log2ceil(sizeof stage). The sizeof stage can be hard to
determine in Makefile to be passed on the commandline.
Change-Id: If4b5329c1df5afe49d27ab10220095d747024ad6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41832
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
If there is no installed audio daughter board on volteer then the
HDA driver in the kernel will crash on resume. In order to prevent
this disable the PCI device when AUDIO=NONE probe match is true.
BUG=b:147462631
TEST=boot on volteer and ensure that the PCI device at 0:1f.3 is gone
Change-Id: I4a436e1b76418030bf635427e490b54a713fdd33
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41217
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
If the OS sets the target device state to D3, we need to clear it so we
can reestablish register access.
BUG=b:153001807
TEST=Boot trembyle with I2C powered off and see it power back on.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: If9bd1b7cfa7b8d074226c4dcdefc1a44cad8b940
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42325
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The legacy UARTs are supposed to default to off according to the
documentation (PPR for AMD Family 17h Model 18h). But legacy UART Range_0
is enabled after reset. The PSP might be enabling it or the documentation
might be wrong.
Having it enabled causes problems though. We have ACPI nodes defining
MMIO UARTs, and the kernel also probes for legacy UARTs. This results in
two drivers accessing the same device, one via MMIO and one via IO. I
suspect this was the cause of the garbage serial output.
Before the change you would see the following in the console:
[ 0.741108] serial8250: ttyS3 at I/O 0x2e8 (irq = 3, base_baud = 115200) is a 16550A
After this change, we no longer see it.
BUG=b:152079780, b:157858890
TEST=Boot trembyle and make sure serial is still working.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I9d837e449b961dbb55d1301d2107838e26b3f892
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The purpose of pci_early_bridge_init() is to temporarily configure
PCIe rootport (or PCI bridge) on bus 0 to configure PCI device BARs
on the secondary bus. Currently used and tested only with UART_OXPCIE.
Since those BARs do not reset on stage changes, it is not necessary
to redo those steps for verstage or postcar. Note that the option
does not really work with many of the later platforms where PCIe
pins/links/lanes are configured late in FSP-M or similar blob.
Change-Id: I148f44c76c61edcfd8ab1c8c531cd2e6ca343130
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42227
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>
Currently, configuring and reviewing DPTF parameters is difficult
because DPTF tables and methods are defined in static ASL files, and are
littered with #ifdefs which both define parameters and influence
behavior (e.g., whether a method is included or not). This patch train
is an effort to bring DPTF support to our ACPI DSDT/SSDT generation
framework.
This first patch is very minimal, and includes only creation of the
DPTF device (in the DSDT).
BUG=b:143539650
TEST=compiles (later tests get more comprehensive).
Change-Id: I14df9f422c911677aeea25552ac1822a9462c58a
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41883
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Correct a message of "Error: Can't add stage_cache 57a9e101 to imd".
ramstage is 0xffc90 and adding FSP-S (0x50000) failed. Increase the
reserved region of SMRAM to accommodate both images.
BUG=b:158704095
TEST=Boot Mandolin and check console log
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: I51595d80d4779e995ec2a26e395cf95d666a309e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42314
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, the logs are only checked, if retrieved locally. Moving it
after the if statement, now logs retrieved remotely are also checked.
The change in behavior is, that now all commands are executed first, so
before hitting this error, other errors might occur unrelated to the
console log.
Change-Id: I016bbde66c58a654042ad880c6007ddc1d143691
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch adds correct PL2 baseline setting and PsysPL2 for different
SKUs. There is no way to identify the barral jack power rating, the
assumption is following that ships with the product:
1. i3/i5/i7: 90W BJ
2. Celeron/Pentium: 65W BJ
For Type-C adapter, we don't have Pcritcial (10ms) data, keeps the
original settings as 90% of adapter rating for PsyspL2/PL4 and PL2
as min(PL2, 0.9n) where n is adapter rating power.
BUG=b:143246320
TEST=Run with U62 and Celeron CPU and ensure the PL2 settings are correct
Change-Id: Ib16d4f65707801b430f06892ab45ecfa7551593f
Signed-off-by: Tim Chen <tim-chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42281
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The Endeavour variant does not have a DisplayPort input so there's no
need to wait for it.
BUG=b:147830399
BRANCH=none
TEST=boot endeavour; check coreboot logs
Signed-off-by: Jeff Chase <jnchase@google.com>
Change-Id: I30c7c47f19a61ce66c6c923864d80870d2761859
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
ALIB function 1 needs to be called every time there is a change in
AC/DC state of the system. This change adds a wrapper method that can
be called by PNOT (method to notify system power state change) to
report to ALIB that system power state has changed i.e. AC <-> DC.
Additionally, this change drops the call to ALIB from _INI method
since the PWRS object might not be initialized correctly at that
point. Instead EC makes a call to PNOT when PWRS is initialized.
This wrapper also fixes the value of power state being passed into
ALIB. ALIB expects 0 = AC and 1 = DC. On the other hand, PWRS reports
1 as AC and 0 as DC. WAL1() takes care of inverting the PWRS state
before passing into ALIB.
BUG=b:157752693
TEST=Verified that WAL1() gets called on AC connect/disconnect.
Steps followed:
$ echo 1 > /sys/module/acpi/parameters/aml_debug_output
$ dmesg -w | grep ACPI
[ 76.306947] ACPI Debug: "EC: AC DISCONNECTED"
[ 76.307064] ACPI Debug: "ALIB call: func 1 params 0x03 0x00 0x01"
[ 82.264946] ACPI Debug: "EC: GOT PD EVENT"
[ 82.539833] ACPI Debug: "EC: GOT PD EVENT"
[ 82.753721] ACPI Debug: "EC: GOT PD EVENT"
[ 82.843676] ACPI Debug: "EC: GOT PD EVENT"
[ 82.970596] ACPI Debug: "EC: AC CONNECTED"
[ 82.970659] ACPI Debug: "ALIB call: func 1 params 0x03 0x00 0x00"
[ 83.047598] ACPI Debug: "EC: GOT PD EVENT"
[ 84.804733] ACPI Debug: "EC: GOT PD EVENT"
[ 86.317934] ACPI Debug: "EC: GOT PD EVENT"
[ 86.385920] ACPI Debug: "EC: GOT PD EVENT"
[ 86.515830] ACPI Debug: "EC: AC DISCONNECTED"
[ 86.515922] ACPI Debug: "ALIB call: func 1 params 0x03 0x00 0x01"
[ 90.089062] ACPI Debug: "EC: GOT PD EVENT"
[ 90.357914] ACPI Debug: "EC: GOT PD EVENT"
[ 90.573812] ACPI Debug: "EC: GOT PD EVENT"
[ 90.662744] ACPI Debug: "EC: GOT PD EVENT"
[ 90.788706] ACPI Debug: "EC: AC CONNECTED"
[ 90.788835] ACPI Debug: "ALIB call: func 1 params 0x03 0x00 0x00"
[ 90.865675] ACPI Debug: "EC: GOT PD EVENT"
[ 92.621793] ACPI Debug: "EC: GOT PD EVENT"
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I1f2ade28ca35378ebf4647d8df3d2ea4d0b08096
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This allows to remove references to CONFIG_DCACHE_RAM entries in
most cache_as_ram.S files. While Kconfig variable names appear
for every stage, linker symbol names will only appear in stages
they are valid in.
Also, linker scripts have LOG2CEIL which comes in handy to enforce
MTRR alignments.
Change-Id: I2fef3546d2bfea2d4d8f87aaf8376e5566fd6aaa
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30872
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates memlayout.ld for Picasso to place all early
stages (bootblock, romstage, FSP-M, verstage) and data buffers (vboot
workbuf, APOB, preram-cbmem console, timestamp, early BSP stack) at
the bottom of DRAM starting at 32MiB. This uses static allocation for
most components by defining Kconfig variables for base and size. It
relies on the linker to complain if any of the assumptions are broken.
This also allows romstage to use linker symbols for
_early_reserved_dram and _eearly_reserved_dram to store information in
CBMEM about the early DRAM usage by coreboot before ramstage starts
execution. This allows ramstage to reserve this memory region in BIOS
tables so that S3 resume can reuse the same space without corrupting
OS memory.
BUG=b:155322763
TEST=Verified memory reported by coreboot:
Writing coreboot table at 0xcc656000
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-0000000001ffffff: RAM
4. 0000000002000000-000000000223ffff: RESERVED
5. 0000000002240000-00000000cc512fff: RAM
6. 00000000cc513000-00000000cc6bffff: CONFIGURATION TABLES
7. 00000000cc6c0000-00000000cc7c7fff: RAMSTAGE
8. 00000000cc7c8000-00000000cd7fffff: CONFIGURATION TABLES
9. 00000000cd800000-00000000cfffffff: RESERVED
10. 00000000f8000000-00000000fbffffff: RESERVED
11. 0000000100000000-000000042f33ffff: RAM
12. 000000042f340000-000000042fffffff: RESERVED
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I009e1ea71b5b5a8e65eba16911897b2586ccfdb6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This change drops the check for IS_TOP_ALIGNED_ADDRESS() before
setting offset to 0 in cbfstool_convert_fsp(). If the user provides a
baseaddress to relocate the FSP to, then the offset should be set to 0
since there is no requirement on where the file ends up in cbfs. This
allows the user to relocate the FSP to an address in lower DRAM.
BUG=b:155322763
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ibeadbf06881f7659b2ac7d62d2152636c853fb9f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change copies src/arch/x86/memlayout.ld file to
src/soc/amd/picasso/ and sets MEMLAYOUT_LD_FILE config variable to
point to this newly added file. Unused elements from the memlayout.ld
file are dropped and path to early_dram.ld is updated to include the
one from src/arch/x86.
BUG=b:155322763
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I59bf5f93b712407ddcc9fb8a46167936c6c28a76
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows
SoC/mainboard to provide a linker file for the platform. x86 already
provides a default memlayout.ld under src/arch/x86. With this new
Kconfig variable, it is possible for the SoC/mainboard code for x86 to
provide a custom linker file as well.
Makefile.inc is updated for all architectures to use this new Kconfig
variable instead of assuming memlayout.ld files under a certain
path. All non-x86 boards used memlayout.ld under mainboard
directory. However, a lot of these boards were simply including the
memlayout from SoC. So, this change also updates these mainboards and
SoCs to define the Kconfig as required.
BUG=b:155322763
TEST=Verified that abuild with --timeless option results in the same
coreboot.rom image for all boards.
Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds memory parts used by variant voxel to
mem_list_variant.txt and generates DRAM IDs allocated to these parts.
This variant is not yet supported by coreboot but DRAM IDs need to be
generated for it. In the coming days, variant voxel will be added to
coreboot.
BUG=b:157732528
Change-Id: I8780beec987deb8fed11bb8f84275dcba4768514
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41994
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The current test framework builds the test code without any warnings at
all, which isn't great -- we have already slipped in some cases of
non-void functions not returning a defined value, for example. It would
likely be overkill to try to use all the same warnings we use for normal
coreboot code (e.g. some stuff like -Wmissing-prototypes makes cmocka's
__wrap_xxx() mock functions unnecessarily cumbersome to work with, and
other things like -Wvla may be appropriate for firmware but is probably
too aggressive for some simple test code). Therefore, let's just add
some of the stuff that points out the most obvious errors.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4d9801f52a8551f55f419f4141dc21ccb835d676
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
For Volteer mainboard, this patch set optimized values for PCH external
VR settings and ext rail voltage/current, to achieve better power
savings in sleep states.
v1p05 and vnn power rails can be used as an alternative source
by-passing vccin_aux during Sx. This by-pass feature, enables us to
shutdown vccin_aux rail which is higher voltage rail compared to v1p05
and vnn. These both rails were disabled by default in FSP. Changes in
this patch are:
1. v1p05 and vnn rails are enabled and enabled supported voltage types
in S0i1, S0i2, S0i3, S3, S4, S5 states. They were disabled by default.
2. Icc Max for v1p05 changed to 500 mA from default 100 mA.
3. vnn rail's voltage is changed to 5 V from default 4.2 V.
BUG=None
BRANCH=None
TEST="Build and boot volteer and check VR settings with Intel ITP-XDP
debugger and verify approx 250 mW power savings in Sx"
Signed-off-by: Venkata Krishna Nimmagadda <venkata.krishna.nimmagadda@intel.com>
Change-Id: Ib46423872c956af9aaa92902fce552d5447237c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42223
Reviewed-by: Venkata Krishna Nimmagadda <Venkata.krishna.nimmagadda@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change reconfigures SPI speeds after FSP-S has run since
FSP-S is currently configuring the SPI frequency when it should
not. Until FSP-S behavior is fixed, this workaround needs to be
applied.
BUG=b:153506142
TEST=Verified that em100 works fine.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id9b8330c6f82c7162ff91e8cc10160fdd8cfedab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Update DPTF_TSR2_SENSOR_ID to 2. Fixes the issue where TSR1 and
TSR2 have the same DPTF_TSR#_SENSOR_ID value causing them to
report the same temperature under /sys/class/thermal
and also swap TSR0 and TSR1 in DTRT to match physical sensor
in volteer schematics
BRANCH=None
BUG=b:149722146
TEST=On volteer system check TSR1 and TSR2 temperatures, should
report different values
`cat /sys/class/thermal/thermal_zone[3,4]/temp`
Also verify other TSRs using `cat /sys/class/thermal/thermal_zone*/temp`
and `ectool tempsinfo all ; ectool temps all`
Signed-off-by: Deepika Punyamurtula <deepika.punyamurtula@intel.com>
Change-Id: Idc5f35e4faf59b0ee726eb32a08eab4654fb342d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42232
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 9ff4029db9.
Pulling the toplevel Makefile into a tiny one has all sorts of side
effects. For instance, the toplevel (random) .config is also included
so the results depend on the board that is selected there. What finally
broke it is a line that is unconditionally printed for AMD Picasso
boards resulting in lots of lines like this:
skipping LENOVO_W520 because we're missing compilers for \
(Adding PSP c7ce61492157d3237f679c4a40a08b79 \
.../coreboot/3rdparty/amd_blobs/picasso/PSP/PspBootLoader_prod_RV.sbin)
While both issues, the random .config and amd/picasso, could be worked
around easily, it seems hard to predict what other pitfalls are lurking
in the Makefile inclusion. Also, the problem solved by its inclusion
can be fixed by a much simpler `make .xcompile`.
Change-Id: I2ff70f561d717eb30e5f3c06c83e83468e174ec5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Selecting VBOOT_LID_SWITCH under BOARD_GOOGLE_BASEBOARD_HATCH creates a
requirement for VBOOT, and prevents building in the non-vboot/non-ChromeOS
case. As this symbol is already selected by CHROMEOS below, there's no need
for the baseboard (and only one of the two) to select it, so don't.
Change-Id: I060e82185997bce451648173dd97dd6a3d5d237f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Some cases could not be factored out while keeping reproducibility.
Also mark some potential bugs with a FIXME comment, since fixing them
while also keeping the binary unchanged is pretty much impossible.
Tested with BUILD_TIMELESS=1, Asus P8Z77-V LX2 does not change.
Change-Id: Iafe62d952a146bf53a28a1a83b87a3ae31f46720
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The ASSERT() macro depends on the line number, so changing the line it
appears in breaks reproducibility testing using BUILD_TIMELESS=1.
Work around this problem by placing the `pch_pcie_acpi_name` function,
which contains this macro, at the beginning of the file. This allows
refactoring the rest of the code without affecting the ASSERT() macro.
Change-Id: I2e0432ec9ae6c7d033fc7495afb3a71fe7e77729
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Picasso doesn't really make use of the common mrc_cache driver because
of the PSP/ABL requirements for APOB NV data. The APOB NV data
gets consumed by PSP/ABLs before x86 comes out of reset. Hence, we cannot
really add any metadata to this saved data or use multiple slots as
done by the default MRC cache driver
(CACHE_MRC_SETTINGS). Additionally, FSP-M requires access to this APOB
NV data which coreboot needs to pass in from different locations
depending upon boot mode:
1. Non-S3 boot: PSP/ABLs store APOB NV data in DRAM at predetermined
location which is present in BIOS directory table.
2. S3 boot: PSP/ABLs do not store APOB NV data in DRAM.
Thus, coreboot needs to set FSP-M UPD NvsBufferPtr as the DRAM
location in non-S3 boot and the address of RW_MRC_CACHE on SPI flash
in case of S3 resume.
This change enables MRC cache support in Picasso in order to meet the
above requirements.
1. NvsBufferPtr is set based on boot mode.
2. APOB NV data is not stashed to CBMEM. Instead it is written right
away to SPI flash in romstage.
BUG=b:155990176
Change-Id: I8661a4cf2d34502967e936bf22a13f6f1b88e544
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This change moves the check for NvsBufferPtr in S3 resume case to
happen just before FSP-M is called. This allows SoC/mainboard code to
set NvsBufferPtr if it doesn't use the default MRC cache driver.
BUG=b:155990176
Change-Id: Ia272573ad7117a0cb851f0bfe6a4c7989bc64cde
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42109
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
CB:41612 added a new set of tools for generating SPDs for TGL and JSL
based mainboards. This change adds relevant documentation to
coreboot-4.13 release notes.
Change-Id: I168adad25df9195dec64e8104f2dbe992eebddc6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42092
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From `Documentation/coding_style.md`:
> This does not apply if only one branch of a conditional statement is a
> single statement; in the latter case use braces in both branches:
Change-Id: I5672949e587a9c0e4efa01521a659e4c224085d0
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42200
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Once we support building stages for different architectures,
such CONFIG(ARCH_xx) tests do not evaluate correctly anymore.
Not strictly required for binaryPI boards, but do this for
consistency.
Change-Id: Id0bbbfb6f695c4bb920bc57a1e9362a23884efb3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Setting the default values for GPIO community power management, causes
issues in detecting TPM interrupts. So to avoid that GPIO PM has to be
disabled in devicetree. But for S0ix it is needed. This patch implements
a workaround in ASL code to enable GPIO PM on S0ix entry and disable it
on S0ix exit.
This patch adds the following three platform specific methods.
1. MS0X to enable power management features for GPIO communities on
low power mode entry and disables it on exit.
2. MPTS to enable power management features for GPIO communities when
preparing to sleep.
3. MWAK to disable power management features for GPIO communities on
waking up.
BUG=b:153847814
TEST=Verify S0ix is working. GPIO PM configuration is upadated on low
power mode entry and exit.
Change-Id: I7225b78ab2ac5bf17f93230cd85cd21e836d807d
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41502
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SPD sources for Dedede and Volteer are being auto-generated by SPD
tools now, and so we can remove SPD_SOURCES from Makefile.inc for
those templates. That makes Makefile.inc empty for those reference
boards, so remove Makefile.inc from the templates.
BUG=b:158492307
BRANCH=None
TEST=Create new variant of volteer, waddledee, and waddledoo, and
verify that we can still build the coreboot image.
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Iba5264384302300cc8d2256a6b43f3353770154a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42204
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds Hot-Plug and power management event handers(_L61 &
_L69) respectively for Thunderbolt in the GPE scope. The _L61 method
invokes sub-method HPEV to support Hot-Plug wake event from Thunderbolt
PCIe root ports. This method intercepts Presence Detect Changed
interrupt and make sure the L0s is disabled on empty slots. The _L69
method checks and clears root port's PME SCI status.
BUG=b:156435065
TEST=Verified multiple hot plug successfully with Lenovo dock.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I022cf4aa3f2ee459b9dc87849494e10755d995c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ACP device sits behind a bridge. Despite the logs indicating
the bridge is likely hooked up, there's some unusual behavior of
writes not sticking. Aside from the speculation of what's causing
the issues the initialization of the device should occur at init()
because of these potential dependencies.
BUG=b:155882600
Change-Id: I8fa83d7d1d4f356c56971d4175a2ae6497a92fb8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42231
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GCC 10 GNAT toolchain uses a new exception handler ABI, so older
GNAT cannot be built with GCC 10. This patch backports the new
exception handler in libgnat to make GNAT able to be built.
The libgnat patch doesn't remove the old exception handler, so it can
still be built with older compilers.
The cross toolchain can now be built with GCC 10.1.0 in Arch Linux
(with the latest IASL in CB:38907 that can be built in Arch), and the
toolchain can build a working coreboot image with libgfxinit for HP
EliteBook 2560p.
The original and patched crossgcc built with Debian 10.4 GCC 8.3.0,
and the patched crossgcc built with Arch GCC 10.1.0 generate identical
coreboot images with `make BUILD_TIMELESS=1`.
Change-Id: I757158056bf4698d3c68715e026c226615bc70a1
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42158
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the comments of
https://review.coreboot.org/c/coreboot/+/41719
, which is about Microcode patch for amd/picasso.
Change the code with the same way.
The changes include:
1. combine the microcode_xxx.c and update_microcode.c
into one source.
2. Redefine the microcode updating function to eliminate
the parameter. Get the revision ID in the black box.
Reduce the depth of function calls.
3. Get the revision ID by bitwise calculation instead of
lookup table.
4. Reduce the confusing type casts.
5. Squash some lines.
We do not change the way it used to be. The code assume
only one microcode is integrated in CBFS. If needed in future,
41719 is the example of integrating multiple binaries.
And, 41719 depends on the definition in this patch.
Change-Id: I8b0da99db0d3189058f75e199f05492c4e6c5881
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Setting preferred_pm_profile under sb/ or soc/ overrides the
default determined from SYSTEM_TYPE_xx (or possibly
SMBIOS_ENCLOSURE_TYPE with followup work). This is not desireable.
With the overrides removed, AMD platforms will switch from
PM_UNSPECIFIED to PM_DESKTOP as their preferred profile.
Boards need to either select a pre-defined SYSTEM_TYPE_xx or provide
board-specific mainboard_fill_fadt() should they need to change this.
As they already select SYSTEM_TYPE_LAPTOP, following boards
will change to PM_MOBILE:
google/kahlee
hp/pavilion_m6_1035dx
lenovo/g505s
Change-Id: I45c4a495a4bf3422adae9e22a6e436adef252e77
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42032
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
The platform_cfg.h files under mainboard/ are a legacy configuration
mechanism used with AGESA family14 boards.
With this change following boards will have FADT preferred_pm_profile
changed from PM_UNSPECIFIED to PM_DESKTOP:
amd/inaqua
amd/south_station
amd/union_station
asrock/e350m1
Change-Id: Ic28761eb238dbbaf3e8f820a29ec64b89f12bf53
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Setting preferred_pm_profile under sb/ overrides the
default determined from SYSTEM_TYPE_xx (or possibly
SMBIOS_ENCLOSURE_TYPE with followup work). This is not desireable.
Boards need to either select a pre-defined SYSTEM_TYPE_xx or provide
board-specific mainboard_fill_fadt() should they need to change this.
As they already select SYSTEM_TYPE_LAPTOP, following boards
will maintain PM_MOBILE:
lenovo/t400
lenovo/x200
roda/rk9
Following will change to PM_DESKTOP:
aopen/dxplplusu
asus/p2b
emulation/qemu-i440fx
emulation/qemu-q35
Change-Id: I2986eb0a8abc94507e9797cc8b64611ae4bd888a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Use a local variable for the ResourceTemplate in the _CRS methods
instead of the RBUF object. When using RBUF, iasl complained that the
_CRS methods need to be serialized, since objects were created in there.
Since those are only used as local variables, just use local variables
for this.
TEST=iasl stops complaining about those methods not being serialized and
Linux still boots and there aren't any related ACPI errors or warnings.
Change-Id: Ic43fcaed5a8b19dbd5634c17f34a159803ba8577
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42207
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
- Move the GPIOs that are likely to be volteer-specific (mostly
peripherals) to reside in variants/volteer/gpio.c so that
variants don't have to override too many GPIO settings.
- Modify malefor's gpio.c to adjust for the changes to baseboard's
gpio.c.
- Remove unused GPP_C3 (USB4_SMB_SCL) and GPP_C4 (USB4_SMB_SCA)
settings.
- Remove unused GPP_D9, GPP_D10, GPP_D11, and GPP_D12 settings.
- Remove unused GPP_E8 (SLP_S0IX), COEX, WWAN, and SNDW related
settings for malefor.
- Remove unused GPP_R4 (HDA_RST_L) setting.
BUG=b:157597158
TEST="emerge-volteer coreboot chromeos-bootimage", flash and boot
volteer SKU4 to kernel.
Change-Id: Ib2f384f539d55a3a8d4a7608336ef22aca3d8c4f
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41797
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The Connect Topology Command(CNTP) is sent with default timeout value
(0x1388) along with FW CM. The CNTP is supposed to be skipped while
using SW CM. While transition from FW CM to SW CM, the default timeout
value could cause boot time delay up to ~10 seconds. Set this FSPS UPD
ITbtConnectTopologyTimeoutInMs to be 0 in order to avoid the 10 seconds
delay. Future FSP release will evaluate this ITbtConnectTopologyTimeoutInMs
value. While FSP finds this UPD value being 0, FSP will skip sending CNTP.
BUG=b:155893566
TEST=Built image with SW CM Thunderbolt firmware and verified no
outstanding delay time while using FSP v3197 during boot to kernel.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I47e3519fd818cb56e6abd16464d8370ffddabc5b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42056
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With SoundWire and USB4 enabled some boards are running out of
memory with all of the ACPI devices and properties. Increase
the heap size to accommodate.
BUG=b:147462631
TEST=Successfully boot on volteer SKU5 board with SoundWire enabled,
before boot was failing with "Error! memalign: Out of memory"
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I0245bdfad93b381871514578e66640e7fe6fa5c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
This patch adds correct PL2 baseline setting and PsysPL2 for different
SKUs. There is no way to identify the barral jack power rating, the
assumption is following that ships with the product:
1. i3/i5/i7: 90W BJ
2. Celeron/Pentium: 65W BJ
For Type-C adapter, we don't have Pcritcial (10ms) data, keeps the
original settings as 90% of adapter rating for PsyspL2/PL4 and PL2
as min(PL2, 0.9n) where n is adapter rating power.
BUG=b:143246320
TEST=Run with U62 and Celeron CPU and ensure the PL2 settings are correct
Signed-off-by: Gaggery Tsai <gaggery.tsai@intel.com>
Change-Id: If7de614d58366158a566563990ee1ecc8c0110bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This reverts commit 04506e2987.
Turned out that `dev->command` is only a `u8` and the way it's used
here is wrong: It is not supposed to reflect the state of the register
but only gathers (lower) bits to be enabled during allocation.
Change-Id: Iacd2b753939e8adcf5aedd4b9cf101638a324aa6
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42163
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 5ac723e (nb/intel: Fix 16-bit read/write PCI_COMMAND register)
uses `pci_read_config8` to read the PCI command register, which does not
correspond with what has been stated in the commit message. Moreover, it
potentially breaks things, as the upper byte of the PCI command register
is now being cleared.
So, restore the original behaviour of the code, using 16-bit accesses.
Fixes: 5ac723e (nb/intel: Fix 16-bit read/write PCI_COMMAND register)
Change-Id: Id2c42ea8551a2fa2fa5c64e8fff8940d8304fbe0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42148
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>
The max98357a_platform_driver will turn on/off the speaker enable gpio
based on use, so configure it low to save power.
BUG=None
TEST=Built dedede and tested speaker playback working.
We are seeing a power saving of ~10mW.
Change-Id: I070679457b06cb82633c1197b893a5d89c8b2cf0
Signed-off-by: Usha P <usha.p@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
As per JEDEC spec, manufacturer part name should be set to
blank (0x20). This change updates gen_spd.go to set bytes 329-348 as
0x20 and regenerates SPDs for TGL and JSL.
Change-Id: I6af18d89afd7264cec7e54b38e95df83d55aa058
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42023
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The orientation, etc. -switch properties are supposed to use the
connector device (underneath the MUX device) that belongs to the port
number in question. This patch finds the CONx device and uses that
to pass to the acpigen API.
BUG=b:154620502
TEST=on Volteer, dump SSDT and verify the *-switch properties point to
\_SB.PCI0.PNC.MUX.CON0 and CON1
Change-Id: Ie65c2d750f3d9f83285e0e4cc9642110c804bbad
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42045
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
A function pci_dev_disable_bus_master() is created. This function
can be used to disable Thunderbolt PCIe root ports, bridges and
devices for Vt-d based security platform at end of boot service.
BUG=None
TEST=Verified PCIe device bus master enable bit is cleared.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ie92a15bf2c66fdc311098acb81019d4fb7f68313
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
All variants are overriding soc_common_config, so source it from
overridetree and remove entry from baseboard devicetree.
Only keeping chipset lockdown config in baseboard which will be
common across all the variants.
BUG=None
BRANCH=None
TEST=Checked code compilation and lockdown config is applied to all variants
Change-Id: I23714b721a6bb0bac785f046586790a98dc5b646
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
When MRC cached data update is performed, messages are written to
event log, which is flash based. For system that does not have flash
based event log, the messages are lost.
Added corresponding BIOS_DEBUG messages.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I1ef4794151fea7213c8317ddc898b0e37da280b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41981
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change allows treating the PMC as a 'hidden' PCI device on Jasper
Lake, so that the MMIO & I/O resources can be exposed as belonging to
this device, instead of the system agent and LPC/eSPI.
Change-Id: Ie07987c68388d03359c43f64a849dc6e3f94676e
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
While working on psp_verstage, I noticed that this file had a number of
unnecessary includes. Remove them.
BUG=b:158124527
TEST=Build & boot psp_verstage on trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I32188e2dda39ece9dc98d0344824d997a2e80303
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Currently, having libgfxinit try to enable VGA will result in a hang.
On the Asrock B85M Pro4, DDI E (VGA) was not being enabled in coreboot,
so it did not hang. However, this renders Linux's i915 driver unable to
use VGA at all. In absence of monitors with digital inputs, this is bad.
To work around this problem, mark DDI E as enabled, and comment out VGA
from gma-mainboard.ads for the time being. This allows one to use a VGA
monitor, even if it only works after Linux drivers have taken over.
Change-Id: Idd6a9e8515a1065ad3c6ddf136896fef9f0fa732
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner
Port commit d7b88dcb (mb/google/x86-boards: Get rid of power button
device in coreboot) to AMD AGESA Hudson boards.
No idea, if this is correct for the two laptops. The Lenovo G505s also
incorrectly defines two power buttons.
[ 0.911423] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[ 0.911434] ACPI: Power Button [PWRB]
[ 0.911493] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[ 0.912326] ACPI: Power Button [PWRF]
If the generic power button device is needed, the POWER_BUTTON flag
should be set in FADT.
The GPE ACPI code seems to originate from commit 806def8c (I missed the
svn add on r3787. These are the additional files., Add AMD dbm690t ACPI
support.), and was copied over.
Change-Id: I88950e15faf1b90ca6e688864bac40bf9779c32e
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Port commit d7b88dcb (mb/google/x86-boards: Get rid of power button
device in coreboot) to AMD AGESA Hudson boards
(SOUTHBRIDGE_AMD_PI_AVALON).
The GPE ACPI code seems to originate from commit 806def8c (I missed the
svn add on r3787. These are the additional files., Add AMD dbm690t ACPI
support.), and was copied over.
Change-Id: Ibeec73c15f2282f7ab0be88f96693bcb551b3e45
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
This change adds device_operations for UART MMIO devices that provides
following operations:
1. uart_acpi_name: Returns ACPI name of UART device. Generation of
UART device node is not yet moved to SSDT, but will be done in
follow-up CLs.
2. scan_bus: Uses scan_static_bus to scan devices added under the UART
devices. This allows mainboard to add devices under the UART MMIO
device.
Change-Id: I18abbe88952e7006668657eb1d0c177e53e95850
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
According to the Wilco EC spec the BTSC bit of PWSR is always cleared
when PWSR is read so that battery status change events are only
triggered one time. Testing of the Wilco EC has verified this behavior.
This changes the way in which the battery status change bit is used from
checking the bit state against the previous value to always issuing a
battery event when the BTSC bit is set. The other bits in PWSR indicate
state directly and do not behave like the BTSC bit.
BUG=b:157113138
TEST=Deploy on Drallion and verify that battery events are generated
BRANCH=drallion, sarien
Signed-off-by: Mathew King <mathewk@chromium.org>
Change-Id: I8fbf2ee1158ddd790b04a20b1eb27a6cce4f5c81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Enable Cr50 update in recovery mode, so that we can at least still
update the process for most cases (that an update is pending in recovery
mode is not impossible but should be unlikely in the field).
Leave manual recovery unaffected so at least that would still work even
if Cr50 wedges in a weird way that it thinks it has an update on every
boot or something.
Setting the recovery_reason to VB2_RECOVERY_TRAIN_AND_REBOOT allows the
update to be applied.
BUG=b:154071064
BRANCH=none
TEST=builds
Thanks to Julius Werner for the suggested fix.
Change-Id: Iba341a750cce8334da4dcf6353ca8cd1268d170f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This change adds memory parts used by variant wheelie to
mem_list_variant.txt and generates DRAM IDs allocated to these parts.
BUG=b:157862308
Change-Id: I53f6f5c832cd40068a6d4379ace849f6e8ad7a91
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41990
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GENERIC_SPD_BIN assumes that the SPDs are all placed in mainboard and
have .spd.hex as the suffix. Disable GENERIC_SPD_BIN for dedede as it
already provides its own rules for SPD inclusion. In follow up
changes, GENERIC_SPD_BIN can be re-enabled by updating gen_spd.go tool
to use similar suffixes and allowing different paths to be provided
for SPD by mainboard.
Change-Id: If10144e0b2bd67884af69f60e5117e388a3ae5da
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42054
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds mem_list_variant.txt that contains the list of
memory parts used by waddledoo and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all dedede variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: MT53E512M32D2NP-046 WT:E
Byte# Current New Explanation
4 0x15 0x16 This part has only 1 die. Hence,
density per die is 16Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
9 0x40 0x00 Unused by MRC.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xFF as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Additionally, manufacturer name bytes are set to 0.
Part: NT6AP256T32AV-J2
Waddledoo started assigning DRAM part IDs from 1. So, this change
fills in Nanya part as ID 0 (though it is currently unused).
Change-Id: I3879c4f3ad942eb349b52aad397333f576599bbd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change adds mem_list_variant.txt that contains the list of
memory parts used by wheelie and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all dedede variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: MT53E512M32D2NP-046 WT:E
Byte# Current New Explanation
4 0x15 0x16 This part has only 1 die. Hence,
density per die is 16Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
9 0x40 0x00 Unused by MRC.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xFF as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Additionally, manufacturer name bytes are set to 0.
Change-Id: If307bfb1d376e32af08af4f020f9e125f6a415dd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change adds mem_list_variant.txt that contains the list of
memory parts used by waddledee and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all dedede variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: MT53E512M32D2NP-046 WT:E
Byte# Current New Explanation
4 0x15 0x16 This part has only 1 die. Hence,
density per die is 16Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
9 0x40 0x00 Unused by MRC.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xFF as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Additionally, manufacturer name bytes are set to 0.
Part: NT6AP256T32AV-J2
Byte# Current New Explanation
4 0x14 0x15 This part has only 1 die. Hence,
density per die is 8Gb.
6 0x90 0x04 1 die in package and 2 channels per
die.
Manufacturer name bytes are set to 0.
Change-Id: I7a68a29ca3632e22f3960c9fc44acf3ce4f87c9c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change adds the following memory parts to LP4x global list and
generates SPDs using gen_spd.go for TGL and JSL:
1. MT53E512M32D2NP-046 WT:E
2. K4U6E3S4AA-MGCR
3. H9HCNNNCPMMLXR-NEE
4. K4UBE3D4AA-MGCR
BUG=b:157862308, b:157732528
Change-Id: Ib7538247d39dfe5faab277d646f87f09103d6969
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41989
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that volteer is moved to using the auto-generated SPDs, we no
longer need the spd/ folder under each variant. Hence, this change
drops the spd/ folders and the SPD files within them.
BUG=b:156126658
Change-Id: Icb36adeb11fd68a84df5b225db32fb8d840a530f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41619
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds mem_list_variant.txt that contains the list of
memory parts used by volteer and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: K4U6E3S4AA-MGCL
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
Part: K4UBE3D4AA-MGCL
Byte# Current New Explanation
6 0xB5 0xB4 Signal loading is not used by
MRC. Set bits 1:0 to 00.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
Part: H9HCNNNBKMMLXR-NEE
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. tckMin is
calculated as (1/4267)*2 which comes
out to be 0.46871. Some datasheets
round this down to 0.468 and others
round it up to 0.469. JEDEC spec uses
0.468. As per that, this value comes
out to be 0xE0.
Part: H9HCNNNFAMMLXR-NEE
Byte# Current New Explanation
4 0x15 0x16 As per datasheet, density is 16Gb per
logical channel. So value should be 0x16.
6 0xF9 0xB8 This device has 4 logical dies
instead of 8. Also, signal loading is
not used by MRC.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
20,21, 0x92,0x55, 0x12,0x29, As per datasheet, part supports CAS
22 0x00 0x15 latencies 6,10,16,22,26,32,36,40. So value
should be 0x12,0x29,0x15.
24 0x8C 0x96 taa is .468ns * CAS-40 which results
in byte 24 being 0x96 as per datasheet.
29,30 0xE0,0x0B 0xC0,0x08 As per datasheet, this corresponds to
280ns in MTB units which is 0x08C0.
31,32 0xF0,0x05 0x60,0x04 As per datasheet, this corresponds to
140ns in MTB units which is 0x04C0.
123 0x00 0xE2 Fine offset for taa. Expected value
is 0xE2 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. tckMin is
calculated as (1/4267)*2 which comes
out to be 0.46871. Some datasheets
round this down to 0.468 and others
round it up to 0.469. JEDEC spec uses
0.468. As per that, this value comes
out to be 0xE0.
Part: MT53E1G32D2NP-046 WT:A
Byte# Current New Explanation
4 0x15 0x16 As per datasheet, density is 16Gb per
logical channel. So value should be 0x16.
5 0x21 0x29 As per datasheet, this part has 17row
address bits and 10column address
bits. This results in 0x29.
6 0xB5 0x94 This device has 2 logical dies. Also,
MRC does not use signal loading.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
12 0x0A 0x02 As per datasheet, this is 1rank and
16-bit wide channel. So, value should
be 0x02.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
29,30 0xC0,0x08 0xE0,0x0B As per datasheet, this corresponds to
380ns in MTB units which is 0x0BE0.
31,32 0x60,0x04 0xF0,0x05 As per datasheet, this corresponds to
190ns in MTB units which is 0x05F0.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:147321551,b:155423877
Change-Id: I3998b2cd91020130bacf371fce9b0d307304acbe
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This change adds mem_list_variant.txt that contains the list of
memory parts used by halvor and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: H9HKNNNCRMBVAR-NEH
Byte# Current New Explanation
4 0x16 0x15 As per datasheet, density is 8Gb per
logical channel. So value should be 0x15.
6 0xB9 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00. 2 channels 2
dies. Hence, 0x94
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
29,30 0xE0,0x0B 0xC0,0x08 As per datasheet, this corresponds to
280ns in MTB units which is 0x08C0.
31,32 0xF0,0x05 0x60,0x04 As per datasheet, this corresponds to
140ns in MTB units which is 0x0460.
125 0xE1 0xE0 Fine offset for tckMin. tckMin is
calculated as (1/4267)*2 which comes
out to be 0.46871. Some datasheets
round this down to 0.468 and others
round it up to 0.469. JEDEC spec uses
0.468. As per that, this value comes
out to be 0xE0.
Part: MT53E1G64D4SQ-046 WT:A
Byte# Current New Explanation
5 0x21 0x29 As per datasheet, this part has 17row
address bits and 10column address
bits. This results in 0x29.
6 0xB9 0x94 Signal loading is not used by
MRC. Set bits 1:0 to 00. 2 channels,
2 dies. Hence, 0x94.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:147321551,b:155423877
Change-Id: I28b065a00380516d8686279a92ef68b9f17e2f65
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41616
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds mem_list_variant.txt that contains the list of
memory parts used by malefor and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: K4U6E3S4AA-MGCL
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Bits 1:0 set to 0.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:155239397,b:147321551
Change-Id: I8b8bdc55314f538aff4dd1944a0b745357744d8c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41615
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds mem_list_variant.txt that contains the list of
memory parts used by ripto and Makefile.inc generated by
gen_part_id.go using mem_list_variant.txt.
In the final change of the series, all volteer variants will be
switched from using the current SPDs to new auto-generated SPDs.
Differences in auto-generated SPD from current SPD are as follows:
Part: K4U6E3S4AA-MGCL
Byte# Current New Explanation
6 0x95 0x94 Signal loading is not used by
MRC. Bits 1:0 set to 0.
16 0x48 0x00 Signal loading is not used by
MRC. Set to 0x00.
19 0x0F 0xFF As per JEDEC spec, tckMax should be
100ns. So, value should be 0xff as
per datasheet.
21,22 0x55,0x00 0x54,0x05 As per datasheet, part supports CAS
latencies 20,24,28,32,36. So value
should be 0x54, 0x05.
24 0x8C 0x87 taa is .468ns * CAS-36 which results
in byte 24 being 0x87 as per datasheet.
123 0x00 0xE5 Fine offset for taa. Expected value
is 0xE5 as per datasheet.
124 0x7F 0x00 Fine offset for tckMax. Expected
value is 0x00 as per datasheet.
125 0xE1 0xE0 Fine offset for tckMin. As per
datasheet tckMin is 0.468ns. So, this
comes out to be 0xE0.
BUG=b:155239397,b:147321551
Change-Id: Ibb06443a5c7fd80915f66b806cdd7c3ae1275b05
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41614
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change uses gen_spd.go and global_lp4x_mem_parts.json.txt to
generate SPD files for currently known LP4x memory parts that
can be used with JSL-based mainboards.
Following files are added:
1. spd-*.hex: SPD files auto-generated by gen_spd.go
2. spd_manifest.generated.txt: Manifest file auto-generated by
gen_spd.go
Mainboards can use the SPD files from SoC directly when creating
SPD binary to add to CBFS.
Change-Id: Ic52506b809c66b9f7cf25a100a959d85c67addf2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41876
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change uses gen_spd.go and global_lp4x_mem_parts.json.txt to
generate SPD files for currently known LP4x memory parts that can be
used with TGL-based mainboards.
Following files are added:
1. spd-*.hex: SPD files auto-generated by gen_spd.go
2. spd_manifest.generated.txt: Manifest file auto-generated by
gen_spd.go
Mainboards can use the SPD files from SoC directly when creating SPD
binary to add to CBFS.
BUG=b:147321551,b:155239397
Change-Id: Ic3935e4f6d106cbdf496fdfa28a0991e2d238fd9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41875
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change adds a JSON file (`global_lp4x_mem_parts.json.txt`)
containing global list of LP4x memory parts to live along with the spd
tools since the part information is not really any SoC or mainboard
dependent and comes directly from the part datasheet. It can be shared
by mainboards based on different platforms supported by the tools.
BUG=b:155239397,b:147321551
Change-Id: I9e2f98fc9c1c8a7f73c9a1bfab22c996de222a32
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41874
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Serial Presence Detect (SPD) data for memory modules is used by Memory
Reference Code (MRC) for training the memory. This SPD data is
typically obtained from part vendors but has to be massaged to format
it correctly as per JEDEC and MRC expectations. There have been
numerous times in the past where the SPD data used is not always
correct.
In order to reduce the manual effort of creating SPDs and generating
DRAM IDs, this change adds tools for generating SPD files for LPDDR4x
memory used in memory down configurations on Intel Tiger Lake (TGL)
and Jasper Lake (JSL) based platforms. These tools generate SPDs
following JESD209-4C specification and Intel recommendations (doc
Two tools are provided:
* gen_spd.go: Generates de-duplicated SPD files using a global memory
part list provided by the mainboard in JSON format. Additionally,
generates a SPD manifest file (in CSV format) with information about
what memory part from the global list uses which of the generated
SPD files.
* gen_part_id.go: Allocates DRAM strap IDs for different LPDDR4x
memory parts used by the board. Takes as input list of memory parts
used by the board (with one memory part on each line) and the SPD
manifest file generated by gen_spd.go. Generates Makefile.inc for
integrating the generated SPD files in the coreboot build.
BUG=b:155239397,b:147321551
Change-Id: Ia9b64d1d48371ccea1c01630a33a245d90f45214
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41612
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This fixes a logic bug in how timeouts are reported back. In the
timeout case, the original code would return -1 instead of 0. All call
sites expect a return value of 0 as the timeout indicator.
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Change-Id: I81a888aa0a1544e55e6a680be8f3b7f6e0d87812
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Advertising SMI triggers in FADT is only valid if we exit with
SMI installed. There has been some experiments to delay SMM
installation to OS, yet there are new platforms that allow some
configuration access only to be done inside SMM.
Splitting static HAVE_SMI_HANDLER variable helps to manage cases
where SMM might be both installed and cleared prior to entering
payload.
Change-Id: Iad92c4a180524e15199633693446a087787ad3a2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
If running on older (like before 2.4.0) version of QEMU there is
no SMI support, so never advertise SMI in FADT for the emulation.
Behaviour if ACPI daemon tries to raise SMI under these conditions
is unknown.
Change-Id: I170058793798648c6713de1530d89ec2ac53e39a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41907
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 adds a hook so that a payload can optionally perform USB service
functions in conjunction with regular USB port status polling. In
particular, this allows depthcharge to control the state of an
external USB mux. Some SoCs like Tiger Lake have a USB mux for Type-C
ports that must be kept in sync with the state of the port as reported
by the TCPC. This can be achieved by hooking into the poll routine to
refresh the state of the USB mux.
BUG=b:149883933
TEST=booted into recovery from Type-C flash drive on volteer
Change-Id: Ic6c23756f64b891b3c5683cd650c605b8630b0fb
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We decided to store the FSG on eMMC instead of SPI flash, so we don't
need this region anymore. Getting rid of it allows us to put more space
into CBFS (to store hi-res bitmaps). Also grow VPD by some remaining
amount to keep the FMAP alignment reasonable.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If73450b65718affae71b6ada70ded5c5f45cfb4c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41980
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philip Chen <philipchen@google.com>
This change adds a helper function set_mmio_dev_ops() in chip.c which
is used for setting the dev->ops for MMIO devices based on the
comparison of MMIO address in device tree to the pre-defined base
addresses in iomap.h.
Call to i2c_acpi_name() is replaced with set_mmio_dev_ops and scope of
i2c_acpi_name is restricted to i2c.c since it is not required to be
exposed out of that file.
Change-Id: I31f96cfe8267b0df37012baeb7cfcaec9c2280f6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
There have been changes to the way device properties are supported
in Linux[1] and Windows[2] which add flexibilty:
- non-standard UUIDs can be used instead of only ACPI_DP_UUID
- support for multiple different packages within the _DSD that
associate different properties with unique UUIDs.
To handle this I extracted the part that does the write of UUID and
properties to a separate function and defined a new PACKAGE type
which has the custom UUID as a name and can be used the same way that
child properties are today.
For example a PCIe root port for a USB4 port has a standard property
indicating the USB4 reference, and then two custom properties which
are defined for different attributes.
Example code:
/* Create property table */
acpi_dp *dsd = acpi_dp_new_table("_DSD");
acpi_dp_add_reference(dsd, "usb4-port", usb4_path);
/* Add package for hotplug */
acpi_dp *pkg = acpi_dp_new_table("6211e2c0-58a3-4af3-90e1-927a4e0c55a4");
acpi_dp_add_integer(pkg, "HotPlugSupportInD3", 1);
acpi_dp_add_package(dsd, pkg);
/* Add package for external port info */
pkg = acpi_dp_new_table("efcc06cc-73ac-4bc3-bff0-76143807c389");
acpi_dp_add_integer(pkg, "ExternalFacingPort", 1);
acpi_dp_add_package(dsd, pkg);
/* Write all properties */
acpi_dp_write(dsd);
Resulting ACPI:
Scope (\_SB.PCI0.TRP0)
{
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
Package ()
{
Package () { "usb4-port", \_SB.PCI0.TDM0.RHUB.PRTA }
},
ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"),
Package ()
{
Package () { "HotPlugSupportInD3", One }
},
ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
Package ()
{
Package () { "ExternalFacingPort", One },
}
})
}
[1] https://patchwork.kernel.org/patch/10599675/
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports
Change-Id: I75f47825bf4ffc5e9e92af2c45790d1b5945576e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add PCIe enumeration and resource assignment/allocation.
Xeon-SP processor family has split IIO design, where PCIe domain 0 is
split into multiple stacks. Each stack has its own resource ranges (eg.
IO resource, mem32 resource, mem64 resource). The stack itself is not
PCIe device, it does not have config space to be probed/programmed.
The stack is programmed by FSP. coreboot needs to take into account of
stack when doing PCIe enumeration and resource allocation.
Current coreboot PCIe resource allocator does not support the concept of
split IIO stack, thus entire support is done locally in this patch.
In near future, improvements will be done, first generalize for xeon-sp,
then generalize for coreboot PCIe device code.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Reddy Chagam <anjaneya.chagam@intel.com>
Change-Id: If461b1dc1f313d98b676dc9e91d08a1dbb9cb388
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40110
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
offsets for ACPI_PM are incorrectly configured for picasso SoC.
Especially incorrect ACPI_PM_TMR_BLK makes kernel to spend 10 sec for
trying to testing it on wrong address.
Fix them to correct offset with hack for GPE0_BLK.
BUG=b:147044624
TEST=build and boot on trembyle; PM Timer error is gone
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: I6adf71479c30f5b6751a21edc4bfa311ddbef5ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
If the device is missing the HID, the code would previously leave an
open scope and device on the stack.
BUG=b:154756391
TEST=Verify stack ACPI stack does not exceed limit on Trembyle.
Fixes: a1c82c5ebe ("drivers/generic/max98357a: Allow custom _HID from config")
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I798ed08ef0a0575def12937a66a7ce99f743e60d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Lower 20bits of TOLUD and TOLM registers include 19 reserved bits and
1 lock bit. If lock bit is set, then systemagent.asl would end up
reporting the base address of low MMIO incorrectly i.e. off by 1.
This change masks the lower 20 bits of TOLUD and TOM registers when
exposing it in the ACPI tables to ensure that the base address of low
MMIO region is reported correctly.
Change-Id: Ib0ffd9a332fa9590de63f8828d30daa710fe50db
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41979
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This change updates hostbridge.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for google/link.
Change-Id: I5345ee22df7da92ee48c718f5bd748d7ea6155f2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41978
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Lower 20bits of TOLUD and TOLM registers include 19 reserved bits and
1 lock bit. If lock bit is set, then systemagent.asl would end up
reporting the base address of low MMIO incorrectly i.e. off by 1.
This change masks the lower 20 bits of TOLUD and TOM registers when
exposing it in the ACPI tables to ensure that the base address of low
MMIO region is reported correctly.
Change-Id: I1fb52a42e84130d973e0970024e263f443aa0b89
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This change updates hostbridge.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for
google/beltino.
Change-Id: I0ba2da441c7b398cc7f84a7ef7a5d233b0365cbe
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41976
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Modify the FCH ACPI devices to query the PCI IRQ mapping registers for
their current IRQ numbers.
BUG=b:139429446, b:154756391
TEST=Boot trembyle and see that I2C and UART devices are finally
functional.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8f2035f74240ead4089ff4d503dfbeb447cf8de4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch modified the puff fmd files to support CSE Lite SKU.
* Reduce the SI_ALL size to 3MiB since ME binary size is less
than 2.5MiB.
* Increase the FW_MAIN_A/B size to accommodate the ME_RW update
binary with CSE Lite SKU.
BUG=b:154561163
TEST=Build and boot puff with CSE Lite SKU.
Cq-Depend: chrome-internal:3046770
Change-Id: I4d39a1bdeabf48fc740da67539f48a9ff72c442c
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41198
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These build on existing functions but use different object types
in order to provide functions for upcoming changes:
acpigen_write_return_op(): Return an operator.
acpigen_write_if_lequal_op_op(): Check if 2 operands are equal.
acpigen_get_package_op_element(): Read an element from a package
into an operator.
This one just provides the missing helper, the other 3 already exist:
acpigen_get_tx_gpio: Read TX gpio state.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I1141fd132d6f09cf482f74e95308947cba2c5846
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41985
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on schematic and gpio table of halvor, generate gpio setting and
overridetree.cb for halvor.
BUG=b:153680359
TEST=FW_NAME=halvor emerge-volteer coreboot chromeos-bootimage
Verify that the image-halvor.bin is generated successfully.
Signed-off-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Change-Id: Ic6bd018551be58945742d1a6e7f7c5560f218e40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The config option APL_SKIP_SET_POWER_LIMITS was accidentally left out
during the set_power_limits refactor (SHA 2adb50d32e). This patch
reinstates the config option which will cause APL boards to not set any
power limits.
TEST=util/abuild/abuild -p none -t siemens/mc_apl1 -a
Change-Id: Iec9f9f340d50a1212b6ef20c2c0e1b66385ae1b2
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41786
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Right now all FSP2.0 based IA platform doesn't need this driver anymore
hence removing to avoid debug and maintenance effort.
TEST=Verified booting from SATA on SPT/CNP/ICP/TGP PCH platforms.
Change-Id: Ied3832b26ba1fdd4c30fafe8149689a01d302c3e
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41674
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For all of the audio devices in devicetree.cb add the probe matches
that will determine if the device should be enabled or not based on
the selected audio daughter board type.
AUDIO=MAX98357_ALC5682I_I2S: enable max98357 and alc5628, disable others
AUDIO=MAX98373_ALC5682I_I2S: enable max98373 and alc5682, disable others
AUDIO=MAX98373_ALC5682_SNDW: enable soundwire devices, disable others
BUG=b:147462631
TEST=test different device present in ACPI based on fw_config value:
> AUDIO=NONE
ectool cbi set 6 0x00000000 4 2
> AUDIO=MAX98357_ALC5682I_I2S
ectool cbi set 6 0x00000100 4 2
> AUDIO=MAX98373_ALC5682I_I2S
ectool cbi set 6 0x00000200 4 2
> AUDIO=MAX98373_ALC5682_SNDW
ectool cbi set 6 0x00000300 4 2
Change-Id: I5492e8cddcff3ba01023b0daef02be3508d347b0
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41216
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the current firmware configuration table for the volteer mainboard
and define some actions based on probe results for audio:
- When I2S options are selected disable the SoundWire GPIOs.
- When SoundWire is enabled disable the I2S GPIOs.
- When no audio is enabled disable all the GPIOs.
BUG=b:147462631
TEST=Test that GPIOs are configured as expected based on the current
value of the fw_config field in cbi.
Change-Id: I179f8b6436be83a2b37911777764bd26a0d404b7
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41215
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Move all audio devices from baseboard to the volteer variant.
- Add max98373 devices and enable the driver
- Disable everything in FSP and let coreboot configure GPIOs.
BUG=b:147462631
TEST=this change makes all audio devices show up in ACPI, so this
was tested by ensuring that all audio devices are present in ACPI.
Change-Id: Ic654ea52a549053622603aa8c81fb37577d4e011
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change adds support to sconfig for generating the firmware
configuration field and option definitions in devicetree.cb.
In addition these fields and options can be used to probe for a device
and have that device be disabled if it is not found at boot time.
New tokens:
fw_config: top level token, table can be defined before chips
field: define field in the mask with the start and end bits
option: define option in a field with the value of the field
probe: indicate that a device should probe by field and option
Example:
fw_config
field FEATURE 0 0
option DISABLE 0
option ENABLE 1
end
end
chip drivers/generic/feature
device generic 0 on
probe FEATURE ENABLE
end
end
Variants can add new fields and add new options to existing fields in
overridetree.cb but cannot redefine an existing option.
Devices can have multiple probe tokens, and the device will be considered
to be found if any of them return true.
The output from defining this field are:
1) the various fields and options will be added as macro constants to
static.h and can be used by fw_config for probing.
2) the probe entries will result in a list of fields/options to probe
that is added to the resulting struct device and handled by coreboot.
BUG=b:147462631
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I8aea63e577d933aea09e0d0b09470929cc96e0de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change introduces a new top-level interface for interacting with a
bitmask providing firmware configuration information.
This is motivated by Chromebook mainboards that need to support multiple
different configurations at runtime with the same BIOS. In these
devices the Embedded Controller provides a bitmask that can be broken
down into different fields and each field can then be broken down into
different options.
The firmware configuration value could also be stored in CBFS and this
interface will look in CBFS first to allow the Embedded Controller value
to be overridden.
The firmware configuration interface is intended to easily integrate
into devicetree.cb and lead to less code duplication for new mainboards
that make use of this feature.
BUG=b:147462631
TEST=this provides a new interface that is tested in subsequent commits
Change-Id: I1e889c235a81545e2ec0e3a34dfa750ac828a330
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There's not a function that is the equivalent to
x86_setup_mtrrs_with_detect() but not solving for above 4GiB.
Provide x86_setup_mtrrs_with_detect_no_above_4gb() which is the
equivalent to x86_setup_mtrrs_with_detect() but instructs the MTRR
solver to not take into account memory above 4GiB.
BUG=b:155426691
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia1b5d67d6f139aaa929e03ddbc394d57dfb949e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41897
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce concept of var_mtrr_context object for tracking and
assigning MTRR values. The algorithm is lifted from postcar_loader
code, but it's generalized for different type of users: setting
MSRs explicitly or deferring to a particular caller's desired
actions.
BUG=b:155426691,b:155322763
Change-Id: Ic03b4b617196f04071093bbba4cf28d23fa482d8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The porting of Asus P8Z77-M mainboard required changing certain Super
I/O configuration registers that were ignored in devicetree.cb because
they aren't listed as resources. Add the declaration so they can be
changed.
This change is nowhere near enough as the current structure is
insufficient to allow changing configuration registers in the 0xE?
range, which this board also needs.
TEST=Changes to config regs 0xf4, 0xf5 in LDN 9 are reflected when
inspected using superiotool -d.
Change-Id: Ia31aafda3fa9423d516b5d839ef5265e8e8ccdd2
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change updates camera_clock_ctl.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for wdoo.
Change-Id: I76ec29210ecdde728ce55531d2b6657be87ce9da
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
This change updates gpio_op.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for wdoo.
Change-Id: I3ec442ad85f408135642a112873231ce7d39524e
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
This change updates pch_hda.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for wdoo.
Change-Id: I8e965560518decbfafabe9ac06066d28d59240d0
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
This change updates scs.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for wdoo.
Change-Id: Ic1b5f3395a1ea8a3dd2ac6b109f9a5abe65d137f
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
This change updates platform.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for wdoo.
Change-Id: Ie55bcd9ac2ca746c046ebe05140b2ac291fb0459
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Update Cooperlake-SP (CPX-SP) FSP header files to WW20 release.
As CPX-SP FSP engineering is on-going (the processor Mass Production
is some time in this year). These header files will be adjusted when
changes are necessary with newer FSP release. This commit corresponds
to FSP release WW20 (tag WHITLEY.0.PRB.0016.D.65).
Also update soc/xeon_sp code file and Skylake-SP header file accordingly
to use FsptPort80RouteDisable instead of PcdPort80RouteDisable.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Signed-off-by: Reddy Chagam <anjaneya.chagam@intel.com>
Change-Id: I8bc6882e47de23d83ba0f521bb12a10dace523ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
CB:35086 exposed that the devicetree listed an EC chip for which there
is no actual driver; the EC is entirely ACPI code (.asl) included by
the board's ec.asl. Remove the unnecessary EC chip driver from both
boards, as well as the unnecessary Kconfig selection for librem_bdw.
Test: build/boot Librem 13v1, 13v4, verify battery info etc still correct.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I5cb0b51881ab8f14e9ec693485f673f4284b5f14
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
These changes are in accordance with the documentation:
[*] page 208-209
Intel(R) 64 and IA-32 Architectures, Software Developer’s Manual,
Volume 4: Model-Specific Registers. May 2019.
Order Number: 335592-070US
Tested on OCP Tioga Pass.
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Change-Id: I5e1de8bcb651fb8ae8b106db1978235b0dd84c47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40523
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With this patch, the ThinkLight on the ThinkPad X230 can be controlled
through the OS. This was initially done for the X201 in f63fbdb6:
mb/lenovo/x201: Add support for ThinkLight.
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Change-Id: Idd93b26f52eccb8fc79888f1e45117f26d694291
Signed-off-by: Stefan Ott <stefan@ott.net>
Tested-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40669
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ACPI bar was not programmed previously for which is needed to enable SMI's and
to check SMI status registers. The architecture of Lewisburg PCH is very
similar to SunrisePoint PCH thus we can use code from soc/intel/skylake.
TEST=build for Tiogapass and check ACPI base. Log message will now show
pmbase=501 (bit 0 is enable) instead of 0. Check by reading and writing
to io port 0x500.
Change-Id: If5a0c4daabf5c35dc2852434fe46712ac9b06379
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
add_register() contained a duplicate check but only compared the new
key to the first (smallest in order) list member. Fix that and factor
the list handling out so it can be used by other functions.
Change-Id: I5a8346f36fa024351e1282c9681868ecf451b283
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41743
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change is based on the concept that system user's (overwrite)
settings are held in VPD_RW region, while system owner's (default)
settings are held in VPD_RO region.
Add VPD_RW_THEN_RO region type, so that VPD_RW region is searched
first to get overwrite setting, otherwise VPD_RO region is searched
to get default setting.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Icd7cbd9c3fb2a6b02fc417ad45d7d22ca6795457
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41732
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
We want to use the CACHE_ROM_* macros in linker scripts. Avoid
`commonlib/helpers.h` as it contains an ALIGN() macro definition
that conflicts with the ALIGN keyword in linker scripts.
Change-Id: I3bf20733418ca4135f364a3f6489e74d45e4f466
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41785
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This explicitly enables TCSS DMA0 controller and disables
TBT PCIe2 and PCIE3 since they are unused on volteer.
BUG=🅱️146624360
TEST=Built and booted on Volteer.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I05cc9e3964d8037d433fca443be6e8d5b444bbce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41387
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Configure SD card GPIOs.
2. Set SD card power polarity and card detect configs.
SD card CMD. DATA and CLK GPIOs are set for native pad termination
as per recommendation in EDS vol1 section 10.4.10
BUG=b:150872580
TEST=Verify SD card enumeration and read/write transactions.
Change-Id: I90c8ceb85ada23718ff7b6fd7013317c818dd532
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Until now, the buildOpts.c files were primarily made out of copy-pasted
AGESA options, commented-out definitions and several useless comments;
that is, the materialization of technical debt in GCC-parsable form...
Until now.
It is assumed that the boards in the tree still boot. So, by comparing
their settings, we can extract saner defaults to place into AGESA. Many
of the settings were common across all boards of the same family, so we
promote those values to default settings. In some cases flipping a flag
was required, so the macros to alter that option had to be adapted as
well. Since those AGESA versions are expected to never receive updates,
it should not be a problem to change their files to suit our needs.
As a result, all but two buildOpts.c files now have less than 100 lines.
AGESA f14 boards need less than 50 lines, and f15tn/f16kb just require
about 60 or 70 lines in those files. Hopefully, this will make porting
more mainboards using AGESA f14/f15tn/f16kb a substantially easier task.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: Ife1ca5177d85441b9a7b24d64d7fcbabde6e0409
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Determine the TcssDma0 and TcssDma1 enabling based on TBT DMA
controllers setting.
BUG=🅱️146624360
TEST=Booted on Volteer and verified TcssDma0 and TcssDma1 enabling.
lspci shows TcssDma0(0d.2) and TcssDma1(0d.3).
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I61ac4131481374e9a2a34d1a30f822046c3897fb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41812
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable heci1 device from devicetree for PCI enumeration. This is
required for ME status dump using HFSTSx resgisters in PCI config
space. Heci1 device is later disabled through heci disable flow.
TEST=Build, boot waddledoo. ME status dump is seen in console logs.
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Change-Id: Icb77db3f0666c2d14ebef2c3214564346d1fd3c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Matching the same behavior change in depthcharge's FIT image code
(CL:2212466), this patch changes the order in which compat strings
involving revision and SKU numbers are matched when looking for a
compatible device tree. The most precise match (board-revX-skuY) is
still the highest priority, but after that we will now first check for
revision only (board-revX) and then for SKU only (board-skuY). The
reason for this is that SKU differentiation is often added later to a
project, so device trees for earlier revisions may not have SKU numbers
defined. So if we have a rev0 board (with sku0 as the "default SKU",
because the board only started having different SKUs with rev1) we want
it to match the board-rev0 device tree, not board-sku0 which was added
as an alias to board-rev1-sku0 to provide the best known default for
potential later revisions of that SKU.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia3cf7cbb165170e2ab0bba633fec01f9f509b874
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
On Picasso, DRAM is up by the time FSP-M runs. This change relocates
FSP-M binary to a specific address (0x90000000) in DRAM. Currently,
this address is randomly chosen to ensure it does not overlap any of
the other stages. Once we have a unified memory map set up for
Picasso, this address can be updated along with it.
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I1a49765f00de9f97fa3dbd5bc288a3ed0d7087f6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41828
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The first DRAM part supported by SPD_LPDDR4X_200b_4Gb_3733_DDP_1x16 is
NT6AP256T32AV-J2 so the SPD content is generally extracted from it's
SPD. On the other hand, SPD bytes 4 / 6 / 13 were amended to follow SoC's
requirement.
BUG=b:152277273
BRANCH=None
TEST=build the image successfully.
Change-Id: If6fb0855a961d1c68315a727466bf45569cf2597
Signed-off-by: Marco Chen <marcochen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41813
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch selects the fmd files based on config
BOARD_GOOGLE_BASEBOARD_HATCH and also renames them to
add the baseboard name and layout size tags.
BUG=b:154561163
TEST=Built hatch variants and verified that they select the
right fmd files.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I5d99ae28cc972ffa635adf100b756c36e168a8f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
All hatch and puff variants use 16MiB SPI flash except the legacy ones
which used 32MiB flash. Kconfig.name is updated to select
BOARD_ROMSIZE_KB_32768 only for the legacy variants and
BOARD_GOOGLE_HATCH_COMMON selects BOARD_ROMSIZE_KB_16384 by default if
BOARD_ROMSIZE_KB_32768 is not selected.
TEST=Verified using abuild --timeless that all hatch variants generate
the same coreboot.rom image with and without this change.
Change-Id: I708506182966936ea38562db8b0325470e34c908
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41662
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implementation of the ACPI objects for the Type-C Connector Class was
added in the previous patch. This patch removes the functionality from
the ChromeEC's SSDT generator, and uses acpigen_usb instead.
TEST=Verified contents of SSDT are the same.
Change-Id: Icdbcee1f989ee3146f7495e08fc13f9386791858
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The Linux ChromeOS EC driver now looks for 3 new properties under each
USBC.CONx device contained within the ChromeOS EC device. These
properties are just a reference to the device that controls the
switches for USB 2/3 muxing, SBU lines, and CC lines. It uses the new
function, soc_get_pmc_mux_device() to retrieve the device.
Change-Id: I03cd83f9b2901b5583053fac8ab6eab64717a07d
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40618
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ChromeOS EC is adding new entries to its USBC.CONx devices (see later
patch), and it needs to get access to the PMC.MUX device so that its
ACPI path can be retrieved. This provides a weak function to return NULL
for all Intel SoCs except for Tiger Lake, which locates the device if it
is found in the devicetree.
Change-Id: I3fe3ef25e9fac8748142f5b1bd870c9bc70b97ff
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40948
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow the ability for chipset or mainboard to choose to
compress FSP-M in cbfs using LZMA or LZ4 routines. However, only
non-XIP platforms will support FSP-M compression. Since the main
cbfs decompression paths are utilized add the appropriate checks
for including compression algorithms under the FSP-M compression
options.
On picasso FSP-M (debug builds) the following savings were measured:
no-compression:
fspm.bin 720896 none
FSP_COMPRESS_FSP_M_LZ4:
fspm.bin 138379 LZ4 (720896 decompressed) -80%
FSP_COMPRESS_FSP_M_LZMA:
fspm.bin 98921 LZMA (720896 decompressed) -86%
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I5c88510c134b56a36ff1cd97a64b51ab2fea0ab0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41450
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In an attempt to help reduce the amount of static ASL files that are
littered throughout the codebase, pmc.asl was converted to runtime SSDT
generation instead. If future SoCs reuse the same PMC, then this
function can be moved to soc/intel/common/block/pmc for example.
TEST=Verified the following was in the decompiled SSDT:
Scope (\_SB.PCI0)
{
Device (PMC)
{
Name (_HID, "INTC1026") // _HID: Hardware ID
Name (_DDN, "Intel(R) Tiger Lake IPC Controller")
Name (_CRS, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xFE000000, // Address Base
0x00010000, // Address Length
)
})
}
}
Also the following found in linux's /var/log/messages:
"acpi INTC1026:00: GPIO: looking up 0 in _CRS", indicating the PMC
ACPI device was found and its _CRS was locatable.
Change-Id: I665c873d8a80bd503acc4a9f0241c7a6ea425e16
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Allow the ability for chipset or mainboard to choose to
compress FSP-S in cbfs using LZMA or LZ4 routines. To accomplish
this fsp_load_component() is added as an assist for performing
the necessary logic and allow the caller to provide the destination
selection. Since the main cbfs decompression paths are utilized add
the appropriate checks for including compression algorithms under
the FSP-S compression options.
On picasso FSP-S (debug builds) the following savings were measured:
no-compression:
fsps.bin 327680 none
FSP_COMPRESS_FSP_S_LZ4:
fsps.bin 98339 LZ4 (327680 decompressed) -70%
FSP_COMPRESS_FSP_S_LZMA:
fsps.bin 71275 LZMA (327680 decompressed) -78%
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I8aa5d8c1cbaf4d08f38a918a9031a2570bc5247e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The LZ4 compressed stages assume in-place decompression. The constraints
are validated in cbfstool for _stages_ such that they can be decompressed
in place. However, that is only true for stages. As such, add a wrapper,
cbfs_stage_load_and_decompress(), that handles the LZ4 stage loading case.
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I9525a266250aa6c775283b598c09d4f40692db55
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41755
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Builds where RESET_X86_VECTOR is adjusted would create unintentionally
large bootblock files since id section can move far away from .reset
and .text. Some builds segfault or may try to create close to 4 GB
large intermediate build objects.
For cases where build is successful, id section would not reside within
REGION(program) or REGION(bootblock).
A proper fix to always place the ID data at the end of the coreboot.rom
file is left as follow-up work. For now, just place id section below
.reset.
Change-Id: Idf0e4defcde6d5e264d4752cc93f4ffb6749d287
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
CB:34634 expanded the VPD code to also be usable from romstage,
shuffling a few things around and adding some extra infrastructure in
the process. Unfortunately, the changes seem to have only been written
with x86 devices in mind and make coreboot always load the whole VPD
FMAP section (not just the used part) on devices where rdev_mmap() is
not a no-op.
This patch rewrites the VPD code to be based on region_device structures
that only represent the VPD area actually used (rather than the whole
FMAP section), and that only get mapped when accessed. (It would be even
better to pull this concept into the VPD decoder itself, but since that
is taken from third-party code and accesses in early stages aren't very
common, let's not go there for now.) It also moves the copying into
CBMEM to romstage so that late romstage accesses can already benefit
from it, and makes early decoding available in all stages because at
this point, why not.
Also fix a long-standing bug where the 'consumed' counter was not reset
between vpd_decode_string() calls to the RO and the RW VPD.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I55a103180b290c1563e35a25496188b6a82e49ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This change makes the following improvements to debug logging in
resource allocator:
1. Print depth is added to functions in pass 1 to better represent how
the resource requirements of child devices impact the resource windows
for parent bridge.
2. Device path is added to resource ranges to make it easier to
understand what device the resouce ranges are associated with.
3. Prints in pass 2 (update constraints, resource ranges, resource
assignment) are shifted left by 1 to make it easier to visualize
resource allocation for each bridge including domain.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3356a7278060e281d1a57d253537b097472827a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41478
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 1726fa1f0ce474cde32e8b32be34a212aff3ffba.
Reason for revert: Resource allocator is split into old(v3) and
new(v4). So, this change to enable hotplug resource allocator for
volteer can land back.
BUG=b:149186922
Change-Id: Ib6a4df610b045fbc885c70bff3698a032b79f770
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41468
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit e15f352039a371156ceef37f0434003228166e99.
Reason for revert: Resource allocator is split into old(v3) and
new(v4). So, this change to provide an option to allocate prefetch
memory above 4G boundary can be added back. Since the support for
allocating above 4G boundary is available only in resource allocator
v4, Kconfig option is accordingly updated to add depends on
RESOURCE_ALLOCATOR_V4.
Change-Id: I94e5866458c79c2719fd780f336fb5da71a7df66
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41467
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds back CB:39487 which was reverted as part of
CB:41412. Now that the resource allocator is split into old(v3) and
new(v4), this change adds support for allocating resources above 4G
boundary with the new allocator v4.
Original commit message:
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The templates for the zork reference boards are still being actively
worked on in the trembyle-bringup branch. Remove the zork template
from the main branch to avoid confusion when trembyle-bringup is
merged.
BUG=b:157099580
BRANCH=none
TEST=N/A
Signed-off-by: Paul Fagerburg <pfagerburg@chromium.org>
Change-Id: I0ff9de959c7b2646b90e68df05f0b2e9bdd60cf7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The majority of the codebase has been converted to use SPDX identifiers
now, so let's enforce those by default. The only exceptions are
src/include and src/lib, which are not being checked since many of the
files there do not have license headers at all. Files with custom
licenses that aren't covered by SPDX can be listed as exceptions at the
top of lint-000-license-headers.
Change-Id: Ie6642153793d5735c74c5950bc9e27ee7eecacbc
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41602
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
mb/google/hatch supports two different reference platforms - Hatch and
Puff. This change adds Kconfigs BOARD_GOOGLE_BASEBOARD_PUFF in
addition to BOARD_GOOGLE_BASEBOARD_HATCH to better organize the
Kconfig selections and reduce redundancy. In addition to this, a new
config BOARD_GOOGLE_HATCH_COMMON is added that selects all the common
configs for both baseboards.
TEST=Verified using abuild --timeless option that all hatch variants
generate the same coreboot.rom image with and without this change.
Change-Id: I46f8b2ed924c10228fa55e5168bf4fe6b41ec36c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41660
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use CAPID0_A to provide information closer to reality.
* Correctly advertise ECC support, max DIMM count and max capacity
* CAPID0_A hasn't changed since SNB, but most EDS mark the bits as
reserved even though they are still used by FSP.
* Assume the same bits for Tiger Lake as for Ice Lake
* Assume the same bits for Skylake as for Coffee Lake
* Add CAPID0_A to Icelake headers
The lastest complete documentation can be found in Document: 341078-002.
Change-Id: I0d8fbb512fccbd99a6cfdacadc496d8266ae4cc7
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Our jenkins instance is also used for flashrom, which can be built with
meson, a mode that we want to be able to test, so add that.
ninja can be used as a backend to both meson and cmake (which coreboot
will use to build cmocka for its unit tests) and may provide some
additional coverage. Plus it's tiny but fast.
Change-Id: If454164852303144eaa72c4071c03ee89e863318
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Enable Intel Speed Shift Technology (ISST) by default. Disable ISST in
waddledee and waddledoo variants on early phases.
BUG=b:151281860
TEST=Build and boot the mainboard. Ensure that cpufreq driver to
configure P-states is enabled in kernel on boards where board version is
provisioned.
Change-Id: Id65d7981501c2f282e564bfc140f8d499d5713e8
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
This is a copy of the mb/google/zork directory from the chromiumos
coreboot-zork branch. This was from commit 29308ac8606.
See https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/29308ac8606/src/mainboard/google/zork
Changes:
* Minor changes to make the board build.
* Add bootblock.c.
* Modify romstage.c
* Removed the FSP_X configs from zork/Kconfig since they should be
set in picasso/Kconfig. picasso/Kconfig doesn't currently define the
binaries since they haven't been published. To get a working build
a custom config that sets FSP_X_FILE is required.
BUG=b:157140753
TEST=Build trembyle and boot to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I3933fa54e3f603985a0818852a1c77d8e248484f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41581
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It never was in GNVS, it never belonged among the ACPI tables. Having
it in CBMEM, makes it easy to look the location up on resume, and saves
us additional boilerplate.
TEST=Booted Linux on Lenovo/X201s, confirmed ASLS is set and
intel_backlight + acpi_video synchronize, both before and
after suspend.
Change-Id: I5fdd6634e4a671a85b1df8bc9815296ff42edf29
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40724
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Addressing comment from CB:41443 that was received after the change
landed. memranges_create_hole() takes size as the last parameter. So,
the I/O hole created at 0x3b0 needs to set size as 0x3df - 0x3b0 + 1
as 0x3df is the upper limit of that hole.
Change-Id: I08fca283436924427e12c6c69edced7e51db42a9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds proper RV2 silicon and Dali SKU detection using both CPUID
information and some bits from silicon_id in the Picasso misc data HOB
that FSP-M stores in memory.
BUG=b:153779573
Change-Id: I589be3bdac4b94785e6ecacf55235be4ad5673d9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The Tiger Lake PMC device has a MUX device which is expected to be
exposed in ACPI tables. The MUX device simply has a _HID and _DDN.
The CON devices link the USB-2 and USB-3 port numbers (from SoC
point of view) to the physical connector. They also have orientation
options for the sideband (SBU) and USB High Speed signals (HSL),
meaning that they can be fixed (i.e, another device besides the SoC
controls the orientation, and effectively the SoC is following only
CC1 or CC2 orientation), or they can follow the CC lines.
BUG=b:151646486
TEST=Tested with next patch in series (see TEST line there)
Change-Id: I8b5f275907601960410459aa669e257b80ff3dc2
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Relying on Cmocka packages, which are provided with different OS
distributions, may introduce some problems with setup environments
across developers (e.g. library version mismatch). Instead, let's build
Cmocka from source code, which is now added to git submodules as
3rdparty/cmocka.
Please note, that cmake tool is required for building Cmocka (thus also
coreboot unit tests).
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: Ia947c5c60d5c58b76acebe4b614dd427ef995950
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Convert spaces to tabs in volteer variant makefiles, and remove empty
comment lines from file headers.
BUG=none
TEST="emerge-volteer coreboot chromeos-bootimage", flash and verify
volteer boots to kernel.
Change-Id: I6c818c3adcc55ce89707efff6dd9a6bce512daa5
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41587
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change disables the old resource allocator by default and instead
uses the new v4 resource allocator. Only the chipsets that explicitly
select RESOURCE_ALLOCATOR_V3 will continue to use the old v3 resource
allocator.
Change-Id: I2ab9f1d612b5f193f058011a18b1d6373e09f788
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
This change adds legacy VGA memory (0xa0000 - 0xbffff) as
mmio_resource in northbridge.c read_resources() to match what is
exposed to the OS in hostbridge.asl. It ensures that the resource
allocator does not use this range for dynamic resource allocation.
Change-Id: I24e3aaf97202575fa9df8408366c8db5bea07145
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This change adds back support for the resource allocator using
multiple ranges as originally landed in CB:39486(commit hash 3b02006)
and reverted in CB:41413(commit hash 6186cbc). The new resource
allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It
was identified that there are some AMD chipsets in the tree that do
not really work well with the dynamic resource allocation. Until these
chipsets are fixed, old (v3) and new (v4) of the resource allocator
need to live side-by-side in the tree. There were some other chipsets
in the tree which originally demonstrated problems with the new
resource allocator, but have been since fixed in the tree.
This change picks up the same additions as performed in CB:39486 along
with the following changes:
1. Changes to avoid fixed resources in the entire tree. Use of
search_bus_resources() is replaced with a walk of the entire tree
in avoid_fixed_resources(). This is required to ensure that all fixed
resources added to any device (including domain) are taken into
consideration to avoid overlap during dynamic resource allocation.
2. Changes to set up alignment for memranges when initializing
them. This is done to ensure that the right granularity is used for
IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource
requests.
3. mark_resource_invalid() is dropped as the resource no longer needs
to be marked in any special way if allocation is not being
done. Instead setting of IORESOURCE_ASSIGNED flag is skipped in this
case.
4. initialize_memranges() is updated to check IORESOURCE_ASSIGNED
instead of base == limit.
Original commit message:
This change updates the resource allocator in coreboot to allow using
multiple ranges for resource allocation rather than restricting
available window to a single base/limit pair. This is done in
preparation to allow 64-bit resource allocation.
Following changes are made as part of this:
a) Resource allocator still makes 2 passes at the entire tree. The
first pass is to gather the resource requirements of each device
under each domain. It walks recursively in DFS fashion to gather the
requirements of the leaf devices and propagates this back up to the
downstream bridges of the domain. Domain is special in the sense that
it has fixed resource ranges. Hence, the resource requirements from
the downstream devices have no effect on the domain resource
windows. This results in domain resource limits being unmodified after
the first pass.
b) Once the requirements for all the devices under the domain are
gathered, resource allocator walks a second time to allocate resources
to downstream devices as per the requirements. Here, instead of
maintaining a single window for allocating resources, it creates a
list of memranges starting with the resource window at domain and then
applying constraints to create holes for any fixed resources. This
ensures that there is no overlap with fixed resources under the
domain.
c) Domain does not differentiate between mem and prefmem. Since they
are allocated space from the same resource window at the domain level,
it considers all resource requests from downstream devices of the
domain independent of the prefetch type.
d) Once resource allocation is done at the domain level, resource
allocator walks down the downstream bridges and continues the same
process until it reaches the leaves. Bridges have separate windows for
mem and prefmem. Hence, unlike domain, the resource allocator at
bridge level ensures that downstream requirements are satisfied by
taking prefetch type into consideration.
e) This whole 2-pass process is performed for every domain in the
system under the assumption that domains do not have overlapping
address spaces.
Noticeable differences from previous resource allocator:
a) Changes in print logs observed due to flows being slightly
different.
b) Base, limit and size of domain resources are no longer updated
based on downstream requirements.
c) Memranges are used instead of a single base/limit pair for
determining resource allocation.
d) Previously, if a resource request did not fit in the available
base/limit window, then the resource would be allocated over DRAM or
any other address space defeating the principle of "no overlap". With
this change, any time a resource cannot fit in the available ranges,
it complains and ensures that the resource is effectively disabled by
setting base same as the limit.
e) Resource allocator no longer looks at multiple links to determine
the right bus for a resource. None of the current boards have multiple
buses under any downstream device of the domain. The only device with
multiple links seems to be the cpu cluster device for some AMD
platforms.
Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41443
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
find_pci_tolm() is updated to ensure that it ignores resources that
have a zero size. This change removes the setting of resource flags to
IORESOURCE_ASSIGNED when the resource is not really allocated any
space by the allocator. It also drops the setting of base to limit
since that is not required anymore.
Change-Id: If8c0d4bf1aa9cd6a5bdf056140f65cf2d70ed216
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41566
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the resource allocator functions out of device.c
and into two separate files:
1. resource_allocator_v3.c: This is the old implementation of
resource allocator that uses a single window for resource
allocation. It is required to support some AMD chipsets that do not
provide an accurate map of allocated resources by the time the
allocator runs. They work fine with the old allocator since it
restricts itself to allocations in a single window at the top of the
4G space.
2. resource_allocator_common.c: This file contains the functions that can
be shared by the old and new resource allocator.
Entry point into the resource allocation is allocate_resources() which
can be implemented by both old and new allocators. This change also
adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old
resource allocator. This config option is enabled by default
currently, but in the following CLs this will be enabled only for the
broken boards.
Reason for this split: Both the old and new resource allocators need
to be retained in the tree until the broken chipsets are fixed.
Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates find_pci_tolm() to not consider any unassigned
resources. This is achieved by adding the following checks:
1. Call search_bus_resources() with mask set to IORESOURCE_MEM |
IORESOURCE_ASSIGNED.
2. In the callback tolm_test, check that the new resource selected has
a non-zero size.
This change is being made so that the resource allocator does not have
to set the IORESOURCE_ASSIGNED flag for marking a resource as
invalid.
Change-Id: I796784dd93aa165e20a672c985b4875991901c87
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Select UDK_2017_BINDING instead of UDK_2015_BIDING. Otherwise
there is build error when turning on FSP debugging.
Remove duplicate configs from SKX-SP and CPX-SP directories, to
keep the configs at SoC family level.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I6b25bf25dcb57937e2d9fec54eeb7951b0ee4b2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
In Tiger Lake we have support for enabling MIPI clocks at runtime in
ACPI. Hence remove setting pch_islclk from devcietree and chip.h.
Also update functions which reference pch_isclk.
BUG=b:148884060
Branch=None
Test=build and boot volteer and verify camera functionality
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I6b3399172c43b4afa4267873ddd8ccf8d417ca16
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41570
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's already disabled by FSP default but disable VMD by devicetree
to remove dependency with FSP default setting.
BUG=None
Branch=None
Test=Build TGLRVP and boot up and check FSP log for checking VMD is
disabled.
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: Ief81fe481b94abed9754881cf1f454999fafa52e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41061
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update processor power limit configuration parameters based on
common code base support for Intel Apollo Lake SoC based platforms.
BRANCH=None
BUG=None
TEST=Built and tested on octopus system
Change-Id: I609744d165a53c8f91e42a67da1b972de00076a5
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41233
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds FSP UPD D3HotEnable and D3ColdEnable for configuration.
D3Hot low power mode support is for TCSS xhci, xdci, TBT PCIe root
ports and DMA controllers. D3Cold is lower mode for TBT PCIe root
ports and DMA controllers with D3Hot->D3Cold transition.
BUG=🅱️146624360
TEST=Built and booted on Volteer.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I6782cde6a1bfe13f46e75db8c85537c6d62f5d41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
When drawing two adjacent boxes with draw_box(), there will be a gap
between them. This is due to the truncation in integer division when
calculating the bottom right coordinate of the box.
In this patch, the relative bottom right coordinate is calculated before
transforming to an absolute one. The same issue is also fixed for
draw_rounded_box().
Also check validity of 'pos_rel' and 'dim_rel' arguments for
draw_rounded_box().
BRANCH=none
BUG=chromium:1082593
TEST=emerge-nami libpayload
Change-Id: I073cf8ec6eb3952a0dcb417b4c3c3c7047567837
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Update processor power limit configuration parameters based on
common code base support for Intel Cannonlake SoC based platforms.
BRANCH=None
BUG=None
TEST=Built and tested on drallion system
Change-Id: Iac6e6f81343fcd769619e9d7ac339430966834f6
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
CPU to PCH method refers to PCH ACPI operation region which was wrongly
defined as SystemMemory and PCH_PWRM_BASE_ADDRESS. Change the operation
region to be SystemIO and ACPI_BASE_ADDRESS.
BUG=b:156530805
TEST=Built and booted to kernel.
Signed-off-by: John zhao <john.zhao@intel.com>
Change-Id: Ifa291a993ec23e1e4dfad8f6cdfabc80b824d20c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Intel introduced the UPD VrPowerDeliveryDesign with Cannon Lake. The
BIOS needs to program VrPowerDeliverDesign configuration per platform
according to the platform capabilities to avoid incorrect
electrial/power parameters. This is only added for Cannon Lake.
Refer to document 599797 for more details.
Change-Id: I89b8dceb40fa6a9dc67b218e91bf728ff928b5a0
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41081
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On AGESA f14/f15tn, various RAM-related options were defined in an enum.
However, the preprocessor mess can't compare enum values. To make AGESA
build, each board redefined them as macros, shadowing the enum elements.
Clean this up by replacing the enums with macros in AGESA headers, and
delete the now-redundant redefinitions from all the mainboards.
Note that AGESA f16kb already uses macros, but each mainboard still had
commented-out definitions. Remove them as well, as they are unnecessary.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: Ie1085539013d3ae0363b1596fa48555300e45172
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41666
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All AGESA f16kb boards use the same MTRR values. Factor them out,
while still allowing a board to override them via BLDCFG.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: I236e9d45505e92027acc3ba5ff496f5e2f09b9f3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
All AGESA f15tn boards use the same MTRR values. Factor them out,
while still allowing a board to override them via BLDCFG.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: I90c95493de1bb5b8f32c06b9575fef3aa7aca031
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
We set BLDCFG_PCI_MMIO_BASE and BLDCFG_PCI_MMIO_SIZE to the same values
everywhere, so we might as well factor them out. As we have equivalent
Kconfig options in coreboot, also deprecate overriding them via BLDCFG.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: I7244c39d2c2aa02a3a9092ddae98e4ac9da89107
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
All AGESA f14 boards use the same MTRR values. Factor them out, while
still allowing a board to override them via BLDCFG.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: Id980e4671e51fe800188f0a84768a307c8965886
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
We use the same AGESA version numbers on all but one mainboard, so we
might as well factor them out. The only exception is asrock/e350m1,
which has the f15tn/f16kb version number even though it actually uses
AGESA f14. To preserve reproducibility, do not change it in this commit.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: I0dad2352ccda454d5545f17228d52e4ff4f23f20
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41591
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We use the same value everywhere, so factor it out. Note that the field
where this value ends up in was doubled in size for AGESA fam16kb, but
we did not update the definition to fill in the additional space. We are
not changing it in this commit so as to preserve binary reproducibility.
In any case, add a FIXME explaining why this value may not be correct.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: Ied118d534ee1e9728db843944d1e042760b4f32c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Current Interrupt setting use 2nd parameters as device function number.
Correct as interrupt pin number according to _PRT package format.
{Address, pin, Source, Source index}
Reference:
- ACPI spec 6.2.13 _PRT
BUG=None
BRANCH=None
TEST=Build and boot JSLRVP Verify Interrupt mappings are same as PCI
INTR(0x3C) register and no interrupt storm is seen
Change-Id: I21462c6befea310a49eecf9ad1b5c8770eccd5bd
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41404
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Convert the remaining files in src/drivers to use SPDX identifiers.
int15.h and default_brightness_levels.asl did not have license headers,
but they were both copied from other GPL2 files, so they should be under
the GPL2 as well.
ne2k.c and drm_dp_helper.h are licensed under custom BSD-like licenses
that do not have an SPDX equivalent, so they are added as exceptions
to the license header lint.
Change-Id: I87fb1c637b8d11b0463f7c19f70b847413e14aed
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41601
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
With this patch, the ThinkLight on the ThinkPad T400 can be controlled
through the OS. The same change was done for the ThinkPad X200 in
b45912f4: mb/lenovo/x200: Add support for ThinkLight
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own a T400 to test this.
Change-Id: I377854d6f54c5459e44626a7d7b61c513268183e
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
With this patch, the ThinkLight on the ThinkPad T430S can be controlled
through the OS. The same change was done for the ThinkPad X200 in
b45912f4: mb/lenovo/x200: Add support for ThinkLight
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own a T430S to test this.
Change-Id: Ifa74f5373a6305d1237e7de6da35028e68f1e99c
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
With this patch, the ThinkLight on the ThinkPad T420S can be controlled
through the OS. The same change was done for the ThinkPad X200 in
b45912f4: mb/lenovo/x200: Add support for ThinkLight
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own a T420S to test this.
Change-Id: I245acf81b34abccf7bcb04126275ab8b154135d5
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
With this patch, the ThinkLight on the ThinkPad T520 can be controlled
through the OS. The same change was done for the ThinkPad X200 in
b45912f4: mb/lenovo/x200: Add support for ThinkLight
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own a T520 to test this.
Change-Id: Iffc5dd2f23ee4896da633c18cbbf22c9e448edf1
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40718
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
With this patch, the ThinkLight on the ThinkPad T530 can be controlled
through the OS. The same change was done for the ThinkPad X200 in
b45912f4: mb/lenovo/x200: Add support for ThinkLight
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own a T530 to test this.
Change-Id: I94d239b65e6e8546a27f751d569681a4e68a4109
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
With this patch, the ThinkLight on the ThinkPad T430 can be controlled
through the OS. The same change was done for the ThinkPad X200 in
b45912f4: mb/lenovo/x200: Add support for ThinkLight
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own a T430 to test this.
Change-Id: I1fb1a9d3a84ce12ab9e3f22a699afbfd7cd1688f
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40716
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
On PC Engines apu1 there were issues with cold reset. Platform hangs
in boot path after performing reset using CF9h.
CB:10549 (amd/sb800: Make UsbRxMode per-board customizable)
mentions a similar issue, and added a configuration macro for it.
That error is also described in AMD SB800 Family Product Errata,
section 15 USB Resets Asynchronously With Port CF9h Hard Reset.
This workaround simply non-execute USB configuration during boot
and hence no reset via CF9h is done.
TEST=perform multiple cold resets and see if platform boots
Signed-off-by: Piotr Kleinschmidt <piotr.kleinschmidt@3mdeb.com>
Change-Id: Ie6cebcfc4b77e121ef44a25fa81377eb5e1f0644
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41627
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With this patch, the ThinkLight on the ThinkPad X220 can be controlled
through the OS. This was initially done for the X201 in f63fbdb6:
mb/lenovo/x201: Add support for ThinkLight.
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own an X220 to test this.
Change-Id: Icead793694475e2f63353690203790ab7ce7c597
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40668
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With this patch, the ThinkLight on the ThinkPad T420 can be controlled
through the OS. The same change was done for the ThinkPad X200 in
b45912f4: mb/lenovo/x200: Add support for ThinkLight
After applying this patch, the light can be controlled like this:
echo on >/proc/acpi/ibm/light
echo off >/proc/acpi/ibm/light
Or through sysfs at /sys/class/leds/tpacpi::thinklight
Unfortunately I do not own a T420 to test this.
Change-Id: I4f9a9937a45995b72a9712919316e95bb8f82f45
Signed-off-by: Stefan Ott <stefan@ott.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change adds a target to the top level Makefile that allows
building sconfig and generating static.c/static.h without building
the rest of coreboot.
It also adds $(DEVICETREE_STATIC_C) to the c-deps for each stage so
the files are generated before the build runs.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I4320288422230d8913dfa7cc7b7512775a1a797b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41439
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable drivers for SoundWire codecs and define the topology in
the devicetree for the volteer variant with the SoundWire daughter
board connected.
+------------------+ +-------------------+
| | | Headphone Codec |
| Intel Tigerlake | +--->| Realtek ALC5682 |
| SoundWire | | | ID 1 |
| Controller | | +-------------------+
| | |
| Link 0 +----+ +-------------------+
| | | Left Speaker Amp |
| Link 1 +----+--->| Maxim MAX98373 |
| | | | ID 3 |
| Link 2 | | +-------------------+
| | |
| Link 3 | | +-------------------+
| | | | Right Speaker Amp |
+------------------+ +--->| Maxim MAX98373 |
| ID 7 |
+-------------------+
This was tested by booting the firmware and dumping the SSDT table
to ensure that all SoundWire ACPI devices are created as expected with
the properties that are defined in coreboot under \_SB.PCI0:
HDAS - Intel Tigerlake HDA PCI device
HDAS.SNDW - Intel Tigerlake SoundWire Controller
HDAS.SNDW.SW01 - Realtek ALC5682 - Headphone Codec
HDAS.SNDW.SW13 - Maxim MAX98373 - Left Speaker Amp
HDAS.SNDW.SW17 - Maxim MAX98373 - Right Speaker Amp
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I7782059807416369e0e1ba0d4d7c79dcab0fcbc5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40894
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of only using the baseboard devicetree add a placeholder
overridetree for volteer and refer to it in Kconfig.
This will allow us to add the volteer specific devices here instead
of at the baseboard level.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I7788a5473fc2275a9791fb27e0e4018a0efcd0f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40893
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ALC5682 headset codec can be connected over SoundWire and be
configured for mainboards to use:
- Data Port 0 and Bulk Register Access is supported
- Data Ports 1-4 are supported as both source and sink
The data port and audio mode properties are filled out as best as
possible with the datasheet as a reference.
The ACPI address for the codec is calculated with the information in
the codec driver combined with the devicetree.cb hierarchy where the
link and unique IDs are extracted from the device path.
For example this device is connected to master link ID 0 and has strap
settings configuring it for unique ID 1:
chip drivers/soundwire/alc5682
register "desc" = ""Headset Codec""
device generic 0.1 on end
end
This driver was tested with the volteer reference design by booting
and disassembling the runtime SSDT to ensure that the devices have the
expected address and properties.
Device (SW01)
{
Name (_ADR, 0x000021025D568200)
Name (_DDN, "Headset Codec")
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-sw-interface-revision", 0x00010000 },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-bra-mode-0", "BRA0" },
Package () { "mipi-sdw-dp-0-subproperties", "DP0" },
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" },
Package () { "mipi-sdw-dp-1-source-subproperties", "SRC1" },
Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" },
[...]
}
}
Name (BRA0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"mipi-sdw-bra-mode-bus-frequency-configs",
Package () { 0x000F4240, [...] }
},
[...]
}
}
Name (DP0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-bra-flow-controlled", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-bra-mode-0", "BRA0" }
}
}
Name (MOD0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"mipi-sdw-audio-mode-bus-frequency-configs",
Package () { 0x000F4240, [...] }
},
[...]
}
}
Name (SNK1, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
Name (SNK1, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
}
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I488dcd81d2e66a6f2c269ab7fa9f7ceaf2cbf003
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40891
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MAX98373 smart speaker amp can be connected over SoundWire and be
configured for mainboards to use:
- Data Port 0 and Bulk Register Access is not supported
- Data Port 1 is the 32bit data input for the speaker path
- Data Port 3 is the 16bit data output for I/V sense ADC path
The data port and audio mode properties are filled out as best as
possible with the datasheet as a reference.
The ACPI address for the codec is calculated with the information in
the codec driver combined with the devicetree.cb hierarchy where the
link and unique IDs are extracted from the device path.
For example this device is connected to master link ID 1 and has strap
settings configuring it for unique ID 3.
chip drivers/soundwire/max98373
register "desc" = ""Left Speaker Amp""
device generic 1.3 on end
end
This driver was tested with the volteer reference design by booting
and disassembling the runtime SSDT to ensure that the devices have the
expected address and properties.
Device (SW13)
{
Name (_ADR, 0x000123019F837300)
Name (_DDN, "Left Speaker Amp")
Method (_STA)
{
Return (0x0F)
}
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-sw-interface-revision", 0x00010000 },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" },
Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" },
Package () { "mipi-sdw-dp-3-source-subproperties", "SRC3" },
}
}
Name (MOD0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"mipi-sdw-audio-mode-bus-frequency-configs",
Package () { 0x00753000, [...] }
},
[...]
}
}
Name (SNK1, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
Name (SRC3, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
}
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I3f8cb2779ddde98c5df739bd8a1e83a12a305c00
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40890
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The Intel Tigerlake SoundWire controller has 4 master links which
are configured differently depending on the external crystal oscillator
which is connected to the PCH.
This function will read the PCH PMC EPOC register to determine the
frequency and then fill out the master link entries with the correct
table values.
The frequency is also provided directly in a custom "ip-clock" property
which will be added to the link descriptor and passed to the OS driver
so it can know the clock rate of the master.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I98b7df21210c29cd8defeff648f2c2207d629295
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40889
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This driver provides support for Intel SoundWire controllers. It is
intended to be used by multiple Intel SoCs and relies on retrieving
controller/master information from the SoC itself. As such it
provides a function that must be implemented by the SoC to fill out
this structure.
The Intel SoundWire driver in the Linux kernel expects firmware to
inform it which master links are unused by adding a custom property
to the link descriptor. This is done by looking for any children
attached to the device that use each link and disabling the ones
that are unused.
Mainboards will enable this driver and define the controller in
devicetree.cb in order provide the required ACPI tables, but the
mainboard should not need to provide any configuration itself as that
should all come from the SoC directly.
This was tested with the volteer board by adding this controller and a
codec to devicetree.cb and ensuring that the properties are all present,
including the custom properties for the device clock and quirk mask for
disabled links.
Device (SNDW)
{
Name (_ADR, 0x40000003)
Name (_CID, Package () { "PRP0001", "PNP0A05" })
Name (_DDN, "Intel SoundWire Controller")
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-sw-interface-revision", 0x00010000 },
Package () { "mipi-sdw-master-count", 0x04 }
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-link-0-subproperties", "LNK0" },
Package () { "mipi-sdw-link-1-subproperties", "LNK1" },
Package () { "mipi-sdw-link-2-subproperties", "LNK2" },
Package () { "mipi-sdw-link-3-subproperties", "LNK3" },
}
}
Name (LNK0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-clock-stop-mode0-supported", One },
[...]
Package () { "intel-sdw-ip-clock", 0x0249F000 },
Package () { "intel-quirk-mask", Zero },
}
}
[...]
}
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I4b4f843a7e5ea170b070a1697c8eedc7c103e127
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The PMC EPOC register indicates which external crystal oscillator is
connected to the PCH. This frequency is important for determining the
IP clock of internal PCH devices.
Add definitions that allow this register to be read and extract the
crystal frequency, and a helper function to extract and return this
as the defined enum.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I959fe507f3dbf93b6176b333a9e725ed09f56328
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40887
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The DRAM Max Cycle Time (tCKmax) for Samsung's K4UBE3D4AA-MGCL DRAM
part should be set to 0xF.
BUG=b:157178553, b:156555863
TEST="emerge-volteer coreboot chromeos-bootimage", flash and boot a
SKU4 volteer to the kernel and run "memtester 6G 100" and verify it
completes successfully without error and does not crash.
Change-Id: Id95b19fe261e3f57a52a43055acab99af66b14ab
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41634
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SPD_LPDDR4X_200b_8bank_1Rx16_16Gb_DDP_4267.spd.hex SPD
contained an incorrect SDRAM Max Cycle Time (0 instead of 0x0f).
After fixing that error, I noticed that two generic SPDs could
be collapsed into one, so I removed one of the duplicate generic
SPDs (SPD_LPDDR4X_200b_8bank_1Rx16_16Gb_16Row_DDP_4267.spd.hex),
and changed Makefile to collapse volteer's DRAM ID 2 into ID 0.
BUG=b:156126658, b:156058720
TEST=Flash and boot a ripto to kernel. Also verified that ripto
can boot successfully to the kernel at 4267 MT/sec with FSP built
in debug mode with RMT enabled.
Change-Id: Ib52bf674ebf91854d3d078015aa640aa7ee98a6f
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41345
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This node is required so we can add child ACPI nodes.
BUG=b:147042464
TEST=Boot trembyle and confirm Bus A has a firmware node
$ cat /sys/bus/pci/devices/0000\:00\:08.1/firmware_node/path
\_SB_.PCI0.PBRA
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I18144a69ed28a913bc9a2523d69edf84a1402e7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of directly writing values to the IOSAV registers, use a struct
and some helper functions to provide a cleaner interface for the IOSAV.
Having IOSAV_SUBSEQUENCE refer to a static function is weird, but we
will remove this macro in a follow-up that does not change the binary.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: I73f13c18a739c5586a7415966f9017c2335fdfd1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40980
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
We set bit 15 of IOSAV_n_SUBSEQ_CTRL three times, but it is reserved.
Since this bitfield is five bits wide, manually truncate the values so
that bit 15 does not get set.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: Ib61b026b016b0d22e164f8817158ec5093f6bb9e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40981
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Turn `iosav_run_queue` and `iosav_run_once` into functions. Inlining
them does not have any effect, as the resulting binary is identical.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: I7844814eeedad9b1d24f833a77c90902fa926bfe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40983
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Turn it into a macro that looks like a function, and add another, more
generic `iosav_run_queue` that covers all current use-cases. They will
be replaced with functions in a follow-up to preserve reproducibility.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I07b260b5fb111c1408ff75316dc0735a9e642ac9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
To replace the register writes with assignments to struct fields, we
would need to have the values as parameters of a single macro. So,
split the raw value of `IOSAV_n_SP_CMD_CTRL_ch` in two parts. Note that
the single command that sets bit 17 is likely wrong, but it will be
fixed after refactoring. For now, we'll treat it as part of `ranksel`.
Move the parameters of `ADDR_UPDATE` into the top-level IOSAV macro.
Hopefully, this will be enough to replace the underlying implementation.
Line length limits are not for review. Breaking the lines unnecessarily
complicates search and replace operations, and wil be taken care of in
subsequent commits.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I404edbd5d90ddc2a6993f39f552480d1ef24e153
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40978
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
New information indicates the PSP expects the APOB NV region
populated for all types of boot, and this is not a feature only
used for S3. Switch over to using the MRC_CACHE flash region.
Remove the Kconfig symbols for the APOB_NV base and size. Override
the MRC_CACHE_SETTINGS_CACHE_SIZE to ensure the default maintains the
minimum required size. Use the generated (or mainboard-specified)
fmap.fmd file as an input for amdfwtool and properly match the
flash region.
Change the original naming for the APOB destination, which matched the
PSP spec's field name, to PSP_APOB_DESTINATION. This should be more
intuitive for a source code reader. The APOB address is the location
in DRAM where the PSP puts its output block.
BUG=b:147042464, b:153675914
TEST=Boot trembyle
Original-Change-Id: Ia5ba8646deec2bd282df930f471738723063eef8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2080375
Original-Change-Id: I972d66f1817f86ff0b689f011c0c44c3fe7c8ef7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2053312
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: I4550766ece462b65a6bfe6f1b747343e08e53fe5
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The audio devices are currently set to enable static devices at their
own level, but in order to supported nested SoundWire devices these
drivers must instead use scan_static_bus. Without this change the
device tree code will not look at children of these devices.
After this change the audio device can have nested devices:
device pci 1f.3 on
chip drivers/intel/soundwire
device generic 0 on end
end
end
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ibb716fbd9ffdc45f2c4bbe5e81f420ec2b13483c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds a help function to write a SoundWire ACPI address
object that conforms to the SoundWire DisCo Specification Version 1.0
The SoundWire address structure is defined in include/device/soundwire.h
and provides the properties that are used to form the _ADR object.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I6efbf52ce20b53f96d69efe2bf004b98dbe06552
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40885
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change uses the previously added SoundWire definitions to provide
functions that generate ACPI Device Properties for SoundWire
controllers and codecs.
A SoundWire controller driver should populate
`struct soundwire_controller` and pass it to
soundwire_gen_controller(). This will add all of the defined master
links provided by the controller.
A SoundWire codec driver should populate the necessary members in
struct soundwire_codec and pass it to soundwire_gen_codec().
Several properties are optional and depend on whether the codec itself
supports certain features and behaviors.
The goal of this interface is to handle all of the properties defined
in the SoundWire Discovery and Configuration Specification Version
1.0 so that controller and codec drivers do not need to all have code
for writing standard properties.
Both of these functions also provide a callback method for adding
custom properties that are not defined by the SoundWire DisCo
Specification. These properties may be required by OS drivers but are
outside of the scope of the SoundWire specification itself.
This code is tested with controller, codec, and mainboard
implementations in subsequent commits.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ib185eaacf3c4914087497ed65479a772c155502b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
I'm not quite sure what happened when we first added the code for
Trogdor strappings but something clearly seems to be wrong. First of
all, on newer schematics the RAM_ID_1 pin is actually pin 19, not pin
91. It only used to be 91 on rev0. Whether that was an intentional
change or someone just swapped the digits on accident at some point,
we're not quite sure anymore, but it seems to be 19 going forward so
that is what we should be programming. (ram_code wasn't used for
anything on Trogdor rev0 so we don't care about adding
backwards-compatibility for that.)
The sku_id pins are also somewhat out of whack: first of all, a new
SKU_ID_2 pin was added for rev1 that wasn't there on rev0. Second,
SKU_ID_0 is not GPIO_114. In fact, it has never been GPIO_114. I have no
idea how that number got there. Anyway, fix it. (Like with the ram_code,
SKU IDs were also not used for rev0 so we won't make this
backwards-compatible.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia14ec74ec2f16ce2661f89d0d597a5477297ab69
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philip Chen <philipchen@google.com>
A handful of boards do not properly implement the presence straps,
leading libgfxinit to fail to detect an attached display. Add an
override, defaulting to N, which can be set for affected boards.
Add a section to the documentation detailing the option and its usage.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I43c61d67147878887658b23d90fb1c0b91e7a2af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The devicetree declares the chrontel interrupt as GpioInt so the GPIO
needs to be configured as such instead of routing directly to APIC.
Also update the compatible string to conform to kernel standards.
BUG=b:146576073
TEST=install ch7322 driver; send commands using cec-ctl and verify
that the interrupt handler is called.
Change-Id: I737d951db135c53deb0f3cb956f0d0f275082251
Signed-off-by: Jeff Chase <jnchase@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The CA vref should alway select range[1]. But in fast calibration flow,
we missed the range selection and caused the CA vref to use the range[0] value.
The DQ vref should select correct range that corresponds to current frequency,
that is for 1600Mbps, 2400Mbps to select range[1], for 3200Mbps and 3600Mbps
to select range[0].
Refer to the 'JESD209-4 - Low Power Double Data Rate 4X(LPDDR4X).pdf',
used MR12 to set Vref(CA) levels, used MR14 to set VREF(DQ) levels.
MR12 range[0] values from 15.0% to 44.9%, range[1] values from 32.9% to 62.9%,
MR14 range[0] and range[1] values same as MR12.
BUG=b:153614919
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: Ie7680b1bf0c29c946d18e3b27626ce6f31c4216b
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40525
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
pmc.c was included in the SMM object, but only needed the one function,
pmc_soc_set_afterg3_en. pmutil.c was already doing power management-
related functionality, and was included in SMM, so moving
pmc_soc_set_afterg3_en to pmutil.c allows pmc.c to be removed from the
SMM build.
Change-Id: I87f65fd10d35f1f75516e804501d5319b81a0383
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41407
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Historically in coreboot, the PMC's fixed PCI resources were described
by the System Agent (the MMIO resource), and eSPI/LPC (the I/O
resource). This patch moves both of those to a new Intel SoC-specific
function, soc_pmc_read_resources(). On TGL, this new function takes care
of providing the MMIO and I/O resources for the PMC.
BUG=b:156388055
TEST=verified on volteer that the resource allocator is aware of and
does not touch these two resources:
("PCI: 00:1f.2 resource base fe000000 size 10000 align 0 gran 0 limit 0
flags f0000200 index 0
PCI: 00:1f.2 resource base 1800 size 100 align 0 gran 0 limit 18ff
flags c0000100 index 1")
Also verify that the MEM resource is described in the coreboot table:
("BIOS-e820: [mem 0x00000000fe000000-0x00000000fe00ffff] reserved")
Verified the memory range is also untouchable from Linux:
("system 00:00: [mem 0xfe000000-0xffffffff] could not be reserved")
Change-Id: Ia7c6ae849aefaf549fb682416a87320907fb3fe3
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41385
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some SoCs, there are PCI devices that may get hidden from PCI
enumeration by platform firmware. Because the Vendor ID reads back as
0xffffffff, it appears that there is no PCI device located at that BDF.
However, because the device does exist, designers may wish to hang its
PCI resources off of a real __pci_driver, as well as have it participate
in ACPI table generation.
This patch extends the semantics of the 'hidden' keyword in
devicetree.cb. If a device now uses 'hidden' instead of 'on', then it
will be assumed during PCI enumeration that the device indeed does
exist, and it will not be removed as a "leftover device." This allows
child devices to be enumerated correctly and also PCI resources can be
designated from the {read,set}_resources callbacks.
It should be noted that as of this commit, there are precisely 0 devices
using 'hidden' in their devicetree.cb files, so this should be a safe
thing to do.
Later patches will begin moving PCI resources from random places (typically
hung off of fixed SA and LPC) into the PMC device (procedure will vary per-
platform).
Change-Id: I16c2d3e1d1433343e63dfc16856cff69cd815e2a
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41384
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Link frequency and a format was not correct for volteer proto 2
ov2740 user-facing camera.
The link frequency is calculated in the following way.
(max frame width * max frame height * max fps * data format in bps
/ number of lanes / data rate) + max 35% of overhead
For ov2740, (1920 * 1080 * 60 * 10 / 2 / 2) = 311Mhz.
360Mhz after adding 18% of overhead.
BUG=b:148428976
BRANCH=none
TEST=Build and boot volteer proto 2 board. Start a camera app
and check user-facing camera functionalities.
Signed-off-by: Daniel Kang <daniel.h.kang@intel.com>
Change-Id: I3b51826e123dec394c1b4eb9a1c5b64b8b11459e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41157
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove unused processor power limit configuration parameter
and function call based on common code base support for
Intel Icelake SoC based platform.
BRANCH=None
BUG=None
TEST=Built for icelake based dragonegg board.
Change-Id: Id8923f2c176092b6f7acfbfb079587f88258dce8
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41236
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On Volteer port 0 (MB PORT) does not have a retimer so the port needs
to be configured for the SOC to handle Aux orientation flipping. This
requires 2 changes setting the TcssAuxOri UPD to 1 for port 0 (Bit 0)
and configuring AUXP and AUXN GPIOs to Native Function 6 so SOC can
control the orientation
BUG=b:145220205
BRANCH=NONE
TEST=booted Volteer proto 2 and verified that the AUX channels flip
when the cable is flipped
Change-Id: Ic81adc24d10322cc305bf0fa4c38514468ea0942
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
In order for the SOC to be able to control the Aux line orientation for
Type-C ports that do not have a retimer, the IomTypeCPortPadCfg UPD needs
to be configurable through devicetree to correctly set the GPIO pins that
the SOC should use to flip orientation.
BUG=b:145220205
BRANCH=NONE
TEST=booted Volteer proto 2 and verified that the AUX channels flip
when the cable is flipped
Change-Id: I2e48adb624c7922170eafb8dfcaed680f008936e
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40244
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add tcss.asl to support TCSS power management.
For the detail please refer cb:39785.
BUG=none
TEST=Check TBT PCIe root ports: 00:07.0/00:07.1/00:07.2/00:07.3
/sys/bus/pci/devices/bus:device:func/power suspend and
active time can increase.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I432f3d6643de13b08c07e47f799c0ecdfe047de6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41506
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add method acpi method GPID to return the GPIO PCR port ID.
This method is further planned to be used for GPIO power
management configuration.
TEST=Build waddledoo board
Change-Id: Ic45b40bbe39e303cddcc82e0e848786b7311ab64
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The resource allocator woes post-4.12 release showed room for
improvement on both discussion and documentation. To encourage this
(and encourage reviewers to look out for issues in that space),
extend the review guidelines so that they encourage to more clearly
document the reason for a change with the change (commit message or
our documentation) and also to loop in the mailing list.
Change-Id: I1962dba3fe7e1a01fa4c8b0058297c7d050cb7b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Originally variants make use of a 32MB chip whereas now they
use a 16MB SPI flash. Allow for the coordination of dealing
with the transition between phases.
V.2: Leave Puff alone at the moment due to the complexity of
coordination.
BUG=b:153682192
BRANCH=none
TEST=none
Change-Id: Ic336168ea1a0055c30f718f5540209d2cf69d029
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40897
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Lower 20bits of TOLUD and TOLM registers include 19 reserved bits and
1 lock bit. If lock bit is set, then systemagent.asl would end up
reporting the base address of low MMIO incorrectly i.e. off by 1.
This change masks the lower 20 bits of TOLUD and TOM registers when
exposing it in the ACPI tables to ensure that the base address of low
MMIO region is reported correctly.
Change-Id: I11b3ef8deda21930998471ab6e712da4c62f5b02
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change updates systemagent.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for auron.
Change-Id: I479bb6cb7ed4c9265325c7c8621f03454f21f467
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Lower 20bits of TOLUD and TOLM registers include 19 reserved bits and
1 lock bit. If lock bit is set, then systemagent.asl would end up
reporting the base address of low MMIO incorrectly i.e. off by 1.
This change masks the lower 20 bits of TOLUD and TOM registers when
exposing it in the ACPI tables to ensure that the base address of low
MMIO region is reported correctly.
Change-Id: I2ff7a30fabb7f77d13acadec1e6e4cb3a45b6139
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41470
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change updates systemagent.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for soraka.
Change-Id: If8d8dd50af9a79d30f54e98f7f2fe7ce49188763
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
CB:41454 updated northbridge.asl to ASL2.0 syntax. During this, GPCL
was incorrectly updated to use << (ShiftLeft) instead of >>
(ShiftRight). This change fixes the error in GPCL by updating it to
use >> (ShiftRight).
TEST=Verified using --timeless option to abuild that the resulting
coreboot.rom is same as without the ASL2.0 syntax changes for hatch.
Change-Id: I36469cb3b0bcc595acf0e43808d6a574986cad68
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41519
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCI interrupt devices were only partially implemented.
* Lacked support for _DIS to disable the bus. Something the kernel does
while booting.
* Lacked support for APIC vs PIC. This means the devices can only be
used when using the PIC. By looking at the PMOD variable we can handle
both PIC and APIC. This means we can stop hard coding the PCI interrupt
numbers in the ACPI tables.
* I removed INT[E-H] since they are not used.
BUG=b:139429446, b:147042464
BRANCH=none
TEST=Boot with both the APIC and PIC and saw that the link devices work
as expected:
PIC MODE:
[ 1.959345] ACPI: PCI Interrupt Link [IRQA] (IRQs 1 3 4 5 *6 7 8 9 10 11 12 14 15)
[ 2.007344] ACPI: PCI Interrupt Link [IRQB] (IRQs 1 3 4 5 *6 7 8 9 10 11 12 14 15)
[ 2.056344] ACPI: PCI Interrupt Link [IRQC] (IRQs 1 3 4 5 6 7 8 9 10 11 12 *14 15)
[ 2.104344] ACPI: PCI Interrupt Link [IRQD] (IRQs 1 3 4 5 6 7 8 9 10 11 12 14 *15)
[ 13.752676] PCI Interrupt Link [IRQA] enabled at IRQ 6
[ 13.816755] PCI Interrupt Link [IRQD] enabled at IRQ 15
[ 27.788798] PCI Interrupt Link [IRQB] enabled at IRQ 6
[ 27.852873] PCI Interrupt Link [IRQC] enabled at IRQ 14
APIC MODE:
[ 19.311764] ACPI: PCI Interrupt Link [IRQA] (IRQs *16 17 18 19 20 21 22 23)
[ 19.374765] ACPI: PCI Interrupt Link [IRQB] (IRQs 16 *17 18 19 20 21 22 23)
[ 19.438770] ACPI: PCI Interrupt Link [IRQC] (IRQs 16 17 *18 19 20 21 22 23)
[ 19.501764] ACPI: PCI Interrupt Link [IRQD] (IRQs 16 17 18 *19 20 21 22 23)
[ 34.719072] PCI Interrupt Link [IRQA] enabled at IRQ 23
[ 34.798994] PCI Interrupt Link [IRQD] enabled at IRQ 22
[ 66.469510] PCI Interrupt Link [IRQB] enabled at IRQ 21
[ 66.542395] PCI Interrupt Link [IRQC] enabled at IRQ 20
Change-Id: I1bb84813b65c89b4b5479602be3e9a9fedb7333d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2095683
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This header implements structures to describe the properties defined in
the SoundWire Discovery and Configuration Specification Version 1.0.
By itself this just provides the property definitions, it is then used
by the code that generates ACPI device properties and by the controller
and codec drivers.
A new header for MIPI vendor/device IDs is also added, with the MIPI
Alliance board members added by default. This will be used in the same
way as pci_ids.h to track devices added to coreboot.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ie9901d26d1efe68edad7c049c98a976c4e4f06f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The common PnP serial port DSDT code is intentionally included twice for
two serial ports with different LDNs. Undefine LDN and the PM register
name before redefining for second serial port so iasl doesn't complain.
Change-Id: I031905479c66698fb01da028e3f37d923396d2d9
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41095
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current implementation uses strcmp() without splitting the list
and therefore returns false even when the string pointed to by
'name' is a part of 'whitelist'. The patch fixes this problem.
Also, update help text of CONFIG_TPM_MEASURED_BOOT_RUNTIME_DATA to
space delimited list to align it with the other lists we use.
Change-Id: Ifd285162ea6e562a5bb18325a1b767ac2e4276f3
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41280
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The IOSAV register descriptions are plagued with errors and nonsense.
Using `git blame` to find the culprit... Zoinks! Turns out it was me!
Rewrite the comment so that the difference between a sub-sequence and a
command is clear. Also, expand the descriptions that could be ambiguous
and fix some insane blunders. CKE and ODT fields are per DIMM and rank!
As per review comments, also invert the order of bitfield value ranges.
Change-Id: Ie384304c565f962fe58baa231c15109eb3d284aa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch adds a basic test for the common region and region_device
APIs, sanity checking the basic functions and things like
overflow-handling. There is certainly more that could be added here, but
it's a start.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4932402f54768557e5b22b16e66220bd90ddebfd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41046
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Jan Dabros
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<cmocka.h> requires a few standard headers to be explicitly included
before itself or it will throw compilation errors. Having to always
include these headers in the right order in every test is cumbersome.
Instead, this patch encapsulates the problem in a new <tests/test.h>
header that all tests should include (instead of <cmocka.h> directly).
Also fix --gc-sections in the test framework which needs to be passed
for linking, not for compiling.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4284d74c8673708e21a5266eb42f7b9ae19a1b12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41045
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Fix unterminated array.
When looking for a type not specified in filetypes (cbfs.h:204), the
loop in lookup_name_by_type (cbfs_image.c:60) will run into a buffer
over-read.
Found-by: AFL++ 2.64d rev 1317433
Signed-off-by: Philipp Bartsch <phil@grmr.de>
Change-Id: Ib82bb92e82b09fa1e26b9ca34529ec7b98e8f7b1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41421
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No code that was or will be upstreamed uses functionality from soc_util
in romstage, so only compile and link it for ramstage.
This also allows to fix the SoC type detection in a follow-up patch
using information that FPS-M will be providing in a HOB.
BUG=b:153779573
Change-Id: If96e53608eadd562f6de5a0c370b89e84e43d049
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The struct (formerly assigned to default_pci_ops_bus.ops_pci) only
contained a NULL (well, 0) pointer for the set_subsystem callback, but
usage of that callback is guarded with NULL checks when it is used,
therefore it can be removed.
TEST=still compiles
Change-Id: I3943c8ae73b95e744a317264d7ceb8929cb28341
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41432
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update processor power limit configuration parameters based on
common code base support for Intel Broadwell SoC based platforms.
BRANCH=None
BUG=None
TEST=Build for broadwell based platform
Change-Id: I97e38a533e74a122b6809e20a10f6e425827ab9c
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Don't directly include <soc/gpio.h>. All code using GPIO features
should always and only include <gpio.h>, which should indirectly
include the SoC-specific <soc/gpio.h>.
Change-Id: I78f1e250570f1b395c61115d4a872b24b3d58f69
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Don't directly include <soc/gpio.h>. All code using GPIO features
should always and only include <gpio.h>, which should indirectly
include the SoC-specific <soc/gpio.h>.
Change-Id: Id2663398b9f069ab1f60d63016ea7aa080f66d20
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Add function to display ME Host Firmware Status registers. Make use of
print_me_fw_version() from CSE lib to print ME firmware version information.
Add manufacturing mode field in HFSTS1 register for JSL in place of,
spi_protection_mode in TGL.
BUG=None
BRANCH=None
TEST=Build and boot jslrvp. In coreboot logs, ME info can be seen.
ME: Version: 13.5.0.7049
ME: HFSTS1 : 0x90006255
ME: HFSTS2 : 0x82100136
ME: HFSTS3 : 0x00000020
ME: HFSTS4 : 0x00004800
ME: HFSTS5 : 0x00000000
ME: HFSTS6 : 0x00400006
ME: Manufacturing Mode : YES
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: CPU Replaced : YES
ME: CPU Replacement Valid : YES
ME: Current Working State : 5
ME: Current Operation State : 1
ME: Current Operation Mode : 0
ME: Error Code : 6
ME: CPU Debug Disabled : YES
ME: TXT Support : NO
Change-Id: Ic6b1c9410db8f06ac24fd997772b2ede04264bee
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Deltaur uses HDA codec so we need to set iDisplay Audio Codec
disconnection and enable HdaAudioLink, otherwise the HDA codec won't
respond to commands to execute HDA verbs.
BUG=b:156447983
TEST=No timeout error when run "devbeep" in CLI.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I15d2895866abcf68963c9732ed5d05f32096fc92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41397
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The index of DRAM_STRAPS indicates to a specific DRAM characteristic
instead of a DRAM part number therefore update the existing DRAM SPD
binary to the naming by DRAM characteristic.
BUG=b:152019429
BRANCH=None
TEST=build the image and verify that coreboot log shows the correct SPD
info
Change-Id: I8ffcf156f37a465209740c5e2a34effb5f1f5d5c
Signed-off-by: Marco Chen <marcochen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reading the SPD using the SMBUS routines takes a long time because each
byte or word is access seperately.
Allow using the i2c read eeprom routines to read the SPD. By doing this
the start address is only sent once per page.
The time required to read a DDR4 SPD is reduced from 200 msec to 50
msec.
BUG=N/A
TEST=tested on facebook monolith
Change-Id: I44e18b8ba72e1b2321f83402a6a055e2be6f940c
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Update monolith root port settings to match those of the original BIOS.
MaxPayload is set to 256 bytes, ASPM is disabled and LTR and Advanced
Error reporting are enabled.
BUG=N/A
TEST=tested on facebook monolith
Change-Id: Idf6e706d45cf1ea1aee4a75a6d0eb130b21db927
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
If panel has too small hfp or hbp, hfp_byte or hbp_byte may become
very small value or negative value. When very small value or
negative value is used, the panel will be scrolling or distorted.
This patch adjusts their values so that they are greater than
the minimum value and keep total of them unchanged.
DSI transfer HBP or HFP, There are some extra packet. ex. packet
header(4byte) and eof(2byte) and (next)hs packet header(4 byte).
the hfp_byte = HFP * BPP - packet header(4byte) and eof(2byte)
and (next)hs packet header(4 byte). So the min hfp_byte is 2 when
HFP = 4.
This is equivalent to the Linux kernel DSI change in:
https://chromium-review.googlesource.com/c/chromiumos/third_party/
kernel/+/2186872
BUG=b:144824303
BRANCH=kukui
TEST=boot damu board with panel CMN N120ACA-EA1 (12" panel and its
hbp only 6), the panel can display without scrolling or
distortions.
Signed-off-by: Paul Ma <magf@bitland.corp-partner.google.com>
Change-Id: I608c01d41ae93c8d5094647bbf3e0ae4a23d814c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41163
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default ROMSTAGE_ADDR and VERSTAGE_ADDR are set to 0x2000000. This
causes problems in a non-xip environment because when verstage loads
romstage, it overrides it's memory. So pick a different offset for
verstage.
BUG=b:147042464
TEST=Boot verstage on trembyle and see OS boot.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2464db6f3769bd23d250588b341d1c9e44f10d21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41367
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CPU to PCH method refers to PCH ACPI operation region which was wrongly
defined as SystemIO. This causes ACPI AE_LIMIT error from PM _DSW
method. Change the operation region from SystemIO to SystemMemory to
resolve this execution failure.
BUG=b:140290596
TEST=Built and booted to kernel. _DSW method executes successfully without
ACPI AE_LIMIT error.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I3965c3d891f7d3cf4a448edc0c3f7e7749a905a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
NO_RANKSEL was introduced because it appeared less often and it did not
cause any lines to become too long. To simplify macro transmutation, add
the RANKSEL opposite and keep NO_RANKSEL as a no-op to ease replacement.
Line length limits are not for review. Breaking the lines unnecessarily
complicates search and replace operations, and wil be taken care of in
subsequent commits.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I5d7aad59fc79840da7de2e9421b84834a6024eb9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40977
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a temporary solution to simplify refactoring verification.
Programming a subsequence involves writing a group of four registers.
Abstract this into a "program subsequence" operation. This eliminates
register write noise, which should improve the readability of the code.
To replace the register writes with assignments to struct fields, we
would need to have the values as parameters of a single macro. So,
unroll SUBSEQ_CTRL and SP_CMD_ADDR into parameters of IOSAV_SUBSEQUENCE.
Line length limits are not for review. Breaking the lines unnecessarily
complicates search and replace operations, and wil be taken care of in
subsequent commits.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I23f7706ba8a87c1c26f9d40a50b6d47dcf95106a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
We have a single IOSAV sequence that is broadcast across all channels.
Introduce the BROADCAST_CH macro, so that we can use the per-channel
register definitions. Treating all IOSAV sequence writes the same eases
the refactoring done in subsequent commits. Also, drop the broadcast
register definitions for the IOSAV commands, as they are now obsolete.
Line length limits are not for review. Breaking the lines unnecessarily
complicates search and replace operations, and wil be taken care of in
subsequent commits.
Tested with BUILD_TIMELESS=1, ASUS P8Z77-V LX2 remains unchanged.
Change-Id: I2dbb100fcad68d128e92b1bc9321fc1e53b748c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40976
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With conversion to variant structure complete, remove temporary guards
inserted to help validate the move.
With this change, all P2B family boards (currently p2b and p2b-ls)
share the same S-state declarations.
TEST=No apparent ACPI regression observed on p2b-ls.
Change-Id: Ibd6e49adeae2a42800ee5bfd74b3850eb19843a5
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Lower 20bits of TOLUD register include 19 reserved bits and 1 lock
bit. If lock bit is set, then northbridge.asl was reporting the base
address of low MMIO incorrectly i.e. off by 1. This resulted in Linux
kernel complaining that the MMIO window allocated to the device at the
base of low MMIO is incorrect:
pci 0000:00:1c.0: can't claim BAR 8 [mem 0x7fc00000-0x7fcfffff]: no compatible brw
pci 0000:00:1c.0: [mem 0x7fc00000-0x7fcfffff] clipped to [mem 0x7fc00001-0x7fcfff]
pci 0000:00:1c.0: bridge window [mem 0x7fc00001-0x7fcfffff]
This change masks the lower 20 bits of TOLUD register when exposing it
in the ACPI tables to ensure that the base address of low MMIO region
is reported correctly.
TEST=Verified that kernel dmesg no longer complains about the BAR at
base of low MMIO.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I4849367d5fa03d70c50dc97c7e84454a65d1887a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41455
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the autoport. The OptiPlex 9010 comes in four different sizes:
MT, DT, SFF and USFF. Tested on SFF only. The other PCBs are slightly
different, but they are designed with intercompatibility in mind. With
small devicetree overrides it should work on OptiPlex 7010 and other
OptiPlex 9010 variants as well.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I88d65cae30d08ca727d86d930707c2be25a527cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40351
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SMSC SCH5545 is very similar to the publicly available
datasheet for the SCH5627.
TEST=use PS2 keyboard and mouse, serial port, runtime registers and
Embedded Memory Interface on Dell Optiplex 9010
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: If8a60d5802675f09b08014ed583d2d8afa29fc04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40350
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Correct comment on HMRFPO_ENABLE flow for CSE Lite SKU. In order to place
CSE into SECOVER_MEI_MSG mode, below procedure has to be followed.
1. Ensure CSE boots from RO(BP1).
- Set CSE's next boot partition to RO
- Issue GLOBAL_RESET HECI command to reset the system
2. Send HMRFPO_ENABLE command to CSE. Further, no reset is required.
TEST=Verified on hatch
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I213e02ba3898194fa6c8fe38fab34b5c19f25aa1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41340
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on Fibocom HW user manual RESET should be deasserted at least 20ms after the power on pin.
The design for the reset pin is open drain connected to a pull up, so it is set to high-Z (configured as GPIO in) after 20ms.
BUG=b:152013143
BRANCH=none
TEST=traced the signals using a scope to verify timing is met.
Signed-off-by: Alex Levin <levinale@chromium.org>
Change-Id: I7c947d1bc4cce1f97383a2f2c254986e182661c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Power key is a special non-matrixed key. Chrome /powerd
only listens to the keyboard device for this key, so add
its keymap.
BUG=b:155941390
TEST=Test that power key generates KEY_POWER in linux evtest
Change-Id: I570602d9febcb5c17e58761f2004ee88be16c27f
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I49ce6ac88c4cb7cd05ff9d78133593ce97304596
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41374
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I419be7edf289636b24b9a7d6c390866ade638de3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I16f0439679471366723a0084918a20cd95834831
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41372
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources
during read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I532f508936d5ec154cbcb3538949316ae4851105
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). This change fixes the order by adding resources in
read_resources().
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I84c1ba8645b548248a8bb8bf5bc4953d3be12475
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The chipset code was incorrectly adding memory resources
to the domain device after resource allocation occurred.
It's not possible to get the correct view of the address space,
and it's generally incorrect to not add resources during
read_resources(). Fix the order by hanging the resources off
of the host bridge device.
Change-Id: I8a7081020be43da055b7de5a56dd97a7b5a9f09c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41364
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: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This change uses cpu_phys_address_size() to calculate the size of high
MMIO region instead of a macro for each SoC. This ensures that the
entire range above TOUUD that can be addressed by the CPU is used for
MMIO above 4G boundary.
Change-Id: I01a1a86c0c65856f9f35185c2f233c58f18f5dfe
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There should be no harm in advertising the MMIO window above 4G in
ACPI tables unconditionally. OS can decide whether or not to use the
window. This change removes the config option enable_above_4GB_mmio
and instead adds the correct MMIO window (above 4G) details to ACPI
tables always.
Change-Id: Ie728f6ee7f396918e61b29ade862b57dac36cb08
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41276
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change sets the base for MMIO above 4G to TOUDD. It matches what
is used by resource allocator if MMIO resources are allocated above 4G
and also matches the expectation in northbridge.asl. This change
also gets rid of the macro ABOVE_4GB_MEM_BASE_ADDRESS since it is now
unused.
BUG=b:149186922
TEST=Verified that kernel does not complain about MMIO windows above
4G.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ibbbfbdad867735a43cf57c256bf206a3f040f383
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code is based on autoport and that for X230. Major differences are:
- Only one DDR3 slot
- HM77 PCH
- M.2 socket instead of mini pci-e
- no docking
- no tpm
Tested:
- CPU i5-3337U
- Slotted DIMM 8GiB
- Camera
- pci-e and usb2 on M.2 slot with A key for wlan
- sata and usb2 (no superspeed components) on M.2 slot with B key for wwan
- On board SDHCI connected to pci-e
- USB3 ports
- libgfxinit-based graphic init
- NVRAM options for North and South bridges
- Sound
- Thinkpad EC
- S3
- Linux 4.9 within Debian GNU/Linux stable, loaded from
Seabios.
Untested:
- Touch screen, which is said to work under ubuntu but not debian.
Change-Id: Ie537645d5ffaee799e79af2f821f80c3ebd2dfec
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds a SPI rom region RW_SPD_CACHE on Puff and it can be used
on spd_cache to reduce reading SPD data from SODIMM by smbus. It's for
saving the boot time and it can be used to trigger MRC retraining when
memory DIMM is changed.
BUG=b:146457985
BRANCH=None
TEST=Build puff successfully and verified below two items.
1. To change memory DIMM can trigger retraining.
2. one DIMM save the boot time : 158ms
two DIMM save the boot time : 265ms
Change-Id: I8d07fddf113a767d62394cb31e33b56f22f74351
Signed-off-by: Jamie Chen <jamie.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch adds some spd_cache functions. They are for implementing the
spd_cache. It's for reducing the SPD fetch time when device uses SODIMMs.
The MRC cache also includes SPD data, but there is no public header file
available to decode the struct of MRC. So SPD cache is another solution.
BUG=b:146457985
BRANCH=None
TEST=Build puff successfully and verified below two items.
one DIMM save the boot time : 158ms
two DIMM save the boot time : 265ms
Change-Id: Ia48aa022fabf8949960a50597185c9d821399522
Signed-off-by: Jamie Chen <jamie.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40797
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch adds the get_spd_sn function. It's for reading SODIMM serial
number. In spd_cache implementation it can use to get serial number
before reading whole SPD by smbus.
BUG=b:146457985
BRANCH=None
TEST=Wrote sample code to get the serial number and ran on puff.
It can get the serial number correctly.
Change-Id: I406bba7cc56debbd9851d430f069e4fb96ec937c
Signed-off-by: Jamie Chen <jamie.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40414
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adds SPD_LPDDR4X_556b_1R_32Gb_8GbD_QDP_4267.spd.hex, which will be used
initially for the "H9HKNNNCRMBVAR-NEH" SKhynix part as DRAM ID #0.
Adds SPD_LPDDR4X_556b_1R_64Gb_16GbD_QDP_4267.spd.hex, which will be
used initially for the "MT53E1G64D4SQ-046 WT:A" Micron part as
DRAM ID #1.
BUG=b:155423877
TEST=none
Change-Id: I5580f602cd411e415dafcb36bd1ffa43c4f02f60
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41076
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Add SPD_LPDDR4X_200b_1R_16Gb_16Row_DDP_4267.spd.hex, initially
used for the SKhynix H9HCNNNBKMMLXR-NEE part with DRAM ID #2
- Add SPD_LPDDR4X_200b_2R_64Gb_ODP_4267.spd.hex, initially
used for the SKhynix H9HCNNNFAMMLXR-NEE part with DRAM ID #3
- Add SPD_LPDDR4X_200b_2R_32Gb_QDP_4267.spd.hex, initially
used for the Micron MT53E1G32D2NP-046 WT:A part with DRAM ID #4
BUG=b:147857288
TEST=none
Change-Id: I60d8bb05a4d6d3608adc7de69efc8623d1ca610d
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41126
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard specific dock-init mechanism introduced
https://review.coreboot.org/c/coreboot/+/36093 works on most boards,
but https://ticket.coreboot.org/issues/256 shows that some boards
(e.g. x201 and t410) need communication with h8 EC to enable or
disable dock, (in dock_connect() and dock_disconnect() respectively)
so they must be done after the h8 EC is brought up, which is not
garanteed in the above mainboard specific dock-init mechanism.
This time, a hook function h8_mb_init() will be called at the end of
h8_enable(). (in place of the ancient h8_mainboard_init_dock() removed
in CB:36093) Its default implementation is a weak empty function, but
could be overrided with a strong one for boards needing to perform
actions which should be done after h8 EC is brought up.
This should fix the regression detected in
https://ticket.coreboot.org/issues/256
Change-Id: I3674fbfeab2ea2cd2a4453a8e77521157d553388
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This change selects SOC_AMD_COMMON_BLOCK_HAS_ESPI which enables
the capability for using eSPI on Picasso.
Additionally, it also calls espi_setup() and espi_configure_decodes()
if mainboard enables use of eSPI and skips LPC decodes in that case.
BUG=b:153675913,b:154445472
Change-Id: I4876f1bff4305a23e8ccc48a2d0d3b64cdc9703d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This change adds a helper function espi_setup() which allows SoCs to
configure connection to slave. Most of the configuration is dependent
upon mainboard settings in espi_config done as part of the device
tree. The general flow for setup involves the following steps:
1. Set initial configuration (lowest operating frequency and single mode).
2. Perform in-band reset and set initial configuration since the
settings would be lost by the reset.
3. Read slave capabilities.
4. Set slave configuration based on mainboard settings.
5. Perform eSPI host controller configuration to match the slave
configuration and set polarities for VW interrupts.
6. Perform VW channel setup and deassert PLTRST#.
7. Perform peripheral channel setup.
8. Perform OOB channel setup.
9. Perform flash channel setup.
10. Enable subtractive decoding if requested by mainboard.
BUG=b:153675913
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I872ec09cd92e9bb53f22e38d2773f3491355279e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41272
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Memory SPD files for each variant are now stored in the variant's
mb/google/volteer/variants/<variant_name>/spd directory instead
of storing them in mb/google/volteer/spd.
This change moves SPDs to where they are needed and changes the
makefile to look for them in their new locations.
BUG=b:156126658
TEST="emerge-volteer coreboot chromeos-bootimage", flash and boot
a proto2 SKU4 to the kernel.
Change-Id: I759c979027477a2a4c5489a6b12278799488d6e7
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41184
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To change frequency, the SOC PLL team suggests procedure below:
First, we need to enable the intermediate clock and
switch the ca53 clock source to the intermediate clock.
Second, disable the armpll_ll clock output.
Third, raise armpll_ll frequency and enable the clock output.
The last, switch the ca53 clock source back to armpll_ll and
disable the intermediate clock.
BUG=b:154451241
BRANCH=jacuzzi
TEST=Boots correctly on Jacuzzi.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Change-Id: Ib9556ba340da272fb62588f45851c93373cfa919
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41077
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CB:41194 got rid of "this file is part of" lines. However, there are
some changes that landed right around the same time including those
lines. This change uses the following command to drop the lines from
new files:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ic3c1d717416f6b7e946f84748e2b260552c06a1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41342
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Immediately following FSP-S, update the data fabric routing
registers to make the region between HPET and LAPIC as non-posted.
If AGESA is modified to do this, we can delete data_fabric_util.c. If
AGESA is modified to not program the registers, then we can simplify
data_fabric_set_mmio_np().
BUG=b:147042464, b:156296146
TEST=boot trembyle
Change-Id: Idbafaac158f5a4c533d2d88db79bb4d6244e5355
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41268
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Family 17h devices are designed with a new internal architecture,
frequently referred to as the data fabric. Although designed to
behave somewhat like the older integrated northbridge designs,
the D18Fx definitions are completely new.
The previous northbridge.c was copied from stoneyridge which is
completely different.
Change-Id: Id70cbda99657249179fb8cf5e461dd6a37ec9153
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41265
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When any USB image disk is connected to the DUT through
HUAWEI/APPLE Dongle, press Ctrl + u on the dev screen,
it cannot boot from USB.
We found the SS hub cannot be enumerated. So disable xHCI
compliance mode.
BRANCH=octopus
BUG=b:155347573
TEST=Confirm successful boot from USB
Change-Id: Iea4a3df156da0627336f7d6c1e03837b6cf0e7f2
Signed-off-by: tong.lin <tong.lin@bitland.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40905
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a helper function lpc_early_init() which does the
following things:
1. Enables LPC controller
2. Disables any LPC decodes (These can be set up later by SoC or
mainboard as required).
3. Sets SPI base so that MMIO base for SPI and eSPI controllers is
initialized.
BUG=b:153675913
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I016f29339466c3fee92fe9b62a13d72297c29b8e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Picasso has an LPC and eSPI bridge on the same PCI DEVFN. They can both
be active at the same time. This adds a way to specify which devices
belong on which bus.
i.e.,
device pci 14.3 on # - D14F3 bridge
device espi 0 on
chip ec/google/chromeec
device pnp 0c09.0 on end
end
end
device lpc 0 on
end
end
BUG=b:154445472
TEST=Built trembyle and saw static.c contained the espi bus.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0c2f40813c05680f72e5f30cbb13617e8f994841
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The default setting of the root port ASPM configuration can be
overridden from the device tree by using a non zero value.
BUG=N/A
TEST=tested on facebook monolith
Change-Id: I85c545d5eacb10f43b94228f1caf1163028645e0
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41171
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Current Interrupt setting use 2nd parameters as device function number.
- Correct as interrupt pin number according to _PRT package format.
{Address, pin, Source, Source index}
- Use irq number directly rather than irq definition as its number
is not for PCI device.
The issue found while enabling GBE and GBE interrupt is not working
without this change.
Reference
- ACPI spec 6.2.13 _PRT
- FSP reference code:
https://github.com/otcshare/CCG-TGL-Generic-SiC/blob/TGL.3163.01/
ClientOneSiliconPkg/IpBlock/Itss/LibraryPrivate/PeiItssPolicyLib/
PeiItssPolicyLibVer2.c
- BIOS reference code:
https://github.com/otcshare/CCG-TGL-Generic-Full/blob/master/
TigerLakeBoardPkg/Acpi/AcpiTables/Dsdt/PciTree.asl
TEST=boot to OS with GBE enabled and check GBE interrupt
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I8084b30c668c155ebabbee90b5f70054813b328e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
pci_domain_set_resources is duplicated in all the SOCs. This change
promotes the duplicated function.
Picasso was adding it again in the northbridge patch. I decided to
promote the function instead of duplicating it.
BUG=b:147042464
TEST=Build and boot trembyle.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iba9661ac2c3a1803783d5aa32404143c9144aea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change provides a helper function espi_update_static_bar() that
informs the eSPI common driver about the static BAR to use for eSPI
controller instead of reading the SPIBASE. This is required to support
the case of verstage running on PSP.
BUG=b:153675913
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I1f11bb2e29ea0acd71ba6984e42573cfe914e5d7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41256
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
FSP provides the UPD's for SATA and DMI power optimization.
In this patch we are adding the soc's config support to set
those power optimization bits in FSP. By default those
optimizations are enabled. To disable those we need to set
the DmiPwrOptimizeDisable and SataPwrOptimizeDisable to 1
in devicetree.
BUG=b:151162424
BRANCH=None
TEST=Build and boot volteer and TGL RVP.
Change-Id: Iefc5e7e48d69dccae43dc595dff2f824e53f5749
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change adds the following helper functions for eSPI decode:
1. espi_open_io_window() - Open generic IO window decoded by eSPI
2. espi_open_mmio_window() - Open generic MMIO window decoded by eSPI
3. espi_configure_decodes() - Configures standard and generic I/O
windows using the espi configuration provided by mainboard in device tree.
BUG=b:153675913,b:154445472
Change-Id: Idb49ef0477280eb46ecad65131d4cd7357618941
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41073
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds eSPI register definitions for I/O and MMIO decode
using eSPI on AMD SoCs. Additionally, it also adds a macro to define
the offset of ESPI MMIO base from SPI MMIO base.
BUG=b:153675913
Change-Id: Ifb70ae0c63cc823334a1d851faf4dda6d1c1fc1a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds support for using common SoC configuration by adding
soc_amd_common_config to soc_amd_picasso_config and helper function to
return pointer to the structure to amd common block code.
Change-Id: I8bd4eac3b19c9ded2d9a3e95ac077f014730f9d1
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds support for following SPI configuration functions to
common block SPI driver and exposes them to be used by SoC:
1. fch_spi_early_init(): Sets up SPI ROM base, enables SPI ROM,
enables prefetching, disables 4dw burst mode and sets SPI speed and mode.
2. fch_spi_config_modes(): This allows SoC to configure SPI speed and
mode. It uses SPI settings from soc_amd_common_config to configure the
speed and mode.
These functions expect SoC to include soc_amd_common_config in SoC
chip config and mainboard to configure these settings in device tree.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia4f231bab69e8450005dd6abe7a8e014d5eb7261
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41248
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a Kconfig option to request allocation of prefetch
memory for hotplug devices above the 4G boundary. In order to
select this option by default and still allow users to disable this if
required, another option is added to request allocation of prefetch
memory below 4G boundary which defaults to n but can be overriden
by mainboards.
Without this change, if the number of pciexp bridges supporting
hot-plug is more than 4 or if the reserved prefetch memory size for
hot-plug cases was increased, then the resource allocator would fail
to satisfy the resource requirement below 4G boundary.
BUG=b:149186922
TEST=Enabled resource allocation above 4G for prefetch memory on volteer
and verified that it gets allocated above 4G boundary.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I061d935eef9fcda352230b03b5cf14e467924e50
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39489
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates the resource limit for PCI domain to allow
resource allocation above 4G boundary. The resource limit is set to
the highest physical address for the CPU.
BUG=b:149186922
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Idfcc9a390d309886ee2b7880b29502c740e6578e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39488
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
BUG=b:149186922
TEST=Verified that resources get allocated above the 4G boundary
correctly on volteer.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I7fb2a75cc280a307300d29ddabaebfc49175548f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change updates the resource allocator in coreboot to allow using
multiple ranges for resource allocation rather than restricting
available window to a single base/limit pair. This is done in
preparation to allow 64-bit resource allocation.
Following changes are made as part of this:
a) Resource allocator still makes 2 passes at the entire tree. The
first pass is to gather the resource requirements of each device
under each domain. It walks recursively in DFS fashion to gather the
requirements of the leaf devices and propagates this back up to the
downstream bridges of the domain. Domain is special in the sense that
it has fixed resource ranges. Hence, the resource requirements from
the downstream devices have no effect on the domain resource
windows. This results in domain resource limits being unmodified after
the first pass.
b) Once the requirements for all the devices under the domain are
gathered, resource allocator walks a second time to allocate resources
to downstream devices as per the requirements. Here, instead of
maintaining a single window for allocating resources, it creates a
list of memranges starting with the resource window at domain and then
applying constraints to create holes for any fixed resources. This
ensures that there is no overlap with fixed resources under the
domain.
c) Domain does not differentiate between mem and prefmem. Since they
are allocated space from the same resource window at the domain level,
it considers all resource requests from downstream devices of the
domain independent of the prefetch type.
d) Once resource allocation is done at the domain level, resource
allocator walks down the downstream bridges and continues the same
process until it reaches the leaves. Bridges have separate windows for
mem and prefmem. Hence, unlike domain, the resource allocator at
bridge level ensures that downstream requirements are satisfied by
taking prefetch type into consideration.
e) This whole 2-pass process is performed for every domain in the
system under the assumption that domains do not have overlapping
address spaces.
Noticeable differences from previous resource allocator:
a) Changes in print logs observed due to flows being slightly
different.
b) Base, limit and size of domain resources are no longer updated
based on downstream requirements.
c) Memranges are used instead of a single base/limit pair for
determining resource allocation.
d) Previously, if a resource request did not fit in the available
base/limit window, then the resource would be allocated over DRAM or
any other address space defeating the principle of "no overlap". With
this change, any time a resource cannot fit in the available ranges,
it complains and ensures that the resource is effectively disabled by
setting base same as the limit.
e) Resource allocator no longer looks at multiple links to determine
the right bus for a resource. None of the current boards have multiple
buses under any downstream device of the domain. The only device with
multiple links seems to be the cpu cluster device for some AMD
platforms.
BUG=b:149186922
TEST=Verified that resource allocation looks correct based on
addresses assigned on Volteer.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia1f089877c62e119c6a994a10809c9cc0050ec9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39486
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently inteltool uses the addresses and names of the PCH of
previous generations. It's wrong for Lynx Point LP and Wildcat Point.
The addresses and names of the I/O registers can be found in "Mobile
4th Generation Intel Core Processor Family I/O Datasheet" (Document
Number: 329003-003) for Lynx Point LP and "Mobile 5th Generation Intel
Core Processor Family I/O, Intel Core M Processor Family I/O, Mobile
Intel Pentium Processor Family I/O, and Mobile Intel Celeron Processor
Family I/O Datasheet" (Document Number: 330837-004) for Wildcat Point.
Change-Id: If6ba718ccff077aa89affec89018bd7923527466
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40273
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit cc805d9dd6.
Advertising certain Windows versions triggers different paths in
the OS. As there may also be device specific quirks in the OS, such
changes need to be tested thoroughly on all affected devices.
There was at least one very subtle regression introduced by this.
When Linux sees "Windows 2012" support advertised, it disables the
`acpi_video` backlight controls, at least on devices with Intel IGD.
Without user-space handling the ACPI events, keyboard backlight
controls stop working.
Moreover, the commit message didn't state any reason for this change.
Why was it merged?
Change-Id: I722075f8e8f836b039fb8b8277e665fb49dac8f4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41192
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change splits lpc_set_spibase() into two separate functions:
lpc_set_spibase() - Sets MMIO base address for SPI controller and eSPI
controller (if supported by platforms)
lpc_enable_spi_rom() - Enables SPI ROM
This split is done to allow setting of MMIO base independent of ROM
enable bits. On platforms like Picasso, eSPI base is determined by the
same register and hence eSPI can set the BAR without having to touch
the enable bits.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3f270ba1745b4bb8a403f00cd069a02e21d444be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change adds support for struct soc_amd_common_config that allows
multiple AMD SoCs to share common configuration. This can then be used
by common/block drivers to get the required configuration from device
tree. It also provides function declaration for
soc_get_common_config() that needs to be provided by SoCs making use
of the common configuration structure.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Idb0d797525414c99894a8e4ede65469381db7794
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41246
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The System76 Lemur Pro (lemp9) is an upcoming laptop computer. Support
in coreboot is developed by System76 and provided as the default
firmware option. Testing is done on a pre-production model expected to
be identical from a firmware perspective to the production model.
Working:
- Payload
- Tianocore
- CPU
- Intel i7-10510U
- Intel i5-10210U
- EC
- ITE IT5570E running https://github.com/system76/ec
- Backlit Keyboard, with standard PS/2 keycodes and SCI hotkeys
- Battery
- Charger, using AC adapter or USB-C PD
- Suspend/resume
- Touchpad
- GPU
- Intel UHD Graphics 620
- GOP driver is recommended, VBT is provided
- eDP 14-inch 1920x1080 LCD
- HDMI video
- USB-C DisplayPort video
- Memory
- 8-GB DDR4 Samsung K4AAG165WA-BCTD (Channel 0)
- 8-GB/16-GB/32-GB DDR4 SO-DIMM (Channel 1)
- Networking
- M.2 PCIe/CNVi WiFi/Bluetooth
- Sound
- Realtek ALC293D
- Internal speaker
- Internal microphone
- Combined headphone/microphone 3.5-mm jack
- HDMI audio
- USB-C DisplayPort audio
- Storage
- M.2 PCIe/SATA SSD-1
- M.2 PCIe/SATA SSD-2
- RTS5227S MicroSD card reader
- USB
- 1280x720 CCD camera
- USB 3.1 Gen 2 Type-C (left)
- USB 3.1 Gen 2 Type-A (left)
- USB 3.1 Gen 1 Type-A (right)
Not working:
- TPM2 - SPI bus 0, chip select 2 is used. Chip selects other than 0
are not currently supported by the intel fast_spi driver.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: Ib0a32bbc6f89a662085ab4a254676bc1fad7dc60
This change adds support for allocating resources for PCI express hotplug
bridges when PCIEXP_HOTPLUG is selected. By default, this will add 32 PCI
subordinate numbers (buses), 256 MiB of prefetchable memory, 8 MiB of
non-prefetchable memory, and 8 KiB of I/O space to any device with the
PCI_EXP_SLTCAP_HPC bit set in the PCI_EXP_SLTCAP register, which
indicates hot-plugging capability. The resource allocation is configurable,
please see the PCIEXP_HOTPLUG_* variables in src/device/Kconfig.
In order to support the allocation of hotplugged PCI buses, a new field
is added to struct device called hotplug_buses. This is defaulted to
zero, but when set, it adds the hotplug_buses value to the subordinate
value of the PCI bridge. This allows devices to be plugged in and
unplugged after boot.
This code was tested on the System76 Darter Pro (darp6). Before this
change, there are not enough resources allocated to the Thunderbolt
PCI bridge to allow plugging in new devices after boot. This can be
worked around in the Linux kernel by passing a boot param such as:
pci=assign-busses,hpbussize=32,realloc
This change makes it possible to use Thunderbolt hotplugging without
kernel parameters, and attempts to match closely what our motherboard
manufacturer's firmware does by default.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: I500191626584b83e6a8ae38417fd324b5e803afc
This implements soc_display_fspm_upd_params for soc/intel/cannonlake
Some parameters are available only on Coffee Lake FSP or Comet Lake FSP
Tested on System76 galp3-c (Coffee Lake FSP) and System76 galp4 (Comet
Lake FSP)
This fixes the following:
- Fix smmstore_read_region to actually read stuff
- Make the API ARCH independent (no dependency on size_t)
- clean up the code a little
- Change the loglevel for non error messages to BIOS_DEBUG
Change-Id: I629be25d2a9b65796ae8f7a700b6bdab57b91b22
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
2019-05-02 15:24:13 -06:00
4272 changed files with 324110 additions and 59921 deletions
SMMSTORE is a SMM mediated driver to read from, write to and erase a
SMMSTORE is a [SMM] mediated driver to read from, write to and erase a
predefined region in flash. It can be enabled by setting
`CONFIG_SMMSTORE=y` in menuconfig.
@ -117,7 +117,18 @@ INPUT:
-`val`: pointer to the value data
-`valsize`: size of the value data
#### Security
Pointers provided by the payload or OS are checked to not overlap with the SMM.
That protects the SMM handler from being manipulated.
*However there's no validation done on the source or destination pointing to
DRAM. A malicious application that is able to issue SMIs could extract arbitrary
data or modify the currently running kernel.*
## External links
* [A Tour Beyond BIOS Implementing UEFI Authenticated Variables in SMM with EDKI](https://software.intel.com/sites/default/files/managed/cf/ea/a_tour_beyond_bios_implementing_uefi_authenticated_variables_in_smm_with_edkii.pdf)
Note, this differs significantly from coreboot's implementation.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
