- Disable devices in variant.c instead of adding probe statements to
devicetree because storage devices need to be enabled when fw_config is
unprovisioned, and devicetree does not currently support this. (it
disables all probed devices when fw_config is unprovisioned.).
- Removed `bootblock-y += variant.c` from Makefile.inc based on
CL:3841120.(The infrastructure for selecting an appropriate firmware
image to use the right descriptor is now ready so runtime descriptor
updates are no longer necessary.).
BUG=b:285477026
TEST=USE="project_joxer emerge-nissa coreboot"
Signed-off-by: Mark Hsieh <mark_hsieh@wistron.corp-partner.google.com>
Change-Id: I6920d88dfec86676ff6733146f748e06d4085c49
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75743
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Update the initial USB PHY tuning values that were a copy of the ones
from the Chausie mainboard to the values used in the Birman UEFI
firmware reference implementation. The USB3 PHY tuning values are still
the same while some of the USB2 PHY tuning values are different. The
last two USB2 PHYs that are used by the USB4 controllers have a
different parameter set compared to the other USB2 PHYs.
TEST=All USB ports on Birman function as expected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0ddfa2594d66b21582282ab8509c921a6e81a93f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75823
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add following config options.
1. TME_GENERATE_NEW_KEY_ON_WARM_BOOT
Program Intel TME to generate a new key for each warm boot. TME
always generates a new key on each cold boot. With this option
enabled TME generates a new key even in warm boot. Without this
option TME reuses the key for warm boot.
2. TME_EXCLUDE_CBMEM_ENCRYPTION
This option allows to exclude the CBMEM region from being encrypted
by Intel TME. When TME is enabled it encrypts whole DRAM. TME
provides option to carve out a region of physical memory to get
excluded from encryption. With this config enabled, CBMEM region
does not get encrypted by TME. If TME is not programmed to generate
a new key in warm boot, exclusion range does not need be programmed
due to the fact that TME uses same key in warm boot if
TME_GENERATE_NEW_KEY_ON_WARM_BOOT is not set. But if TME is
programmed to generate a new key in warm boot, contents of the CBMEM
get encrypted with a new key in each warm boot case hence, that leads
to loss of CBMEM data from previous warm boot. So enabling this
config allows CBMEM region to get excluded from being encrypted and
can be accessible irrespective of the type of the platform reset.
Bug=b:276120526
TEST=Able to build rex
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Change-Id: Id5008fee07b97faadc7dd585f445295425173782
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75625
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch disables the ACPI PM timer which is necessary for XTAL OSC
shutdown. Also, disabling ACPI PM timer switches off TCO.
BUG=b:274744845
TEST=Able to boot and verify S0ix is working even with EC reset and
cold boot scenarios.
w/o this cl:
> iotools mmio_read32 0xfe4018fc
0x0
w/ this cl:
> iotools mmio_read32 0xfe4018fc
0x2
Change-Id: Ibb6e145f67dba7270e0a322ef414bf1cb09c5eda
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
In commit e59f18bf29 ("drivers/i2c: Add PI7C9X2G608GP PCIe switch
driver (pi608gp)"), there were some suggestions after it's been already
merged.
This patch addresses the points regarding the number types - fix of the
printk format strings, inclusion of 'stdint.h' and marking the set of
allowed values as constant.
BUG=none
TEST=Build OK, no behavioral changes in the pi608gp driver, console logs
without changes.
Change-Id: I34c664f6a8a257b260facdbf9043825ff4a4c932
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75500
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This makes sure that the resource allocator won't use this address range
for anything else. In the systems I looked at, this was between the end
of the above 4GB memory and the beginning of the above 4GB PCI BAR MMIO
region, but better reserve it here so nothing else will get allocated
there if this expectation isn't met.
TEST=Reserved region is printed in the console logs:
update_constraints: PCI: 00:00.0 09 base fd00000000 limit fdffffffff mem (fixed)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5a8150873cb019ca1d903ed269e18d6f9fabb871
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch reduces the redundant config check to understand if an ISH FW
partition is available and to fetch the ISH FW version.
The goal is to fetch the ISH FW version if the ISH FW belongs to the CSE
firmware partition table.
Change-Id: I689a71377e7aea0fa3bc1835f355708c33c2caea
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75811
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames `SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION` config
to `SOC_INTEL_STORE_ISH_FW_VERSION` to ensure the usage of this config
is clear.
Any platform would like to fetch the currently running ISH firmware
version should select this configuration.
TEST=Able to build and boot google/marasov.
Change-Id: Ie503d6a5bf5bd0d3d561355b592e75b22c910bf5
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75767
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Boxy audio codec chip uses ALC5682I-VD, not ALC5682I-VS.
It needs to modify codec HID to "10EC5682" in coreboot to fix audio no
output sound issue.
BUG=b:286970886
BRANCH=dedede
TEST=confirm audio soundcard can be list by command "aplay -l"
Change-Id: Icd69a9d757ba817b586a703a17375682db684224
Signed-off-by: Kevin Yang <kevin3.yang@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Sometimes systems don't boot to the OS due to wrong ACPI tables.
Printing the tables in an ACPICA compatible format makes analysis of
ACPI tables easier.
The ACPICA format (acpidump, acpixtract) is the following:
"
FACS @ 0x0000000000000000
0000: 46 41 43 53 40 00 00 00 E8 24 00 00 00 00 00 00 FACS@....$......
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
"
To achieve analyze ACPI tables capture the coreboot log between
"Printing ACPI in ACPICA compatible table" and "Done printing ACPI in
ACPICA compatible table". Remove the prefix "[SPEW ] " and then call
'acpixtract -a dump' to extract all the tables. Then use 'iasl -d' on
the .dat files to decompile the tables.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7b5d879014563f7a2e1f70c45cf871ba72f142dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75677
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Time elapsed for a single board build with ccache typically measures
well below 10 seconds. Improve the measurements to milliseconds
resolution using bash EPOCHREALTIME (pseudo) environment variable.
Change-Id: Iaedc470bb45cf9bb6f14ff8b37cd6f7ae3818a08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
One specific Hynix LPDDR5x DRAM part requires an ABL workaround to
eliminate DRAM-related failures during a FAFT test, but due to the
use of generic/common SPDs, there is no way for the ABL to determine
the DRAM part # itself.
Consequently, we will have coreboot check the DRAM part #, and set/clear
a CMOS bit as appropriate, which the ABL will check in order to apply
(or not apply) the workaround.
The ABL already uses byte 0xD of the extended CMOS ports 72/73 for
memory context related toggles, so we will use a spare bit there.
BUG=b:270499009, b:281614369, b:286338775
BRANCH=skyrim
TEST=run FAFT bios tests on frostflow, markarth, and whiterun without
any failures.
Change-Id: Ibb6e145f6cdba7270e0a322ef414bf1cb09c5eaa
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75698
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
On nissa, the ISH is running closed source firmware, so the ChromeOS
security requirements specify it must be behind an IOMMU. Add
DmaProperty to the ISH _DSD on joxer.
BUG=b:285477026
TEST=Kernel marks ISH (PCI device 12.0) as untrusted, and changes the
IOMMU group type to "DMA". Also, device still goes to S0i3.
Before:
$ cat /sys/devices/pci0000\:00/0000\:00\:12.0/untrusted
0
$ ls /sys/kernel/iommu_groups/5/devices
0000:00:12.0
0000:00:12.7
$ cat /sys/kernel/iommu_groups/5/type
DMA-FQ
After:
$ cat /sys/devices/pci0000\:00/0000\:00\:12.0/untrusted
1
$ ls /sys/kernel/iommu_groups/5/devices
0000:00:12.0
0000:00:12.7
$ cat /sys/kernel/iommu_groups/5/type
DMA
Signed-off-by: Mark Hsieh <mark_hsieh@wistron.corp-partner.google.com>
Change-Id: I69b00f0281f4493db157783840d9cdcbb138017f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75758
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When fw_config is unprovisioned, devicetree will disable all probed
devices. However, boot-critical devices such as storage devices need to
be enabled.
As a temporary workaround while adding devicetree support for this,
remove the fw_config probe for storage devices so that all storage
devices are always enabled. On eMMC SKUs, UFS and ISH will be disabled
by the PCI scan anyway. On UFS SKUs, eMMC is not disabled by the PCI
scan, but keeping it enabled should have no functional impact, only a
possible power impact.
BUG=b:285477026
TEST=On joxer eMMC and UFS SKUs, boot to OS and
`suspend_stress_test -c 10`
Signed-off-by: Mark Hsieh <mark_hsieh@wistron.corp-partner.google.com>
Change-Id: I834bd81ce636a6f32d50434cbf07b1d572620492
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75757
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename get_smee_reserved_address_bits to get_sme_reserved_address_bits
since the feature is called secure memory encryption and the last 'e' in
SMEE bit in the SYSCFG MSR just stands for enable. The function will
return a valid number of reserved address bits no matter if this is
enabled or not, so drop the second 'e'.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3795f7a861e39cb6c8209fee10191f233cbcd308
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This is a complete rewrite of the UHCI root-hub driver, based on
the xHCI one. We are doing things by the book as far as possible.
One special case is uhci_rh_reset_port() which does the reset se-
quencing that usually the hardware would do.
This abandons some quirks of the old driver:
* Ports are not disabled/re-enabled for every attachment anymore.
* We solely rely on the Connect Status Change bit to track changes.
* Further status changes are now deferred to the next polling round.
The latter fixes endless loops in combination with commit 7faff543da
(libpayload: usb: Detach unused USB devices).
Change-Id: I5211728775eb94dfc23fa82ebf00fe5c99039709
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>