It's possible that some BARs are not got their resource successfully
mapped, e.g. when these BARs are too large to fit into the available
MMIO window.
Not assigned resources might be with base address as 0x0. During
global resource search, these not assigned resources should not be
picked up.
One example is MTRR calculation. MTRR calculation is based on global
memory ranges. An unmapped BAR whose base is left as 0x0 will be
mistakenly picked up and recognized as an UC range starting from 0x0.
Change-Id: I9c3ea302058914f38a13a7739fc28d7f94527704
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66347
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
coreboot uses TianoCore interchangeably with EDK II, and whilst the
meaning is generally clear, it's not the payload it uses. EDK II is
commonly written as edk2.
coreboot builds edk2 directly from the edk2 repository. Whilst it
can build some components from edk2-platforms, the target is still
edk2.
[1] tianocore.org - "Welcome to TianoCore, the community supporting"
[2] tianocore.org - "EDK II is a modern, feature-rich, cross-platform
firmware development environment for the UEFI and UEFI Platform
Initialization (PI) specifications."
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4de125d92ae38ff8dfd0c4c06806c2d2921945ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65820
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We want to extend the vb2ex_hwcrypto APIs on the vboot side to allow
passing 0 for the data_size parameter to vb2ex_hwcrypto_digest_init()
(see CL:3825558). This is because not all use cases allow knowing the
amount of data to be hashed beforehand (most notable the metadata hash
for CBFS verification), and some HW crypto engines do not need this
information, so we don't want to preclude them from optimizing these use
cases just because others do.
The new API requirement is that data_size may be 0, which indicates that
the amount of data to be hashed is unknown. If a HW crypto engine cannot
support this case, it should return VB2_ERROR_EX_HWCRYPTO_UNSUPPORTED to
those calls (this patch adds the code to do that to existing HW crypto
implementations). If the passed-in data_size value is non-zero, the HW
crypto implementation can trust that it is accurate.
Also reduce a bit of the console spew for existing HW crypto
implementations, since vboot already logs the same information anyway.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ieb7597080254b31ef2bdbc0defc91b119c618380
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
When powering down SSUSB, the system needs to wait the ACK from SSUSB.
We found that the setting of USB PAD top macro is not correct and
it will cause timeout waiting for the ACK from SSUSB.
To resolve this, we add mt_pll_set_usb_clock() in pll.c to enable usb
macro control for powering down SSUSB.
TEST=timeout of ssusb powerdown ack does not occur.
BUG=b:239634625
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.corp-partner.google.com>
Change-Id: I58ba86e0467284e9947bfda1005c151a3e0c8881
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66600
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This change provides access to IOE through P2SB Sideband interface for
Meteor Lake TCSS functions of pad configuration and Thunderbolt
authentication. There is a policy of locking the P2SB access at the end
of platform initialization. The tbt_authentication is read from IOM
register through IOE P2SB at early silicon initialization phase and its
usage is deferred to usb4 driver.
BUG=b:213574324
TEST=Built coreboot and validated booting to OS successfully on MTLRVP
board. No boot hung was observed.
Change-Id: Icd644c945bd293a8b9c4a364aaed99ec4a7c12f9
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Delete the Thunderbolt authentication function ioe_tcss_valid_tbt_auth
from the common block. Meteor Lake Platform will implement it.
BUG=b:213574324
TEST=Built coreboot image successfully.
Change-Id: I97a289faa6351fe562f91d8478b72c9403ce88cb
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
DDR5 memory modules have two separate 32-bit channels (40-bit on ECC
memory modules), and the SPD info refers to one channel: the primary
bus width is 32 (or 40) bits and the "DIMM size" is halved. On Alder
Lake, there are 2 memory controllers with 4 32-bit channels each for
DDR5. FSP has 16 positions to store SPD data, some of which are only
used with LPDDR4/LPDDR5.
To try to make things less confusing, FSP abstracts the DDR5 channels
so that the configuration works like on DDR4. This is done by copying
each DIMM's SPD data to the other half-channel. Thus, fix the wrapper
parameters for DDR5 accordingly.
Tested on AlderLake-P DDR5 RVP (board ID 0x12), both DIMM slots now
function properly. Without this patch, only the top slot would work.
Change-Id: I5f01cd77388b89ba34d91c2dc5fb843fe9db9826
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66608
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
From Meteorlake, IGD BAR0(GTTMMADR) is changed to 64bit prefetchable.
Due to the prefetchable attribute, resource allocation for IGD BAR0 is
assigned WC memory and it causes kernel driver failure.
For avoiding kernel driver failure, ignore prefetch PCI attribute
for IGD BAR0 to assign UC memory.
We're working on publishing below information.
- IGD BAR0(GTTMMADR) is changed to 64bit prefetchable BAR
- GTTMMADDR BAR should be always mapped as UC memory although
marked Pre-fetchable.
BUG=b:241746156
TEST=boot to OS and check guc driver loading successful
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I76d816d51f32f99c5ebcca54f13ec6d4ba77bba5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66403
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
'Mendocino' was an embargoed name and could previously not be used
in references to Skyrim. coreboot has references to sabrina both
in directory structure and in files. This will make life difficult
for people looking for Mendocino support in the long term. The code
name should be replaced with "mendocino".
BUG=b:239072117
TEST=Builds
Cq-Depend: chromium:3764023
Cq-Depend: chromium:3763392
Cq-Depend: chrome-internal:4876777
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: I2d0f76fde07a209a79f7e1596cc8064e53f06ada
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The EC used on zork uses a level high interrupt. This change configures
the polarity correctly.
The eSPI config is baked into RO verstage. The zork ToT build doesn't
use signed verstage since it's incompatible with the ToT version of
vboot. This means we can safely switch the keyboard IRQ polarity.
NOTE: Do not cherry pick this into the Zork firmware branch!
BUG=b:160595155
TEST=On morphius verify keyboard works as correctly and no spurious
interrupts are thrown on S0i3 resume. Also verified keyboard and mouse
work correctly in windows.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8d3195522f3bd5e477635494c7156683aae0ff0a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The default state for the IRQ lines when the eSPI controller comes out
of reset is high. This is because the IRQ lines are shared with the
other IRQ sources using AND gates. This means that in order to not cause
any spurious interrupts or miss any interrupts, the IO-APIC must use a
low polarity trigger.
On zork/guybrush/skyrim the eSPI IRQs are currently working as follows:
* On power on/resume the eSPI controller drives IRQ 1 high.
* eSPI controller gets configured to not invert IRQ 1.
* OS configures IO-APIC IRQ 1 as Edge/High.
* EC writes to HIKDO (Keyboard Data Out) which causes the EC to set IRQ1
high.
* eSPI controller receives IRQ 1 high, doesn't invert it, and leaves IRQ
1 as high. This results in missing the first interrupt.
* When the x86 reads from HIKDO, the EC deasserts IRQ1. This causes the
eSPI controller to set IRQ1 to low. We are now primed to catch the
next edge high interrupt. This is generally not a problem since the
linux driver will probe the 8042 with interrupts off.
On S3/S0i3 resume since the eSPI controller comes out of reset driving
the IRQ lines high, we trigger a spurious IRQ since the IO-APIC is
configured to trigger on edge high. This results in the 8042 controller
getting incorrectly marked as a wake trigger.
By configuring the IO-APIC to use low polarity interrupts, we no longer
lose the first interrupt. This also means we can use a level interrupt
to match what the EC actually asserts.
We use the `Interrupt` keyword instead of the `IRQ` keyword in the ACPI
because the linux kernel will ignore the level/polarity parameters
for the `IRQ` keyword and default to `edge/high. `Interrupt` doesn't
have this problem.
The PIC is not currently configured anywhere and it defaults to an
edge/high trigger. We could add some code to configure the PICs trigger
register, but I don't think we need the functionality right now.
For zork and guybrush, this change is a no-op. eSPI is configured in
verstage which is located in RO, and we have already locked RO for
these devices. We will need to figure out how to properly set the
`vw_irq_polarity` for these devices.
BUG=b:218874489, b:160595155, b:184752352, b:157984427, b:238818104
TEST=On zork, guybrush and skyrim
$ suspend_stress_test --post_resume_command 'cat /sys/devices/platform/i8042/serio0/wakeup/wakeup35/active_count'
Verify keyboard works as expected and no interrupt storms are observed.
On morphius I verified keyboard and mouse work on windows as well.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4608a7684e34ebb389e0e55ceba7e7441939afe7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Modify sabrina's fw.cfg to point to the proper directory and use the
standard names, as released by AMD.
The name 'sabrina' was an alias used for the Mendocino product. The
public-facing builds have been using Cezanne blobs, renamed as Sabrina
or SBR, but can now take advantage of the appropriate blobs.
BUG=b:239072117
TEST=Build amd/chausie
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: Id646844e41980802be1e39dce96e5adaace4311d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66463
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Set the watchdog timeout to 0 in ite_kill_watchdog, as in some ITE
models it is set to non-zero by default, activating the watchdog despite
us setting the control register to 0.
Based on:
- "ITE IT8786E-I Preliminary Specification V0.4.1 (For D Version)"
- Linux it87_wdt driver
Change-Id: I1e78e2acc96e9dd0f283c5c674d3277d26cdee26
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Looking into pciexp_get_ext_cap_offset() it seems a little hackish
and prone to endless loops. Either it should limit the loop or bail
out when pci_read_config32() returns 0xffffffff, meaning "Unsupported
Requests".
This commit fixes an endless loop when the queried PCIe device is
downstream of a legacy PCI bus which doesn't support extended config
space, thus pci_read_config32() will return 0xffffffff, for example,
the combination below with CONFIG_PCIEXP_SUPPORT_RESIZABLE_BARS
enabled.
TEST=Build and boot to OS in ASUS P8C WS with the following
peripherals and CONFIG_PCIEXP_SUPPORT_RESIZABLE_BARS enabled:
00:1c.4 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series
Chipset Family PCI Express Root Port 5 [8086:1e18] (rev c4)
00:1c.4/00.0 SATA controller [0106]: Marvell Technology Group Ltd.
88SE9170 PCIe 2.0 x1 2-port SATA 6 Gb/s Controller [1b4b:9170]
(rev 13)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev a4)
00:1e.0/00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8111 PCI
Express-to-PCI Bridge [10b5:8111] (rev 21)
00:1e.0/03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc.
VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044]
(rev c0)
00:1e.0/00.0/00.0 Network controller [0280]: Qualcomm Atheros AR93xx
Wireless Network Adapter [168c:0030] (rev 01)
with 00:1c.4/00.0 being successfully tuned with pciexp_tune_dev(), and
00: 1e.0/00.0/00.0 not tuned as expected.
Change-Id: Ibb92548c47288b40e851fcc0a8a37937e8bdbf3c
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66439
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Recent changes to both coreboot and edk2 means that UefiPayloadPkg
seems to work on all hardware. It has been tested on:
* Intel Core 2nd, 3rd, 4th, 5th, 6th, 8th, 8th, 9th, 10th,
11th and 12th generation processors
* Intel Small Core BYT, BSW, APL, GLK and GLK-R processors
* AMD Stoney Ridge and Picasso
This includes the problematic Lenovo X230s. The most likely fixes are:
* Configuring the PCI Base and Length in edk2
* Fixes to the HostBridgeLib in edk2
* Adjustment to the SD/eMMC initialisation timeout
This means we can now remove the already deprecated option for
CorebootPayloadPkg and the legacy 8254 timer build option.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ice7b7576eb3d32ea46e5138266b7df3fbcdcf7ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The software used to read the document listing the VR settings turns
out to not be perfectly compatible. Indeed, it displays a value of 55A
for RPL-P 282 15W GT ICC MAX while the correct value actually is 40A.
After a thorough review using the software used to create the
document, it is the only value presenting a discrepancy.
BRANCH=firmware-brya-14505.B
BUG=b:239797178
TEST=build and boot
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Iee293c87a66f0cd32714766e3ad81eee1a411723
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.corp-partner.google.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Boot issue while using FW slot A has been root-caused to the usage of
same TLB to map HW Crypto engines and SPI flash. With upcoming PSP
release, this TLB usage conflict has been resolved. Hence enable CCP
DMA.
BUG=b:240175446
TEST=Build and boot to OS in Skyrim with PSP verstage using CCP DMA.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I2b12adb7e94e489bf07963a6f9a829cf4b36ad5c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
