This reverts commit 1f81af52a4 ("mb/system76: Add custom backlight
levels for Intel GMA").
Defaulting to 40% can make the screen hard to read as System76's
firmware setup uses white text on a gray background.
Change-Id: I13ab3797319c4db6e800737a3f4e4344e3b588f3
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Port fix from Alder Lake to not set/reset IOM MCTP during
D3 cold entry or exit.
Ports 5008d34003 ("soc/intel/adl: Remove IOM Mctp command from TCSS
ASL"):
> Recently as part of s0ix hang issue, it was found that sending IOM
> MCTP command as part of TCSS D3 Cold enter-exit sequence created an
> issue.
> We discovered that due to change in hardware sequence, ADL should not
> set/reset IOM MCTP during D3 cold entry or exit. This patch removes
> the bit setting from ASL file to prevent hang in the system.
> This patch also removes obsolete Pcode mailbox communication which
> is no longer required for ADL.
> BUG=b:220796339
> BRANCH=firmware-brya-14505.B
> TEST=Check if hang issue is resolved with the CL and no other
> regression
> observed
> https://review.coreboot.org/c/coreboot/+/62861
Test: build/boot drobit to Win11. Verify TCSS XHCI power management
working and USB Root Hub doesn't Code 43 in device manager
Change-Id: I40a537fd2b0c821caf282f52aaff1874f54325f1
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80719
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
System sleep time (SLP_S0 signal asserted) is measured in ticks, for
Alder Lake soc in 122us (i.e. ~8197Hz) granularity/ticks.
BUG=b:301854636
TEST=/sys/devices/system/cpu/cpuidle/
low_power_idle_system_residency_us" will show system idle residency time
Change-Id: I449f7ed0d9ef891ae5266e8fd784a063a75e38eb
Signed-off-by: Marx Wang <marx.wang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Commit 2d48238618 ("soc/intel/alderlake: Set PchHdaSdiEnable for Alder
Lake") hooked up a new UPD, overriding the FSP default and causing HDA
init to break. Hook up the new UPD in the devicetree to restore HDA
functionality.
Also remove PchHdaAudioLinkHdaEnable per board romstage, as it set in
the devicetree.
Change-Id: I2533fa829fac4913308379788911339effa36d9f
Signed-off-by: Tim Crawford <tcrawford@system76.com>
On Raptor Lake based systems with TCSS, Linux will report ACPI
errors for \_SB.PCI0.TDM0 and \_SB.PCI0.TRP0. This is due to the
tcss.asl file only being included for one specific mainboard. This
change includes tcss.asl for all Raptor Lake models.
Change-Id: I2d8de7a77cfa91cd8bdbb9c3048e21d0a677d2fa
Signed-off-by: Dan Campbell <dan@compiledworks.com>
The FSP may fail to detect PCIe 4.0 devices in PCIe 3.0 slots on S3
resume. This issue has only been experienced on lemp12, and only with
Samsung drives, but implies it could happen on other systems or with
other drives as well.
Tested on lemp12 with Samsung 980 PRO and 990 PRO drives.
Change-Id: Ieacab03f6cb0943ed2a589e9bb7669d3d8fd45ae
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Retry calling the SMI 5 times in case the initial write to APM did not
cause SMM entry immediately.
Fixes occasional SMMSTORE initialization failure on Clevo NV4xPZ with
Intel i5-1240P processor. The issue was especially evident when all
logging in coreboot was disabled.
Based on SMMSTORE implementation in MrChromebox's fork of EDK2:
27854bc8c5
Change-Id: I8929af25c4f69873bbdd835fde5cb60fc324b6ab
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Some drives block the CPU from reaching C10 on suspend without the RTD3
config.
Fixes suspend with the following drives:
- Kingston KC3000 (SKC3000D/4096G)
- Kingston HyperX (SHPM2280P2H/240G)
- Solidigm P44 Pro (SSDPFKKW010X7)
The following drives continue to work:
- Samsung 970 Evo (MZVLB250HAHQ)
- WD Black SN770 (WDS250G3X0E)
- WD Green SN350 (WDS240G2G0C-00AJM0)
- WD Blue SN570 (WDS100T3B0C)
Change-Id: I205d78377fa2b0db8d37542cdb94ba86ded1d66e
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Tested-by: Levi Portenier <levi@system76.com>
Since these boards will use S0ix they need to leave CSME enabled for the
CPU to reach C10.
Change-Id: I70c908402c9964508bb9c439d48d24773f5a35ab
Signed-off-by: Tim Crawford <tcrawford@system76.com>
The newer batch of these boards do not de-assert VW PLTRST# on S3
resume, causes the units to not power on in the EC code. Switch them to
S0ix by default, but leave S3 available.
Change-Id: I95337c1391102db9e020e82bdd938659c1a4f905
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Add a driver for laptops with NVIDIA Optimus (hybrid) graphics. The
driver provides ACPI support for dynamically powering on and off the
GPU, NVIDIA Dynamic Boost support, and a function for enabling the GPU
power in romstage.
References:
- DG-09845-001: NVIDIA GN20/QN20 Hardware Design Guide
- DG-09954-001: NVIDIA GN20/QN20 Software Design Guide
Change-Id: I2dec7aa2c8db7994f78a7cc1220502676e248465
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Device 0:01.1 does not exist on ADL-P. I assume this works because the
bridged device has function 1.
Fixes the following error in Linux:
pcieport 0000:00:01.0: can't derive routing for PCI INT B
snd_hda_intel 0000:01:00.1: PCI INT B: no GSI - using ISA IRQ 10
Which in turn resolves the conflict with the PCH HDA device...again:
irq 10: nobody cared (try booting with the "irqpoll" option)
<snip>
[<00000000bf549647>] azx_interrupt [snd_hda_codec]
Disabling IRQ #10
Change-Id: I9d9a0003764a1e031be578c1f406b2a5d7512de7
Signed-off-by: Tim Crawford <tcrawford@system76.com>
The Bonobo has 2 AMPs: one for the speakers and one for the subwoofer.
Smart AMP data was collected using a logic analyzer connected to the IC
during system start on proprietary firmware. This data is then used to
generate a C file [1].
[1]: https://github.com/system76/smart-amp
Change-Id: I5389a9890563ebd3adb20096b6225f474bc006f9
Signed-off-by: Tim Crawford <tcrawford@system76.com>
The HX board, using PCH-S, use a discrete Thunderbolt device (Intel
Maple Ridge), as opposed to a built-in one like the boards using PCH-P.
Fixes Thunderbolt on RPL-HX boards using the Maple Ridge controller.
Change-Id: I53d18f3ec5a084431e1113782c791bcb42728350
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Add a new driver for discrete Thunderbolt controllers. This allows using
Maple Ridge devices on Raptor Point PCH.
Change-Id: Ib78ce43740956fa2c93b9ebddb0eeb319dcc0364
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
CB:52731 introduced support for reading SPD from the EEPROM via SMBus.
Replace the now unneeded workaround for DDR5 with filling in the correct
channels for DDR5.
Change-Id: I5a92199a7cd2718e9396f0dac8257df40e4f834c
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
DDR5 uses a Serial Presence Detect EEPROM with hub function
(SPD5 hub device) to store the spd data.
This CL adds support to read the spd5 hub device via smbus.
BUG=b:180458099
TEST=Boot adlrvp DDR5 board to kernel
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: Ic5e6c58f255bef86b68ce90a4f853bf4e7c7ccfe
The Infineon SLB 9672 on newer Clevo machines regularly fails TPM Resume
on S3 with the error `TPM_RC_VALUE`.
Per TPM2 spec, handle the failure by performing a TPM Restart.
> The startup behavior defined by this specification is different than
> TPM 1.2 with respect to Startup(STATE). A TPM 1.2 device will enter
> Failure Mode if no state is available when the TPM receives
> Startup(STATE). This is not the case in this specification. It is up
> to the CRTM to take corrective action if it the TPM returns
> TPM_RC_VALUE in response to Startup(STATE).
Fixes the following error from being repeatedly logged in Linux:
> kernel: tpm tpm0: A TPM error (256) occurred attempting get random
Ref: Trusted Platform Module Library, Part 1: Architecture, rev 1.59
Change-Id: I3388007d4448c93bd0dda591c8ca7d1a8dc5306b
Signed-off-by: Tim Crawford <tcrawford@system76.com>
It's not needed other than for booting w/SeaBIOS, where it is already
selected by default, and enabling it with edk2 payload prevents Linux/
Windows from fully entering S0ix.
TEST=build/boot purism/librem_cnl (Mini v2), verify Win11/Linux able
to enter and exit S0ix properly.
Change-Id: I974a82bedc4e06f48ce801f2bc0c29afbd80ffcf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80602
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
currently the HiFive Unmatched mainboard produces the following error:
```
util/crossgcc/xgcc/lib/gcc/riscv64-elf/13.2.0/rv64imafdc/lp64d/libgcc.a
(_clzsi2.o): in function `__clzdi2':
util/crossgcc/gcc-13.2.0/libgcc/libgcc2.c:690:(.text+0x1e): relocation
truncated to fit: R_RISCV_HI20 against symbol `__clz_tab' defined in
.rodata section in util/crossgcc/xgcc/lib/gcc/riscv64-elf/13.2.0/
rv64imafdc/lp64d/libgcc.a(_clz.o)
```
This is due to the fact that the libgcc.a library is compiled with the
medlow code model but the mainboards are compiled with the medany code
model.
Changing the code model of the GCC libraries to the medany code model
fixes the issue.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If5f07ce034686dd7fec160ea76838507c0ba7fa0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80139
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only call fill_pds() once to prevent leaking memory. Previously it was
called for every active stack on every socket.
Only call dump_pds() once to prevent spamming the console with the same
information.
Drop the return value since it's always returning success.
Change-Id: Ifa9609e9da086dc9731556014ea9b320b270d776
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The struct map_entry has two zero'd entries due to the ifdef
being used. Do not read those entries and do not print those
entries.
Fixes a NULL string being printed along as the vendor and device
ID of the PCI device.
Change-Id: Id87ced76af552c0d064538f8140d1b78724fb833
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80546
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since linux commit f9ba70535dc12d9eb57d466a2ecd749e16eca866
"[PATCH] Increase number of e820 entries hard limit from 32 to 128"
made in 2005 the number of e820 entries passed from the bootloader
is 128. Use the boot protocol version to check for support of
128 entries and use them if necessary.
Tested on IBM/SBP1:
Fixes booting a Linux payload when more than 32 entries are present
in the memory table, which can easily happen on a 4 socket platform.
Change-Id: Iec0a832fff091b6c3ae7050ef63e743a30618f25
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marvin Drees <marvin.drees@9elements.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Now that the baseboard uses chipset devicetree references, remove
all references whose value is identical to the chipset devicetree
default or the baseboard default, since they are pointless clutter.
TEST=build/boot purism/librem_cnl (Mini v2), verify output of lspci
and lsusb unchanged before and after patch.
Change-Id: I12498e7261dafd7ee59fe79926532399392d1b09
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80600
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the board uses chipset devicetree references, remove all
references whose value is identical to the chipset devicetree default,
since they are pointless clutter.
TEST=build/boot purism/librem_cnl (Mini v2), run lspci and verify output
unchanged before and after patch.
Change-Id: I6c656d227962548cebde61f1d82333837adbbf56
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80599
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch eliminates coreboot from loading microcode from RW CBFS
(when the RO descriptor is locked, which indicates a fixed RO image)
because the kernel can already patch the microcode on BSPs and APs
while booting to OS.
This may be a chance to lower the burden on the AP FW side because
patching microcode on in-field devices is subject to firmware updates,
which are rarely published and, if required, must go through the
firmware qualification testing procedure (which is costly, unlike
kernel updates for ucode updates).
1. The FIT loads the necessary microcode from the RO during reset.
2. Reloading microcode from RW CBFS impacts boot time
(~60ms, core-dependent).
3. The kernel can still load microcode updates.
ChromeOS devices leverage RO+RW-A/RW-B booting. The RO's microcode is
sufficient for initial boot, and the kernel can apply updates later.
BUG=none
TEST=Verified boot optimization; in-field devices skip RW-CBFS microcode
loading when RO is locked.
Change-Id: Ia859809970406fca3fa14e6fa8e766ab16d94c8a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Add an ACPI stub containing the TCPU device in proper scope, along with
the device status, on boards not using the DPTF driver, so that there
exists an ACPI device to be referenced from the PEPD LPI constraint
list.
Adding the stub fixes an AE_NOT_FOUND ACPI error under Linux for
_SB.PCI0.TCPU on boards with the SA thermal device enabled but which do
not use the Intel DPTF driver.
TEST=build/boot Linux,Win11 on purism/librem_cnl (Librem Mini v2).
Change-Id: I926d0461e5e0dfaf606102575c2be555a6bfb695
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When 'reset_gpio' and 'enable_gpio' properties are defined in
overridetree.cb, the kernel will power on the FPMCU. If the device was
previously enabled the kernel will reset it.
To avoid situation in which the FPMCU is powered on and reset later we
leave the FPMCU powered off in coreboot and started by the kernel. This
is exactly what other boards do (e.g. brya).
TEST=Boot the board (e.g. karis) and make sure the FPMCU was booted once
(e.g. examine FPMCU console logs)
Change-Id: I5df8d9385be2621c02ccee2d36511a4e80ab87d1
Signed-off-by: Patryk Duda <patrykd@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80457
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Setting the EC interrupt GPIO as an APIC is able to solve many
problems that we are currently seeing:
1. Routing through the APIC make the IRQ# associated with this pin
unavailable to claim for other devices in the kernel. This is causing
EC interrupts to not work.
2. Since EC interrupt are not working, we are not able to flash the
EC from the DUT.
3. Also, the GPI_INT configuration does not allow us to set the
polarity of the GPIO, which means that it is by default set as active
high. As a result, we are seeing an excessive number of host command
interrupts to the EC. This disappears when we change the
configuration to APIC and set the polarity as INVERT.
BUG=b:319129926,b:324707182
BRANCH=None
TEST=1. After boot up, check if ec_cros_lpcs driver was successfully
registered. Look for the following string:
"cros_ec_lpcs GOOG0004:00: Chrome EC device registered"
2. Make sure can flash the EC image from the DUT
3. Make sure EC console is not getting continuous stream of host
commands.
Change-Id: I74bff88d2ddbaf1f4b085c31d582bd66e18c438a
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80467
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ashish Kumar Mishra <ashish.k.mishra@intel.corp-partner.google.com>
Configure PMC mux in devicetree. This allows PD controllers to be
used for both video and power delivery.
Tested on StarBook Mk VI with Ubuntu Lunar, by checking a USB-C PD
display can supply power and display video output.
Change-Id: I580b148b036e62fbcab50d1ca2ab1ed021cfed6b
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Configure PMC mux in devicetree. This allows PD controllers to be
used for both video and power delivery.
Tested on StarBook Mk VI with Ubuntu Lunar, by checking a USB-C PD
display can supply power and display video output.
Change-Id: I9e49612d7f165a9c9604093535f7b141a4c7048c
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79426
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 977b8e83cb ("mb/emulation/qemu-aarch64: Add MMU support") adds
MMU support for ARM64 QEMU VMs, but registers a limited 1GiB region for
the DRAM, with a note that ramstage should update it.
However on recent versions of QEMU "virt" VMs, accessing RAM outside
this registered region results in an exception even if the address is
backed by actual RAM. This interferes with RAM detection which catches
these exceptions, effectively limiting us to detecting a maximum 1GiB of
RAM even if more is available.
Register the entire RAM space to MMU instead of just the 1GiB, so that
probing RAM addresses can correctly detect how much RAM we have.
Change-Id: I3afbd27b91ab37304a29a62506f965ac3cfb1c06
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This tool doesn't have a makefile, when trying to compile it manually
with the given instructions it even fails to compile after fixing the
paths in the given command, and it references the non-existing
PCI_BUS_SEGN_BITS Kconfig symbol, so just drop this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8ca75db281a215bf3f194ab72a107f666dc0694e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79934
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Normally this would be done by the Intel GMA driver, but we can't have
two copies of the _DOD method, so generate the LCD backlight controls
here to allow use of this driver instead of the default GMA panel
definition.
TEST=build/boot Win11 on google/byra (redrix), ensure ACPI brightness
controls functional.
Change-Id: Ic8fbaf7550405f8c6f36012c8efadb8c36b968c2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80061
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is a modification for the x230 which uses the 2nd DP from the
dock as the integrated panel's connection, which allows using a custom
eDP panel instead of the stock LVDS display.
There are several adapter boards present on the market and all of them
use the same method of enabling the custom eDP panel.
To make this work with coreboot, the internal LVDS connector should be
disabled in libgfxinit. Additionally, VBT has been modified to keep
brightness controls functional on the adapter boards that use LVDS for
the job.
The modifications done to the VBT are:
- Remove the LVDS port entry.
- Move the DP-3 (which is the 2nd DP on the dock) entry to the first
position on the list.
- Set the DP-3 as internally connected.
This has been reported to work with the following panels:
- LP125WF2-SPB4 (1920*1080, 12.5")
- LQ125T1JW02 (2560*1440, 12.5")
- LQ133M1JW21 (1920*1080, 13.3")
- LTN133HL10-201 (1920*1080, 13.3")
- B133HAN04.6 (1920*1080, 13.3")
- B133QAN02.0 (2560*1600, 13.3")
Other eDP panels not on this list should work as well.
Change-Id: I0355d39a61956792e69bccd5274cfc2749d72bf0
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Signed-off-by: Alexei Sorokin <sor.alexei@meowr.ru>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/28950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The HDA specification defines bits 11:8 of the Configuration Default
register as a miscellaneous field for other jack information. Only bit 8
has a standard meaning, and indicates that the jack does not have
presence detect capability. Add an enum for use in the AZALIA_PIN_DESC
macro to indicate this field. Note that many vendor firmwares set bits
11:9 to non zero values despite them being reserved in the
specification, and their meaning in these cases is not well known.
Change-Id: I70cbfca8541828a1e0c7280887060c04e4c71721
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add an enum for the Display Type, which if set, can be used to generate
the Device ID value dynamically when the addr field is not set. This
will allow devicetree entries to specify the display type instead of
a hex value for the address which requires referencing the ACPI spec
to decode.
For an internal panel connected to the first port on the graphics chip,
currently an addr value of 0x80010400 is specified. Replacing the
'addr' field with the 'type' field and setting it to 'panel' will
generate the same DID value.
Change-Id: Id0294a14606b410a13fa22eeb240df9e409a7ca3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Jinlon disables the eps device if no privacy screen is present, so add
a second generic gfx device 'no_eps' to handle that case, so that ACPI
backlight controls are generated either way. Add logic to ensure only
one of the two devices is active.
TEST=build/boot Win11 on google/hatch (jinlon), ensure LCD backlight
controls present and functional on device both with and without a
privacy screen.
Change-Id: Icf20de97d26c8be76c84e87d5dc6ed1a4b6dbfbc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80178
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Puff-based Chromeboxes use a LSPCON for HDMI 2.0 output, but no driver
exists or is needed for Windows. Use the devicetree hidden keyword to
set the ACPI status to hidden for these devices, to prevent unknown
devices from being listed in Windows Device Manager.
TEST=build/boot Win11 on google/wyvern, verify no unknown devices in
Windows Device Manager for either LSPCON device.
Change-Id: Ib646e01a337b8d7baf20a886c49a8cb64d6408f3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78040
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Improves code maintainability and potentially reduces redundancy by
using the IA common implementation.
Additionally, drop the unused macros from SoC local.
TEST=Build and boot successful on google/marasov.
Change-Id: I290fea99f04cfc9f18e5f1435ed07de42995869f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80403
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit streamlines code and strengthens common code robustness
by moving the following SoC-layer functions to the common layer:
- sa_get_mmcfg_size: Retrieves the MMIO (Memory-Mapped I/O)
configuration space size by reading offset
0x60 of the PCI Host Bridge (D0:F0).
- sa_get_dsm_size: Calculates the size of the DSM (Device Stolen
Memory) by reading offset 0x50 of the PCI
Host Bridge (D0:F0) to determine pre-allocated
memory for the IGD (Integrated Graphics Device).
- sa_get_gsm_size: Calculates the size of the GSM (Graphics Stolen
Memory) by reading offset 0x52 of the PCI Host
Bridge (D0:F0).
- sa_get_dpr_size: Determines the size of the DMA Protection
Range (DPR) by reading offset 0x5C of the PCI
Host Bridge (D0:F0).
TEST= Build and boot successful on google/screebo.
Change-Id: Ic00e001563ec6f0d737a445964c716b45db43327
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Goal is to use existing defines for all pins to make the file
self-documenting, but it would make lines too long, so I'll just
start with the NC pins.
TEST=Timeless binary did not change.
Change-Id: I6da02d7bc4c87cc8477d687b238e6e6c9aec62cd
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79733
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This function turns off gpp_clk for the devices which are disabled, and
adds the code to fix up the clock configuration depending on dxio
descriptors. Also this brings picasso in line with cezanne, mendocino
and phoenix. This also prepares picasso to use the common function
gpp_clk_setup_common.
Change-Id: Ice2e3a5a78359da9a438434c7d4aa1eca878d396
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80413
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The name LEDLOGO comes from schematics. It's the red indicator, embedded
in the dot of the 'i' of the ThinkPad logo on laptop's lid.
In vendor firmware, this led starts fading in-and-out, or, in other
words, pulsing, when laptop is put to S3. It helps to determine whether
the laptop is in S3 just by taking a look at the logo.
As of now, coreboot doesn't do anything with this particular indicator,
it's always in enabled (on) state, which is not very convenient.
This patch fixes it.
Tested on T440p.
Change-Id: I85fb69c8c1bed8635a1b31e9b8385c7036bb46dd
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80437
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GMP and IASL don't compile with the default compiler and linker flags:
- GMP's check for the MacOS architecture hard coded x86_64 but it also
needs to know about arm64.
- iasl does some trickery on pointer alignment to save space(?), so we
need to tell clang about it.
Change-Id: If4cca9d3e55051a6121d992e5320bee1df17af9f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80435
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Leverages common SA header definitions for Host Bridge registers.
Renames DSM_BASE_ADDR_REG to BDSM and DPR_REG to DPR for brevity.
Additionally, made some minor code alignment corrections while
adding newer macros in the header file.
TEST= Build and boot successful on google/screebo.
Change-Id: I476f213d75a0978336b3749a5ba1499107eb2238
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80361
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
It simply adds a comment to indicate to the reader that the
RISCV_PAYLOAD_MODE_S parameter causes OpenSBI to switch to Supervisor
mode. Otherwise it could be interpreted that coreboot switches to
Supervisor mode before starting OpenSBI (which is not the case)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ib62be0c2ff59361200df4c65f9aca5f7456a0ada
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79949
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Hug <philipp@hug.cx>
gpp_clk_setup code in most AMD SoC is similar and it can moved to common
code. The only thing which is SoC dependent in this function is the SoC
config, hence keep it in SoC code and move everything else in new
gpp_clk_setup_common function which is in soc/amd/common. Picasso and
Glinda don't have pcie_gpp_dxio_update_clk_req_config fixup function so
they are addressed in later patches.
Change-Id: I7d7da4bfe079f07e31212247dbf3acd14daa6447
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80285
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TCHSCR_RST_L signal was originally being configured to 1 in gpio.c but
this was causing some leakage. Configuring it to 0 initially in
romstage fixes this. Also, make sure that EN_PP3300_TCHSCR is
initialized in romstage as well.
BUG=b:322249892
BRANCH=None
TEST=Make brox boots and touchscreen is still working
Change-Id: I5bf1901a3a40a38237b950abcb758f96aebcc1cf
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80300
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is an existing issue for nissa where wake up from RTC wake is not working during suspend_stress_test.
The phenomenon of the issue is that after pulling out the stylus, can see an interrupt storm occurs, checking through:
"cat /proc/interrupts | grep acpi".
When the counter of interrupt is greater than a certain value, "Disabling IRQ #9" will occur, so RTC wake is not working.
Reference: https://review.coreboot.org/c/coreboot/+/65086
This patch skips the locking for GPP_F15 to allow kernel to
configure it later. The interrupt storm of acpi disappears.
BUG=b:321348117
TEST=1. cat /proc/interrupts | grep acpi
there isn't interrupt storm of acpi when pulling out stylus.
2. The stylus tools panel will pop up when pulling out it.
3. Inserts stylus can wakeup DUT after powerd_dbus_suspend.
4. Passed:
suspend_stress_test -c 2500 --suspend_min=15 --suspend_max=20
Change-Id: Ie143c43e0555d17d8a290f17637b537fba806144
Signed-off-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80316
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While introducing driver support for QEMU Cirrus display device, commit
7905f9254e ("qemu: cirrus native video init") also explicitly adds
VGA I/O functions into ramstage class when Bochs display driver support
is enabled.
Later, commit db7d04d1b7 ("qemu: Support textmode gfx init.") makes
the related config option select CONFIG_VGA, which also adds the same
file into ramstage class (among other things) in another Makefile.
Doing this twice is unnecessary. Remove the addition based on the Bochs
display driver's config option. Adding it based on CONFIG_VGA is
clearer, and future patches will try to support a Bochs display without
legacy VGA support on non-x86 architectures.
Change-Id: Ib31344e242689682d74d8a83c97b6e8027641926
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80374
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Ensure that the SerialIoDevMode config and common_soc_config registers
for each variant are programmed consistently with the devices'
enabled status in that variant's overridetree; remove and disable
extraneous devices as appropriate.
TEST=build/boot several puff variants, verify all components working
as expected, nothing missing from cbmem, lspci, etc.
Change-Id: Ib9d0cf48e405be7c00c553646651fc6f28c4e3f0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80164
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the puff baseboard uses chipset devicetree references, remove
all references whose value is identical to the chipset devicetree
default or the baseboard default, since they are pointless clutter.
TEST=tested with rest of patch train
Change-Id: Iada32111367fdc964d6126ee43e261c1feb123cf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80163
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
In commit 30f36c35e7 ("soc/amd: rework DRAM and fixed resource
reporting") the reporting of the DRAM resources was moved from the
northbridge PCI device to the domain device. amd_pci_domain_fill_ssdt
didn't skip those DRAM resources when generation the resource producer
ranges which made Windows 10 very unhappy when it tried to evaluating
the ACPI tables causing it to reboot in a loop. To fix this, add a check
to also skip the resources that have the IORESOURCE_STORED flag set when
generating the resource producer ranges for the PCI root.
TEST=Windows 10 now successfully boots and reboots again on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b6d3fd8c7f89aa4364de7963d745aef8d6b6f42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80407
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
It seems that reducing the return type of timer_hz() to uint32_t in
CB:78888 was a bad idea... some Intel platforms actually use their raw
CPU clock for the timestamp counter which can be higher than 4GHz. This
patch reverts it back to uint64_t.
Also remove the redundant assertion in timer/generic.c since timer_us()
itself already does that check.
Cq-Depend: chromium:5274555
Change-Id: I471c7de7a28aec5bb965b23525ed579481ac8361
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Yidi Lin <yidilin@google.com>
This patch selects the DRIVERS_MTK_WIFI and USE_MTCL configs for google/yaviks as
the first platform that provides a country list to the Linux kernel via an
ACPI function (MTCL) in SSDT for MediaTek WiFi chipsets that are capable of
operating on the 6GHz band.
BUG=b:295544553
TEST=Build on similar model (PUJJO) that I have access to and verify the
flag and feature work as intended.
TEST=Add wifi_mtcls.bin blob to cbfs
TEST=Build coreboot for pujjo `emerge-nissa coreboot chromeos-bootimage`
TEST=Verify that MTCL defined in the file is present:
TEST=`acpidump -b`
TEST=`iasl ssdt.dat`
TEST=`less ssdt.dsl`
TEST=Search for MTCL
Change-Id: Iec54fc582d68b443665fceda47187c28f1a9216c
Signed-off-by: David Ruth <druth@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80305
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subratabanik@google.com>
It seems that we have some applications where we need to calculate a GCD
in 64 bits. Now, we could instantiate the algorithm multiple times for
different bit width combinations to be able to use the most efficient
one for each problem... but considering that the function usually only
gets called once per callsite per stage, and that software emulation of
64-bit division on 32-bit systems doesn't take *that* long either, we
would probably usually be paying more time loading the second instance
of the function than we save with faster divisions. So let's just make
things easy and always do it in 64-bit and then nobody has to spend time
thinking on which version to call.
Change-Id: I028361444c4048a0d76ba4f80c7334a9d9983c87
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80319
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Current pagetable implementation allows memory access up to 4GiB using
2MiB pages. If user wants to access more than 4GiB with a 2MiB page it
will require more pagetable entries. By using a 1GiB page table, users
can access more than 4GiB of memory while reducing the number of
pagetable entries. This patch enables memory access up to 512GiB through
1GiB pages by selecting USE_1G_PAGES_TLB in Kconfig.
TEST: Verified in 64bit mode boot and access above 4GiB
Change-Id: Id569ae5b50abf5b72e4db33b5e4cd802399e76ec
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80088
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In case where PAD_CFG_GPI_INT() is initialized with a pin value
lower to PAD_CFG_GPI_IRQ_WAKE() for same GPIO community
the set_ioapic_used() is only called for the PAD_CFG_GPI_IRQ_WAKE() pin.
Due to this the IRQ associated with PAD_CFG_GPI_INT() is found free by
find_free_unique_irq() during IRQ assignment and assigned to other pins
which causes IRQ conflicts
BUG=b:322984217
BRANCH=None
TEST=Boot test on brox, check if correct IRQ assigned to EC
Change-Id: I8c3d557e888b8d0ceac203f49b702910fba26d6d
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80334
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In case printk does not work the current exception handler will print a
simple "!" to notify the developer that coreboot is actually there but
something went wrong.
The "!" can be quite confusing when it actually happens that printk does
not work. Since "!" doesn't really say much (if you don't know the
exception arm64 code) the developer (like me) can easily assume that
something went wrong while configuring clocks or baud rate of UART,
since the output seemingly does not seem to make sense.
This adds a little bit more output to assure the developer that what was
printed was actually intended to be printed. Therefore it prints
"EXCEPT" which assures the developer that this was intended output.
It also adds a comment above so that developer can more easily grep
for this message.
It has intentionally not been written as:
```
const char *msg = "\r\n!EXCPT!";
while (*msg)
__uart_tx_byte(*msg++);
```
because in this case the compiler will generate code that will place
`msg` somewhere in bootblock and the code will try to access this using
a memory address. In rare cases (if you link bootblock at the wrong
address) this memory address can be wrong and coreboot will not print
the message. Using individual calls to `__uart_tx_byte` ensures that the
compiler will generate code which directly puts the character bytes into
the argument register without referencing a variable in bootblock.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2f858730469fff3cae120fd7c32fec53b3d309ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80184
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the unneeded data_fabric_set_mmio_np function and the corresponding
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig symbol. In systems
with only one FCH, its MMIO region will be subtractively decoded and
there's no need to add a non-posted data fabric MMIO region after the
FSP/openSIL has already configured the data fabric decode windows. In
systems with more than one FCH, openSIL will already take care of
initializing everything for the additional FCH, so we also won't need to
do anything in that case. Since dropping this function also removes both
data_fabric_print_mmio_conf calls before and after adding the unneeded
non-posted MMIO region, replace the data_fabric_set_mmio_np call with a
data_fabric_print_mmio_conf call to still print the data fabric MMIO
decode regions set up by the FSP/openSIL.
TEST=Mandolin still boots successfully
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I474b6e066060abb3fe5b78505521c7782cc192ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Updating from commit id 23d6774ab:
2024-01-16 09:47:43 +0100 - (Merge "feat(qemu-sbsa): mpidr needs to be present" into integration)
to commit id 17bef2248:
2024-02-05 23:33:50 +0100 - (Merge "feat(fvp): delegate FFH RAS handling to SP" into integration)
This brings in 142 new commits.
Change-Id: If89a3f0d32180ff7ae0a6b447687b9749dfab2ea
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80352
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Back in the days of the APIC bus, the IOAPIC IDs mustn't overlap with
the LAPIC IDs (0 to CONFIG_MAX_CPUS - 1), but since the IOAPIC and LAPIC
nowadays talk to each other via the system bus, an IOAPIC ID of 0 is
valid. When set_ioapic_id gets called with an IOAPIC ID of 0, it skipped
writing the IOAPIC ID to the corresponding IOAPIC register, so the code
was relying of the register having the expected default value of the
IOAPIC IO 0 for things to work as expected. The case of the IOAPIC ID
being 0 is the most common case in coreboot, since that's what
register_new_ioapic_gsi0 will end up doing. Fix this issue by not making
the io_apic_write call conditional on ioapic_id being non-zero. The only
southbridge that doesn't call register_new_ioapic_gsi0, calls
set_ioapic_id with the IOAPIC ID 2 for which this won't cause any
changes in behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic8538f82a6b10f16eeb228669db197dc8e326ffd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Remove hardcoded B:D:F numbers for the first socket and pass the PCI
addresses to be locked within SMM by using the smm_pci_resource_store.
This allows to lock down SMM on all sockets without knowing the actual
bus topology or PCI segment group at compile time where the UBOX devices
reside on.
Tested: SMM is locked on all 4 sockets instead of just one.
Change-Id: Ica694911384005681662d3d7bed354a60bf08911
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80247
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MTCL function provides a country list to the Linux kernel via an
ACPI function in SSDT for MediaTek WiFi chipsets that are capable of
operating on the 6GHz band. The country list is used to selectively
disable 6GHz and 5.9GHz operation based on the country the device is
operating in.
The function needs to read a binary file and send it as a package via
the MTCL method in SSDT for PCIe WiFi with MediaTek chipsets.
Change Summary:
* Add src/drivers/wifi/generic/mtcl.c to abstract functionaltity related
to MTCL
* Add write_mtcl_aml function to convert the byte data into the format
expected by the MTCL functionality in the Linux kernel.
* Add validate_mtcl function to validate that the byte data read in
from a file is in the expected format.
* Add write_mtcl_function function to read a binary file called
"wifi_mtcl".bin" from cbfs, then call validate_mtcl to verify that
it is in an expected format, and if so write the aml via acpigen
* Add config flag DRIVERS_MTK_WIFI to src/drivers/wifi/generic in order
to include MediaTek WiFi specific functionality
* Add config flag USE_MTCL which depends on DRIVERS_MTK_WIFI and
enables including the specific ACPI function defined in SSDT
* Add config flag CONFIG_MTCL_CBFS_FILEPATH which depends on
DRIVERS_MTK_WIFI which enables configuring the file to add as
"wifi_mtcl.bin"
* Add a call to write_mtcl_function to src/drivers/wifi/generic/acpi.c
to include the MTCL function in SSDT for MTK WiFi devices when
USE_MTCL is enabled.
* Add MediaTek VID to src/include/device/pci_ids.h.
BUG=b:295544553
TEST=Add Kconfig entry USE_MTCL for pujjo
TEST=Add wifi_mtcl_defaults.bin blob to cbfs
TEST=Build coreboot for pujjo `emerge-nissa coreboot chromeos-bootimage`
TEST=Verify that MTCL defined in the file is present:
TEST=`acpidump -b`
TEST=`iasl ssdt.dat`
TEST=`less ssdt.dsl`
TEST=Search for MTCL
Signed-off-by: David Ruth <druth@chromium.org>
Change-Id: I9b5e7312a44e114270e664b983626faa6cfee350
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80170
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Currently, SOC_INTEL_COMMON_BLOCK_TCSS will set MUX to disabled. The two
related options to re-configure it for either USB devices or displays,
are currently only supported by the ChromeEC. As such, any device
without the ChromeEC will boot with attached USB-C devices in a
non-functional state.
Add TCSS_HAS_USBC_OPS to make this feature configurable, and set the
default to enabled if the board features the ChromeEC.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ia848668ae9af4637fc7cffec9eb694f29d7deba9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79882
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Update the I2C configuration to match the usage such that only required
I2C controllers are enabled.
BUG=b:319390850
TEST=Build Brox BIOS image and boot to OS. Ensure that only the required
I2C controllers are enabled.
Change-Id: I9f24beb9ef587163362cc6ded88efb05be1329b9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80303
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch switches the cbmem utility from its own IP checksum
implementation to the commonlib version (which is good because the old
one had a couple of bugs: doesn't work on odd sizes and may overflow
its carry accumulator with input larger than 64K).
Change-Id: I0bef2c85c37ddd3438b7ac6389e9daa3e4955b31
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80256
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a bit of optimized assembly code to the ipchksum()
algorithm for x86 targets in order to take advantage of larger load
sizes and the add-with-carry instruction. The same assembly (with one
minor manual tweak) works for both 32 and 64 bit mode (with most of the
work being done by GCC which automatically inserts `rax` or `eax` in the
inline assembly depending on the build target).
Change-Id: I484620dc14679ff5ca02b2ced2f84650730a6efc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80255
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a bit of optimized assembly code to the ipchksum()
algorithm for arm64 targets in order to take advantage of larger load
sizes and the add-with-carry instruction. This improves execution speed
on a Cortex-A75 by more than 20x.
Change-Id: I9c7bbc9d7a1cd083ced62fe9222592243a796077
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80254
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Yidi Lin <yidilin@google.com>
This patch adds a few more test cases for the IP checksum algorithm to
catch more possible corner cases (large data with more than 64K carries,
unaligned data, checksum addition with offset, etc.).
Change-Id: I39b4d3f1bb833894985649872329eec88a02a22c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
This patch moves the IP checksum algorithm into commonlib to prepare for
it being shared with libpayload. The current implementation is ancient
and pretty hard to read (and does some unnecessary questionable things
like the type-punning stuff which leads to suboptimal code generation),
so this reimplements it from scratch (that also helps with the
licensing).
This algorithm is prepared to take in a pre-calculated "wide" checksum
in a machine-register-sized data type which is then narrowed down to 16
bits (see RFC 1071 for why that's valid). This isn't used yet (and the
code will get optimized out), but will be used later in this patch
series for architecture-specific optimization.
Change-Id: Ic04c714c00439a17fc04a8a6e730cc2aa19b8e68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80251
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Make the initialization of the IOAPIC(s) in the PCI root(s) common
across all AMD family 17h+ SoCs. For this the more general
implementation from the Genoa code that supports multiple PC roots is
moved to the common AMD code. All other family 17h+ SoCs are then
adapted to use the common code. For those non-Genoa SoCs, the
initialization of this second IOAPIC is moved from the northbridge
device to the domain device above to match Genoa.
Test=Both the FCH IOAPIC and the PCIe root IOAPIC are still initialized
on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7c0ec6ac2f11cb11e46248cceec96c1fd2a49c16
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80286
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce BOARD_AMD_BIRMAN_PHOENIX_OPENSIL which selects the openSIL
based Phoenix SoC code. Since the Phoenix chip.c is different due to
some FSP-specific data structures in there that are guarded in the
openSIL case, a separate devicetree for the openSIL case is added.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I248102e92818b2d395d561a4bf2627f80906b2f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The configuration of the PCIe clock generators in the FCH was moved from
the FSP to coreboot, since all registers are documented. This
initialization is however tightly integrated in the rest of the PCIe
init code inside the reference code. In the FSP case, this code was
manually removed. openSIL will do that part of the initialization so
that there's no coreboot-specific change needed in openSIL. This will
also avoid the problems caused by mismatching configurations done by the
coreboot code and the PCIe init part of the reference code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6d64285a301ade6860c07e62dcb1a718e7a96644
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
In the FSP case we get this info via a HOB. It's currently unclear if
we'll get a data structure for this from openSIL or if we'll end up
being able to just read the configuration fro the hardware, so add a
get_pci_routing_table stub for now to be able to build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5003e287d6a3a9320922beaffff8a3a846531e14
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add the SOC_AMD_PHOENIX_OPENSIL Kconfig option to be able to build the
Phoenix code using openSIL instead of FSP for initializing the hardware.
Since there's currently no publicly available openSIL code for Phoenix,
SOC_AMD_OPENSIL_STUB is selected to have the stubs added to the build
instead of the actual openSIL code. The code added by selecting
SOC_AMD_COMMON_BLOCK_ACPI_CPPC relies on getting the information it
needs via a HOB, so for only select that option in the FSP case for now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If597ff3dc824ce832399d3efde32352b36354b21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add a stub implementation of the openSIL interface between coreboot and
vendorcode. This can be used to add most of the coreboot-side support
for a SoC using openSIL without the actual opnSIL code already being
publicly available. Once the corresponding openSIL code is available,
the SoC can then switch over to using the actual openSIL implementation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9284b0cbacba6eae7e2e7e69bc687f015076c2b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80292
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Provide 3 separate functions for each openSIL time point instead of one,
so that we don't need the xSIM-api header file to be included in
opensil.h to decouple the coreboot code more form the openSIL code. This
will allow to create an openSIL stub implementation to already get most
of the coreboot-side SoC code in place before the openSIL source code is
done and released.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I969bc0862560b7254c48f04e9a03387417f328bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
When a device with no resource is passed it will keep overwriting
the current slot. Remove the conditional and allow a PCI device
to not have any resources.
This is particular useful for the next commits that makes use
of the PCI resource store to pass UBOX devices to SMM that allow
to lock-down SMM from within an SMI handler. Those devices do
not have any resources and cannot be hardcoded in SMM as their
PCI segment group and bus number varies depending on socket
count, CPU discovery and configuration.
Change-Id: I1a1b5944c97da5be6b9794c653b5159683f492e5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80246
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Commit d252776668 ("tree: Replace And(a,b) with ASL 2.0 syntax")
replaced two instances of `And(var, mask) == 0` with `var & mask == 0`.
This expression needs parentheses - `(var & mask) == 0`.
Without parentheses, it is always false, since the masks are nonzero
(`var & (mask == 0)`; `var & 0`; `0`).
This caused brightness changes on Intel GMA to take longer than
normal since the status was never checked. The brightness would
change immediately, but another brightness change could not occur until
the first change timed out.
This was most noticeable in KDE, which waits for the brightness change
to complete before accepting another brightness up/down keypress.
Tapping brightness up/down repeatedly would take much longer to reach
max/min brightness due to many presses being ignored.
It is noticeable in GNOME as well but less obvious. Tapping brightness
up/down repeatedly would handle all keypresses, but the display's
actual brightness would lag behind and skip some intermediate steps.
I tested both Librem 13v2 and Librem 14, as far as I know this would
apply to all systems configuring brightness with Intel GMA.
Test: Verify brightness keys respond quickly again on Librem 13v2 / 14.
Change-Id: I57895e8c654c83368b452d7adfe1856c0a0341fb
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80260
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch adds support for the new command-line option `-E` to
the ifdtool, which enables users (primarily factory users) to
protect GPR0.
Additionally, this patch refactors some code while adding support for
enabling GPR0 protection.
For more information on the scope of GPR0 (General Protection Range 0),
please refer to the Intel Meteor Lake-U Type 4 Client Platform SPI
Programming Guide, Document Number 768150.
BUG=b:270275115
TEST=Able to test GPR0 protection on google/rex and google/yahiko.
> ifdtool -p mtl -E image.bin -O image.bin_lock
...
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
...
GPR0 protection is now enabled
Change-Id: I27c533ae4109c79299f4e7ff75e750d7cc64280f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
On Brox, HDA Codec used is ALC256. Add verb table for the same. Also,
add the related device tree changes for HDA related registers.
Realtek High Definition Audio Configuration-
Version : 5.0.3.1
BUG=b:317398558
BRANCH=None
TEST=verified HDA on Brox.
HDA Sound cards detected. Headphone working verified.
Device listed under sysfs as below:
cat /sys/bus/hdaudio/devices/ehdaudio0D0/chip_name
ID 256
cat /sys/bus/hdaudio/devices/ehdaudio0D0/vendor_name
Realtek
Change-Id: I1edd5aee053debe39b34048266703031c088cd00
Signed-off-by: Poornima Tom <poornima.tom@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79723
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the SoC-specific memory map is reported on the domain device
instead of the northbridge device, factor out the
read_soc_memmap_resources function from root_complex.c to new memmap.c
file. For now each SoC still has its own memmap.c file, but the plan is
to eventually have a common implementation that works for all AMD family
17h+ SoCs. For that I'll still need to look closer into the differences
between the FSP and the openSIL integration though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifd7659e9a55de9df24118b6d6c885a21dc6f14a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since reporting the PCI ECAM MMCONF MMIO region and the IO ports for the
legacy PCI config space access is needed on all AMD SoCs, implement a
common add_pci_cfg_resources function that reports both and gets called
from amd_pci_domain_read_resources and don't report those in the SoC-
specific code any more. The only functional change is that on Genoa now
the IO ports used for the legacy PCI config space access get reserved.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibbcc2aea4f25b6dc68fdf7f360e5a4ce53f6d850
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
To make add_opensil_memmap match the other function that are directly or
indirectly called by amd_pci_domain_read_resources, pass the resource
index as a pointer instead of passing it by value and then returning the
new resource index.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6a17e488a01cc52b2dab5dd3e3d58bdf3acb554d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Introduce read_soc_memmap_resources which gets called by
amd_pci_domain_read_resources for the first domain of the SoC to report
the DRAM and PCI config space access resources to the allocator. For
Genoa this allows to use amd_pci_domain_read_resources as read_resources
in the genoa_pci_domain_ops instead of needing to wrap that call to be
able to call add_opensil_memmap for the first domain. For the other
family 17h+ SoCs the moves the reporting of the DRAM resources and the
PCI config space access resources from the northbridge device to the
domain device.
TEST=Resources still get reported on Mandolin, but now under the domain
instead of the northbridge PCI device
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib19fd94e06fa3a1d95ade7fafe22db013045a942
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80268
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Previously the code checked if the first downstream bus of the domain
was bus 0 in segment group 0 to only run certain code for the first
domain. Instead check if the domain number is 0 which should make the
code a bit easier to understand.
TEST=add_opensil_memmap still gets called exactly once on Onyx
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id8cc0078843e5e0361a53ba897cde508cee16aad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of manually crafting S:B:D:F numbers for every
VTD device loop over the entire devicetree by PCI DEV IDs.
This adds PCI multi-segment support without any further code
modifications, since the correct PCI segment will be stored in the
devicetree.
Change-Id: I1c24d26e105c3dcbd9cca0e7197ab1362344aa96
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80092
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Attach UBOX stacks on newer generation Xeon-SP.
In order to use PCI drivers for UBOX devices, locating UBOX devices
by vendor and device IDs and replacing device access by specifying
S:B:D:F numbers, add a PCI domain for the UBOX stacks and let the
PCI enumerator index all devices.
Since there are no PCI BARs on the UBOX bus the PCI locator doesn't
have to assign resources on those buses.
Once all PCI devices on the UBOX stack can be located without knowing
their UBOX bus number and PCI segment the Xeon-SP code can fully
enable the multi PCI segment group support.
Test: ibm/sbp1 (4S) is able to find all PCU devices by PCI ID.
Change-Id: I8f9d52dd117364a42de1c73d39cc86dafeaf2678
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80091
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Macros can be confusing on their own; hiding commas make things worse.
This can sometimes be downright misleading. A "good" example would be
the code in soc/intel/xeon_sp/spr/chip.c:
CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev,
This appears as CHIP_NAME() being some struct when in fact these are
defining 2 separate members of the same struct.
It was decided to remove this macro altogether, as it does not do
anything special and incurs a maintenance burden.
Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
With Cr50, the GPIO EC_IN_RW is used to determine whether EC is trusted. However, With the switch to Ti50, it is determined by Ti50's boot mode. If the boot mode is TRUSTED_RO, the VB2_CONTEXT_EC_TRUSTED flag will be set in check_boot_mode(). Therefore in the Ti50 case get_ec_is_trusted() can just return 0.
The current code of get_ec_is_trusted() only checks the GPIO, which
causes the EC to be always considered "trusted". Therefore, correct the return value to 0 for TPM_GOOGLE_TI50.
BUG=b:321172119
TEST=emerge-nissa coreboot chromeos-bootimage
TEST=firmware_DevMode passed in FAFT test
Change-Id: I308f8b36411030911c4421d80827fc49ff325a1b
Signed-off-by: Qinghong Zeng <zengqinghong@huaqin.corp- partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
The current panel voltage measured at mainboard side is 1.79V and the
voltage at panel side is 1.74V. Since the panel requires 1.8V or more,
increase the circuit voltage to 1.9V to meet the panel requirement.
After adjustment mainboard side voltage is 1.89V and panel side is
1.84V.
BUG=b:322080023
TEST=Check ciri vm18 ldo voltage
BRANCH=None
Change-Id: I6d6193d45409f53c0b656890c44ddaef253c5e01
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80198
Reviewed-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's what this function family is defined to do, we currently don't
usually run into the case (see: not too many die() instances going
around), it's more useful to try to recover, and the JPEG parser can run
into it if the work buffer size exceeds the remaining heap, whereas its
sole user (the bootsplash code) knows what to do when seeing a NULL.
Use xmalloc() if you want an allocation that either works or dies.
tl;dr: That code path isn't usually taken. Right now it crashes. With
this patch it _might_ survive. There is a use-case for doing it like
that now.
Change-Id: I262fbad7daae0ca3aab583fda00665a2592deaa8
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Multiple links are unused throughout the tree and make the code more
confusing as an iteration over all busses is needed to get downstream
devices. This also not done consistently e.g. the allocator does not
care about multiple links on busses. A better way of dealing multiple
links below a device is to feature dummy devices with each their
respective bus.
This drops the sconfig capability to declare the same device multiple
times which was previously used to declare multiple links.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
CXL IIO stacks
When an IIO stack is connected with CXL cards, its bus range
will be divided by a PCI host bridge object and a CXL host
bridge object, otherwise, all its range will be owned by the
PCI host bridge object. Accordingly, CXL ACPI resources should
be only created when the IIO stack is connected with a CXL
card.
TEST=intel/archercity CRB
Change-Id: I6c1b1343991bc73d90a433d959f6618bbf59532f
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80087
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently resource allocation starts top down from the default value
0xfe000000. This does not match what ACPI reports, so adapt
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT to reflect that.
Change-Id: I32d08ffd5bbd856b17f7ca2775c5923957d92c85
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The CRAT (Component Resource Attribute Table) isn't used on the APUs
from Renoir on and has also been marked as deprecated in version 6.5 of
the ACPI specification. So remove the 'TODO: look into adding CRAT'
comment from all SoCs from Renoir/Cezanne on.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3ea1e3678608b0ace2a1ff7fc104594e90c91476
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80227
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the acpi_add_fsp_tables implementation is identical for all SoCs,
factor it out and move it to the common AMD FSP code. Also guard the
acpi_add_fsp_tables call in soc_acpi_write_tables with
if (CONFIG(PLATFORM_USES_FSP2_0)) to properly handle the FSP dependency.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8917a346f586e77b3b3278c73aed8cf61f3c9e6a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80225
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Factor out acpi_add_fsp_tables from the soc_acpi_write_tables function
and move the remaining parts of the soc_acpi_write_tables function to
the SoC's acpi.c. This aligns the other family 17h/19h SoCs more with
Genoa and only leaves the FSP-specific code in agesa_acpi.c which will
be made common in a following patch. I decided against also renaming
agesa_acpi.c to acpi_fsp.c, since that would have made the diff less
readable and the files get deleted in a following patch anyway.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia87ac0e77c5e673e694703b85a4bab85a34b980e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
A pointer to soc_acpi_write_tables gets assigned to the
write_acpi_tables element of the device_operations struct, so make sure
that the function has the expected function signature which in this case
means using unsigned long as type for both the 'current' parameter and
the return value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iee45badb904fa20c6db146edbc00c40ca09361d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80218
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As a result of hardware changes on this board, the PHY previously
routed to the PSE GbE 1 is now routed to PSE GbE 0 on the Elkhart Lake
SoC.
This patch changes the device PCI ID in the board's devicetree and
accordingly, the GPIO configuration.
BUG=none
TEST=Boot into Linux and observe whether both PSE GbE 0 and PCH GbE
are working, while PSE GbE 1 remains inactive (not listed by 'ip link')
.
Change-Id: I322371f944d15134e6f48ecd84a4026c2fced27b
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
The currently used panel type could work with 500 ms but increasing
the value to 1 second allows to use a wider range of LVDS LCD panels,
as many of them specify the delay of 1 s as minimum.
The patch has already been made for mc_ehl3 and serves the purpose of
standardization.
commit c0221aa980 ("mb/siemens/mc_ehl3/lcd_panel.c: Set LVDS re-power
delay to 1 s")
Change-Id: Ife26ff27b41298ceeed7d9aed0c1ae5553ab5ff8
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
This patch refactors GPR0 unlock function to add few important
logic as below
1. Perform GPR0 unlock if GPR0 is locked.
2. While unlocking dump the GPRD PCH strap details
3. Additionally, print the GPR start and end range if GPR0
protection is enabled.
TEST=Able to test GPR0 protection on google/rex and google/yahiko.
Exp 1: Trying to unlock GPR0 protection for a locked image
> ifdtool -p mtl -g image.bin -O image.bin_unlock
File image.bin is 33554432 bytes
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
Writing new image to image.bin_unlock
Exp 2: Trying to unlock GPR0 protection for a unlocked image
> ifdtool -p mtl -g image.bin_unlock -O image.bin_unlock
File image.bin_unlock is 33554432 bytes
GPR0 protection is already disabled
Change-Id: Id35ebdefe83182ad7a3e735bdd2998baa0ec3ed7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80216
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This is causing an assertion error on the devices that don't have CNVi
enabled because CNVi is hidden behind a FW_CONFIG flag in the
overridetree now.
BUG=b:319188820
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
make sure we can boot to kernel on device.
Change-Id: Ifcfbc04825d4d4e7f2874a4c52f9c5cf3e657856
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80211
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds the ability to add a flat-binary using menuconfig.
Test: boot hifive-unmatched mainboard with the following config:
CONFIG_PAYLOAD_NONE=n
CONFIG_PAYLOAD_ELF=y
CONFIG_PAYLOAD_FILE="~/repos/linux-riscv/arch/riscv/boot/Image"
CONFIG_PAYLOAD_IS_FLAT_BINARY=y
CONFIG_PAYLOAD_OPTIONS="-l 0x82000000 -e 0x82000000"
CONFIG_COMPRESSED_PAYLOAD_LZMA=y
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I48c6b53a0c9f5b173c89f1a294a0c37fa1a58f31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79950
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds APCB blobs to the mainboard directory and it replaces
CB:76445 Also this brings onyx_poc mainboard inline with how APCB are
included in other AMD mainboard: commit 95d05d8301 ("mb/google/zork:
Add and use APCB configuration data"), commit I352f58e0d39 ("mb/google/
skyrim: Add and use APCB configuration data") and commit I1c34528fa0f
("mb/amd/onyx_poc: Add and use APCB configuration data").
BUG=none
TEST=build/boot onyx_poc
Change-Id: I1c34528fa0fd15b847c22c995713078c60ac3873
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80204
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As with other devices with only an external display, the Librem mini/
mini-v2 need a few extra seconds (vs an internal panel) for display init in order for the edk2 boot splash to be visible before the
default boot target is booted.
TEST=build/boot Librem Mini v2 w/edk2 payload, verify splash screen
shown / user has time to enter setup menu.
Change-Id: I9d2d514719a9918ee58cc63969b3adae44ac1632
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2a6a4d1eb7e0d0cd32c8690caf3eff340cdb0d8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80124
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I434940ebb46853980596f7ad55d27a62c90280fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id09eafd293a54198aab87281f529749325df8b07
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add an ACPI stub containing the SATA device in proper scope, along with
the device status, so that there exists a device to be referenced from
the PEPD LPI constraint list. Fixes a Windows BSOD INTERNAL_POWER_ERROR
on devices with enabled SATA ports.
TEST=build/boot Win11 on google/puff (kaisa).
Change-Id: I951c62d09609ed73079fe97ea9ce49fdee333272
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <ericllai@google.com>
This reverts commit d64b66ba26:
"soc/intel/cannonlake: Add missing min sleep state for thermal device."
Reverting because commit e00523aae2 ("soc/intel/cannonlake: Drop
entries from soc_acpi_name()") removed the ACPI device name for the PCH
thermal device, since there is no ACPI device defined for it. Removing
the name without removing the minimum sleep state caused an invalid LPI
entry to be created, which caused a Windows BSOD: INTERNAL_POWER_ERROR.
TEST=build/boot Win11 on google/puff (wyvern).
Change-Id: I2dfe76d5f72cde7742cee338fa24eaafb84c4604
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80057
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
When the device right below the MPIO chip driver has downstream devices
without another chip in between, those downstream devices will also have
their chip_ops entry set to vendorcode_amd_opensil_genoa_poc_mpio_ops.
To avoid adding the same MPIO descriptor again for those additional
downstream devices, make sure that the chip_info pointer of the device
isn't the same as the one of the parent device, since that's only the
case for those additional downstream devices.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6ba90fdc83ba089127e6722778bfef29dd480bb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80149
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Call setup_opensil, opensil_entry, and fch_init in the right order from
the init method of the SoC's chip operations. This brings this SoC both
more in line with the other SoCs and avoids using boot state hooks for
this which also makes the sequence in which those functions are called
easier to understand. Previously the boot states were used so that
setup_opensil was run before configure_mpio which was run before
opensil_entry(SIL_TP1), but since configure_mpio is called from
setup_opensil, this is no longer necessary.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same. The FCH init code now runs
before the resource allocation like on the AMD SoCs that rely on FSP.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic752635da5eaa9e333cfb927836f0d260d2ac049
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79985
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of calling configure_mpio from the init function of the MPIO
chip struct for the first device that has this struct as chip_ops, call
if from setup_opensil. This will allow to do the calls into openSIL from
the SoC's chip_ops init function instead of having to rely on boot state
hooks. configure_mpio needs to be called after the xSimAssignMemoryTp1
call which sets up the openSIL data structures, but before the
opensil_entry(SIL_TP1) call for which the MPIO data structures need to
be filled for it to be able to initialize the hardware accordingly.
Since the vendorcode_amd_opensil_genoa_poc_mpio_ops struct now no longer
assigns configure_mpio to the init function pointer, we have to check
if the device's chip_ops pointer points to
vendorcode_amd_opensil_genoa_poc_mpio_ops instead of checking if the
chip_ops' init function is configure_mpio to match for the devices below
the MPIO chips in the devicetree.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If37077c879e266763fd2748a1a8d71c63c94729b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since we pass va_list list to the print function, we need to use vprintk
instead of printk. Earlier versions of this code used vsnprintf and a
local buffer, but when that code was reworked to not need the temporary
buffer, it was replaced by printk instead of the correct vprintk.
TEST=Now the console output from openSIL looks as expected:
Example line from openSIL's console output when it prints the MPIO
configuration from a log some commits before this patch:
Host PCI Address - -1352681400:-1353251983:7
Same line with this patch applied looks how it's supposed to:
Host PCI Address - 0:0:0
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: Ia931cc80dea5b7eabb75cfb19f8baa9a09cd2dbf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80203
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some variants added the generic gfx driver with an LCD device without
specifying the address, which is required for the backlight controls
to be functional under Windows. Add the address value where missing.
Address value used (0x80010400) is same as on other Brya variants which
did properly set it, and is taken from the ACPI 6.5 spec section B.4.2,
_DOD (display output device enumeration), table B-2:
- bit 31 = use the ACPI-defined (vs vendor-defined) bit scheme for bits
15-0
- bit 16 = platform firmware can detect the device
- bit 10 = display type is internal/integrated flat panel (aka LCD)
TEST=build/boot Win11 on google/brya (osiris), verify ACPI backlight
controls functional.
Change-Id: Id24e330cfb7c993d12665a704e1ca78e2e38874f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80062
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
There was a mistake in the gpio spreadsheet provided by the HW team
and the GPIO assignments for the EC INT and WAKE signals got switched
from what it was in the schematics. The correct assignments are:
GPP_D0 = EC_PCH_INT_ODL
GPP_D1 = EC_PCH_WAKE_ODL
BUG=b:311450057,b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Will try to boot OS image on device and see if there are any
ec errors.
Change-Id: I02057aeb5d82218dbbe4c939d4feb87a4d3da678
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79886
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4790adb41cb62c8c8dd44261a2926dfb6350955a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80111
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Icfdadfa6705a64655b38aca25be0818ec26429f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80110
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib8a2ae26ed4380592d15e1a7b2d682639413af01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80109
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I85cda24aa7dec82d23e8a321dac03ec737f4c503
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80108
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I92f8bd7e1c9fc6e4120fb94c2299a266304e19de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80107
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I134acc26c0a79d974a6dd0a3b257f961db7e2d86
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80106
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5855f49984db59d786decad6142e3525b146a573
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80105
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I422cb475723006ca42be93508fb0bf4b1e4e84d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80104
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie7038712de8cc646632d5e7d29550e3260bf2c62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80103
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I41f8a9b5d1bdb647a915da1a5e95161b2e34df28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80082
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I9eabe84d55fd9f434e4128866810c0e4970f2ae7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80081
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8cf3d2e2cd1b6ebe4e941ad64f27698379fef696
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80080
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id47a5ef3c53f767d1e03c788e0022d05b21f5c28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80079
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I358b878b97adfd9be156a5dd4a9cbaf9e81bca1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2f299920eb7c6d6f8888cfe5e223ae03093a1d88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80077
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I41191f6971bdd8ecff2c56f4bfa2b57c87530b83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80076
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic80d27a963da8eddc3d1f0d9a3d59763028d4ed0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80075
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I6f502b97864fd7782e514ee2daa902d2081633a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80074
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib479b93b7d0b2e790d0495b6a6b4b4298a515d9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80073
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie449267fe4fdd75110f577e1b9f748cd06140950
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iddac15cc42532f44dda44032be0f8525f6347abd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80070
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic060f3605cd18d4bf774573c21957f626f984e2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80069
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I552d487978906f5ea74c3d0d85373fe5b2de3f38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80068
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I80559b7c86a8fd2583cb0335279f676e0aa0209e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80067
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ice5dadd3eaadfa9962225520a3a75b05b44518ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80066
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
The rest of the Makefiles will be renamed in following commits.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Idaf69c6871d0bc1ee5e2e53157b8631c55eb3db9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80063
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This was determined by sniffing the LPC bus while moving the hardware
wireless switch between the enabled and disabled positions on the
Latitude E6400. The vendor BIOS provides options to change which radios
the switch controls, which was used to determine the mapping between
each radio device and the command argument values.
Change-Id: I173dc197d63cda232dd7ede0cb798ab0a364482b
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77534
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
We need to disable the cnvi device when pcie wifi is enabled, so need
to use the FW_CONFIG defined in the overridetree for this.
BUG=b:311450057,b:300690448,b:319188820
BRANCH=None
TEST=This will be tested on the device when received
Change-Id: If9e861db37e321fd69c09f9b4aafa2e212f92caa
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79898
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the xol variant of the brya0 reference board by copying the
template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:319506033
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_XOL
Change-Id: Id60c50b70c9ab53d62ad48cfc15462f2410f9f02
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80145
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is no need to inject this code in DSDT. Just generating a _CRS
Name in SSDT containing a resource template works well and reduces the
need to sync up on names being used to return _CRS names in DSDT.
TEST=intel/archercity CRB
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I691d7497dceb89619652e5523a29ea30a7b0fab8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The code can now deal with stacks that have no resources so just hook
them all up.
Intel XEON-SP FSP reports all report the state of its stacks, which
comprise of PCI root bridges and their respective resources, like PCI
busses, IO and MEM resources, via HOB. Parsing all of those into native
coreboot structures makes it possible to handle those in a more native
fashion like use PCI drivers, native helper functions, ... As opposed
parsing those structures again out of the HOB each time. This makes code
reuse across the tree more feasible.
An additional advantage is that Linux does not need to redo resource
allocation since the one done by coreboot will be valid, which
potentially decreases boot time.
TEST=intel/archercity CRB
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Change-Id: Id72c6e4499e99df3b7ca821ab2893cbcc869dbcd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Although a section ".bss.ttb_buffer" is created automatically for
'ttb_buffer' with the GCC option '-fdata-sections', specify the section
name explicitly to make the name stand out to code readers, and to
reduce the chance of accidentally changing the section name by renaming
the variable.
Change-Id: I2930f238f63b555c4caa65709768afa314d9cf87
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Repo sync code recently, run command as memtioned in TEST and
found the changed for the auto-gen files.
Then correct the memory typo from K4UBE3D4AA-MGCR to K4U6E3S4AA-MGCR,
and no new for the used hex file.
BUG=b:320181366
BRANCH=firmware-dedede-13606.B
TEST=Run command "go run ./util/spd_tools/src/part_id_gen/\
part_id_gen.go JSL lp4x \
src/mainboard/google/dedede/variants/galtic/memory/ \
src/mainboard/google/dedede/variants/galtic/memory/\
mem_parts_used.txt"
Change-Id: I7c158eb7b4455cde839a335913e6a18895c12b41
Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79976
Reviewed-by: Derek Huang <derekhuang@google.com>
Reviewed-by: Daniel Peng <daniel_peng@pegatron.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit d078ef2152
("soc/intel/cmn/block/pmc: Add previous sleep state strings in log")
used SLP_TYP numbers to map ACPI sleep state value. This incorrectly
printed wrong string for prev_sleep_state during S5.
ex: after a cold reset the previous sleep state printed was
[DEBUG] prev_sleep_state 5 (S3)
This patch corrects this by using ACPI sleep state numbers for mapping
the prev_sleep_state values.
TEST=test the logs on google/rex board after cold reset
[DEBUG] prev_sleep_state 5 (S5)
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I9bcdacc4d01a8d827a6abdf9af2b9e5d686ed847
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80144
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Issue: System hang occurred due to unhandled SPI synchronous SMI,
triggered by LOCK_ENABLE bit and WPD assertion.
Solution: Enabled SOC_INTEL_COMMON_BLOCK_SMM_TCO_ENABLE configuration
to allow the system to handle and clear SPI synchronous SMI.
BUG=b:306267652
TEST=Cold reboot test on 20 google/screebo by ODM, all passed w/o
hang.
Change-Id: Ie1f096f8eda4adcf1627e44afa517b02adddad76
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79654
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Updating from commit id e7486343d:
2023-11-28 22:48:16 +0100 - (Merge changes from topic "xlnx_fitimage_check" into integration)
to commit id 23d6774ab:
2024-01-16 09:47:43 +0100 - (Merge "feat(qemu-sbsa): mpidr needs to be present" into integration)
This brings in 150 new commits.
Change-Id: I4aefd60dcd785934286eb8f7b0defd61c73e78f7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80045
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
WLAN has always been pcie_rp5, there is nothing on pcie_rp1. RP5 gets
promoted to function 0 (RP1's function) since no earlier functions are
enabled.
This simplifies later refactoring that will handle the FSP root port
enable flags (which were correctly set already) using the device tree
enables.
Test: Boot librem_13v2 and verify WLAN is enabled.
Change-Id: I7a724a01b5f171a16de83ff6122630e2d66557c1
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Since the romstage code is very similar between all AMD non-CAR SoCs,
factor out a common romstage implementation. All SoCs that select
SOC_AMD_COMMON_BLOCK_PM_CHIPSET_STATE_SAVE call fill_chipset_state, so
this Kconfig option can be used to determine whether to make that call.
In the FSP case, amd_fsp_early_init gets called, while in the case of an
implementation that doesn't rely on an FSP to do the initialization,
cbmem_initialize_empty gets called to set up CBMEM which otherwise would
be done inside the FSP driver code. Since only some SoCs call
fch_disable_legacy_dma_io again in romstage right after
amd_fsp_early_init, introduce the new
SOC_AMD_COMMON_ROMSTAGE_LEGACY_DMA_FIXUP Kconfig option, so that the
SoCs can specify if this call is needed or not.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4a0695714ba08b13a58b12a490da50cb7f5a1ca9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80083
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Split the SOC_AMD_PHOENIX Kconfig option into SOC_AMD_PHOENIX_BASE that
selects the non-FSP-specific options and SOC_AMD_PHOENIX_FSP that
selects both SOC_AMD_PHOENIX_BASE and the FSP-specific options. This
will help to separate the FSP-specific from the FSP-agnostic code. The
mainboards using this SoC now select SOC_AMD_PHOENIX_FSP instead of
SOC_AMD_PHOENIX.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5e95fbfd9d16930ba3e6cc497557d61adba5a6fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79983
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add get_wifi_sar_cbfs_filename(). This function uses the FW_CONFIG
for WIFI to choose the right wifi_sar hex file. Below is the file
mapping:
wifi_sar_0.hex = wifi6
wifi_sar_1.hex = wifi7
BUG=b:319302319
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
Change-Id: I212c80412141e7770a512bd8ccf4111963bab395
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80085
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reformat alternate dump output to show default values before read
values, and to use brackets to visually indicate which values differ
from the defaults.
old output:
Register dump:
idx val def
0x07: 0x0b (0x00)
0x10: 0xff (0xff)
0x11: 0xff (0xff)
...
new output:
Register dump:
idx def val
0x07: 0x00 [0x0b]
0x10: 0xff 0xff
0x11: 0xff 0xff
...
TEST=build/dump registers from Erying SRMJ4 w/Nuvoton NCT6796D.
Change-Id: Idef2cc136151328b114620eb297ab8fd62b71bcd
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80004
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
If CONFIG_LP_ARCH_MOCK, pass FIRMWARE_ARCH=mock when building vboot
fwlib, so that vboot's Makefile will append the correct flags to CFLAGS.
BUG=none
TEST=(depthcharge) make unit-tests -j
BRANCH=none
Cq-Depend: chromium:5182247
Change-Id: I9ead7f2f93eac5f5c3887074423fb9aa50a489c0
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79956
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Describe the FW_CONFIG probe for the settings for Palutena.
- WIFI_SAR_ID_0 for AW Wi-Fi module AW-CM421NF
- WIFI_SAR_ID_1 for Intel Wi-Fi module AX211NGW
2. In contrast to the AW Wi-Fi module, the Intel Wi-Fi module needs
to load a SAR table in dedede platform.
3. For Palutena project, the SKU ID segment of Palutena is set for
"0x350000~0x35FFFF".
BUG=b:319792428
BRANCH=firmware-dedede-13606.B
TEST=build pass
Change-Id: Ic4f38928d24c4398d90df226cfe0788a30075bf2
Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79930
Reviewed-by: Daniel Peng <daniel_peng@pegatron.corp-partner.google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shou-Chieh Hsu <shouchieh@google.com>
1. Modify 6w/15w DPTF parameters based on b:290705146#comment41.
2. 6W MSR power limit_1 power (Watts) increase to 20.
3. 15W MSR power limit_1 power (Watts) increase to 20.
BUG=b:290705146
TEST=emerge-nissa coreboot chromeos-bootimage
Thermal team test pass.
Change-Id: I15fa4b8f7c7088ff56da6493659ae45572913b5a
Signed-off-by: Rex Chou <rex_chou@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79890
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Work around a romstage restriction. Globals (or static variables) cannot
be initialized to a non-zero value because there's no data section. Note
that the revision ID for stepping A0 is zero, so `pch_silicon_revision`
will no longer use the cached value for this PCH stepping. Since it is a
pre-production stepping, it is most likely not used anywhere anymore.
Change-Id: I07663d151cbc2d2ed7e4813bf870de52848753fd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
I got confused and used UFS (User Facing Side) for the User Facing
Camera (UFC) in the FW_CONFIGs. Change references of the camera from
UFS --> UFC.
BUG=b:300690448
BRANCH=None
TEST=None. The camera has not been enabled yet.
Change-Id: I4f8240ae51aad1e077f325a9eab5a2a92f1402cb
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79997
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of checking if there is more than one PCI segment group and
erroring out in that case during the build, add this requirement as a
dependency to the GENERATE_MP_TABLE Kconfig option. The mpspec.c source
file only gets included in the build if GENERATE_MP_TABLE is selected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie532a401ad0161890d0fb4ca2889af022d5f6b47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79994
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Always use the high-level API region_offset() and region_sz()
functions. This excludes the internal `region.c` code as well
as unit tests. FIT payload support was also skipped, as it
seems it never tried to use the API and would need a bigger
overhaul.
Change-Id: I18f1e37a06783aecde9024c15876b67bfeed70ee
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Accessing RAM before mmu initialized is time consuming. During mmu
initialization, `mmu_init()` and `mmu_config_range()` write logs to the
console buffer and contribue the extra boot time.
This patch adds a kconfig option to move `mtk_mmu_init()` to
`bootblock_soc_early_init()`. When `EARLY_MMU_INIT` is enabled, mmu is
initialized before `console_init()` ready. So `mmu_init()` and
`mmu_config_range()` won't write logs to the console buffer and save the
boot time.
It saves about 65ms on Geralt with EARLY_MMU_INIT enabled.
Before:
0:1st timestamp 239,841 (0)
11:start of bootblock 239,920 (79)
12:end of bootblock 323,191 (83,271)
After:
0:1st timestamp 239,804 (0)
11:start of bootblock 239,884 (80)
12:end of bootblock 258,846 (18,962)
BUG=b:320381143
TEST=check timestamps in cbmem
Change-Id: I7f4c3c6c836f7276119698c6de362794cf4222a6
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Gothrax cannot boot into OS with a kernel loading failure.
Update eMMC DLL values to improve initialization reliability
How to get these values:
- Sending different speed TX/RX command/data signal to eMMC and check
the response is successful or not.
- Collecting above results from each eMMC model that project used.
- Analysing logs to provide a fine tuned DLL values.
BUG=b:310701323
TEST=Cold reboot stress test over 2500 cycles
Change-Id: Ie36cc9948e3d5dee46385e584baad141a249be79
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
These are specific to the brox board, so moving devices to the brox
variant.
BUG=b:311450057,b:300690448,b:319058143
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
will check if this helps detect the storage device in the factory
Change-Id: I18d096040c293abfd4cd0b1bb5f50ba6dcc2e183
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Brox project has FW_CONFIG bits already set up in the project file for
the retimer and for storage, so make sure that the brox device tree
matches those settings.
BUG=b:311450057,b:300690448,b:319058143
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
will check if this helps detect the storage device in the factory
Change-Id: Iaf43003b7e8210eee9016d779839d7048c15825f
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79854
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id 32402941:
2024-01-08 19:53:43 +0000 - (treewide: Put the static keyword at the beginning of declarations)
to commit id 3d37d2aa:
2024-01-15 06:21:04 +0000 - (Makefile: Support FIRMWARE_ARCH=mock for firmware unit tests)
This brings in 2 new commits:
3d37d2aa Makefile: Support FIRMWARE_ARCH=mock for firmware unit tests
ffe3fb20 make_keyblock: Add support for omitting extension
Change-Id: I30425f0c50caf24800661568da8f72f6b4418d9c
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
There is a mismatch in how PCI memory resources are allocated on Apollo
Lake with the current configuration. While the ACPI code expects
resources to be below PCR_BASE_ADDRESS (i.e. PMAX), the coreboot C code
allocates them above, leading to the following error messages on Linux:
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
pci_bus 0000:00: root bus resource [mem 0x80000000-0xd0000000 window]
pci_bus 0000:00: root bus resource [mem 0x280000000-0x7fffffffff window]
pci 0000:00:13.1: can't claim BAR 14 [mem 0xdeb00000-0xdebfffff]: no compatible bridge window
pci 0000:00:13.1: can't claim BAR 15 [mem 0xdec00000-0xdecfffff 64bit pref]: no compatible bridge window
pci 0000:00:13.1: BAR 14: assigned [mem 0x80000000-0x800fffff]
pci 0000:00:13.1: BAR 15: assigned [mem 0x281300000-0x2813fffff 64bit pref]
Tested on up/squared with Linux kernel version 6.1.0.
Fix this by setting the DOMAIN_RESOURCE_32BIT_LIMIT to PCR_BASE_ADDRESS,
and by moving the UART base address into the expected range.
Thanks to Nico Huber for the help in writing this patch.
Change-Id: I3a805beb47ab4d19cf8dfce0942485e7982861b1
Signed-off-by: Reto Buerki <reet@codelabs.ch>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79957
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add initial support for multiple PCI segment groups. Instead of
modifying secondary in the bus struct introduce a new segment_group
struct element and keep existing common code.
Since all platforms currently only use 1 segment this is not a
functional change. On platforms that support more than 1 segment the
segment has to be set when creating the PCI domain.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ied3313c41896362dd989ee2ab1b1bcdced840aa8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The xeon_sp code worked around the coreboot allocator rather than using
it. Now the allocator is able to deal with the multiple IIOs so this is
not necessary anymore.
Instead do the following:
- Parse the FSP HOB information about IIO into coreboot PCI domains
- Use existing scan_bus and read_resource
- Handle IOAT stacks with multiple domains in soc-specific code
TEST=intel/archercity CRB
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Change-Id: Idb29c24b71a18e2e092f9d4953d106e6ca0a5fe1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The PCIE MMCONFIG base address value and size is updated correctly to
access the PCIE config space registers.
TEST=Verified that PCIE enumeration takes place in boot log
and config space registers are accessible.
Change-Id: Ifa8377df7a2973a88d414c217b5ed114c8ae5cc3
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79832
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Describe the USB 'current' settings based on MRC.bin that converts
the USB trace length to a predefined register value.
MRC.bin decides which setting to use based on the PC type, mobile
or desktop, and the trace length.
Tested: Lenovo X220 still boots.
Change-Id: I79d35ca16818daec03ee7f464349a4c8ee0f78e4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Currently autoport fills in USB current '0' if the detected setting
isn't one of the known settings. This works as 0 is a valid setting
from C point of view, but it's not supported on desktop PCs and on
mobile platform results in the lowest possible USB PHY gain. Thus
this might cause instabilities as the original firmware had stronger
USB drive currents and gain settings.
Add more known USB current fields to the map and generate a FIXME
as comment when the detected current isn't one of the known entries
instead of defaulting to 0.
Change-Id: I48f4d636ce3401ba188f5519b5ff45fccf13f080
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78828
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
According to BWG the USB current setting 0 should not be used for
desktop boards. As autoport defaults to 0 if the USB current doesn't
match one of the lookup table entries most of the desktop boards in
tree have such a setting. Print an error to alert users of such boards
to update the USB current settings.
Tested: Lenovo X220 still boots.
Change-Id: If76e9126b4aba8e16c1c91dece725aac12e1a7e9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78827
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A recent update broke installation of commonlib headers with a relative
path in $(DESTDIR), which is the default. Make sure to install into the
right location in case we changed the current directory.
Change-Id: I61fa4aa0ecd0f81ee03ff89183e1b65e7875dea6
Signed-off-by: Nico Huber <nico.h@gmx.de>
Fixes: ee53dfd07d (libpayload: Remove shell for loops in install Makefile target)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79908
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MIPI panel BOE_NV110WUM_L60 will be used for Ciri, enable it.
Also remove the `mdelay(10)` after mtk_i2c_bus_init, because MTK
confirms this is not needed. Add mdelay(2) between VDD18 and VSP/VSN
to meet the panel datasheet.
BUG=b:308968270
TEST=Boot to firmware screen
BRANCH=None
Change-Id: I0a04f062f81c543d38716d7ff185b5633c1aa3a9
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78957
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Always use the high-level API region_offset() and region_sz()
functions. This excludes the internal `region.c` code as well
as unit tests. FIT payload support was also skipped, as it
seems it never tried to use the API and would need a bigger
overhaul.
Change-Id: Iaae116a1ab2da3b2ea2a5ebcd0c300b238582834
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79904
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
As a preparation for the multi PCI segment group support, use
acpigen_write_BBN to generate the _SEG method that returns the segment
group number of the PCI root. Until the multi PCI segment group support
is enabled in coreboot, it will always return 0.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2a812dcc564c5319385e9ad482d29b2984a71b8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79924
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is needed for NVMe to work when PCIe device is connected to the
CPU side of RPL soc.
BUG=b:311450057,b:300690448, b:319058143
BRANCH=None
TEST=Tested on device and was able to boot to the OS
Change-Id: Ic8a1fdcedf2ec6c7bf1dd00e02ef7c13e9338aac
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79857
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This needs to be disabled for RPL otherwise we'll hit the assertion:
[EMERG] ASSERTION ERROR: file 'src/soc/intel/alderlake/fsp_params.c', line 1066
There is a comment in the referenced file/line in the assertion that
says that "C state demotion must be disabled for Raptorlake J0 and Q0
SKUs." So, disabling it.
BUG=b:311450057,b:300690448
BRANCH=None
TEST=Tested that we didn't hit this assertion on the device after this
change
Change-Id: Ib7b2484de2d84c980550fd951f1e30efab0ee197
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79855
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Historically resource allocation in coreboot was 32bit x86 thing. To
remain compatible with this behavior (e.g. to keep 32bit payloads
happy), resource allocation limits resources to 32 bits unless
explicitly overridden. However this behavior is not always appropriate:
e.g. on non x86 platforms the PCIe mem decode window could be above 4G.
Another case on x86 is where the decode window(s) below 4G are not
adequate for fitting all resources and the payload is 64bit
capable (e.g. Linux).
This adds a Kconfig flag to override the behavior to limit resources to
32bit by default and to allocate resources according to the real
hardware limits.
TEST=intel/archercity CRB
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I01218a8a3efc4a5f8ba344808949ca6b8898525f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78331
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
As per Intel Meteor Lake SPI programming doc, the BIOS region should
have a read access enabled for device expansion 2 region
(aka region 9).
This patch ensures that BIOS region is able to read the device
expansion 2 region for Intel Meteor Lake platform as known as
SPI padding region.
BUG=b:274356894
BRANCH=firmware-rex-15709.B
TEST=Able to flash screebo AP FW image using flashrom on DUT.
Without this patch:
> flashrom -p internal -r /tmp/bios.rom
flashrom 1.4.0-devel on Linux 6.1.67-09255-ge8ae3115f8b0 (x86_64)
...
...
Found Winbond flash chip "W25Q256JW_DTR" (32768 kB, Programmer-specific)
on internal.
Reading flash... Transaction error between offset 0x0072f000 and
0x0072f03f (= 0x0072f000 + 63)!
read_flash: failed to read (0x72f000..0x7fffff).
Read operation failed!
FAILED.
FAILED
With this patch:
> flashrom -p internal -r /tmp/bios.rom
flashrom 1.4.0-devel on Linux 6.1.68-09294-g001fdda5287d (x86_64)
...
...
Found Winbond flash chip "W25Q256JW_DTR" (32768 kB, Programmer-specific)
on internal.
Reading flash... done.
SUCCESS
Change-Id: I18c44aa9a0f890f01a889247da118b69a58936e8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Eric Lai <ericllai@google.com>
driver
Since DRIVERS_I2C_SX9324_SUPPORT_LEGACY_LINUX_DRIVER value on dedede
cannot meet DRIVERS_I2C_SX9324 on nissa, need to update the tuning
value. Update proximity sensor fine tune value with quandiso EVT
machine.
BUG=b:314550601
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot and verify p-sensor
watch 'cat /sys/bus/iio/devices/iio:device*/*raw'
Change-Id: I5fc3bc5876594f2df79d628bd986113d37087c3d
Signed-off-by: Robert Chen <robert.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
The APU boards have an NCT5104D chip on the LPC bus that implements some
serial ports that have the legacy IO port interface to the host and
doesn't describe this in the ACPI tables, so select
HUDSON_FADT_LEGACY_DEVICES to have the corresponding FADT bit set. Since
this chip doesn't provide an 8042-compatible keyboard controller, don't
select HUDSON_FADT_8042.
TEST=Surprisingly, this doesn't seem to make a difference to the Linux
kernel; is creates all ttyS[0..3] devices with and without this patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8872b8c3d6e0610630ba17a0fccdcf8cebb1d3c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79894
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
HUDSON_LEGACY_FREE controlled both if the legacy devices and the 8042
flags are set in the IA-PC boot architecture filed of the FADT. Since
some systems have legacy devices on the LPC bus, but no 8042-compatible
keyboard controller, replace this option with the two new options
HUDSON_FADT_LEGACY_DEVICES and HUDSON_FADT_8042.
TEST=The FACP table doesn't change on APU2
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id4ff85630c90fb2ae8c8826bbc9049a08668210d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use pm_acpi_smi_cmd_port() to get the APMC trigger IO port instead of
using the hard-coded APM_CNT define. This makes sure that the correct
APMC IO port will be used even when a system doesn't use the default
APM IO port.
TEST=SMMSTORE V2 still works with the EDK2 payload on Careena
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icb79c91cfcd75db760bd80cff7f3d0400d1f16cd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79568
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use call_smm instead of open-coding the same in inline assembly
functionality in init_store. The local ebx variable is dropped, since
call_smm takes a pointer to the argument instead of an integer, and the
local eax variable is renamed to res to make the code a bit clearer,
since the EAX register is used for both passing the command and
subcommand to the APMC SMI handler and to get the return value from the
handler.
TEST=SMMSTORE V2 still works with the EDK2 payload on Careena
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib14de0d120ae5c7db3bb7a529837ababe653e1a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Moving it into the .ttb_buffer section will accidentally set the LOAD
flag. So, move it back to .bss.ttb_buffer section to prevent the binary
size bloating.
BUG=b:248610274
TEST=Make sure the device is still bootable with this change.
BRANCH=none
Cq-Depend: chromium:5173448
Change-Id: I9bb08878dd4be01d9ed3f96933f774dd6296f76e
Signed-off-by: Yi Chou <yich@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79800
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tell binaryPI to not disable the LPC decodes for the IO ports used by
the serial ports on the Super I/O chip during the AmdInitReset binaryPI
entry point. Checked the Stoneyridge binaryPI source code which is
closely enough related to be reasonable sure that this option only
controls which LPC decode bits get cleared and won't have any other side
effects.
TEST=Now the full console output from the APU2 board gets printed on the
serial console.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Change-Id: I91ef4423bd7bf6c1d7a175336f0f89479f2cde02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79852
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that Stoneyridge also reports the GNB IOAPIC on the domain and with
the IOMMU_IOAPIC_IDX resource index the common AMD MADT code expects, we
ca switch over to using this common code on Stoneyridge too.
TEST=The resulting MADT doesn't change on Careena
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If4ce71a47827e144c4d4991152101650904901f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Move the GNB IOAPIC resource from being reported in the GNB PCI device
to the domain and use IOMMU_IOAPIC_IDX as resource index, so that the
common AMD MADT code will be able to find the resource.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If6e9aaf4a3fa2c5b0266fd9fb8254285f8555317
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Move the IOMMU_IOAPIC_IDX define from amdblocks/data_fabric.h to
amdblocks/ioapic.h which is both a more logical place for it to be and
this is also a preparation to use the common AMD MADT code for the
Stoneyridge SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaa20e802cf5ed93f0d05842abb1aea0d43b1cac4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This commit adds support for showing different logos on the ChromeOS
firmware splash screen based on the device model (between
Chromebook-Plus and regular ChromeOS devices like Chromebook and
Chromebox). This allows OEMs to customize the branding on their
devices.
This patch also introduces three new Kconfigs:
- CHROMEOS_FW_SPLASH_SCREEN
- CHROMEOS_LOGO_PATH
- CHROMEBOOK_PLUS_LOGO_PATH
which allow users to enable the fw splash screen feature in the
vendorcode. Previously, we were using the BMP_LOGO Kconfig in
drivers/intel/fsp2_0, but we didn't want the top level Kconfigs to be
located inside the architecture specific files.
BUG=b:317880956
BRANCH=None
TEST=emerge-rex coreboot chromeos-bootimage
verify that FW splash screen appears
Change-Id: I56613d1e7e81e25b31ad034edae0f716c94c4960
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79775
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Removes unnecessary HAVE_FSP_LOGO_SUPPORT config from google/rex
baseboard. Intel Meteor Lake SoC now selects this config
automatically for supported platforms.
BRANCH=firmware-rex-15709.B
TEST=Able to build and boot google/rex and intel/mtlrvp.
Change-Id: I89bdd54cb73b11f74db2927a5eb86ab826c60517
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79860
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enables FSP logo support for Meteor Lake SoC config, covering
both Intel Meteor Lake RVP and ChromeOS devices.
Applies HAVE_FSP_LOGO_SUPPORT configuration only for platforms
with native FSP support.
Ensures successful builds and boots for google/rex and intel/mtlrvp.
BRANCH=firmware-rex-15709.B
TEST=Able to build and boot google/rex and intel/mtlrvp
Change-Id: Ic99bfdc2d33db48bdb015525981c1ef76df8203b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79859
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
The acpi_fill_madt implementation from the Genoa PoC also works for the
other AMD SoCs that select SOC_AMD_COMMON_BLOCK_DATA_FABRIC_DOMAIN, so
factor out this function to the common AMD ACPI code and change those
other SoCs to use the new common functionality instead of having their
own implementations.
The old code on the single-domain SoCs used the GNB_IO_APIC_ADDR base
address to create the MADT entry for the additional IOAPIC in the root
complex. The new code iterates over all domains and looks for a resource
with the IOMMU_IOAPIC_IDX index in each domain and if it finds it, it
creates an MADT entry for that IOAPIC. This resource is created earlier
in the boot process when the non-PCI resources are read from the IOHC
registers and reported to the allocator.
TEST=The resulting MADT doesn't change on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4cc0d3f30b4e6ba29542dcfde84ccac90820d258
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79861
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The call_smm function is currently unused and the inline assembly code
for more or less the same functionality in drivers/smmstore/ramstage is
both a bit easier to understand since it uses the register names in the
'outb' instruction instead of positional arguments, and also tells the
compiler that this piece of code might change global memory. Having too
much in the clobber list might only have some performance impact, which
should however be negligible compared to the SMI handler being called,
while missing something in the clobber list might cause hard to debug
problems.
This is a preparation to make drivers/smmstore/ramstage use call_smm
instead of having its own inline assembly implementation for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I73837cab75429014897486b38a5c56f93a850f96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This partially reverts commit f493857c9b ("mb/google/brya/var/*: Set
dGPU/LAN/WLAN device type to generic"). Setting the WLAN device type to
generic broke ACPI SSDT table definition, so set it back to pci.
BUG=b:318576073
TEST=build/boot google/nissa (pujjo), verify WLAN ACPI SSDT tables
contain the appropriate device entry.
Change-Id: If5dad9deb040c8cb0c507e11726f0ba44ccb2909
Signed-off-by: David Ruth <druth@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The Hudson southbridge code for the AMD binaryPI SoCs had its own ACPI
enable and disable APMC command numbers that didn't match the common
defines in coreboot, so use the common define here to be consistent with
the command numbers in the corresponding FADT fields. Since the only SoC
that still would use this code doesn't select HAVE_SMI_HANDLER, this
won't fix any observable bug, but better fix this before anyone possibly
runs into this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5e596071e1b5269b616b7a93151648cb86ae77bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This fixes the following compile error when trying to build the APU2
board with HAVE_SMI_HANDLER selected and the NO_SMM select removed:
In file included from src/soc/amd/common/block/gpio/gpio.c:8:
src/include/gpio.h:6:10: fatal error: soc/gpio.h: No such file or directory
6 | #include <soc/gpio.h> /* IWYU pragma: export */
| ^~~~~~~~~~~~
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie06044b12f5cbcc55a2706ec566afd2eb294c62b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79846
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The sequences of configure_display() are similar on MediaTek platforms.
The sequences usually involve following steps:
1. Setup mtcmos for display hardware block.
- mtcmos_display_power_on()
- mtcmos_protect_display_bus()
2. Configure backlight pins
3. Power on the panel
- It also powers on the bridge in MIPI DSI to eDP case.
4. General initialization for DDP(display data path)
5. Initialize eDP/MIPI DSI accordingly,
- For eDP path, it calls mtk_edp_init() to get edid from the panel
and initializes eDP driver.
- For MIPI DSI path, the edid is retrieved either from the bridge or
from CBFS (the serializable data), and then initializes DSI driver.
6. Set framebuffer bits per pixel
7. Setup DDP mode
8. Setup panel orientation
This patch extracts geralt/display.c to mediatek/common/display.c and
refactors `struct panel_description` to generalize the display init
sequences. configure_display() is also renamed to mtk_display_init().
TEST=check FW screen on geralt.
Change-Id: I403bba8a826de5f3fb2ea96a5403725ff194164f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79776
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to comply with the more recent style of declarations, put the
static keyword at the beginning.
Fixes following GCC error when the related flag is set:
error: 'static' is not at beginning of declaration [-Werror=old-style-declaration]
Change-Id: Ida683319f7a0c428a9e4808821075abdd9fcb504
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79856
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Updating from commit id 7c3b60bb:
2023-12-21 20:34:49 +0000 - (firmware/2lib: Use SSE2 to speed-up Montgomery multiplication)
to commit id 32402941:
2024-01-08 19:53:43 +0000 - (treewide: Put the static keyword at the beginning of declarations)
This brings in 4 new commits:
32402941 treewide: Put the static keyword at the beginning of declarations
242d198b crossystem: Use external tool the clear the TPM
c8a0802f tests: Remove unnecessary vb2_verify_fw.c from TEST20_NAMES list
706088b8 tests: Test HW crypto RSA signature verification
Change-Id: I667376dfc3021fa6d213e3d89917ee228fd14a28
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
A following error occurred when I commit, it seems that the extra `\`
after `\.md$` is unnecessary.
File Binary file src/mainboard/google/guybrush/data.apcb matches has
lines ending with whitespace.
File Binary file src/mainboard/google/skyrim/data.apcb matches has
lines ending with whitespace.
File Binary file src/mainboard/google/zork/data.apcb matches has
lines ending with whitespace.
test failed
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I315a37ccc3c6ebb67f7a250402549761c699dd1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79782
Reviewed-by: cong yang <yangcong5@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Introduce the HAVE_CONFIGURABLE_APMC_SMI_PORT Kconfig option that when
not selected will result in a default implementation of
pm_acpi_smi_cmd_port to be included in the build that returns APM_CNT.
SoCs that provide their own pm_acpi_smi_cmd_port implementation, need to
select this Kconfig option.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaceb61b0f2a630d7afe2e0780b6a2a9806ea62f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Commit 850b6c6254 ("soc/amd/picasso: add eMMC MMIO device to
devicetree") broke both S3 resume on Morphius SKUs that use an NVMe SSD
instead of an eMMC and boot on the currently out-of-tree ASRock X370
Killer SLI board. In the latter case, commenting out the
power_off_aoac_device call inside the emmc_enable function fixed things.
TEST=This fixes S3 resume on Morphius with NVMe SSD and an equivalent
change discussed in the patch mentioned above that caused the regression
also fixed boot on the ASRock board.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Change-Id: Id976734c64efe7e0c3d8b073c8009849be291241
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Enable x86_64 support for MRC.bin:
- Add a wrapper function for console printing that calls into
long mode to call native do_putchar
- Remove Kconfig guard for x86_64 when MRC is being used
Tested: Booted Lenovo X220 using mrc.bin under x86_64 and
MRC is able to print to the console.
Change-Id: I21ffcb5f5d4bf155593e8111531bdf0ed7071dfc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add another mode_switch assembly function to call x86_64 code from
x86_32 code. This is particullary useful for BLOBs like mrc.bin or
FSP that calls back into coreboot.
The user must first wrap all functions that are to be called from
x86_32 using the macro prot2lm_wrapper. Instead of using the original
function the wrapped functions must be passed to the x86_32 BLOBs.
The assembly code assume that 0-3 32bit arguments are passed to
the wrapped function.
Tested:
- Called x86_64 code from x86_32 code in qemu.
- Booted Lenovo X220 using x86_32 MRC using x86_64 console.
Change-Id: Ib625233e5f673eae9f3dcb2d03004c06bb07b149
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch ensures `chromeos_get_factory_config()` returns an
unsigned integer value because factory config represents
bit-fields to determine the Chromebook Plus branding.
Additionally, introduced safety measures to catch future
"factory_config" bit-field exhaustion.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: I3021b8646de4750b4c8e2a2981f42500894fa2d0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79769
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On ChromeOS devices with updateable CSE firmware, the GPR0 (Global
Protected Range) register is used to ensure the CSE RO is write
protected even when the FLMSTR-based protection is temporarily disabled
by coreboot to allow updating the CSE RW. For more details see
Documentation/soc/intel/cse_fw_update/cse_fw_update.md
Therefore to allow modifying the CSE firmware from the CPU, the
descriptor must have both the FLMSTR-based protection disabled (which
can be done using ifdtool --unlock), and GPR0 disabled.
Add an ifdtool option for disabling GPR0. For now I've added support for
all platforms for which I have the SPI programming guide. Support for
more platforms can be added in the future if needed.
BUG=b:270275115
TEST=Run `ifdtool -p adl -g image.bin -O image-unlocked.bin` on a locked
craask image, check the GPR0 field is set to 0.
Change-Id: Iee13ce0b702b3c7a443501cb4fc282580869d03a
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79788
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To verify the boot chain, we will need to extend the PCR with the
firmware version. And the server will be able to attest the firmware
version of devices.
The "firmware version" here is the RW firmware anti-rollback version,
determined by the ChromeOS's signing infra, and will be verified in
vb2api_fw_phase3, by comparing it with the version stored in the TPM.
This version will be increased when there is critical vulnerability
in the RW firmware.
According to [1], PCRs 8-15 usage is defined by Static OS. Therefore
PCR_FW_VER is chosen to be within that range. Ideally the existing
PCR_BOOT_MODE and PCR_HWID should also be allocated in the same range,
but unfortunately it's too late to fix them. Because PCRs 11 and 13
have been used for other purposes in ChromeOS, here PCR_FW_VER is set
to 10.
[1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_05_3feb20.pdf
BUG=b:248610274
TEST=Boot the device, and check the PCR 10
BRANCH=none
Signed-off-by: Yi Chou <yich@google.com>
Change-Id: I601ad31e8c893a8e9ae1a9cdd27193edce10ec61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79437
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In DDR3 DLL-Off mode is an optional feature advertised by SPD.
Honor the SPD and only use DLL-Off mode when all DIMMs on the
same channel indicate support for it.
The same is done on MRC.bin.
Tested on Lenovo X220: Still boots fine.
Change-Id: Ief4bfb9e045cad7ff9953f6fda248586ea951a52
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79758
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To avoid code duplication and to also bring the mainboards using the
Picasso SoC more in line with Cezanne and newer, factor out the SoC-
specific code from the mainboard's dsdt.asl files to the SoC's soc.asl.
TEST=Timeless builds result in identical images for Bilby, Mandolin, and
Zork/Morphius
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id4ed3a3d3cb55c8b3b474c66a7c1700e24fe908e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This patch introduces the 512KB SI_EC FMAP region for storing the EC
firmware, a necessary addition to support EC chips without internal
flash memory.
As a testing platform, the MTLRVP Chrome SKU is utilized in conjunction
with the Microchip EC1723, and the changes are verified.
Cq-Depend: chrome-internal:6691498
Cq-Depend: chrome-internal:6741356
BUG=b:289783489
TEST=build "emerge-rex coreboot chromeos-bootimage" is successful.
changes are verified.
EC Log:
23-11-06 17:46:49.564 --- UART initialized after reboot ---
23-11-06 17:46:49.564 [Image: RO, mtlrvpp_m1723_v3.5.142816-ec:6596a3,
os:f660f7,cmsis:42cf18,picolibc:6669e4]
23-11-06 17:46:54.609 D: Power state: S5 --> S5S4
23-11-06 17:46:54.620 D: Power state: S5S4 --> S4
23-11-06 17:46:54.620 D: Power state: S4 --> S4S3
23-11-06 17:46:54.642 I: power state 10 = S3S0, in 0x0087
23-11-06 17:46:54.642 ec:~>: Power state: S3S0 --> S0
Change-Id: I788dbeaad05e5d6904fb2c7c681a0bf653dc7d84
Signed-off-by: Deepti Deshatty <deepti.deshatty@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79209
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the first argument specifying the number of arguments pushed
to the stack. Instead always push the 3 arguments to stack and use
the first one as function pointer to call while in protected mode.
While on it add more comments and simplify register restore code.
Tested:
- On qemu can call x86_32 function and pass argument and return
value.
- Booted Lenovo X220 in x86_64 mode using x86_32 MRC.
Change-Id: I30809453a1800ba3c0df60acd7eca778841c520f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79752
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Remove pointers in argument list passed to MRC to make sure the struct
has the same size on x86_64 as on x86_32.
- Add assembly wrapper to call the MRC with argument in EAX.
- Wrap calling MRC in protected_mode_call_2arg, which is a stub on x86_32
Tested: Boots on Lenovo X220 using MRC in x86_32 and x86_64 mode.
Change-Id: Id755e7381c5a94360e3511c53432d68b7687df67
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
1. Set PCIe related GPIOs to NC if fw_config use "WIFI_CNVI".
2. Set CNVi related GPIOs to NC if fw_config use "WIFI_PCIE".
3. Remove "ALC5650_NO_AMP_I2S" case in
fw_config_gpio_padbased_override(). bt_i2s_enable_pads should not
relevant to audio codec/amp, and it is already enabled in "WIFI_CNVI"
case.
BUG=b:312099281
TEST=Build and test on karis
Change-Id: Ib1a32f1a38ae33cf992b80a3408aa8e2fa3ddab0
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79765
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
They always require special care so that line breaks and variable names
are escaped properly. One loop can be removed entirely because install
accepts multiple files to install in a target directories, the other
loops were filled by find which can just call the commands on its own.
Change-Id: I9f9dddfe3f3ceceb6a0510d6dd862351e4b10210
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79523
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements an API which relies on the
chromeos_get_factory_config() function to retrieve the factory
config value.
This information is useful to determine whether a ChromeOS device
is branded as a Chromebook Plus based on specific bit flags:
- Bit 4 (0x10): Indicates whether the device chassis has the
"chromebook-plus" branding.
- Bits 3-0 (0x1): Must be 0x1 to signify compliance with
Chromebook Plus hardware specifications.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: Iebaed1c60e34af4cc36316f1f87a89df778b0857
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This code leverages the TPM vendor-specific function
tlcl_cr50_get_factory_config() to fetch the device's factory
configuration.
BUG=b:317880956
TEST=Able to retrieve the factory config from google/screebo.
Change-Id: I34f47c9a94972534cda656ef624ef12ed5ddeb06
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch enables retrieval of factory configuration data from
Google TPM devices (both Cr50 and Ti50).
This patch utilizes vendor-specific command
TPM2_CR50_SUB_CMD_GET_FACTORY_CONFIG (68).
The factory config space is a 64-bit, one-time programmable.
For the unprovisioned one, the read will be 0x0.
BUG=b:317880956
TEST=Able to retrieve the factory config from google/screebo.
Change-Id: Ifd0e850770152a03aa46d7f8bbb76f7520a59081
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79736
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add `VBOOT_X86_RSA_ACCELERATION' Kconfig option to enable SSE2
instruction set implementation of modulus exponentiation which is part
of the RSA signature verification process.
BUG=b:312709384
TEST=Able to use SSE2 accelerated implementation on rex0
Change-Id: Ib6e39eb9f592f36ad3dca76c8eaf2fe334704265
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79289
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id c0cb4bfa:
2023-12-08 signer: sign_android_image.sh should die when image repacking fails
to commit id 7c3b60bb:
2023-10-13 firmware/2lib: Use SSE2 to speed-up Montgomery multiplication
This brings in 3 new commits:
7c3b60bb firmware/2lib: Use SSE2 to speed-up Montgomery multiplication
8bb2f369 firmware: 2load_kernel: Set data_key allow_hwcrypto flag
2b183b58 vboot_reference: open drive rdonly when getting details
6ee22049 sign_official_build: switch from dgst to pkeyutl
da69cf46 Makefile: Add support for make 4.3
Also update the implementations of the vb2ex_hwcrypto_modexp() callback
to match the API changes made in vboot.
Change-Id: Ia6e535f4e49045e24ab005ccd7dcbbcf250f96ac
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The FSP boot mode showing in serial log is a magic number.
In order to let user understand its meaning directly, add
the strings to describe the modes.
TEST=build, boot the device and check the logs:
without this change, the log is like:
[SPEW ] bootmode is set to: 2
with this change:
[SPEW ] bootmode is set to: 2 (boot assuming no config change)
Change-Id: I49a409edcde7f6ccb95eafb0b250f86329817cba
Signed-off-by: Marx Wang <marx.wang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Since we have chipset devicetrees for all SoCs that include this code in
the build, we can use the DEV_PTR macro instead of using
pcidev_path_on_root to get the device struct pointer. We can also use
the is_dev_enabled function instead of checking the value of the enabled
element of the device struct directly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5dcd92399e2d3f304352f2170dd3ef8761e86541
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79672
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since we have chipset devicetrees for both SoCs supported by the
Stoneyridge code, we can use the DEV_PTR macro instead of using
pcidev_path_on_root to get the device struct pointer. We can also use
the is_dev_enabled function instead of checking the value of the enabled
element of the device struct directly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifb787750ebc6aa2fef9d3be0e84e6afcffdc2ac1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79671
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This southbridge can route POST codes written to port 0x80 to either
LPC or PCI, but currently always route them to LPC. Change it so that
POST codes are routed to PCI if CONFIG(POST_DEVICE_PCI_PCIE) is
selected, LPC otherwise.
Rename the static function because POST codes no longer always go to
LPC.
Change-Id: I455d7aff27154d6821e262a21248e8c7306e2d61
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch follows the BWG recommendation (doc 729123) by clearing
the SPI SYNC_SS bit before disabling the WPD bit in
SPI_BIOS_CONTROL. This prevents boot hangs due to a 3-strike error.
Unable to follow this guideline would result into boot hang
(3-strike error).
BRANCH=firmware-rex-15709.B
TEST=Able to build and boot google/rex.
Change-Id: I18dbbc92554d803eea38ceb0b936a9da9191cb11
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Previous sleep state showing in serial log is a magic number.
In order to let users understand its meanings directly, add
the strings to describe the modes.
TEST=build, boot the device and check the logs:
without this change, the log is like:
[DEBUG] prev_sleep_state 0
with this change:
[DEBUG] prev_sleep_state 0 (S0)
Change-Id: Iabe63610d3416b3b6e823746e3ccc5116fabb17d
Signed-off-by: Marx Wang <marx.wang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78999
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
According to datasheet, EN_TCHSCR_PWR high --> SOC_TCHSCR_RST_R_L high
should over 5ms. And current measure result is 200us.
Set EN_TCHSCR_PWR to output high in bootblock to make it meet datasheet
requirment.
Measurement result of EN_TCHSCR_PWR high --> SOC_TCHSCR_RST_R_L high:
Power on --> 31.7 ms
Resume --> 38.7 ms
BUG=b:314245238
TEST=Measure the sequence
Change-Id: I56e455a980b465f27794b30df058ec0944befc2e
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79571
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The physical address size of the System-on-Chip (SoC) can be different
from the CPU physical address size. These two different physical
address sizes should be used for settings of their respective field.
For instance, the physical address size related to the CPU should be
used for MTRR programming while the physical address size of the SoC
should be used for MMIO resource allocation.
Typically, on Meteor Lake, the CPUs physical address size is 46 if TME
is disabled and 42 if TME is enabled but Meteor Lake SoC physical
address size is always 42. As a result, MTRRs should reflect the TME
status while coreboot MMIO resource allocator should always use
42 bits.
This commit introduces `SOC_PHYSICAL_ADDRESS_WIDTH' Kconfig to set the
physical address size of the SoC for those SoCs.
BUG=b:314886709
TEST=MTRR are aligned between coreboot and FSP
Change-Id: Icb76242718581357e5c62c2465690cf489cb1375
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79665
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some GPIOs were not configured correctly according to the HW
spreadsheet provided by the HW team.
* GPP_B5/GPP_B6 use NF1, not NF2
* GPP_B23 should use NF2, no GPI
* GPP_D11 should be set to NC
* GPP_E21/22 should be using NF (previous NC)
* GPP_F17 is a GPO
* GPP_F18 should be an interrupt, not a NF
BUG=b:300690448,b:316180020
BRANCH=NONE
TEST=emerge-brox coreboot
Change-Id: I9e1e62adb79bd7fdab935afdbf2d23f9061b88aa
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Did a pass through HW team's brox speadsheet and aligned the gpio.c
file with it. The changes in this CL include fixing the pulls for
GPIOs as necessary, making sure that it matches what is in the HW
team's spreadsheet.
BUG=b:300690448
BRANCH=NONE
TEST=emerge-brox coreboot
Change-Id: Ie50cb3c6fc85f1633c1afd1330c0e040e04b0ec1
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79704
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Did a pass through HW team's brox speadsheet and aligned the gpio.c
file with it. The changes here include changing the pad config to NC
because it is not being used in ChromeOS.
BUG=b:300690448
BRANCH=NONE
TEST=emerge-brox coreboot
Change-Id: I15471e4d7ff25c858b05ef024f15ca7c0b9e598e
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79703
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some of the boards use the EC_SYNC pin to wake the AP but do not
advertise the pin as wake capable in the CREC _CRS resource. Relevant
boards were determined through empirical testing and inspection of gpio
configuration.
Update the ACPI tables for rex, brya, and brox based boards to advertise
their EC_SYNC pin as wake capable.
BUG=b:243700486
TEST=-Dump ACPI and verify ExclusiveAndWake share type is set when
EC_SYNC_IRQ_WAKE_CAPABLE is defined
-Wake Aviko via keypress and verify chromeos-ec as wake source
-Wake Screebo via lid open and verify chromeos-ec as wake source
Change-Id: I5828be7c9420cab6ae838272c8301c302a3e078c
Signed-off-by: Mark Hasemeyer <markhas@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79374
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
SATA_IDE_DEVID, AHCI_DEVID_MS and AHCI_DEVID_AMD are still kept even
though they're unused at the moment, but those might still be useful to
keep around, since the SATA controller can have different PCI device IDs
depending on in which mode it is in.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia05683b732d9748d9198225acaecbd4dc196733a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
These IDs are not used as crashlog data is not stored in CBMEM now.
(Ref CL: I43bb61485b77d786647900ca284b7f492f412aee
Title: soc/intel/common,mtl: Refactor BERT generation flow for crashlog)
BUG=b:298234592
TEST=Able to build REX.
Change-Id: Ie38571dece89a995d582099d34f0a1dd57cb936f
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
With earlier flow, a chunk of CBMEM region was allocated for each SRAM
e.g., PUNIT SRAM, SOC PMC SRAM and IOE PMC SRAM. Then entire SRAM
content was copied to dedicated CBMEM region. Later in acpi_bert.c, the
BERT table was getting created for each chunk of CBMEM. This flow was
not considering creating separate entries for each region of crashlog
records. It resulted in only the first entry getting decoded from each
SRAM.
New flow aims to fix this issue. With new flow, a simple singly linked
list is created to store each region of crashlog records from all
SRAMs. The crashlog data is not copied to CBMEM. The nodes are
allocated dynamically and then copied to ACPI BERT table and then
freed. This flow also makes the overall crashlog code much simpler.
BUG=b:298234592
TEST=With this change decoding crashlog show comprehensive details,
tested on REX.
Change-Id: I43bb61485b77d786647900ca284b7f492f412aee
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78257
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The optimization of sleep time in acpi code includes reducing the sleep
duration and increasing the polling frequency within the acpi _ON/_OFF
method. StorageD3Enable is activated in Google/Rex, and this
optimization results in a saving of approximately 25ms in D3cold resume
time, reducing it from around 160ms to 135ms.
BUG=b:296206467
BRANCH=firmware-rex-15709.B
TEST=boot test verified on google/rex
verified _ON/_OFF Method in SSDT.
verifid kernel log in s0ix test -
0000:00:06.0: PM: pci_pm_resume_noirq
Change-Id: I7ba960cb78b42ff0108a48f00206b6df0c78ce7a
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79414
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Enable Acoustic noise mitigation for google/screebo and set slew rate
to 1/8 for IA domain and ignore the slew rate for SA domain.
BUG=b:312405633,
TEST=Able to build and boot google/screebo.
Before:
[SPEW ] AcousticNoiseMitigation : 0x0
[SPEW ] FastPkgCRampDisable for Index = 0 : 0x0
[SPEW ] SlowSlewRate for Index = 0 : 0x0
After:
[SPEW ] AcousticNoiseMitigation : 0x1
[SPEW ] FastPkgCRampDisable for Index = 0 : 0x1
[SPEW ] SlowSlewRate for Index = 0 : 0x2
Change-Id: Ib86939ab48c2c6e7d0491d7c1cb4a2c7c6a1b568
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79323
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Acoustic noise in PCBs is a common problem and be caused by a variety
of factors, including:
Mechanical vibrations, Electromagnetic interference (EMI) and/or Thermal
expansion.
This patch adds the UPDs to FSPM header file for mitigating the acoustic
noise.
FSPM:
1. AcousticNoiseMitigation
2. FastPkgCRampDisable
3. SlowSlewRate
BUG=b:312405633
TEST=Able to build and boot google/rex.
Change-Id: Iea0bfa2f92bb82e722ffc1a0b2f1e374b32e4ebc
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79301
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
As we look at unifying the format of coreboot code (/src, excluding
src/vendorcode), we need a code-beautifier configuration that works
well with the coreboot style. This patch is an attempt to match the
existing code styles as much as possible.
There are going to be some trade-offs in any code formatter. Tables
which have been hand-formatted probably won't look as good. These
can be specifically marked to be excluded from the formatter, however
this should be the exception, not the rule.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I70341d77e167c145f447594b6b0bef628cea83c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78832
Reviewed-by: Zebreus <lennarteichhorn@googlemail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PCH identification functions and `pch_iobp_update` are used in multiple
stages. Move them out of `pch.c` to drop some ugly preprocessor usage.
Subsequent commits will use `pch_iobp_update` in romstage as well.
Change-Id: I8d33338a4f74fd03c8f99f8fcece99b63c28adab
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79624
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This option is nowhere selected and there is only a single case left
where it's used. Guarding the check in pci_rom_load() seems like a
bad idea: As the code would be copying all VGA ROMs to the same
location, it would be only working by chance (if the last encoun-
tered ROM is the right one). Hence, drop the guard and always check
for the correct device.
Change-Id: Ib283bf0a65367b99099a3bfcbd27585d44235eb9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79596
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There's neither need to remove get_hw_mem_hole_info from the code if the
Kconfig option was set to 0 nor the actual value didn't make any
difference in the behavior of the code: When node_id has still its
initial value of -1, domain_read_resources won't use the value of
hole_startk, and when node_id is set to 0, get_hw_mem_hole_info also
sets hole_startk to the actual value that then gets used by
domain_read_resources.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ieffab695a3151ed7f6bf9d6c880bbb43eecf7893
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79609
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This APU is always a single-node, so the nodeid parameter of
get_node_pci is always 0. Since this SoC has a chipset devicetree, we
can just use DEV_PTR(ht_X) instead of the pcidev_on_root call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1bf9d214b4c2e5d995976fb79fef6fe43a6e9fa0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79608
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This APU is always a single-node and since we're in ramstage when
domain_read_resources gets called, there's DRAM on this node, so no need
to check for this. To be extra sure, also initialize basek and limitk
before calling get_dram_base_limit with pointers to those as arguments.
This won't be necessary for the code to work as intended, but will
probably keep the compiler from complaining. Also move the declaration
of basek, limitk and sizek to the beginning of the function.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4ef8011eb57b16218b8f5fea295900b855c3014b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79611
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This APU is always a single-node and also only has one DRAM controller,
so there is only one valid DRAM base and limit register. It's also worth
mentioning that the assumption made in get_dram_base_limit that the n-th
node is using the n-tn DRAM range register was valid for K8, but not
necessarily on newer generations than that.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0529c66e8d0e6c8eb42eec2c6d9d2e892287865
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79607
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This APU is always a single-node and also only has one DRAM controller,
so we don't need to loop over the different nodes to find the memory
hole below 4GB. We also don't need to check for the special case where
the memory hole is non-DRAM address space between the parts of the
address space decoded by different DRAM controllers.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9793d911d2d496be49168c06d83ceb802bc2b647
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79606
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This APU is always a single-node, so domain_read_resources only needs to
handle exactly one node and doesn't need to loop over the nodes.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4218077cb4e11b762ce0e8694a97bdec33eaa056
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This SoC only supports a single-node configuration, so all the code
related to multi-node support can be removed. In this commit only the
get_fx_devs function and related code are removed for better
reviewability. In f1_write_config32 it's no longer needed to loop over
the different devices of the different nodes, so only a single PCI
config space write remains.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5dc7324d3fcd0d07ac7a3a246a740fd9e91c3840
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79604
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This APU is always a single-node system and bits 4..6 of the node ID
register D18F0x60 are also marked as reserved in BKDG #52740 Rev 3.05.
On an APU2 board with quad-core APU, this register reads back 0x00030000
which results in a value of 1 to be returned from get_node_nums, so this
patch doesn't change behavior, but stops using reserved bits.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I65ed1124c0ca8e7eba54ff53dc626d35cd5e2e58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79603
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This system only has one northbridge and amd_initcpuio has already set
up the routing of the legacy VGA IO and MMIO ranges to it. Since only
the pci_dev_set_resources call remains in nb_set_resources, use
pci_dev_set_resources directly as set_resources function.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib3835db9fd83221ac2b8e34d998f938812d24413
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since the IOMMU is always function 2 of device 0 on bus 0, the device
operations can be statically assigned in the devicetree and there's no
need to bind the IOMMU device operations to the PCI device during
runtime via a list of PCI IDs.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I84e949500ee86e0fcb2d15791502f5e3e7127703
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79105
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Since the northbridge is always function 0 of device 0 on bus 0, the
device operations can be statically assigned in the devicetree and
there's no need to bind the northbridge device operations to the PCI
device during runtime via a list of PCI IDs.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia7faaa468ff77e05c378c5555622c3584cfe3f81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
With 1ms delay, reset is de-asserted too soon, before power is fully
up, causing a glitch to the reset signal. The issue is resolved with
4ms delay.
TEST=tested on google/jinlon device and observed the issue is resolved.
BUG=b:260253945
Signed-off-by: Eran Mitrani <mitrani@google.com>
Change-Id: I4efe916824cc193a7c2db7599b37f0d4de40bfce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79474
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Shelley Chen <shchen@google.com>
This patch provides a way to mask the 3-strike error on Intel
Meteor Lake SoC platform across pre-prod and prod SoC.
This patch decouples MSR selection for 3-strike error disablement, ensuring compatibility across SoC types.
Without the correct MSR been programmed the SoC platform is unable to disable 3-strike error.
BUG=b:314883362
TEST=Disable the 3-strike on google/screebo with QS silicon.
Change-Id: I5363102deea67c44c9433a3f66c92badb0d0f182
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79473
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When caching the ramstage for suspend/resume, we copy the entire image
as it resides in RAM. The last part of that, CONFIG_HEAP_SIZE bytes, is
the heap that will be reinitialized when the ramstage is started again.
As such, copying doesn't make sense and complicates HEAP_SIZE
configuration (because it needs to fit the space-constrained cache
location) and costs time and space. Therefore, skip the heap.
Side notes:
- When building with ASAN, program.ld indicates that it will allocate
some more space after the heap. This is not a problem, we just copy
an ASAN-sized copy of the heap.
- Heap use is managed in src/lib/malloc with statically allocated
variables. Because ramstage is cached before it's executed, these
values will be reset to their compile-time default values, too.
Change-Id: I6553dc8b758196f2476af2e692c0421d0fa2b98e
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79525
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The end-of-build targets weren't very granular previously, so warnings
could be lost instead of being printed at the end of the build.
This separates the end-of-build targets into 4 different groups, in this
order:
- build_complete: The coreboot build itself is done
- files_added: All files have been added to CBFS
- show_coreboot: Display any normal coreboot build messages
- show_notices: Display any warnings or notes
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia67446f164b8e66415a1a8c196999316fdf39f1e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79382
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
For initial debugging, we want to disable SW syncing. Will re-enable
in the future.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
run gbb_utility --get --flags <image>
make sure that it returns 0xa39
Change-Id: I865e9585ab37d1328a0ff54c6343cdad2c02220c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79569
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Keith Short <keithshort@chromium.org>
In commit 0a0945c6a2 (sio/nuvoton/npcd378: Use acpi_device_path_join),
some oversights were made. Instances of "strconcat(scope, ..." should be
replaced with "..._join(dev->bus->dev, ..." instead of "..._join(dev, ...".
On HP 8200 USDT, this fixes ACPI error like this on resume from S3:
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPCB.SIO0.L040.RMFG], AE_NOT_FOUND (20230628/psargs-330)
ACPI Error: Aborting method \_GPE._L08 due to previous error (AE_NOT_FOUND) (20230628/psparse-529)
ACPI Error: AE_NOT_FOUND, while evaluating GPE method [_L08] (20230628/evgpe-511)
RMFG seems to be a typo of PMFG made in that same commit.
Change-Id: Ifffa7ad72cfdb644c8b5147132a5fd56511ed33b
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79588
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Even though this mainboard is called 'Onyx', the openSIL implementation
and the corresponding coreboot integration is only a proof of concept
that isn't fully featured, has known limitations and bugs, and is not
meant for or ready to being productized. Adding the proof of concept
suffix to the name should point this out clearly enough so that no
potential customer could infer that this might be a fully functional
and supported implementation which it is not.
Change-Id: I157a8fffdc2a8543465fe8d444ac87f3f417389f
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77896
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The openSIL code for the Genoa SoC is only a proof of concept, so change
the name of the Kconfig option to include this code in the build from
SOC_AMD_OPENSIL_GENOA to SOC_AMD_OPENSIL_GENOA_POC to clarify that this
is code that isn't intended or ready to be productized.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If91cdaa7c324426964bba2de2109b6c38482fab8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79574
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Even though this SoC is called 'Genoa', the openSIL implementation and
the corresponding coreboot integration is only a proof of concept that
isn't fully featured, has known limitations and bugs, and is not meant
for or ready to being productized. Adding the proof of concept suffix to
the name should point this out clearly enough so that no potential
customer could infer that this might be a fully functional and supported
implementation which it is not.
Change-Id: Ia459b1e007dcfd8e8710c12e252b2f9a4ae19b72
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77894
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The default EPP is set at 50%, which is deemed insufficiently
aggressive for meeting the MTL performance expectations in
balance_performance mode.
# cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
balance_performance
# iotools rdmsr 0 0x774
0x0000000080003f06
EPP=45% is giving the required performance in MTL.
# iotools rdmsr 0 0x774
0x0000000073003d06
NOTE: Kernel changes are necessary to ensure that the EPP (Energy Performance Preference) configured in the BIOS is not overwritten: https://patchwork.kernel.org/patch/13461932
BUG=b:314275133
TEST=Build and boot.
Change-Id: I1953994cdb4e9363fdd4b4728e3e5236276c06c8
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79386
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit lays the groundwork for implementing the ACPI WDAT (Watchdog
Action Table) table specification. The WDAT is a special ACPI table
introduced by Microsoft that describes the watchdog for the OS.
Platforms that need to implement the WDAT table must describe the
hardware watchdog management operations as described in the
specification. See “Links to ACPI-Related Documents”
(http://uefi.org/acpi) under the heading “Watchdog Action Table”.
BUG=b:314260167
TEST=Mock the acpi_soc_fill_wdat function for a specific platform/soc
and enable ACPI_WDAT_WDT in the kconfig. Check if the build passes
successfully.
Change-Id: Ieb82d1f69b2b7fffacfd2928bc71f8ff10498074
Signed-off-by: Marek Maslanka <mmaslanka@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
FSP default value for LpDdrDqDqsReTraining is 1. For boards
that didn't set LpDdrDqDqsReTraining to any value, 0 was being
assigned and it caused black screen issue.
BUG=b:302465393
TEST=Boot to OS with debug FSP, check LpDdrDqDqsReTraining = 1
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I301a6e43f2944ffbc63431393378ab8b23450032
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch introduces a new API to disable signaling the 3-strike event
on Intel Meteor Lake C0 (QS) stepping and subsequent SoCs. This is
necessary because the existing event handling mechanism is incompatible
with the new hardware design.
Disabling the 3-strike event registration prevents the 3-strike count
from increasing, which addresses bug b:314883362. This issue can potentially lead to system instability.
BUG=b:314883362
TEST=disabling the 3-strike event on a Google Screebo system with QS silicon.
Change-Id: I15bd5a93da34d7f2a127c21c4cd8b5952926bccf
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79472
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FSP default value for LpDdrDqDqsReTraining is 1. For boards
that didn't set LpDdrDqDqsReTraining to any value, 0 was being
assigned and it caused black screen issue.
BUG=b:302465393,b:315739133
TEST=Boot to OS with debug FSP, check LpDdrDqDqsReTraining = 1
Change-Id: I5d61301fddac6630bb1c48e992dd76e5cf02a272
Signed-off-by: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79533
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Previously ramdetect.c was compiled only for VENDOR_EMULATION.
Hence add Kconfig option PROBE_RAM which allows board outside
the scope of VENDOR_EMULATION to select and utilize probe_ram
function to runtime detect usable RAM in emulation environment.
PROBE_RAM is default selected if VENDOR_EMULATION is set so
that existing boards under VENDOR_EMULATION scope are not
affected.
Other boards can explicitly select PROBE_RAM to use probe_ram.
TEST=Build mb/arm/rdn2 with PROBE_RAM selected & make sure
there is no any error.
Also checked qemu-aarch64 build to make sure build is success.
Change-Id: Id909ddaee6958cfa8a6c263a11f9a90d94710aa7
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79450
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Updating from commit id db533497:
2023-12-05 20:09:44 +0000 - (host/lib/pkcs11: Remove superfluous 'nss' directory from include paths)
to commit id c0cb4bfa:
2023-12-08 09:14:32 +0000 - (signer: sign_android_image.sh should die when image repacking fails)
This brings in 3 new commits:
c0cb4bfa signer: sign_android_image.sh should die when image repacking fails
30e37712 tlcl: Add `TlclCreatePrimary()` support
12fa13e3 2api: Add firmware & kernel PCR support
Change-Id: I354c1d07c3b506069d5b64bc2fc476dadc36e0e2
Signed-off-by: Yi Chou <yich@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79484
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To quote its repo[0]: Wuffs is a memory-safe programming language (and
a standard library written in that language) for Wrangling Untrusted
File Formats Safely. Wrangling includes parsing, decoding and encoding.
It compiles its library, written in its own language, to a C/C++ source
file that can then be used independently without needing support for
the language. That library is now imported to src/vendorcode/wuffs/.
This change modifies our linters to ignore that directory because
it's supposed to contain the wuffs compiler's result verbatim.
Nigel Tao provided an initial wrapper around wuffs' jpeg decoder
that implements our JPEG API. I further changed it a bit regarding
data placement, dropped stuff from our API that wasn't ever used,
or isn't used anymore, and generally made it fit coreboot a bit
better. Features are Nigel's, bugs are mine.
This commit also adapts our jpeg fuzz test to work with the modified
API. After limiting it to deal only with approximately screen sized
inputs, it fuzzed for 25 hours CPU time without a single hang or
crash. This is a notable improvement over running the test with our
old decoder which crashes within a minute.
Finally, I tried the new parser with a pretty-much-random JPEG file
I got from the internet, and it just showed it (once the resolution
matched), which is also a notable improvement over the old decoder
which is very particular about the subset of JPEG it supports.
In terms of code size, a QEmu build's ramstage increases
from 128060 bytes decompressed (64121 bytes after LZMA)
to 172304 bytes decompressed (82734 bytes after LZMA).
[0] https://github.com/google/wuffs
Change-Id: If8fa7da69da1ad412f27c2c5e882393c7739bc82
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Based-on-work-by: Nigel Tao <nigeltao@golang.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78271
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Early versions of CB:76519 had more devices enabled in the chipset
devicetree which shouldn't necessarily be enabled in the chipset
devicetree. Enable most of those in the Onyx mainboard's devicetree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ieeb96755a007a5ca70e4c31df09325835bb8ef47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Add the device and chip entries for the various PCIe ports and MPIO
lane configuration. Below each PCIe bridge device with an external PCIe
port on the mainboard, an MPIO chip is added that provides the
corresponding MPIO configuration for this external PCIe port.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8563c5a07eb8fd8ff9dd4e7b63fc9a7d485b1316
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78921
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When using the --skip_set and --skip_unset arguments, the config line
looked like a statement that the build was being skipped instead of
abuild just printing the configuration.
This updates those config statements to better show that it's the
config and not stating that this particular build is being skipped.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I6cc59f9b33dcda51aeb3640d449037a0aa054e36
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76936
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
The ACPI spec defines keywords for the GpioInt and Interrupt resources
to specify whether a given pin is wake capable. Some boards are using
the ec sync interrupt pin to wake the system so the CREC _CRS needs to
be updated accordingly.
Provide a new macro that allows a board to specify whether its ec sync
pin is wake capable.
BUG=b:243700486
TEST=Dump ACPI and verify ExclusiveAndWake share type is set when
EC_SYNC_IRQ_WAKE_CAPABLE is defined
Change-Id: I483c801ff0fee4d3ce0a3b2fc220e0bd9356a612
Signed-off-by: Mark Hasemeyer <markhas@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Forest Mittelberg <bmbm@google.com>
Drive board specific USB configuration from the coreboot devicetree into
the opensil input block.
Add USB OC pins to chipset.cb
In the process of scrubbing opensil for public release USB became non
functional.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I506547a7abbb643d3e982e44a92f33b45cd739e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
If a framebuffer is already configured by coreboot, we need to ensure
that the framebuffer size is a multiple of GRANULE_SIZE before passing
to `mmu_add_memrange`. Otherwise, we would fail to allocate memory
region due to `sanity_check`.
Change-Id: Ia6a6400733ca10a61220087e87022f68c28e4789
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79451
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Return the PCI segment group number from data_fabric_get_pci_bus_numbers
via pointer argument so that amd_pci_domain_scan_bus can handle the PCI
segment group numbers once coreboot supports more than one PCI segment
group. For now, just print an error and return if the buses are on a PCI
segment group other than 0.
TEST=Mandolin still boots
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia53cda0ba656201c2197d05bc0d4a8fbbe8ad5d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This patch records early signs of user activity during CSE firmware
synchronization or MRC (re)training events in the event
log (ELOG_TYPE_FW_EARLY_SOL).
These can be used to ensure persistence across global reset (e.g. after
CSE sync) so that they can be later retrieved in order to build things
such as test automation ensuring that we went through the SOL
path/display initialized.
BUG=b:279173035
TEST=Verified on google/rex, event shows in eventlog after CSE sync
and/or MRC.
Scenario #1: While performing MRC update
1 | 2023-11-08 | Early Sign of Life | MRC Early SOL Screen Shown
2 | 2023-11-08 | Memory Cache Update | Normal | Success
3 | 2023-11-08 | System boot | 9
4 | 2023-11-08 | ACPI Wake | S5
Scenario #2: While performing CSE update/downgrade
11 | 2023-11-08 | Early Sign of Life | CSE Sync Early SOL Screen Shown
12 | 2023-11-08 | System boot | 13
Scenario #2: While performing both MRC and CSE upgrade
16 | 2023-11-08 | Early Sign of Life | MRC Early SOL Screen Shown
17 | 2023-11-08 | Early Sign of Life | CSE Sync Early SOL Screen Shown
18 | 2023-11-08 | Memory Cache Update | Normal | Success
19 | 2023-11-08 | System boot | 16
20 | 2023-11-08 | ACPI Wake | S5
Change-Id: Idfa6f216194fd311bb1a57dd7c86fe7446a3597c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78983
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Meteor Lake Firmware Support Package (FSP-M) for ChromeOS includes an
pre-memory graphics driver which can be leveraged to display a text
message thanks to the following FSP-M UPD (Updateable Product Data):
- VgaInitControl (bitfield):
Bit 0: Turn on graphics, setup VGA text mode and display
`VgaMessage' text centered on the screen.
Bit 1: Clear text and tear down VGA text mode and graphics before
returning from FSP-M.
- VbtPtr (address): Pointer to the VBT (Video BIOS Tables) binary.
- VbtSize (unsigned int): Size of the VBT binary.
- LidStatus (boolean): Due to limited resources at early boot stages,
the text message is displayed on a single monitor. The lid status
helps decide which display is the most appropriate.
0: Lid is closed: show the text message on the external display if
available, do not display anything otherwise.
1: Lid is open: show the message on the internal display if
available, use an external display if available otherwise.
- VgaMessage (string): Text message to display.
If the `SOC_INTEL_METEORLAKE_SIGN_OF_LIFE' flag is set, coreboot
configures the UPDs above to display a text message during memory
training and CSME update. The text message can be configured via the
locale text mechanism using the `memory_training_desc' name.
The `SOC_INTEL_METEORLAKE_SIGN_OF_LIFE' selects the LZ4 compression
algorithm for VBT because LZMA decompression is not available in
romstage by default and adding LZMA support increases the romstage
binary size more than the VBT binary is reduced.
BUG=b:279173035
TEST=Text message is displayed during memory training on a rex board
Change-Id: I8e7772582b1895fa8e38780932346683be998558
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78244
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch adds a function to check if a CSE FW update is required
during this boot. The function is expected to be used during use
cases like Pre-Memory Sign of Life text display to inform user of
a CSE Firmware update.
Bug=279173035
TEST=build and boot on google/rex board. Call the function in romstage
and confirm it returns True during CSE FW update and False otherwise
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: If5fae95786d28d586566881bc4436812754636ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78243
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
vboot_fw.a is built via a sub-invocation of make, but make is not able
to track dependencies between different invocations. That means the
toplevel make assumes that the vboot_fw.a target depends only on the
dependencies explicitly listed in coreboot's Makefile (only config.h in
this case), and thus assumes that if config.h didn't change it does not
need to rebuild the library. This breaks incremental builds when files
inside the vboot repository change.
This patch marks the target as .PHONY so that it will always be rebuilt.
The vboot Makefile's own dependency tracking will then ensure that on an
incremental build we only rebuild the vboot sources that actually
changed, so if nothing changed this will just add a simple and quick
$(AR) call.
Change-Id: I8bdd4e1589124914ba1e877e04b40ee709ea4140
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79375
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updated Linux FW works with PCI gen3 speed and PSPP.
This reverts
commit 05c9a850fd ("mb/google/nipperkin: Fix WLAN to GEN2 speed")
https://review.coreboot.org/c/coreboot/+/63593
and
commit 76fddd9639 ("mb/google/nipperkin: Disable PSPP for WLAN")
https://review.coreboot.org/c/coreboot/+/63722
The changes are overlapped and are reverted together.
BUG=b:240426142 & b:228830362
The system is able to ran over 2500 cycles on Nipperkin with command
suspend_stress_test -c 10000 --wake_min 10 --suspend_min 10 \
--nofw_errors_fatal
The whole variant_update_dxio_descriptors is empty and is pushed back
to weak function.
Change-Id: Id207076542edc8ea0cabc6e02e29856c2b6803c7
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
The device/device.h provides the definition for struct device used in
those files, so include this header file to make sure that it's not only
included indirectly via some other header file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6ff7cdbf0f53ada92adb53cf268e5feee9df4629
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Updating from commit id 6788bb0:
2023-08-08 12:04:21 -0600 - (microcode-20230808 Release)
to commit id ece0d29:
2023-11-14 10:19:09 -0600 - (microcode-20231114 Release)
This brings in 1 new commits:
ece0d29 microcode-20231114 Release
Change-Id: I1d65318015803d5ca11dcf52e4011f49cf3129a1
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Updating from commit id ba7fd22d:
2023-11-29 01:50:20 +0000 - (Makefile: Always link libdl)
to commit id db533497:
2023-12-05 20:09:44 +0000 - (host/lib/pkcs11: Remove superfluous 'nss' directory from include paths)
This brings in 4 new commits:
db533497 host/lib/pkcs11: Remove superfluous 'nss' directory from include paths
3307f1a7 tlcl: Add `TlclEvictControl()` support
0bd01137 tlcl: Remove the redundant bytes in TlclReadPublic
9afdf0f2 sign_official_build.sh: stop messing with +x
Change-Id: Ib2ded699605dfa4032f4687e1e336297c0af1372
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Integration for additional container images might be added to the
Makefile at some later point. However, in order to build and test new
images just add a simple script which fulfills that requirement until
then.
Change-Id: Ibd0a6d59f395e074c784452849650d7f03b4f1d8
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79361
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
- First a console is set up for opensil.
- After that a region in CBMEM is reserved and passed to opensil which
will use it as a buffer for input/output information.
- Finally opensil is called and the return value handled.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4833a5a86034a13e6be102a6b68c3bb54108bc9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Since the EHCI controllers in the PCH are always on the same device
functions, the device operations can be statically assigned in the
devicetree and there's no need to bind the EHCI device operations to the
PCI devices during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I92ecc3607216fb2f31639db9628898c9ce81770d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79171
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Since the XHCI controller in the PCH is always on the same device
function, the device operations can be statically assigned in the
devicetree and there's no need to bind the XHCI device operations to the
PCI device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8685bec734415346a53330c9bd1aa82986995f1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79170
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Since the PCI bridge in the PCH is always on the same device function,
the device operations can be statically assigned in the devicetree and
there's no need to bind the PCI bridge device operations to the PCI
device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic9ca925a12e64c9a5b3bf295653bf032572ff29a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79169
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since the SMBus controller in the PCH is always on the same device
function, the device operations can be statically assigned in the
devicetree and there's no need to bind the SMBus device operations to
the PCI device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3d3745ba5aefa30efbe705155d216aa7eadd26a7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79168
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Function 0 of the device that has the bridges to other buses is a dummy
function that can be left enabled to not have to shuffle around the
device function numbers when the first PCI bridge on that device isn't
enabled. That dummy device function is however not a PCI host bridge, so
change the comment from 'Dummy Host Bridge' to 'Dummy device function'.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6069205bd2e1cb0f75025e9f330afc50462e742a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79397
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Function 0 of the devices that have the bridges to other buses are dummy
functions that can be left enabled to not have to shuffle around the
device function numbers when the first PCI bridge on those devices isn't
enabled. Those dummy device functions are however not PCI host bridges,
so change the comments from 'Dummy Host Bridge' to 'Dummy device
function'.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ibddfdf558d84bc44434d718b86f41bd06044b22a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Since the LPC bridge in the PCH is always on the same device function,
the device operations can be statically assigned in the devicetree and
there's no need to bind the LPC bridge device operations to the PCI
device during runtime via a list of PCI IDs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I366226be4aba75b98e45e4832bfe129fac14dbfa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Fix up the memory config for brox based on the schematics. Also,
since memory training needs to happen in romstage, initializing the
MEM_STRAP & MEM_CH_SEL gpios for use in romstage. Also consolidating
the GPIOs needing to be initialized in romstage into the baseboard
gpio.c file.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I17615cda7df10e73e49fb49f736728787ef7625d
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Building the Lenovo T60/T60p, iasl 20230628 shows the remark below:
dsdt.asl 2099: PowerResource (FPwR, 0, 0)
Remark 2182 - ^ At least one lower case letter found in NameSeg, ASL is case insensitive - converting to upper case (FPWR)
dsdt.asl 2118: Name (_PR0, Package () { FPwR })
Remark 2182 - ^ At least one lower case letter found in NameSeg, ASL is case insensitive - converting to upper case (FPWR)
Address it by making it all upper case.
Change-Id: Ia7924b015e76c43818d2d82da35ce0013d721c26
Fixes: 3ab13a8691 ("ec/lenovo/h8/acpi/thermal: Add support for passive cooling")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79367
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update BND_NORTH_APB2_S's domain 5 permission to allow the access from
APU. The APU requires certain information saved in BND_NORTH_APB2_S for
voltage tuning. If this information cannot be retrieved, the APU may
operate at a high frequency with low voltage. Consequently, the APU may
not function as expected.
Change-Id: I967b138dc5517e54da7fbf94b9e502e478c991b5
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79348
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For ChromeOS platform the recovery reason is cleared in
vb2api_kernel_phase2 which is probably not called by any non-ChromeOS
system. It results in the platform being stuck in recovery mode, e.g.
when RW firmware verification fails. Even if the RW partition is
flashed with correctly signed image, the persistent non-zero recovery
reason will prevent vboot from attempting the RW partition check.
Use the newly exposed vb2api_clear_recovery and
VBOOT_CLEAR_RECOVERY_IN_RAMSTAGE Kconfig option to clear the recovery
reason and save it immediately to the VBNV. The idea is to let
non-ChromeOS coreboot platform to clear the recovery reason when
needed.
TEST=Clear the recovery reason in mainboard_final function right
before payload jump when RW partition is corrupted and RW partition is
valid. In case it is corrupted, the platform stays in recovery mode,
when valid the platform boots from RW partition. Tested on MSI PRO
Z690-A DDR4.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I7ffaf3e8f61a28a68c9802c184961b1b9bf9d617
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74343
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the power limit configuration for MCH ID index 3 aka
0x7d14 DID which is identical to MCH ID 0x7d01 (index 1).
TEST=Able to perform power limit configuration for google/ovis.
[DEBUG] WEAK: src/mainboard/google/rex/variants/baseboard/ovis/
ramstage.c/variant_devtree_update called
[INFO ] Overriding power limits PL1 (mW) (19000, 28000)
PL2 (mW) (64000, 64000) PL4 (W) (120)
Change-Id: Iff71adb4e26d18970b5947927c258419f751de32
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79332
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch removes the deprecated PL_PERFORMANCE and PL_BASELINE
configurations, relying instead on the refactored power limit flow.
This flow allows for seamless overrides by the baseboard and/or by
the variant board, if necessary.
Specifically, this patch:
- Removes PL_PERFORMANCE and PL_BASELINE configuration options from
mainboard.c in the google/rex directory.
- Relies on the baseboard_devtree_update() function, which is
implemented by the respective baseboard, to handle power limit
configuration.
- Leverages the variant_devtree_update() function, which is a
__weak implementation, to allow overrides by the variant directory.
This simplification improves code readability and maintainability while
maintaining the flexibility to handle power limit configurations as
needed.
Change-Id: I872e5cb59d7b2789ef517d4a090189785db46b85
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79331
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the LidStatus UPD is passed a dynamic value,
rather than always passing 1 (CONFIG_RUN_FSP_GOP enabled) for FSP 2.0
devices.
Problem statement:
* FSP-S GFX PEIM initializes the on-board display (eDP) even when the
LID is physically closed, because LidStatus is always set to 1.
* FSP-S skips external display initialization even when the LID is
closed.
Solution:
* FSP-S GFX PEIM module understands the presence of an external display
if LidStatus is not set, and tries to probe the other display
endpoint.
* Statically passing LidStatus as always enabled (aka 1) does not
illustrate the exact device scenarios, so this patch updates
LidStatus dynamically by reading the EC memory map offset.
BUG=b:313886118
TEST=Able to build and boot google/marasov to redirect the display
using external HDMI monitor while LID is closed.
Change-Id: Idb1d71bd54837630f36d43a45effc53d35f9cb70
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79352
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds code to generate Processor Properties
Topology Tables (PPTT) compliant to the ACPI 6.4 specification.
- The 'acpi_get_pptt_topology' hook is mandatory once ACPI_PPTT
is selected. Its purpose is to return a pointer to a topology tree,
which describes the relationship between CPUs and caches. The hook
can be provided by, for example, mainboard code.
Background: We are currently working on mainboard code for qemu-sbsa
and Neoverse N2. Both require a valid PPTT table. Patch was tested
against the qemu-sbsa board.
Change-Id: Ia119e1ba15756704668116bdbc655190ec94ff10
Signed-off-by: David Milosevic <David.Milosevic@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch expands the power limit override capability to include
variants directories, enabling them to modify power limit settings
configured by the baseboard.
Previously, only the baseboard could override power limit settings.
For instance, while the google/rex baseboard sets the PL1 max power
limit to 15W, the google/screebo variant couldn't override this value.
This enhancement empowers variants directories to override baseboard-
configured power limit settings, allowing for greater flexibility and
control over power limits.
BUG=b:313667378
TEST=Able to call into _weak implementation of `variant_devtree_update`
unless there is one override.
[DEBUG] WEAK: src/mainboard/google/rex/variants/baseboard/rex/
ramstage.c/variant_devtree_update called
[INFO ] Overriding power limits PL1 (mW) (10000, 15000) PL2 (mW)
(40000, 40000) PL4 (W) (84)
Change-Id: Ib07691625e075b0fbab42271512322ffc60ba13b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79329
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The Microsoft Debug Port Table 2 (DBG2) specification says that the
serial port subtype 0x00 should only be used for I/O-mapped 16550
compatible UARTs. The subtype 0x12 is a superset of that, and supports
specifying MMIO vs IO and the register access size via the generic
address structure. Rename the subtype 0x00 definition to
ACPI_DBG2_PORT_SERIAL_16550_IO_ONLY and add the subtype 0x12 definition
as new ACPI_DBG2_PORT_SERIAL_16550, so that the acpi_write_dbg2_uart
function will write the correct subtype for the generic 16550 UART.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I816bb22e6f76e661c8b8e39a2a4cb83b0085acb5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79219
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Inteltool is GPLv2 licensed so all files that link to it should be GPLv2
by default. In addition, the contents of several of these headers were
originally moved directly from gpio_groups.c, which is explicitly marked
as GPL-2.0-only.
Change-Id: Ie897cb238c0c9e89fe677c999cbf1803f5f4609a
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
We should make sure _stack/_estack and the other labels are consistent.
And _data & _edata is also useful to clean up the sensitive data on the
data section.
BUG=b:248610274
TEST=emerge-cherry libpayload
BRANCH=none
Cq-Depend: chromium:5052462
Change-Id: I589040f4db60b35813ea9f4ba9503244bd7def00
Signed-off-by: Yi Chou <yich@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79144
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Brox has SSD and UFS storage per different SKU.
1. Set SSD on CPU PCIe port (PCIEX4_A) and configure related gpio
settings according to the schematic.
2. Enable UFS, also enable ISH since it is PCI function 0, required
for UFS function 7 to be enabled.
3. Set unused SRCCLKREQ signals to NC.
4. Remove unused gpio settings in variant gpio table to prevent
unexpected overrides.
BUG=b:311450057
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I88922bcfa13652006aa10078c3c444624fd4575e
Signed-off-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79295
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The "config" targets exist to edit the .config file, and so they
should be more forgiving with invalid configs (that they'll convert
into valid configs on save). They will still emit warnings about
invalid symbols, but not exit with an error.
The regular build process still fails if the .config looks unexpected
(for example when there's an unknown config flag).
Change-Id: If427e075766c68d493dd406609f21b6bb27d1d74
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79298
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Updating from commit id f2b01bf0:
2023-10-27 Julius Werner firmware: Undeprecate VB2_RECOVERY_FW_GET_FW_BODY
to commit id ba7fd22d:
2023-11-27 Julius Werner Makefile: Always link libdl
This brings in 54 new commits:
ba7fd22d Makefile: Always link libdl
1b30d195 sign_official_build: sign_update_payload with pkcs11
ca7a1427 sign_firmware: support loem key config
a9623573 sign_official_build: add keys to default key config
d41497dc sign_official_build: support loem key config
da2450db sign_official_build: support sign with .vbprik2 files
ee326142 getversion: Make reproducible
8aaf9e32 futility: fix a typo in help message of `read`
9ce505f4 futility: Fix incorrect warning about signing length
23a0ce4e scripts: add lib/keycfg.sh
2e34330b Makefile: Fix firmware build for FIRMWARE_ARCH=arm64
fd5937d1 tests/futility/test_show_and_verify: Add test cases for invalid data key
00aa0626 futility/cmd_vbutil_kernel: Drop --pad option for --verify
c661ab76 futility/cmd_show: Drop --pad option
c70511d7 tests/futility/test_show_and_verify: Add test cases for kernel vblocks
c9100f46 signer: Use compression flags stored in the metadata file
f1f3076f vboot: Add vb_keyb_from_private_key
c39a2fc1 host: support signing with pkcs11 key for vbprik2
c6d44076 vboot: merge reading function of vb2/vb21 private key
6b8e759f vboot: replace custom prefix "pkcs11" to "remote"
481440d0 futility: Prefer to flash over CCD instead of C2D2
1244c06f futility/cmd_dump_fmap: Print an error if FMAP header not found
cab69289 futility/cmd_show: Fix parseable output for kernel preamble flags
71a03dc6 futility/cmd_show: Make preamble parseable output consistent
bdac62a4 futility/cmd_show: Make 'show' return 0 for invalid kernel body
135df2d7 futility/cmd_show: Show parseable "keyblock::valid" for valid keyblock
37f37fcd futility/cmd_show: Fix output for firmware body signature
79c244ff tests/futility/test_show_and_verify: Add test cases for bios_brya_mp.bin
d4b6560f signer: Update mkfs.erofs pcluster value to 32K
f79a2432 futility/cmd_sign: Fix a space in usage text
a307fcb5 futility: updater: rename --ccd to --ccd_without_servod
6b9f66d3 futility: updater: Fix malloc overflow due to broken keyblock
a94a784c updater: update: Support multiple Servos without --servo_port
25875bef tests/futility: Add test cases for VBOOT_CBFS_INTEGRATION
5f8e3973 futility/cmd_show: Fix typo "metatadata"
9d30a01f futility: Trim trailing spaces in kernel config
c59794a6 sign_uefi: Support signing via pkcs11
68d4aa4b sign_uefi: Skip private key check if it's a pkcs11 URI
6b9d624b sign_uefi: Pass each key path separately
483f65e4 sign_official_build.sh: properly show errors on loem issues
516ee7bc sign_uefi: Use named args instead of positional
0eec8e25 vboot_reference-sys: Switch from Command to bindgen::Builder
46f5aab8 image_signing: support multiple release names
f13af139 sign_official_build: Sudo invocation within bits of android signing
3f165374 futility: updater: Add optional serial number argument to --ccd
64379cc6 sign_official_build: add --debug flag
7160bf9f 2lib: Fix relocation issue when compiling locally with musl libc
0e27cdff vboot_reference-sys: Add vboot_host.h
2c82e73c Override use_apksigner FLAGS
b43469c7 futility/cmd_show: Support --publickey FW_VBLOCK
0eb4da96 tests/futility: Update kern_preamble.bin as kernel_part.bin
68a03355 tests/futility: Move test_show_vs_verify.sh into test_show_and_verify.sh
8daf1474 tests/futility: Move 'futility show' tests to a separate file
34190e3d futility: Exit with error when metadata hash verification not supported
967aa462 firmware/2lib: Fix function comment for vb2api_get_firmware_size()
Change-Id: I58b231d53f433a396b1ea8cd4e0ddc49a310e385
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79313
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
Updating from commit id 88b2d8134:
2023-09-06 11:26:32 +0200 - (Merge "fix(scmi): add parameter for plat_scmi_clock_rates_array" into integration)
to commit id e7486343d:
2023-11-28 22:48:16 +0100 - (Merge changes from topic "xlnx_fitimage_check" into integration)
This brings in 451 new commits.
Change-Id: I75a89c6f0d60ccccd8ff42954416666dabef717f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Since lars has two touchscreen options, we need to determine which (if
any) are present on a given device at runtime so that there are not
multiple ACPI touchscreen devices (as it makes Windows unhappy).
Implement power sequencing and runtime detection for both touchscreen
options.
TEST=build/boot Win11/Linux on google/lars, verify touchscreen detected
and functional under both OSes.
Change-Id: I49ccb29ec4589315a4abe3c0ea8fa76f97080bcd
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
LARS has a Melfas touchscreen option, so add an entry for it. Adapted
from Chromium branch firmware-glados-7820.315.B, commit a26fe552569f
("Chell: Update DPTF parameters for CPU").
TEST=build/boot Linux on google/lars with Melfas touchscreen, verify
functional.
Change-Id: Idecd572335d7d5d52e4f89e85ebf7f0c90f23751
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79310
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The address space of possible SPD-EEPROMs 0x50..0x53 on the SMBus
interface is per default write-protected in FSP. This avoids that an
SPD-EEPROM on a DRAM module gets overwritten by the host.
On mc_ehl1, memory-down configuration is used and there is no SPD EEPROM
available. Nevertheless, there is a general purpose EEPROM on the same
address available which needs to stay writeable.
This patch disables the default-enabled write protect feature for the
SPD-EEPROM addresses just for mc_ehl1.
Test=Boot into Linux and make sure a write access into the EEPROM is
possible.
Change-Id: I6b0fcdbeb0dbf971cfdceb70d6f4845765a3bdb6
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Anraggar cannot boot into OS and kernel loading failure.
Update eMMC DLL values to improve initialization reliability
- Sending different speed TX/RX command/data signal to eMMC and check
the response is success or not.
- Collecting every eMMC that use for the project
- Based on above result to provide a fine tune DLL values
BUG=b:308366637
TEST=Cold reboot stress test over 2500 cycles
Change-Id: I9ec3cc23000301aa72aed96e74b63114623c4fc2
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78851
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
As customer demand, it is necessary to set MSR Package Power Limit-1 to 17W for the DTT setting to optimize performance.
The PL1 value (17W) suggested by the thermal team which is different from the reference code(PL1=15W).
BUG=b:312321601
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot chromeos-bootimage
Built and booted into OS, and confirm MSR PL1=17W correctly.
Change-Id: If7874d26038118c5605cf0721c30e681b45123fe
Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79335
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Daniel Peng <daniel_peng@pegatron.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch moves the SOC_INTEL_STORE_ISH_FW_VERSION config from the
Nissa baseboard to BOARD_GOOGLE_BRYA_COMMON. This allows all baseboards
to retrieve the ISH version and store it into memory.
Ensure SOC_INTEL_STORE_ISH_FW_VERSION is enabled only for platforms
with ISH support (DRIVERS_INTEL_ISH).
Additionally, the dedicated SOC_INTEL_STORE_ISH_FW_VERSION config
selection for the Nissa baseboard is no longer needed.
BUG=b:280722061
TEST=Able to build and boot google/marasov.
Change-Id: I99dab43ae4e13869b7f8797a9c4014f60e38a595
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79338
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Earlier entire SPI ROM was mapped to memory. With limited TLB resources
in PSP, this approach hit the limit on systems using 32 MiB SPI ROM.
Therefore regions in SPI ROM were mapped on need basis. This works well
on Picasso, Mendocino and Phoenix SoCs. But unfortunately this causes
boot hangs in Cezanne SoC. Add a configuration to map the entire SPI ROM
and enable it in Cezanne SoC. For other SoCs, keep the configuration
disabled so that only the required SPI ROM region is mapped.
BUG=b:309690716
TEST=Build and boot to OS in both Dewatt and Skyrim.
Change-Id: I166ac7b50b367c067e1a743fc94686e69dd07844
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79155
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Updating from commit id e4519efca746 (2023-11-15):
Revert "picasso: Update PSP binaries to release 0.8.13.7B"
to commit id 68ebd4b567f4 (2023-11-27):
PCO: Update ABL to version CABLRV21080200
This brings in 1 new commit:
68ebd4b567 PCO: Update ABL to version CABLRV21080200
Change-Id: I4cf528c2d2489782758d2e16ea9201324c466919
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Drop code that puts Super I/O into config mode, select serial device,
then leave config mode right away having done nothing.
I'll also take this chance to revise its #includes based on
include-what-you-use results.
Change-Id: I304fc1610740375b59121b6b8784122440795838
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73693
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Board was not producing serial output until well into ramstage.
To fix, select SUPERIO_NUVOTON_COMMON_COM_A Kconfig to tell
nuvoton_enable_serial() to route serial port A signals to the outside,
not GPIO8x.
TEST=Full native raminit debug log received over serial by minicom.
Change-Id: I376a79dd76ffa5f4d47e7c0cb53680e173e1ad78
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79222
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Upstream reimplemented KCONFIG_STRICT, just calling it KCONFIG_WERROR.
Therefore, adapt our build system and documentation. Upstream is less
strict at this time, but there's a proposed patch that got imported.
TEST=`util/abuild/abuild -C` output (config.h and
config.build) remains the same. Also, the failure type fixed in
https://review.coreboot.org/c/coreboot/+/11272 can be detected,
which I tested by manually breaking our Kconfig in a similar way.
Change-Id: I322fb08a2f7308b93cff71a5dd4136f1a998773b
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Now that the 4.22 release tag has been added to git, update the release
notes with the final statistics and wording.
We also decided to add a fix submitted immediately after the 4.22
release was tagged into the release package and do a point release.
This also adds an expected date for the next release
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iae9653a275fcc1d11efbb88e12676f332be0a5dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79147
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The upstream build system uses a newly introduced function `read-file`,
so copy that in from Linux 6.2.
TEST=`util/abuild/abuild -C` output (config.h and config.build) remains
the same
Change-Id: Ic100bf189ebd3eaa0eb26904ae8602910329a180
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79179
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
In nissa platform, we configured GPP_F17 as SCI+APIC to wake the system
and also generate IRQ to the IOAPIC. Currently, we set GPP_F17 to level
triggered and it causes AP (Application Processor) to keep sending
GET_NEXT_EVENT to EC during resume from suspend by connecting AC.
So we change GPP_F17 to edge triggered to avoid this condition.
BUG=b:308716748
TEST=Original failure rate was 7 out of 10 times and it reduced to
0 out of 60 times on six joxer systems.
Signed-off-by: Scott Chao <scott_chao@wistron.corp-partner.google.com>
Change-Id: I3ceb1dfce46376a6a9a8c6cb6d691d818a0a42ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79244
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
When cleaning the sensitive data in the memory, we will want to prevent
zero out the content of tbb_buffer. Move the ttb_buffer to a standalone
section will simplify the problem.
BUG=b:248610274
TEST=emerge-cherry libpayload
BRANCH=none
Change-Id: I610276cbe30552263d791860c15e5ad9a201c744
Signed-off-by: Yi Chou <yich@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79078
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable 3VSBSW# in NCT6779D super I/O like other variants in the family,
needed to maintain power to memory during S3 suspend. Without it
resuming totally fails.
(Enabling it in devicetree is OK; it needs not be done in early
board init.)
TEST=Resuming from S3 works.
Change-Id: Ia8059b2a263ab5c459e54685f046eeb913776473
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78205
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kevin Keijzer <kevin@quietlife.nl>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables the FSP (Firmware Splash Screen) rendering feature
for all Rex variants, including chromeboxes like Ovis. This will allow
users to see the FSP logo during the boot process.
BUG=b:284799726
TEST=Verify that the FSP logo is displayed during the boot process on
an google/ovis chromebox.
Change-Id: I73d82e16f70ffdc8cb168506c86d9c4e9a92c38d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79175
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
The Genoa SoC has 6 I2C controllers. In order to support those, select
SOC_AMD_COMMON_BLOCK_I2C and implement the SoC-specific functions and
data structures needed by the common AMD I2C code. Since the common AMD
I2C code also reports if the controller is enabled or not in the SSDT,
change the corresponding DSDT code to use this information. In this
patch the I2C pad control registers don't get configured by coreboot yet
and we rely on ABL already having those set up correctly which seems to
be an assumption that the reference firmware is making too. PPR #55901
Rev 0.26 was used as a reference for the I2C controllers and the GPIO
pins being used.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iebc10de6ea5c6d441cff04e016dcec62405078c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
The code for "phase 4" of firmware verification currently only sets a
recovery reason when there's an actual hash mismatch detected in
vb2api_check_hash_get_digest(). This is the most likely way how this
section of code can fail but not the only one. If any other unexpected
issue occurs, we should still set a recovery reason rather than just
reboot and risk an infinite boot loop.
This patch adds a catchall recovery reason for any error code that falls
out of this block of code. If a more specific recovery reason had
already been set beforehand, we'll continue to use that -- if not, we'll
set VB2_RECOVERY_FW_GET_FW_BODY.
Change-Id: If00f00f00f00aa113e0325aad58d367f244aca49
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78866
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch unifies and simplifies the Kconfig selection model for the
Gru, Herobrine, Trogdor and Veyron boards according to the model
discussed in CB:78972.
Also add missing license headers to two Kconfig files while I'm here.
Change-Id: If679a05afd10869afba9c2a33b54862e102b5f40
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79022
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While transitioning the devicetree to make use of the chipset
devicetree, commit 3b5b9f4c54 ("mb/hp/280_g2: Make use of the chipset
devicetree") removed useful comments documenting the endpoints of the
root ports. Restore them.
Change-Id: I178cb472a8f40baaccc30514689bda2730dfa9dc
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79153
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some sensitive data may remain DMA buffer, we will want to zero out
everything on the DMA buffer before we jump into the kernel to
prevent leaking sensitive data into the kernel.
To accomplish that, we will need this function to get the range of
memory that can be allocated by the dma allocator.
BUG=b:248610274
TEST=emerge-cherry libpayload
BRANCH=none
Signed-off-by: Yi Chou <yich@google.com>
Change-Id: I8f3058dfd861ed44f716623967201b8cabe8d166
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78407
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch guarantees that non-ChromeOS platforms continue to enable
early caching.
ChromeOS devices, on the other hand, control this configuration through
the motherboard configuration based on the underlying SoC.
BUG=b:306677879
TEST=Enable SOC_INTEL_COMMON_BASECODE_RAMTOP for google/rex.
Change-Id: I412b2b6a807dc0f5f2632f0fbd56bd37689dead3
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch enables the `SOC_INTEL_COMMON_BASECODE_RAMTOP` config
option for select mainboards, as not all board variants may want to
enable this config due to underlying SoC dependencies.
Mainboards that attempt to enable early caching have exhibited soft
hangs while switching between pre-RAM and post-RAM phases. This patch
allows mainboards to choose to enable this option without enabling
it by default (which could cause boot hangs).
Furthermore, it reorganizes the configuration options under
BOARD_GOOGLE_BASEBOARD_REX in alphabetical order for better readability.
BUG=b:306677879
TEST=Enable SOC_INTEL_COMMON_BASECODE_RAMTOP for google/rex and
intel/mtlrvp.
Change-Id: If380c2ecbee4f6437c3d58bfb55be076a4902997
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79048
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This partially reverts commit f493857c9b ("mb/google/brya/var/*: Set
dGPU/LAN/WLAN device type to generic"). Setting the LAN device type to
generic broke programming the LAN MAC address, so set it back to pci.
TEST=build/boot google/brya (osiris), verify LAN MAC address programmed
correctly.
Change-Id: I4fb43b7212e67b5c38724baad572860bc45b558e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79150
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This mostly reverts commit 6c705e766f ("mb/google/puff/var/*: Set
LAN/WLAN device type to generic"). Setting the LAN device type to
generic broke programming the LAN MAC address, so set it back to pci.
TEST=build/boot google/puff (wyvern), verify LAN MAC address programmed
correctly.
Change-Id: I558ae6dc1366d5a8a22e0383d7d597d15159df03
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Instead of using MSR IA32_PLATFORM_ID read the SystemAgent device id
to figure out the PC type. This follows the BWG which suggest to not
use MSR IA32_PLATFORM_ID for system identification.
Tested: Lenovo X220 still boots.
Change-Id: Ibddf6c75d15ca7a99758c377ed956d483abe7ec1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78826
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Write MSRs that are in scope package only once by checking for the BSP
bit. While this improves performance a bit it also has the benefit
that registers can be safely locked down without the need for
semaphores.
TEST: Lenovo X220 still boots.
Change-Id: I43f5d62d782466d2796c1df6015d43c0fbf9d031
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Updating from commit id c59794a6:
2023-11-02 Nicholas Bishop sign_uefi: Support signing via pkcs11
to commit id f2b01bf0:
2023-10-27 Julius Werner firmware: Undeprecate VB2_RECOVERY_FW_GET_FW_BODY
This brings in 66 new commits:
c59794a6 sign_uefi: Support signing via pkcs11
68d4aa4b sign_uefi: Skip private key check if it's a pkcs11 URI
6b9d624b sign_uefi: Pass each key path separately
483f65e4 sign_official_build.sh: properly show errors on loem issues
516ee7bc sign_uefi: Use named args instead of positional
0eec8e25 vboot_reference-sys: Switch from Command to bindgen::Builder
46f5aab8 image_signing: support multiple release names
f13af139 sign_official_build: Sudo invocation within bits of android signing
3f165374 futility: updater: Add optional serial number argument to --ccd
64379cc6 sign_official_build: add --debug flag
7160bf9f 2lib: Fix relocation issue when compiling locally with musl libc
0e27cdff vboot_reference-sys: Add vboot_host.h
2c82e73c Override use_apksigner FLAGS
b43469c7 futility/cmd_show: Support --publickey FW_VBLOCK
0eb4da96 tests/futility: Update kern_preamble.bin as kernel_part.bin
68a03355 tests/futility: Move test_show_vs_verify.sh into test_show_and_verify.sh
8daf1474 tests/futility: Move 'futility show' tests to a separate file
34190e3d futility: Exit with error when metadata hash verification not supported
967aa462 firmware/2lib: Fix function comment for vb2api_get_firmware_size()
f2b01bf0 firmware: Undeprecate VB2_RECOVERY_FW_GET_FW_BODY
ef6d02df futility/vb2_helper: Add missing newline for error messages
886d13d7 PRESUBMIT: switch to cros format
ac2e1a75 host/lib: Decouple openssl headers from HOSTLIB
86ec05f7 futility: updater: Add help info for --quirks
2850244e futility: updater: Abort if the unlock_csme_* is used on a locked device
f1b5c88d devkeys: delete old unused firmware_bmpfv.bin
4444c5fe crossystem: Fix tpm_fwver for fwid < 12935
98ef339f 2lib: Prevent overwriting the value of fw_vboot2
c7517eb4 make_dev_ssd: support ChromeOS Kdump
8e3462cc tlcl: Increase the TPM_BUFFER_SIZE
740a2966 vboot_reference: Drop 'host' usage for 'internal' in flashrom.h
57877a44 vboot: Remove comments about physical dev switch
3401d16c 2lib: Fix typos, comments and formats
fdf52d45 scripts/: Drop deprecated {g,s}et_gbb_flags.sh scripts
bf76e9ee 2lib: Output the correct kernel_version
1ac4663e make_dev_firmware.sh: update pattern for matching wp status
c57ab9f7 2lib: Add recovery reason VB2_RECOVERY_WIDEVINE_PREPARE
e094ba31 tlcl: Reduce the variants of TPM2B
b047600d sign_official_build: support key config for pkcs11
f8712b73 vboot: support signing with pkcs11 private key
17fe786f strip_boot_from_image.sh: sfill fast
6c856cd3 futility/updater: Fix EC software write protection logic
1dc5a421 futility: update: Deprecate --unlock_me by --quirk unlock_csme_nissa
f0d88587 futility: update: Refactor the 'unlock ME' quirk(s)
81429ee9 futility: update: Do not update RO when the AP RO is locked
a3beb737 futility: update: Revise the ordering or quirks
2c1844fa futility: update: Remove unused quirk 'unlock_wilco_me_for_update'
75530d32 tests/futility: Test with new signer_config.csv based firmware updater
cba649fa 2lib: Expose 2hmac
ab015448 2lib: Refactor hmac to vb2_hmac_calculate
3545f8b4 Revert "sign_uefi: Remove exception catching"
55f625a9 dump_fmap: Add offset and size to flash_ec format output
a27ee336 keygeneration: add shellcheck source statements to help linting
055f9aa2 keygeneration: replace_recovery_key.sh: make minios key optional
6cb8ab60 scripts: delete unused values kernel command line
1f76c38b vboot: Drop phone recovery support
ccf6b037 scripts: Legacy fix for set_gbb_flags.sh
8f03069e futility: Add basic README.md
88963df8 utility: Query platform wp status with futility
6c3817d2 utility: Drop cros_alias technical debt in dev_debug_vboot
df85f512 scripts: Drop cros_alias technical debt in make_dev_firmware.sh
7395cd68 futility/updater_utils.c: Match on EC path to prepare for split
52518415 crossystem: Recover corrupted RW_NVRAM on flash writes
81f9ddaf futility/cmd_gbb_utility.md: Add basic GBB subcmd doc
c4995268 futility/: Fix define confusion
69dab5a6 crossystem: Avoid writing duplicate entries to RW_NVRAM
6c37b520 Revert "crossystem: stop supporting legacy chromeos_acpi driver"
Change-Id: Ic7ecdabcdd26df349b8abf1c5a77c806facfe1d8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78865
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check FW_CONFIG and disable gpios for HPS if HPS_ABSENT for skolas
and brya0 variants.
BUG=b:311740746
BRANCH=firmware-brya-14505.B
TEST=`emerge-brya coreboot chromeos-bootimage`, flash and boot skolas
to kernel and verify via "cbmem -c | grep HPS".
Change-Id: I8cbe4f40c41f1d06e8f511c3e88c05984566d441
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Check FW_CONFIG and disable gpios for LTE if LTE_ABSENT for skolas
and brya0 variants.
BUG=b:311459627
BRANCH=firmware-brya-14505.B
TEST=`emerge-brya coreboot chromeos-bootimage`, flash and boot skolas
to kernel and verify LTE gpios are disabled via "cbmem -c | grep LTE".
Change-Id: I3f3bc2b536babf71cc484cce02f96f47707f729c
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79122
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Skolas uses brya0 schematic, so override tree should be almost the same
for brya0 and skolas. This change sync's the skolas overridetree.cb
with brya0's overridetree.cb.
BUG=b:311722825
BRANCH=firmware-brya-14505.B
TEST=`emerge-brya coreboot chromeos-bootimage`, flash and boot skolas to
kernel.
Change-Id: I14a2ed803a8ffb8614018af587c66034fb724b38
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This changes the path where go installs its packages.
Now the packages are not installed in the users home directory anymore.
This solution is not perfect though, since offline build are still not
possible, because go will fetch the packages at build time.
-modcacherw will create the go files with rw permissions, otherwise
coreboot is not able to delete the files afterwards (make distclean).
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2a35369628454057ea4758cd1225e57f07cb71c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Since the HD audio controller in the PCH are always on the same device
functions, the device operations can be statically assigned in the
devicetree and there's no need to bind the host bridge device operations
to the PCI device during runtime via a list of PCI IDs.
TEST=Lenovo X220 still boots to Linux and audio still works
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: I9bbbe9f4490dc6fb21174d63d1c8906d69ea3ee0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79118
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the PCIe root ports in the PCH are always on the same device
functions, the device operations can be statically assigned in the
devicetree and there's no need to bind the host bridge device operations
to the PCI device during runtime via a list of PCI IDs.
TEST=Lenovo X220 still boots to Linux and all PCIe devices on PCH are
visible and working.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: I05bfe8db88fd54415f320f32ea147636ca4e0df8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Since the integrated GPU is always function 0 of device 2 on bus 0, the
device operations can be statically assigned in the devicetree and
there's no need to bind the host bridge device operations to the PCI
device during runtime via a list of PCI IDs.
TEST=Lenovo X220 still boots to Linux and graphics works in UEFI
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: I20e387e626e19dc441aceda18451186d1e86cd5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79114
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While having select statements in Kconfig.name files is valid in the
syntax of the Kconfig language, having the selections split between the
normal Kconfig file and Kconfig.name files makes it harder to see what's
going on.
Kconfig.name files will now be limited to their original purpose of
selecting a particular board or board variant, not actually configuring
that board.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2aab78e296f2958e77a938b1afa40a25a6aa82b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78972
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Assigning the macros in gpio.h to the correct GPIOs. Also, fixing GPE
configurations so that they are mapped to the proper wake sources
(GPP_B, D, E groups).
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I6320cd98e560e514e63c52e173cb7923cfd1cdee
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
We need to increase romstage size a little to make a compiler upgrade
fit (CB:70771). Unfortunately the end of the romstage directly touches
the QCSDI region in the current memlayout, and there is no other way
to reshuffle things to make more space... so we need to move QCSDI out
of the way. This means that anyone who is actually building this
platform with CONFIG_QC_SDI_ENABLE (which requires a proprietary blob
that's not publicly available) will need to recompile their QCSDI binary
to match the new start address.
Change-Id: Iaf13e4001b3c763e3ec59009779931ec75603d5d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79074
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Building coreboot for the Qualcomm SoCs SC7180 and SC7280 requires to
include the Qualcomm blobs, which requires to accept their license.
However, for various reasons it makes sense to build without blobs, e.g.
static analysis or just build-testing.
So in order to do that, run the steps integrating the Qualcomm blobs
into the coreboot binary only if USE_QC_BLOBS is enabled and also remove
guards which prevent building related mainboards when USE_QC_BLOBS is
not enabled.
Change-Id: I249ac477b8f10e7fa0848e967c23a3b3b9bbd27d
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79026
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since this chip is a SoC and also to bring the chipset devicetree more
in line with the chipset devicetree of Sandy Bridge, merge the chip
operations of the northbridge's root complex and the northbridge itself
into one chip operations structure and use it at the top level of the
devicetree.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8b42bac07b1409bbc797bc4428cf9f84a40e94c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
BKDG #52740 Rev 3.05 was used as a reference for the SoC's various PCI
devices. The HDA controller in the FCH at function 2 of device 0x14 on
bus 0 was missing in the mainboard's devicetrees.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6970c2f6e6d661d40406586f4e6eeb05bcd07979
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79083
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Morphius boards using pre-v3.6 schematics don't have a dedicated GPIO
for touchscreen power/enable, and so fail with runtime detection
enabled. Since it only has one touchscreen option, and no SKUs lack a
touchscreen, we can safely assume it is present in all cases.
TEST=build/boot morphius w/4k screen, verify touchscreen enabled in
cbmem and functional in Linux and Windows.
Change-Id: I13e07e14b5a18fa1dd3b18950cf46e9d7821eedc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Some boards (e.g. prodrive/hermes) that do not provide their own FMAP
and therefore have been generated by the build system (+ ifdtool)
experience a failure when trying to build with an IFD that contains
regions which do not have equivalent fmap names (set to NULL).
Therefore add a NULL check for the fmapname and ignore the region if we
do not have an fmapname.
Test: compile prodrive/hermes
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ib4589b7fdbd11d644214ca5601536e9aeb26882f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Generated using update_ec_headers.sh [EC-DIR].
The original include/ec_commands.h version in the EC repo is:
ab9b64ac4c Add a host command to print info about AP-firmware state
The original include/ec_cmd_api.h version in the EC repo is:
ab9b64ac4c Add a host command to print info about AP-firmware state
BUG=b:300525571
BRANCH=none
TEST=none
Change-Id: I3570e073a91621cb1d28a24aa35c1f4beedceaab
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79066
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Returning a NULL device name can cause issues if something else does
handle it.
E.g. UART and GNA devices on Intel Alder Lake-N cause
INTERNAL_POWER_ERROR BSOD's in Windows when enabled due to invalid
packages being created from a NULL name
Test: build/boot google/nissa (craaskvin) to Win11
Change-Id: I0679147ad3e330d706bbf97c30bc11b2432e2e8a
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Appears to not be used under Windows, Linux, or ChromeOS, and causes
high CPU usage at idle under Windows.
BUG=none
TEST=build/boot Win11, Linux on google/frostflow, verify camera shutter
function unchanged, CPU usage under Windows idles where expected.
Change-Id: I8a6ea3b886766bdb055b40949c75bec0264eecc5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Updating from commit id edd465837e26 (2023-10-20):
cezanne: Update PSP binaries to release 0.11.11.75
to commit id e4519efca746 (2023-11-15):
Revert "picasso: Update PSP binaries to release 0.8.13.7B"
This brings in 1 new commit:
e4519efca7 Revert "picasso: Update PSP binaries to release 0.8.13.7B"
Change-Id: I860aa04324128199cbc91a5f310fcdf92a2cd65d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
System76 only sells units with memory speeds up to 5200 MT/s, but the
i9-13900HX supports up to 5600 MT/s memory.
Tested by running memtest and checking dmidecode reports 5600 MT/s when
using 2x16 GB 5600 MT/s Crucial SODIMMs (CT2K16G56C46S5) on addw3,
bonw15, serw13.
Change-Id: I9bb0435769c70c1db06d2c5cca2dd28eb5331f49
Signed-off-by: Matt Parnell <mparnell@gmail.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Tested-by: Levi Portenier <levi@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78912
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This uses the size attribute to traverse the possible string.
This patch traverses the entire property for non printable characters
and not just until the first 0 is hit.
Now numbers that start with a zero (memory wise) are not falsely
recognized as strings:
before the patch:
clock-frequency = "";
after the patch:
clock-frequency = < 0x1c2000 >;
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I229c07b76468fe54f90fa9df12f103d7c7c2859d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch creates a new variant mtlrvp4es_p_ext_ec. The new
variant will support ESx samples. The existing mtlrvp_p_ext_ec
variant will support the QS samples.
BUG=b:310775573
TEST= Build and boot mtlrvp4es_p_ext_ec.
Signed-off-by: Usha P <usha.p@intel.com>
Change-Id: Iad72c0f6343af149d16d8b1f8639ba496f6aab0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79052
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch sets the default locales to English for platforms that
do not have support for VBOOT configuration. This ensures that the
system will use English locales if the platform does not provide
its own locale settings.
TEST=Built and booted the google/rex platform successfully.
Change-Id: I7554c8bfd58411f460deeb22cf7218059ca8ba9f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79054
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The ux_locales-test relies on the ability to determine supported
locales for the platform. However, this information is unavailable
without VBOOT config being enabled. Therefore, enforce this test for
platforms with VBOOT config alone to avoid unnecessary failures.
Change-Id: I2828eb062e2b601e073e7dab9aef7316fc6ba2cd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Previously acpigen_pop_len always wrote a 3 byte PkgLength to the 3
bytes reserved by acpigen_write_len_f. After this patch acpigen_pop_len
encodes PkgLength in 1-3 bytes depending on the PkgLength. When less
than the 3 bytes that were previously reserved in the corresponding
acpigen_write_len_f call are needed for PkgLength, the payload data will
be moved back by the number of reserved bytes that aren't needed for the
PkgLength.
This fixes the problem that the Windows AML parser doesn't like a 3 byte
PkgLength being used for the size of the buffer containing UTF-16
strings when the length could be encoded in a single PkgLength byte. In
that case, Windows previously ignored the whole SSDT containing this
larger than necessary PkgLength encoding. It should however be noted
that the ACPI 6.4 spec doesn't specify if it's required to always use
the most compact possible encoding of the PkgLength or not. Since iasl
generates the shortest possible PkgLength encoding, it's also a good
idea to make coreboot's acpigen do the same although it's not required
by the specification.
With this patch applied, Windows still boots on Mandolin and the time it
takes to write the tables doesn't change. To measure the times, the log
level in bs_sample_time was increased to BIOS_CRIT and the console log
level was increased to BIOS_CRIT too to only get those times as output.
BS: BS_WRITE_TABLES run times (exec / console): 8 / 0 ms
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib897b08a05a7cdc52902d51364246c260ea1f206
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
The THRM and SATA PCI devices do not currently have any ACPI devices
defined, so drop them from soc_acpi_name() so they do not end up in
the LPI constraint list. This eliminates the following errors
under Linux:
AE_NOT_FOUND: _SB_.PCI0.THRM
AE_NOT_FOUND: _SB_.PCI0.SATA
TEST= build/boot google/hatch (jinlon) and verify no ACPI errors.
Change-Id: I3827b152644e2eaecc1ad288d441d2dad4d76ccb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79013
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After commit adaeb11021 (nb/intel/sandybridge: Clean up post Haswell SPD mapping API migration), no boards use this header anymore and it
no longer offers original content.
Adjust northbridge code #includes as needed and drop it.
Change-Id: I2785e920bd6188dbfc1a6157351083ec4a2526d0
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
With commit adaeb11021 (nb/intel/sandybridge: Clean up post Haswell SPD mapping API migration), raminit_native.h now only includes 4
other headers and offers no original content. Based on the idea that
all source files should include what they use directly, drop it in
favor of sandybridge.h (which it already includes anyway) and types.h
(replacing stdint.h because it also uses boolean constructs).
Board appears to not use anything sb/intel/bd82x6x/pch.h provides.
And the board still builds after dropping it.
Change-Id: I1b201fe4dd29bac5feb08f372d1e36353eac161d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78783
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All of these signals have net names, but are actually unstuffed, so we
have to set them to NC.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I27d8b7cd02aefb49a2dc031a30eb0d1e8aa9faa9
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The comments related to the PCI devices are superfluous since the
reference names from the chipset devicetree are used. So remove the
comments and also the devices which are turned off, or in general have
an equal state compared to the configuration in chipset devicetree.
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ic45446b03a3c571837fc1c41f55d60bdf2a25a7e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
- Disable unconnected PCH PCIe ports 1 + 3.
- Add smbios_slot_desc to WLAN PCIe port
- Add comment for PCIe port 7 that might have a
XHCI controller connected (some variants only).
Test: Lenovo X220 still boots and all devices are still working
fine. The WLAN slot is shown in dmidecode -t 9.
Change-Id: I3fdfbb7ad30e2ff8a289d9055eaef0557475fdff
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
With migration to Haswell SPD mapping interface complete:
1. Remove weak stubs meant to ensure smooth transition and
internalizes mainboard_get_spd() within raminit.c.
2. Remove post-mainboard SPD data sanitization code in raminit_mrc.c,
now that it fills its own SPD data.
3. Remove old prototypes from raminit_native.h
4a. Drops raminit_native.h from raminit.c, as individual headers
therein are already included.
4b. Drop another header from raminit.c IWYU identified as unneeded.
asus/p8z77-m still builds afterwards.
(sandybridge to receive a full IWYU cleanup later.)
Change-Id: Ie073c1386cd0a645069f0e1416263b4fa359b74b
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76991
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While converting this board to provide SPD info using the Haswell API,
it was discovered that its SPD setup was not correct to begin with.
For a board that only has soldered down memory with SPD data in CBFS,
it didn't enable HAVE_SPD_IN_CBFS in Kconfig. It also duplicated one
set of SPD data with deliberate gaps in between. It worked its dark
magic within mainboard_get_spd(), which is going away as a callback.
Add HAVE_SPD_IN_CBFS to mainboard Kconfig, recreate the one set of SPD
data as a hex dump same as other boards, and hook everything back up
with Haswell-style mb_get_spd_map().
Recreated SPD data was extracted from abuild-built binary and manually
verified for correctness against existing spd.bin (which will be
removed in a follow-up).
Change-Id: I906c49f6d1949f830828530edc0298b1b22ec04d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76995
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Changes both MRC and native raminit code path to get SPD mapping
from one place.
Boards with all memory socketed specify their mappings in a
devicetree setting introduced in commit 5709e03613
("nb/intel/sandybridge: Migrate MRC settings to devicetree") back in
May 2019 but remains unused as of this patch. This setting
will now hold raw SMBus addresses, and MRC raminit gets code to
translate them into a representation MRC expects.
Boards with soldered down memory (specifically with HAVE_SPD_IN_CBFS
in their board Kconfig), with or without socketed memory, specify
their layouts in mb_get_spd_map() as used by Haswell boards, where
they access hardware GPIO straps to select which SPD data to use.
This harmonizes the way boards specify their SPD layouts across
Haswell/SNB/IVB boards whether using MRC or native raminit. Going
forward they only need to specify the layout in one place. (Going
forward the devicetree setting should be backported to Haswell,
once we get native raminit working there.)
With this, northbridge code is now fully responsible for loading
all SPD data, be it from CBFS or SMBus.
To avoid breakage, transition will happen in stages:
1. This patch gets all the code in, and implements weak stubs that
maintain existing code and data flow (i.e. mainboards still populate
final SPD layout data). At this point devicetree already uses new
representation, but is still unused meaning no breakage.
2. Follow-up patch(es) remove mainboard_get_spd() from mainboards, and
replace it with mb_get_spd_map() or devicetree values (as appropriate)
with converted SPD info. The "weak" mainboard_get_spd() with new logic
takes over. Boards go Haswell Style at this point. Boards with MRC
raminit also lose code to fill in SPD data, allowing new data to take
hold.
3. Clean-up patch removes the weak functions and public prototypes re
mainboard_get_spd(), making it internal to northbridge. Changeover is
complete.
Change-Id: I1a75279d981e46505930a9ce1aae894ccc4e1f24
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76965
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In vboot_get_context(), vb2api_reinit() is called to restore the vboot
context from the previous stage. We use assert() for the return value of
vb2api_reinit() because there shouldn't be runtime errors, except for
one edge case: vb2_shared_data struct version mismatch. More precisely,
when RW firmware's VB2_SHARED_DATA_VERSION_MINOR is greater than RO's,
vb2api_reinit() will return VB2_ERROR_SHARED_DATA_VERSION.
To avoid using an invalid vb2_context pointer (when FATAL_ASSERTS is
disabled), change assert() to die() on vb2api_reinit() failure. For the
vb2api_init() case the assertion is unchanged because there shouldn't be
any runtime error for that.
Also move the vb2api_init() call outside the assert() argument, as
assert() may be a no-op macro depending on the implementation.
Change-Id: I4ff5ef1202bba2384c71634ec5ba12db1b784607
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a fixup to CB:78914 which inadvertently broke the RK3288 SoC.
Unfortunately we can only accommodate very little PRERAM_CBFS_CACHE in
the tiny SRAM for that chip, so we would not be able to map an entire
FMAP. Solve this problem for now by mapping less space when CBFS
verification is disabled, and disallowing CBFS verification on that SoC.
Change-Id: I2e419d157dc26bb70a6dd62e44dc6607e51cf791
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Proposed in the comment of commit 29030d0f3d
("drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume"),
during sanitize_cmos(), only reset CMOS range covered by checksum and
the checksum itself from the file cmos.default in CBFS, in order to
prevent other runtime data in CMOS (e.g. the DRAM training data on
GM45 platforms for s3 resume) being erased.
Tested: cherry-pick this commit before commit 44a48ce7a4 ("Kconfig:
Bring HEAP_SIZE to a common, large value"), which is already
before my commit 29030d0f3d , Thinkpad X200 with
CONFIG(STATIC_OPTION_TABLE) can resume from s3 again,
indicating that DRAM training data are no longer erased.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Co-authored-by: Jonathon Hall <jonathon.hall@puri.sm>
Change-Id: I872bf5f41422bc3424cd8631e932aaae2ae82f7a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
init() was always followed by open() and after successful initialization
we only need send-receive function which is now returned by tis_probe()
on success, thus further reducing number of functions to export from
drivers.
This also removes check for opening TIS twice that seems to have no
value.
Change-Id: I52ad8d69d50d449f031c36b15bf70ef07986946c
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76954
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id d81517e:
2023-09-28 14:13:56 -0600 - (Improper bit field offset calculation)
to commit id 0411c75:
2023-11-10 23:59:34 +0000 - (Minor changes to fix issues compiling with clang)
This brings in 1 new commits:
0411c75 Minor changes to fix issues compiling with clang
Change-Id: Ib3adfd7bccd45dfd76ede462677dcfb294baa15d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
To see which Kconfig symbols are actually used, and to verify that
they're used correctly, kconfig_lint scans the C code. It gives an error
if it sees a CONFIG(symbol) where the symbol doesn't exist.
This creates a problem when a C preprocessor macro is created to match
multiple Kconfig symbols. The simple solution here is to just ignore
those C preprocessor macro definitions as beyond the scope of this
linter.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5a20e8bb5a3e19e380802cba712d6dd3ff2f4dc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78681
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When a package length needs to be written, we used to always
write three bytes for it, even when the length would fit into
one or two bytes. To allow such compact package lengths, we
have to move the written buffer data in case the length is
smaller. This makes tracking the start of nested buffers
harder, as they may be moved entirely later when a package
length is written. So instead of tracking start addresses in
test_acpigen_nested_ifs(), let's work with the generated AML
alone. In this lucky case, we can simply search for the `if`
operations.
Change-Id: Id8557dd5d1be3878713ee0b6106c3e0975665e97
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add variant of LTE and WFC support on gothrax board.
We base decisions on the values within the firmware configuration
CBI field.
In fw_config settings, if the board move LTE and WFC modules,
the hardware GPP_A8/GPP_E13/GPP_F12/GPP_H19/GPP_H23/GPP_R6/GPP_R7
pins need to be deasserted.
BUG=b:303526071
TEST=emerge-nissa coreboot & \
Check against schematic.
Whether it works as expected under different SKUs.
Signed-off-by: Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com>
Change-Id: Ia8041bdc599509911bde95d6294314036e75b227
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78916
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Instead of installing the pip modules system-wide, and possibly causing
conflicts, install them into a virtual environment for the coreboot
user.
If we wanted to, in the future, we could install different versions of
the modules into different virtual environment directories to allow
for testing or anything else we needed.
Change-Id: I49c749a13a698bfb7af29bf07e42ac14b67b2ae7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
There is no enumerate_buses() today and also no trace of it in our
repository. Also, in current terms, mainboard_enable() is called
as the very first thing in our enumeration so the comment seems
misleading.
Change-Id: Iae620f83c8166c1cfc8b9fb9ef4a7025987bf1be
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The buffer length is in bytes, and since we are converting from ASCII
to UTF-16, the value written needs to be 2x the string length + null
terminator.
TEST=build/boot google skyrim (frostflow), dump acpi and check bytecode
for correct buffer length preceding unicode strings.
Change-Id: Id322e3ff457ca1c92c55125224ca6cfab8762a84
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Guard multiple options depending on another with an if-block. It's not
needed to repeat the condition for every option.
This also cleans up the ordering of the options and groups all options
related to iPXE.
Change-Id: I9e74ab567f619a2d5c20c6c0282b37193d9ac01b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78925
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When a variant setup is used, checking for each variant in order to do
the mainboard configuration is quite painful. Thus, move the selects
from BOARD_SPECIFIC_OPTIONS, which is enabled by default when a variant
is chosen, out to a common option, which is disabled by default but
selected by the variants.
So in order to enter that config block, it's only needed to check if
that common option is enabled and not for each variant. It's also a very
common scheme now.
Change-Id: I4ed889ce78a0d7cd088e05d0f4b7fbbc89153860
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78975
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The combination of SOC_INTEL_RAPTORLAKE_PCH_S and FSP_TYPE_IOT is
currently broken. By default, e.g. for MSI PRO Z790-P, the
FSP_HEADER_PATH does not match the default FSP_FD_PATH. For headers
the client FSP is selected, while for the FD file, IoT FSP binary
is chosen. The order of default for both headers and FD file must be
the same to match the headers and binaries.
TEST=Build default MSI PRO Z790-P config and see that FSP_HEADER_PATH
matches FSP_FD_PATH FSP variant-wise.
Change-Id: I8db5ea10c2986ff8d3fa7d616b3f1617d05f0260
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78410
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Dynamic Tuning Technology (DTT) device IRQ is not programmable and
is INT_A/PIRQ_A (IRQ 16).
Reference: Meteor Lake U/H and U Type4 External Design Specification
External Design Document (657165)
TEST=Linux driver successfully uses IRQ 16 on rex. Without this patch
it was binding IRQ 18 but interrupts were going to IRQ 16.
Change-Id: I2cbb9dd41f27c40a29346be325bb9c46d1061afb
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
When the SMI transfer monitor (STM) is configured, get_save_state
returns an incorrect pointer to the cpu save state because the size
(rounded up to 0x100) of the processor System Management Mode (SMM)
descriptor needs to be subtracted out in this case.
This patch addresses the issue identified in CB:76601, which means
that SMMSTOREv2 now works with the STM.
Thanks to Jeremy Compostella for suggesting this version of the patch.
Resolves: https://ticket.coreboot.org/issues/511
Change-Id: I0233c6d13bdffb3853845ac6ef25c066deaab747
Signed-off-by: Eugene D. Myers <edmyers@cyberpackventures.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78889
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Later GSCs don't need a EC_IN_RW GPIO anymore, so removing the use of
this for get_ec_is_trusted().
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I29f94969e9f2c1f239d9f9655f39b8410296f695
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Updating from commit id 37366af8d:
2023-07-28 17:04:54 +0200 - (Merge "fix(cpus): fix minor issue seen with a9 cpu" into integration)
to commit id 88b2d8134:
2023-09-06 11:26:32 +0200 - (Merge "fix(scmi): add parameter for plat_scmi_clock_rates_array" into integration)
This brings in 225 new commits.
Change-Id: I97147fbec5c0a91daab67524027f57962f61d0a1
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
As TOUCHSCREEN_I2C_SPI will be used for two different configurations,
splitting it to TOUCHSCREEN_GSPI and TOUCHSCREEN_THC, and re-order
the FW_CONFIG bits by moving VPU to different bit position.
BUG=b:307774932
TEST=build and boot rex
Signed-off-by: YH Lin <yueherngl@google.com>
Change-Id: Ied4d732ef7993e95edbb7eb281842b9392e72820
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Some GPIOs (like WP and GSC) need to be configured in bootblock.
Making sure that they get configured earlier for this.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I8dd4853bc05b954f47d858d87ea2aed48e4b8074
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78943
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are some inaccuracies in arbitrage. This is the first pass at
correcting the incorrectly generated configs. I also tried to update
the "No heuristic was found useful" comment generated by arbitrage
into something more useful (ie: the appropriate NFs).
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I836565e09a3e0b25746b3e2f9ed6610eaacf7e97
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78942
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Initialise overridetree based on the schematics revision 20231020A.
Added data.vbt just only for running abuild completed.
Real vbt define by CONFIG_INTEL_GMA_VBT_FILE in chromium:4936896.
BUG=b:304920262
TEST=abuild -v -a -x -c max -p none -t google/brya -b anraggar
Change-Id: I232bde990747be80e1ab62c3f0d010d5fc854cb5
Signed-off-by: wuweimin <wuweimin@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78456
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the FMAP cache is enabled, it cannot fail in pre-RAM stages unless
flash I/O in general doesn't work. Therefore, it is unnecessary and a
waste of binary size to also link a fallback path for this case.
Similarly, once the cache is written to CAR/SRAM/CBMEM there should be
no way for it to become magically corrupted between boot stages. Many
other parts of coreboot blindly assume that persistent memory stays
valid between stages so there is no reason why this code should link in
extra fallback paths in case it doesn't.
This saves a little over 200 bytes per affected (uncompressed) stage on
aarch64.
Change-Id: I7b8251dd6b34fe4f63865ebc44b9a8a103f32a57
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78904
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A recent security audit has exposed a TOCTOU risk in the FMAP
verification code: if the flash returns a tampered FMAP during the first
setup_preram_cache(), we will abort generating the cache but only after
already filling the persistent CAR/SRAM region with the tampered
version. Then we will fall back into the direct access path, which could
succeed if the flash now returns the original valid FMAP. In later
stages, we will just use the data from the persistent CAR/SRAM region as
long as it looks like an FMAP without verifying the hash again (because
the hash is only linked into the initial stage).
This patch fixes the issue by just calling die() immediately if FMAP
hash verification fails. When the verification fails, there's no
recourse anyway -- if we're not dying here we would be dying in
cbfs_get_boot_device() instead. There is no legitimate scenario where
it would still be possible to continue booting after this hash
verification fails.
Change-Id: I59ec91c3e5a59fdd960b0ba54ae5f15ddb850480
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78903
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The rarely-used fallback path for accessing the FMAP without a cache
currently only maps the FMAP header for the initial verify_fmap() call.
This used to be fine when we were just checking the magic number, but
with CBFS verification we may need to hash the entire FMAP.
Since this path is so rarely used anyway and the size difference only
has a practical impact on a few platforms, lets keep things simple and
just always map the whole FMAP.
Change-Id: Ie780a3662bf89637de93a36ce6e23f77fed86265
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78914
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The value from raw_read_cntfrq_el0() could be large enough to cause
overflow when multiplied by USECS_PER_SEC. To prevent this, both
USECS_PER_SEC and hz can be reduced by dividing them by their GCD.
This patch also modifies the return type of `timer_hz()` from
`uint64_t` to `uint32_t`, assuming that in practice the timestamp
counter should never be that fast.
BUG=b:307790895
TEST=boot to kernel and check the timestamps from `cbmem`
Change-Id: Ia55532490651fcf47128b83a8554751f050bcc89
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78888
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the hda_soc_ssdt_quirks function since it doesn't apply for any of
the SoCs supported by the Stoneyridge code which was the only SoC
implementing it. This code was added when commit 91a7abf25c
("soc/amd/hda: Move HDA PCI device from DSDT to SSDT") rewrote the code
originally added in commit 1587dc8a2b ("soc/amd/stoneyridge: Add
northbridge support") as a copy from northbridge/amd/pi/00670F00. This
code was moved around in commit 6580408a7e ("amd/pi/hudson: Move audio
to northbridge"), since the HDA controller was moved from the FCH to the
northbridge complex. When the controller was moved, the PCI config space
interface also changed, so those bits are no longer the DisableNoSnoop,
DisableNoSnoopOverride, and EnableNoSnoopRequest bits of the Misc
Control register of the HDA controller, but some bits within the
ClassCodeW field of the ACGAZ Mirrot Reg Ctrl 0 register.
BKDG #55072 Rev 3.04 (Stoneyridge), BKDG #50742 Rev 3.08 (family 15h
model 60h-6fh / 00670F00), and BKDG #52740 Rev 3.05 (family 16h model
30h-3fh) were used as a reference. Only the SoC with BKDG #52740 still
has the HDA controller in the FCH; the other two have it in the
northbridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I77fc76752b1c7de62ba8a196f15c198f55be3074
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78940
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The builds from the configs directory were not being saved in the
junit.xml files that Jenkins uses to determine pass vs fail of the
individual builds.
This also fixes the path to a log file that I noticed while testing.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I37dbee676cc9e507e612ce66994a04aba062757a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78863
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 44a48ce7a4.
Reason for revert: It breaks wakeup from suspend on a bunch of boards.
While this approach of eyeballing "correct" values by chipset _should_
be fixed, it should also be accompanied by compile time verification
that the memory map works out.
Since nobody seems to care enough, let's just revert this, instead of
keeping the tree broken for a bunch of configurations.
Change-Id: I3cd73b6ce8b15f06d3480a03ab472dcd444d7ccc
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78850
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Now VBOOT is always assumed to run after romstage and be linked inside
romstage. This currently is the case but for flexibility reasons (e.g.
linking romstage into bootblock or having a verstage before romstage)
this could be more precise.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I361731c930a35e12245153920df1b6884d47064c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Instead of redirecting the output of sed into a temporary file and
copying it to its target then, just tell sed to do the replacements
in-place and don't let it create a backup of the original file. The
overhead is not needed.
Change-Id: I442616cd78098b653af5bd49bc7a4f021c99e081
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The value from raw_read_cntfrq_el0() could be large enough to cause
overflow when multiplied by USECS_PER_SEC. To prevent this, both
USECS_PER_SEC and tfreq can be reduced by dividing them by their GCD.
BUG=b:307790895
TEST=emerge-geralt coreboot
TEST=boot to kernel and check the timestamps from `cbmem`
Change-Id: I366667de05392913150414f0fa9058725be71c52
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78800
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After CB:78800 applied, the bootblock increases 2128 bytes and exceeded
its allotted size (40K). Therefore, we enlarge BOOTBLOCK to 44K to solve
the compilation error. This patch also increases PRERAM_CBFS_CACHE to
103K to fill the empty space (1K) between TIMESTAMP and TTB.
BRANCH=none
BUG=none
TEST=./util/abuild/abuild -p none -t GOOGLE_HEROBRINE -x -a -B
Change-Id: Iae9d44939b29098e823508dd3965a1bae7a69041
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
To get tracehub working, it requires few settings such as
SOC_INTEL_METEORLAKE_DEBUG_CONSENT=2 and enable tracehub device in
dev tree. This commit binds all tracehub related settings to Kconfig,
so that users only need to enable SOC_INTEL_COMMON_BLOCK_TRACEHUB
TEST=boot on screebo and test tracehub device exists and working
Change-Id: Ie830fe2fd38e3456497bea37fe42ca60d26ca305
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78648
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add an entry in the min_pci_sleep_states array for SA_DEVFN_DPTF,
to correct warning in cbmem log:
[WARN] unknown min d_state for PCI device 00:04.0
TEST=build/boot google/brya (banshee), verify warning not present in
cbmem log, verify entry for DPTF device in ACPI LPI constraint list.
Change-Id: I2a9976b065f08e4acd31c3deca13c5278f031a90
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78877
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Commit 2bc9cee0f7 ("Braswell: Update the ACPI tables") switched the
SoC from using its own HPET generation code to the common x86 code, but
along the way the min_tick value got lost. Restore the original value
prior to the above commit, which is now set via a Kconfig override.
TEST=build/boot google/cyan (edgar), verify min_tick value in HPET
ACPI table is correct.
Change-Id: I2633e7cd0c3d74c1554ae8c1f2bb6387fd6dde2b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78744
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, there are 3 separate settings for DPTF which are not always
in sync:
- the enabled/disabled state of the devicetree PCI device
- the 'dptf_enable' register, which sets the ACPI device status via GNVS
- the 'DptfDisable' register, which sets the FSP UPD of the same name
To make things sane, drop the two chip registers, and set the GNVS
variable and FSP UPD based on the enabled/disabled status of the DPTF
PCI device in the mainboard's devicetree.
TEST=build/boot google/cyan (edgar). Verify that the PCI and ACPI
devices are present/enabled when DPTF is enabled in devicetree, and not
present/disabled when disabled in devicetree.
Change-Id: I8fc1b63eda0dc2e047d9cb1e11a02d41ab8b2ad7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The device name for the SA thermal/DPTF PCI device was missing from
soc_acpi_name(), leading to an invalid PLI device constraint entry
being generated in the SSDT (the name field was blank/missing).
Add the missing entry, matching the name to the existing ACPI
device.
TEST=build/boot Win11 on google/puff (wyvern) without a BSOD.
Change-Id: I7ac03fd292246981f32d9ad894b8f0f9870240fc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78869
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add an entry in the min_pci_sleep_states array for SA_DEVFN_THERMAL,
to correct warning in cbmem log:
[WARN] unknown min d_state for PCI device 00:12.0
TEST=build/boot google/puff (wyvern), verify warning not present in
cbmem log, verify entry for THRM device in ACPI LPI constraint list.
Change-Id: Ide98c1b82c56ed1d34c608f9419f61c8e15d2dab
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78868
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change the LAN/WiFi device types from PCI to generic, so that the bogus
PCI device and function values don't end up in coreboot's internal
device tree. The presence of these bogus PCI devices cause the LPI
constraint generator to create a reference for an ACPI device which does
not exist (SB.PCI0.RP{xx}.MCHC). The invalid reference(s) cause a
Windows BSOD (INTERNAL_POWER_ERROR).
TEST=build/boot Win11 on google/puff (wyvern). Verify LAN/WLAN devices
function correctly under Windows and Linux.
Change-Id: Ibc5f96250edb358d0517bd3840bf5604defe0b39
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
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).
BUG=b:305887856
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I5993049ac63520c4dfd057c38b566fc69502d825
Signed-off-by: Rex Chou <rex_chou@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Change the dGPU/LAN/WiFi device types from PCI to generic, so that the
bogus PCI device and function values don't end up in coreboot's
internal device tree. The presence of these bogus PCI devices cause the
LPI constraint generator to create does a reference for an ACPI device
which does not exist (SB.PCI0.RP{xx}.MCHC). The invalid reference(s)
cause a Windows BSOD (INTERNAL_POWER_ERROR).
TEST=untested
Change-Id: Ic997b5ad893853b99ae53a2e5c7acf58467ea4f1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78873
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch calls into the function to join the MBUS if the GFX PEIM
module inside the FSP binary is taking care of graphics initialization
based on the RUN_FSP_GOP config option. The FW skips joining the MBUS
in case of a non-FSP solution and/or SOC_INTEL_GFX_MBUS_JOIN config is
not enabled.
BUG=b:284799726
TEST=MBUS joining is only applicable for google/rex while using GFX
PEIM.
Change-Id: I50d719a286722f5aafbad48ab4ca60500c836dd6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
gnatgcc is deprecated and in recent GCC releases its purpose is
fulfilled by the gcc binary. In case of a deprecated gnatgcc version is
installed, it doesn't provide the expected output and hostcc_has_gnat1()
fails. In this case, just set the value of CC to gcc.
It's still required to install GNAT in addition to GCC.
Change-Id: I730bdfda81268d10bd2a41ef5cb4e3810b76a42c
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Commit e728766f45 ("soc/amd/mendocino: Do not load MP2 Firmware when
in RO") added logic to ensure that the MP2 disable soft fuse bit was set
for the RO section, but failed to check if the bit was already set
otherwise (as it is for non-ChromeOS builds). This caused the bit to
appear twice in the PSP_RO_SOFTFUSE_BITS string, and when the string
was converted to a series of numeric values and added together, bit
(n+1) ended up being set instead of bit n.
To mitigate this, use the makefile sort() function to ensure the
PSP_[RO_]SOFTFUSE_BITS string does not contain any duplicates before
the bitmask is calculated. Apply this to all AMD SoC makefiles where
the softfuse bits are added.
TEST=build/boot google/skyrim (frostflow). Use a verbose build (V=1)
to verify that the correct soft fuse value is passed to amdfwtool for
RO and RW_A/B for both ChromeOS and non-ChromeOS builds.
Change-Id: I2e207e20132d44016fbcb986bdfd8e935d8fead5
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78823
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
On guybrush, keyboard presses are signaled by the EC via eSPI virtual
wire. The interrupt is shared with others and should be active low.
From 74bce48f1d ("mb/google/{zork,guybrush,skyrim},soc/amd/espi: Fix vw_irq_polarity"):
> 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.
Setting `vw_irq_polarity` in the device tree provides an option to
invert interrupts from the eSPI controller, but the register is
initialized from verstage which is baked into RO.
As a workaround, the necessary interrupts on the EC have been
reconfigured to be active low, and we can modify the IO-APIC
accordingly.
EC related CL here: https://crrev.com/c/4891663
BUG=b:218874489
TEST=-`emerge-guybrush chromeos-ec coreboot chromeos-bootimage`
-Flash new RW fw and verify keyboard is functional
-`suspend_stress_test -c 1` and verify i8042 irq is removed as a
wake source
-`echo mem > /sys/power/state`. Press key and verify system wake
from i8042.
Cq-Depend: chromium:4891663
Change-Id: I7d093d94a666263684645ef724e945069c68c806
Signed-off-by: Mark Hasemeyer <markhas@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Commit 1df1cf994a ("commonlib/fsp_relocate: add PE32 section
support") introduced a potential NULL pointer dereference if there is
PE32 binary to relocate outside of the first firmware volume.
The `fih_offset' pointer was used as an output variable but now it is
also used as an input variable to pass the FSP information header to
the `pe_relocate()' function.
This commit resolves this potential NULL-pointer dereference by
passing the pointer systematically and without affecting the logic as
it is only set if it has not been set before.
Change-Id: I9fad90a60854d5f050aa044a5c0b3af91c99df4a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78501
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A new FSP-S UPD is added to allow passing a buffer containing boot logo
in BMP format. Update the FSP-S UPD and add a SoC specific callback to
populate the UPD.
BUG=b:294055390
TEST=Build and boot to OS in Skyrim. Pass the BMP logo buffer through
the UPD to FSP-S. Ensure that the concerned driver in FSP-S handles the
buffer.
Change-Id: Ie522956b6dfe2400ef91d43c80f2adc6d52c8415
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78817
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ACPI name of any device needs to match the name used for generating
the S0i3 LPI constraint list, which comes from soc_acpi_name() for each
SoC. The names used for the eMMC controller do not match, which will
lead to broken ACPI tables since the LPI constriant will reference
an ACPI device which does not exist. Some OSes tolerate this better
than others, but it should still be corrected.
TEST=build/boot google/{hatch,volteer, brya}, dump ACPI and verify
no invalid device names referenced.
Change-Id: Icbc22b6b2a84bbe73f1b09083f27081612db5eba
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78825
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch fixes the redundent GFX modeset issue when a dual display
is attached (e.g. an eDP display and an HDMI display).
The issue was caused by the MBUS joining logic not considering the
display type. This patch introduces three types of display: internal,
external, and dual-display. The MBUS joining logic is then updated
to consider the display type and ensure that the correct pipes are
joined to the MBUS:
For internal-only displays, only PIPE-A is joined to the MBUS.
For external displays, no pipes are joined to the MBUS.
For dual-displays, all available pipes are joined to the MBUS.
BUG=b:284799726
TEST=Able to fix the redundent modeset issue when eDP and HDMI attached
to the google/rex.
Change-Id: Ie2a3b9f1212a9dcab2b7305078fe22ee35e7423c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78691
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change the WiFi device type to generic, so that the LPI constraint
generator does not create a reference for a device which does not
exist in ACPI (SB.PCI0.RP14.MCHC). The invalid reference causes
a Windows BSOD.
TEST=build/boot Win11 on google/hatch (akemi)
Change-Id: Ieab0722a81f0952bb5b6df8e60c4d684ff455418
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78543
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No driver available or needed under Windows, so hide from OS.
TEST=build/boot Win11 on google/kahlee (liara), verify ADAU7002
device no longer listed as unknown under Device Manager.
Boot Linux and verify audio still functional.
Change-Id: If6d250a123825a69441b5c4d3cde35d5a68f568d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78510
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the required FMD changes to support the change
in cse_lite 'commit Ie0266e50463926b8d377825 ("remove
cbfs_unverified_area_map() API in cse_lite")' for CBFS verification.
With the change in cse_lite the ME_RW_A/B blobs are now part of
FW_MAIN_A/B and corresponding entries in FMD can be removed for boards
that currently use them.
BUG=b:284382452
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I3ca88fee181f059852923d50292b24c0e5b9fd6d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
During warm reboot, NVMe is not detected with non-serial image
sometimes while there is no issue with serial image. This change
toggles NVMe PWR pin as soon as in early stage to make NVMe ready
sooner.
BUG=b:260547988
BRANCH=None
TEST= Build rex0 and try warm reboot from OS console. Check if
the platform with Micron SSD boots to OS again without an issue.
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I2f34e3f49e7fc388198ff85c8e119cb3f242a60e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Intel has identified an idle hang issue on pre-prod silicon that will
not be fixed or root-caused. To avoid the issue, this commit sets
SaGvWpMask to SAGV_POINTS_0_1_2 in the devicetree.
Note: This change will affect system power.
BUG=b:287170545
TEST=Able to idle for more than 5+ hours without any hang on
google/screebo.
Change-Id: Id0b8db0076d983d336c3bec6d6c33614c69964d1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78794
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds power limit settings for 4+8 28W SOC sku and renames
MTL_P_682_CORE to MTL_P_682_482_CORE since they are sharing same 28W
settings.
BUG=b:306677879
TEST=boot on rex with 4+8 SOC and power limit settings are correct
Change-Id: Icb5fc2b13e8510f89c03927439431190439a3a94
Signed-off-by: Curtis Chen <curtis.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78796
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code for "phase 4" of firmware verification currently only sets a
recovery reason when there's an actual hash mismatch detected in
vb2api_check_hash_get_digest(). This is the most likely way how this
section of code can fail but not the only one. If any other unexpected
issue occurs, we should still set a recovery reason rather than just
reboot and risk an infinite boot loop.
This patch adds a catchall recovery reason for any error code that falls
out of this block of code. If a more specific recovery reason had
already been set beforehand, we'll continue to use that -- if not, we'll
set VB2_RECOVERY_FW_GET_FW_BODY.
Change-Id: If00f8f8a5d17aa113e0325aad58d367f244aca49
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78821
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id 24cb127a:
2023-08-21 Nicholas Bishop sign_uefi_unittest.py: Fix long-line lint
to commit id f2b01bf0:
2023-10-27 Julius Werner firmware: Undeprecate VB2_RECOVERY_FW_GET_FW_BODY
This brings in 47 new commits:
f2b01bf0 firmware: Undeprecate VB2_RECOVERY_FW_GET_FW_BODY
ef6d02df futility/vb2_helper: Add missing newline for error messages
886d13d7 PRESUBMIT: switch to cros format
ac2e1a75 host/lib: Decouple openssl headers from HOSTLIB
86ec05f7 futility: updater: Add help info for --quirks
2850244e futility: updater: Abort if the unlock_csme_* is used on a locked device
f1b5c88d devkeys: delete old unused firmware_bmpfv.bin
4444c5fe crossystem: Fix tpm_fwver for fwid < 12935
98ef339f 2lib: Prevent overwriting the value of fw_vboot2
c7517eb4 make_dev_ssd: support ChromeOS Kdump
8e3462cc tlcl: Increase the TPM_BUFFER_SIZE
740a2966 vboot_reference: Drop 'host' usage for 'internal' in flashrom.h
57877a44 vboot: Remove comments about physical dev switch
3401d16c 2lib: Fix typos, comments and formats
fdf52d45 scripts/: Drop deprecated {g,s}et_gbb_flags.sh scripts
bf76e9ee 2lib: Output the correct kernel_version
1ac4663e make_dev_firmware.sh: update pattern for matching wp status
c57ab9f7 2lib: Add recovery reason VB2_RECOVERY_WIDEVINE_PREPARE
e094ba31 tlcl: Reduce the variants of TPM2B
b047600d sign_official_build: support key config for pkcs11
f8712b73 vboot: support signing with pkcs11 private key
17fe786f strip_boot_from_image.sh: sfill fast
6c856cd3 futility/updater: Fix EC software write protection logic
1dc5a421 futility: update: Deprecate --unlock_me by --quirk unlock_csme_nissa
f0d88587 futility: update: Refactor the 'unlock ME' quirk(s)
81429ee9 futility: update: Do not update RO when the AP RO is locked
a3beb737 futility: update: Revise the ordering or quirks
2c1844fa futility: update: Remove unused quirk 'unlock_wilco_me_for_update'
75530d32 tests/futility: Test with new signer_config.csv based firmware updater
cba649fa 2lib: Expose 2hmac
ab015448 2lib: Refactor hmac to vb2_hmac_calculate
3545f8b4 Revert "sign_uefi: Remove exception catching"
55f625a9 dump_fmap: Add offset and size to flash_ec format output
a27ee336 keygeneration: add shellcheck source statements to help linting
055f9aa2 keygeneration: replace_recovery_key.sh: make minios key optional
6cb8ab60 scripts: delete unused values kernel command line
1f76c38b vboot: Drop phone recovery support
ccf6b037 scripts: Legacy fix for set_gbb_flags.sh
8f03069e futility: Add basic README.md
88963df8 utility: Query platform wp status with futility
6c3817d2 utility: Drop cros_alias technical debt in dev_debug_vboot
df85f512 scripts: Drop cros_alias technical debt in make_dev_firmware.sh
7395cd68 futility/updater_utils.c: Match on EC path to prepare for split
52518415 crossystem: Recover corrupted RW_NVRAM on flash writes
81f9ddaf futility/cmd_gbb_utility.md: Add basic GBB subcmd doc
c4995268 futility/: Fix define confusion
69dab5a6 crossystem: Avoid writing duplicate entries to RW_NVRAM
6c37b520 Revert "crossystem: stop supporting legacy chromeos_acpi driver"
Change-Id: Ic7ecd1755d26df349b8abf1c5a77c806facfe1d8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78820
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This prevents a headscratcher when .config in root doesn't have a write
permission bit set which causes a build failure of savedefconfig
not able to write to copied file, for example
*** Error while saving defconfig to:
build/mainboard/emulation/qemu-i440fx/cbfs-file.eU5E0t.out.tmp2
Change-Id: I2e7d35c9f6e8add3e7438d163850bc5fda5a99b2
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Windows doesn't have / will likely never have a signed driver for the
FPR, so set the device status as hidden so it will not appear as an
unknown device in Windows Device Manager. Linux does not check/care
about the ACPI device status.
TEST=build/boot Win11 on google/brya (kano), verify FPR does not show
up as unknown device under Device Manager.
Change-Id: Ie73fd9d448ecca9e9112abc0d92b4ab46ce3618d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Windows doesn't have / will likely never have a signed driver for the
FPR, so set the device status as hidden so it will not appear as an
unknown device in Windows Device Manager. Linux does not check/care
about the ACPI device status.
TEST=build/boot Win11 on google/hatch (jinlon), verify FPR does not
show up as unknown device under Device Manager.
Change-Id: Ia4a908afdabad0ae8db45c4731a00c9cb17b42bb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch allows google/rex mainboard to choose between "Performance"
(PL_PERFORMANCE) and "Baseline" (PL_BASELINE) power limits (PLs).
This is important for platform to meet balance between power and
performance.
The OEM design google/screebo selects baseline power limit to maintain
the balance performance in lower power.
BUG=b:307237761
TEST=Able to build and boot google/screebo.
w/o this patch:
screebo4es-rev1 ~ # cbmem -c -1 | grep "CPU PL"
[INFO ] CPU PL1 = 15 Watts
[INFO ] CPU PL2 = 57 Watts
[INFO ] CPU PL4 = 114 Watts
w/ this patch:
screebo4es-rev1 ~ # cbmem -c -1 | grep "CPU PL"
[INFO ] CPU PL1 = 15 Watts
[INFO ] CPU PL2 = 40 Watts
[INFO ] CPU PL4 = 84 Watts
Change-Id: I43debc5442ae9c01851652beba676ffc102ca27d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I2f641ce1fc44a9d7c9f9c403d255997214021f47
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78668
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I15f326774850b3c9562f7eebb78f29430dec1031
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78667
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I75aeb46ea3b4a7c0a41dce375735e7b42ed59587
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78664
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I92414efc9ddb849ceb8b9c4f0bc564bdbd92773b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78638
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DDR interfaces emit electromagnetic radiation which can couple
to the antennas of various radios that are integrated in the system,
and cause radio frequency interference (RFI). The DDR Radio Frequency
Interference Mitigation (DDR RFIM) feature is primarily aimed at
resolving narrowband RFI from DDR4/5 and LPDDR4/5 technologies
for the Wi-Fi high and ultra-high bands (~5-7 GHz).
This patch sets CnviDdrRfim UPD and enables CNVI DDR RFIM feature
for Craask variant.
Refer to Intel doc:640438 and doc:690608 for more details.
BUG=None
BRANCH=None
TEST=Build and boot Craask.
- Verified that Wifi DDR RFIM Feature is enabled and DDR RFI table can be modified.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: I5560bbedb26e88edd9d35f16b639fe63ef42c30e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Just as in commit 38569d0610: ("mb/lenovo/{x230, x230s}: Disable
SuperSpeed capabilities for WWAN USB")
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.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I61e61283a821686558f7f3fdfac7073bb3557e93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78680
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Meteor Lake has a UPD config called In-Band ECC(IBECC) which uses a part of the system DRAM to store the ECC information. There are a few UPD parameters in FSP-M to configure this feature as needed.
This patch adds code to expose these parameters to the devicetree so
that they can be configured on the mainboard level as needed.
Change-Id: Ice1ede430d36dff4175a92941ee85cc933fa56d5
Signed-off-by: Marx Wang <marx.wang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they will be moved
into the devicetree to their related root ports at some later point.
While on it, remove superfluous comments related to modified lines.
Change-Id: I27bac17098beb8b6cb3942e68a37da0095f0d0bd
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78602
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch introduces a dedicated devicetree.cb file for platforms
built with pre-production SoC. This will help to keep the SoC
configuration separate for platforms with ESx and QSx silicons.
For example, the SaGv WP configuration is different between
pre-production (aka ESx) and production (aka QSx) silicon.
BUG=b:306267652
TEST=Able to build and boot google/rex4es.
Change-Id: I01b0abeeb25ce5a83882c56b30929228fcc6c95c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Mike Lee <mike5@huaqin.corp-partner.google.com>
For variants without a digitizer, disable I2C2.
For variants without a proximity sensor, disable I2C3.
For variants without a fingerprint reader, disable SPI1.
For all variants, disable I2C5 as it is unused.
Adjust comment blocks as needed.
Change-Id: I27e9eb2b0dcc869d1964c0b17c656d6691c0f05e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78553
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they will be moved
into the devicetree to their related root ports at some later point.
While on it, remove superfluous comments related to modified lines.
Change-Id: I769233a5baabbea920c9085f8008071ba34bb9dd
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78598
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the required FMD changes to support the change
in cse_lite 'commit Ie0266e50463926b8d377825 ("remove
cbfs_unverified_area_map() API in cse_lite")' for CBFS verification.
These blobs were kept separate originally to avoid hash loading and
verification every time and hence save boot time.
With the change in cse_lite the ME_RW_A/B blobs are now part of
FW_MAIN_A/B and corresponding entries in FMD can be removed.
BUG=b:284382452
TEST=Build CB image for google/rex board and test CSE FW
update/downgrade with CONFIG_VBOOT_CBFS_INTEGRATION config enabled.
Also confirm there is no increase in boot time with this change.
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I56865a9e5c8b5f9e908e00e1a7e7e187d5d6a2f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With CBFS verification feature (CONFIG_VBOOT_CBFS_INTEGRATION)
being enabled, we can now remove cbfs_unverified_area_map() APIs
which are potential cause of security issues as they skip verification.
These APIs were used earlier to skip verification and hence save
boot time. With CBFS verification enabled, the files are verified
only when being loaded so we can now use cbfs_cbmem_alloc()/cbfs_map
function to load them.
BUG=b:284382452
Change-Id: Ie0266e50463926b8d377825142afda7f44754eb7
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78214
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Skolas is actually using the SOC_INTEL_ALDERLAKE_PCH_P config, so
fixing Brox to reflect this as it's using the same SoC.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I632ec055d523956983d2053cd8e7000b1eaabf92
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78656
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce Kconfig choice to pick between lzma, lz4 and no compression
at all of the VBT binary.
If VBT is needed in romstage, it can be used to set VBT lz4
compression as an alternative to enabling lzma compression support.
Indeed, the extra lzma code needed to de-compress VBT undermines the
compression size reduction between lzma and lz4.
BUG=b:279173035
TEST=Verified that vbt.bin is lz4 compressed with
VBT_CBFS_COMPRESSION_LZ4 and not compressed at all with
VBT_CBFS_COMPRESSION_NONE
Change-Id: I1df6a96c2ec122f0ef8ee6a1e96ffbd621b14941
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
POWER_STATE_OFF_AFTER_FAILURE can't be directly selected since it's a
choice, so instead set POWER_STATE_DEFAULT_ON_AFTER_FAILURE to n, as
it's functionally equivalent. This fixes the warnings generated by
the pre-commit hook Kconfig check.
It is necessary to override and set default n in the mainboard Kconfig
as it is set to default y in src/soc/intel/common/block/pmc/Kconfig.
TEST=select starlabs/starbook_adl in menuconfig and verify the default
power-on setting is S5/soft off.
Change-Id: I3ce33517dcc0af693b8db8d1de2926117ad3c16b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78627
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Lai <ericllai@google.com>
Add FP enable/disable based on SKU ID for Morphius. This is meant
to resolve a UMA issue with Morphius devices that had the FPMCU
populated on non-fp devices. Since the FPMCU is present, and the
firmware enables the power GPIO's based on variant, not SKU, the
devices were reporting data on fingerprint errantly.
BUG=b:258040377
TEST=Flash to Morphius, test FP.
Disable test SKU, flash on Morphius, test FP.
Change-Id: If5794a9a1b7eb3daaa4cdfd1354dfb0c688624fd
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78622
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
CB:77409 corrected what the UPD `Timer8254ClkSetting` was set to; this
stopped a few boards from booting.
Selecting USE_LEGACY_8254_TIMER ensures that the previous behaviour is
maintained.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ibf898cae6c9fbaf3dc7184eee745278d9b5eade4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78504
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Simplify audio overrides for dalboz baseboard-based variants by using
device aliases. This prevents duplicate ACPI devices from being
generated for the ChromeEC i2s tunnel (which causes Windows to BSOD
with an ACPI_BIOS_ERROR).
TEST=build/boot Win11 on google/zork (vilboz), dump ACPI tables
and verify only one EC tunnel device in SSDT.
Change-Id: I56aa2f761843aa269620f7e8c89ae9c0f205f349
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78509
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is only a single i2c tunnel bus for audio from the EC, so all
attached devices need to exist under a single device attached to that
bus. This change will facilitate cleanup/simplification using device
aliases in a subsequent commit.
TEST=tested with rest of patch train
Change-Id: Ie09c682a7419868d39421574568dff1a651fa0dc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78626
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Select SOC_AMD_COMMON_LATE_SMM_LOCKING to ensure that SMM remains
unlocked on S3 resume until after the AGESA call to s3finalrestore
has completed. If SMM is locked prior, S3 resume will fail:
[DEBUG] agesawrapper_amds3laterestore() entry
[DEBUG] Error: Can't find 57a9e200 raw data to imd
[ERROR] S3 volatile data not found
TEST=build/boot google/liara, verify S3 resume succeeds.
Change-Id: I49659b4e5aba42367d6347e705cd92492fc34a0f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Pre-Zen SoCs like Stoneyridge call into an AGESA binary as part of S3
resume, which will fail if SMM is locked, causing the device to
(eventually) cold boot. To mitigate this, add a new Kconfig to enable
"late" SMM locking, which restores the previous behavior prior to
commit 43ed5d2534 ("cpu/amd: Move locking SMM as part of SMM init").
TEST=tested with rest of patch train
Change-Id: I9971814415271a6a107c327523a0a7c188a91df6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78352
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move all security patch level (SPL) related Kconfig options to the
common AMD PSP Kconfig file. Commit 4ab1db82bb ("soc/amd: rework SPL
file override and SPL fusing handling") already reworked the SPL
handling, but missed that another Kconfig option
SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL controlled if the PSP mailbox command
to update the SPL fuses was sent by the code that got added to the build
when PERFORM_SPL_FUSING was selected.
To make things less unexpected, rename PERFORM_SPL_FUSING to
SOC_AMD_COMMON_BLOCK_PSP_SPL since it actually controls if the SPL
support code is added to the build and also rename
SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL to PERFORM_SPL_FUSING. This changes
what PERFORM_SPL_FUSING will do from including the code that could do
the fusing if another option is set to being the option that controls if
the fusing mailbox command will be set. All SoCs that support SPL now
select SOC_AMD_COMMON_BLOCK_PSP_SPL in their Kconfig, which won't burn
any SPL fuses.
The logic in the Skyrim mainboard Kconfig file is reworked to select
PERFORM_SPL_FUSING for all boards on which the SPL fuses should be
updated; on Guybrush PERFORM_SPL_FUSING default is changed to y for all
variants. The option to include the code that checks the SPL fusing
conditions and allows sending the command to update the SPL fuses if the
corresponding Kconfig is set doesn't need to be added on the mainboard
level, since it's already selected at the SoC level.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I12fd8775db66f16fe632674cd67c6af483e8d4e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Supports a brand new ACP driver for STONEY / Grunt chromebooks.
AMD's Audio CoProcessor handles i2s/tdm audio, and is located on the
GPU.
On Windows the PCIe device for the GPU is owned by the AMD proprietary
driver, hence a separate device has to be added for the ACP driver.
Fortunately since IOMMU is disabled on STONEY, the driver itself can
pull BAR5 from the GPU and use that to initialize, so no special
configuration is required in ACPI other than the ID.
Change-Id: I0e31c3b31fa9fb99578c04b79fce2d8c1d695561
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the devicetree at their related root ports.
Change-Id: I85f7c0ddebf88dd21e6c2603ce45f0a4fc868d51
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78600
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the devicetree at their related root ports.
While on it, remove superfluous comments related to modified settings.
Change-Id: I67f4fdcfb59da6c594c89d7ad3ee7f2ddbbea69b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78592
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the devicetree at their related root ports.
Change-Id: I25b87a157e934640355442edceb0760827dc7a43
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78591
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they will be moved
into the devicetree to their related root ports at some later point.
While on it, remove superfluous comments related to modified settings.
Change-Id: I19af8c6b1167af793eb18b000fd93ec409385587
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78597
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
DDR2 already had a define to specify the SPD length, but other memory
types did not. This led to the value being coded into other locations.
Unify the definition for DDR2 to DDR5 and put the value at the top of
the respective header file.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id13b9c5d311984d4a98b831a8746d1659724aa96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78601
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
For Sandy Bridge boards with MRC raminit support, migrate as much
MRC settings to devicetree as possible, to stop mainboard code from
needlessly overwriting entire PEI data structure, so they will not
interfere with upcoming transition to one standard Haswell way of
providing SPD info to northbridge.
Some exceptions allowed are described below and in code comments.
SPD-related items are kept out of devicetree for now. They will be
migrated (with a different representation) with the Haswell SPD
transition.
google/{butterfly,link,parrot,stout} have max DDR3 frequency set in
pei_data to 1600 (2*800), but in devicetree to 666. The reason for the
difference seems to be problems with native raminit code. These are
converted into ternaries tied to CONFIG_USE_NATIVE_RAMINIT, with an
added "fix me" tag. asus/p8x7x-series also needs the same treatment,
based on testing various memory on p8z77-m hardware.
TEST=Builds on all affected boards. asus/p8z77-m still works with multiple RAM modules tested.
Change-Id: Ie349a8f400eecca3cdbc196ea0790aebe0549e39
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
psys_pmax_watts is configured in SoC node of devicetree.
Value represents Watts the PSU provides.
Zero means automatic/default configuration (not optimal).
BUG=b:289853442
TEST=Build google/rex/ovis4es target board
Change-Id: I69afa06110254f6384352c062891c0c9c0b23070
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76796
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id b1741d184add (2023-10-04):
PCO: Update SMU firmware to 4.30.77.200
to commit id edd465837e26 (2023-10-20):
cezanne: Update PSP binaries to release 0.11.11.75
This brings in 4 new commits:
edd465837e cezanne: Update PSP binaries to release 0.11.11.75
480c9d2efd picasso: Update PSP binaries to release 0.8.13.7B
1b1fd40889 Stoneyridge: Update SMU firmware for fanless/kicker to 33.10.0
c99172d385 Stoneyridge: Update SMU firmware to 26.17.0
Change-Id: I1fc1756a204e5f637ca67ef51daf4592572a6a17
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Update the filename for the PSP_SMUFW2_SUB1_FILE to use the compressed
and signed version (.csbin) rather than the uncompression + signed
version (.sbin), in order to be consistent with the other SMU firmware
files. This will also facilitate dropping the duplicate files in an
upcoming update to the amd_blobs repo and updating the SMU files (all
of which are .csbin).
This change is actually a no-op since the .csbin and .sbin are the same
file; it appears that the .sbin file was incorrectly named when added,
and then the same file was added later with the correct extension.
TEST=build/boot google/kahlee (liara)
Change-Id: I10fa8e949ab589d315862c06b4125c902520cbbc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In EC versions older than 1.18, if the mirror flag was enabled, the
EC would mirror once the system reached S5.
When a mirror is successful, the system will automatically power
on, as it acts like it's been in G3. This led to machines turning on
when the intention was them to be off.
In 1.18 and later, they're installed when turning on. The result was
slower boot times when mirroring, but no unwanted powering on.
Because of this, coreboot no longer needs to power off when setting
the mirror flag.
Change-Id: I973c1ecd59f32d3353ca392769b44aadf5fcc9c3
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78200
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Disable the GpioOverride UPD in FSP M, and comment out the Clock Request
GPIOs to ensure that coreboot doesn't touch them.
This solves behaviour that can only be described as weird:
* Devices connected to Root Ports don't initialise
* Hang seen when entering S5
* Hang when edk2 is reached
Change-Id: Idf8d2112a1c44064af73bb54fd3e1a1a429e0649
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Create an event handler for the PEWAKE# GPIO and notify the device
driver to wake up the device.
BUG=b:301150499
TEST=Compiled and tested on google/redrix:
1. Enable runtime suspend for linux mtk_t7xx driver
2. Wait for device to enter suspended state
3. Modem should be able to wake up driver, e.g. on SIM card insert/eject
The interrupts should show up under /proc/interrupts as ACPI:Event
Signed-off-by: Paweł Anikiel <panikiel@google.com>
Change-Id: I32257689da85ea71f9de781093b3ede0cfe70a0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78297
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This signal gets deasserted by the WWAN modem to reactivate the PCIe
link when in low power mode. In order to handle this efficiently, the
kernel needs to set up an interrupt.
BUG=b:301150499
TEST=Compiled and tested on google/redrix
Signed-off-by: Paweł Anikiel <panikiel@google.com>
Change-Id: I37f6836aefe4a374eaff3e4bc11358be274cf563
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78416
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
When walking the devicetree to generate the list of devices and minimum
sleep states, skip any devices which have the disable or hidden flags
set. This prevents adding entries for devices which are not present,
which are hidden (and likely to not have a min sleep state entry), or
generating duplicate entries in the case of PCIe remapping.
Any of these conditions are considered invalid by Windows and will
result in a BSOD with an INTERNAL_POWER_ERROR.
TEST=tested with rest of patch train
Change-Id: I06f64a72c82b9e03dc8af18700d24b3d10b7d3a7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Users have reported audio cutting in and out when playing through the
speakers on bonw15 and oryp11. This issue originally only affected
serw13 and was fixed before upstreaming. Apply the updated HDA verb
provided by Clevo to fix speaker output on these units as well.
Change-Id: I105bf165227456593863faa9bb8c4f152e49796b
Signed-off-by: Levi Portenier <levi@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Tested-by: Daniel Sutton <daniel@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Some Type-C monitors do not immediately assert HPD. If we enter FSP-S
before HDP is asserted, display initialisation may fail. So wait for
HPD.
This is similar to commit b40c600914 ("mainboard/hatch: Fix puff DP
output on cold boots") on puff, except we don't use
google_chromeec_wait_for_displayport() since that EC command was removed
for TCPMv2 (https://crrev.com/c/4221975). Instead we use the HPD signals
only. By waiting for any HPD signal (Type-C or HDMI), we skip waiting if
HDMI is connected, which is the same behaviour as puff and fizz.
BUG=b:303533815
BRANCH=dedede
TEST=On dexi, connect a display via a Type-C to HDMI dongle and check
the dev and recovery screens are now displayed correctly. Also check the
logs in the following cases:
Cold reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 800 ms
Warm reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct Type-C:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct HDMI:
HPD ready after 0 ms
Cold/warm reboot in dev mode, no display:
HPD not ready after 3000 ms. Abort.
Change-Id: Ib4fc071cac98a542072ffbeb6943bff4c988554c
Signed-off-by: Kenneth Chan <kenneth.chan@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78450
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After commit e12b313844 ("drivers/pc80/rtc/option.c: Allow CMOS
defaults to extend to bank 1"), Thinkpad X200 with
CONFIG(STATIC_OPTION_TABLE) can no longer resume from s3 (detected via
bisect).
Further inspection shows that DRAM training result of GM45 is stored
in CMOS above 128 bytes in raminit_read_write_training.c, for s3 resume
to restore, but it will be erased by sanitize_cmos(), which now clears
both bank 0 and bank 1, leaving only "untrained" result restored, so s3
resume will fail.
However, resetting CMOS seems unnecessary during s3 resume. Now,
cmos_need_reset will be negated when acpi_is_wakeup_s3() returns true.
Tested: Thinkpad X200 with CONFIG(STATIC_OPTION_TABLE) can resume from
s3 again with these changes.
Change-Id: I533e83f3b95f327b0e24f4d750f8812325b7770b
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78288
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clevo had apparently swapped the Realtek card reader for the O2 Micro
card reader for newer batches of all TGL models. Enable the BayHub
driver on everything (except bonw15, which doesn't have a card reader)
to fix LTR programming, as was done for other in commit 3d7a5bdf58
("mb/system76: Enable DRIVERS_GENERIC_BAYHUB_LV2 to fix LTR issue").
Tested on system76/galp5: CPU reaches C-states deeper than C2 when idle.
Change-Id: I3667e08acd23c12638159a2f7d2592737a34e63d
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Update Goodix touchpad HID to GDIX0000 for GXTP7288 and GXTP7863.
BUG=b:305118852
BRANCH=firmware-dedede-13606.B
TEST=Build and touchpads are workable
# evtest for GXTP7863
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Lid Switch
/dev/input/event1: Power Button
/dev/input/event2: AT Translated Set 2 keyboard
/dev/input/event3: cros_ec_buttons
/dev/input/event4: Elan Touchscreen
/dev/input/event5: GDIX0000:00 27C6:0D51 Mouse
/dev/input/event6: GDIX0000:00 27C6:0D51 Touchpad
# evtest for GXTP7288
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Lid Switch
/dev/input/event1: Power Button
/dev/input/event10: GDIX0000:00 27C6:01F5 Touchpad
/dev/input/event11: sof-da7219max98360a Headset Jack
/dev/input/event12: sof-da7219max98360a HDMI/DP,pcm=2
/dev/input/event13: sof-da7219max98360a HDMI/DP,pcm=3
/dev/input/event14: sof-da7219max98360a HDMI/DP,pcm=4
/dev/input/event2: AT Translated Set 2 keyboard
/dev/input/event3: cros_ec_buttons
/dev/input/event4: ELAN900C:00 04F3:2E5D
/dev/input/event5: ELAN900C:00 04F3:2E5D UNKNOWN
/dev/input/event6: ELAN900C:00 04F3:2E5D UNKNOWN
/dev/input/event7: ELAN900C:00 04F3:2E5D Stylus
/dev/input/event8: ELAN900C:00 04F3:2E5D Stylus
/dev/input/event9: GDIX0000:00 27C6:01F5 Mouse
Change-Id: Id2a6223bdbb2f0693149136baa853ca2efb57815
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
When CBFS verification is enabled, add amdfw_a/b.rom at offset 128 bytes
to account for CBFS file header with hash attribute. When CBFS
verification is disabled, add amdfw_a/b.rom at offset 64 bytes to
account for CBFS file header without hash attribute.
BUG=None
TEST=Build Skyrim, Myst BIOS images with and without CBFS verification
enabled.
Change-Id: Ic374ac41df0c8fb8ce59488881ce5846e9058915
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78425
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Some stalls are observed while using CCP DMA in PSP verstage -
especially with CBFS verification enabled. Also with RW CBFS
verification enabled, the entire firmware body is not loaded during
verstage for verification. Instead the files are verified as and when
they are loaded from CBFS. Hence the impact to boot time is reduced
since only few files are loaded during PSP verstage. Hence disable CCP
DMA in PSP verstage until the root cause is identified.
BUG=None
TEST=Build and boot to OS in Myst with CBFS verification enabled.
Change-Id: I22ac108b08abcfe432dfd175644393e384888e11
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78234
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add SPI flash RO ranges to be verified by GSC in order to enable CBFS
verification. Also with CBFS verification enabled, CBFS metadata is
more than 64 bytes. So configure the offset of amdfw_a/b to 128 bytes -
next address aligned to 64 bytes.
BUG=b:277087492
TEST=Build and boot to OS in Myst with and without CBFS verification
enabled.
Change-Id: Ibfffd3d6fce8b80ec156a7b13b387e1df8c43347
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78233
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Meteor Lake TME bits [42-45] are reserved regardless of if the part
supports TME or not.
On a device with TME fused off, we noticed some reboot hangs which
have been narrowed down to internal IP routing issues when the IA
accesses the Input Output Manager (IOM) which is mapped at
0x3fff0aa0000 (0x3ff upper 32 bits).
It turns out since TME is fused off, coreboot uses the full physical
address size reported by CPUID MAXPHYADDR (46 bits). Therefore, it
allocates thunderbolt memory range on 46 bits (0x3fff upper 32 bits).
Since 4 of these bits are actually reserved, it seems that this
address range is "stripped down" to 42 bits (=> 0x3ff upper 32 bits)
resulting in potential conflict with other devices such as IOM.
BUG=b:288978352
TEST=No reboot issue on rex with TME fused off
Change-Id: I96ba23ab304257003c0413243d3ac8129ce31743
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78452
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According the Intel Software Developer Manual,
CPUID.80000008H:EAX[15:8] reports the physical-address width supported
by the processor. Unfortunately, it does not necessarily reflect the
physical-address space the system can actulally use as some of those
bits can be reserved for internal hardware use.
It is critical for coreboot to know the actual physical address size.
Overestimating this size can lead to device resource overlaps due to
the hardware ignoring upper reserved bits. On rex for instance, it
creates some reboot hangs due to an overlap between thunderbolt and
Input Output Manager (IOM) address space.
As some SoCs, such as Meteor Lake, have physical address reserved bits
which cannot be probed at runtime, this commit introduces
`CPU_INTEL_COMMON_RESERVED_PHYS_ADDR_BITS' Kconfig to set the number
of physical address reserved bits at compilation time for those SoCs.
A runtime detection by hardware probing will be attempted if the value
is 0 (default).
BUG=b:288978352
Change-Id: I8748fa3e5bdfd339e973d562c5a201d5616f813e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78451
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `RAMSTAGE_CBFS_CACHE_SIZE' Kconfig to
set a ramstage CBFS cache size. A cache size of zero disables the
CBFS cache feature. The default size is 16 KB which seems a
reasonable minimal value large enough to satisfy basic needs such as
the decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
To support S3 suspend/resume use-case, the CBFS cache memory cannot be
released to the operating system. There are two options to meet this
requirement:
1. Define a static CBFS cache buffer (located in the .bss section)
2. Create a new CBMEM entry
Option #2 seems more powerful but considering that:
1. The CBFS cache is actually not a cache but just a scratch pad
designed to be isolated between stages
2. postcar is a very short stage not really needing CBFS cache
3. The static initialization of the `cbfs_cache' global
variable (cf. src/lib/cbfs.c) offers a simple and robust design
=> It is simpler to use a static buffer and limit the support to
ramstage.
Since some AMD SoCs (cf. `SOC_AMD_COMMON_BLOCK_NONCAR' Kconfig) define
a `_cbfs_cache' region, an extra `POSTRAM_CBFS_CACHE_IN_BSS' Kconfig
must be set to enable the use of a static buffer as the CBFS cache
scratchpad.
TEST=Decompression of vbt.bin in ramstage on rex using cbfs_map()
Change-Id: I7fbb1b51cda9f84842992e365b16c5ced1010b89
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77885
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set
the pre-memory stages CBFS cache size. A cache size of zero disables
the CBFS cache feature. The default value is 16 KB which seems a
reasonable minimal value enough to satisfy basic needs such as the
decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
We have set this size to zero for all the platforms without enough
space in Cache-As-RAM to accommodate the default size.
TEST=Decompression of vbt.bin in romstage on rex using cbfs_map()
Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The linker can make relocation entries of a symbol which has a value
of zero point to the undefined symbol entry. It is permitted since
when the symbol value is zero as the documentation of the relocation
entry `r_info' field states:
"If the index is STN_UNDEF, the undefined symbol index, the relocation
uses 0 as the symbol value."
The ELF binary does not really have any missing symbols. It is an
optimization as the symbol points to the undefined symbol because its
value is zero.
A typical way to hit this cbfstool limitation is to define an empty
region using the REGION macro in the linker script. Here is an
example if we assume `CONFIG_MY_REGION' is set to 0:
.car.data {
[...]
REGION(my_region, CONFIG_MY_REGION_SIZE)
[...]
}
A region is defined as follow:
#define REGION_SIZE(name) ((size_t)_##name##_size)
#define DECLARE_REGION(name) \
extern u8 _##name[]; \
extern u8 _e##name[]; \
extern u8 _##name##_size[];
So the size of the region is actually the address of the
`_##name##_size' symbol. Therefore, the `_my_region_size' symbol
address is zero and the linker can make the relocation entry of this
symbol point to the undefined symbol index.
In such a situation, cbfstool hits a segmentation fault when it
attempts to relocate the symbol in `parse_elf_to_xip_stage()'
function. We resolves this issue by making cbfstool skips relocation
entries pointing to the undefined symbol similarly to the way it skips
relocation relative to absolute symbols. A symbol which value is zero
can be considered an absolute symbol and therefore should not be
relocated.
Of course, we could argue that we could just prevent the declaration
of an empty region as illustrated in the following example:
.car.data {
[...]
#if CONFIG_MY_REGION_SIZE > 0
REGION(my_region, CONFIG_MY_REGION_SIZE)
#endif
[...]
}
However, this is not a satisfying solution because:
1. It requires to add unnecessary code in the linker script as an empty
region is a valid declaration. Such a workaround requires the code
using it to mark the region symbols as weak symbols to handle the
situation where the region is not defined.
2. There could be other situations which have yet to be uncovered which
would lead the same cbfstool crash.
3. A binary with an empty region is a valid ELF file and cbfstool
should not crash when it is asked to create an eXecute-In-Place stage
out of it.
Change-Id: I2803fd3e96e7ff7a0b22d72d50bfbce7acaeb941
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Update SaGv gears and frequency values as per recommendation
from power and performance team. This change doesn't cause
negative impact on firmware boot time performance.
BUG=b:274137879
TEST=Verified the settings on google/rex using debug FSP logs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ie8a81c05f25b1cdab1008d09c606d1debea6e6e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Crypto Engine in PSP prefers the buffer from Static RAM (SRAM). Hence if
a buffer comes from within SRAM address range, then it is passed
directly to Crypto Engine. Otherwise a bounce bufer from the stack is
used. But on SoCs like Picasso where PSP Verstage stack is mapped to a
virtual address space this check fails causing a bounce buffer to be
used and hence a stack overflow. Fix this issue by assuming that the
buffer comes from the SRAM always in such SoCs and pass the buffer
directly to crypto engine.
BUG=b:259649666
TEST=Build and boot to OS in Dalboz with unsigned PSP verstage.
Change-Id: I2161c8f0720c770efa5c05aece9584c3cbe7712a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The Bayhub BH720 eMMC bridge is a fixed internal device, and needs to
me marked as non-removable in order for Windows to properly recognize/
utilize the device. Add the necessary ACPI to be generated at runtime.
TEST=build/boot/install Win11 on google/kahlee (liara)
Change-Id: I0815abf1d2dc5cfe785dc04670ab91f2a6a1af23
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
AMD Audio CoProcessor handles I2S audio on AMD SoC's. Prior to AMD
Ryzen platforms (e.g. STONEY) it is located on the Integrated GFX
device. As the proprietary AMD driver does not support accessing this
easily, reserve a custom ACPI ID from the coreboot namespace so that
another driver can be attached in Windows device manager.
Change-Id: I855b81908ed9ad0587b6367b052c726c36350208
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This Kconfig option is used as a failback when `get_uint_option`
fails. It will fail after coreboot is flashed, as the cfr code has
not yet setup the options.
Change the default to OFF, so when it does fallback, it's the correct
behaviour.
Change-Id: I5d06047fe23322520e9c84ded8f1941f6d716a51
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This adds support for the Librem 11 tablet, using the ME 13.50.15.1436
binary from the original BIOS (version 28.D8.E1.021) and FSP binaries
from a Jasper Lake Chromebook.
The following features were tested with PureOS:
* Audio (speakers, microphone, headset jack)
* Cameras
* Display
* Touchscreen and pen
* Keyboard cover, with tablet/laptop mode switch indicated via ACPI
* Power and volume buttons
* USB-C ports (USB 2/3, DP alt mode, PD charging)
* SD card reader
* WLAN
* Bluetooth
* NVMe SSD (socketed)
* Battery state information from EC
* Accelerometer
A UART is accessible with soldering via test points on the mainboard,
documented in the mainboard Kconfig with a toggle to enable it for
coreboot logging.
Change-Id: I545994889ddfb41f56de09b3a42840bccbd7c4aa
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The next board revision of Librem 14 (v1-02) has replaced the ALC256
codec with ALC269. Add verbs for it.
Two GPIOs were changed from SMBus native functions to NC for this
revision. They are not used on either revision, change to NC.
Change-Id: I43b6265d2f502c05d5539ff3abf53ade0da6d706
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78347
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
New Librem 14s have a newer CPU stepping, which changes them from CML
v1 to v2. The product is not significantly different and remains v1,
specifically "v1-02".
Select SOC_INTEL_COMETLAKE_1_2 to support all CPU steppings.
Change-Id: Iab37208b81e973714a2c088d2346eda518bf1214
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Define SOC_INTEL_COMETLAKE_1_2, which creates a build supporting both
Comet Lake v1 and v2 by including both sets of FSP binaries and
selecting one based on the CPUID.
A mainboard can select this instead of SOC_INTEL_COMETLAKE_1 or ..._2
to support all CML-U steppings in one build.
Change-Id: Ic8bf444560fd6b57064c47faf038643fabde010e
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78345
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Support embedding a second FSP-M/FSP-S binary for an SoC that can
select one at runtime.
Comet Lake v1 and v2 are different steppings of the same SKUs, but they
require different FSP binaries. Supporting both in a single build
requires embedding both FSPs and selecting one at runtime based on the
CPUID. This is desirable for a product that may have different CPU
steppings but is not otherwise differentiated enough for a separate
firmware build.
An SoC can select PLATFORM_USES_SECOND_FSP to indicate that two FSP-M/
FSP-S binaries are required. Implement soc_select_fsp_m_cbfs() and
soc_select_fsp_s_cbfs() to choose one based on platform-specific
criteria. For Comet Lake, the first FSP is CML v1 and the second is
CML v2, but in principle a platform could define any meaning for the
first and second FSP.
FSP-T is not affected, only one FSP-T can be embedded if FSP_CAR is
used.
Only one set of FSP headers is used, which is sufficient for Comet Lake
v1/v2; their headers are equivalent.
ADD_FSP_BINARIES, FSP_USE_REPO, and FSP_FULL_FD are supported for both
sets of FSP-S/FSP-M but cannot be configured separately, both use the
same configuration.
Change-Id: Ied4c6c49a6bdf278238272edd47a2006258be8e5
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78344
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Within TBT PCIe, following register offsets have been updated for
production silicon. Update ASL with new offsets.
1. MPC - Miscellaneous Port Configuration Register
2. RPPGEN - Root Port Power Gating Enable
3. SMSCS - SMI/SCI Status Register
BUG=306026121
TEST= Check TBT PCIe Tunnel creation and device enumration.
Change-Id: I0497f7108ef5046c2694aece232263582514a0c5
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78163
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Commit bd9c562a9e ("acpi: Configure
slp-s0 residency counter frequency in LPIT table") led to jenkins
reporting the following error:
!!!!! Error: defined(CONFIG_ACPI_SOC_INTEL_SLP_S0_FREQ_HZ)
used at src/include/acpi/acpi.h:457. Symbols of type 'hex'
are always defined.
Since hex Kconfig are always defined there is no need to test it being
defined but also no need to handle zero or non-zero values.
In addition:
1. This config was defined in Meteor Lake specific Kconfig file while
it should actually be define closer to where it is being used (here
soc/intel/common/block/acpi/Kconfig) and only set by the SoC Kconfig.
2. Once moved and under control of `SOC_INTEL_COMMON_BLOCK_ACPI_LPIT'
gating (lpit.c), the Kconfig name needed to be adjusted to better fit
its use.
3. Make Meteor Lake Kconfig sets the config but does not define it
anymore.
TEST=LPIT ACPI table Counter Frequency field is set to 0x2005 on rex
Change-Id: I2083c9209e61be6180cca2c9f74097e2f4b4ce9a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78458
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The microcode for RPL-S C0 and H0 is actually available, however, the
name of the file contained a typo: 06-b7-05 vs 06-bf-05. Fix the typos
in the comments.
Moreover, the ADL-S C0/H0 microcode file 06-97-05 has the same sha256
sum as the equivalent RPL-S C0/H0 microcode file 06-bf-05. The sha256
sum of ADL-S/RPL-S C0/H0 microcode on intel-microcode tag
microcode-20230808:
5d8d4a4d5456c43b7cc04937c80aec094ccbf3bd89f34ffa5182913ef944a9f9
Update the comments to correctly indicate supported CPU steppings.
Change-Id: I4c848e0dfc40f6c8e26a9b31e7c4cf4c5a09128f
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78413
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SCI handler for the GPE associated with the Super I/O did not clear
the respective PME status bits resulting in the SCI reoccurring
endlessly. The /proc/interrupts reported millions of ACPI interrupts
generated in just a few minutes of uptime. The flood of interrupts
caused some units to be unusable in extreme cases once attempted to
boot Qubes OS for example. On systems like Qubes OS it had a huge
impact on performance due to many IPCs the SCIs caused under Xen.
Clear the PME bits of devices that report a PME event. Then clear
the global PME status bit at the end of SCI handler to prevent the SCI
from asserting again until a new event occurrs. With this change
the number of ACPI interrupts generated in the first minutes of uptime
settles at a few thousands.
TEST=Boot Qubes OS R4.1.2 on Dell OptiPlex 9010 SFF and check
/proc/interrupts in dom0 if the number of ACPI interrupts is only
a few thousands.
Change-Id: I64e03d268138a62b46084be41343ef7fb089dfc3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Package C-state auto demotion feature allows hardware to determine lower
C-state as per platform policy. Since platform sets performance policy
to balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter below PC8 state and
additional power savings ~30mW in Local-Video-Playback scenario.
Change-Id: I6ff408280178a24686180f72f79522d2741607a1
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78278
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel platforms use Low Power Idle Table (LPIT) to enumerate platform
Low Power Idle states. There are two types of low power residencies
a) CPU PKG C10 - read via MSR (Function fixed hardware interface)
b) Platform Controller Hub (PCH) SLP_S0 - read via memory mapped
Ref. https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
System sleep time (SLP_S0 signal asserted) is measured in ticks,
varies in every platform and based on PMC clock.
BUG=b:300440936
TEST=check kernel cpuidle sysfs for non-zero residency after s0ix cycle
and both must match
cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
Change-Id: I401dd4a09a67d81a9ea3a56cd22f1a681e2a9349
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78164
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the IGD joins the MBUS when the firmware splash
screen feature is enabled (aka BMP_LOGO config is enabled).
For ChromeOS platform, it prevents the i915 driver from reinitializing
the display, which can save up to 75ms-80ms of boot time and eliminate
a brief period of blank screen between the firmware splash screen and
the OS login prompt.
BUG=b:284799726
TEST=Able to build and boot google/rex.
Change-Id: I36af167afa902053a987602d494a8830ad9b1b1a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch implements `.final` hooks for the IGD device to perform the
required operations before handing the control to the payload or OS.
The MBUS (Memory Bus) is a high-speed interface that connects the
graphics controller to the system memory. It provides a dedicated data
path for graphics data, which helps to improve graphics performance.
The MBUS is a key technology that helps to make the Intel i915 driver
powerful and versatile graphics drivers available. It provides the
high-speed data transfer capabilities that are essential for smooth
and responsive graphics performance.
Enable this config to ensure that the Intel GFX controller joins the
MBUS before the i915 driver is loaded. This is necessary to prevent
the i915 driver from re-initializing the display if the firmware has
already initialized it. Without this config, the i915 driver will
initialize the display to bring up the login screen although the
firmware has initialized the display using the GFX MMIO registers and
framebuffer.
Kernel graphics driver can avoid redundant display init by firmware,
which can optimize boot time by ~15ms-30ms.
Ensures hashing mode is 1x4 to enable a single pipe between Pipe A or B.
Typically, internal display is on Pipe-A, so 1x4 restricts MBUS joining
to internal display alone.
BUG=b:284799726
TEST=Able to build and boot google/rex
Change-Id: I60ae76dc783383e027e66edbcdeeb535472caeb1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78385
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 9b230ae295 introduced a redefinition of the config option
`BOARD_GOOGLE_BROX`, which is already defined in Kconfig.name
accordingly and thus causing a Kconfig warning. Fix that by removing the
type redefinition.
Change-Id: Iea6219a686a23d8d48a0bfb6ac642efd482fded9
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78394
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the anraggar variant of the nissa reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:304920262
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_ANRAGGAR
Change-Id: I95e72188679fc825c94c4043ed02b0aad310c6a3
Signed-off-by: wuweimin <wuweimin@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This script lists all new commits from users with few merged commits.
By default, it looks at the last week, and considers anyone with fewer
than 5 commits merged to be a new user.
Currently the only command line argument that's accepted is the gerrit
username of the person running the query. To modify any of the other
options, the values hard-coded into the script need to be updated.
To keep down the number of repeated queries, the script saves lists of
users considered to be experienced, as well as the commits from new
users that it lists.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic698798f3fddc77900c8c4e6f8427991bda3f2d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
This patch adds support for detecting dual displays (eDP and HDMI) on
Intel platforms. This information is useful for setting the
`lb_framebuffer.has_external_display` variable, which is used to
determine whether depthchage should avoid shutting down when an
extended display is present.
TEST= Able to build and boot google/rex, where depthchage now
successfully avoids shutting down when both eDP and HDMI displays
are attached.
w/o this patch:
with eDP and HDMI attached: .has_external_display=0
with eDP attached: .has_external_display=0
with HDMI attached: .has_external_display=1
w/ this patch:
with eDP and HDMI attached: .has_external_display = 1
with eDP attached: .has_external_display=0
with HDMI attached: .has_external_display=1
Change-Id: Ie39d48da75a21e3508a1fbcf09da31caedaa1c0a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78383
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reserve SBREG BAR if it is outside of the PCH reserved memory range.
Desktop series processors have larger SBREG BARs, which, unlike mobile
processors, do not fall into the standard PCH reserved range
(0xfc800000 - 0xfe7fffff). Create a separate reservation for such a case. There is no telling what could happen if the reservation is not
made in ACPI.
TEST=Boot Windows 11 and Ubuntu 22.04 on MSI PRO Z690-A DDR4
Change-Id: Ibaf45daba37e3acfcea0e653df69fa5c2f480c4a
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77445
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
When battery level is below critical level or battery is not present,
cpus need to run with a power optimized configuration to avoid platform
instabilities. This will check the current battery status and configure
cpu power limits properly.
BUG=b:296952944
TEST=Build rex0 and check cpu power limits are configured with
a performance efficient configuration and the platform boots to OS if
battery level is above the critical level. And check cpu power limits
are configured with a power optimized configuration and boots to OS
without an issue if battery is not present or battery level is at or
below critical level.
Change-Id: I12fd40abda76c8e7522b06a5aee72665f32ddec8
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78322
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds is_battery_present_and_above_critical_threshold to check the
battery is present and the battery level is above critical level.
BUG=b:296952944
TEST=Build rex and check is_battery_present_and_above_critical_threshold
returns the correct battery status.
Change-Id: Ib38be55bc42559bab4f12d5e8580ddc3e1a6acc1
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This CL is just getting the initial brox framework to get the
baseboard building. Copied files from brask baseboard and tried to
remove contents of some files like the device tree and memory IDs.
Added support for memory part "MT62F512M32D2DR-031 WT:B", mapped to
DRAM ID 0.
BUG=b:300690448
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_BROX -x -a
Change-Id: I929b465646ac4c69d4bab33ce23848c7b1fa0f98
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Because integrated PCI devices are hidden in chip_ops
the PCI enumeration code never sees them.
When hiding static devices mark them as hidden so the
PCI enumeration no longer complains about them being
missing, even though they are present and were working
just fine.
Test: Disabled southbridge devices no longer appear in
"Leftover static devices:" log.
Change-Id: Iae70072a85b62a456102190a5f72f4d652ad6d5a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Warn when a device took longer than usual to appear.
Use the PDS bit to detect if a root port has a downstream
device connected and warn if enumeration failed.
Test: On Lenovo X220 all PCIe device are visible, thus the
added code path is never taken.
Change-Id: I86b498b89d672b239d9951e116dc3680030666a6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78229
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Use pci_find_capability() and defines from pci_def.h
- Set the 'Hotplug Capable' bit and 'Hot Plug Surprise' bit in SLCAP
for hotplugable PCIe slots.
- Assign unique slot number and set power limit for PCIe root ports
that have a slot connected. For integrated devices clear slot number
and power limit.
Test: System still boots and all PCIe devices are working.
Change-Id: I03aeb0a1ff0041901acc20fe700d3f7995d22366
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This commit adds all the individual authors and their companies, as
determined by their email addresses. Because it is very difficult to
figure out if an individual is doing work on their own, or on the
company's behalf, both are being added.
This will be maintained as a part of the release process from here on.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id199f1c5d49d74290002d46dbdfc1d33b0fb55e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78286
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
On ICH9 the SPI control register is not naturally aligned
and a word write might be split into smaller naturally aligned
I/O transactions.
As the first byte starts a new SPI transfer, replace the existing
word write with two byte writes and write the second byte first.
This is required for platforms that do not support unaligned
word I/O instructions and would start a SPI transfer while the
second byte hasn't reached the control register yet.
TEST: Virtual SPI controller on qemu 8.0 doesn't start a transfer
early.
Change-Id: Id05b1a080911b71b94ef781c6e26d98165f02f67
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
We have a tiny HEAP_SIZE by default, except when we don't, and
mainboards that override it, or not.
Since memory isn't exactly at a premium these days, and unused heap
doesn't cost anything extra, just crank it up to the highest value
we have in the tree by default and remove all overrides.
Change-Id: I918a6c58c02496e8074e5fba06e38d9cfd691020
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78270
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check for pkg-config presence and fail out with actionable message.
BUG=b:302521446
TEST=Build successfully with working pkg-config and failed build with no
pkg-config
Change-Id: I5d604145c919e7f71680d1e095dc68cb21868319
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Some Type-C monitors do not immediately assert HPD. If we enter FSP-S
before HDP is asserted, display initialisation may fail. So wait for
HPD.
This is similar to commit b40c600914 ("mainboard/hatch: Fix puff DP
output on cold boots") on puff, except we don't use
google_chromeec_wait_for_displayport() since that EC command was removed
for TCPMv2 (https://crrev.com/c/4221975). Instead we use the HPD signals
only. By waiting for any HPD signal (Type-C or HDMI), we skip waiting if
HDMI is connected, which is the same behaviour as puff and fizz.
TEST=On dibbi, connect a display via a Type-C to HDMI dongle and check
the dev and recovery screens are now displayed correctly. Also check the
logs in the following cases:
Cold reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 800 ms
Warm reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct Type-C:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct HDMI:
HPD ready after 0 ms
Cold/warm reboot in dev mode, no display:
HPD not ready after 3000 ms. Abort.
Change-Id: Id4657b5d5a95a68ecbd9efcf3585cf96ad1e13e1
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Internal testing showed that CPU heatsink gets hot and temperature
goes over 75C. In this situation, the fan does not even start
to lower down CPU temperature. This is because of existing temperature
thresholds of TSR0 and TSR1 sensors are set at 45C to start fan.
With updated new settings based on tuning from thermal team,
the fan starts early at 43C for TSR0 and TSR1 so the CPU temperature
stays below 75C.
BUG=b:302673874
TEST=Built and tested on google/rex board
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: I6580652d6165946e98ecf1b46ace3352cd34dcdf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Follow the PCH BIOS spec more closely by porting the broadwell
and braswell PCIe downstream device detection. To safe power
disable PCIe root ports that have no downstream device connected.
By setting the FLAGS_SLOT bit in register PCI_EXP_FLAGS the
PCI_EXP_SLTSTA_PDS bit will be updated with in band device
detection from the PCIe PHY. While this is primarly used for PCIe
hot-plug detection, it is more reliable than probing for downstream
devices by reading DID/VID PCI registers.
The FLAGS_SLOT bit should stay cleared for integrated devices,
as those are known to be present, but to simplify the code all
PCIe ports will have the FLAGS_SLOT bit set. There currently
used devicetrees might also be lacking integrated devices on
the PCH root ports...
The SLOTCAP field must be updated by BIOS when the FLAGS_SLOT
is set, but it shouldn't be filled for integrated devices. Until
now the SLOTCAP field has always been populated and it never
was a problem.
- Set FLAGS_SLOT "Slot Implemented" bit early.
- Read bit PCI_EXP_SLTSTA_PDS to detect connected downstream
devices as done on braswell.
- Disable unused PCIe slots that are not hotplugable.
- Set BIT26 in register 0x338 and wait for bits in register 0x328
to clear as done on broadwell.
Test: Tested on Lenovo X220. Unused root ports are disabled and port
that are in used or marked hot-plug are kept enabled.
Change-Id: I8ccfcab2e0e4faba8322755a4f8c2108d9b007ac
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78226
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Dojo fails to boot from NVMe with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN
enabled. The root cause is using __fls() will get a smaller value when
the size is not a power of 2, for example, __fls(0x3000000) = 25. Hence
the PCIe translation window size is set to 0x2000000. Accessing
addresses higher than 0x2300000 will fail.
Fix translation window by splitting the MMIO space to multiple tables if
its size is not a power of 2.
Resolves: https://ticket.coreboot.org/issues/508.
TEST=Build pass and boot up to kernel successfully via SSD on Dojo
board, it can boot with and without the
CONFIG_RESOURCE_ALLOCATION_TOP_DOWN option.
BUS=b:298255933
BRANCH=cherry
Change-Id: I42b0f0bf9222d284dee0c29f1a6ed6366d6e6689
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78044
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PCH BIOS spec says that BIOS must clear BIT26 in register 0x338
in PEI, as done on lynxpoint.
Copy and adapt the lynxpoint code to do the same on bd82x6x.
Add special case for UM77 chipset, which only has 4 PCIe ports.
Test: System still boots and all PCIe ports are fully working.
Change-Id: I865818c0c22194fffcb2bbdf8c43737b0dce2307
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Commit 26d54b70e2 ("soc/amd/common/cpu: use TSC_MONOTONIC_TIMER for
SOC_AMD_COMMON_BLOCK_TSC") updated all the AMD SoCs with Zen-based CPU
cores to use TSC_MONOTONIC_TIMER. The same change adjusted the PSP
Verstage timestamps (in microseconds) to the x86 TSC rate. But it
included only the base_time during the adjustment leaving the individual
entry timestamp. This leads to incorrectly adjusted PSP Verstage
timestamps. Fix the adjustment logic.
BUG=None
TEST=Build and boot to OS in Skyrim. Ensure that the PSP Verstage
timestamps in cbmem -t output are adjusted correctly.
Before this change:
5:start of verified boot 67,890 (69,936)
503:starting to initialize TPM 67,890 (0)
504:finished TPM initialization 67,902 (12)
505:starting to verify keyblock/preamble (RSA) 67,906 (3)
506:finished verifying keyblock/preamble (RSA) 67,984 (77)
511:starting TPM PCR extend 67,984 (0)
512:finished TPM PCR extend 67,992 (7)
513:starting locking TPM 67,992 (0)
514:finished locking TPM 67,995 (3)
6:end of verified boot 67,995 (0)
11:start of bootblock 572,152 (504,156)
After this change:
5:start of verified boot 71,000 (73,040)
503:starting to initialize TPM 71,065 (65)
504:finished TPM initialization 101,506 (30,441)
505:starting to verify keyblock/preamble (RSA) 110,624 (9,118)
506:finished verifying keyblock/preamble (RSA) 297,101 (186,477)
511:starting TPM PCR extend 297,297 (196)
512:finished TPM PCR extend 315,338 (18,041)
513:starting locking TPM 315,341 (3)
514:finished locking TPM 322,922 (7,581)
6:end of verified boot 322,943 (21)
11:start of bootblock 570,296 (247,353)
Change-Id: I3e52bef22f65596152f29c511bed680427660ff5
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78231
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The original code only reserves IOM mmio, but there is other asl
code that requires to program ioe p2sb mmio such as IOE PCIE clk request
control. See \_SB.ECLK.CLKD in src/soc/intel/common/acpi/pcie_clk.asl
TEST=as before: suspend_stress_test 50 cycle pass, type-c display OK
on screebo
Change-Id: Ie55f7975277b390f776e44596c42e426ba9cd235
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78252
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Package C-state auto demotion feature allows hardware to determine lower
C-state as per platform policy. Since platform sets performance policy
to balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter below PC8 state and
additional power savings ~30mW in Local-Video-Playback scenario.
BUG=b:303546334
TEST=Local build successfully & Boot to OS successfully
- Also check platform enter PC8 state in local video playback
- before this change: # iotools rdmsr 0 0xE2 -> 0x0000000060008008
- After # iotools rdmsr 0 0xE2 -> 0x0000000000008008
Change-Id: Ia4cf4a7cb6bd5eaae26197b55f9385c078960d7b
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78250
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
When advertising C-state using the ACPI _CST object, make sure
to only advertise those that are supported by the CPU.
Downgrade if it's not and make sure to not advertise duplicate
states.
Add debug prints for the finally selected mapping of ACPI
C-state vs Intel CPU C-state.
Test: Tested on Lenovo X220.
All C-states are still advertised as all are supported.
Change-Id: Iaaee050e0ce3c29c12e97f5819a29f485a7946c2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
According to the BWG C-states are processor specific
and BIOS must check if a C-state is supported at all.
Print the supported C-states in before ACPI _CNT generation.
Test: Tested on Lenovo X220 using Intel i5-2540M.
All C-states are reported as supported.
Change-Id: I713712a1a104714cbf3091782e564e7e784cf21d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78133
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id ae822f2d0db7 (2023-09-21):
MDN: Restore SMU fw version 90.41.0
to commit id b1741d184add (2023-10-04):
PCO: Update SMU firmware to 4.30.77.200
This brings in 1 new commit:
b1741d184a PCO: Update SMU firmware to 4.30.77.200
BRANCH=zork
BUG=b:299603947
Change-Id: I0ce75b762bda90a5fa3bc546de42bc5d55637e17
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Intel platforms use Low Power Idle Table (LPIT) to enumerate platform
Low Power Idle states. There are two types of low power residencies
a) CPU PKG C10 - read via MSR (Function fixed hardware interface)
b) Platform Controller Hub (PCH) SLP_S0 - read via memory mapped IO
Ref. https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf,
section 2.2.1: value of 0 indicates that counter runs at TSC frequency.
Ref. Intel 64 and IA-32 Architectures Software Developer’s Manual (Vol 4)
MSR 0x632: PC10 residency counter is at same frequency as the TSC.
Whereas slp_s0 residency counter running in different frequency.
BUG=b:300440936
TEST=check kernel cpuidle sysfs are created after kernel boot
cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
Change-Id: Ibde764551a21b9aecb1c269948f4823548294711
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This consolidates the bp, tb, cmp, srp0 and srp1 variables under the new
spi_flash_bpbits struct to allow treating them as one unit in the
refactoring to follow.
Change-Id: I2a1a77fb73047df733498c0fa8b8de1153c3b09e
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42113
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the block protection bits are being passed around as
individual arguments. We will use this new struct to replace the
corresponding arguments in the winbond_bpbits_to_region and
winbond_set_write_protection functions.
Change-Id: I02828b1f764aea29374e794001e74cdc86a94c92
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
When service center repair touchscreen or touchpad will change
compatible device not specific one, the fw_config probe mechanism is not
convenient for service center. Removing touchscreen and touchpad
fw_config probe for the purpose.
BUG=b:297840605
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I66f12ae478f74c019c53ee5e77f7e0f9c324e758
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77538
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements an API to report the presence of an external
display on Intel silicon. The API uses information from the transcoder
and framebuffer to determine if an external display is connected.
For example, if the transcoder is attached to any DDI ports other than
DDI-A (eDP), and the framebuffer is initialized, then it is likely
that an external display is present.
This information can be used by payloads to determine whether or not
to power on the display, even if eDP is not initialized.
BUG=b:299137940
TEST=Build and boot google/rex
Scenarios:
Booting with eDP alone: has_external_display value is 0
Booting with eDP + HDMI: has_external_display value is 0
Booting with HDMI alone: has_external_display value is 1
Booting with USB-C display alone: has_external_display value is 1
Change-Id: I77436940978c7fa9368d79394b46a5e794c32e42
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78080
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch introduces a new coreboot table entry named
"has_external_display" to understand if external display is attached.
This information is useful to prevent graceful shutdown by payload
when the LID is closed but an external display is present.
This piece of the information will be gathered by coreboot and passed
into the payload using this new entry aka external_display because
payload (i.e., deptcharge) doesn't have any other way to determine
if external display is available.
BUG=b:299137940
TEST=Able to build and boot google/rex.
w/o this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> System is powered off by depthcharge
w/ this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> Booted to OS and device is alive/usable
Change-Id: I0fa7eee4c5a50371a7a66c6ca1ac2c7d046d010b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77796
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel GFX IP TRANS_DDI_FUNC_CTL register bit definitions have changed
since Tiger Lake.
This register is used to map ports and pipes to display controllers,
so reflecting the correct status is important for detecting physical
display end point devices.
This patch ensures that ADL, MTL, and TGL SoCs choose GMA version 2 to
properly reflect the updated port and pipe register definitions.
BUG=b:299137940
TEST=Build and boot google/rex successfully.
Change-Id: Ie2082747d18a5f136f410b1019be4d6c801617b1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This commit updates the port select bit definitions for the
TRANS_DDI_FUNC_CTL registers in the Intel GMA driver to accommodate
the changes introduced since TGL SoC.
Specifically, the following changes were made:
- Updated the DDI select bit definitions from 3-bits (bit 28-30) to
4-bits (bit 27-30).
- Introduces `INTEL_GMA_VERSION_2` config to accommodate the port and
pipe related differences between previous generation GMA register
(TRANS_DDI_FUNC_CTL) to the current generation GMA register.
This commit backports the change from the following upstream patch:
https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-3-lucas.demarchi@intel.com
BUG=b:299137940
TEST=Able to build and boot google/rex.
Change-Id: I815ffa90c2e235afd70baa7e3837e1f9af89b1b0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The ACPI methods for enabling USB wake are identical on ADL, CNL and
SKL. Move them to a common ASL file so they can be reused more easily
on other SoCs.
Also move the USB_PORT_WAKE_ENABLE macro used to create enable bitmasks
in devicetree to a common header.
BUG=b:300844110
TEST=Use abuild to build kinox, puff, and fizz with and without this
change. Check the generated dsdt.aml is unchanged.
Change-Id: Iabdfe2bece7fafc284ddf04382f1bbcacc370cce
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This panel is never actually enabled on Geralt. The derived project
won't use this panel either. Therefore, remove this panel support.
BUG=none
BRANCH=none
TEST=emerge-geralt coreboot
Change-Id: I97ed5b341724ed42098b2c17d0eb75eab881dbb1
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The tolerance of ADC voltage table is too small. Update the table values
accordring to the suggestion from the hardware team. The patch is
prepared for the derived projects. There is no actual issue now.
BRANCH=none
BUG=b:301908091
TEST=check firmware screen
Change-Id: I3bde30b6bbe79c81e276f23f4110715c3278d42c
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The SPL_TABLE_FILE and SPL_RW_AB_TABLE_FILE Kconfig options provide a
way to override the default SPL file configured in the SoC's fw.cfg file
by passing the '--spl-table' parameter to amdfwtool which will then use
the override instead of the SPL file from the fw.cfg file. When
SPL*_TABLE_FILE is an empty string, the corresponding add_opt_prefix
call in the makefile will result in no '--spl-table' parameter being
passed to amdfwtool, so it'll use the default SPL file from fw.cfg. In
order to not pass an SPL override by default, remove the default from
the SPL_TABLE_FILE in the SoC's Kconfig. The SoC default pointed to the
same SPL file as in fw.cfg file anyway. Now only when a mainboard sets
this option to point to a file, that file will be used as an override.
This override is used to include a special SPL file needed for the
verstage on PSP case on the Chromebooks. Since SPL_TABLE_FILE is an
empty string by default, neither the SPL_TABLE_FILE Kconfig option nor
it being evaluated in the Makefile need to be guarded by HAVE_SPL_FILE,
so remove the dependency in the Kconfig and the ifeq in the Makefile.
Before this patch, the HAVE_SPL_FILE option controlled two things that
shouldn't be controlled by the same Kconfig option: Only when
HAVE_SPL_FILE was set to y, the SPL_TABLE_FILE override was taken into
account, and it also controls if spl_fuse.c got added to the build which
when added will send the SPL fusing command to the PSP. So the case of
needing an SPL file override, but not updating the SPL fuses wasn't
supported before.
The SPL file in the amdfw part will be used by the PSP bootloader for
the anti-rollback feature which makes sure that the SPL file version
isn't lower than what is in the SPL fuses. For this the SPL file needs
to be present in the PSP directory table. The SPL version check happens
way before we're running code on the x86 cores. The SPL fusing PSP
command that can be sent by coreboot will tell the PSP to update the SPL
fuses so that the fused minimal SPL version will be updated to the
current SPL version.
Since the former HAVE_SPL_FILE option now only controls if the SPL
fusing command will be sent to the PSP mailbox, rename it to
PERFORM_SPL_FUSING to clarify what this will do and update the help text
correctly describe what this does.
TEST=With INCLUDE_CONFIG_FILE set to n, timeless builds for both Birman
with Phoenix APU and Skyrim result in identical binaries.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6cec1f1b285fe48e81a961414fbc9978fa1003cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78178
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
During CSE firmware downgrade, data is cleared. To preserve PSR data
during downgrade, it needs to be backed up. Select
SOC_INTEL_CSE_LITE_PSR config to ensure PSR backup related flow is
executed on CSE Lite SKU.
BRANCH=None
BUG=b:273207144
TEST=Verify CSE firmware upgrade/downgrade on rex.
Change-Id: I39af029a5f0c018a5db3ac68191764abfa9518ac
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76115
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds eventlog entries for the below scenarios:
1. To indicate success or failure of PSR data back-up command
2. To indicate the loss of PSR data when CSE update is corrupted, and
data clear command is issued to clear the data.
3. To indicate the loss of PSR data when CSE boot partition info
response is corrupted and data back-up is not initiated.
BRANCH=None
BUG=b:273207144
TEST=Verify elog event added after PSR data backup command is sent
cse_lite: PSR_HECI_FW_DOWNGRADE_BACKUP command sent
...
ELOG: Event(B9) added with size 10 at 2023-06-27 06:44:49 UTC
Change-Id: I2459a2b941d28a87b6c78f75dbe8779d73328d7a
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Get PSR bit state using MKHI_FWCAPS_GET_FW_FEATURE_STATE HECI command
Use this bit info to check if SKU supports PSR and consequently issue
PSR_HECI_FW_DOWNGRADE_BACKUP command for PSR data backup during
downgrade.
BUG=b:273207144
TEST=build CB image and boot on google/rex board. Check for
"PSR is supported in this SKU" message in coreboot logs to confirm
that PSR bit is set in SKU
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I6e92341a9dc799146eb8f1a70b3a4a16fd1aa0ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
During CSE FW downgrade we erase CSE data. This would result in
Platform Service Record(PSR) data also to be erased.
To avoid losing PSR data we need to make a backup before data clear.
This patch sends PSR_HECI_FW_DOWNGRADE_BACKUP HECI command to CSE,
informing the CSE to backup PSR data before a data clear operation
during downgrade.
CMOS memory is used to track the backup status. PENDING is the default
state, it is updated to DONE once PSR_HECI_FW_DOWNGRADE_BACKUP HECI
command is sent.
PSR data can be backed up only post DRAM is initialized. The idea is to
perform cse_fw_sync actions in ramstage when PSR is enabled on a
platform. As part of the cse_fw_sync actions, when a firmware downgrade
is requested the command to back-up data is sent. Once the backup has
been done, trigger the firmware downgrade.
BRANCH=None
BUG=b:273207144
TEST=build CB image for google/rex board and check PSR backup command
is being sent during a CSE FW downgrade. Also check PSR data is not
lost/erased after a downgrade using intel PSR tool.
Change-Id: I135d197b5df0a20def823fe615860b5ead4391f8
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74577
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data. Since firmware downgrade
and PSR data backup flows involve global resets, there is a need to
track the PSR data backup status across resets. So adding a CMOS
variable for the same.
This patch implements API to access PSR backup status stored in CMOS.
The get API allows to retrieve the PSR backup status from CMOS memory.
The update API allows to update the PSR backup status in CMOS.
BRANCH=None
BUG=b:273207144
TEST=Able to retrieve PSR backup status across resets.
Change-Id: I270894e3e08dd50ca88e5402b59c211d7e693d14
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CSE firmware downgrade and PSR data backup flows involve global resets,
there is a need to track the PSR data backup status across resets. In
the subsequent patches, a CMOS structure to store PSR back-up status
will be added.
The current SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET of 68 can only store
cse_specific_info, as ramtop is at offset 100 and PSR back-up status
structure will not be able to fit within the range.
This patch overrides the SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET to 161
to accommodate all CSE related info in adjacent CMOS memory.
BUG=b:273207144
TEST=Verify CSE RW FW versions are stored in CMOS memory in rex.
Change-Id: I8bae5245f93b99be15b4e59cfeffbc23eec95001
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78054
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Platform Service Record(PSR) will be enabled on Meteor Lake
platforms. cse_fw_sync actions happen in ramstage when PSR is enabled.
To avoid the boot time penalty of sending the cse_get_bp_info in
ramstage, call cse_fill_bp_info to get cse_bp_info response early in
romstage and store in cbmem. This data can be later used in ramstage.
BUG=b:273207144
TEST=Verify cse_bp_info is filled in romstage in rex.
Change-Id: Ic0e8fb34f21ff07e182a7b848d38e9d329010028
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
Sending cse_get_bp_info command in ramstage takes additional boot time
of ~45-55ms on rex. To avoid the boot time penalty, this patch provides
an API to get the cse_bp_info in early romstage. The response data is
then migrated to cbmem once memory is initialized. The same data in
cbmem can be utilized in ramstage to perform other cse_fw_sync actions.
This patch also adds check to validate cse_bp_info in cbmem and avoids
sending the command again if the data is valid.
BUG=b:273207144
TEST=Verify the command works in early romstage, data is migrated to
cbmem and valid data is available in ramstage on rex.
Change-Id: Ib1e72c950ba0f4911924805f501ec1bd54b6ba3c
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78053
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since commit 9b186e0ffe ("util/xcompile: Add NASM to xcompile") NASM
from the coreboot toolchain is properly hooked up to the build system.
So it's not needed to install the distro package. Remove it.
Change-Id: I2ab0317531e25ae6d5baa8be8ac4d41dc145658f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77728
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Now that Intel has publicly released FSP headers/binaries for
RaptorLake-P/S client platforms, set the defaults accordingly if
FSP_USE_REPO is not selected. This does not change any existing
defaults as the RaptorLake headers in vendorcode are only used when
FSP_USE_REPO is not set.
TEST=build/boot google/brya (osiris)
Change-Id: Ida92d269fcaf6f323599ec174f4dcedbbe65f03c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78190
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
During suspend, the ISH I2C transactions cannot go through
because the GPIO pads remain the pervious value.
The IO Standby State (IOSSTATE) needs to be changed to keep I2C bus
active and functional during suspend.
BUG=b:302612549
TEST=on Google/rex platform with ISH enabled, do suspend_stress_test
and check that no i2c failure.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I9a2c902ed56461f3a535428db399c2050756f2da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78179
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Li1 Feng <li1.feng@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set default to enabled for hibernate on setup failure for all devices
using a Google EC. This will have no impact on devices that don't
bring the GSC down on hibernate, but will provide a recovery path
for all devices that do.
BUG=b:296439237
TEST=Force error on Skyrim with custom build, boot normally with
normal build
Change-Id: I2d9e8f75b25fb6c530a333024c342bea871eb85d
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78098
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Separate these so a mainboard can describe a PS/2 keyboard without a
PS/2 mouse or vice-versa.
Librem 11 has a PS/2 keyboard for the volume keys, but does not have a
PS/2 mouse, and the presence of a mouse device can cause the cursor to
appear on the desktop incorrectly.
ps2_controller.asl remains since many boards include it, it now just
includes the two new files.
Change-Id: I13a4c2caf8dc9e5004b775dc0a9ac2488e39f184
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78096
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of having the get_usable_physical_address_bits function that
only got used in the data fabric domain resource reporting code, drop
this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the
common AMD non-CAR CPU and rename get_sme_reserved_address_bits to
get_reserved_phys_addr_bits so that the common cpu_phys_address_size
function will return the correct number of usable physical address bits
which now can be used everywhere. The common AMD CAR CPU support is only
selected by Stoneyridge which doesn't support secure memory encryption,
so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the
SOC_AMD_COMMON_BLOCK_CAR Kconfig option.
Before only the MMIO region reporting took the reserved physical address
bits into account, but now also the MTRR calculation will take those
reserved bits into account. See the AMD64 Programmers Manual volume 2
(document number 24593) for details. Chapter 7.10.5 from revision 3.41
of this document was used as a reference. The MTRR handling code in
older Linux kernels complains when the upper reserved bits in the MTRR
mask weren't set, but sets them after complaining and then continues to
boot. This issue is no longer present in version 6.5 of the Linux
kernel.
The calculation of the TSEG mask however still needs to take all
physical bits into account, including the ones reserved for the memory
encryption. When not setting the reserved bits in the TSEG mask, the
Mandolin board with a Picasso APU won't boot to the OS any more due to
not returning from SeaBIOS calling into the VBIOS. Haven't root-caused
what exactly causes this breakage, but I think previously when something
else was wrong with the SMM initialization, also something went wrong
when calling into the VBIOS.
TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2
and Windows 10 boots on it via EDK2.
TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following
warning, but it still continues the boot process as described above:
mtrr: your BIOS has configured an incorrect mask, fixing it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
In the cpuid helper functions eax is always written to
by the cpuid instruction, so add it to the output clobbered list.
This prevents GCC from generating code with undefined behaviour
when the function is inlined.
Test: Verified that the generated assembly is sane and runtime
tests showed no "strange" behaviour when calling cpuid
functions.
Change-Id: I5dc0bb620184a355716b9c8d4206d55554b41ab9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78192
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Updating from commit id a72794810884 (2023-09-07):
IoT ADL-N MR1 (4172_00)
to commit id 481ea7cf0bae (2023-09-19):
Move to RaptorLakeFspBinPkg.dec
This brings in 9 new commits:
481ea7cf0b Move to RaptorLakeFspBinPkg.dec
55e25b819e Raptor Lake FSP C.1.BD.40
2b0aac4f64 Raptor Lake FSP C.0.BD.40
3fa75657aa Add Client Raptor Lake FSP
8d24189361 Add Alder Lake and Raptor Lake to README.md
98f4a1fe2f Rename to AlderlakeSiliconPkg
c78a6784cb Add FvLateSilicon for Alder Lake
849ce8261b Tiger Lake FSP A.0.7E.70
4b0b1eb4e3 Update SplitFspBin.py to latest from edk2
Change-Id: I8a724bf0a03cba5a9689894e1aec0a81a5bf2c94
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78189
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Configure the SCP to operate within domain 8, allowing it to access
only the necessary registers. Any unauthorized access will be prevented
by the DAPC.
- Set SCP domain from domain 0 to domain 8.
- Lock register settings down to prevent unexpected modification.
BUG=b:270657858
TEST=scp bootup successful with dapc settings
Change-Id: I049486c997542d91bd468e0f4662eafbca4c17e0
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77883
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch sets domains for masters:
SSPM - domain 3
CPUEB - domain 14
PCIE0 - domain 2
SPM - domain 9
Change-Id: Ie3e1d5055e72824257b66d6257982652eeb05953
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77862
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch updates the permission settings for domains 2, 3, 4, 5, 7,
8, 9, and 14, as these domains will be assigned masters in the upcoming
patch.
BUG=b:270657858
TEST=build pass
Change-Id: I6e95ddb5d84a09ff865d7615596430e25b69d3fc
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77861
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Since also some AMD CPUs have reserved physical address bits that can't
be used as normal address bits, introduce the
RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT Kconfig option which gets
selected by CPU_INTEL_COMMON, and use the new common option to configure
if the specific SoC/CPU code implements get_reserved_phys_addr_bits or
if the default of this returning 0 is used instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0059e63a160e60ddee280635bba72d363deca7f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Update the default branch used for MrChromebox's edk2 fork from 2023-06
to 2023-09. This updated branch has been rebased on the latest upstream
stable tag (edk2-stable202308), and fixes some USB detection issues, as
well the coreboot Kconfig for prefering internal or external boot
devices.
TEST=build/boot google boards link, panther, lulu,reef, ampton, akemi,
banshee, zork, frostflow with edk2 payload selected.
Change-Id: I7c5f9ae1ca4edd8211f55f4ecf2b3b495f473a43
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78136
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Disabling TPM support in edk2 can actually cause problems booting from
USB on some Intel-based boards with a CR50 TPM when using the edk2
GOP driver option, so rather than disable the TPM for all CR50 boards,
restrict the default to only AMD boards, where the boot hang with
TPM enabled was originally observed.
TEST=build/boot Win11, Linux from usb on google/fizz when built
with edk2 payload and edk2 GOP driver option selected.
Change-Id: I01509fea2dd42b741c00abcf9fb8b936e895b932
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78031
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
ASPM on the WLAN PCIe bus introduces large latency spikes, which can be
measured with cyclictest:
$ cyclictest --policy=rr --priority=12 --interval=10000 --threads=1 --loops=6000
Disabling ASPM for WLAN reduces the latency spikes from 2,500-3,000 usec
down to 35-65 usec. These latency spikes can impact the user when
real-time processes like Audio (cras) are starved of CPU time, leading
to buffer underruns resulting in crackling/distorted audio.
ASPM is already disabled for Nipperkin devices (CB:63537), so this CL
disables it for both in the shared declaration of
guybrush_czn_dxio_descriptors.
Power impact for Dewatt:
* ASPM enabled
power_VideoCall.FDO_25min_webrtc
w_energy_rate 7.425043688811071
power_Idle.default20min
wh_energy_used 1.4164200000000022
* ASPM disabled
power_VideoCall.FDO_25min_webrtc
w_energy_rate 8.779998551703423
power_Idle.default20min
wh_energy_used 1.4860800000000012
When using Google Meet over WiFi, power increases by ~1.5W.
BUG=b:297970318
TEST=cyclictest --policy=rr --priority=12 --interval=10000 --threads=1 --loops=6000
Change-Id: I16940987d598943bd5d6ace8b4008eba4d4a177c
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77963
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Implement support for elan i2c touchscreen and use fw_config
to pick between i2c or HID-over-i2c touchscreen.
Support G2 TS have different slave address by fw_config
BUG=b:295272539
BRANCH=firmware-nissa-15217.B
TEST=build and verified touchscreen work
Change-Id: I5e3f85106606d84e1cfa204e62b7b2662db6546b
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Revise the Makefile.inc rules for generating FMD parser files.
- lex: If --header-file is supported then the lex (usually flex) should
also support '-o' so we don't need to do redirection (-t).
- yacc: Bison is already required by bincfg and sconfig so we
can change the default parser compiler to Bison. That also
allows us to use -o and --defines to override the output files.
- both: Line directives are only helpful when debugging the scanner and
the parser, so we should remove them to get better git diff
results (-L for lex, -l for bison).
Also regenerated the shipped files with latest version of flex (2.6.4)
and bison (3.8.2).
Change-Id: I15b58ff65dcd9f3f3a6095aa004091ff733ffec3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
This patch ensures SOC_INTEL_CSE_LITE_SYNC_IN_RAMSTAGE is selected when
PSR is enabled.
BUG=b:273207144
Change-Id: I7c9bf8b8606cf68ec798ff35129e92cd60bbb137
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78055
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable hibernate on TPM setup error for Skyrim devices.
BUG=b:296439237
TEST=Force the error by hard coding the return code and observe the
device entering hibernate.
BRANCH=None
Change-Id: Ibf96b830f07dac98035d3152c8ec220685a912bc
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77668
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure PL1 and PL2 are configured for powerformance.
Based on values from Intel Meteor Lake UH Power Map document ID:640982
BUG=b:286834207
TEST=Build and boot google/ovis and check ACPI SSDT for DPTF entries
Change-Id: Ia40884b3abd1417dea6ad291de4845762ee01966
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77623
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch selects LZ4 decompression for logo CBFS file. Able to save
2ms of the boot time when HAVE_FSP_LOGO_SUPPORT config is enabled.
However, the compressed BMP logo size is increased by ~2KB.
Raw BMP Image size is ~97KB.
BUG=b:284799726
TEST=Able to see pre-boot splash screen while booting google/redrix
with 32MB (W25Q256JWEIM) SPI-Flash.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I98e2c9a4f77d0b91f84eda9aec5060b236bd5e94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78121
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id c6e5fba929ef (2023-09-02):
MDN: Update ABL to version WABLMDN3516B01A
to commit id ae822f2d0db7 (2023-09-21):
MDN: Restore SMU fw version 90.41.0
This brings in 3 new commits:
ae822f2d0d MDN: Restore SMU fw version 90.41.0
d4f752a6fa MDN: Restore MP2 fw version 0A.0D.00.06
7b7b04723b CZN: Update VBIOS to version 021
BUG=b:301109173
BRANCH=none
Change-Id: I02b39ea94a23f7c25533347f06cd8488711c37cd
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Jasper Lake was missing these bases, so attempting to enable an SCI
would poke unrelated registers starting from offset 0. Set them so
GPEs can be enabled.
GPE is used on the Librem 11 for the keyboard dock connector, its sense
signal on GPP_D4 raises a GPE which is used to indicate tablet/laptop
mode to the OS.
The register offsets are documented in the datasheet volume 2 (Intel
document 634545), all groups' GPE_STS/GPE_EN start at the same offsets.
Change-Id: Ib6b9b9a79e9cc4467e609eaf591ec4e87b78d617
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78097
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Don't skip checking out the specified edk2 branch if the repo contains
untracked files, which may be the case if the EDK2_GOP_DRIVER option
is selected. Also ensure the submodule pointers are correct when
checking out.
TEST=build google/panther with GOP driver option and edk2 payload 2x,
switching branches between builds and ensure the correct branch is
used each time and submodules are synced with branch.
Change-Id: If7040bd5c49209b37a4b308485bf59352197d3b6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Several of the build commands passed by the Makefile only exist
in MrChromebox's fork of edk2. Guard these, and the corresponding
Kconfig options, against the selection of the MrChromebox repository.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I41d8d54e5b91990dd9fb88967fcd549a86cf6fe9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78036
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The mapped windows is up to 16M. Even if the flash size is 32MB, it is
not mapped at 0xFE000000.
So using "0xFFFFFFFF - rom_size + 1" to get the "rom_base_address" can
only explain well when rom_size is less or equal to 16MB. For larger
size, it is not physically correct (Even though it can get expected
result).
If the flash size is larger than 16M, we assume the given addresses
are already relative ones. So we don't need the physical base address
any more.
This commit is part of a series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: I9eea45f0be45a959c4150030e7e213923510ad68
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72959
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Rather than disabling C State demotions for every single Raptor
Lake board due to an issue with S0ix, regardless of if they even
use S0ix, configure it in the mainboard.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4f941a549bc717ae2f8ec961ead7ac7668347c99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Besides fw.cfg, each combo entry needs dedicated APCB files. If no new
APCB is provided, the main APCB is used for all entries.
The combo is fully supported after this.
Change-Id: I21c2bf7d98ded43848ae8a8bb61d1ded1a277f88
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58620
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Before the cpuid(0x80000001) read in smbios_write_type4, it was
previously checked in a slightly convoluted way if the result from
cpu_cpuid_extended_level was larger than 0x80000001, but the check
should be if it is larger or equal to 0x80000001.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iabcfdb2b8b90d80baf8f4c4d2fd79f1f44866dc7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78107
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the HDA device can neither be disabled using softstraps
nor can it be disabled by using FSP UPDs. Add code to disable it in
coreboot when it's marked as 'off' in coreboot's devicetree.
TEST: Device 00:1f.3 is hidden and platform boots into OS without issue.
Change-Id: Ifa1422d653cf81ee6faf2bdda27a471c2084642b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77873
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On the first boot after flashing, the data read from the FMAP and
stored in vbios_data is not valid, so hashing it produces a value which
will not match on the subsequent boot, requiring an additional boot
before the vbios_data and hash match / before the GOP driver can be
skipped. To fix this, update vbios_data before hashing.
BUG=b:271850970
BRANCH=skyrim
TEST=build/boot google/skyrim with USE_SELECTIVE_GOP_INIT selected,
verify that GOP driver execution is skipping on 2nd boot after flashing
when booting in normal / verified boot mode.
Change-Id: Idc10d752bfa004a34b91307a743c620fb97eeb82
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77727
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This adds support for booting the Librem L1UM v2 mainboard with
coreboot, using binaries from the original BIOS.
The following features have been tested on PureOS:
- USB: front USB3, rear USB3, USB2 header on board
- SATA: 8x SATA ports, one M.2 M-key shared with SATA0
- PCIe: two PEG slots, one PCIe slot from PCH, and one M.2 M-key
- Network: 2x GbE
- Video: BMC VGA and IPMI
- Serial: Physical serial port, provided by BMC SuperIO
- Hardware monitor
- POST code display
- TPM2
These binaries are extracted from the original BIOS:
- Intel Management Engine
- Intel Firmware Descriptor
This was developed and tested on a Librem L1UM v2 using a Core i7-9700
CPU. Native graphics init works for the Aspeed AST2500 BMC.
For development, the serial port console works from bootblock. Early
init waits for the BMC to finish booting since this is required for
serial port output.
Change-Id: I990f6024d65098a9553d7d1fe7f36614cc55ea19
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75090
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Makefile.inc to include five generic LPDDR5 SPDs for the following
parts for Dochi:
DRAM Part Name ID to assign
MT62F1G32D2DS-023 WT:B 0 (0000)
K3KL8L80CM-MGCT 1 (0001)
H58G56BK8BX068 0 (0000)
BUG=b:298337185
TEST=USE="project_dochi emerge-brya coreboot"
Change-Id: If0fd4bc950cef484db53b7b21849cfdfdd7816a5
Signed-off-by: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78064
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
There is a technical debt in ChromeOS flashrom, `cros_alias.c`, which
is to work around ChromeOS calling flashrom with `-p host` instead of
`-p internal`.
Replace all `-p host` occurrences with `-p internal`.
BUG=b:296978620
TEST=none
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: I81674213b9a21598002f349ced1130f0844841ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This reverts commit 21e61847c4.
Reverting as it breaks booting on google/dedede based boards. First boot
after flashing is successful, 2nd hangs with the following error:
[EMERG] FspMemoryInit returned with error 0x80000003!
TEST=build/boot google/dedede (magpie, metaknight)
Change-Id: I6a2474617b444414c4248dbeda23ed0915704a17
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
This patch fixes the mistake introduced with 'commit 17cea380d9
("commonlib: Add CBMEM ID to store CSE Boot Partition Info")' where
single CBMEM ID name `CBMEM_ID_CSE_INFO` is associated with two
different name description.
Additionally, use little endian format for `CBMEM_ID_CSE_INFO` cbmem id.
TEST=Build and boot google/rex. Able to fix the issue introduced in
commit 17cea380d9 while running cbmem --list and verify that the
associated name string is proper.
Change-Id: I4235f1f6881ab86ccb252065e922d5d526f7f1f7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78110
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. In order to
backup PSR data before initiating firmware downgrade, CSE Lite firmware
supports a command to do this. This command works only after memory has
been initialized. So the CSE firmware downgrade can be done only in
post-RAM stage. CSE firmware sync actions will be moved to early
ramstage to support this.
Moving CSE firmware sync actions to ramstage results in cse_get_bp_info
command taking additional boot time of ~45-55ms. To avoid this,
cse_get_bp_info will be sent in early romstage and the response will be
stored in cbmem to avoid sending the command again, and re-use in
ramstage.
This patch adds a CBMEM ID to store this CSE Boot Partition Info
response in cbmem.
BUG=b:273207144
Change-Id: I914befadab4ad0ac197435e2a2c4343a796b2b1b
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78052
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
cse_store_rw_fw_version() stores CSE RW firmware version in global
variable or cbmem in romstage and ramstage respectively, based on the
stage it is called in. The call to this function is from the
cse_print_boot_partition_info() in cse_get_bp_info.
In the subsequent patches, the idea is to send the cse_get_bp_info early
in romstage and store in cbmem once memory is initialized. So when the
cse_fw_sync is called in early ramstage, the stored cse_bp_info_rsp is
used instead of sending the CSE get boot partition info command again.
To de-link the call to cse_store_rw_fw_version from cse_get_bp_info and
to ensure the CSE RW FW version is stored in all cases, moving the
function to do_cse_fw_sync.
BUG=b:273207144
Change-Id: I0add2c167c85cbddef2ecb4c019061a08562bbdf
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost.
CSE Lite SKU firmware supports a command to backup PSR data before
initiating a firmware downgrade. PSR data backup command works only
after memory has been initialized. Moving only the downgrade would add
complexity of splitting the cse_fw_sync across pre-RAM and post-RAM
stages. So the idea is to move cse_fw_sync into ramstage when PSR is
enabled.
We are introducing a flow to get CSE boot partition info in early
romstage and then same data will be stored in cbmem once DRAM is
initialized. The CSE BP info data in cbmem will be utilized in early
ramstage to perform cse firmware sync operations. This helps in avoiding
re-sending the CSE get boot partition info command in ramstage. Having
cse_bp_info_rsp as global helps in de-linking cse_get_bp_info from
cse_fw_sync.
Many functions take cse_bp_info as input parameter. Since
cse_bp_info_rsp is global now, we can make use of global cse_bp_info and
remove it as input parameter from those functions.
BUG=b:273207144
TEST=Verify cse_bp_info_rsp holds value across the stage.
Change-Id: I0ee050b49fcae574882378b94329c36a228e6815
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77070
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
No Windows driver exists or is needed, so hide to prevent an unknown
device from being listed in Windows Device Manager.
TEST=build/boot Win11 on frostflow, verify unknown device for the
fingerprint reader no longer present.
Change-Id: I666e92706f698608f2df92c8296cfb615d5ece67
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
No Windows driver exists or is needed, so hide to prevent an unknown
device from being listed in Windows Device Manager.
TEST=build/boot Win11 on dewatt, verify unknown device for the ACP
machine driver no longer present.
Change-Id: I44d25fd2ea75593383cbb14f2324d4376b399de7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
No Windows driver exists or is needed, so hide to prevent an unknown
device from being listed in Windows Device Manager.
TEST=build/boot Win11 on morphius, verify unknown device for the ACP
machine driver no longer present.
Change-Id: I14347ab6c840066db4ff700eff1aad4cf6faf66b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Remove the unnecessary tss_common.h header from the repo.
tss_errors.h is a more appropriate place for the TPM_SUCCESS
value, and the other define is only used by tpm_common.c and
can be placed there.
BUG=b:296439237
TEST=Builds
Change-Id: I99cf90f244a75c1eeab5e9e1500e05c24ae0a8e5
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78033
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Dedede boards which select AUDIO_AMP_UNPROVISIONED via fw_config use
rt1015 for the speaker topology, not max98360a.
TEST=build/boot Win11 on google/magpie, verify correct audio profile
selected.
Change-Id: I5b75bd8fd37d2837de3c5bd25a02411a6982103b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
This reverts commit 06cb756f02.
Reason for revert: These Kconfigs are needed by boards which use the
CSE stitching tools (i.e. select STITCH_ME_BIN). They're selected by
some boards in the downstream ChromeOS repo. They're used in
src/soc/intel/Makefile.inc (see the line with
`$(CONFIG_CSE_$(2)_FILE)`).
Change-Id: Ide6fc74b457439f06b7ef9b37f11d6c9ff226b80
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76719
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Without the PCH UART GPIOs set early, there is no serial console
output until ramstage. Add them to the early GPIOs for all puff
variants.
TEST=build/boot google/puff (wyvern) with serial console enabled,
verify console output starts in bootblock.
Change-Id: Ica0506b2b80e4fac0d3ca11b4cfdd128ce424b36
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78029
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Brya queries the TPM in early ramstage (pre-device init) to determine
if the CR50 has support for long-pulse interrupts. If the TPM (and
underlying I2C controller) hasn't already been setup in verstage, it
will fail to do so in ramstage since the I2C controller has not yet
been initialized. To work around this, initialize the TPM in bootblock
for the non-vboot case, to ensure the I2C controller is set up when
needed in early ramstage.
TEST=build/boot google/brya (banshee), verify no I2C errors in cbmem
console when initializing TPM in early ramstage.
Change-Id: I26f0711a9cc4c2eb9837f258cadf391d337994c9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78028
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Meteor Lake QS silicon provides better size optimized pre-x86
reset blobs.
This patch creates a new flash layout (FMD) for QS to accommodate those
optimizations, and renames the existing FMD for ES (pre-prod) silicon.
Comparative analysis between QS and ES flash layout is here:
For QS silicon:
- SI_ALL reduced from 9MB to 8MB.
- SI_BIOS increased by 1MB (from 23MB to 24MB) to fill in the 32MB SPI
layout.
- ME_RW_A/B reduce from ~4.5MB to 4MB.
- Ensure RW-B slot is starting at 16MB boundary.
- Unused space increased by 1MB.
For ES silicon:
- SI_ALL: 9MB
- SI_BIOS: 23MB
- ME_RWA/B: 4.5MB (for ISH) and 4.4MB (non-ISH).
- Unused space 3MB (for release) and 2MB (for debug) layout.
Change-Id: I881832a6b11a35710d4e847feadcc544b1f5d048
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77994
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
The options in conf.py for the following build targets are either
commented out or contain example values, which suggests that there was
no interest in them recently. Their comments also seem more like
generated examples.
* LaTeX
* man pages
* Texinfo
In order to clean up our configs and scripts for the documentation,
remove the configuration options from conf.py for these build targets.
Also, remove the build targets responsible for generating a PDF file
from Makefile. Don't touch Makefile.sphinx for now though as we usually
wrap around it.
We may bring these build targets back if there is real interest in
them, but it seems only the HTML target was really used.
Change-Id: I7df8ea886f94d9b25e8eeb0ccbc2a7392b96a575
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77439
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No drivers exists or are needed, so use devicetree hidden keyword to
set the ACPI status to hidden to prevent unknown devices from showing
in Windows Device Manager.
TEST=build/boot Win11 on morphius, verify unknown devices for the
fingerprint reader and stylus detection are no longer shown.
Change-Id: I992c0ec8d97c6041e3a268445613bfa42dd8b279
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently MP2 Firmware is not built into RO firmware section but the
soft fuse bit to disable MP2 firmware loading is not set. This causes
the device to boot loop during recovery mode. Set the bit to disable MP2
firmware loading in RO.
BUG=b:259554520
TEST=Build and boot to OS in Skyrim under both normal and recovery
modes.
Change-Id: I9e4cf4f72e2d36ad3cc33629ddb501ecdbf5eda9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78023
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This board is similar to x11ssm-f but has a proprietary form factor with
NVMe and a single x16 slot (potentially bifurcated to 2x x8) and a x4
slot.
Change-Id: I53a0b6012ae64cf1ba4b625f11aaf771637307f3
Signed-off-by: Kieran Kunhya <kieran@kunhya.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Now that no local union definitions are used any more, pass the msr data
to display_mtrr_fixed_types as an msr_t type parameter instead of a
uint64_t parameter. Also rename the parameter from msr to msr_data to be
more specific that this parameter is the MSR contents and not the MSR
number.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iafde64129acc4bf9f01816de21c7793edfc1a799
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Commit 407e00dca0 ("include/cpu/msr.h: transform into an union")
changed the msr_t type to a union that allows accessing the full 64 bit
via the raw element, so there's no need to wrap it again in another
union for the full 64 bit access.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I750307297283802021fac19e2cdf5faa12ede196
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Hook up the OC watchdog common block and initialize it if requested.
TEST=Enable watchdog on MSI PRO Z690-A and see the platform resets
after some time. Enable the watchdog in driverless mode and see the
platform no longer resets and periodic SMI keeps feeding the watchdog.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I1c2c640d48b7e03ad8cd8d6cdf6aac447e93cd86
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68945
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the
`DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC` config is enabled if
the underlying platform is built with a pre-production SoC (aka
`SOC_INTEL_METEORLAKE_PRE_PRODUCTION_SILICON` config is enabled).
BUG=b:300652989
TEST=Ensures `DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC` is enabled
for google/rex4es aka all variants with ES silicon.
Change-Id: Ieda39427915fa3973b832376ec20fc414ac2bedd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77993
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
The tree contains engineering sample boards, that ship with
pre-production Meteor Lake SoC. These boards are not sold.
BUG=b:300652989
TEST=Ensure mainboards like google/rex4es and screebo4es have
`SOC_INTEL_METEORLAKE_PRE_PRODUCTION_SILICON` config enabled.
Change-Id: I1a875a0f1d2c38582f35250ebe645e53599f62de
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77992
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Certain Intel Meteor Lake specific features are only enabled in
production silicon (not available in early SoC aka pre-production
silicon).
- SPI usage for production SoC is much optimized compared to pre-
production silicon.
- MIPI driver requires a way to identify between pre-prod vs prod
silicon.
This patch adds config options to select the Pre-Production
aka Engineering Silicon (ES). The mainboard users can specify which
underlying SoC is being used for the target platform.
BUG=b:300652989
TEST=No change in the functionality, just added new configs.
Change-Id: I60fe11c1151a3a6c290cd0105eb570cb78e81797
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Add the eMMC MMIO device to the devicetree and make it use the common
AMD eMMC driver. Since there is now a device for this in the devicetree,
also use this device to determine if the FSP should be told if the eMMC
controller is supposed to be disabled.
TEST=On Mandolin the eMMC controller both disappears in the Windows 10
device manager and in dmesg on Ubuntu 2022.04 LTS
TEST=Morphius with NVMe SSD still works
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5453b69df776d2ce1f3be11e37cd26c8c64f0cd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
When the eMMC MMIO device is enabled in the devicetree, it needs to be
exposed in ACPI in order for the OS driver to be able to attach to it.
The Cezanne eMMC controller isn't used in google/guybrush, so this the
code path where the eMMC MMIO device is enabled in the devicetree can't
be easily tested.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I69ff79b2d1c6a08cf333a2bb3996931962c2c102
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add a separate Kconfig option for adding np_region.c to the build. Only
the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call
data_fabric_set_mmio_np which is implemented in that file, so only
select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option
for those.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
tis_init calls into tis_probe and returns an error or success, simplify
the call stack by removing the current tis_init implementation and
renaming tis_probe to tis_init.
BUG=None
TEST=builds
Change-Id: I8e58eda66a44abf5858123cf9bcf620626f1b880
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Patch adds:
- vboot_fail_and_reboot() for vboot failures handling.
- reboot() weak implementation for payloads to implement, used
by vboot_fail_and_reboot().
- vboot_recovery_mode_enabled() to check if recovery mode flag is set in
vboot context. Implemented for future libcbfs implementation
of VBOOT_CBFS_INTEGRATION in libpayload.
BUG=b:197114807
TEST=none
Change-Id: I53d1955573d54bc56d05f7780c18dcc8ac1fd399
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
To fully and easily implement fallback/recovery in libcbfs with vboot
support the codebase requires access to vboot context. Moving context
management to libpayload allows to avoid unnecessary overhead and code
complication and still allows payloads to access it in a way it was
designed. Access to this codebase will also allow implementation of e.g.
vboot_fail_and_reboot() and other helpful utilities used by coreboot and
depthcharge.
BUG=b:197114807
TEST=make unit-tests
TEST=Build and boot on google/ovis4es with CL:4839296 and
VBOOT_CBFS_INTEGRATION enabled
Change-Id: Id719be7c4f07251201424b7dc6c1125c6b5756d8
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Use data_fabric_get_mmio_base_size in data_fabric_print_mmio_conf
instead of open coding the functionality. This will fix the printing of
the MMIO config in the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
case which wasn't handled properly before.
TEST=Console output from this function doesn't change on Mandolin:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 0 ffff 90 9
4 fed00000 fed0ffff 93 x x 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If602922648deca0caef23a9999c82acdd128b182
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Since vboot_extend_pcr() returns vb2_error_t, the return type of
extend_pcrs() should be vb2_error_t too.
Also fix an assignment for vboot_locate_firmware(), which returns int
instead of vb2_error_t.
Change-Id: I1a2a2a66f3e594aba64d33cfc532d1bd88fa305e
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
For GICD and GICR a SOC needs to implement 2 callbacks to get the base
of those interrupt controllers.
For all the cpu GIC the code loops over all the DEVICE_PATH_GICC_V3
devices in a similar fashion to how x86 lapics are added. It's up to the
SOC to add those devices to the tree.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5074d0a76316e854b7801e14b3241f88e805b02f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76132
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot offers two vboot schemes VBOOT_SLOTS_RW_A and
VBOOT_SLOTS_RW_AB. When VBOOT_SLOTS_RW_AB is not selected then the
resulting image is rather not expected to have the FW_MAIN_B FMAP
region. When only RW_A region is used, vboot does additional full_reset
cycles to try RW_B, even though it does not exist / the build was not
configured for two RW partitions. To avoid it, a new vboot context
flag has been introduced, VB2_CONTEXT_SLOT_A_ONLY, which can be set
right after context initialization to inform vboot about absence of
slot B. This will result in less full_reset cycles when vboot runs
out of available slots and cause vboot to switch to recovery mode
faster.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ie123881a2f9f766ae65e4ac7c36bc2a8fce8d100
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75462
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit dc7cc5bc6e ("mb/google/skyrim: Disable
USE_SELECTIVE_GOP_INIT") but limits the default enablement to Skyrim
variant only, to allow for continued testing.
BUG=b:271850970
BRANCH=skyrim
TEST=build/boot ChromeOS R117+ on google/skyrim, verify no display init
failures with feature enabled on cold/warm boots or S0i3 resume.
Change-Id: I21c70111a5f407a7e8dd1ad1f2c2759ddb91893e
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
cpu_cl_cleanup() function checks if the SOC supports storage-off
feature. This feature allows to turn off PUNIT SSRAM to save power.
Enable the storage-off if it's supported. Enabling it also clears the
crashlog records from PUNIT SSRAM.
cpu_cl_rearm() function rearms the CPU crashlog.
BUG=b:262501347
TEST=Able to build google/rex. Verified both features get asserted.
Change-Id: Id9ba0f5db0b5d2bd57a7a21f178ef1e86ca63fae
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77239
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add more details in CPU crashlog header structure, such as
storage off status and support, re-arm status etc. These fields
are used to check of particular feature is supported or not and
if supported what is the status of the feature.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I4242b6043b8f8ad9212780f44ca0448cd2b6b9f8
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77562
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
relanding original commit 5013c60a87
("soc/intel/meteorlake: Generate new TME key on each warm boot") which was previously reverted by commit 19e66b7c95
(Revert "soc/intel/meteorlake: Generate new TME key on each warm boot")
due to consecutive reboot post warm reset issue.
The consecutive reboot post warm reboot issue has been fixed with
commit ba7a9eefcf ("soc/intel/common: Fix
invalid MADT entries creation"), hence, reattempting to land the original TME key related patch.
BUG=299294328
TEST=Boot up the system, generate kernel crash using following
commands:
$ echo 1 > /proc/sys/kernel/sysrq
$ echo "c" > /proc/sysrq-trigger
System performs warm boot automatically. Once it is booted,
execute following commands in linux console of the DUT and confirm
ramoops can be read.
$ cat /sys/fs/pstore/console-ramoops-0
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I5d45d265ccef1a7d37669ea22a74b52e2f3ae20d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This reverts commit 449c6d981c.
Reason for revert: (EVT board build does not exhibit shutdown followed
by warm reboot)
This commit reverts the workaround that limits the TCC activation
temperature. The original issue that was reported (shutdown followed
by warm reboot) was not seen in the EVT board build, so this change is
likely unnecessary.
Change-Id: I22adcdee6512e57ad0b6d531f2611e22a95c863e
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77806
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Configure _DSC to ACPI_DEVICE_SLEEP_D3_COLD so that the driver skips
initial probe during kernel boot and prevent privacy LED blink.
TEST=Boot to OS, check camera LEDs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ib9375d602171aa5018b1add1deac3021724dc207
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC is added to mipi camera
driver to extend the same support for all SoCs, so removing this config
from Alderlake SoC code.
BUG=None
TEST=Build rex and brya to check if the build passes without an
error.
Change-Id: I5bc23fce89f0ae22b64b90cb12621320cac30d85
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Move the existing FSP 4221.00 headers for Raptor Lake to a
subdirectory called 4221.00_google, and select this if the
vendor is Google.
Add the standard FSP 4301.01 headers to a separate directory,
from Intel download #686654, and select this for all other
vendors.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Icd99bdee1eeac70dfcaca3d07150d3de6bb83d81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77101
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch addresses the increased boot time issue that occurs when ISH
store is enabled, such as in the "rex4es_ec_ish" variant.
During a cold reboot, the CBMEM memory resets and loses the stored
firmware versions. This causes the firmware versions to be fetched again
from the CSE, which increases the boot time by about 200 ms. This patch
stores a backup of the firmware version in CMOS and updates the CBMEM
memory during a cold reboot.
BUG=b:280722061
Test=Verified the changes on rex board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ibc5a027aa2bb7217e5032f56fece0846783557a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75755
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements APIs to access the CSE FW partition versions in
CMOS. The get API allows users to retrieve the current version from
CMOS memory. The set API allows users to set the version in CMOS
memory.
BUG=b:280722061
TEST=APIs verified on rex board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Idd0ee19575683691c0a82a291e1fd3b2ffb11786
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Remove the check to follow the new flow that commit 9c348a7b7e
("soc/intel/alderlake: Fix processor hang while plug unplug of
TBT device") introduced.
Processor hang is observed while hot plug unplug of TBT device. BIOS
should execute TBT PCIe RP RTD3 flow based on the value of
TBT_DMA_CFG_VS_CAP_9[30]. It should skip TBT PCIe RP RTD3 flow, if
BIT30 in TBT FW version is not set.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ie822b8e1fd7592a31275db8455519c4cc6ac02ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The memory log we get returned by QcLib contains Windows line endings
("\r\n"), while we prefer to have POSIX line endings in the CBMEM
console (just "\n"). Filter the '\r' character out when copying that log
into the CBMEM console to convert.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0652300c2393fbc0b3c9875bb0ca1aa921e59098
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77722
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
For x86 eXecute-In-Place (XIP) pre-memory `.data` section support, we
have to use an extra segment as the VMA/LMA of the data is different
than the VMA/LMA of the code.
To support this requirement, this patch makes cbfstool:
1. Allow the load of an ELF with an extra segment
2. Makes add-stage for XIP (cf. parse_elf_to_xip_stage()) write its
content to the output binary.
To prevent the creation of unsuitable binaries, cbfstool verifies that
the LMA addresses of the segments are consecutives.
TEST=XIP pre-memory stages with a `.data` section have the `.data`
section covered by a second segment properly included right after
the code.
Change-Id: I480b4b047546c8aa4e12dfb688e0299f80283234
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77584
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For x86 eXecute-In-Place (XIP) .data section support, cbfstool need to
to skip relocation of the .data section symbols in addition to
.car.data section symbols.
To support this requirement, this patch makes the `-S` option take a
multiple section names separated by commas.
TEST=With `-S ".car.data .data"`, XIP pre-memory stages with
a `.data` section do not have any of the `.car.data` or `.data`
section symbols relocated.
Change-Id: Icf09ee5a318e37c5da94bba6c0a0f39485963d3a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When using Intel(R) Xeon(R) Platinum 8490H on IBM/SBP1 the platform runs
with 480 cores. With 480 cores coreboot needs at least 440KiB for ACPI
tables. Bump the config to 512 KiB to have some free space for future
changes.
Change-Id: I2c0bbc36f45aab921f3189459de4438a0cd5dd1f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
This enables DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC for rex
variants boards with ES SoC to load pre-production signed IPU FW from
IPU kernel driver to make Camera function properly.
BUG=None
TEST=Build rex and check if SSDT-IPU0 includes the correct value for
"is_es" with Meteorlake ES and QS SoC.
Change-Id: I407d1932762622652939e8568fe34c704bc3b433
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77855
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This adds DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC to provide
the option to load pre-production or production signed IPU FW from IPU
kernel driver.
BUG=None
TEST=Build rex and brya to check if the build passes without an
error.
Change-Id: Ib507bceb6fd85d8ed764df82db400526a10e4d6e
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77854
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Dibbi variants are chromeboxes, so they need different settings in ec.h.
Add a new dibbi baseboard ec.h and use it for dibbi variants. For now
it's identical to the dedede baseboard ec.h. It will be updated in the
following CL.
BUG=b:294963793
TEST=With the following CL, boot dibbi and check the APCI tables no
longer contain lid and PS/2 keyboard devices.
Change-Id: I4075041ab8f02026623d1a26a555bee5eb09e77b
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77782
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Since d8f2dce "acpi.c: Swap XSDT and RSDT for adding/finding tables"
XSDT is primarily used to add new tables or to find the S3 resume vector.
However with QEMU coreboot does not generate most ACPI tables but takes
them from whatever QEMU provides. Qemu only creates an RSDT and lacks an
XSDT.
To keep the codebase simple with the assumption that XSDT is always
present, create an XSDT based on the existing RSDT and update the
address in RSDP.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ia9b7f090f55e436de98afad6f23597c3d426bb88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77385
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When CSE jumps between RO and RW, it triggers global reset so the
AP goes down to S5 and back to S0. For Chromebox, when AP goes
down to S5 EC set AP_IDLE flag. This cause an issue to warm reset
the Chromebox device when it is in recovery mode and powered by
USB-C adapter. This patch allows AP to direct EC to clear AP_IDLE
flag before trigger reset.
BUG=b:296173534
BRANCH=firmware-dedede-136-6.B
TEST=Chromebox DUT which is powered by USB-C adapter boots up
after warm reset in recovery mode
Change-Id: Ib0002c1b8313c6f25d2b8767c60639aed8a4f904
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77632
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Create the dochi variant of the brya0 reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:299570339
BRANCH=firmware-brya-14505.B
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_DOCHI
Change-Id: Iadeb97bd217278cdf777ae350100313b4345ecf3
Signed-off-by: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77756
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch shortens the name of the CBMEM field CBMEM_ID_CSE_INFO from
"CSE SPECIFIC INFORMATION" to "CSE SPECIFIC INFO" to improve the
alignment of the text on the screen. The functionality of the field has
not been changed.
BUG=NA
Test=Boot verified on rex board.
Change-Id: I39c716dab7d02d49e7d552cff77d544a1c168433
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77743
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In soundwire.h, SOUNDWIRE_DPN MIN & MAX are set to 1 and 14. When
creating the dpn array, the length was set to MAX - MIN or 13, numbered
0 to 12.
When accessing the array, the code was bailing out if a value greater
than MAX was trying to be accessed, so the array was able to be overrun
by two structure lengths.
Fix this problem by:
1) Not subtracting the MIN value when creating the array, which does
waste a little space. If anyone wants to refactor the code to fix that,
please feel free.
2) Breaking out of the loop when the port is equal to the MAX port
number instead of just when it's greater than the max port number.
Reported-by: Coverity (CID:1429766 & CID:1429771)
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0841bb8c9869fe9f53958f05614848785a98b766
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
The EFS data structure diagrams in the Makefiles of Picasso and newer
SoCs were wrong, since the BIOS directory table pointer is in a
different location than shown in the diagram. Since the diagram also
wasn't that easy to understand and amdfwtool does all of that handling,
drop the wrong diagram from the Makefiles.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5f86fea29f956ff10746d35dbe967a4a89e11cca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
When more ACPI tables are written than space is available in CBMEM, the
buffer overflow corrupts other CBMEM tables and a successful boot is unlikely.
Upgrade the error message to critical and be more precise what to do.
Change-Id: I152842945f552905729265f7d623cd581dd0a8d0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
commit f8ac3dda02 ("soc/intel/common:
Order the CPUs based on their APIC IDs") sort algorithnm walks all the
`cpu_info' entries without discarding empty ones. Since `cpu_info' is
not initialized, the data that is used is undefined and it generally
results in the creation of invalid `Local x2APIC' entries in the
MADT ("APIC") ACPI table.
Depending on the X2APIC ID value the Linux kernel behavior
changes (cf. arch/x86/kernel/acpi/boot.c::acpi_register_lapic()):
1. If (int)ID >= MAX_LOCAL_APIC (32768), the Linux kernel discards the
entry with the "skipped apicid that is too big" INFO level
message.
2. If (int)ID < MAX_LOCAL_APIC (32768) (including negative) this data
is taken into account and it can lead to undesirable behavior such
as core being disabled as (cf. "native_cpu_up: bad cpu" ERROR
kernel message).
TEST=Verified the MADT does not contain any invalid entries on rex.
Change-Id: I19c7aa51f232bf48201bd6d28f108e9120a21f7e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77615
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
The sta_himax83102 panel sometimes shows abnormally flickering
horizontal lines. The front gate output will precharge the X point of
the next pole circuit before TP term starts, and wait until the end of
the TP term to resume the CLK. For this reason, the X point must be
maintained during the TP term. In abnormal case, we measured a slight
leakage at point X. This is because during the TP term, the GPW does not
fully pull the VGL low, causing the TFT to not be closed tightly.
To fix this, we completely pull GPW to VGL before entering the TP term.
This will ensure that the TFT is closed tightly and prevent the abnormal
display.
BUG=b:299249186
BRANCH=corsola
TEST=FW Screen display normally
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I5dddaaa38917a65990c1474b657db5eb551940b1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77692
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MPTS method should only be generated for the board sku with 5G.
BUG=NA
TEST=Check kernel messages when going to S3. The following errors
should not be seen:
ACPI BIOS Error (bug):
Could not resolve symbol [\_SB.PCI0.RP06.RTD3._STA]
ACPI Error:
Aborting method \_SB.MPTS due to previous error (AE_NOT_FOUND)
ACPI Error:
Aborting method \_PTS due to previous error (AE_NOT_FOUND)
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I78f434c9049773cf5229d3a1f3934ae82d1fe46d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77690
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that platforms with lids, such as Chromebooks, only
select the VBOOT_LID_SWITCH configuration option.
Only samples the LID GPIO if VBOOT_LID_SWITCH config is enabled,
otherwise fake LID is open to avoid shutdown after reaching
depthcharge.
Tested by building and booting Google/Rex with the VBOOT_LID_SWITCH
configuration option enabled, and verifying that google/ovis does not
required VBOOT_LID_SWITCH config.
Change-Id: Ic5123b822a5a7021023319cb08a3f9e5225961ba
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77693
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch ensures that the LidStatus UPD is passed a dynamic value,
rather than always passing 1 (CONFIG_RUN_FSP_GOP enabled) for FSP 2.0
devices.
Problem statement:
* FSP-S GFX PEIM initializes the on-board display (eDP) even when the
LID is physically closed, because LidStatus is always set to 1.
* FSP-S skips external display initialization even when the LID is
closed.
Solution:
* FSP-S GFX PEIM module understands the presence of an external display
if LidStatus is not set, and tries to probe the other display
endpoint.
* Statically passing LidStatus as always enabled (aka 1) does not
illustrate the exact device scenarios, so this patch updates
LidStatus dynamically by reading the EC memory map offset.
BUG=b:299137940
TEST=Able to build and boot google/rex to redirect the display
using external HDMI monitor while LID is closed.
Change-Id: I7d7b678227a6c8e32114de069af8455b8c1aa058
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
initramfs is built always, ignoring CONFIG_LINUXBOOT_BUILD_INITRAMFS
Built initramfs only is CONFIG_LINUXBOOT_BUILD_INITRAMFS is set
BUG = N/A
TEST = Built and boot facebook monolith
Change-Id: I0d575ff7528fceb06b5394642527713bb071c8b3
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77607
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AMD's Windows display drivers validate the checksum of the VBIOS data
in the VFCT table (which gets modified by the FSP GOP driver), so
ensure it is set correctly after copying the VBIOS into the table if the
FSP GOP driver was run. Without the correct checksum, the Windows GPU
drivers will fail to load with a code 43 error in Device Manager.
Thanks to coolstar for root causing the issue.
TEST=build/boot Win11 on google/skyrim (frostflow), ensure GPU driver
loaded and functional.
Change-Id: I809f87865fd2a25fb106444574b619746aec068d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Instead of reporting all I2C controllers in the system as enabled in the
corresponding ACPI device's _STA method, report the I2C devices that are
disabled in the devicetree as disabled in the corresponding _STA method
too. This is done by returning the contents of the STAT variable inside
each device's scope in the DSDT that have a default value of 0 (device
not present/disabled). For all enabled and hidden I2C devices
i2c_acpi_fill_ssdt gets called which then writes 0xf (device enabled and
visible) or 0xb (device enabled, but hidden) to the STAT name inside the
same scope, but in the SSDT. This object in the SSDT will then override
the default in the DSDT resulting in the _STA method returning the
correct status of each device. The code was inspired by
commit 7cf9c74518 ("soc/amd/*: Fix UART ACPI device status").
TEST=On Mandolin all I2C controllers are disabled and with this patch
none shows up in the Windows 10 device manager. When enabling an I2C
controller in the devicetree for testing, it shows up again in the
Windows device manager.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4cd9f447ded3a7f0b092218410c89767ec517417
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
With kernel 5.15, puff hangs during power idle tests because
the NIC does not enter ASPM L1.2. We add "enable_aspm_l1_2" in
devicetree for RTL8111H to enable ASPM L1.2.
BUG=b:268859220, b:279618219
TEST=emerge and run power.Idle
Change-Id: I129dfd79e8112191453be513b2e3a260429b3030
Signed-off-by: Alexis Savery <asavery@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77570
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A workaround was added for puff to assert/deassert the #ISOLATE pin
during suspend/resume to resolve the situation where the realtek
ethernet device cannot enter L1.2 mode when its ASPM is disabled.
The realtek driver has since been fixed and ASPM of realtek devices have
been enabled on kernel 5.10 and 5.15 and this original workaround
is now causing suspend/resume errors on kernel 5.15:
r8169 0000:01:00.0: Unable to change power state from D3cold to D0,
device inaccessible
Puff devices were originally shipped with kernel 4.19, and applying
this change to the firmware on a device running 4.19 causes
suspend/resume failures, basically reversing the problem. We are
upreving the puff kernel to 5.15 so we need this patch, but since
it is incompatible with 4.19 we will have to take that into
consideration when pushing new firmware and potentially will need
to backport the necessary fixes to 4.19.
BUG=b:268859220
TEST=suspend_stress_test -c 500 on wyvern
Change-Id: I5eead2d70cd9528b3ca3fadd11f98c0330601324
Signed-off-by: Alexis Savery <asavery@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77378
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Currently pirrha's digitizer pen uses GPP_F12 for I2C HID interrupt
signal. But its IRQ number is the same as GPD2, which is used as
EC_SYNC_IRQ.
It caused EC driver loading error from dmesg:
cros_ec_lpcs GOOG0004:00: Failed to request IRQ 98: -16
cros_ec_lpcs GOOG0004:00: couldn't register ec_dev (-16)
cros_ec_lpcs: probe of GOOG0004:00 failed with error -16
So change the digitizer pen interrupt type to GpioInt to prevent
the conflict.
BUG=b:292134655
TEST=Verified EC driver reported no error and pen device worked
Change-Id: Ieb88e87fcfb06544a4b5b5133b752aa821fab76a
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77346
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the existing MRC cache storing logic, which was
spread between the ROM and RAM stages, into a single early MRC cache
store stage. The only exception is when SoC user selects
FSP_NVS_DATA_POST_SILICON_INIT to store MRC cache from ramstage (after
FSP-S).
It reverts all the boot-state logic previously used to locate and store
MRC cache from NVS HOB into NVS because majority of the platform can
potentially use the early MRC cache store with improved memory caching
at the pre-RAM phase (with the ramtop implementation).
The only exception is the Xeon SP platform, which currently locates
the MRC cache post in FSP-S (at ramstage). Therefore, this patch
provides an API to the FSP 2.x silicon init code to perform late
storing of the MRC cache.
In majority cases the updated logic, the romstage (post FSP-M) will
attempt to save the MRC cache. Platform that selects
FSP_NVS_DATA_POST_SILICON_INIT config performs the same operation post
FSP-S. Depending on whether the MRC_STASH_TO_CBMEM config is
enabled, the MRC cache will either be written directly to NVRAM at the
romstage or stashed into CBMEM for a late NVRAM write at ramstage.
Below table captures the change in the boot state w/ and w/o this
patch for storing the MRC cache. Overall the goal is to ensure the
platform behavior is remain unchanged before and after this patch.
w/o this patch:
| | Save MRC | Finalize | Lock the |
| | Cache | MRC Cache | Boot Medium |
+-----------+----------------+----------------+----------------+
| MRC_WRITE | BS_OS_RESUME | BS_OS_RESUME | BS_ON_RESUME |
| NV_LATE | CHECK_ENTRY | CHECK_ENTRY | CHECK_EXIT |
+-----------+----------------+----------------+----------------+
| MRC_STASH | BS_DEV | BS_DEV | BS_DEV |
| TO_CBMEM | ENUMERATE_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
+-----------+----------------+----------------+----------------+
| FSP_NVS | BS_DEV_INIT | BS_DEV | BS_DEV |
| DATA_POST | CHIPS_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
| SILICON | | | |
| INIT | | | |
+-----------+----------------+----------------+----------------+
| Platform | BS_PRE | BS_DEV | BS_DEV |
| w/o above | DEVICE_ENTRY | ENUMERATE_EXIT | ENUMERATE_ENTRY|
| config | | | |
| (FSP 2.0 | | | |
| platforms | | | |
w/ this patch:
| | Save MRC | Finalize | Lock the |
| | Cache | MRC Cache | Boot Medium |
+-----------+----------------+----------------+----------------+
| MRC_WRITE | BS_OS_RESUME | BS_OS_RESUME | BS_ON_RESUME |
| NV_LATE | CHECK_ENTRY | CHECK_ENTRY | CHECK_EXIT |
+-----------+----------------+----------------+----------------+
| MRC_STASH | BS_DEV | BS_DEV | BS_DEV |
| TO_CBMEM | ENUMERATE_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
+-----------+----------------+----------------+----------------+
| FSP_NVS | Post FSP-S | BS_DEV | BS_DEV |
| DATA_POST | (ramstage) | ENUMERATE_EXIT | RESOURCES_ENTRY|
| SILICON | | | |
| INIT | | | |
+-----------+----------------+----------------+----------------+
| Platform | Post FSP-M | BS_DEV | BS_DEV |
| w/o above | (romstage) | ENUMERATE_EXIT | ENUMERATE_ENTRY|
| config | | | |
| (FSP 2.0 | | | |
| platforms | | | |
BUG=b:296704537
TEST=Able to build and boot google/rex without any boot time impact.
Change-Id: Id1e91d25916594f59d1e467a142f5042c6138b51
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77556
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Specify the default path to, and automatically include the FSP binaries
needed to boot a board if USE_AMD_BLOBS is selected. Simplifies board
configs, and matches use in previous patforms.
TEST=build/boot google/skyrim
Change-Id: Ic837d264327723c8dc18a60fb16e8d41fe38b44e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77625
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Automatically include the FSP binaries needed to boot a board if
USE_AMD_BLOBS is selected. Simplifies board configs, and matches
use in soc/amd/picasso.
TEST=build/boot google/guybrush
Change-Id: I5b6e34085410a2aafe5d7876be5097f28f521ce8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77624
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames `SAVE_MRC_AFTER_FSPS` config to
`FSP_NVS_DATA_POST_SILICON_INIT` to highlight the violation in the Xeon
SP FSP implementation, where the FSP Silicon Init API produces
Non-Volatile Storage (NVS) instead of the FSP-Memory Init API.
According to the FSP 2.x specification (section 11.3), the FSP
populates the NVS data using the FSP_NON_VOLATILE_STORAGE_HOB and
expects the boot firmware to parse the FSP_NON_VOLATILE_STORAGE_HOB
after the FspMemoryInit() API in API mode.
However, not all Intel SoC platforms that support the FSP 2.x
specification adhere to this requirement. For example, the FSP binary
for XEON SP platform produces NVS data (aka
FSP_NON_VOLATILE_STORAGE_HOB) after the FspSiliconInit() API.
Therefore, attempting to locate NVS data after the FspMemoryInit() API
on these platforms would result in an error. The `save_mrc_data.c`
implementation provides the required hooks to locate the NVS post
FSP-Silicon Init and store into Non-Volatile Storage.
BUG=b:296704537
TEST=Able to build and boot Intel Xeon SP w/o any functional impact.
Change-Id: I815a64263fa1415bfe30bb3c1c35e4adee307e86
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
With the introduction of a new Linux version a problem has appeared
after a software initiated reset via CF9h register. The problem
manifests itself in the fact that the Linux kernel does not start after
the reboot. The problem is solved by setting bit 3 to 1 in Reset Control
Register (I/O port CF9h). This leads to the fact that the PCH will drive
SLP_S3 active low in the reset sequence. It leads to the same behavior
as in commit 04ea73ee78 ("siemens/mc_apl3: Set Full Reset Bit into
Reset Control Register") explained.
Change-Id: Ibc6d538c939e38732f42995d5ec6c8b61f979a6a
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77603
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the VR configuration for IA, SA, and GFX is
properly initialized, assigning zero values to VR causes a black screen
(no display) issue.
Problem Statement:
Override CEP (Current Excursion Protection) value with zero aka set to
disable results into black screen issue (no display).
Solution:
Keep CEP default enabled and don't override w/ zero value.
w/o this patch:
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[0] : 0x0
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[1] : 0x0
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[2] : 0x0
w/ this patch:
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[0] : 0x1
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[1] : 0x1
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[2] : 0x1
Change-Id: I8908e8b6c995390b559212d456db6ddf984448a3
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
All of the SoCs in the cannonlake directory select the following
options. So move them to the common option SOC_INTEL_CANNONLAKE_BASE
in order to deduplicate selections.
* FSP_USES_CB_STACK
* HAVE_INTEL_FSP_REPO
* SOC_INTEL_CONFIGURE_DDI_A_4_LANES
Change-Id: I6ce5edb2ba2c138b44601b32c3ecba2e761136f7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77447
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Remove MAILBOX word from CPU_CRASHLOG_MAILBOX_WAIT_STALL
and CPU_CRASHLOG_MAILBOX_WAIT_TIMEOUT macros, because they
can be used for other interface as well.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I62b04fa4b05c427db494a536ca6504db02dfeb68
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77236
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Region with metadata tag contains information about BDF entry for
SOC PMC SRAM and IOE SRAM. We don't need to parse this as we already
define BDFs in soc/pci_devs.h for these SRAMs. Also we need to skip
to region as it does not contain any crashlog data.
BUG=b:262501347
TEST=Able to build google/rex. Able to trigger crashlog and decode
correctly.
Change-Id: Id8ed40b865cde8e89045f5c9e713398fcbff5890
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76834
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When parsing descriptor table the record can have tag type = 7.
This tag contains metadata depending on SOC. The platform may
choose to parse it based on implementation of crashlog.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I60dda06950974f7949fa5635141e4b7798c4d1f2
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CPU crashlog discovery table and crashlog record is considered
invalid if first 32bits of the table is either 0x0 (no crashlog)
or 0xdeadbeef (invalid crashlog).
Crashlog record is considered consumed if bit 31 is set. So in this
case stop processing the subsequent records.
BUG=b:289600699
TEST=Able to build and verified invalid records are skipped on
google/rex.
Change-Id: Ia81bd293a533217425e44473ae85b2115c85faf6
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76333
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow the use of 64bit MMCONF base in MCFG table.
Previously only 32 bits were utilized for MMCONF base, while the
remaining 32bits were reserved & held value of zero as evident from MCFG
table disassembly. This commit entails updating the 'base_address' field
in the 'mmconfig' structure to 64 bits and removing the 'base_reserved'
field.
TEST=Confirmed the functionality of the 64bit MMCONF base in the MCFG
table disassembly below
Signature : "MCFG"
Table Length : 0000003C
Revision : 01
Checksum : BD
Oem ID : "COREv4"
Oem Table ID : "COREBOOT"
Oem Revision : 00000000
Asl Compiler ID : "CORE"
Asl Compiler Revision : 20230628
Reserved : 0000000000000000
Base Address : 0000001010000000
Segment Group Number : 0000
Start Bus Number : 00
End Bus Number : FF
Reserved : 00000000
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I2f4bc727c3239bf941e1a09bc277ed66ae6b0185
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77539
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a dummy soc (genoa) based on EXAMPLE_MIN86 with
amd linker script hooked up.
Default to 64bit code as that will be a sensible default for this
platform (high memory access required for RAS setup).
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I69253466084d17c4359d7e824d69f12490b076e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76495
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This board will use custom MP2 FW to dump the contents of the STB when
the SOC fails to enter/exit S0i3. Enable `PSP_LOAD_MP2_FW` by default.
BUG=b:259554520
TEST=Built and ran on skyrim device, verified that MP2 FW loads.
Change-Id: I4222521d01e2c98708f0e5b6693a8aee9e59edf2
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72118
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The rule being added to the refactoring section is already present
in the "coding style" section of the guide, but is currently easy
to miss. Adding it to its own section makes it a little more plain
and makes it more strongly worded.
Update a couple of other areas:
- Make kernel specific phrasing better aligned with coreboot.
- Remove duplicate "try to match" phrase in coding style section.
- Remove section on Data structures - it doesn't apply to coreboot.
- Update text to make it clearer and more coreboot-centric.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic3508529f639ea0609d2ea2032cc52407e9543e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71067
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add support for FSP ASPM and Clock PM configuration based on Kconfig
options: PCIEXP_ASPM, PCIEXP_CLK_PM and PCIEXP_L1_SUB_STATE. For some
use cases it may be desirable to disable ASPM and Clock PM to achieve
more deterministic and higher performance of PCIe devices.
TEST=Boot MSI PRO Z690-A DDR4 without ASPM and Clock PM. Confirm all
PCIe devices are still working and ASPM and Clock PM capabilities
are not present on the PCIe Root Ports.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I6d9d11016bed89dcfee6909d0d3e3e2e56237a2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69825
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The amdfw.rom is mostly in region COREBOOT. Calculate the relative
address as the CBFS module address. That is for future 32M flash size
support.
TEST=binary identical test on amd/birman amd/majolica amd/gardenia
amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon
pcengines/apu2
google/skyrim google/guybrush google/zork google/kahlee google/myst
This commit is part of a series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: I2add8e4e6755e582b3be6a150cf83d1468f2f1be
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72961
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is based on work by Arthur Heymans, 69852.
Get rid of the confusing "position index" and use the relative flash
offset as the Kconfig setting instead.
TEST=binary identical on amd/birman amd/majolica amd/gardenia
amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon
pcengines/apu2
google/skyrim google/guybrush google/zork google/kahlee google/myst
(The test should be done with INCLUDE_CONFIG_FILE=n)
Change-Id: I26bde0b7c70efe9f5762109f431329ea7f95b7f2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The Genoa SoC supports MMIO addresses larger than 48 bits. Since the
MMIO base and limit registers in the data fabric only contain bits 16 to
47 of the MMIO address, the MMIO address extension register is
introduced on some SoCs like Genoa. This additional register contains
the upper bits of the MMIO base and limit. Since it's not available on
all SoCs, introduce the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
Kconfig option to select the correct data_fabric_get_mmio_base_size
implementation to be added to the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic304f5797bc5661c1d511c95e457c6dde169d329
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77514
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Add HDMI GPIO configuration to early GPIO list to support
VGA text o/p in Pre-RAM stage on HDMI.
BUG=b:279173035
TEST=If CONFIG_UGOP_EARLY_GRAPHICS is set to y, check SOL
text on HDMI during Pre-RAM boot stage.
Change-Id: I13691850d09a442d5d5493a2b1dcf1145cf9797a
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch sets the Fast V-Mode (FVM) configuration parameter as
suggested in Intel doc 640982. As per the doc, Intel MTL-U 15W CPU
supports FVM on IA and SA.
Fast V-Mode (FVM): Intel Meteor Lake introduces the ability to manage
the peak power events it calls "reactive peak power management".
The Fast V-Mode is one such technique to perform the reactive peak power
management. It relies on the detector integrated inside the processor
which senses when the processor load current exceeds a present threshold
by monitoring the processor power domain IMVP (Intel Mobile Voltage
Positioning) VR sense point.
The baseline ITRIP for IA is 66A and 21A for SA.
BUG=b:286809233
TEST=Able to build and boot google/rex without seeing any performance
regression.
Change-Id: Ia7157bddf2e9586e4a91cc55e48693561072cd05
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75763
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
KBL_STATE was originally intended to provide more granular control
of the keyboard backlight. However, KBL_BRIGHTNESS has a valid value
of "off" which achieves the same thing.
Therefore, unconditionally set the KBL_STATE to enabled, and rely on
KBL_BRIGHTNESS.
Change-Id: Ic7ee6b96b1dcaa6633b111e92097bce87908885e
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77201
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds option to override Fast Vmode on Meteor Lake SoC.
This requires CepEnable, EnableFastVmode, IccLimit FSPM UPDs in FSP
header. If the hardware supports Fast Vmode, the FSPM will set the
ICC limit value to the value passed from coreboot.
With CepEnable and EnableFastVmode enabled, if IccLimit is not
specified by coreboot, FSPM sets IccLimit as default value. If no
values assigned to all the three CepEnable, EnableFastVmode and
IccLimit, coreboot sets their values to 0 and Fast Vmode is disabled.
BUG=b:286809233
TEST=In debug MTL FSP logs, the value of FSP parameters is as passed
from coreboot including enable_fast_vmode, cep_enable, and
fast_vmode_i_trip. Also, fast_vmode_i_trip value is passed to pcode
using mailbox command without any error. This test done on google/rex
board.
Signed-off-by: Jay Patel <jay2.patel@intel.com>
Change-Id: Id05dccac56c504523f9327babe0c6fbeff488ec2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75566
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
This patch adds logic for logging the FW splash screen event to
the event log.
There could be three possible scenarios as below:
1. Platform w/o FW splash screen (i.e., either HAVE_FSP_LOGO_SUPPORT
or BMP_LOGO configs not enabled)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) not
present in the event log.
39 | 2023-08-27 12:42:54-0700 | System boot | 12
40 | 2023-08-27 12:42:54-0700 | ACPI Wake | S5
41 | 2023-08-27 12:42:54-0700 | Wake Source | Power Button | 0
2. Platform w/ FW splash screen (i.e., both HAVE_FSP_LOGO_SUPPORT
and BMP_LOGO configs are enabled)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) is
enabled in the event log.
34 | 2023-08-27 12:07:29-0700 | System boot | 11
35 | 2023-08-27 12:07:29-0700 | Firmware Splash Screen | Enabled
36 | 2023-08-27 12:07:31-0700 | ACPI Wake | S5
37 | 2023-08-27 12:07:31-0700 | Wake Source | Power Button | 0
3. Failed to render FW splash screen (due to any reason if FSP failed
to render the splash screen)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) is
disabled in the event log.
43 | 2023-08-27 13:06:10-0700 | System boot | 13
44 | 2023-08-27 13:06:10-0700 | Firmware Splash Screen | Disabled
45 | 2023-08-27 13:06:11-0700 | ACPI Wake | S5
46 | 2023-08-27 13:06:11-0700 | Wake Source | Power Button | 0
BUG=b:284799726
TEST=Verify that the event shows up in the event log when the user
selects the HAVE_FSP_LOGO_SUPPORT and BMP_LOGO configs to display
the firmware splash screen.
Change-Id: Ie9e09acff5443c31b881c300134bc0bb06c490c6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch adds support for logging the firmware splash screen event
to the event log. There could be two possible scenarios for this
event: enabled and disabled.
BUG=b:284799726
TEST=Verify that the event shows up in the event log when the user
selects the HAVE_FSP_LOGO_SUPPORT and BMP_LOGO configs to display
the firmware splash screen.
Change-Id: I1e224903df21159d6eef2849a7d6fb05de09f543
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This change causes a freeze during boot on an RPL-UR that does not have
the memory part string in the CBI.
BUG=b:296353047
BRANCH=firmware-brya-14505.B
TEST='emerge-brya coreboot chromeos-bootimage', flash and boot
problematic DUT to kernel.
This reverts commit c51a7cdde4.
Change-Id: I99fe5111b5294673d9e0a5d13f9c240e0f4a92c3
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77516
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: <srinivas.kulkarni@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both mainboards have the same documentation. Instead of having two list
items referring to the same document, just merge the two items.
This fixes the following Sphinx warning:
WARNING: duplicated entry found in toctree: mainboard/lenovo/w530
Change-Id: I4140b34db01b1d5f47a39b9c1e33405e7789de63
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77503
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The document for northbridge/intel/i440bx doesn't exist and it didn't
exist at the time of introduction of these two mainboard documents. So
replace the reference with just the northbridge name.
This fixes the following Sphinx warning:
WARNING: unknown document: '../../northbridge/intel/i440bx/index'
Change-Id: Iaa67399f9d0e62d5d54ae08f5ebb8c70073c601f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Add new documentation generated by util/util_readme/util_readme.sh.
This also fixes the following Sphinx warning:
util/abuild/index.md: WARNING: document isn't included in any toctree
Change-Id: I26c33af3c5a5853f6bcce23e982a6b192b01f1d7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77441
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Clevo started using OZ711LV2 for the SD card reader around the time of
making its TGL boards. Without the driver, CPUs don't go to power states
lower than C2 due to LTR not being programmed. After enabling the driver
the CPU will go to C8 while the system is idle, giving significant power
savings if the system is left on battery power.
There is another issue with RPL where it only goes to C6 instead of C8.
This may be due to the intel_idle driver in Linux (as of 6.5-rc6
mainline and 6.4.6 stable) not supporting RPL C-states.
- tgl: Started being used with the Gazelle 3060 variant
- adl: Used on all models
- rpl: bonw15 does not have an SD card reader
Change-Id: I85c60feb6dcae7d877e70a6c6f2d3a7b3296fa0e
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77278
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The psp_transfer.h file was the same under all SoCs, and is really
tied to the file common/vboot/transfer.c, not the SOC.
This patch makes an include directory under vboot to put the header into
and sets it to be included for all SoCs using SOC_AMD_COMMON. This makes
the header file available to all platforms, so that new chips that don't
use the psp_verstage don't have to make a psp_transfer.h file just to
satisfy the compiler.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b9f2adee3a1d4d8d32813ec0a850344b7d717b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77303
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
License classifiers are much better about classifying files with SPDX
headers than they are at classifying the general text licenses due to
minor variations in the text. To help with classification, add the
SPDX headers to the files.
To see the current state of coreboot's licensing, see:
https://coreboot.org/fossology/
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If490f6705e7862d9ad02c925104113b355434101
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add new block for handling overclocking watchdog. The watchdog is
present since Skylake or maybe even earlier so it is safe to use with
most of the microarchitectures utilizing intelblocks.
The patch adds the common block for initializing and feeding the
watchdog. Timeout is defined statically in Kconfig and should be set
high enough by the board or SoC Kconfig to let the board boot with
full memory training and avoid reset loops. Full training of 128GB
DDR5 DIMM memory on AlderLake takes about 5 minutes. Newer SoCs
with newer memory technologies and higher RAM capacity may take more.
The default has been set to 10 minutes.
The patch also adds support for feeding watchdog in driverless mode,
i.e. it utilizies periodic SMI to reload the timeout value and restart
the watchdog timer. This is optional and selectable by Kconfig option
as well. If the option is not enabled, payload and/or software must
ensure to keep feeding the watchdog, otherwise the platform will
reset.
TEST=Enable watchdog on MSI PRO Z690-A and see the platform resets
after some time. Enable the watchdog in driverless mode and see the
platform no longer resets and periodic SMI keeps feeding the watchdog.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ib494aa0c7581351abca8b496fc5895b2c7cbc5bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68944
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We only checked that the resource fits below the given `limit` in
memranges_find_entry(), but then accidentally placed it at the top
of the found memrange. As most resources have only a coarse limit,
e.g. the 4G barrier of 32-bit space, this became only visible when
artificially setting an unusual, lower limit on a resource.
So, for the final placement, use `MIN(limit, range end)` instead
of the range's end alone.
Change-Id: I3cc62ac3d427683c00ba0ac9f991fca62e99ce44
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Create the nokris variant of the nissa reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:285838647
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_NOKRIS
Change-Id: If7cb00ce978236746dfe4d097d1f20aeebb96a35
Signed-off-by: Chen-Tsung Hsieh <chentsung@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
In order to support logging of events for PSR data backup command
status during CSE firmware downgrade, add support for
ELOG_TYPE_PSR_DATA_BACKUP and ELOG_TYPE_PSR_DATA_LOST types.
BRANCH=None
BUG=b:273207144
TEST=Verify event shows in eventlog after CSE firmware downgrade
Change-Id: Ibb78ac8d420bb7a64328ce009ddcb99030519ec6
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77005
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Add new eventlog types to support logging of Platform Service Record
(PSR) backup related messages. Eventlog entries are added on PSR data
backup success/failure and also when PSR data is lost.
BRANCH=None
BUG=b:273207144
TEST=Verify elog event added after PSR data backup command is sent
cse_lite: PSR_HECI_FW_DOWNGRADE_BACKUP command sent
...
ELOG: Event(B9) added with size 10 at 2023-07-27 06:44:49 UTC
Change-Id: I01ce3f7ea24ff0fdbb7a202ec3c75973b59d4c14
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77004
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TEST: Boot to ubuntu OS and verify that USB4 devices are listed in lspci command
00:08.3/06:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15c0
00:08.3/06:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15c1
Change-Id: I6253a7694702179454bc1ca14825fd4f3b949c13
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
When LZMA compression is selected, then it's not needed to check if LZ4
compression is selected in addition. So instead of handling both cases
separately, check for LZ4 only if LZMA is not selected.
This applies to the cases of both, FSP-M and FSP-S.
Change-Id: I4ea61a38baf4c29bf522a50a26c6b47292e67960
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77323
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch saves the output of the IWYU build into $(obj)/iwyu.txt. It
will also automatically adds -k to the MAKEFLAFGS when IWYU is selected,
so that the build doesn't halt after the first operation.
When IWYU is not selected, there is no change to the build.
This will allow us to create an automated IWYU build on jenkins.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0ea300d4c64bb923e9f7cc0e595885c3006ec3ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77192
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Add a new mainboard called fa_ehl which is based on Siemens's
'mc_ehl2'. This commit simply copies the mainboard directory and
adjusts the naming to match the new board's name. Moreover a variants
scheme is provided for possible alternative implementations. Follow-up
commits will introduce the needed changes for the new mainboard.
Change-Id: Ia389c8812d14db8b663547e6336e900becbc8be6
Signed-off-by: Johannes Hahn <johannes-hahn@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76444
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
Based on "MediaTek_EFUSE_MT8188_Confidential A_Technical Doc.docx",
MT8188G used in ChromeOS project does not support clock hardware
monitor. Thus, we can simplify the initialization flow by removing the
hardware default value check.
BUG=b:292866009
TEST=emerge-geralt coreboot
BRANCH=none
Change-Id: I07cd753f153da5b0aea1518a04a818214f986aeb
Signed-off-by: Sen Chu <sen.chu@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77334
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
When the script is run, it fetches a new copy of the repo, then creates
a tag, signed by GPG. When this signing step runs, a window pops up for
the user to enter their PGP key's passphrase. This window prevents the
user from doing anything else on their desktop, like looking up the
passphrase. It also times out after a while, and causes the script to
fail at that point.
To prevent this annoyance, pause right before the step asking for the
passphrase until the user is ready.
Because the submodules aren't tagged, we can delay their update until
after the tag is created to lower the amount of time needed before the
tag & signing step.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I414dfc0f8944b4408881392278a2bce2a364992b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77366
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This script allows any user with abandon rights to abandon patches that
haven't been touched (reviewed, commented on, rebased, etc) in over a
year.
As a part of the release process, we're now going to run the script to
abandon all of those patches so that we don't get to the point of
needing to abandon 1300 patches again in the future.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4a07c09edf02d9c1858a58322095eefbceb529d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Create the quandiso variant of the nissa reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0.)
BUG=b:296506936
BRANCH=firmware-nissa-15217.B
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_QUANDISO
Change-Id: I846c39260e2db504d7bec6e81a8317b6824c17f4
Signed-off-by: Robert Chen <robert.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77258
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
When using the Windows fast startup mechanism which is enabled by
default, Windows will use a cached version of the ACPI tables during
normal boots after a clean shutdown. Since I've run into this issue and
spent quite a bit of time debugging the wrong issue due to this, better
document this possibly unexpected behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia9e65f6a3aff13fa54abe68c8f5fcbf9bc6efc1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Add some HDMI-related gpios that are needed for early sign-of-life
to the early_graphics_gpio_table array so that SOL will show up on
HDMI ports.
BUG=b:277861633
BRANCH=firmware-brya-14505.B
TEST=`emerge-brya coreboot chromeos-bootimage` and verify it builds
without error.
Change-Id: Ic36a636e68c2d457f40329a2e9c69dab5bbba41f
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77353
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The doc.coreboot.org container is several years out of date, using the
three year old Alpine 3.8 as the base image along with Sphinx related
pip packages which are even older. Accordingly, update the documentation
related pip packages in the coreboot-jenkins-node container as well.
- Update doc.coreboot.org to Alpine 3.18.3
- Update documentation related pip packages on coreboot-jenkins-node
and doc.coreboot.org to the latest versions on PyPI
- Update Sphinx to 6.2.1 as the latest version of sphinx_rtd_theme does
not yet support sphinx >= 7
The updates also noticeably improve performance, dropping documentation
build times from ~75 s down to ~42 s on my system from the Alpine+Python
updates alone, and further down to ~35 s with the rest of the updates.
TEST: The documentation builds and renders properly when built using the
updated container.
Change-Id: I38dfd22ee71c3779ab5fd3b3060e4675e9e3fe54
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73159
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If IASL isn't installed, the genbuild script throws a confusing warning.
This can and should be ignored because toolchain.inc will find this and
provide a much better error message.
The trailing >/dev/null was probably intended to do this, but didn't
actually affect anything.
Adding quotes around the IASL command will make "" be the command that
tries to get run instead of `-v` when IASL isn't present. This will
always be a failure, whereas `-v` could theoretically be a valid
command.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ibff93db670766c4de21faa7553f2003450465407
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76857
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
PchPcieClockGating and PchPciePowerGating UPDs are not yet available
in RPL-S IOT FSP. It also looks like those UPDs are not generally
available in all public RaptorLake FSP headers yet, so guard it
against SOC_INTEL_RAPTORLAKE to avoid build errors.
Change-Id: Iedac21bafa3428957e054fc8fefa38f9f776772d
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77337
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This adds a Kconfig option to select memtest86+ version 6 as a secondary
payload and sets that as the default. The coreboot version 5 code may
still be selected and used if desired.
Compiling for 32 bit requires glibc from multilib installed, if the host
system is running on 64 bit, as header files, e.g. gnu/stubs-32.h, are
required from there. So introduce a new choice menu which allows to
choose between 32 and 64 bit.
By default, the stable 6.20 version is selected instead of the top of
the main branch.
TEST=Build both V5 and V6, boot them in QEMU
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Ie0eedc25fcf37b925b072ca809c019a599a20392
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This binutils patch was pushed by the original author using the word
"loosing", which means "to release" instead of "losing", meaning to drop
or misplace.
I did not change the spelling of the commit message inside the patch so
that the patch can still be tracked easily, but wanted to fix the
mistaken spelling which appears when the patch is applied when building
the crossgcc toolchain.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I66fd596a79c9eb331f473d175180cf7bb5a38529
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
We've had issues in the past where building with a sufficient number of
processors would expose a previously hidden timing issue in the build.
Those have frequently been in the path of a single chip or architecture,
so this adds a few different builds.
I'd like to have a representative sampling without increasing the build
time too much so maybe in the future, we can modify the clang build
targets to be different than the GCC targets.
These can be updated to different targets over time.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I51e39bc1ce6b9b7c257d0170ce3d2b5ab99d35df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77329
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
When installing the python modules with pip3 as root, the installer
throws a lot of warnings about conflicts and recommends that it not
be run that way. This change installs the python modules as the
coreboot user instead. The --break-system-packages argument can now
be removed.
It takes along some other changes made to the coreboot home directory
which also don't need to be run as root, and now adds the .local/bin
directory into the path.
The trailing docker PATH configuration is discarded as cleanup - it
doesn't have any effect. Nothing uses it in the Dockerfile, and it
doesn't end up updating the path, which is set by /etc/profile.
Change-Id: Ie8273009bb527e267584bba84504191aa7294ca3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76855
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The libfreetype6-dev has been a transitional package pointing at
libfreetype-dev for a while now. The libfreetype6-dev package is
currently out of date in debian sid, so it's a good time to switch
away from it.
TEST=Rebuild coreboot-sdk
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If40e9eacf871d3840745ea18ec2ff5975cc62da7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77328
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Registering Clock Driver (RCD) is responsible for driving address and
control nets on RDIMM and LRDIMM applications. Its operation is
configurable by a set of Register Control Words (RCWs). There are two
ways of accessing RCWs: in-band on the memory channel as MRS commands
("MR7") or through I2C.
Access through I2C is generic, while MRS commands are passed to memory
controller registers in an implementation-specific way.
See JESD82-31 JEDEC standard for full details.
Change-Id: Ie4e6cfaeae16aba1853b33d527eddebadfbd3887
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The default branch for the board-status repo was renamed to main, and
thus the -u option for board_status.sh no longer works as it tries to
push to master. Update the branch accordingly.
TEST: board_status.sh is able to upload results to review.coreboot.org
using the -u flag.
Change-Id: Ic90e95d8701e21c4ae30a7ac85560eebe7658d79
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The EFER MSR is in the SMM save state and RSM properly restores it.
Returning to 32bit mode was only done so that fxsave was done in the
same mode as fxrstor, but this is no longer done.
See commit 1efca4d570 (cpu/x86/smm: Drop fxsave/fxrstor logic)
TESTED on qemu: the smihandler works fine.
Change-Id: Ie0e9584afd1f08f51ca57da5c4350042699f130d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68895
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Excluding the "recommended" packages reduces the size of the container
image from ~8.40GB to ~7.23GB.
Install the following packages in addition as they are useful for one or
the other case, or at some point even required:
* ca-certificates
* less
* neovim
* openssh-client
Change-Id: Ic38ba75765e3a0c21bbfe3f380880c9ac575d0d2
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76085
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While Debian Sid provides GCC version 13, GNAT is still on version 12.
To keep them in sync, install GNAT 13 explicitly instead of the meta
package that is still referring to GNAT 12.
The coreboot toolchain including GNAT still compiles fine.
Change-Id: Ifb2b4c5fbaf3c0a8a78f6ebe244e2ccfec664b41
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
broadwell/pch/Kconfig is sourced if SOC_INTEL_BROADWELL is true. So
remove 'if SOC_INTEL_BROADWELL' condition and duplicated
'INTEL_LYNXPOINT_LP'
Change-Id: I9b5676fd232b47e9d5f89f7faffdfd5d2c76984e
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76699
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While debugging lack of battery status under Windows, it was discovered
that the read/write flags in the args to the EC RAM 'ECRW' method were
not being correctly identified. Force set them from the R() and W()
methods which call ECRW() so those calls are processed properly.
TEST=build/boot Windows on google/drallion, verify battery status,
charging, etc are all reported properly.
Change-Id: I2a40b8d50ba65213813c781e53b56cc1a8b8debf
Signed-off-by: Coolstar <coolstarorganization@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72472
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
IOE_PMC support was not enabled on Meteor Lake platforms. This patch
adds the bare minimum hooks to initialize and allocate a memory region
for IOE operations. Additionally, this patch moves those IOE operations
to a newly included IOE-specific file, Previously, PMC was responsible
for these operations.
BUG=b:287419766
TEST=build and verified on google/rex.
Change-Id: I8bbc0b8a3e32dad5404c80bc7717ef07e3ec60b9
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77261
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
C1-state auto demotion feature allows hardware to determine C1-state
as per platform policy. Since platform sets performance policy to
balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter PC2 and lower
state in camera preview case and save platform power.
Note: C1 demotion heuristics used EPB parameter to balance between power
and performance, i.e. low threshold when EPB is low in-order to get C1
demotion faster and vice-versa. ChromeOS operates at default EPB=0x7
(low EPB) in both AC/DC, so in DC mode it gets more C1 demotion hits
than expected (similar to AC mode) and losing power respectively.
ref. https://review.coreboot.org/c/coreboot/+/76827
BUG=b:286328295
TEST=Code compiles and correct value of c1-state auto demotion is
passed to FSP. Also verified PC residency improvement ~10% in
camera preview case.
Change-Id: I1b2db634176f0072c535608c5600846a9086fef1
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Allow users of Alderlake N processors to use the microcode repository
and also add their related microcode blob to the list of microcodes
which should be included in the coreboot rom.
Change-Id: I11c9cb13fa81118bfcb819bad5fb39731c7e3e76
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Newer versions of Sphinx complain about the language being set to None,
so explicitly set it to 'en'. The syntax that is currently used to
enable custom CSS styling for tables [1] also no longer works, resulting
in the docs rendering without CSS. Fix this using the html_css_files
option instead.
TEST: The documentation builds and renders correctly with both Sphinx
1.8.3 in from the doc.coreboot.org Docker container and Sphinx 7.2.2
from distro packages.
[1] Commit a78e66e5f4: Documentation: Add static CSS file to fix tables
Change-Id: I036b1cad3cfa533c0c3a037bac649caa2d968d4b
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add data.vbt files for all variants supported by current brya, brask,
and nissa recovery images. Select INTEL_GMA_HAVE_VBT for all variants
which currently have a VBT file.
TEST=build/boot various brya variants (banshee, osiris, redrix)
Change-Id: Ic66f91e264d37c3742cb17994f637604d77a1576
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77144
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements `soc_is_ish_partition_enabled()` override to
uniquely identify the SKU type between ISH and non-ISH to conclude
if ISH partition is enabled and need to retrieve the ISH version from
CSE FPT by sending a HECI command.
BUG=b:285405031
TEST=Able to uniquely identify the ISH SKUs while booting
to google/rex_ec_ish to dump the ISH version.
Change-Id: I48358ad9e2e582e8b2274cbf4655de01f8792e6c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77177
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch uses the CSE firmware specific data to store Intel
ISH firmware related information. Sending an ISH partition version
information command on every boot cycle would impact the overall boot
performance.
This information is used by the auto-test framework to ensure the ISH
firmware update is proper for in-field devices.
BUG=b:285405031
TEST=Able to build and boot google/rex. Verified ISH FW version is
getting displayed across warm resets without impacting the boot time.
Change-Id: I0242c26dd90d834815799f54740d8147ff9d45b7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77176
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch selects SOC_INTEL_STORE_CSE_FW_VERSION config by default
for CSE LITE SKU. It helps to dump the CSE RW firmware version which
further consumed by auto-test infrastructure to ensure CSE RW firmware
update is successful.
BUG=b:285405031
TEST=Able to build and boot google/rex.
Verified CSE RW FW version (for LITE SKU) is getting displayed without
impacting the boot time.
Change-Id: Iba5903c73c0a45b01e6473714e0d5f759c061825
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77175
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch introduces a CSE firmware specific data in order
to store Intel CSE and associated firmware related information which
requires a sync between Pre-RAM and Post-RAM phase.
This information will be used further to retrieve currently running
CSE RW firmware instead of fetching the version information by sending
a HECI cmd (which consumes 7ms-15ms depending upon the CSE operational
state).
Current implementation attempts to simply the CSE RW FW version store
and retrieval operations as below
* CSE sync in romstage (aka Pre-RAM) - Relying on .bss segment to store
the CSE info data in absence of real physical memory and sync back into
the CBMEM once available (after FSP-M exits).
* CSE sync in ramstage (aka Post-RAM) - Directly stored the CSE RW
version into the CBMEM (as CBMEM is online).
BUG=b:285405031
TEST=Able to build and boot google/rex. Verified CSE RW FW version
(for LITE SKU) is getting displayed without impacting the boot time.
w/o this patch:
10:start of ramstage 722,257 (43)
17:starting LZ4 decompress (ignore for x86) 723,777 (1,520)
w/ this patch:
10:start of ramstage 722,257 (43)
17:starting LZ4 decompress (ignore for x86) 723,777 (1,520)
Change-Id: Ia873af512851a682cf1fac0e128d842562a316ab
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77174
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Disable TPM support for CR50 TPM when using MrChromebox repo, since
it's not currently supported in edk2, and causes some boards (eg AMD
Zen-based) to failed to boot.
TEST=build/boot on google/frostflow
Change-Id: I64b5eb09d64eafd2bed400b7a7c97750cc368aed
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77270
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Kconfig for passing a VBT file and GOP driver to edk2, and pass a
build param to use them along with the platform GOP driver. This allows
edk2 to initialize the display and change display modes, instead of
being limited to the single mode set by whatever display init method
coreboot might use (libgfxinit, FSP/GOP, VBIOS, etc).
TEST=build/boot multiple google boards spanning several platforms using
the edk2 GOP driver for display init.
Change-Id: I63a49df2411fe44b06eaee6d0fb9aab42ac8aedb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
When cbfs_map()/cbfs_ro_map() fails, the caller may still want to know
the decompressed size of the CBFS file, for example, to print an error
message. Move the assignment earlier in the flow. Note that coreboot's
cbfs_map() is already doing the same.
BUG=none
TEST=emerge-geralt libpayload
BRANCH=none
Change-Id: I82c6b7e69c95bf597fa3c7d37dd11252893c01af
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77193
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update header files for FSP for Meteor Lake platform to version 3292.83,
previous version being 3223.80.
The patch doesn't include any function changes, only a few comments and
headers have been changed.
BUG=b:295126631
TEST=Able to build and boot google/rex to ChromeOS.
Change-Id: I27f88732bfafd4732ea39bf9c54e18341dd26cf9
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The site-local directory is not checked into the coreboot tree, so this
change excludes it by default. By adding the site-local directory,
an issue could be missed in the rest of the coreboot tree.
This change also adds a new command-line argument of -S or --site_local
that re-enables the site-local checking.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I95efa3e7b2cbb84e5c84d263222d8e914626d314
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77138
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add support for ACPI display brightness controls, so that panel
adjustment is available under Windows.
TEST=build/boot Win11 on google/drobit, verify panel brightness
controls available and functional.
Change-Id: Ic0c026ae09b3fde648db4bdeb4971423953c96a1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77143
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configures ISH related GPIO's based on FW_CONFIG obtained from CBI.
BUG=b:280329972,b:283023296
TEST= Set bit 21 of FW_CONFIG with CBI
Boot rex board
Check that ISH is enabled, loaded, and functional
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Change-Id: I778251aadef4499427fc9855adfdd9cade3a3e70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77235
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch chooses to show the early splash screen which is an
OEM feature. The current implementation is relying on the Intel
FSP GFX PEIM to perform the display initialization.
Having this feature allows the platform to show the user notification
with 500ms since boot compared to traditional scenarios where first
user notification is coming from kernel (typically ~3sec+ after cpu
reset). Eventually this feature will help to improve the user
experience while booting Intel SoC platform based chromeos devices.
BUG=b:284799726
TEST=Able to see the early splash screen on google/marasov.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2449bf97d6c82cb08f603b29643cc261738b5379
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch adds the ability to show a pre-boot splash screen on
Meteor Lake systems using FSP-S.
The patch calls into `fsp_convert_bmp_to_gop_blt()` when the
`BMP_LOGO` config is enabled. This function converts a BMP
file to a BLT buffer, which is then used by FSP-S to render the splash
screen.
Additionally, increase the heap size (malloc'able size) upto 512KB
(when BMP_LOGO config is enabled) to accommodate high
resolution logo file.
BUG=b:284799726
TEST=Able to see splash screen while booting google/marasov
with BMP_LOGO config enable.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I9f4d1bc0aa991e784624ca19ba96a259ab8ddfa6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch selects LZ4 decompression for logo CBFS file. Able to save
2ms of the boot time when HAVE_FSP_LOGO_SUPPORT config is enabled.
However, the compressed BMP logo size is increased by ~2KB.
Raw BMP Image size is ~97KB.
BUG=b:284799726
TEST=Able to see pre-boot splash screen while booting google/rex
with 32MB (W25Q256JWEIM) SPI-Flash.
w/o this patch:
sudo cbfstool image-screebo4es.bin print -r FW_MAIN_A
FMAP REGION: FW_MAIN_A
Name Offset Type Size Comp
...
...
logo.bmp 0x167480 raw 6172 LZMA (97078 decompressed)
...
15:starting LZMA decompress (ignore for x86) 849,090 (1,022)
16:finished LZMA decompress (ignore for x86) 851,207 (2,116)
w/ this patch:
sudo cbfstool image-screebo4es.bin print -r FW_MAIN_A
FMAP REGION: FW_MAIN_A
Name Offset Type Size Comp
...
...
logo.bmp 0x167480 raw 8568 LZ4 (97078 decompressed)
...
17:starting LZ4 decompress (ignore for x86) 849,419 (1,279)
18:finished LZ4 decompress (ignore for x86) 849,559 (140)
Change-Id: I856c39146a5ec0faf44c1cd37fa7c0d7296bf673
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch adds a new configuration option to allow the compression
algorithm for the logo cbfs file to be specified. By default, the logo
cbfs file is compressed using LZMA. However, enabling LZ4 compression
can save ~2ms of boot time when the BMP_LOGO config is enabled.
This patch verified that the logo cbfs file can be booted using either
LZMA or LZ4 compression.
BUG=b:284799726
TEST=Able to boot google/rex and verified firmware splash screen using
either LZMA or LZ4 compression.
Change-Id: Ib0aa5320632ae3f734004d2b1d495af11c2e1928
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Intel has rebranded ESE as ISSE (Intel Silicon Security Engine),so all
references to ESE is updated to ISSE in the current coreboot code.
BUG=None
TEST=Build all the variants based on Intel Meteor Lake SoC
Signed-off-by: Usha P <usha.p@intel.com>
Change-Id: I1f8785704706d56a35e94a0f3386bc551cd1f263
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77241
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Early Chromebook generations stored the information about
USB port power control for S3/S5 sleepstates in GNVS, although
the configuration is static.
Reduce code duplication and react to ACPI S4 as if it was ACPI
S5 request.
Change-Id: I7e6f37a023b0e9317dcf0355dfa70e28d51cdad9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The docker-shell target was originally intended to point at the
docker-jenkins-node image, and was documented as such. It was actually
split into two targets - docker-shell and docker-jenkins-shell.
This fixes the documentation for docker-shell and adds new help
for docker-jenkins-shell. The docker-jenkins-shell target is also
noted as phoney now.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib3ce82f6a73a2f81e5ae51ce8063ae4e59ef67db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Update DPTF thermal settings from thermal team suggestion:
1. Modify CPU passive policy to 95.
2. Modify TS0/TS1/TS2 passive policy to 90 for CPU.
3. Modify TS1 passtve policy watt to 6w.
4. Modify TS0/TS1/TS2 critical policy to 100.
BUG=b:294479707
TEST=Build and verify DPTF value by thermal team on Boxy system
Change-Id: Ic34e44f218ff980c54bf93841880fab5e21b3fca
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77108
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of open coding this, use the mmio_range helper function to tell
the resource allocator about the northbridge's IOAPIC's MMIO. This
change sets the IORESOURCE_RESERVE and IORESOURCE_STORED bits in the
resource flags that weren't set before, but mmio_range is already used
elsewhere for similar purposes.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id66a73cdb22fd551e4359914ba5513313dcc3193
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Disable NULL breakpoints in setup_realmode_idt before calling
write_idt_stub in a loop.
TEST=No more spurious Null dereference errors in the console output.
Before Mandolin showed these two errors before running the VBIOS:
[ERROR] Null dereference at eip: 0x4e6f1a35
[ERROR] Null dereference at eip: 0x4e6f1a4f
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2255d85030e41192ae8a3a7f0f6576c0d373eead
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Instead of open coding the same functionality, use fixed_io_range_flags
to tell the resource allocator about the FCH subtractively decoding the
first 0x1000 bytes of I/O space. Also update the comment to match the
code.
TEST=On Mandolin the flags of this resource stay the same (0xc0040100).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia30a87a4e37c98248568476b74af2730a3c0e88d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77170
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use get_iohc_fabric_id() to translate the coreboot domain's number into
the destination data fabric ID of the PCI root. This allows using the
coreboot domain 0 as primary domain of the SoC in all cases, so it's
still possible to use config_of_soc(). This allows dropping the
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_DOMAIN_MULTI_PCI_ROOT Kconfig option
and do the check if the destination fabric ID in the PCI bus number,
MMIO, and IO decode registers is the correct one for the domain without
the need to use a non-zero number for the primary PCI root domain.
TEST=Mandolin still boots and the PCI bus, IO and MMIO resources still
get reported correctly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I880ee0bf5c185cfe4af7de0d39581eb951ee603a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77169
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement get_iohc_fabric_id for each SoC that translates the coreboot
domain number to the fabric ID of the corresponding PCI root. This
allows the primary domain to have the number 0 even though the
destination data fabric ID will be non-zero. Keeping the primary domain
number 0 allows to use config_of_soc() which can be resolved at link
time and not need to dynamically find the SoC device to get the config.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6538a777619eed974b449fc70d3fe3084ba447dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the commonlib, console, northbridge, security, and
southbridge directories that don't already have an SPDX license line
at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I02804a10d0b0355e41271a035613d9f3dfb122f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
In the case of SoCs hat have more than one PCI root, we need to check to
which PCI root the PCI bus number, IO and MMIO regions configured in the
data fabric registers get routed to and only tell the resource allocator
about the resources that get routed to the current PCI root domain. For
this the numbers of the domains need to match the PCI root's destination
data fabric ID.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib6a6412f733d321044678d2b064c33418a53861c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Intel Platform Service Record (PSR) provides on-platform persistent and
tamper resistant ledgers and counters.
Key events captured within the Intel PSR Event Ledger, e.g., Chassis
Intrusion Detection, can be observed over the life cycle of the platform
to help assess confidence.
Counters for platform S0 operational use and power state transitions can
be assessed to aid in the determination of general wear or correlations
of other platform events when determining platform decommission plans
(repurpose, resell, recycle).
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost.
CSE Lite SKU firmware supports a command to backup PSR data before
initiating a firmware downgrade. Add a config to support this PSR data
backup flow.
BRANCH=None
BUG=b:273207144
Change-Id: Iad1ce2906177081c103ef4d4bcef78fa2c95026f
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Based on contents from coreboot wiki[1], this patch adds much needed
documentation for the very important abuild utility.
On top of what was there:
- Mainboard targets have been updated
- Added example for building one variant of one board
- Added example for building boards selectively and/or with custom
configurations using --skip_set/--skip_unset, -K, and config files
[1] https://www.coreboot.org/Abuild
Change-Id: I69701eaeef616828bc30736aba2f617e844a3148
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The data fabric also controls which PCI bus numbers get decoded to the
PCI root. In order for the resource allocator to know how the hardware
is configured, read the corresponding data fabric registers to get the
information that then gets passed to the allocator.
Picasso, Cezanne, Mendocino and Rembrandt only support one PCI segment
with 256 buses while the Phoenix and Glinda data fabric hardware has
support for more PCI segments. Due to this change, the register layout
is different and incompatible between those two, so introduce the
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_MULTI_PCI_SEGMENT Kconfig option for a
SoC to specify which implementation is needed. At the moment, coreboot
doesn't have support for multiple PCI segments and the code doesn't
support PCI segments other than segment 0.
On Picasso the PCI bus number limit read back from the data fabric
register is 255 even though CONFIG_ECAM_MMCONF_BUS_NUMBER is set to 64,
so also make sure that the bus and limit returned by
data_fabric_get_pci_bus_numbers is within the expected limits.
TEST=PCI bus allocation still works on Mandolin (Picasso) and Birman
(Phoenix). Picasso has 64 PCI buses. coreboot puts this info into the
resource producer in _SB\PCI0\_CRS which the Linux kernel reads:
* coreboot: PCI0 _CRS: adding busses [0-3f]
* Linux: pci_bus 0000:00: root bus resource [bus 00-3f]
This matches the information in the ACPI MCFG table.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide5fa9b3e95cfd59232048910cc8feacb6dbdb94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77080
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fixed I/O resource descriptor macro implies that the device will
only decode 10 of the 16 IO port bits causing aliasing. Use an I/O port
descriptor instead and use Decode16 to tell the OS that this I/O
resource will decode all I/O address bits.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2df260cea6f12f5a3a6cbae3c7b99bab244a556b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The fixed I/O resource descriptor macro implies that the device will
only decode 10 of the 16 IO port bits causing aliasing. Use an I/O port
descriptor instead and use Decode16 to tell the OS that this I/O
resource will decode all I/O address bits.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6183d625fb7968fb33caf396f19feef8917ba4fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The SOC_AMD_REMBRANDT_BASE comment at the end of Glinda's Kconfig is
probably a leftover from the Mendocino/Rembrandt SoC this file was
copied from. Change it to SOC_AMD_GLINDA to match the corresponding
'if SOC_AMD_GLINDA' in the file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I85132e4840c1bc713cfc2f3493f800d66edd10ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Neither Windows nor mainline Linux make use of IOSF on the Braswell
platform, so adjust the ACPI status return value based on
CONFIG(CHROMEOS) to prevent an unknown device being listed in Windows
device manager.
TEST=build/boot Win11, Linux 6.2 on google/edgar
Change-Id: Ic51624ffd816d48c007c13d510601cf8cbf1edc4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77142
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Neither Windows nor mainline Linux make use of IOSF on the Baytrail
platform, so adjust the ACPI status return value based on
CONFIG(CHROMEOS) to prevent an unknown device being listed in Windows
device manager.
TEST=build/boot Win11, Linux 6.2 on google/swanky
Change-Id: I249028c57cc704955cf5a11e2088780ef58e16cf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77141
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Neither Windows nor mainline Linux make use of DPTF on the Baytrail
platform, so guard its inclusion with CONFIG(CHROMEOS) to prevent an
unknown device being listed in Windows device manager.
TEST=build/boot Win11, Linux 6.2 on google/swanky
Change-Id: Ifc4d349691b647fe2d70c92bd20d1b1128b1e10a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77140
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After enabling VBOOT_CBFS_INTEGRATION, bootblock exceeds allocated size
(60K) by 3.5K. Since TPM and EC won't be accessed in bootblock, we move
I2C and SPI initializaion to verstage to reduce bootblock size. The GSC
interrupt pin configuration is also moved to verstage to save more
spaces for bootblock.
The size of bootblock.raw.bin is reduced from 64,040 bytes to 60,808
bytes.
BUG=b:294643742
TEST=boot to kernel
Change-Id: I5f6855d5a1a0fce6e739d44652c88e406f6f7b89
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The EC should be mirrored (if it's out of date) unconditionally if
the board support Thunderbolt. Use DRIVERS_INTEL_USB4_RETIMER instead
of SOC_INTEL_COMMON_BLOCK_TCSS as it's more suitable.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I27b238d4d404746c9a70bacf8e60d9e0b0e1ccca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76579
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This variant was inadvertently missed when upstreaming other rambi
variants, so add it here for completeness. Add ACPI for the light
sensor to common code to match all other i2c devices.
Sourced from downstream Google branch firmware-expresso-5216.223.B,
commit 6f4073c0e8c8 ("baytrail: implement baytrail technical advisory
556192").
Change-Id: Ia507f95f6af85344e1ab8452f7b3c2cc61526699
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Set the maximum subordinate bus number of the domain to the last PCI bus
number that is decoded to this PCI root. This makes sure that the
resource allocator knows the maximum number of PCI buses on this PCI
root to not assign bus numbers to buses below this PCI root that aren't
routed to that PCI root.
Now that we have this info in the link list structure or the domain
device, we can pass the max_subordinate field to the
acpigen_resource_producer_bus_number call and can leave the subordinate
number after pci_domain_scan_bus is done unchanged instead of setting it
to the limit.
TEST=On Mandolin both the bus resource producer in _SB\PCI0\_CRS and the
PCI bus number allocation remain unchanged.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2ee75b2a7054a306b0c7d98c5357391c029187bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77112
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the ability to show a pre-boot splash screen on
Meteor Lake systems using FSP-S.
The patch calls into `fsp_convert_bmp_to_gop_blt()` when the
`BMP_LOGO` config is enabled. This function converts a BMP
file to a BLT buffer, which is then used by FSP-S to render the splash
screen.
Additionally, increase the heap size (malloc'able size) upto 512KB
(when BMP_LOGO config is enabled) to accommodate high
resolution logo file.
BUG=b:284799726
TEST=Able to see pre-boot splash screen while booting google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3608bfacc21574e12cde0e2012a16e6388ce54df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch adds an API to convert BMP images into GOP BLT buffers for
Intel FSP-S. This is required to display the OEM splash screen at
pre-boot phase.
Previously, Intel FSP-S had provision to consume the *.BMP file as is.
However, starting with the Alder Lake platform, Intel FSP has dropped
this conversion logic and expects the boot firmware to pass the BLT
buffer directly.
This patch implements the conversion logic in coreboot.
BUG=b:284799726
TEST=Able to build and boot google/rex
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I992b45d65374f09498ff0cab497f7091e1e7a350
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch adds BMP image header and BLT header macros in
`efi_datatype.h` to implement a converter inside coreboot FSP 2.0
driver that converts any input *.BMP image into the BLT buffer.
The output BLT buffer is used by FSP-S to render any pre-boot display.
Added `Bmp.h` and `GraphicsOutput.h` files for `UDK base >= 2017`,
as these files were added with the UDK version 2017.
Note: BLT in UEFI BMP implementation stands for `Bit-block transfer`.
It is a method of copying graphis data (specifically images and fonts)
from one location to another (framebuffer), where the data is stored
in blocks of bits.
BUG=b:284799726
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4e282d135007d288aadb5996a662524f76428874
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76920
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Intel requires that all enabled PCIe PCH ports have a CLK_REQ signal
connected. The CLK_REQ is used to wake the silicon when link entered
L1 link-state. L1 link-state is also entered on PCI-PM D3, even with
ASPM L1 disabled. When no CLK_REQ signal is used, for example when
it's using a free running clock the silicon will never wake from L1
link state. This will trigger a MCE.
Starting with FSP MR4 the UPD 'PchPcieClockGating' allows to work
around this issue by disabling ClockGating. Disabling ClockGating
should be avoided as the silicon draws more power when it is idle.
TEST: Verified on two boards, one with missing CLK_REQ on a PCH
root port, that the code does the right decision to disable
UPD PchPcieClockGating and PchPciePowerGating when necessary.
Change-Id: I673bbdbadc9afbed6a7bd5ce9f35dc70716d875b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76687
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Split the signed AMDFW binaries into their own section and enable PSP
verstage.
BUG=b:284984667
TEST=Build Myst BIOS image with PSP Verstage. Boot to OS successfully
with PSP verstage and a separate section for signed AMDFW binaries.
Change-Id: Ie0a54c157ebdebf9a0c95933c96865e0782a0f90
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
With reference to the Picasso PPR 55570 Rev 3.18, LegacyIoEn bit is 0 on
reset and setting it will enable the decoding of the following legacy IO
ports:
0x20, 0x21, 0xA0, 0xA1 (PIC);
0x40, 0x41, 0x42, 0x43, 0x61 (8254 timer);
0x70, 0x71, 0x72, 0x73 (RTC);
0x92.
Verstage does not use those legacy IO ports. Also newer SoCs like
Phoenix do not support Legacy I/O registers to access Power Management
registers and accessing them from PSP verstage causes a hang. Hence
enable legacy IO only on platforms that support it.
BUG=b::284984667
TEST=Build Myst BIOS image with PSP Verstage. Boot to OS successfully
with PSP verstage.
Change-Id: I5e74b4cd1fa7e942770976e5e2197ded47503660
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76692
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Merlin was the name for the open-source variant of the EC. It
ended up getting entirely rewritten to work with SDCC, and is
currently being used on starbook/adl. The source code isn't
available at the time of this commit due to some old ITE XLT
code being used.
Add the latest version of the code, replacing the old code, so
the boards can be migrated over.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ib8384fc9322058297e8219ac8e483ac37a70bd33
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Recent ChromeOS devices use Ti50 instead of Cr50. Therefore, some
strings or comments are not accurate anymore. When applicable, rename
Cr50 to GSC (Google security chip).
BUG=b:275544927
TEST=./util/abuild/abuild -x -t GOOGLE_TOMATO -a
BRANCH=none
Cq-Depend: chromium:4756700
Change-Id: Ie5b9267191a5588830ed99a8382ba1a01933028f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77100
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Updating from commit id 034907b2:
2023-06-03 08:10:11 +0000 - (vboot_reference: eliminate redundant call to write protect EC-RO)
to commit id 0c11187c:
2023-08-07 11:41:45 +0000 - (vboot_reference: Rename Cr50 to GSC when applicable)
This brings in 38 new commits:
0c11187c vboot_reference: Rename Cr50 to GSC when applicable
76c160e2 futility: updater: Support --unlock_me with --mode=output
48a12071 futility: Add `show` test for CBFS integration firmware
b419912f futility: Pull file names into ft_show_bios() subtypes
db56d9c5 futility: Clarify `name` and remove `data` argument of file type funcs
311f59e8 futility: Use -P for signing tests
854c71b9 tests: futility: Make test_show_contents easier to update
5f5a695e futility: Document machine parseable format guidelines
774c700f futility: Fix HWID digest footer output
8cc8b710 futility: Fix build with a single RW partition and CBFS verification
6d4b03e5 futility/cmd_read.c: Implement --split-path|-s switch
636d5b16 Correct a malloc() check in VbExStreamOpen()
def2f5af firmware/2lib: Switch to RO immediately if only one slot present
9c9931b4 futility/cmd_read.c: Optimise to limit SPI transaction
cb56129f checkpatch: Change max line length from 80 to 96
aa23241a tests: Fix run_vbutil_kernel_arg_tests.sh
d7c26f52 futility: Follow-up fixes to CL:4548417
56490778 futility: add machine friendly print option
23e750b8 tests: Remove duplicate test for vb2api_fail()
612d140b futility: updater: fix custom label devices using customization_id
69cbe7ee Revert "futility: Avoid unnecessary servo control command"
290b72d6 vbutil_kernel: Drop alignment check for EFI stub
5d582eb5 sign_android_image.sh: Preserve capabilities for EROFS as well
8c30aaab futility: Avoid unnecessary servo control command
58f8bb5c futility: Fix flash teardown issue
2d9f9cdb sign_official_build: add cloud-signing param
d0ceeee6 image_signing: sign_official_build: create a proper main() func
38cfb9b0 Revert "make_dev_ssd.sh: Add support for kdump"
2c43e4dd .clang-format: Change the ColumnLimit from 80 to 96
3107ce77 host/lib/flashrom_drv.c: Check chip len symmetrically across R/W ops
0549e3c1 2load_kernel: Change bootloader_address out-parameter to offset
979f61de Make sign_android_image.sh support EROFS image format as well.
bb5ccd7d lib/flashrom_drv.c: Pass regions as pointer + size.
249a3477 vbutil_kernel: Move kernel's EFI boot stub into bootloader section
c8998d5f host/lib: Use absolute path for flashrom
564d9274 futility/updater_utils.c: Drop flashrom cli producer
9bf3edf8 futility/updater.c: Clarify conditions of do_update
212643bd futility/updater.c: Use canonical defines
Change-Id: I0947f0f6670328b779d2a8ef240ca196ef615cec
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
The command "git branch -a | grep -q ${branch}" may not exit with 0 when
pipefail is set. "grep -q" exits immediately with exit code 0 as soon as
a match is found. However, at that point "git branch -a" may be still
writing to the pipe, leading to SIGPIPE. When pipefail is set,
PIPESTATUS 141 will be returned. Fix the problem by not using "grep -q".
Also fix the branch name in the generated commit subject.
Change-Id: Ic07efb5e2a4f3b7bbc6e76da9e026771bc685bdb
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77085
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The use of a separate _PRW is not necessary when the _CRS interrupt
already has the Wake flag set (as these all do). Additionally, Windows
does not allow the use of a gpioint for the _PRW source, which results
in an ACPI_BIOS_ERROR BSOD.
Since ChromeOS builds for CYAN devices use an older kernel and may not
make use of _CRS interrupt Wake flag, keep the _PRW around when
CONFIG_CHROMEOS is selected.
TEST=build/boot Win11 on google/{cyan,edgar}
Change-Id: I7d0883e4de9572a14c8bad0ac086370bd00eeb1a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76798
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The change does the following:
- adds PCH IDs for 700 series chipsets per the DOC# 619362 rev 2.2
- updates GPIO table for PCH-S per the DOC# 618659 rev 2.1
- enables dumping GPIOs for 700 series PCH
Change-Id: I4509ad714772ce90cdee5135227c02640acb6085
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
IT8784E is basically a IT8786E stripped from serial ports 3-6.
There are very few minor register differences in EC IO space and GPIO
LDN, which are covered by this patch.
Based on IT8784E-I Preliminary Specification V0.7.1 (non-public).
TEST=Dump SIO configuration on Protectli VP4670 (vault_cml).
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5de8aeaff9697b854281391083f77a1083d12fe6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Prior to commit d1c0f958d1 ("acpi: Call acpi_fill_ssdt() only for
enabled devices"), uart_inject_ssdt() was used to set the ACPI status
(_STA) for both enabled and disabled devices. The aforementioned commit
limited it to being called only on enabled devices, which left disabled
devices without any _STA method at all -- which the OS assumes means
that the device is present and enabled.
To fix this, create the _STA method in the UART asl code for each port,
and set the return value to a name variable (STAT) which defaults to
0 (not present/disabled). Then, have uart_inject_ssdt() set STAT to
present and enabled (0xF) for UARTs actually present on the board.
TEST=build/boot google/skyrim (frostflow), dump ACPI tables, and verify
that _STA returns 0xF only for UARTs enabled in devicetree.
Change-Id: Id89e74c3ea7f53280935898ee35311b7cf3b152a
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77092
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Kahlee selects AMD_SOC_CONSOLE_UART causing UART0 to be used as console,
so enable uart_0 in the devicetree to make sure that the UART will be
marked as enabled in the SSDT that will be generated with the next patch
applied. This also matches the other AMD SoC based Chromebooks.
Change-Id: Ibe18f87d8bf63603fb2eb87728395e45e9a9ef69
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77094
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Define the UARTs as MMIO devices in the chipset devicetrees. Drop ACPI
_STA in asl since now handled by common SSDT generator. Implement
wait_for_aoac_enabled() since required by SoC common code, and ensure
compiled during all stages necessary.
TEST=build/boot google/liara, verify console UART still functional.
Change-Id: Ibecafdfa189d9c63a29b63759c5b965d03719009
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77093
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens. This removes
non-present devices from the SSDT and relieves the OS of the burden of
probing.
TEST=build/boot Windows/linux on redrix?, verify touchscreen functional
in OS, dump ACPI and verify only i2c devices actually present on the
board have entries in the SSDT.
Change-Id: I0273014b2d164f67f503da7b968a09256bffb43c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74929
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For brya variants with a touchscreen, drive the enable GPIO high
starting in romstage while holding in reset, then disable the reset
GPIO in ramstage (done in the baseboard). This will allow coreboot
to detect the presence of i2c touchscreens during ACPI SSDT generation
(implemented in a subsequent commit).
BUG=b:121309055
TEST=tested with rest of patch train
Change-Id: I8e56ac4834ce69de18bef2d34f5c361a7fda1aab
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Before add_io_regions only reported one fixed IO range to the resource
allocator that covered the whole IO range from 0x0000 to 0xffff. Instead
read the data fabric IO space decode base and limit address register
pairs to get the actual IO port decoding from the data fabric registers.
This will also help with adding support for multiple PCI root domains to
the common data fabric domain code so that Genoa can use it. In that
case each PCI root domain will only decode a part of the whole IO port
range.
Beware that the data fabric IO base and limit fields can contain values
that correspond to IO port addresses far outside of the addressable IO
port range. In case of Picasso, the IO limit read from the only enabled
DF IO range register would be 0x1ffffff after converting the raw data to
an IO port address. To not give the resource allocator wrong constraints
make sure that the IO limit we report will be at maximum 0xffff.
TEST=On Mandolin (Picasso) and Birman (Phoenix) the full range of IO
port addresses still gets reported as a domain IO resource producer like
before the patch:
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I087d96f7bdaae0d7b53089f6abaf0500a4b064e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76960
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
To have both the PCI function number and the register offset into the
config space of that function of the data fabric device in the data
fabric register definitions, introduce and use the DF_REG_ID, DF_REG_FN
and DF_REG_REG macros. The DF_REG_ID macro is used for register
definitions where both the function number and the register offset are
specified, and the DF_REG_FN and DF_REG_REG macros are used to extract
the function number and the register offset from the register defines.
This will allow having one define for accessing an indexed group of
registers that are on different functions of the data fabric device.
TEST=MMIO resources read from the data fabric's MMIO decode registers
don't change on Mandolin and the ACPI CRAT table is also identical.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I63a284b26081c170a217b082b100c482f6158e7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76886
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Debug messages shown during IDE initialization are streamlined as
follows:
"Primary IDE interface" (and similar) are shortened to
"Primary interface".
We don't need to see "IDE" twice as messages are already prefixed.
Refactor "IDE: (Primary) IDE interface: (on)" into
"IDE: (Primary interface): (on)" to allow compiler to deduplicate
component strings, also used later in messages re UDMA/33.
This reduces uncompressed string size by 32 bytes and allows ramstage
to compress a wee bit better.
Change-Id: I16f5c2b3775c5a73b83d83817d7075e944089a12
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73331
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I don't get around to do proper full reviews of SIO patches since maybe
3 years, so I better remove myself from the maintainers list for that
part of the coreboot tree. If anyone else wants to take this over,
please go ahead. I can still help with some advice and general ideas in
that area, but even the "odd fixes" status that I downgraded the
maintenance status of that sub-tree to some time ago was a bit too
optimistic.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic56b710ffe68c6e407786d551cafac698e8bb61d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77063
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When wildcards are used in toplevel Makefile.inc it ends up appending
all items including regular files into subdirs-y which then are treated
as directories in "evaluate_subdirs" with "Makefile.inc" appended to
them. Check for a valid path (existing Makefiles.inc) before attempting
to process it.
Change-Id: I368b5b9a7ece3c675674fcb24303276a87c15668
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68800
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Fix ethernet MAC address configuration. Currently, coreboot would
use ethernet_mac0 for both ports when setting the system's MAC
address. Instead, set the right device_index for the second controller
to pick up ethernet_mac1.
BUG=b:294856127
TEST=boot device and observe two different MAC addresses on the ethernet
ports.
Change-Id: I5ff6d62d2f837a120f7095f9b9aed487e6c5aee4
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77044
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Without setting these GPIO bits, you /can/ power on your board after
powering it down again. This includes after cutting the power.
The only way to recover from this is to pull the CMOS battery and cut
the power for 15mins. Then make sure you don't do this GPIO trickery or
you end up with the same state of basically an unresponsive "dead"
mainboard. So flash the chip before you pull the battery.
One small workaround I found when you like to flash from the system, is
to press the power button with 1 second after you enable power to the
board. In this small timeframe, apparently the superio chip didn't
intialise/restore/gets set with the settings that make it never want to
power on again. The other workaround is to connect the appriopriate
pins on the ATX power connector to force power to the mainboard.
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: I4c9df200ba3ec5f315ad3d184588551d29fa68ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I19c029968584fedbb6749e66c7ea2f74a7d580f4
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Once platform code has filled in the (legacy) ACPI PM register
map, added function will fill in the extended entries in FADT.
TEST=samsung/lumpy and amd/mandolin FADT stays unchanged.
Change-Id: I90925fce35458cf5480bfefc7cdddebd41b42058
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The first platform samples came with IT8786E. The production units
switched to IT8784E in the final design.
Change the code to use IT8784E and reflect the proprietary firmware
configuration of the SIO chip.
TEST=Boot Ubuntu 22.04 on Protectli VP4670 (vault_cml) and dump the
configuration with superiotool and compare the configuration with
proprietary firmware.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5dc6669b592484e445c8c4bbe95d73f0a9f0392e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74175
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
IT8784E is basically a IT8786E stripped from serial ports 3-6.
The patch creates a chip directory for IT8784E used by
protectli/vault_cml platforms.
TEST=Boot Ubuntu 22.04 on Protectli VP4670 (vault_cml) and dump the
configuration with superiotool and compare the configuration with
proprietary firmware.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ibe01358611f3ce3f155ddb01a7d177a3ff75765e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Threatening or initiating legal action against the maintainers of our
infrastructure or projects (all projects hosted on our infrastructure)
is a huge stressor to those maintainers.
To underline that severity, such threats or action will lead to an
immediate ban from our infrastructure as agreed on the leadership
meeting of 2023-05-31.
There may be legitimate legal action to take in certain cases, and
it's always possible to unban people, but given the severity provide
warning that we'll opt for a "ban first, sort out later" approach.
Change-Id: Ifa865487dc81ed3797fe60e5cef737c57dd85fea
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75554
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Problem:
Me: $ util/abuild/abuild -t asus/p2b -b p2b-ls
abuild: No such target: asus/p2b, variant: p2b-ls
Cause: We identify boards and variants using path names in tree, so
I type in the test command above. abuild identifies all board variants
the Kconfig way, in all caps and all underscores.
Result: Expectation gap and abuild can't find anything where we expect
it to. All variants with a hyphen in their names are affected.
Fix: Add a substitution to replace hyphens with underscores.
Test: I get my abuild with the command above, even a variant-specific
test config works.
Change-Id: I10d5b471dac41c50a85c4a309ec561b02687bb9a
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41918
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Use ARM architectual timer by initializing frequency to 13 MHz. Since
system timer is the source of the architectual timer, we also call
`timer_prepare` in `init_timer`.
BUG=b:229800119
TEST=run `suite:faft_bios` to verify the firmware stability.
check timestamps by cbmem.
Cq-Depend: chromium:4747539
Change-Id: I8b1348044e4c92984510604b7f61611e13284d86
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76919
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All boards based on brya will have GFX devices to represent DRM
connectors in the kernel's /sys/class/drm/.
There should be no functional impact with or without this patch.
BUG=b:277629750
TEST=emerge-brya coreboot
Change-Id: I11afa9e8a1c8bf9f57bf6d195f07531182bd36f1
Signed-off-by: Won Chung <wonchung@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the device and soc directories that don't already have an
SPDX license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I89c05c7c1c39424de2e3547c10661c7e3f58b8f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the mainboard directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic451e68b1ad9ccdf34484dd98bd7fca7e177ef22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68982
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the drivers directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8442bc18ce228eca88a084660be84bcd1c5de928
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68980
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the cpu directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3033f2a9eebc75220f7666325857b3ddd60c8f75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68979
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Select ENABLE_TCSS_USB_DETECTION for non-ChromeOS builds, to enable
booting from TCSS USB-C ports.
TEST=build/boot google/banshee, verify able to boot from all USB ports
using edk2 payload.
Change-Id: I998cc4a40950f43b4c511ead93ccc02c56c8367c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76945
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Select ENABLE_TCSS_USB_DETECTION for non-ChromeOS builds, to enable
booting from TCSS USB-C ports.
TEST=build/boot google/drobit, verify able to boot from USB ports using
edk2 payload.
Change-Id: Ic6ab84dd5d1b980296eac043917d2cc7f14a5536
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Inspect all type-C USB ports, check if there is a USB device attached,
and if so, send the connection request to the PMC. This allows for any
attached USB2/USB3 devices to be used for booting by the payload.
Since this functionality is only needed by ChromeOS devices with TCSS
running upstream coreboot, introduce a new Kconfig to guard its use.
Boards needing it will select it in subsequent commits.
TEST=tested with rest of patch train
Change-Id: I69522dbcc8cae6bbf41659ae653107d0e031c812
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72909
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When lemp9 was converted to a variant in CB:64528, the Makefile was not
updated to handle the variant-specific `romstage.c`. This, as would be
expected, caused memory init errors and broke boot on CML-U boards.
Tested lemp9 boots to payload again.
Fixes: 5b7b04c938 ("mb/system76/cml-u: Convert lemp9 to a variant")
Change-Id: Ibc11d69a1662df653e6553421d67a9cd1b1d03e2
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
header="src/soc/amd/common/block/include/amdblocks/post_codes.h \
src/include/cpu/intel/post_codes.h \
src/soc/intel/common/block/include/intelblocks/post_codes.h"
array=`grep -r "#define POST_" $header | \
tr '\t' ' ' | cut -d ":" -f 2 | cut -d " " -f 2`
for str in $array; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r $str src | cut -d ':' -f 1 | \
xargs sed -i'' -e "s/$str/POSTCODE_$splitstr/g"
done
Change-Id: Id2ca654126fc5b96e6b40d222bb636bbf39ab7ad
Signed-off-by: Yuchen He <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76044
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
_DSD "StorageD3Enable" property is needs to be set under the root
port in the DSDT or SSDT. The ACPI _DSD method is the preferred way
to opt D3hot support for storage devices.
This also bypasses the low LTR from SSD that blocking S0i2.2
LTR/latency SoC requirement.
Name (_DSD, Package () {
ToUUID("5025030F-842F-4AB4-A561-99A5189762D0"),
Package () {
Package (2) {"StorageD3Enable", 1},
// 1 - Enable; 0 - Disable
}
}
)
BUG=b:289028958
TEST=Check code compiles & boot rex, and verify the "StorageD3Enable"
SSDT entry.
Change-Id: I19decc2706954e73bc28fc2d9c3c4d18d2c384b7
Signed-off-by: Kangheui Won <khwon@chromium.org>
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76835
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch configures external V1p05/Vnn/VnnSx rails for Craaskov
to follow best practices for power savings – untested though.
* Enable the external V1p05, Vnn, VnnSx rails in S0i1, S0i2, S0i3, S3,
S4, S5 , S0 states.
* Set the supported voltage states.
* Set the voltage for v1p05 and vnn.
* Set the ICC max for v1p05 and vnn.
BUG=b:290165011
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: Ibaf6a285788e26688d3d42691ab40052ef6d6cdb
Signed-off-by: Rex Chou <rex_chou@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76926
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This feature was originally present and then dropped, but turns out
that users prefer it. Set the backlight to 50% in romstage, back to
zero in ramstage; skip enabling on the S3 resume path.
TEST=build/boot google/eve, verify keyboard backlight turns on/off
as expected.
Change-Id: I33af888d614010538f69512bbd052ed2b83fcaa5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76803
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Move the jack detect GpioInt resources under the codec (where they
belong), but also leave a copy under LPEA for since the Linux drivers
(incorrectly) require them there. Add pin list for Windows' SST driver.
Adapted from the Intel ValleyView edk2 ACPI reference code.
TEST=build/boot Win11, Linux on google/swanky; verify audio functional
OOTB under Linux, under Windows with coolstar's drivers.
Change-Id: I51c07013fc20f07d2fd3639f7fbc2af0e0e490a0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76795
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
The coreboot-jenkins-test docker image takes the coreboot-jenkins-node
docker image and runs a series of tests to verify that things build
properly.
This was original created to test the coreboot-sdk, but build functions
like the documentation have been moved from the sdk image into the
jenkins node, so the test needs to be renamed.
Add the makefile target to the help and phony target list at the same
time.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0e6282bbb163064f177c8e68e7180ba2bdc101f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The JPEG decoder, that was added many years ago to display a boot-
splash in coreboot, has a few quirks. People used to do some voodoo
with GIMP to convert images to the right format, but we can also
achieve the same with ImageMagick's `convert`. The currently known
constraints are:
* The framebuffer's color format is ignored,
* only YCC 4:2:0 color sampling is supported, and
* width and height have to be a multiple of 16 pixels.
Beside that, we can only display the bootsplash if it completely
fits into the framebuffer. As the latter's size is often decided
at runtime, we can't do much more than offering an option to set
a specific size.
Change-Id: I564e0d89fb46503ff4c11e095726616700009968
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76564
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
On mainboards using Phoenix SoC with PSP verstage enabled, to
accommodate growing number of PSP binaries, multiple smaller hash tables
are introduced. Also some hash tables are in V2 format identifying the
concerned PSP binaries using UUID. Add SVC calls to support multiple
hash tables with different versions.
BUG=b:277292697
TEST=Build and boot to OS in Myst with PSP verstage enabled. Ensure that
all the hash tables are injected successfully. Ensure that PSP validated
all the signed PSP binaries using the injected hash tables successfully.
Change-Id: I64e1b1af55cb95067403e89da4fb31bec704cd4f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76588
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently PSP verstage updates PSP bootloader with one unified hash
table containing hashes for all the signed PSP binaries to be validated.
With growing number of PSP binaries to validate and memory constraints
in PSP, there is a requirement to split and update the hash table into
multiple smaller chunks. Hence change the update_psp_fw_hash_table()
signature such that the hash tables are updated in a chipset specific
way.
BUG=b:277292697
TEST=Build and boot to OS in Myst with PSP verstage enabled. Build the
Skyrim BIOS image and confirm that the hash table is identical before
and after this change.
Change-Id: I75aac5bc5e7f61069be25d801d0838fdf565d3d1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76587
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some stages in bootflow prefer to use 16 bytes UUID instead of
traditional 2 bytes FWID to identify the firmware components they
verify/validate. Hence add version 2 of hash table which identifies
firmware components using UUID. Other than UUID and a reserved field for
alignment reasons, the format of the hash table is very similar to hash
table v1.
BUG=b:277292697
TEST=Build and boot to OS in Myst with PSP Verstage enabled. Ensure that
the hash table v2 is built and installed into BIOS image for the
components that are configured in amdfw.cfg file. Ensure that the
validation by PSP is successful for all the relevant components during
the boot flow.
Change-Id: I2899154086cf8e90c3327178157b07ead034b16e
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76586
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently this tool generates a hash table to verify signed binaries,
with a 2 byte FWID as the only kind of identifier. Going forward some
binaries are going to adopt 16 byte UUID identifiers and more binaries
will follow in the future SoCs. Hence add support for handling multiple
firmware identifier types. While at this remove the unused fwid from the
PSP FW table.
BUG=b:277292697
TEST=Build BIOS image and boot to OS in Myst & Skyrim.
Change-Id: I5180dc0fe812b174b1d40fea9f00a85d6ef00f2f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76585
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
As of OS/FW: 15276.0.0 - Skyrim is not able to wake from S1/standby.
The wake issue either needs to be fixed, or S1 should not be advertised
as a capability in the ACPI table.
Select ACPI_S1_NOT_SUPPORTED to indicate that ACPI state S1 is not
supported on Skyrim devices. This results in 'standby' being removed
from /sys/power/state.
BUG=b:263981434
TEST=suspend_stress_test
TEST=frostflow-rev2 ~ # cat /sys/power/state
freeze mem
Change-Id: I85fcdca34187a8c275cf5a93beb931dfb27a7c87
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
C1-state auto demotion feature allows hardware to determine C1-state
as per platform policy. Since platform sets performance policy to
balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter PC2 and lower
state in camera preview case and save platform power.
Note: C1 demotion heuristics used EPB parameter to balance between power
and performance, i.e. low threshold when EPB is low in-order to get C1
demotion faster and vice-versa. ChromeOS operates at default EPB=0x7
(low EPB) in both AC/DC, so in DC mode it gets more C1 demotion hits
than expected (similar to AC mode) and losing power respectively.
BUG=b:286328295
TEST=Code compiles and correct value of c1-state auto demotion is
passed to FSP. Also verified PC residency improvement ~10% in
camera preview case.
Change-Id: I548e0e5340dec537d05718dd2f4652e10fb36ac0
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Since all indirect data fabric register accesses will be non-broadcast
accesses that target a specific data fabric instance, the
cfg_inst_acc_en bit in the DF_FICAA_BIOS register will always be set
since that makes the indirect access target only a specific data fabric
instance.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9aff01750c2c1e3506141b3ed293a980a64f8fac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
FSP has a parameter to enable/disable c1-state autodemotion feature.
Boards/Baseboard can choose to use this feature as per requirement.
This patch hooks up this parameter to devicetree.
BUG=b:286328295
TEST=Check code compiles & boot google/rex, and correct value has been
passed to FSP.
Change-Id: I2cc60bd297271fcb3000c0298af71208e3be60fc
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76826
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
USB DBC is very helpful for SoC debug. TraceHub needs to be enabled in
coreboot if debug consent == 2 or 4. Debug consent == 6 enables USB DBC without TraceHub enabled.
This patch updates the Kconfig help text to meet PlatformDebugOption in
MTL and changes debug consent to 6 in default to provide basic SoC
debug capability.
TEST=Boot to OS on screebo and DBC connection is OK.
Change-Id: Ic12528bdd8b1feda7f1b65045c863341f932d3a2
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76880
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit 9a7a677 from opensbi project moved the fu540 platform to generic
code and commit 26998f3 from opensbi removed the old non generic
platform. Therefore opensbi platform needs to change to generic.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I76aa3d386936b331785a23edb8deb0d73609be47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76688
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
cse_prep_for_rw_update() should return CB_ERR when
cse_data_clear_request fails. It was modified to CB_SUCCESS in this
commit ad6d3128f8 ("soc/intel/common: Use enum cb_err values")
BRANCH=None
BUG=None
TEST=Verify the system goes to recovery during downgrade when
cse_data_clear_request() fails.
Change-Id: Ibbccb827765afa54e5ab1b386fa46093b803977a
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Enable config TME_KEY_REGENERATION_ON_WARM_BOOT for Intel Meteor
Lake SOCs. This config allows Intel FSP to programs TME engine to
generate a new key for each warm boot and exclude CBMEM region
from being encrypted by TME.
Bug=b:276120526
TEST= Boot up the system, generate kernel crash using following
commands:
$ echo 1 > /proc/sys/kernel/sysrq
$ echo "c" > /proc/sysrq-trigger
System performs warm boot automatically. Once it is booted,
execute following commands in linux console of the DUT and confirm
ramoops can be read.
$ cat /sys/fs/pstore/console-ramoops-0
S0ix also tested and found working.
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Change-Id: I3161ab99b83fb7765646be31978942f271ba1f9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
To support full 64-bit addresses, there is a new field `ext_lfb_base`
since Linux 4.1. It is unclear, however, how a loader is supposed to
know if the kernel is compatible with this. Filling these previously
reserved bits doesn't hurt, but an old kernel would probably ignore
them and not know that it's handling a clipped, invalid address. So
we play safe, and only allow 64-bit addresses for kernels after the
2.15 version bump of the boot protocol.
Change-Id: Ib20184cf207f092062a91ac3e6aa819b956efd33
Signed-off-by: Nico Huber <nico.h@gmx.de>
Co-authored-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76479
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Merge TME_KEY_REGENERATION_ON_WARM_BOOT and
TME_EXCLUDE_CBMEM_ENCRYPTION config options under new config option
named TME_KEY_REGENERATION_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.
If a new key is generated on warm boot, DRAM contents from previous
warm boot will not get decrypted. This creates issue in accessing
CBMEM region from previous warm boot. To mitigate the issue coreboot
also programs exclusion range. Intel TME does not encrypt physical
memory range set in exclusion range. Current coreboot implementation
programs TME to exclude CBMEM region. When this config option is
enabled, coreboot instructs Intel FSP to program TME to generate
a new key on every warm boot and also exclude CBMEM region from being
encrypted by TME.
BUG=b:276120526
TEST=Able to build rex.
Change-Id: I19d9504229adb1abff2ef394c4ca113c335099c2
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76879
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add more details to instruct future boards/models implementers regarding
how GFX devices should be added.
If HDMI and DP connectors are enumerated by the kernel in
/sys/class/drm/ then corresponding GFX device should be added to ACPI.
It is possible that some connectors do not have dedicated ports, but
still enumerated.
The order of GFX devices is DDIA -> DDIB -> TCPX.
BUG=b:277629750
TEST=emerge-brya coreboot
Change-Id: I59e82ee954a7d502e419046c1c2d7a20ea8a9224
Signed-off-by: Won Chung <wonchung@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76776
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Introduce new symbol SOC_INTEL_RAPTORLAKE_PCH_S that can be selected
by board with RPL-S PCH.
For now only the IoT variant of RPL-S FSP is available for use with
700 series chipsets. Boards with 600 series chipsets can still use
RPL CPUs with the ADL-S C.0.75.10, which contains minimal RPL-S CPU
support.
Change-Id: I303fac78dac1ed7ccc9d531a6c3c10262f7273ee
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Only the headers on Intel FSP repository have the CnviWifiCore
present. Options guarded for RPL like: DisableDynamicTccoldHandshake
or EnableFastVmode and IccLimit is also supported by all public FSPs
(except ADL-N for the handshake).
Options like LowerBasicMemTestSize and DisableSagvReorder have to be
guarded when FSP_USE_REPO is not selected, as publci FSPs do not have
these options.
Use FSP_USE_REPO instead of/in addition to SOC_INTEL_RAPTORLAKE
as dependency on the guarded UPDs to make them available for FSPs
that support them as well. Also prioritize the headers from FSP repo
over vendorcode headers if FSP_USE_REPO is selected.
Change-Id: Id5a2da463a74f4ac80dcb407a39fc45b0b6a10a8
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
If ACPI is above 4G it's not possible to have a valid RSDT pointer in
RSDP, therefore swap RSDT and XSDT. Both are always generated on x86.
On other architectures RSDT is often skipped, e.g. aarch64. On top of
that the OS looks at XSDT first. So unconditionally using XSDT and not
RSDT is fine.
This also deal with the ACPI pointer being above 4G. This currently
never happens with x86 platforms.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6588676186faa896b6076f871d7f8f633db21e70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This makes sure google/ovis don't get a random mac address on boot.
Additionally, program the LAN WAKE GPIO properly as per the Ovis
schematics dated July'23.
BUG=b:293905992
TEST=Verified on google/ovis that able to get the fixed MAC address across the power cycles.
Change-Id: I699e52e25f851de325f96ef885e04d15ca64badd
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76872
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
In the datasheet of ILI9882T [1] section 3.11 Power On/Off Sequence,
the TReset-CMD (Reset to First Command in Display Sleep In Mode) should
be larger than 10ms, but it's 1.1ms now. This may cause abnormal
display as some commands may be lost during power on. Fix this and
leave some margins by increasing TReset-CMD to 20ms. Also, to align
with the kernel driver structure starry_ili9882t_init_cmd, add 20ms
delay at the end of command.
[1] ILI9882T_Datasheet_20220428.pdf
BUG=b:293380212
TEST=Boot and display normally
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Ifdcaf0e34753fc906817c763f1c8e7389448d1dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76766
Reviewed-by: cong yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The EFS_OFFSET is the relative address to flash base. We can not
assume the flash size is 16M.
The change will affect only Gardenia and Pademelon whose flash size
are 8M.
Change-Id: Ia68032db05264c55d333deec588ad9690a4ed2c1
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76764
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PSP_ADDR_MSR is programmed into the BSP by FSP, but not always
propagated to the other cores/APs. Add a hook to run a function
which will read the MSR value from the BSP, and program it into the
APs, guarded by a Kconfig. SoCs which wish to utilize this feature
can select the Kconfig.
BUG=b:293571109
BRANCH=skyrim
TEST=tested with rest of patch train
Change-Id: I14af1a092965254979df404d8d7d9a28a15b44b8
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This patch chooses to show the early splash screen which is an
OEM feature. The current implementation is relying on the Intel
FSP GFX PEIM to perform the display initialization.
Having this feature allows the platform to show the user notification
with 500ms since boot compared to traditional scenarios where first
user notification is coming from kernel (typically ~3sec+ after cpu
reset). Eventually this feature will help to improve the user
experience while booting Intel SoC platform based chromeos devices.
BUG=b:284799726
TEST=Able to see the early splash screen on google/rex.
Change-Id: I399ddb6618e774302200e8a87629647ba070d080
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76361
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While FSP programs the VmxEnable UPD per CONFIG_ENABLE_VMX, it doesn't
set the lock bit, which prevents Windows from enabling virtualization
on devices which support it. Call set_vmx_and_lock() to ensure the
lock bit is properly set.
TEST=build/boot Win11 on google/ampton,reef; verify virtualization
enabled.
Change-Id: I54ea0adb0a6d10f2df18f604b1f1e5a7a145dfb3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76804
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Typically we set SaOcSupport to allow overclocking RAM, but addw2 saw a
high rate of errors when using the provided 3200 MHz DIMMs. Disable OC
so modules run at the standard 2933 MHz.
Change-Id: I469b9c73d2e6bfa0b3c9175bcc87584aeaa95f75
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67837
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the default branch used for MrChromebox's edk2 fork from 2023-04
to 2023-06. This updated branch has been rebased on the latest upstream
stable tag (edk2-stable202305), and fixes issues booting on AMD Zen
platforms (Picasso and newer).
TEST=build/boot google boards link, panther, lulu,reef, ampton, akemi,
banshee, zork, frostflow with edk2 payload selected.
Change-Id: I4867d453514f2b00f66ffdad50e091e5b80afdcb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76806
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This matches the change done for DDR4 in commit 8509c25eec
("soc/intel/alderlake: Allow channel 0 for memory-down").
Fixes detection of the on-board RAM (Samsung M425R1GB4BB0-CQKOD) on the
System76 Lemur Pro 12 (Clevo L140AU). The Clevo L140*U are the only
boards in the tree using mixed memory topology.
Change-Id: I395f898472a9a8f857fd6b0564b95c787b96080b
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75285
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Set the ACPI SSID using Google's project campfire ID for EVE, to allow
coolstar's Windows drivers to identify the device (since it uses a
generic ACPI _HID). Custom drivers are necessary under Windows since
the touchpad firmware is not fully I2C-HID compliant.
TEST=build/boot Win11 on google/eve, verify touchpad fully functional.
Change-Id: I3b8d56ff01d4cca7ba5c02f1aaab1a7049607dbc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
The EAPD pin needs to be enabled and set in order for the headphone
jack to work properly. It's already done for the speaker in the
beep verbs, but needs to be done for the HP jack as well in order
for output to work properly under Windows.
TEST=build/boot Win11 on LINK, verify headphone output functional
when headphones plugged in.
Change-Id: I411d7317aefc1154635c4c17ca0dc1e37c9f40f4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76746
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id c161772f4:
2023-06-08 15:47:09 +0200 - (Merge "refactor(el3-spmc): add emad_advance()" into integration)
to commit id 37366af8d:
2023-07-28 17:04:54 +0200 - (Merge "fix(cpus): fix minor issue seen with a9 cpu" into integration)
This brings in 287 new commits.
Change-Id: Ic364a54154a7b4c5757f9d8abafe2047159ea3ba
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The non-PCI resources added to the domain device are resource consumers,
so they mustn't be reported as resource producers. To make sure that
this is the case, skip all resources that have the IORESOURCE_RESERVE
flag set in amd_pci_domain_fill_ssdt.
Commit 7a5dd781d1 ("soc/amd/common/data_fabric/domain: provide
amd_pci_domain_fill_ssdt") that introduced amd_pci_domain_fill_ssdt
already contained the bug, but since no MMIO range consumers were added
back then, the bug only became visible when commit 32169720bb
("soc/amd/common/data_fabric/domain: report non-PCI MMIO resources")
added the reserved non-PCI MMIO resources to the domain device's
resources resulting in MMIO producer objects being generated for MMIO
consumers. Those producers that should have been consumers then
overlapped with the actual MMIO resource producers which caused Windows
to BSOD with an ACPI_BIOS_ERROR.
TEST=The non-PCI MMIO resources are no longer added as resource
producers and Windows boots again on google/frostflow.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: Matt DeVillier <matt.devillier@gmail.com>
Change-Id: Ib099675bc5bea93bf7c2a80f741bef067fd37a58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76818
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
When iterating over the resource list in amd_pci_domain_fill_ssdt, don't
return when a resource is unassigned, but just continue to the next loop
iteration so the resulting SSDT will be complete and not broken due to
a missing resource template footer and the scope not being closed.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I39fe516f27a6d971fb9c57a1e64ead79d23aff08
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I80b4b2df4a38dcbb28d928018446e91acae90ee6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I3d716b29d8e28584a0c9e4056d4c93dca2873114
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76780
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: If31cbc5ae184c4eb66011666c1bb655fa16afba0
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: Ia1d597c0e3e86db8c13829e58a8a27d9de1480b4
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76788
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I52b5a83e7e484889bfef5a4e45a0279fadd58890
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I495605190b2c6cd11c7f78727ab4611e10b4d9d3
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I53ffa4b35d35d4f8b0170377041b258d4bd2eeeb
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76777
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: Iea63e7ce165b1c8129725136e39bff45765023e6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I688bef264ff41b2a9755133698880fa397f652d4
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76755
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce new parsing rules for ux_locales.c:ux_locales_get_text():
* Add a version byte: PRERAM_LOCALES_VERSION_BYTE in the beginning. This
provides more flexibility if we want to change the format of
preram_locales region.
* Add a new delimiter 0x01 between two string_names. This could fix the
issue that 'string_name' and 'localized_string' might be the same.
Also fix two bugs:
1. We would search for the language ID exceeding the range of current
string_name.
2. In 'move_next()', we would exceed the 'size' due to the unconditional
increase of offset.
Finally, make some minor improvements to some existing comments.
BUG=b:264666392, b:289995591
BRANCH=brya
TEST=emerge-brya coreboot chromeos-bootimage
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: Ic0916a0badd7071fa2c43ee9cfc76ca5e79dbf8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Change the SSID to allow the correct Creative Labs Windows audio drivers
to attach (vs generic HDA audio ones) and provide full functionality.
Linux doesn't care about the SSID, so changing it has no effect there.
TEST=build/boot Windows, Linux on google/link, verify the correct
audio drivers attach under Windows, no regressions under Linux.
Change-Id: Ib5e523b07583289b0222ef156245fb0771ad1f1c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76745
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add new memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
1) LP5 Memory - 2GB Micron MT62F512M32D2DR-031 WT:B
2) LP5 Memory - 2GB Hynix H9JCNNNBK3MLYR-N6E
3) LP5 Memory - 4GB Samsung K3LKBKB0BM-MGCP
4) LP5 Memory - 4GB Hynix H9JCNNNCP3MLYR-N6E
DRAM Part Name ID to assign
MT62F512M32D2DR-031 WT:B 0 (0000)
H9JCNNNBK3MLYR-N6E 0 (0000)
K3LKBKB0BM-MGCP 1 (0001)
H9JCNNNCP3MLYR-N6E 2 (0010)
BUG=b:292461498
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: I02e49d60e43c4fed8356556ec194d726c30cd609
Signed-off-by: Rex Chou <rex_chou@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
Set the cs_pi_start_high_in_ect if the DUT is using one of the two
following Hynix parts: H54G56CYRBX247 and H54G46CYRBX267. Failure to
set cs_pi_start_high_in_ect when using these parts will result in an
MRC cache failure and DUT will fail to boot.
BUG=b:292153199
TEST=`emerge-brya coreboot chromeos-bootimage`, flash and boot brya
variant to kernel.
Change-Id: I36040139b959c85c3ac220a34574caa12ca6c5fe
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
With currently set default PSP_SOFTFUSE_BITS for phoenix SoC,
the non-serial build does not boot on Myst.
Override PSP_SOFTFUSE_BITS by disabling SPIConfig to also get
the non-serial build booting.
The documentation of PSP_SOFTFUSE_BITS is available in #55758 doc (NDA).
BUG=b:292489356
TEST=Flash image-myst.bin, verify that it's able to boot on Myst
proto0.
Change-Id: Id4472fd85fdefcafb8378199dbaa054fab8b3274
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76713
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Necessary to allow coolstar's Windows touchpad driver for this board,
since the touchpad is attached to the SMBus. The VID/DID combo used is
not registered/doesn't conflict with any currently in use, and would
be difficult to change at this point since the Windows drivers have
already been signed.
TEST=build/boot Win11, Linux on butterfly/lumpy/parrot, verify
touchpad driver works properly.
Change-Id: Ica3756e117fc58166958f37e7b007abb79d9d350
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76744
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Necessary to allow coolstar's Windows touchpad driver for this board,
since the touchpad is attached to the SMBus. The VID/DID combo used is
not registered/doesn't conflict with any currently in use, and would
be difficult to change at this point since the Windows drivers have
already been signed.
TEST=build/boot Win11, Linux on butterfly/lumpy/parrot, verify
touchpad driver works properly.
Change-Id: Ie1d882cac90211541a636d2dab297c343a12d66d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76743
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Necessary to allow coolstar's Windows touchpad driver for this board,
since the touchpad is attached to the SMBus. The VID/DID combo used is
not registered/doesn't conflict with any currently in use, and would
be difficult to change at this point since the Windows drivers have
already been signed.
TEST=build/boot Win11, Linux on butterfly/lumpy/parrot, verify
touchpad driver works properly.
Change-Id: I61912fd6db9eb4b8d202ab633b8c7ca5913e759f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
After switching to S3, it was found that drives on the SATA port do not
exit D3cold on S3 exit. Disable RTD3 on the port until the issue can be
resolved.
Avoids the following error in Linux:
pcieport 0000:00:1d.0: Unable to change power state from D3cold to D0, device inaccessible
Tested on darp8 with a Samsung 970 EVO or Crucial P5 in J_SSD1.
Change-Id: Ib26f59db61acfbf9248cea379c197765d3d9c470
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76593
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit e33d253793 ("soc/amd/common/block/acpi/ivrs: fix
missing IOAPIC[1] error").
Now that the per PCI root domain IOAPIC MMIO resource is reported on the
domain device, we can again probe the resource on the domain device
instead of the northbridge PCI device in that domain. This will make the
IVRS code compatible again with the work in progress Genoa SoC support.
TEST=Linux doesn't complain about the IOAPIC[1] missing in the IVRS on
Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib861b19d798fc8ee6603e8803d8d1939be08d275
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76659
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Call read_non_pci_resources from amd_pci_domain_read_resources to tell
the resource allocator about the non-PCI MMIO regions within the data
fabric MMIO regions so that the allocator won't place any PCI MMIO in
the same areas.
TEST=On Mandolin 3 new non-PCI resources get reported to the allocator:
avoid_fixed_resources: DOMAIN: 0000 04 base fd100000 limit fd1fffff mem (fixed)
avoid_fixed_resources: DOMAIN: 0000 05 base fd000000 limit fd0fffff mem (fixed)
avoid_fixed_resources: DOMAIN: 0000 20000120 base fec01000 limit fec01fff mem (fixed)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7f69b86e376e3368d4f156ccf93791cc00886489
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76599
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Introduce the common read_non_pci_resources function to read the base
address of the non-PCI resources within the MMIO regions configured in
the data fabric registers and pass that info to the resource allocator.
Each SoC will need to provide implementations for get_iohc_misc_smn_base
and get_iohc_non_pci_mmio_regs in order for read_non_pci_resources to
know the SoC-specific base addresses, register offsets and MMIO region
sizes. In case of SoCs with only one PCI root domain, the domain
parameter of get_iohc_misc_smn_base will be unused, but in the case of
SoCs with more than one PCI root domains, this parameter will be used by
the SoC-specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If9aca67fa0f5a0d504371367aaae5908bcb17dd9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The SuperIO is not used so don't enable decoding of 0xE2 and
drop all code using it. It's not even required for the virtual
UART on 0x3f8 to work.
Add the virtual UART on 0x3f8 as ACPI device.
TEST: Verified on SBP1 that serial still works.
Change-Id: I8e431a0c8417435cc6e3ba16f97ff080e1656a7b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add pujjo new supported memory parts in mem_parts_used.txt, generate
SPD id for this part.
1. Hynix H58G56BK7BX068
2. Samsung K3KL6L60GM-MGCT, K3KL8L80CM-MGCT
3. Micron MT62F1G32D2DS-026 WT:B
BUG=b:292452868
TEST=Use part_id_gen to generate related settings
Signed-off-by: Leo Chou <leo.chou@lcfc.corp-partner.google.com>
Change-Id: Ia123a1cfd93a5e08ab0ba65f1d9be240d60ff356
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76672
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From ccache(1):
mtime
Hash the compiler’s mtime and size, which is fast. This is the default.
Hashing the compiler binary's content would only be necessary when we
expect different binaries of the same size with the same path (e.g.
during a compiler bootstrap) and wrong modification timestamps (might
happen when checking an older version out of a (package) repository).
Neither should be the case during our builds. And even if everything
fails at once, chances are additionally low that a wrong cache hit
would cause a problem.
tl;dr we're building and testing firmware, not toolchains.
Change-Id: I264a72c628559384fcc2060d777c52af927d5e14
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
There were some issues with the current Linuxboot Makefiles.
- multithreaded compilation didn't work, because some prerequisites
were missing
- initramfs wasn't added for x86 qemu boot.
- riscv support was incomplete
It began with separate patches, but resulted in a clean up patch, that
is hard to separate. The most important changes are the following:
- Instead of phony targets, actual files are now used as prerequisites
- riscv can now be used as target
- initramfs works now also for x86
- instead of querying the most recent version from the internet, I set a
known working version (because I tested it) that can be customized
and/or upgraded in the future. The reasons:
- querying the version from the internet requires a constant
connection to the internet even after linux kernel is already
build (aka subsequent builds).
- one usually wants to use a known working version, but optionally
still have the posibillity to choose a custom one. This patch
introduces this possibility in its most simple form.
- I removed as much ifeq statements as possible and moved that
responsibility to Kconfig, because they tend to make the
Makefile less readable.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I25e757108e0dd473969fe5a192ad0733f1fe6286
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76150
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch increases the `tcc_offset` to reduce the TCC
(Thermal Control Circuit) activation temperature to avoid running
into abrupt power off during power cycle tests.
On Intel processors, the core frequency can be by an HW agent when
the current temperature reaches the TCC activation temperature.
The default TCC activation temperature is specified by MSR_IA32_TEMPERATURE_TARGET (which is 90°C for google/rex variants).
However, this patch adjusted the TCC by specifying an offset in
degrees C (i.e., using `tcc_offset` from variant override device tree).
Note: The bigger the TCC offset is, the lower the effective TCC activation temperature would be, to ensure that processors can be throttled earlier before the system critical overheats.
BUG=b:283008762
TEST=Able to perform power cycle on google/screebo w/o any crash/shutdown.
Change-Id: Ib19703877dbbfc26b2d9f538dda4f10c27cf872d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76658
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Hook the PchHdaSdiEnable UPD so that mainboard can change the
settings via devicetree. PchHdaSdiEnable UPD enable HDA SDI lanes.
BUG=b:268546941
TEST=Verified the settings on google/brya using debug FSP logs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I82bbfa5442936aefa53f8826e395b7ce75c895a3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Adding EC_HOST_EVENT_PANIC to SCI mask allows the EC to interrupt the
Kernel when an EC panic occurs. If system safe mode is also enabled
on the EC, the kernel will have a short period to extract and save info
about the EC panic.
BUG=b:290985698
BRANCH=firmware-volteer-13672.B
TEST=Observe kernel ec panic handler run when ec panics
Change-Id: I87173f93d0e47baa816d15dad0777007342b4fdb
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch creates a new variant rex4es. The new variant will support ESx samples. The existing rex variant will support the QS samples.
BUG=b:290732344
TEST=Able to build google/rex4es board and boot on target hardware.
Change-Id: I25dd1f42ee812f47289da0c2ef7aa79d6f340d48
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch creates a rex model so that other variants developed using
`rex` baseboard are easy to land without duplicating the config
selection.
So far, `rex0` and `rex_ec_ish` are developed using the `rex` model.
The plan is to extend the support for `rex4es` and `rex4es_ec_ish`
variants.
TEST=Able to build and boot google/rex.
Change-Id: Id4e8d1162da93b7266ee1108f870e89b6d884ab9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76608
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
acpi.c contains architectural specific things like IOAPIC, legacy IRQ,
DMAR, HPET, ... all which require the presence of architectural headers.
Instead of littering the code with #if ENV_X86 move the functions to
different compilation units.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5083b26c0d4cc6764b4e3cb0ff586797cae7e3af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
With arm64 -Wstack-usage= is enabled which is triggered on any use of
alloca(). Since this function basically works on x86 without wrecking
things and causing massive stack consumption it's unlikely to cause
problems on arm64.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5d445d151db5e6cc7b6e13bf74ce81007d819f1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76007
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
AGESA S3 restore needs to occur before SMM finalization/locking,
but it's a crapshoot as to which runs first since both use the same
BS_OS_RESUME/BS_ON_ENTRY boot state callback, and there's no way
to prioritize/force ordering.
To work around this, move the AGESA S3 resume call to the preceding
boot state (BS_OS_RESUME_CHECK) to ensure it runs first, and guard it
to ensure it only runs on the S3 resume path.
BUG=none
TEST=build/boot google/liara, verify S3 resume successful.
Change-Id: I765db140c6708a0b129f79fb7d3dc8a4ab3095bd
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76592
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This supports a brand new I2C driver that is designed specifically
for the Pixel 2013 chromebook (LINK). The GMBus interface on the IGPU
is an i2c-compatible interface, but AFAIK only Link has touch devices
attached in this way.
On Windows, the PCIe device for the IGP is owned by the Intel
proprietary driver, hence a separate ACPI device has to be added for
the I2C driver arbitrator to attach to. The MMIO method is used instead
of _CRS so that Windows does not try to assign ownership of the
resource to our device (even though we're using the MMIO registers at
the same time as the IGP driver).
Even though in theory 2 drivers accessing the same MMIO may cause
problems, in testing, there has been no issues with
sleep/wake/hibernate, updating/installing/uninstalling the IGP driver,
or changing display resolutions with the i2c driver attached.
The arbitrator is necessary as well, since even though there are
multiple i2c buses, the MMIO registers are shared. Hence a shared lock
is required for i2c access across the buses.
The original Sleep Button devices are preserved for Linux due to the
completely custom and non-standard implementation of the Windows driver
in order to work around the non-standard nature of Link's hardware.
Change-Id: If7ee05d15bc17d335cf8c1a8e80bea62800de475
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76159
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
From the Linux documentation (Documentation/PCI/acpi-info.rst):
[6] PCI Firmware 3.2, sec 4.1.2:
If the operating system does not natively comprehend reserving the
MMCFG region, the MMCFG region must be reserved by firmware. The
address range reported in the MCFG table or by _CBA method (see Section
4.1.3) must be reserved by declaring a motherboard resource. For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
the resources in this case should not be claimed in the root PCI bus’s
_CRS. The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.
So in order for the OS to use ECAM MMCONF over legacy PCI IO
configuration, a PNP0C02 HID device needs to reserve this region.
As no AMD platform has this defined in DSDT this fixes Linux using
legacy PCI IO configuration over MMCONF. Tianocore messes with e820
table in such a way that it prevents Linux from using PCIe ECAM. This
change fixes that problem.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I852e393726a1b086cf582f4d2d707e7cde05cbf4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75729
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is a problem of screen shake on the old panel[1]. So increase the
panel GOP component pull-down circuit size in hardware, and update the
initialization code at the same time. The new initialization code is
mainly adjusted for GOP timing. When Display sleep in, raise all GOP
signals to VGHO and then drop to GND. In order to be consistent with
the current panel model, let's rename this file.
[1]: INX old panel product number is HJ110IZ-01A-B1, and the new
panel product number is HJ110IZ-01A-B2. We have recalled the shipment
old panel.
BUG=b:270276344
BRANCH=trogdor
TEST= test firmware display pass
Change-Id: I2b2534afee1ed700c39d3c360aafd685b63ccbfb
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch updates the Type-C USB2/3 port mapping to reflect the mux
connection change as mentioned in previous patch
commit ee3f796200 (mb/google/rex/var/ovis: Fix mux
change as per schematics).
Here is the correct port mapping after considering the mux swap:
+--------------------------------+-------------+---------------+
| TCSS-USB Mapping | Port C0 | Port C1 | Port C2 |
+------------------+-------------+-------------+---------------+
| USB2-Port | 2 | 3 | 1 |
| USB3-Port | 0 | 2 | 1 |
+------------------+-------------+-------------+---------------+
BUG=b:289300284
TEST=Able to build and boot google/ovis to get display over Type-C1
and Type-C2 port.
Change-Id: I460004842dd8fcdc03fca6639d03e422259380ca
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76464
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Patch to increase CONSOLE_CBMEM_BUFFER_SIZE to contain FSP debug serial log.
The existing implementation uses larger cbmem size irrespective of FSP debug is enabled or
not. Ideally. larger cbmem size is required only if FSP debug is enabled.
Bug=b:284124701
TEST=Able to build and boot google/marasov.
Change-Id: I9a9e660f2738813808e0dd65d2783424b49f9a5e
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reduces the CAR (Cache-as-RAM) variable usage while using FSP debug binaries, which can prevent the CAR from becoming too full and unable
to integrate other CAR global variables.
This change has the following downsides:
- FSP debug output into the cbmem buffer will be partial.
To test this change, you can:
Build and boot google/rex without any function impact with non-serial
and serial FSP debug image (unless what has been documented here).
Bug=b:284124701
TEST=Able to build and boot google/rex.
Change-Id: I16a1aa25fd32327d03a37381a696c86c95014ba0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
According to Intel doc#763797 to overcome early command training hang
issue, the CsPiStartHighinEct needs to be enabled for hynix memory.
BUG=b:281643325
BRANCH=firmware-brya-14505.B
TEST=Built and booted into OS.
Change-Id: I95702e675fa3b73c7e8ee0c8625c7828d8129ea8
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76355
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit provides option for board to set CsPiStartHighinEct
FSP UPD using a new cs_pi_start_high_in_ect mb_cfg field.
BUG=b:279835630
BRANCH=none
TEST=CsPiStartHighinEct UPD is set properly
Change-Id: I7d0d5f3c782e29fb047ea421e1a5fdfc30bcc26d
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Disable the CSME by default now that S3 is used instead of S0ix.
The CSME will not go into a low power state during S0ix when it is
disabled. This prevents the CPU from reaching C10 and so increases the
power usage during suspend compared to leaving CSME enabled. (This was
measured to be a ~2W different on TGL-U.) In S3, the state of the CSME
doesn't matter because the CPU will be off.
Change-Id: I88c0aebdcc977f3ba9dd8f46a6abfaa7a4ae8eb6
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73354
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
After fixing TPM logs clobbering other regions in CB:73297, S3 no longer
causes cache issues resulting in power off after multiple suspends.
This is required for disabling Intel CSME by default.
Change-Id: I7eef4c883fd65db93dae81adabd895b2de90496a
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73353
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
The preram TPM log was being copied to the end of the CBMEM TPM log no
matter what the size of the CBMEM TPM log was. Eventually, it would
overwrite anything else in CBMEM beyond the TPM log.
This can currently be reproduced by enabling TPM_MEASURED_BOOT and
performing multiple S3 suspends, as coreboot is incorrectly performing
TPM measurements on S3 resume.
Change-Id: If76299e68eb5ed2ed20c947be35cea46c51fcdec
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73297
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The original default, minimum abbreviated hash length was 7. It dif-
fers on newer systems, however. This breaks reproducibility, so set
an explicit length. 12 hex digits should be good enough.
Note: This sets only a minimum. With a high enough number of commit
objects in the repository, Git could still decide to use a longer
hash, again breaking reproducibility. 12 digits will hopefully pro-
vide enough margin.
Change-Id: Ia86e9cc41e27a0a57d498dcb13aec954c4ea0f04
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The current Sapphire Rapids code assumes that all sockets have working
CPUs. On multi-socket platforms a CPU might be missing or was disabled
due to an error. The variable PlatformData.numofIIO and the variable
SystemStatus.numCpus reflect the working CPUs, but not the actual
socket count.
Update the code to iterate over sockets until PlatformData.numofIIO
IIOs have been found. This is required as FSP doesn't sort IIOs by
working/non working status.
This resolves invalid ACPI table generation and it fixes a crash
as commands were sent to a disabled CPU.
TEST: Disabled Socket1 on IBM/SBP1.
Change-Id: I237b6392764bbdb3b96013f577a10a4394ba9c6e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76559
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a function to check if the CPU placed at the specified socket was
found usable during QPI init. This is useful for multi-socket
platforms were a CPU is missing or has been disabled due to an error.
Change-Id: I135968fcc905928b9bc6511e3ddbd7d12bad0096
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use the FSP define to iterate over all sockets as the runtime value of
numofIIO is the detected number of sockets, not the highest working
socket.
This fixes printing the HOB on multi-socket platforms where a CPU has
been removed or has been disabled (4S system running as 3S).
Change-Id: Ieed67cd48d26c7634636c0aae6a56f3b6fbdf640
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76492
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On Intel Meteor Lake (MTL), PCIe CLK control register is accessed by
P2SB on IOE/SOC die.
So this patch does:
1. Enable PCIE_CLOCK_CONTROL_THROUGH_P2SB
2. Include pcie_clk.asl
3. Set the correct IOE_DIE_CLOCK_START for MTL-U/H.
BUG=b:288976547, b:289461604
TEST=Test on google/screebo and found the pcie clock is on/off properly
and sdcard PCIe port doesn't block S0ix with RTD3 cold enabled.
Change-Id: I6788ae766f36c9a0d4910fda1d6700f20ce73ea8
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76356
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the older platform such as Raptor Lake (RPL), Tiger Lake (TGL), it
needs PMC IPC cmd to turn on/off the corresponding clock.
Now on Meteor Lake (MTL), it control pcie clock registers on P2SB on
IOE or SoC die.
BUG=b:288976547, b:289461604
TEST=Test on google/screebo and found the pcie clock is on/off properly
and sdcard pcie port doesn't block S0ix with RTD3 cold enabled.
Change-Id: Ia729444b561daafc2dca0ed86c797eb98ce1f165
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76347
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch creates a helper library to migrate all the common P2SB
access routines. The PCH P2SB ACPI implementation will now rely on the
common library to perform PCR read/write operations. This will make the
code more modular and easier to maintain.
The helper library provides a single interface for accessing P2SB
registers. This makes it easier to port the code to different platforms,
for example: adding support for PS2B belongs to the IOE die for
Meteor Lake SoC generation.
BUG=b:290856936
TEST=Able to build and boot google/rex.
Change-Id: I0b2e7ea416ca7082f68d0b822ebb9a87025b4a8b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76408
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the JPEG decoder, use `bytes_per_line` instead of `width` for
address calculations, to allow for bigger framebuffers. When
calling jpeg_decode(), add an offset to the framebuffer address
so the picture gets centered.
Change-Id: I0174bdccfaad425e708a5fa50bcb28a1b98a23f7
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
In all SoC pm_set_power_failure_state gets called either after a call to
enable_acpimmio_decode_pm04() or the ACPIMMIO mapping is already enabled
after reset on the SoC. This allows to use pm_read8 and pm_write8 that
use the ACPIMMIO mapping of the PM registers instead of pm_io_read8 and
pm_io_write8 which won't work on Phoenix and Glinda due to the IO ports
used on older generations to access to the PM registers not being
implemented any more.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0d0523d2c4920da41b3fb73cf62f22a60f1643a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76463
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
rv32iafc-ilp32 is compatible with rv32iac-ilp32 for library
implementation, so add a reuse rule allowing the default configuration
to support rv32iafc.
-IAFC is an unusual configuration (much less common than -IMAFC),
but multilib reuse has essentially no cost: this change is useful to
users of platforms that support hardware floating-point but cannot
use hardware multiply/divide for any reason. To avoid generating a
new set of libraries this is limited to the soft-float ABI.
Tested by verifying that `gcc -march=rv32iafc -mabi=ilp32
--print-search-dirs` refers to the rv32iac/ilp32 library directory
as expected, rather than just the root library directory as occurs
when an unsupported target is selected (for instance, rv32id).
Change-Id: Ie056ba6488a138fe0876eebf7cbc59477b3c3518
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
In all SoC lpc_early_init gets called either after a call to
enable_acpimmio_decode_pm04() or the ACPIMMIO mapping is already enabled
after reset on the SoC. This allows to use pm_read8 and pm_write8 that
use the ACPIMMIO mapping of the PM registers to set the PM_LPC_ENABLE
bit in the PM_LPC_GATING register instead of pm_io_read8 and
pm_io_write8 which won't work on Phoenix and Glinda due to the IO ports
used on older generations to access to the PM registers not being
implemented any more.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8b31ec4e03a06796502c89e3c2cfaac2d41b0ed9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76461
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The enable_acpimmio_decode_pm04 function uses the IO port based indirect
access of the PM register space. The PM_INDEX and PM_DATA registers
don't exist any more on Glinda, so the code shouldn't access those.
Since the PM_04_ACPIMMIO_DECODE_EN bit in the
ACPIMMIO_DECODE_REGISTER_04 register is 1 after reset, the ACPIMMIO
space is still accessible.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic6bc0479ea4ea2b9fe3629a6e15940b31b2864d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The enable_acpimmio_decode_pm04 function uses the IO port based indirect
access of the PM register space. The PM_INDEX and PM_DATA registers
don't exist any more on Phoenix, so the code shouldn't access those.
Since the PM_04_ACPIMMIO_DECODE_EN bit in the
ACPIMMIO_DECODE_REGISTER_04 register is 1 after reset, the ACPIMMIO
space is still accessible.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia41f239b023edc094f5cbae63ed7c079649c74da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76437
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch disables early EC sync to avoid an idle delay (~3sec)
without a provision to notify the user about some critical task
in progress.
Doing EC sync at later stage allows us to notify using graphical msg
on screen to make user aware of the WIP task.
BUG=b:279944831
TEST=Able to perform EC sync from depthcharge on google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I03ed40827c50e75ceaaf94e30d675014ebf22dac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74837
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add support for AP initiated mode entry. The code flow has been
optimized as below -
Code flow when AP initiated mode entry is disabled:
+-------+
| Start |
+---+---+
|
|
+---------+---------+
|wait_for_connection|
| Is DP ALT mode |
| available? |
+---------+---------+
|
+--------------->-------+
Yes| No |
+---------+---------+ |
|Skip enter_dp_mode | |
+---------+---------+ |
| |
| |
+-----------+----------+ |
|wait_for_dp_mode_entry| |
| Is DP flag set? | |
+-----------+----------+ |
| |
+--------------->--------
Yes| No |
+-----------+----------+ |
| wait_for_hpd | |
| Is HPD_LVL flag set? | |
+-----------+----------+ |
| |
+--------------->--------
Yes| No |
+-----------+----------+ |
| Rest of the code | |
+-----------+----------+ |
| |
+---------------<-------+
|
+---+---+
| End |
+-------+
Code flow when AP initiated mode entry is enabled:
+-------+
| Start |
+---+---+
|
+------------+-----------+
|Skip wait_for_connection|
+------------+-----------+
|
+--------+-------+
| enter_dp_mode |
| Is USB device? |
+--------+-------+
|
+--------------->-------+
Yes| No |
+---------+---------+ |
| enter_dp_mode | |
| Send DP mode | |
| entry command | |
+---------+---------+ |
| |
+-----------+----------+ |
|wait_for_dp_mode_entry| |
| Is DP flag set? | |
| (If not, loop wait | |
| until timed out) | |
+-----------+----------+ |
| |
+--------------->--------
Yes| No |
+-----------+----------+ |
| wait_for_hpd | |
| Is HPD_LVL flag set? | |
| (If not, loop wait | |
| until timed out) | |
+-----------+----------+ |
| |
+--------------->--------
Yes| No |
+-----------+----------+ |
| Rest of the code | |
+-----------+----------+ |
| |
+---------------<-------+
|
+---+---+
| End |
+-------+
BUG=b:247670186
TEST=Verify display over TCSS and its impact on boot time for
google/rex
Time taken by enter_dp_mode / wait_for_dp+hpd / MultiPhaseSiInit
functions with this patch train:
1. When AP Mode entry is enabled
- With type-c display on C1 and SuzyQ on C0: 6.9ms / 420ms / 616ms
- With USB key on C1 and SuzyQ on C0 : 6.0ms / 505ms / 666ms
- Without any device on C1 and SuzyQ on C0 : 3.7ms / 0ms / 178ms
2. When AP Mode entry is disabled
- With type-c display on C1 and SuzyQ on C0: 1.7ms / 2.5ms / 213ms
- With USB key on C1 and SuzyQ on C0 : 0.9ms / 3.3ms / 177ms
- Without any device on C1 and SuzyQ on C0 : 0.8ms / 1.8ms / 165ms
Without this patch train, wait_for_hpd would cause a constant delay of
WAIT_FOR_HPD_TIMEOUT_MS (i.e. 3 seconds) per type-c port when there is
no device connected.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I514ccbdbaf905c49585dc00746d047554d7c7a58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Because of the way that the CBFS filename is generated from the contents
of the microcode patch, if a duplicate microcode patch is included in
the build, the makefile would create a second copy of the name, which
doesn't work. This led to "odd" results where the other attributes of
the first copy were erased, causing cbfstool to fail. The cause of the
failure is not immediately obvious, and is a little difficult to track
down.
This patch causes an immediate failure and gives a reason as to the
cause of the issue.
When a failure is seen, this is the result:
File1: 3rdparty/amd_blobs/phoenix/psp/TypeId0x66_UcodePatch_PHXn4_A0.bin
File2: 3rdparty/amd_blobs/phoenix/psp/TypeId0x66_UcodePatch_PHX4_A0.bin
src/soc/amd/common/block/cpu/Makefile.inc:25: *** Error: The cbfs
filename "cpu_microcode_a740.bin" is used for both above files. Check
your microcode patches for duplicates.. Stop.
TEST=Now checked for both positive and negative failures.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3d34dc5585182545bdcbfa6370ebc34aa767cae2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76423
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is a data abort in ABL when the memory training data is used from
APOB Cache. Disable APOB Cache until the cause is identified. The
downside of this change is that the memory training happens in every
boot cycle.
BUG=b:290763369
TEST=Build BIOS image and boot to OS in Myst. Trigger a reboot from AP
console and ensure that the system boots to OS.
Change-Id: I20f4f40cdaac68bca6e121e3a238d13fe80d0d3c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The OxPCIe952 serial cards currently fails after entering
postcar, since the state of oxpcie_present is not maintained
from previous stage.
As a quick work-around test the expected UART register space
to see if anyone decodes the address.
Change-Id: I5601034be6e413616fb3433c894fb008a3e02138
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74597
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot logs the error below, since the value of hporch is too small. Increasing hbl from 80 to 174, and hso from 40 to 72 to revise the HBP(Horizontal Back Porch) and HFP(Horizontal Front Porch). After revising this, the actual measurement frame rate is 60.1Hz.
[ERROR]HFP plus HBP is not greater than d_phy, the panel may not work
properly.
BUG=b:284812193
TEST=cbmem -c | grep "ERROR" and measure frame rate
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I7de5984ce8aec12d8ebe292974e05776835330d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76218
Reviewed-by: cong yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some of the error messages of checkpatch.pl contain "*". Since now
Gerrit supports markdown, messages with "*" will be rendered
incorrectly. For example,
foo* bar should be foo *bar
will be shown as
foo bar should be foo bar
with "bar should be foo" being in italics. Fix the problem by
surrounding the output message with "`" to make it verbatim.
Change-Id: I02d0e894adf7f94a9e154f99321f51d4097963a5
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76392
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
This patch updates the MemInfoHob header file as per Meteor Lake
version 3251.81.
Changes include:
1. Drop DimmDFE structure variable
2. Drop unused macro MAX_COPY_DIMM_DFE_TAPS
BUG=b:290898626
TEST=Able to build and boot google/rex.
w/o this patch:
cbmem -c -1 | grep DIMM
[ERROR] No DIMMs found
w/ this patch:
cbmem -c -1 | grep DIMM
[DEBUG] 8 DIMMs found
Change-Id: I8eed410831399bb4835244f48c14d5ed9e701e68
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76433
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCR (Private Configuration Register) is applicable to access the
P2SB register space starting with the Intel SkyLake generation of SoC.
Prior to Intel Meteor Lake SoC generation, the only P2SB existed inside
the PCH die. Starting with Meteor Lake SoC, there are two P2SB, one in
SoC die (same as PCH die for U/H SoC) and another in IOE die.
This patch renames pcr.asl to pch_pcr.asl to reflect the actual source
of the P2SB IP in the die (i.e., SoC die or PCH die).
BUG=b:290856936
TEST=Able to build and boot google/rex.
Change-Id: Idb66293eaab01e1d4bcd4e9482157575fb0adf04
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76407
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
GMBus is an I2C compatible link on Intel IGPUs. Most non-Linux OS's
don't support accessing this ordinarily, so a custom driver is
needed with a bit of ACPI hackery. Reserve 2 IDs from the
coreboot namespace so that the 2 devices required can be populated
in Windows device manager
Change-Id: I389612441e96ce2fc5e006051e523661953eba6e
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
With the latest hardware revision, the polarity of GPP_B5 has been
changed. For a full-populated DRAM configuration, the input signal is
now connected to 3.3 V and for a half-populated configuration it is
connected to ground.
BUG=none
TEST=Use different populated mainboards and check coreboot log
GPP_B5 = 0:
[INFO ] meminit_channels: DRAM half-populated
[DEBUG] 1 DIMMs found
GPP_B5 = 1:
[DEBUG] 2 DIMMs found
Change-Id: Iaa3a63fa52c802d8f5d8c6cc11dd6edfac117e88
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76434
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In newer ADL/RPL PCH EDS 619362 revision 2.1 the ESPI ID 0x7A8A
belongs to the W790 chipset. Earlier revisions had the chipset with
ID 0x7A8A named W685, which was probably just a temporary name.
Change the naming throughout the tree to W790, which is the real
existing chipset.
Change-Id: I87603298d655e9bf898b34acdd5b403f5affaee3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
CPUID is the same for Alder Lake and Raptor Lake S and HX variants.
To reduce the confusion and concerns how to name the macros, remove
the suffixes from macros and platform reporting strings. Thankfully
the stepping names are unique across mobile (P suffixed) and desktop
(S and HX suffixed) SKUs. Distinguishing the S from HX is possible via
host bridge PCI ID.
Change-Id: Ib08fb0923481541dd6f358cf60da44d90bd75ae2
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Add PCI IDs, default VR values and power limits for Raptor Lake S
CPUs. Based on docs 639116 and 640555.
TEST=Tested on a MSI PRO Z690-A (ms7d25) with i9-13900K with Ubuntu
22.10 and LinuxBoot (Linux + u-root). Also tested on MSI PRO Z790-P
with i5-13600K (UEFI Payload) usign RPL-S IoT FSP and Ubuntu 22.04.
Change-Id: I767dd08a169a6af59188d9ecd73520b916f69155
Signed-off-by: Max Fritz <antischmock@googlemail.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69798
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Some of the microcode update files listed in the Makefile are redundant:
* 06-97-02 is exactly the same as 06-97-05
* 06-9a-03 is completely contained in 06-9a-04 (at offset 0x1c400)
So drop these files. This saves us about 200KiB CBFS space in each case.
Change-Id: Idfcab1de26ea4712295c1d22790bab3a73c17f93
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76381
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch drops the unnecessary alignment of 64 bytes that was
introduced when implementing the split Intel microcode packing logic
into CBFS.
- The 16-byte alignment that is already used for Intel microcode is
sufficient.
- Removes unnecessary alignment check of 64 bytes against an AMD
platform specific config.
TEST=Able to build and boot google/rex without any functional
impact.
Change-Id: Icc44e9511e321592de7ab8d1346103d0a9951c9b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76397
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The commit 4d8da8ed ("Docs: Update sphinx targets with the build directory")
introduces an additional variable intending to allow an user to specify
a different build directory. Since the variable is not writable from the
outside and also the Docker container used to build doc.coreboot.org
calls the Makefile with `BUILDDIR` instead of `SPHINXDIR`, building the
documentation within the container doesn't work anymore.
Thus, change the variable name to `BUILDDIR` and make it writable.
Steps to reproduce:
cd util/docker
make doc.coreboot.org
make docker-build-docs
Change-Id: Ibc44134cf1996592597252aeb9dcf7ffb3378ee3
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
During the ACPI dump of the System Resource Affinity Table (SRAT), it
was noticed that the reserved field within the Memory Affinity structure
contained a non-zero value. This commit addresses the issue by
performing a memset to zero on the reserved field, ensuring the
avoidance of any potential problems arising from garbage values.
TEST= Build for ibm/sbp1 & make sure SRAT Memory Affinity entries
reserved fields read zeroes
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I4ba697a6bd59054e74c84b98f3d9b517d333a5d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75417
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This configures GPIO IO Standby State of GPP_F00 - GPP_F05 as masked
for CNVi.
Meteor Lake rex platform does not wake up from low power state by
bluetooth keyboard and mouse properly. It is identified that IO Standby
State needs to be configured as masked to function properly for CNVi.
BUG=None
TEST=Make rex platform suspend to s0ix state and press a key from
bluetooth keyboard. Check the platform wakes up properly from s0ix.
Change-Id: Ia98abde584699fa01acba47a9df4ef6332ac16fd
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76338
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The actual NVM size of camera module is 64KB; however, only 8KB is in
use to store data. This reduces the size of both NVM0 and NVM1 to 8KB
to minimize the time taken to read NVM and launch Camera preview.
BUG=NONE
TEST=Launch Chrome camera application and check the time taken to
read eeprom from camera service log and show camera preview. It takes
2 to 3 seconds to show camera preview while it takes 4 to 5 seconds
without the changes.
Before the changes:
06:21:04.204944Z OpenDevice(): camera_id = 1
06:21:07.297584Z Read camera eeprom from eeprom
06:21:08.763491Z Read camera eeprom from nvmem
After the changes:
21:37:23.923676Z OpenDevice(): camera_id = 1
21:37:24.386020Z Read camera eeprom from eeprom
21:37:24.574515Z Read camera eeprom from nvmem
Change-Id: I0e2272b3307fea60ea7406fc6899ae2cb0134fa3
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76189
Reviewed-by: Kiran2 Kumar <kiran2.kumar@intel.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch skips reading the MEM_CH_SEL GPIO aka GPP_E13 to determine
the memory channel configuration. The signal behavior is not proper,
hence limiting the DIMM capacity to half (only MC0 is enabled).
This patch always reports the full memory capacity as in dual channel
(both MC0 and MC1 enabled).
This change is necessary to ensure that the system reports the correct
memory capacity, even if the MEM_CH_SEL GPIO is not working properly.
BUG=b:290174538
TEST=Able to detect 32GB memory capacity while booting google/ovis.
Without this patch:
localhost ~ # cat /proc/meminfo
MemTotal: 16183080 kB
With this patch:
localhost ~ # cat /proc/meminfo
MemTotal: 32673664 kB
Change-Id: I6c3fa941abb044b79b13785f7b65d09957f0487d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76359
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The AW37503 is designed to supply positive/negative supply for driving
the MIPI panel. It doesn't integrate non-volatile memory(EEPROM), so we
need to program the registers at boot. We program the target
positive/negative output voltage via I2C and enable the power rails by
pulling up ENP and ENN pins.
On Starmie, we need +/-6V power supply for the MIPI panel. We program
the AW37503 registers in coreboot so that kernel can control AW37503
via fixed regulators without additional settings(what we did for
TPS65132). Since we distinguish AW37503 and TPS65132 by reading the
vendor ID, we need to initialize I2C bus as early as possible.
Therefore, we move mtk_i2c_bus_init() to mainboard_init().
BUG=b:289482828
TEST=emerge-staryu coreboot chromeos-bootimage
TEST=Test the sequence the voltage
Change-Id: I9ccd4db19c93a032226f006eab0427f78f7b6dc8
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76219
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: cong yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The BT VGPIOs pad config in variant of gpio.c won't be overwritten on board eventually because no matched gpios existed here.
Put BT VGPIOs in gpio_table, ensure that these were able to be overwritten.
The fix included crota and omnigul BT offload work successfully.
BUG=b:264834572
TEST=test Bluetooth offload playback/capture in SCO profile.
Change-Id: I62cecf26abd0411f7cbb0a56b8b8f0a25d370c69
Signed-off-by: Mac Chiang <mac.chiang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
In VBOOT_STARTS_IN_ROMSTAGE=y case, vboot_run_logic() did not
get called when postcar was loaded from TSEG stage cache on
ACPI S3 resume path. Resume failed as MP init attempts to
access microcode update from unverified FW_MAIN_A/B section.
In a similar fashion, for POSTCAR=n, loading ramstage from
TSEG stage cache would bypass the call to vboot_run_logic().
TEST=samsung/lumpy with VBOOT_STARTS_IN_ROMSTAGE=y is able
to complete S3 resume.
Change-Id: I77fe86d5fd89d22b5ef6f43e65a85a4ccd3259d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch fixes the boot hang due to commit 053a45bcdb ("cpu/x86/lapic: Fix X2APIC_ONLY regression") on platform which selects X2APIC_LATE_WORKAROUND config.
[EMERG] Switching from X2APIC to XAPIC mode is not implemented.
Without this patch: Boot gets stuck inside at BS_WRITE_TABLES when enable_lapic() gets called after X2APIC mode has been enabled. The fix is to change enable_lapic() to track when late enablement for X2APIC mode happens with X2APIC_LATE_WORKAROUND.
TEST=Able to build and boot google/rex to chromeos.
Change-Id: I41e72380e9cfb59721d0df607ad875d7b6546974
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76384
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current design of the `ucode-<variant>.bin` file combines all
possible microcode per cpuid into a unified blob. This model increases
the microcode loading time from RW CBFS due to higher CBFS verification
time (the bigger the CBFS binary the longer the verification takes).
This patch creates a provision to pack individual microcodes (per CPUID)
into the CBFS (RO and RWs). Implementation logic introduces
CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config which relies on converting
Intel CPU microcode INC file into the binary file as per format
specified as in `cpu_microcode_$(CPUID).bin`.
For example: Intel CPU microcode `m506e3.inc` to convert into
`cpu_microcode_506e3.bin` binary file for coreboot to integrate if
CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config is enabled.
Another config named CPU_INTEL_UCODE_SPLIT_BINARIES is used to specify
the directory name (including path) that holds the split microcode
binary files per CPUID for each coreboot variants.
For example: if google/kunimitsu had built with Intel SkyLake processor
with CPUID `506e3` and `506e4` then CPU_INTEL_UCODE_SPLIT_BINARIES
refers to the directory path that holds the split microcode binary
files aka cpu_microcode_506e3.bin and cpu_microcode_506e4.bin.
Refer to the file representation below:
|---3rdparty
| |--- blobs
| | |--- mainboard
| | | |--- google
| | | | |--- kunimitsu
| | | | | |--- microcode_inputs
| | | | | | |--- kunimitsu
| | | | | | | |--- cpu_microcode_506e3.bin
| | | | | | | |--- cpu_microcode_506e4.bin
Users of this config option requires to manually place the microcode
binary files per CPUIDs as per the given format
(`cpu_microcode_$(CPUID).bin`) in a directory. Finally specify the
microcode binary directory path using CPU_UCODE_SPLIT_BINARIES config.
Additionally, modified the `find_cbfs_microcode()` logic to search
microcode from CBFS by CPUID. This change will improve the microcode
verification time from the CBFS, and will make it easier to update
individual microcodes.
BUG=b:242473942
TEST=emerge-rex sys-firmware/mtl-ucode-firmware-private
coreboot-private-files-baseboard-rex coreboot
Able to optimize ~10ms of boot time while loading microcode using
below configuration.
CONFIG_CPU_MICROCODE_CBFS_SPLIT_BINS=y
CONFIG_CPU_UCODE_SPLIT_BINARIES="3rdparty/blobs/mainboard/
$(CONFIG_MAINBOARD_DIR)/microcode_inputs"
Without this patch:
10:start of ramstage 1,005,139 (44)
971:loading FSP-S 1,026,619 (21,479)
> RO/RW-A/RW-B CBFS contains unified cpu_microcode_blob.bin
Name Offset Type Size Comp
...
cpu_microcode_blob.bin 0x1f740 microcode 273408 none
intel_fit 0x623c0 intel_fit 80 none
...
...
bootblock 0x3ee200 bootblock 32192 none
With this patch:
10:start of ramstage 997,495 (43)
971:loading FSP-S 1,010,148 (12,653)
> RO/RW-A/B CBFS that stores split microcode files per CPUID
FMAP REGION: FW_MAIN_A
Name Offset Type Size Comp
fallback/romstage 0x0 stage 127632 none
cpu_microcode_a06a1.bin 0x1f340 microcode 137216 none
cpu_microcode_a06a2.bin 0x40bc0 microcode 136192 none
...
...
ecrw 0x181280 raw 327680 none
fallback/payload 0x1d1300 simple elf 127443 none
At reset, able to load the correct microcode using FIT table (RO CBFS)
[NOTE ] coreboot-coreboot-unknown.9999.3ad3153 Sat May 20 12:29:19
UTC 2023 x86_32 bootblock starting (log level: 8)...
[DEBUG] CPU: Genuine Intel(R) 0000
[DEBUG] CPU: ID a06a1, MeteorLake A0, ucode: 00000016
Able to find `cpu_microcode_a06a1.bin` on google/rex with ES1 CPU
stepping (w/ CPUID 0xA06A1) (from RW CBFS)
localhost ~ # cbmem -c -1 | grep microcode
[DEBUG] microcode: sig=0xa06a1 pf=0x80 revision=0x16
[INFO ] CBFS: Found 'cpu_microcode_a06a1.bin' @0x407c0 size 0x21800 in
mcache @0x75c0d0e0
[INFO ] microcode: Update skipped, already up-to-date
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic7db73335ffa25399869cfb0d59129ee118f1012
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch changes the default behaviour of the MICROCODE_UPDATE_PRE_RAM
config for the platform with FIT (CPU_INTEL_FIRMWARE_INTERFACE_TABLE)
enabled. If FIT is enabled then microcode update will be taken care of
by FIT at pre-cpu reset hence, microcode update at pre-ram phase can be
skipped.
BUG=b:242473942
TEST=Able to build and boot google/rex with MICROCODE_UPDATE_PRE_RAM
remains disabled. No functional impact.
Without this patch:
CONFIG_MICROCODE_UPDATE_PRE_RAM=y
With this patch:
CONFIG_MICROCODE_UPDATE_PRE_RAM is not set
Change-Id: I603e064115869aba2bffa5589ffe47a44a90b848
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Commit cde4f3b279 ("acpi/gnvs.c: Drop unused pointer to the cbmem
console") removed writing the coreboot memory console pointer to the
GNVS and kept the CBMC field as reserved. Since those fields aren't
needed any more and there are no dependencies on the absolute position
of the different fields in GNVS as long as both GNVS definitions on the
C and the ASL side match, remove the deprecated and unused CBMC field
from the GNVS structs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iadfaf5a4ec1401b027dbfb6a7c6ce74a1dcecdfa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76351
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The function ux_locales_get_text() should expect to have a correct
preram_locales region to read, hence we need to adjust the log levels
inside lib/ux_locales.c:ux_locales_get_text():
* If the region does not exist or is not in a correct format, we should
print in BIOS_ERR
* If the arguments are not correct but we have a good workaround (e.g.
the lang_id from vboot API seems weird), we should print in
BIOS_WARNING.
Also change some minor syntax issues.
BUG=b:264666392, b:289995591
BRANCH=brya
TEST=emerge-brya coreboot chromeos-bootimage
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: Ic8a8856c883f6ca78fed69542a7d388f57c5c508
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76316
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Fix below build error after DISPLAY_UPD_DATA is selected:
src/soc/intel/xeon_sp/spr/upd_display.c:131:29: error: variable 'old' set but not used [-Werror=unused-but-set-variable]
131 | const FSP_S_CONFIG *old;
| ^~~
src/soc/intel/xeon_sp/spr/upd_display.c:130:29: error: variable 'new' set but not used [-Werror=unused-but-set-variable]
130 | const FSP_S_CONFIG *new;
Change-Id: I43ed5fadab58e0d4dc824457c7a1bdf48511198e
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76342
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove BUILD_TIME_STAMP_SIZE macro from coreboot because FSP 3223
version have BUILD_TIME_STAMP_SIZE macro defined as part of
`FspProducerDataHeader.h`.
Ref change:
9c28ab1d1a vc/intel/fsp/mtl: Update header files from 3194_81 to 3223.80
BUG=b:285110116
TEST=Able to build google/rex.
Change-Id: I52707adf1aa6dadca8dcf82102f76916a0cfe346
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Add a new apcb edit tool, apcb_v3a_edit.py, that injects SPDs into
an APCB for phoenix platform.
The tool makes several assumptions:
* Each SPD only uses blocks 0, 1, 3 and 5. All other blocks are zero.
* Each block is 64 bytes.
* Dimm and socket are always 0
* Unused SPD entries are zero'd
BUG=b:281983434
BRANCH=None
TEST=build, flash, boot myst
Change-Id: Ifb50287de77138170714a702ab87d56427aacfef
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76188
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Always exit 4-byte addressing mode to prevent errors when the spi flash
is not left in 4-byte addressing mode.
TEST=boot with PSP releases that leave the flash in both 4-byte
and 3-byte mode and verify flash writes
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9884b85bc3b0a9b654a2cb91fb314b0869abd622
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76094
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPIO GPP_B5 is used as input on this mainboard. For a full-populated
DRAM configuration, the input signal is connected to ground and for a
half-populated configuration it is connected to 3.3 V.
BUG=none
TEST=Use different HW configurations and check coreboot log
GPP_B5 = 0:
[DEBUG] 2 DIMMs found
GPP_B5 = 1:
[INFO ] meminit_channels: DRAM half-populated
[DEBUG] 1 DIMMs found
Change-Id: I48b4a3bea7f1ff804b78b7c648a7ea1925627b8a
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76245
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
There can be mainboard variants, which are only equipped with
half-populated DRAM. For this reason, the meminit parameter for
populatation should be adjustable. The default setting remains at
full-populated DRAM. At mainboard variant level a different selection
via individual input paths can be made.
Change-Id: I390bbfa680b5505bb2230fa0740720bd9dd1fafb
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76244
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
At the time of writing SMM runtime does not make register
accesses to LAPIC registers, but such breakage has been
reported.
S3 resume failure, where OS switched back from X2APIC
to XAPIC mode, can be reproduced with a sandybridge SKU
that has VT-d disabled.
Change-Id: I300ba87c3d8fde548dbaf95703bd7e2fe54cff57
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Some ancient CPUs may have had LAPIC disabled at power-up, so
semantically enable_lapic() should always come before attempting
to access the register banks.
With X2APIC_ONLY option it is necessary to ensure enable_lapic()
is called prior to any other lapic register space accesses,
since the XAPIC mode MMIO accessors are optimised away build-time
and CPU's do not yet initialise for X2APIC mode at reset.
Change-Id: I96eaa5c43108c802375e184e0c68b5091ca0198f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76195
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Updating from commit id 8be5a82:
2022-10-04 14:01:00 +0000 - (Fix "unnecessary with of ancestor [-gnatwr]")
to commit id 95ad8c5:
2022-12-22 15:32:38 +0000 - (hw-debug: Place global variables in the .bss section)
This brings in 1 new commits:
95ad8c5 hw-debug: Place global variables in the .bss section
Change-Id: Ib28dbcdf14f313cbfeab03e98e05fffe16a1b708
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75794
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Updating some submodule pointers to their latest commit causes some
builds with default configuration to fail since all required components
don't fit into 2MB anymore. Specifically, this has been experienced with
the microcode and FSP submodules.
So, increase the default CBFS size to 4MB to make sure builds succeed
with updated submodules.
Change-Id: I2fc16240bef36c057608acadf3cb7c65e7f0d244
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76217
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
VP2420 (vault_ehl) has only 1 DIMM slot present. Set the DIMM_MAX to 1
to optimize the common libraries to not attempt to read and parse more
SPD than needed.
TEST=Boot Protectli VP2420 (vault_ehl) with different DIMMs and see
FSP is retraining the memory properly and fastboot is working.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I29a99f387ffe2df1060547e0818c5c5b66a27061
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73819
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CBMEM can contain log in different forms (at most one is present):
- coreboot-specific format (CBMEM_ID_TPM_CB_LOG exported as
LB_TAG_TPM_CB_LOG)
- TPM1.2 format (CBMEM_ID_TCPA_TCG_LOG)
- TPM2 format (CBMEM_ID_TPM2_TCG_LOG)
The last two follow specifications by Trusted Computing Group, but until
now cbmem couldn't print them. These formats were added not so long ago
in:
- commit 4191dbf0c9 ("security/tpm: add TPM log format as per 1.2
spec")
- commit 53db677586 ("security/tpm: add TPM log format as per 2.0
spec")
These changes make cbmem utility check for existence of TPM1.2/TPM2 logs
in CBMEM and add code necessary for parsing and printing of their
entries.
TEST=`cbmem -L` for CONFIG_TPM1=y case
TCPA log:
Specification: 1.21
Platform class: PC Client
TCPA log entry 1:
PCR: 2
Event type: Action
Digest: 5622416ea417186aa1ac32b32c527ac09009fb5e
Event data: FMAP: FMAP
TEST=`cbmem -L` for CONFIG_TPM2=y case
TPM2 log:
Specification: 2.00
Platform class: PC Client
TPM2 log entry 1:
PCR: 2
Event type: Action
Digests:
SHA256: 68d27f08cb261463a6d004524333ac5db1a3c2166721785a6061327b6538657c
Event data: FMAP: FMAP
Change-Id: Ib76dc7dec56dd1789a219539a1ac05a958f47a5c
Ticket: https://ticket.coreboot.org/issues/425
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68749
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables BT offload feature for soundwire audio over SSP1.
BT mode is selected via FW_CONFIG and corresponding VGPIOs are
programmed.
BUG=b:275538390
TEST=build and verify BT offload on rex soundwire audio
Change-Id: I99df78787d9f54c91bcedf6f70352890a715cdb3
Signed-off-by: Uday M Bhat <uday.m.bhat@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75924
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Always send the Exit 4-Byte Address Mode (E9h) command before the first
access to the SPI flash in all stages when the SPI flash is
memory-mapped. This is useful for x86 mainboards that do not access SPI
flash in bootblock yet still need to exit 4-byte addressing mode in
romstage or ramstage.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I3a62bfa44a0a5645c1bb80b32d0b9f92075c66bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Replace `CBFS_SIZE` with FMD files to declare regions and sizes. This
will be used to lock BIOS region (except SMMSTORE) on boot.
`CBFS_SIZE` was incorrectly set to 10 MiB, so this also corrects the
BIOS region size to match the FIT values.
Change-Id: I0f068f4d9b376f12b46faa5bb0c6a08e6cb744d8
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76155
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Multiple users have requested to have the DMI values for product UUID
and serial number be populated. Enable the drivers so that we may set
them when flashing or updating firmware.
Change-Id: I710363d9df626d51756a265f0099f26ef28411c2
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76153
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Adding EC_HOST_EVENT_PANIC to SCI mask allows the EC to interrupt the
Kernel when an EC panic occurs. If system safe mode is also enabled
on the EC, the kernel will have a short period to extract and save info
about the EC panic.
BUG=b:283245785
BRANCH=firmware-grunt-11031.B
TEST=Observe kernel ec panic handler run when ec panics
Change-Id: I8eeb5c0935d0531c21bcf4cd3d4fd9dc80b54f79
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This configures the SoC to flip the orientation of the AUX pins to
follow the orientation of the cable when using the kb8010 retimer. This
is necessary when there is no external retimer/mux or the retimer/mux
does not implement the flip. The kb8010 retimer does not support this
feature, so let the SoC do the flip.
BUG=b:267589112
TEST=verified DP-ALT mode works in both cable orientations on rex with
reworked kb8010 DB by flykt@
Change-Id: Iad093e27617b80f8301008deb00b57fb9b3a48ba
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76137
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Secure OS was disabled on Grunt devices since it isn't used.
This reduces the attack surface and is meant to mitigate potential
security risks. However, this prevents users from using an alternate OS.
Enable Secure OS upstream to allows users to use Windows, and ensure
that it is still disabled in the chromium repo.
BUG=b:287630343
TEST=Builds with Secure OS included.
Cq-Depend: chromium:4620881
Change-Id: I213aebc41cae300ecee8c01fc5c7687f7e7f5ee3
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
New port based on autoport.
Autoport worked with minor tweaks, but fan speeds went almost
immediately to the maximum. They are controlled by the NPCD379
Super I/O which isn't supported by coreboot.
But coreboot already has code for NPCD378,
which HP Compaq 8200 SFF makes use of.
So SuperIO configuration was copied from the 8200 SFF port.
It seems to work without any issues in "normal" use.
Most importantly, fan speed control seems to work correctly.
However this means that some of the SuperIO LDNs may be configured
incorrectly. See the comments on Gerrit for more information.
The following is tested and is working:
* Native raminit with both DIMMs
* Libgfxinit textmode and framebuffer on both DisplayPorts and VGA
* External USB2 and USB3 ports: they all work
* USB 3.0 SuperSpeed on Linux-libre (rear, 4 ports)
* Ethernet
* Mini-PCIe WLAN
* SATA: 2.5" SSD and optical drive bay
* Booting Live Linuxes from DVD and USB with SeaBIOS 1.16.1
* GRUB (with Libreboot config)
* PS/2 keyboard and mouse
* S3 suspend and resume, wake using USB keyboard
* Headphone output, line out, internal speaker
* Wake on LAN
* Rebooting
* CMOS options & nvramcui
Untested:
* mSATA slot. The SATA port needs to be enabled on devicetree
too, but I'm unable to test due to lack of hardware
* Line in, mic input
* MXM graphics card
* EHCI debug
Not working:
* Mini-PCIe USB: I couldn't get it working on vendor BIOS either, so
maybe it just isn't present
* PS/2 keyboard wake from S3
Change-Id: I2dc31778c2aa1987d5acdf355973a203dd0bb3a3
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74906
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch performs below operations to enable LAN0.
- Complete the LAN PEREST power sequencing
- Program the SRC_CLKREQ (GPP_D20) with correctly.
- Add overridetree.cb entry to configure the LAN0 device.
BUG=b:289395519
TEST=Able to boot google/ovis with LAN0 being enabled.
Change-Id: I91b0a76395ade4459cf8705c333728a71f95df14
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76213
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch performs below operations to enable LAN1.
- Add overridetree.cb entry to configure the LAN device.
- Complete the LAN1/SD PEREST power sequencing
BUG=b:289395519
TEST=Able to boot google/ovis with LAN1 being enabled.
Change-Id: Ifb67cb8e6fc03e3ff14b1b3d8382322fd0b3aeff
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76212
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch configures GPP_V12 aka SOC_SLP_LAN_L properly as per the
Ovis schematics dated June'23 to ensure LAN port is not in sleep.
BUG=b:289395519
TEST=Able to measure SLP_LAN PIN and confirm it's deasserted.
Change-Id: I1fe8715862823149c8a1f05e3e4463a615fbbbce
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76211
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch configures GPP_C10 aka EN_LAN_RAILS properly as per the Ovis
schematics dated June'23 to ensure LAN ports having power.
BUG=b:289395519
TEST=Able to measure LAN port power is enabled with this CL.
Change-Id: I3f4d611313325dba66905e0c8ef391765a1fe7a7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
flashrom does not support libftdi 0.20 anymore and it's not used by
anything else. Its build systems (Makefile and Meson) only reference
libftdi1 and it still compiles fine without the legacy package. Thus,
drop it from the package list.
Change-Id: If1b575bc9abfd192e93811a83d8615bed61eba0c
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
flashrom does not support libusb 0.1 anymore and it's not used by
anything else. Its build systems (Makefile and Meson) only reference
libusb1 and it still compiles fine without the legacy package. Thus,
drop it from the package list.
Change-Id: Ib9b7530e5b707e12fbf3f8058999456dc1f8dff4
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This was missed recently when adding the table. Linux complains about
the missing checksum, e.g.
[ 0.186070] ACPI BIOS Warning (bug): Incorrect checksum in table [SPCR] - 0x00, should be 0x87 (20210730/tbprint-173)
Tested with QEMU/Q35, albeit with changes to the special handling for
ACPI with QEMU. The warning goes away.
Change-Id: I0086a3e8c5b3a06da9edf40a7a288c534fc5a6b2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Fixes: commit 90464073e4 (acpi: Add SPCR table)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76158
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In mtl, there is no MAILBOX_BIOS_CMD_TCSS_DEVEN_INTERFACE
So, this patch removes unused code related to
MAILBOX_BIOS_CMD_TCSS_DEVEN_INTERFACE
ADL also removes this code, see cl:62861
BUG=b:288976547
TEST=Tested on Screebo and DP/USB are working as expected after suspend/resume
Change-Id: I5a4b26c38ec3f5fe1d81fd70f8c2196d0e5b84c3
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76126
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SOC/IOE SRAM device is used to store crash logs. Previously, the
crashlog enablement was hardcoded in the baseboard.common module.
This commit moves the crashlog enablement logic to the baseboard
module, so that it can be enabled or disabled based on the specific
baseboard.
Additionally, the SOC/IOE SRAM is now enabled by default in the
baseboard devicetree.cb file. This prevents the system from hanging
if the SOC/IOE SRAM device is not present.
BUG=b:262501347
TEST=Able to build and boot google/screebo with this patch.
w/o this patch:
[ERROR] SOC SRAM device not found!
[ERROR] IOE SRAM base not valid
Change-Id: I02d581e5b62cfa114a3761a9704ad9f24dead8aa
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76134
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
When probing the resource with the IOMMU_IOAPIC_IDX index, we need to
use the PCI device 0 function 0 on the first bus in the domain for
probing and not the domain device, since the resource isn't on the
domain device, but on the northbridge device which is B0F0D0 in the case
of the APUs.
TEST=This fixes the following error on Mandolin with Picasso:
AMD-Vi: [Firmware Bug]: : IOAPIC[1] not in IVRS table
AMD-Vi: Disabling interrupt remapping
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id88f17d68ba5accef6561837478828bd3d24baa5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76117
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Hades uses DDR5 which can't read SPD from coreboot yet. Use smbios
dump to print memory information.
TEST=check the coreboot log.
memory Channel-0-DIMM-0 type is DDR5
memory part number is MTC8C1084S1SC56BG1
memory max speed is 5600 MT/s
memory speed is 5200 MT/s
memory size is 16384 MiB
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Ica44081228a3a1edc36e2110e84686582fbe8f33
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
This patch avoids random hang issue observed after booted to OS on LPDD5/x platforms due to CLK not tuned properly in SAGV point 0, 2133MT/s.
As per Intel doc 769410 the expected work around is to change SAGV
point 0 from 2133 G4 to 3200 G4.
BUG=b:287170545
TEST=Able to perform 500 power cycles on google/rex without any hang.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I02a9cadc075f396549703d7a008382e76268f865
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76076
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Assign the current address casted to acpi_ivrs_ivhd[11,40]_t pointer to
*ivhd_[11,40] at the beginning of acpi_fill_ivrs[11,40] and then use
memset on *ivhd_[11,40] to zero-initialize the structs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I70b12fee99d6c71318189ac35e615589a4c8c629
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76077
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No matter what DRAM calibration is performed, DRAM scramble should be
enabled as long as MEDIATEK_DRAM_SCRAMBLE is set to y. Currently, DRAM
scramble is enabled only if full calibration is performed. Correct the
behavior by adding DRAMC_CONFIG_SCRAMBLE to the header config in fast
calibration flow.
BUG=b:285474337
TEST=Check the scramble feature is disabled on serial build
Signed-off-by: Xi Chen <xixi.chen@mediatek.corp-partner.google.com>
Change-Id: I907bccd4e68e040179e1971db6bf7a57b88dec1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75818
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Description of POST_EXIT_PCI_SCAN_BUS indicates the opposite of what
its name suggests. Secondly, POST_ENTER_PCI_SCAN_BUS and
POST_EXIT_PCI_SCAN_BUS have identical comments, which appears to be
a copy-paste issue.
Change the description accordingly.
Change-Id: Ifc920651255bacf033cac39f0208d817f9ee84fc
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76047
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The eMMC entry in the IVRS table should only be generated if an eMMC
controller is present in the SoC.
Where the PCI_DEVFN(0x13, 1) is from is currently unclear to me. There
is no PCI device 0x13 on bus 0 and the eMMC controller is also an MMIO
device and not a PCI device, but this is what the reference code does.
My guess would be that it mainly needs to be a unique PCI device that
won't collide with any existing PCI device in the SoC. Add a comment
about this too.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00865cb7caf82547e89eb5e77817e3d8ca5d35dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Rename shared SRAM aliases for IOE and PMC to make them more readable.
pci device 13.3 is IOE shared sram, renamed to ioe_shared_sram.
pci device 14.2 is PMC shared sram, renamed to pmc_shared_sram.
Rename them in SOC code as well as mainboard to make sure the patch
builds for the relevant boards.
BUG=b:262501347
TEST=Able to build.
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Change-Id: I02a8cacc075f396549703d7a008382e76258f865
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75999
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The CNVi PCI device is required for the system to boot properly.
By ensuring that this device is enabled, we can prevent the below
error message from appearing and ensure that the system boots successfully.
BUG=b:274421383
TEST=Able to build and boot google/ovis without any error.
w/o this patch:
[ERROR] CNVi WiFi is enabled without CNVi being enabled
[ERROR] CNVi BT is enabled without CNVi being enabled
Change-Id: I4dbae14f0cfccf96a33437a0e2fdefb508209354
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
This patch introduces a newer config to store the CSE RW FW version into
the CBMEM. Prior to that CSE RW FW version was fetched unconditionally
and ended up increasing the boot time by 7ms to 20ms depending on the
SoC arch (including CSE arch).
The way to retrieve the CSE firmware version is by sending the HECI
command to read the CSE Boot Partition (BP) info. The cost of sending
HECI command to read the CSE FW version is between 7ms-20ms (depending
on the SoC architecture) hence,ensure this feature is platform specific
and only enabled for the platformthat would like to store the CSE version into the CBMEM.
TEST=Build and boot google/rex to avoid getting CSE RW FW version
to save 18ms of the boot time.
w/o this patch:
10:start of ramstage 722,215 (43)
17:starting LZ4 decompress (ignore for x86) 741,415 (19,200)
w/ this patch:
10:start of ramstage 722,257 (43)
17:starting LZ4 decompress (ignore for x86) 723,777 (1,520)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I94f9f0f99706724c7d7e05668390f3deb603bd32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
The patch adds a possibility to cache the PCIe 5.0 HSPHY firmware in
the SPI flash. New flashmap region is created for that purpose. The
goal of caching is to reduce the dependency on CSME and the HECI IP
LOAD command which may fail when the CSME is disabled, e.g. soft
disabled by HECI command or HAP disabled. This change allows to
keep PCIe 5.0 root ports functioning even if CSME/HECI is not
functional.
TEST=Boot Ubuntu 22.04 on MSI PRO Z690-A and notice PCIe 5.0 port
is functional after loading the HSPHY from cache.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5a37f5b06706ff30d92f60f1bf5dc900edbde96f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68987
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When moving the code to allocate at the top level in commit 9260ea60bf
(allocator_v4: Use memranges only for toplevel), a call to restrict the
limit of the resource was dropped. Probably by accident in one of the
earliest rebases. Without this call to effective_limit(), 64-bit resour-
ces at the top level, i.e. PCI bus 0, were always placed above 4G. Even
when this was not requested with the IORESOURCE_ABOVE_4G flag.
Tested on kontron/ktqm77 where the issue could be reproduced with
x86_64. Without the fix, boot hangs when trying to access the GMA
MMIO registers of PCI 00:02.0, which were placed above 4G.
Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483
Signed-off-by: Nico Huber <nico.h@gmx.de>
Found-by: 9elements QA
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76090
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces CBMEM ID to store the MRC version (similar to
existing implementation that stores the FSP-M version inside CBMEM ID)
inside cbmem so the version information is available across the
different coreboot stages. For example:
* romstage: Use the CBMEM ID version information to check if the MRC
cache is valid and need to erase the MRC cache
* ramstage: Use the CBMEM ID to store the MRC cache into the
non-volatile space.
BUG=b:261689642
TEST=Able to build and boot google/rex and dump the MRC version as
below.
cbmem --list
CBMEM table of contents:
NAME ID START LENGTH
...
21. MRC VERSION 5f43524d 75ffeb60 00000004
...
localhost ~ # cbmem -r 5f43524d | hexdump
00000000 01 12 07 00
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I91f735239b33c6f8ba41c076048903e4b213c6a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75921
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch uses the "generic" variable name as "version" while storing
the MRC cache data instead referring to the FSP-M version or MRC
version. Hence, updated all the instances of `fsp_version/fspm_version`
with `version`.
Also introduces the new option to the MRC cache
version that allows SoC users to store the MRC cache version based on
the supported EDK2 version. Intel FSP built with EDK2 version 202302
onwards has support to retrieve the MRC version by directly parsing
the binary.
Additionally, added the helper function `fsp_mrc_version()` and
corresponding header file to read the MRC version from the FSP binary.
BUG=b:261689642
TEST=Able to build and boot google/rex and google/omnigul.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia8af53aed674ad4a3b426264706264df91d9c6b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75920
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
During phase 1 of the resource allocation we gather all the size
requirements. Starting from the leafs of our devicetree, we cal-
culate the requirements per bus, until we reach the resource do-
main.
However, because alignment plays a role, we can't just accumulate
the sizes of all resources on a bus. Instead, we already sort all
the resources per bus to predict their relative placement, inclu-
ding alignment gaps. Then, phase 2 has to perform the final allo-
cations with the exact same relative placement.
This patch introduces a very simple mechanism to avoid repeating
all the calculations: In phase 1, we note the relative `base` of
each resource on a bus. And after we allocated all the resources
directly below the domain in phase 2, we add the absolute `base`
of bridge resources to the relative `base` of child resources.
This saves most of the computational complexity in phase 2. How-
ever, with a shallow devicetree with most devices directly below
the domain, this won't have a measurable impact.
Example after phase 1:
domain
|
`-- bridge #0
| res #0, base 0x000000 (relative),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0x800000 (relative),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0x000000 (relative),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
After phase 2 allocation at the domain level (assuming res #0 got
0xa000000 assigned):
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0x800000 (relative),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0x000000 (relative),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
Now, all we need to do is to add the `base` of bridge resources
recursively. Starting with resources on the bus below bridge #0:
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0xa800000 (absolute),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0xa000000 (absolute),
| size 8M, align 8M
|
`-- device #1
res #3, base 0x000000 (relative),
size 8M, align 8M
And finally for resources on the bus below bridge #1:
domain
|
`-- bridge #0
| res #0, base 0xa000000 (absolute),
| size 12M, align 8M
|
|-- device #0
| res #1, base 0xa800000 (absolute),
| size 4M, align 4M
|
`-- bridge #1
| res #2, base 0xa000000 (absolute),
| size 8M, align 8M
|
`-- device #1
res #3, base 0xa000000 (absolute),
size 8M, align 8M
Change-Id: I70c700318a85f6760f27597730bc9c9a86dbe6b3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65420
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
We currently have two competing mechanisms to limit the placement of
resources:
1. the explicit `.limit` field of a resource, and
2. the IORESOURCE_ABOVE_4G flag.
This makes the resource allocator unnecessarily complex. Ideally, we
would always reduce the `.limit` field if we want to "pin" a specific
resource below 4G. However, as that's not done across the tree yet,
we will use the _absence_ of the IORESOURCE_ABOVE_4G flag as a hint
to implicitly lower the `limit` of a resource. In this patch, this
is done inside the effective_limit() function that hides the flag
from the rest of the allocator.
To automatically place resources above 4G if their limit allows it,
we have to allocate from top down. Hence, we disable the prompt for
RESOURCE_ALLOCATION_TOP_DOWN and turn it on by default. Platforms
that are incompatible should be fixed, but can also override the
default as a temporary measure.
One implication of the changes is that we act differently when a
cold-plugged device reports a prefetchable resource with 32-bit
limit. Before this change, we would fail to allocate the resource.
After this change, it forces everything on the same root port below
the 4G line.
A possible solution to get completely rid of the IORESOURCE_ABOVE_4G
flag would be rules to place resources of certain devices below 4G.
For instance, the primary VGA device and storage and HID devices
could be made available to a payload that can only address 32 bits.
For now, effective_limit() provides us enough abstraction as if the
`limit` would be the only variable to consider. With this, we get
rid of all the special handling of above 4G resources during phase 2
of the allocator. Which saves us about 20% of the code :D
An earlier version of this change (commit 117e436115) had to be
reverted because of missing resource reservations in platform code.
This is worked around now with commit ae81497cb6 (device/pci:
Limit default domain memory window).
Change-Id: Ia822f0ce648c7f7afc801d9cb00b6459fe7cebea
Signed-off-by: Nico Huber <nico.h@gmx.de>
Original-reviewed-on: https://review.coreboot.org/c/coreboot/+/65413
Original-reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reducing the polling time from 16ms to 2ms. Experimentally we
have determined that the link state normally takes approximately
3.5ms to update and therefore we were waiting longer than necessary.
TEST=build and confirm we are not waiting the extended period.
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: I8fabb5ac46cae5c92d5b6f1dc0641a4d121c61dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76052
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Pre-boot display is not POR for google/rex hence disable the config
ENABLE_TCSS_DISPLAY_DETECTION.
BUG=b:247670186
TEST=Build and boot to google/rex and make sure that display over TCSS
works in the OS
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Ib55e251a4620c7a375ee2f27763154c39207236e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
For Phoenix the lane numbers in the DXIO descriptor match the ones in
the schematic, so remove the corresponding text and the table from the
comment on the fsp_dxio_descriptor struct. Since there's no logical to
physical lane number remapping needed for the lanes in the Phoenix DXIO
descriptors, drop the 'logical' from the start_logical_lane and
end_logical_lane fields in the DXIO descriptor and rename those to
start_lane and end_lane.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I94664fd9d3807370b73f9fae8645d444e5faf7b7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch adds the initial code for adlrvp_rpl variant board
which includes
1. Add overridetree.cb to corresponding variant directory
2. Update mainboard name in Kconfig and Kconfig.name
3. Add config option to select corresponding overridetree.cb
BUG=b:286030718
BRANCH=firmware-brya-14505.B
TEST=Able to build with the patch and boot the adlrvp_rpl platform
to ChromeOS on Windows SKU.
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Ifb95ff705189863d23894769ff450f9528e73b14
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73962
Reviewed-by: Usha P <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
USB type-A port with same PLD.token information as USB type-C port,
causes conflict while generating ACPI code for the EC CONN device.
Use a different PLD.token number for type-A port to fix the issue.
BUG=b:286328285
TEST=check ACPI can have right USB port in EC CON.
before patch:
Package (0x02)
{
"usb2-port",
\_SB.PCI0.XHCI.RHUB.HS01
},
Package (0x02)
{
"usb3-port",
\_SB.PCI0.TXHC.RHUB.SS01
},
after patch:
Package (0x02)
{
"usb2-port",
\_SB.PCI0.XHCI.RHUB.HS01
},
Package (0x02)
{
"usb3-port",
\_SB.PCI0.TXHC.RHUB.SS03
},
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: If3e76c11dd6808eee4c9c2f3f71604a60379b5a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This patch renames config `SOC_INTEL_METEORLAKE_U_P` to
`SOC_INTEL_METEORLAKE_U_H` as per Intel Meteor Lake Processor EDS
version 1.3.1 (doc number: 640228).
With new branding, the MTL-U/H-Processor Line offered in a 1-chip platform that includes the Compute, SOC, GT, and IOE tile on the
same package.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I032be650bbfef0bf0ef86bb37417b1d854303501
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75931
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
DDR5 spd is not supported read by coreboot. But FSP can read it,
so print the memory information from smbios type17 dimm information.
TEST=check the coreboot log.
memory Channel-0-DIMM-0 type is DDR5
memory part number is MTC8C1084S1SC56BG1
memory max speed is 5600 MT/s
memory speed is 5200 MT/s
memory size is 16384 MiB
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I2b5ca1f4a59598531a6cba500672c2717f2a7b00
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75756
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using the boolean type and the true/false macros give the reader a
better understanding about the option. Thus, use the bool type for the
attribute and use the macros for assignments.
Skylake mainboards which use that option were changed by the following
command ran from the root directory.
socs="SOC_INTEL_(SKYLAKE|KABYLAKE|SKYLAKE_LGA1151_V2)" && \
option="s0ix_enable" && \
grep -Er "${socs}" src/mainboard | \
cut -d ':' -f 1 | \
awk -F '[/]' '{print $1"/"$2"/"$3"/"$4}' | \
xargs grep -r "${option}" | \
cut -d ':' -f 1 | \
xargs sed -i'' -e "s/${option}\".*\=.*\"1\"/${option}\" \= true/g"
Change-Id: I372dfb65e6bbfc79c3f036ce34bc399875d5ff16
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75871
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Enable early caching of the TOM region to optimize the boot time by
selecting `SOC_INTEL_COMMON_BASECODE_RAMTOP` config.
Purpose of this feature is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I579f85e84e0aba7f192ff81a6725d65b7f79ff75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74517
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a new Kconfig that controls whether CBFS APIs for
unverified areas will allow file decompression when CBFS verification is
enabled. This should be disallowed by default because it exposes the
attack surface of all supported decompression algorithms. Make
allowances for one legacy use case with CONFIG_SOC_INTEL_CSE_LITE_
COMPRESS_ME_RW that should become obsolete with VBOOT_CBFS_INTEGRATION.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ieae420f51cbc01dae2ab265414219cc9c288087b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75457
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This configures the SoC to flip the orientation of the AUX pins to
follow the orientation of the cable when using the anx7452 retimer. This
is necessary when there is no external retimer/mux or the retimer/mux
does not implement the flip. The anx7452 retimer does not appear to
support this feature, so let the SoC do the flip.
BUG=b:267589042,b:281006910
TEST=verified DP-ALT mode works on rex using both cable orientations
Change-Id: Ibb9f442d2afd81fb5dde4bca97c15457837f9f4a
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75827
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
edk2-stable202111 is older release of edk2. MTL FSP uses 202302 Edk2.
There are structure definition changes between 202111 and 202302. One of
change is in FSP_INFO_HEADER structure. Also, Next Gen Intel SoC needs
202302 Edk2.
This patch includes (edk2/edk2-stable202302) all required
headers for edk2-stable202302 EDK2 tag from EDK2 github
project using below command:
git clone -b edk2-stable202302 https://github.com/tianocore/edk2.git
commit hash: f80f052277c88a67c55e107b550f504eeea947d3
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.
Add UefiCpuPkg/Include Because `MpServices2.h` file is part of
`UefiCpuPkg/Include/Ppi/`
Add following fixes from edk2-stable202111
060492ecd2 Safe guard enum macro in SmBios.h
2bf9599cf1 Use fixed size struct elements
BUG=b:261689642
TEST= select UDK_202302_BINDING Kconfig for MTL, Test Build and boot rex
Image
Change-Id: I8d4deab0bd1d2c6df28e067894875b80413cd905
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
- 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>
The original clock rate 416MHz is insufficient for 4K resolution and
causing the screen to glitch. Set the clock rate to 594MHz to support
4K resolution.
BUG=b:236328487
TEST=Glitching screen was fixed after applying this patch
Change-Id: Ic40dd28264d03ef7218ff4edd8d4182e0fe74ea3
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75661
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Define a CMOS layout for Librem Mini v1/v2 spanning both banks. The
only setting provided is the automatic power-on setting, which is
implemented by the EC. This can now be configured in a firmware image
by replacing cmos.default in CBFS.
Since cmos.default is applied early in bootblock, the EC BRAM interface
must now be configured in bootblock, including opening the LPC I/O
range.
Change-Id: Ib0a4ea02d71f6f99e344484726a629e0552e4941
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74363
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Geralt SoC does not support 'persist certain regions' across reboots.
Considering the impact of missing ramoops for debugging, set
MEDIATEK_DRAM_SCRAMBLE to default n to disable this feature in
production FW image.
BUG=b:269049451,b:278478563
TEST=emerge-geralt coreboot and confirm CONFIG_MEDIATEK_DRAM_SCRAMBLE=n
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Change-Id: I109634d811a928e3e6f7f56e706a5b61a52a21ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75562
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As per AMD64 Architecture Programmer's Manual, section 10.2.5 SMRAM
Protected Areas:
The TSEG range must be aligned to a 128 Kbyte boundary and the minimum
TSEG size is 128 Kbytes.
The SMM TSEG size should be less than SMM reserved size.
AMD TSEG mask works like an MTRR. It needs to be aligned to it's size
and it's size needs to be a power of 2.
Change-Id: Ic4f557c7b77db6fc5ab2783ca4e2ebe7a4476e85
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75405
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This commit introduces a refactored version of the IVRS (I/O
Virtualization Reporting Structure) table generation. The main objective
of this refactoring is to generalize the process of generating the IVRS
table based on the IOMMU (Input/Output Memory Management Unit) domains
and their corresponding resources.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: Ic471f05d6000c21081d70495b7dbd4350e68b774
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75451
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch configures external V1p05/Vnn/VnnSx rails for Joxer
to achieve the better power savings.
* Enable the external V1p05, Vnn, VnnSx rails in S0i1, S0i2, S0i3, S3,
S4, S5 , S0 states.
* Set the supported voltage states.
* Set the voltage for v1p05 and vnn.
* Set the ICC max for v1p05 and vnn.
Kit: 646929 - ADL N Platform Design Guide
BUG=b:285477026
TEST=Verified all the UPD values are updated with these configs.
Signed-off-by: Mark Hsieh <mark_hsieh@wistron.corp-partner.google.com>
Change-Id: I78d2a885d577f6c1a89ab74c0da7b6544322c0d7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Baieswara Reddy Sagili <baieswara.reddy.sagili@intel.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Updating from commit id 9df5910:
2023-05-10 15:42:44 +0100 - (mb/starlabs/starbook/adl: Update EC binary to 1.13)
to commit id 797e7fc:
2023-06-10 03:59:43 +0000 - (00730F01/binaryPI: fix firmware table lookup)
This brings in 8 new commits:
797e7fc 00730F01/binaryPI: fix firmware table lookup
ba23e82 cpu/intel/stm: Use URLs so a link is generated
ecad6f8 cpu/intel/stm: Mark up file name as code/monospace
3434921 cpu/intel/stm: Use *firmware* over *BIOS*
a683e04 cpu/intel/stm: Use official spelling of *Kaby Lake*
ec80479 cpu/intel/stm: Remove blank line at end of README.md
22248b1 cpu/intel/stm: Remove blank line at start of README.md
475dce4 mb/google/utils: Add script to prepare PSP verstage for signing
Change-Id: I0005c3950bcbdf407c2abfc254123931806952f2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75792
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Updating from commit id 4c985e867:
2023-03-14 19:53:19 +0100 - (Merge "fix(cpus): workaround for Neoverse V1 errata 2743233" into integration)
to commit id c161772f4:
2023-06-08 15:47:09 +0200 - (Merge "refactor(el3-spmc): add emad_advance()" into integration)
This brings in 598 new commits.
Change-Id: I4008ebfffa1ff5176fa9cfe262cfd1598e6751c7
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Updating from commit id 066e52e:
2022-10-04 14:04:23 +0000 - (Fix "unnecessary with of ancestor [-gnatwr]")
to commit id 732feb4:
2023-06-04 12:14:31 +0000 - (gma i2c: Update for Tiger Lake)
This brings in 17 new commits:
732feb4 gma i2c: Update for Tiger Lake
fc49b60 gma: Update PCH Rawclk programming for TGL
1b65b84 gma: Update BDSM register offset for TGL onwards
79a5379 gma pcode: Add Mailbox_Read procedure
b6df683 gma registers: Update for Tiger Lake and Alder Lake
24748f3 dp aux: Add support for TGL
e9631d8 gma: Begin Alder Lake (ADL) integration
605660b gma: Begin Tiger Lake (TGL) integration
0dadb67 gma pch-transcoder: Work around GNAT issue
fe80fbb common: Turn off VGA when not in use anymore
793f4f8 gma: Correct Global annotation for Initialize()
1dff38c gma: Make HW.GFX.GMA.SPLL package private
c68cafa gma skylake: Avoid aliasing of Config.State
17b513e gma: Shuffle warning justifications to support old and new tooling
3c1ac18 display probing: Update warning justification
b636d81 framebuffer filler: Extend loop invariant to assist prover
420e863 dp info: Provide Link_Status'Object_Size and padding
Change-Id: I17a95cc0b8e9dc4bffe8c82f0f53ee411281061b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75786
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id 33cc4f2:
2022-10-26 14:21:20 +0530 - (sc7280/qtiseclib: Update qtiseclib blobs binaries and release notes from 63 to 69)
to commit id a252198:
2023-05-23 11:00:31 +0000 - (sc7180/boot: Update qclib blobs binaries from 50 to 55)
This brings in 4 new commits:
a252198 sc7180/boot: Update qclib blobs binaries from 50 to 55
3fbd986 sc7180/qtiseclib: Update qtiseclib blobs binaries and release notes from 50 to 69
7a3f064 sc7280/boot,shrm: Update qclib blobs binaries from 35 to 52
9884189 sc7280: Update AOP firmware to version 454
Change-Id: I938b768318d31d5e105d7c98823947cf8c02b195
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This add's an option to use EDK2's Universal Payload instead
of the standard UefiPayloadPkg. Universal Payload requires
a ShimLayer, to build the required HOBs and pass them to Universal
Payload.
The ShimLayer is built to encompass UniveralPayload, so only
one ELF binary is added to coreboot.
Universal Payload is based on Intel's USF specification:
https://universalscalablefirmware.github.io/documentation/
This has been added with the repository pointing to
https://github.com/starlabsltd. The required ShimLayer patches
will be merged into edk2 master once corresponding coreboot
patches are merged.
This is because the EDK2 engineers believe it is an impossible
task to patch coreboot to build and use Universal Payload.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I17cc86d5eac0d5d91551ba5bea73fbc07ebdf0d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65934
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Follow spec[1] to modify WWAN power sequence. The WWAN power sequence
of warm reset is fail. The correct sequence is WWAN_EN should keep high when doing warm reset. Set GPP_D6 to PWROK which is not to do PAD
reset when warm reset.
[1]:
[JDB10] FC ADL-N_WWAN sequence_FM101-GL SDX12 Power Timing
Review_V1.6_20230602.xlsx
BUG=b:285065375
BRANCH=firmware-nissa-15217.B
TEST=1. emerge-nissa coreboot chromeos-bootimage
2. power sequence meets spec.
Change-Id: If59630dbd10e971c91e01f33a657c01d857bc0b9
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75690
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The file VGA_BIOS_FILE points to is right now the Mendocino VBIOS. Since
the default value probably shouldn't point to a location in site-local,
drop this for now, but leave a TODO to put that back once the correct
VBIOS files are available in 3rdparty/amd_blobs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifbc6cbe1e371d8d247f86555a5361ed237897dea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of adding the new PCI IDs of the XHCI controllers in every new
chip generation to the pci_xhci driver, bind the driver to the internal
PCI devices of the XHCI controllers via the device ops statement in the
chipset devicetree. The PCI device function of the XHCI2 controller in
Mendocino can be either a dummy device or the XHCI controller, so the
device ops are attached to that device in the mainboard devicetree
instead. The Glinda code is right now just a copy of the Mendocino code,
so it'll change in the future, but for consistency the equivalent
changes to those in Mendocino are applied there too.
Since the device ops are now attached to the devices via the static
devicetree entry, also remove both the xhci_pci_driver struct and the
amd_pci_device_ids array from drivers/usb/pci_xhci/pci_xhci.c.
TEST=SSDT entries for the XHCI controllers are still generated on
Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9c455002c6d2aac576fe24eee0c31744b4507bb0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Initialize the SPI Flash in bootblock to ensure that
CONFIG_SPI_FLASH_EXIT_4_BYTE_ADDR_MODE will exit 4-byte addressing mode.
BUG=b:285110121
TEST=boot myst and verify flash operations work correctly
Change-Id: Ia88d2b46884b096b4c558bc86513159ec6d35eb5
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75588
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCI root complex itself isn't on an enumerable bus, so without
providing an _STA method, the device will still be assumed to be present
and visible, so this won't change behavior. This also brings Stoneyridge
more in line with the newer SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I663c7bcba89ffe25d0819d83461cb95e10f49028
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75671
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCI root complex itself isn't on an enumerable bus, so without
providing an _STA method, the device will still be assumed to be present
and visible, so this won't change behavior. This also brings Picasso
more in line with Cezanne and newer SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ied48b48113f6e871e90d17cbd216be003f05b5ef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having the different static parts of the PCI0 device in
northbridge.asl and sb_pci0_fch.asl, instantiate the static parts of the
PCI0 device via the ROOT_BRIDGE macro in soc.asl.
TEST=Both Ubuntu 2022.4 and Windows 10 still boot successfully and don't
show any new ACPI-related error.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2587d8bb270dc3edce9dfa570a5018116fc9187f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
When instantiated in the DSDT, this macro will expand to the static part
of the PCIe root bridge device. This macro allows both to deduplicate
parts of the DSDT code as well as adding more than one PCIe root bridge
device in the DSDT.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6f20d694bc86da3c3c9c00fb10eecdaed1f666a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75568
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the new common AMD code that gets the usable non-fixed MMIO windows
from the data fabric MMIO decode registers and generate the PCI0 _CRS
ACPI code based on those regions. For a more detailed description see
the corresponding patch that changes the Picasso code to use this new
code. In contrast to the Picasso code, this change will drop the
unneeded _STA method inside the PCI0 scope which wasn't present in
Picasso's ACPI code before it got replaced by the SSDT that gets
generated by amd_pci_domain_fill_ssdt.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I948d882b2e2c6d19f73c0be094e4ff6e42ec81d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75560
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use the new common AMD code that gets the usable non-fixed MMIO windows
from the data fabric MMIO decode registers and generate the PCI0 _CRS
ACPI code based on those regions. For a more detailed description see
the corresponding patch that changes the Picasso code to use this new
code. In contrast to the Picasso code, this change will drop the
unneeded _STA method inside the PCI0 scope which wasn't present in
Picasso's ACPI code before it got replaced by the SSDT that gets
generated by amd_pci_domain_fill_ssdt.
BUG=b:283495475
TEST=Myst still boots and both the coreboot console and the kernel show
the expected PCI MMIO ranges being used.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I425876c4ef470574e00e123d36101641240c98cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Use the new common AMD code that gets the usable non-fixed MMIO windows
from the data fabric MMIO decode registers and generate the PCI0 _CRS
ACPI code based on those regions. For a more detailed description see
the corresponding patch that changes the Picasso code to use this new
code. In contrast to the Picasso code, this change will drop the
unneeded _STA method inside the PCI0 scope which wasn't present in
Picasso's ACPI code before it got replaced by the SSDT that gets
generated by amd_pci_domain_fill_ssdt.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iad34d74d9f6cbed1d8a71a561a505f563e31db18
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use the new common AMD code that gets the usable non-fixed MMIO windows
from the data fabric MMIO decode registers and generate the PCI0 _CRS
ACPI code based on those regions. For a more detailed description see
the corresponding patch that changes the Picasso code to use this new
code. In contrast to the Picasso code, this change will drop the
unneeded _STA method inside the PCI0 scope which wasn't present in
Picasso's ACPI code before it got replaced by the SSDT that gets
generated by amd_pci_domain_fill_ssdt.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b14ee0682ae1f2212ab43977c076687706434ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75557
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having PCI0's _BBN method in the DSDT that always returns 0,
use acpigen_write_BBN to generate the _BBN method that returns the first
PCI bus number in the PCI domain/host bridge.
TEST=On mandolin the _BBN method in the _SB/PCI0 scope is now in the
SSDT instead of the DSDT, but still returns 0.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8badeb0064b498d3f18217ea24bff73676913b02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74992
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use amd_pci_domain_read_resources function that gets the configured MMIO
regions for the PCI root domain from the data fabric's MMIO decode
registers instead of using pci_domain_read_resources. This results in
the same IO port range being used by the allocator, but makes sure that
the allocator will only allocate non-fixed MMIO resources in the address
ranges that get decoded to the PCI root complex. In order for the PCI0
_CRS ACPI resource template to match the decoded PCI root domain MMIO
windows, use amd_pci_domain_fill_ssdt to generate the _CRS ACPI code
instead of having a mostly hard-coded _CRS method in the DSDT. This
makes sure that the OS will know about the MMIO regions it is allowed to
used.
Before this patch, only the region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS was advertised as usable PCI MMIO in the
PCI0 _CRS method. Also the resource allocator didn't get any constraint
on which address ranges it can use to put the non-fixed MMIO resources.
This approach worked until now, since all address range from 0 up to
right below TOM1 was filled with either usable or reserved memory and
the allocator was allocating beginning right from TOM1, since it was
using the bottom-up allocation approach and everything below TOM1 was
already in use. The MMIO region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS also matched the MMIO decode window
configured in the data fabric's MMIO decode registers, so everything
seemed to work fine. However, when either selecting
RESOURCE_ALLOCATION_TOP_DOWN or enabling above 4GB MMIO, things broke
badly. This was partially due to the allocator putting non-fixed MMIO
resources in regions that weren't decoded to the PCI root, since AMD
family 17h and 19h silicon doesn't subtractively decode PCI MMIO and the
wrong ranges the allocator used also weren't advertised in ACPI.
TEST=Even when selecting RESOURCE_ALLOCATION_TOP_DOWN that usually ends
up with a non-working system when the MMIO ranges aren't reported
correctly to the resource allocator due to the reasons descried above,
Ubuntu 22.04 LTS still boots on Mandolin both with SeaBIOS and EDK2
payload and Windows 10 boots with EDK payload. There's however an EDK2
bug that results the MMCONFIG region not being advertised in the e820
table, which causes Linux to not use the MMCONFIG and fall back to the
legacy PCI config access method. This only happens with EDK2 payload and
everything works fine when using SeaBIOS as payload. That e820 issue is
unaffected by this patch.
At the end of the data_fabric_set_mmio_np call, this is the data fabric
MMIO register configuration:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
The limit of the data fabric MMIO decode register 1 is configured as
0xffffffffffff although this is way beyond the addressable memory space.
add_data_fabric_mmio_regions fixes this up, so the range that gets
passed to the allocator in that case is 0x7fcffffffff which takes both
the reserved most significant address bits used for the memory
encryption and the 12GB reserved data fabric MMIO at the top of the
usable address space into account.
This results in the following domain ranges passed to the resource
allocator:
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done
DOMAIN: 0000 mem: base: fc000000 size: 0 align: 0 gran: 0 limit: febfffff
DOMAIN: 0000 mem: base: 10000000000 size: 0 align: 0 gran: 0 limit: 7fcffffffff
DOMAIN: 0000 mem: base: d0000000 size: 0 align: 0 gran: 0 limit: f7ffffff
The IO resource producer region is split into two parts to not cover the
PCI config IO region resource consumer. This results in these resources
being added to the PCI0 _CRS resource template:
amd_pci_domain_fill_ssdt ACPI scope: '\_SB.PCI0'
PCI0 _CRS: adding busses [0-3f]
PCI0 _CRS: adding IO range [0-cf7]
PCI0 _CRS: adding IO range [d00-ffff]
PCI0 _CRS: adding MMIO range [fc000000-febfffff]
PCI0 _CRS: adding MMIO range [10000000000-7fcffffffff]
PCI0 _CRS: adding MMIO range [d0000000-f7ffffff]
PCI0 _CRS: adding VGA resource
Kernel version 5.15.0-43 from Ubuntu 2022.4 LTS prints this in dmesg:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-3f]
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff window]
pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfebfffff window]
pci_bus 0000:00: root bus resource [mem 0x10000000000-0x7fcffffffff window]
Another noteworthy thing I wasn't aware of at first when testing ACPI
changes on Windows 10 is that a normal Windows shutdown and boot cycle
won't result in it processing the changed ACPI tables; you have to tell
it to reboot to do a proper full boot where it will process the updated
ACPI tables (and fail if it dislikes something about the ACPI tables and
bytecode).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia24930ec2a9962dd15e874e9defea441cffae9f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74712
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Generate the PCI0 _CRS ACPI resource template to tell the OS which PCI
bus numbers and IO and MMIO regions can be used for PCI devices below
_SB/PCI0. This data corresponds to what amd_pci_domain_scan_bus and
amd_pci_domain_read_resources provided to the resource allocator. This
makes sure that the PCI0 _CRS ACPI resource template matches the
constraints the resource allocator used when allocating resources.
TEST=With also the rest of the current patch train applied, the
generated _CRS resource template contains the expected PCI bus numbers
and IO and MMIO resources and both Linux and Windows boot on Mandolin.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaf6d38a8ef5bb0163c4d1c021bf892c323d9a448
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74843
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When an IO resource producer is generated that covers the whole IO space
from 0 to 0xffff, the length field in the word resource ACPI type would
overflow and be truncated which results in Linux not finding any usable
IO space to use for the PCI IO BARs. Instead generate a double word IO
resource producer to have all cases supported. Beware that covering all
IO ports with the IO resource producer while covering the PCI config IO
ports with a resource consumer in the same PCI root device will make
Linux a bit unhappy and it will complain due to the overlap, but still
end up doing the right thing:
acpi PNP0A08:00: host bridge window expanded to [io 0x0000-0xffff]; [io 0x0000-0xffff window] ignored
The SoC code should make sure to carve out the PCI config IO ports from
the IO resource producer.
TEST=Both Ubuntu 2022.04.1 LTS and Windows 10 are ok with the IO DWord
resource producer.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8a59cdfcfa30a8fdd13f8db3dc1447994c266c8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75613
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Provide amd_pci_domain_scan_bus to enumerate the PCI buses in the one
PCI root domain and amd_pci_domain_read_resources to read the MMIO
regions that the resource allocator can use to allocate the PCI MMIO
BARs in the one PCI root domain from the corresponding data fabric MMIO
decode registers. This makes sure that the allocator will only put PCI
MMIO resources in areas that are decoded to the PCIe root complex. The
current code only covers the case of a system with one PCI root where
all PCI bus numbers belong to the only PCI root, all IO ports get
decoded to the only PCI root and the MMIO regions from the data fabric
MMIO decode registers get decoded to the only PCI root. In future
patches, this will be extended to also support the multi PCI root case.
TEST=With also the rest of the current patch train applied, the resource
allocator uses the constraints on the MMIO regions and both Linux and
Windows boot on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4aada7c8a2a43145ad08d11d0a38d9cdc182b98e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74717
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In case the secure memory encryption is enabled, some of the upper
usable address bits of the host can't be used any more. Bits 11..6 in
CPUID_EBX_MEM_ENCRYPT indicate how many of the address bits are taken
away from the usable address bits in the case the secure memory
encryption is enabled.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia810b0984972216095da2ad8f9c19e37684f2a2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75623
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Meteor Lake SOC has a separate I/O Expander (IOE) die.
SRAM from this IOE die contains crashlog records for the IPs
of the IOE die.
This patch adds functions with empty implementation using
__weak attribute for IOE die related crashlog, changes common
data structures while maintaining backwards compatibility,
and support for filling IOE crashlog records, guarded by
SOC_INTEL_IOE_DIE_SUPPORT config and makes cl_get_pmc_sram_data
function as weak because it needs SOC specific implementation.
Bug=b:262501347
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog
Change-Id: Id90cf0095258c4f7003e4c5f2564bb763e687b75
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75475
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The K&D-ILI9882T panel and STA-ILI9882T share all DCS commands and EDID
information except for the manufacturer_name which has no effect to the
function of panel. Let's reuse the STA_ILI9882T struct in this case.
BUG=None
TEST=emerge-staryu coreboot chromeos-bootimage and boot the panel
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I510462a49d273f3d25158b25906d4c514f855cdf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Based on the power sequence of the panel [1], the power on T2 sequence
VSP to VSN should be larger than 1ms, and the power off T2 sequence VSP
to VSN should be larger than 0ms. We modify the power sequence to meet
the datasheet requirement.
[1] B5 TV110C9M-LL0 Product Specification Rev.P0
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I4ccb5be04062a0516f84a054ff3f40afbf5279be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
vboot code changes have eliminated the redundant call to WP the EC-RO
region as protecting RW flash implies protecting both RO and RW flash,
so the call to protect RO is redundant. google/rex currently takes
about 17 ms to lock down the EC.
Along with vboot changes, this patch drops argument to choose between
RO and RW slot to protect while calling into `vb2ex_ec_protect()`.
It ensures vb2ex_ec_protect() is explicitly meant for protecting RW
regions.
w/o this patch:
517:waiting for EC to allow higher power draw 846,196 (17,297)
w/ this patch:
517:waiting for EC to allow higher power draw 838,258 (9,719)
Additionally, update vboot submodule to upstream main to avoid the
compilation error.
Updating from commit id 35f50c3154e5:
Fix build error when compiling without -DNDEBUG
to commit id 034907b279c9db:
vboot_reference: eliminate redundant call to write protect EC-RO
Change-Id: I2974f0cb43ba800c2aaeac4876ebaa052b5ee793
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The version of the 4.19 release notes on the server was updated with
signatures and a note explaining the new tarballs vs the original,
corrupted tarballs. That data didn't make it back to the version of
the release notes in the documentation.
Likewise, the updates in the documentation didn't get pushed to the
release directory on the website.
The website now has this version of the release notes that combines the
two. This patch does the same for the documentation folder.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib2563e7fa4b8d82ad4fbb3fd3880ee62a24a8aca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This adds printing content of 'manifest' file at ramstage.
It allows to learn about blobs version used to build the coreboot
binary, which is useful when investigating bugs.
Version data are stored in CBFS file, which was generated during
coreboot build. If AMD FW blobs will be manually replaced in coreboot
image, versions from CBFS file are no longer valid.
Log:
AMDFW blobs version:
type: 0x01 ver:00.3c.01.18
type: 0x08 ver:00.5a.28.00
type: 0x30 ver:2b.25.b0.10
type: 0x73 ver:00.3c.01.18
BUG=b:224780134
TEST=Tested on Skyrim device
Change-Id: I8df54b74cd987b4a3be635932d38ea178d0b0311
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74269
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This moves the release notes to 4.20.1, as was done with the 4.8 release
when it went to 4.8.1. The index.md file is updated for both the 4.20.1
and 4.8.1 releases, and extra spacing was added. This doesn't get shown
in the output, but makes the text version look better.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic2fb35f1bf9fa7dc16d324882cd6057a1a4b05ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75637
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Update the 4.20 release notes to the final post-release version.
This fixes a few typos, updates the statistics to include the final few
patches, and adds a note about the licensing issues which required a
version bump to 4.20.1.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I350535b8aa531642e161f1cad4752452f9171647
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Since we now explicitly compile both ramstage and smihandler code
without floating point operations and associated registers we don't need
to save/restore floating point registers.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I180b9781bf5849111501ae8e9806554a7851c0da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75317
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Add an NVMe drive and be more conservative with hotplug-capable PCIe
ports. QEMU treats everything as hotpluggable by default, so devices
can be added at runtime. However, this leads to unrealistic resource
allocations with PCIEXP_HOTPLUG enabled.
Tested recent allocator changes with QEMU/Q35 config and:
$ make qemu QEMU_EXTRA_CFGS=util/qemu/q35-alpine.cfg
Change-Id: I23746b642329356c6767b04ec177cd9411e3adb9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67026
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Ensure USB-C ports' _PLD group numbers appear in order.
get_usb_port_references in src/ec/google/chromeec/ec_acpi.c uses group
token to match with the Type-C port number.
BUG=b:216490477
TEST=build coreboot and system boot into OS.
BRANCH=firmware-brya-14505.B
Change-Id: I5c0395d33ee47ab1c7d45f33d6afb063b8263836
Signed-off-by: Won Chung <wonchung@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75572
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ensure USB-C ports' _PLD group numbers appear in order.
get_usb_port_references in src/ec/google/chromeec/ec_acpi.c uses group
token to match with the Type-C port number.
BUG=b:216490477
TEST=build coreboot and system boot into OS.
BRANCH=firmware-brya-14505.B
Change-Id: I51ff0991565d60807c100b33fb66ab10cc48b8e1
Signed-off-by: Won Chung <wonchung@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Ensure USB-C ports' _PLD group numbers appear in order.
get_usb_port_references in src/ec/google/chromeec/ec_acpi.c uses group
token to match with the Type-C port number.
BUG=b:216490477
TEST=build coreboot and system boot into OS.
BRANCH=firmware-brya-14505.B
Change-Id: Ib564ffe272e73f46ec6608420dc431c8b017fb65
Signed-off-by: Won Chung <wonchung@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Select SOC_INTEL_RAPTORLAKE for kuldax so that it will use the RPL
FSP headers for kuldax.
BUG=b:285406822
BRANCH=firmware-brya-14505.B
TEST="FW_NAME=kuldax emerge-brask
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage"
Cq-Depend: chromium:4583807, chrome-internal:6003096
Change-Id: Icbf8b26bc2bfee2559cce236bde80a99f8bff859
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75599
Reviewed-by: Bob Moragues <moragues@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Add the phoenix usb config struct for Myst since the FSP has been
updated to accept the config from coreboot and the default values
do not work.
BUG=None
TEST=Boot to OS on Myst, verify devices are seen with lsusb
Change-Id: I329aba80f3003a3a5f343b8dcc3efa8502b98e24
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75574
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Enable ISH based on FW_CONFIG obtained from EC CBI. This is useful in
case device is a tablet and motion sensors are handled by ISH instead
of EC.
BUG=b:280329972,b:283023296
TEST= Set bit 21 of FW_CONFIG with CBI
Boot rex board
Check that ISH is enabled and loaded
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Change-Id: Ibe0e1b8ce2c9b08ac6b1e6fef9bd19afc9b4f59f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75039
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix for the "Onboard Keyboard and Type-C ports are not working after
resuming from powerd_dbus_suspend" issue. This issue was caused since
FSP 3165 FSP was fixed and started skipping GpioConfigureIoStandbyState
programming when GpioOverride UPD is enabled.
This patch moves the IO Standby State programming that FSP was doing to
coreboot.
BUG=b:284264580
TEST=Boot to OS, compare gpio pins, verify keyboard / Type-C
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: If96c1e71fdde784a55fe079875915ffa5a4f548a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75555
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To support the localized text, we need to get the locale id by vboot
APIs and read raw string content file: preram_locales located at either
RO or RW.
The preram_locales file follows the format:
[string_name_1] [\x00]
[locale_id_1] [\x00] [localized_string_1] [\x00]
[locale_id_2] [\x00] [localized_string_2] ...
[string_name_2] [\x00] ...
This code will search for the correct localized string that its string
name is `memory_training_desc` and its locale ID matches the ID vb2api
returns. If no valid string found, we will try to display in English
(locale ID 0).
BUG=b:264666392
BRANCH=brya
TEST=emerge-brya coreboot chromeos-bmpblk chromeos-bootimage
Change-Id: I7e3c8d103c938a11b397c32c9228e44e31c3f01d
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On Myst, the FSP is shutting down the PCIe lanes that the SSD is
on. Enable hotplug to force the FSP to keep the lanes active.
BUG=b:284213391
TEST=Boot to OS
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: Iaf0aca329f05f15a3ce9edfa6a0e782c2edccabe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Libpayload's USB API was changed in commit e9738dbe2b (libpayload: Make
USB transfer functions return amount of bytes). However, the UHCI driver
was never adapted. Instead of returning 0 for success, we can return the
expected data length as a best effort. We won't be able to catch short
transfers this way, but previously working cases will work again.
Change-Id: I31d7de495a46af401e2cbe5a3b8f6349facad8ff
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch ensures to update the FSP-M UPDs related to PCIe RP mask
properly as per the SoC type.
For example: PCIe RPs belong to the SoC/IOE die for MTL-U/P whereelse
PCIe RPs are from PCH die in case of MTL-S.
BUG=b:276697173
TEST=Able to build and boot google/rex.
Change-Id: Ice81553274682476bb4c927061b1196dc142836d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75608
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch introduces the different SoC flavors of Intel Meteor Lake as:
* MTL-U
* MTL-P
* MTL-S
MTL-U and MTL-P are PCH less designs, while MTL-S is with PCH die.
The task for mainboard is to specify the correct SoC type rather than
selecting the MTL SoC by default.
This change is necessary to support the different SoC flavors of Intel
Meteor Lake.
BUG=b:276697173
TEST=Able to build and boot google/rex.
Change-Id: I27404bbbd0b489412953118e140f6f39b6e43426
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75606
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Because Makefile.sphinx looks like a standard makefile from the sphinx
project, it probably shouldn't be updated without good reason. This
change lets us update the output directory and tell the Makefile.sphinx
where we want the output.
Also fix the spacing on PDFLATEX to match the new SPHINXDIR variable.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iab111e8feea8ec02260f39636e7c17fd1cae7c30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Create the karis variant of the rex0 reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0.)
BUG=b:285195072
TEST=util/abuild/abuild -p none -t google/rex -x -a
make sure the build includes GOOGLE_KARIS
Change-Id: I16d8b43390401789b87a6233238e37f32a17b46b
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Hash table containing hashes of all signed PSP binaries is compiled at
build time and installed into the concerned CBFS. During boot, PSP
verstage reads the hash table binary and passes it to PSP bootloader.
PSP bootloader in turn uses the hash table to verify the signed PSP
binaries. Currently the hashes for all the signed PSP binaries are
compiled into one hash table. On upcoming platforms with more number of
signed PSP binaries, PSP bootloader does not have resources to handle
one monolithic hash table. Instead PSP bootloader recommends splitting
them into smaller hash tables (currently limited to 3 hash tables).
Update amdfwtool tool to support splitting hash tables. This is done by
adding an optional hash table id to the entries in the amdfw.cfg file.
By default, one hash table binary is always compiled and it's name is of
the format ${signed_rom}.hash. If an entry has a hash table id defined,
then this utility will compile a separate hash table binary whose name
is of the format ${signed_rom}.${N}.hash where N is the hash table id.
BUG=b:277292697
TEST=Build Skyrim BIOS image and boot to OS. Ensure that the hash table
is identical with and without this change. Perform suspend/resume
cycles, warm/cold reset cycles for 50 iterations each.
TEST=Artificially inject hash table id against some entries in
amdfw.cfg and ensure that the concerned hash table binaries are getting
compiled.
Change-Id: I7ef338d67695a34c33b5c166924832939f381191
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
pci_rom_probe() can allocate memory when mapping a CBFS
file, so pci_rom_free() should be called before leaving
the function.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: Ie6fbbfd36f0974551befef4d08423a8148e151e7
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74779
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
It adds simple function, which frees the memory which
could be allocated by pci_rom_probe(). In the next step
it will be modified to free only memory, which was mapped
from CBFS.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: Ibc9aad34b6bf101a3a0c06b92ed2dc6f2d7b9b33
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74778
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move microcode load/unload to pre_mp_init and post_mp_init callbacks.
It allows to make sure that ucode is freed only if all APs updated
microcode.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Passing this option tells amdfwtool to create a text file, containing
the versions of the blobs below:
- PSP bootloader (type 0x01),
- SMU firmware (type 0x08),
- AGESA bootloader 0 (type 0x30),
- PSP bootloader AB (type 0x73).
Created file can be embedded into CBFS which allows to read the version
of blobs at runtime. This way version of blobs used to build the
coreboot image can be verified at runtime and also from the binary file.
Format of manifest file is following:
$ cat build/amdfw_manifest
type: 0x01 ver:00.35.00.13
type: 0x08 ver:00.5a.23.a6
type: 0x30 ver:2a.14.b0.10
type: 0x73 ver:00.35.00.13
BUG=b:224780134
TEST=Tested on Skyrim device
Change-Id: Idaa3a02ace524f44cfa656e34308bd896016dff6
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Enable early caching of the TOM region to optimize the boot time by
selecting `SOC_INTEL_COMMON_BASECODE_RAMTOP` config.
Purpose of this feature is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Iadbce3124a88cf5be0aebde4a76ec6fd4b670216
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Follow the schematic_0502 to add the audio codec and amp.
BUG=b:270109435
TEST=Check device can detect in coreboot.
[INFO ] \_SB.I2C3.RT58: Realtek RT5682 at I2C: 04:1a
[INFO ] \_SB.I2C3.D029: Realtek SPK AMP R at I2C: 04:29
[INFO ] \_SB.I2C3.D02A: Realtek SPK AMP L at I2C: 04:2a
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Icfec8d99be8fde986c5516e0c4cd50dae1edfa98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75477
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are only SSD connected to SATA ports on this mainboard. To prevent
misbehavior, set the correct hard drive type for enabled SATA ports.
BUG=none
TEST=Boot into OS and check the stability of the SSD
Change-Id: I2c2b0548865e87859a1d742295e09a731bfb3f76
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Intel's APL FSP offers the possibility to select the connected hard
drive type to SATA ports. One has the option to choose between HDD ('0'
- default) and SSD ('1').
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: I52c3566fb3c959ada6be33f0546ac331f4867d10
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
In cases where there are limitations on the mainboard it can be
necessary to limit the used SATA speed even though both, the SATA
controller and disk drive support a higher speed rate. The FSP parameter
'SpeedLimit' allows to set the speed limit.
It should be noted that Gen 3 equals the default value '0'. This means
that inside FSP the same code is executed.
This patch provides a chip config so that this FSP parameter can be
set as needed in the devicetree on mainboard level.
Change-Id: I9c3eda0649546e3a40eb24a015b7c6efd8f90e0f
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75364
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check existence of crashlog records in CBMEM before copying them
to BERT, otherwise it can lead to NULL pointer access.
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I4288011866283a3a5fb8ec9e10cd51b794052b4e
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75528
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new Kconfig LINUXPAYLOAD_CMDLINE_VPD_OVERWRITE that can overwrite
Linux payload's kernel command line from VPD. Currently only overwrite
Linux kernel command line 'loglevel' via VPD key 'kernel_log_level'.
TESTED=On OCP Delta Lake, with kernel_log_level set to 0, warm reboot
time can see about 10 seconds improvement comparing to kernel log level
7.
Change-Id: Idf06c7ab9958c940fc3b23d560bb9dade991a6da
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
When the default pci_domain_read_resources() is used,
keep 32-bit memory resources below the limit given by
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT. This serves as a
workaround for missing/wrong reservations of chipset
resources.
This will help to get more stable results from our own
allocator, but is far from a complete solution. Indvi-
dual platform ASL code also needs to be considered, so
the OS won't assign conflicting resources.
Most platforms have reserved space between 0xfe000000
and the 4G barrier. So use that as a global default.
In case of `soc/intel/common/`, use 0xe0000000 because
this is what is advertised in ACPI and there are traces
of resources below 0xfe000000 that are unknown to core-
boot's C code (PCH_PRESERVED_BASE?).
Tested on QEMU/Q35 and Siemens/Chili w/ and w/o top-
down allocation. Fixes EHCI w/ top-down in QEMU.
Change-Id: Iae0d888eebd0ec11a9d6f12975ae24dc32a80d8c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75102
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the power sequence of the panel [1] and PMIC datasheet [2],
the power on T2 sequence VSP to VSN should be large than 1ms, but it's
-159us now, and the power off T2 sequence VSP to VSN should be large
than 0ms, but it's less than 0 now. Let's modify the power sequence
to meet the datasheet requirement.
[1] HX83102-J02_Datasheet_v03.pdf
[2] TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:282902297
TEST=power sequence T2 pass
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Ib1625c6a211f849071393f69eaf5c649a8e7f72e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75298
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The TPS65132S is designed to supply positive/negative driven
application. It communicates through standard I2C compatible interface,
and it intergrates a EEPROM whose contents will be loaded into the
register at startup. Since TPS65132S is used in staryu and geralt
projects, we move the implementation to mediatek/common.
The datasheet: TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:282902297
TEST=boot starmie to firmware screen
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Iad2c9bdea5824455efcef18b44876111061cfa1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75488
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Don't assume only one IO and one MEM domain resource.
Currently the code is awkward for bridge devices where loops over
resources are done twice. This would be avoided on top of other patches
that improve the allocator (topic:allocator) by adding a top-down mode.
However those patches break the tree and having the option to have
multiple resources per type would make it easier to get those patches in
without breaking the tree.
Change-Id: I3d3a60c9a4438accdb06444e2b50cc9b0b2eb009
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67018
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
This patch refers and backport some of previous work from Linux Kernel
(https://lore.kernel.org/all/1561689337-19390-3-git-send-email-ricardo.
neri-calderon@linux.intel.com/T/#u) that optimizes the MTRR register
programming in multi-processor systems by relying on the CPUID
(self-snoop feature supported).
Refer to the details below:
Programming MTRR registers in multi-processor systems is a rather
lengthy process as it involves flushing caches. As a result, the
process may take a considerable amount of time. Furthermore, all
processors must program these registers serially.
`wbinvd` instruction is used to invalidate the cache line to ensure
that all modified data is written back to memory. All logical processors
are stopped from executing until after the write-back and invalidate
operation is completed.
The amount of time or cycles for WBINVD to complete will vary due to the
size of different cache hierarchies and other factors. As a consequence,
the use of the WBINVD instruction can have an impact on response time.
As per measurements, around 98% of the time needed by the procedure to
program MTRRs in multi-processor systems is spent flushing caches with
wbinvd(). As per the Section 11.11.8 of the Intel 64 and IA 32
Architectures Software Developer's Manual, it is not necessary to flush
caches if the CPU supports cache self-snooping (ss).
"Flush all caches using the WBINVD instructions. Note on a processor
that supports self-snooping, CPUID feature flag bit 27, this step is
unnecessary."
Thus, skipping the cache flushes can reduce by several tens of
milliseconds the time needed to complete the programming of the MTRR
registers:
Platform Before After
12-core (14 Threads) MeteorLake 35ms 1ms
BUG=b:260455826
TEST=Able to build and boot google/rex.
Change-Id: I83cac2b1e1707bbb1bc1bba82cf3073984e9768f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This patch removes the wbinvd call preceding CR0.CD setting in
disable_cache() to improve the boot time performances. According to
some experimental measurements, the wbinvd execution takes between 1.6
up and 6 milliseconds to complete so it is preferable to call it only
when necessary.
According to Intel Software Developer Manual Vol 3.A - 12.5.3
Preventing Caching section there is no need to flush and invalidate
the cache before settings CR0.CD. The documented sequence consists in
setting CR0.CD and then call wbinvd.
We also could not find any extra requirements in the AMD64
Architecture Programmer’s Manual - Volume 2 - Memory System chapter.
This extra wbinvd in coreboot disable_cache() function does not seem
documented and looking into the history of the project got us all the
way back to original commit 8ca8d7665d ("- Initial checkin of the
freebios2 tree") from April 2003.
Even the original disable_cache() implementation (see below) is a bit
curious as the comment list two actions:
1. Disable cache cover by line 74, 75 and 77
2. Write back the cache and flush TLB - Line 78
But it does not provide any explanation for the wbinvd call line 76.
68 static inline void disable_cache(void)
69 {
70 unsigned int tmp;
71 /* Disable cache */
72 /* Write back the cache and flush TLB */
73 asm volatile (
74 "movl %%cr0, %0\n\t"
75 "orl $0x40000000, %0\n\t"
76 "wbinvd\n\t"
77 "movl %0, %%cr0\n\t"
78 "wbinvd\n\t"
79 :"=r" (tmp)
80 ::"memory");
81 }
BUG=b/260455826
TEST=Successful boot on Skolas and Rex board
Change-Id: I08c6486dc93c4d70cadc22a760d1b7e536e85bfa
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Enable drivers for SoundWire codecs and define the topology in
the devicetree for the rex0 variant with the SoundWire daughter
board connected.
+------------------+ +--------------------+
| | | Headphone Codec |
| Intel Meteor Lake| +--->|Cirrus Logic CS42L42|
| SoundWire | | | ID 0 |
| Controller | | +--------------------+
| | |
| Link 0 +----+ +-------------------+
| | | Left Speaker Amp |
| Link 1 | +--->| Maxim MAX98363 |
| | | | ID 0 |
| Link 2 +----| +-------------------+
| | |
| Link 3 | | +-------------------+
| | | | Right Speaker Amp |
+------------------+ +--->| Maxim MAX98363 |
| ID 1 |
+-------------------+
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 Meteor Lake HDA PCI device
HDAS.SNDW - Intel Meteor Lake SoundWire Controller
HDAS.SNDW.SW00 - Cirrus Logic CS42L42 - Headphone Codec
HDAS.SNDW.SW20 - Maxim MAX98363 - Left Speaker Amp
HDAS.SNDW.SW21 - Maxim MAX98363 - Right Speaker Amp
BUG=b:269497731
TEST=Verified SSDT for SNDW in the OS. Playback and recording are also
validated on google/rex.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I3e11dc642ff686ba7da23ed76332f7f10e60fade
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73280
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The FBVDD_PWR_EN signal should be inverted in its control level
on Agah v.s. Hades. The original change covered the Hades
implementation, but needs to be updated to invert for Agah. This
change can be removed once we drop support for Agah.
BUG=b:280467267
TEST=built for Hades and Agah
Change-Id: I7f90c03b8d9b859004e5c124bf0a1f7b59921c3d
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75530
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add ACPI DmaProperty for WLAN device. `is_untrusted` is eventually
ended up by adding DMA property _DSD which is similar to what
`add_acpi_dma_property` does for WWAN drivers, hence it makes sense to
have a unified name across different device drivers.
BUG=b:279676191
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I6d898a939aa0be31a671d2436a81c34f7a1ec030
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75460
Reviewed-by: Shou-Chieh Hsu <shouchieh@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Add 'common_config.acp_config' to the device tree, so we have the
correct pin configuration.
BUG=b:225320579
TEST=USE=fwconsole emerge-skyrim ... ; verify 'devbeep' works in
depthcharge console
TEST=Boot into ChromeOS, verify YouTube sound works with internal
speakers and headphone jack
TEST=Boot into ChromeOS, verify microphone with Google Meet
Change-Id: Ie2d79408104273d8a53214b683800fa0663c14d3
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Improve boot time performances by replacing the wbinvd instruction
with multiple clflush to ensure that the SIPI data is written back to
RAM.
According to some experimental measurements, the wbinvd execution
takes between 1.6 up and 6 milliseconds to complete. In the case of
the SIPI data, wbinvd unnecessarily flushes and invalidates the entire
cache. Indeed, the SIPI module is quite small (about 400 bytes) and
cflush'ing the associated cache lines is almost instantaneous,
typically less than 100 microseconds.
BUG=b/260455826
TEST=Successful boot on Skolas and Rex board
Change-Id: I0e00db8eaa6a3cb41bec3422572c8f2a9bec4057
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Suggested-by: Erin Park <erin.park@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75391
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
With the coreboot build process, `UniversalPayloadBuild.sh` calls
`UniversalPayloadBuild.py`. That Python script will unconditionally
build DXE as 64-bit, but accepts an argument for the entry point:
parser.add_argument('-a', '--Arch', choices=['IA32', 'X64'],
help='Specify the ARCH for payload entry module. Default build X64
image.', default ='X64')
Currently, ` -a IA32 -a X64` is passed, and the Python script will
use the `X64` argument, resulting in a payload that won't work with
coreboot.
Remove the `-a X64`, so the resulting build is a 32-bit entry point,
and 64-bit DXE, which works with coreboot.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I8a557d6e155a2938b44036d98f9274cc8b38f156
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73668
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This function can be called to more easily add a file to CBFS.
Additional file attributes can be added later:
cbfs-files-y += pagetables
pagetables-file := $(objcbfs)/pt
pagetables-type := raw
pagetables-compression := none
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
becomes
$(call add-cbfs-file-simple, pagetables, $(objcbfs)/pt, raw, none )
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
This is especially useful inside macros where you may want to add
an unknown number of entries.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I72bb2f21fb22f650b7970c7a37a48c10a4af0ed5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The acpigen_resource_[bus_number,io,mmio*] functions didn't make it very
clear that they are generating resource producer ranges and not resource
consumer ranges. To clarify this, change the function names to
acpigen_resource_producer_[bus_number,io,mmio*] and explicitly add the
ADDR_SPACE_GENERAL_FLAG_PRODUCER flag which evaluates to 0, so this
doesn't change the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I334f38aa8ab418d5577f92b980ff750504e2bb4e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75486
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
The IBM SBP1 is an evaluation platform.
It's utilising:
- 4 SPR sockets, having 16 DIMMs each
- 240C/480T at maximum
- 32x CPU PCIe slots
- 2x M.2 PCH PCIe slots
- Dual 200Gbit/s NIC
- SPI TPM
It has an AST2600 BMC for remote management.
It doesn't have:
- External facing USB ports
- Video outputs
- Audio codec
Test:
The board boots to Linux 5.15 with all 480 cores available.
All PCIe devices are working and no errors in ACPI.
All 64 memory DIMMS are working and M.2 devices can be used.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: Ie21c744224e8d9e5232d63b8366d2981c9575d70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73392
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit enables the build for IO Margining, ensuring that ASPM is
disabled and certain FSP knobs are adjusted in coreboot as below
1. Enable DFXEnable
2. Disable PcieGlobalAspm
3. Disable KtiLinkL1En & KtiLinkL0pEn
Since the FSP UPD does not provide all the necessary knobs for IO
Margining, the following settings need to be applied during the FSP
build process:
1. Enable PcdBiosDfxKnobEnabled
2. Disable PchDmiAspm
3. Enable SataTestMode
4. Enable WmphyMargining
5. Disable IioErrorEn
TEST=Build for IBM sbp1 board.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: Ie306d12943adb76411d55358548b5cb2eb3a95be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75415
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds support for Intel 800 series chipset. The new chipset
can be uniquely identified by its SPI speed, eSPI speed, and
chipset name.
This commit message is clear and concise, and it accurately describes
the changes that were made to the code. It also includes the following
information:
- Specify the correct chipset name.
"PCH Revision: 800 series Meteor Lake"
- Show the valid eSPI/EC frequency.
"Read eSPI/EC Bus Frequency: 20MHz"
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I70619d9e3ed2bcad86f84a0527e3a0ad13acd706
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch adds two new chromeos_*.fmd files for release and debug FSP
builds targeting rex_ec_ish.
`rex_ec_ish` variant would pack ISH firmware into the CSE boot partition
hence, the blob size is expected to increase. Creates separate flash map
layout to ensure ISH work is not impacting on the regular `rex0` project
SPI flash usage.
BUG=b:284254353
TEST=Able to build google/rex_ish_ec board and boot on target hardware.
Change-Id: Ife4663d3ccf80a928646eadaac4c9ab49ad29055
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75471
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch creates a new variant to support the ISH enablement using
Rex platform.The idea here is to leverage the `rex0` code as much as
possible and add specific support for ISH enablement as per the hardware
schematic differences.
BUG=b:284254353
TEST=Able to build google/rex_ish_ec board and boot on target hardware.
Change-Id: I625fd0b31aed998f4e8f2d139827bc212ee8a90b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75470
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
EFS header is mapped during PSP verstage and bootblock to read some SPI
configuration. After use it is left unmapped. Unmap the EFS region after
use.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I865f45a3d25bc639eb8435b54aa80895ec4afd27
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75455
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I51b9d066a40103f2ebdf2ef2fc3da13beb467921
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: If1d355972cc743b8d8c451e1b3f827abd15e98fe
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
On FMAP without RW slots, PSP verstage fails to build because of
reference to FMAP_SECTION_FW_MAIN_A_*. Instead extract the offset and
size of relevant sections using fmap_locate_area().
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I29997534c6843b47a36655431f79e5c70bd17f9b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The SuperIO ACPI name was hard-coded to "SIO0". Allow setting the name
in the device tree so more than one SuperIO can be named.
An upcoming board (purism/librem_l1um_v2) has two SuperIOs - one in the
AST2500 BMC, and a Nuvoton NCT6791D used for hardware monitor, POST
display, etc.
Many boards have references to SIO0 already, so the default name is
still the same for a single SuperIO.
Change-Id: Ibfa6ab7622749e6310ee91530bc3722e8e28d9bb
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75089
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support of variant_devtree_update() function to override
devtree settings for variant boards. Also, add CPU power limit
values for rex baseboard.
BRANCH=None
BUG=b:270664854
TEST=Built and verified power limit values as below log message
for 15W SKU on Rex board.
Overriding power limits PL1 (mW) (10000, 15000) PL2 (mW)
(57000, 57000) PL4 (W) (114)
Change-Id: If46445157358e3e0f227e26a35b4303fc9189a4b
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add support to update power limit values for variants.
Until now, each SoC implements this themselves.
To avoid code duplication, add this to common code.
BRANCH=None
BUG=b:270664854
TEST=Built and verified power limit values as below log message
for 15W SKU on Rex board.
Overriding power limits PL1 (mW) (10000, 15000) PL2 (mW)
(57000, 57000) PL4 (W) (114)
Change-Id: I414715f211d816bbfad03a673ca96dd5df94caeb
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74620
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Hook the SaGvFreq, SaGvGear upds so that mainboard can change the
settings via devicetree. Meteor Lake supports 4 SaGv work points and it
can dynamically scale the work point based on memory bandwidth
utilization. Dynamic gearing technology allows the Memory Controller to
run at 1:1, 1:2 or 1:4 ratio of DRAM speed. The gear ratio is the ratio
of DRAM speed to Memory Controller Clock.
BUG=b:282164577
TEST=Verified the settings on google/rex using debug FSP logs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I37169880af4019675374594e90735b5d7d0873b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75290
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the schematic and vendor ASL code, PCI interrupt lines ABC of
the Ricoh R5C847 PC Card/Media Card/FireWire controller are routed DBC.
From lspci and the schematic this chip is PCI device 1. The original
config copied from the T400 was routed ABCD->BCDA, causing Linux to
issue an "irq 18: nobody cared" message when inserting an SD card.
This is fixed by this patch and the SD card now works properly.
Change-Id: Iede1de72d5369f1aebbac170792733739add3431
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75411
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The MAX98363 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
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 2 and has strap
settings configuring it for unique ID 0.
chip drivers/soundwire/max98363
register "desc" = ""Left Speaker Amp""
device generic 2.0 on end
end
This driver was tested with the rex0 reference design by booting
and disassembling the runtime SSDT to ensure that the devices have the
expected address and properties.
Device (SW20)
{
Name (_ADR, 0x000230019F836300) // _ADR: Address
Name (_DDN, "Left Speaker Amp") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () { "mipi-sdw-sw-interface-revision", 0x00010000 },
[...]
Package () { "mipi-sdw-source-port-list", Zero },
Package () { "mipi-sdw-sink-port-list", 0x02 }
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package ()
{
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" },
Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" }
}
})
Name (MOD0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () { "mipi-sdw-audio-mode-bus-frequency-configs",
Package () { 0x00927C00, ... }
},
Package () { "mipi-sdw-audio-mode-sampling-frequency-configs",
Package () { 0x3E80, ... }
},
[...]
}
})
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:269497731
TEST=Verified SSDT for SNDW in the OS
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Ie56109d615759e3e5e32782c8782cb2f47014ec4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73278
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even though coreboot does not allow floating point operations some
compilers like clang generate code using hw floating point registers,
e.g. SSE %XMMx registers on 64bit code by default. Floating point
operations need to be enabled in hardware for this to work (CR4). Also
in SMM we explicitly need to save and restore floating point registers
for this reason. If we instruct the compiler to not generate code with
FPU ops, this simplifies our code as we can skip that step.
With clang this reduces the binary size a bit. For instance ramstage for
qemu/Q35 drops from 216600 bytes decompressed to 212768.
TEST: See that with x86_64 bit and clang coreboot reaches the payload
without setting the CR4_OSFXSR bit in CR4. Without this change it would
bootloop very early in the bootblock on Qemu Q35.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ib8590c55e7aed1ece2aa23b8ea99463396435e11
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75316
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit f99d6700 ("mb/google/skyrim/var/winterhold: Fix USB port ACPI
generation") fixed the USB-A ports being double-nested, but neglected
to move the chip driver registers up into the correct scope. While the
generated ACPI is still correct, fix the register scope anyway to
avoid confusion.
BUG=b:283778468
BRANCH=skyrim
TEST=build/boot winterhold, dump ACPI, verify unchanged
Change-Id: Ia9982fed0fe2093d787ee9506ac5bbadd6cc03f9
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75389
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Commit d81ee3f1 ("mb/google/skyrim/var/markarth: Fix USB port ACPI
generation") fixed the USB-A ports being double-nested, but neglected
to move the chip driver registers up into the correct scope. While the
generated ACPI is still correct, fix the register scope anyway to
avoid confusion.
BUG=b:283778468
BRANCH=skyrim
TEST=build/boot markarth, dump ACPI, verify unchanged
Change-Id: I5c1cd23c49b512f55e9e13b2164d30dfb7fb682d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75388
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Commit a539893c ("mb/google/skyrim/var/frostflow: Fix USB port ACPI
generation") fixed the USB-A ports being double-nested, but neglected
to move the chip driver registers up into the correct scope. While the
generated ACPI is still correct, fix the register scope anyway to
avoid confusion.
BUG=b:283778468
BRANCH=skyrim
TEST=build/boot frostflow, dump ACPI, verify unchanged
Change-Id: I3912fe1b7d3f2a07cb379928cd4f5d87100d3284
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75387
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch adds an enum macro to define the different SaGv work points.
The enum macro is named `sagv_wp_bitmap` and it has three values:
The goal is to choose the optimal SaGv work point for the target
platform after considering the two inputs as power consumption and performance. The first group is for workloads that require high performance, even if it means consuming more power. The second group
is for workloads that can tolerate lower performance, in order to save
power.
SAGV_POINTS_0_1: The highest power consumption, but also the highest
performance.
SAGV_POINTS_0_1_2: A lower power consumption than work point
SAGV_POINTS_0_1, but also a lower performance.
SAGV_POINTS_0_1_2_3: The lowest power consumption, but also the lowest
performance.
Set SaGv work points after reviewing the power and performance impact
with SaGv set to 1 (Enabled) and various considering various work points
between 0-3 being enabled.
BUG=b:267879107
TEST=Able to build google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4af0038f2799a458d1b006270068341f65d36609
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75362
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch overrides `SaGv` FSP-M UPD to enable SaGv feature to be
able to train memory (DIMM) at different frequencies.
On all latest Intel based platforms SaGv is expected to be enabled
to support dynamic switching of memory operating frequency.
BUG=b:267879107
TEST=Able to verify SaGv is enabled with 3 work point (0, 1 and 2)
and MRC retraining takes around ~20ms extra compared to SaGv being
disabled.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic680bfeab4dd285c0d3916ba5e917cc12bae3284
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73534
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A directory for tarballs is needed in any case but it's created at build
time. However, in reproducible build environments the sources are
downloaded before the buildgcc scripts runs and the directory needs to
be created.
Thus, to simplify that, add an empty tarballs directory.
Change-Id: Id3b4bf918c93f10c145f580684e916a4f8bae3b1
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The payload API of coreboot described in
https://www.coreboot.org/Payload_API does not reflect the current
handoff mechanism to hand the coreboot tables off. Therefore the
arguments supplied by coreboot (cbtable) will currently never be parsed
correctly and libpayload has to search for the coreboot tables by
iterating through memory.
This patch removes the old payload API implementation and just takes the
coreboot table pointer from the first argument on the stack.
Tested: started prodrive/atlas with coreinfo payload
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I51fb0cfc81043cbfe3fc9c8ea0776add2d6a42b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74965
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add devicetree and Kconfig entries to enable additional configuration
of the Pericom PI7C9X2G608GP PCIe switch on this board variant.
The amplitude is being adjusted to 425 mV and de-emphasis level to
6.0 mV.
BUG=none
TEST=Read out the PCIe config space values of the switch and check if
they match with the ones configured over SMBus.
Change-Id: I11459f0794278ad614aa6e16c56df1ad578fe2f8
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The data payload size of PCIe root ports can be set to either 128
(default) or 256 bytes. A bigger payload size can improve PCIe data
throughput on the given port. FSP-S provides a parameter to configure
this value.
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: I5798a72adaa8089dda0b4bc12266b5a235ed4aa3
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75126
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Override the weak function mainboard_ewl_check() and select OCP_EWL.
Select IPMI_KCS_ROMSTAGE and IPMI_OCP for OCP IPMI commands which are
needed for OCP EWL driver, but they are Meta-specific BMC commands
and don't really work for AC, this change is just for a demonstration
with AC.
Note that FSP UPD promoteWarnings needs to be disabled so that
FSP won't block and can return to coreboot for EWL processing
when memory EWL type 3 error occurs.
Tested=On Intel AC, connected with a faulty DIMM can see
EWL type 3 error being generated and halted with coreboot log:
[DEBUG] Number of EWL entries 3
[ERROR] EWL type: 3 size:32 severity level:1
[ERROR] Major Warning Code = 0x29, Minor Warning Code = 0x04,
[ERROR] Major Checkpoint: 0xb7
[ERROR] Minor Checkpoint: 0x74
[ERROR] Socket 0
[ERROR] Channel 4
[ERROR] Dimm 0
[ERROR] Rank 0
[ERROR] IPMI: ipmi_get_board_config command failed (ret=3 resp=0xc1)
[DEBUG] ipmi send memory training error
[DEBUG] EWL type: 1 size:19 severity level:1
[DEBUG] 0x6392e968: 01 00 00 00 13 00 01 00 00 00 b7 74 0a 03 00 04
[DEBUG] 0x6392e978: 00 00 00
[DEBUG] EWL type: 1 size:19 severity level:1
[DEBUG] 0x6392e97b: 01 00 00 00 13 00 01 00 00 00 b7 74 0a 03 00 04
[DEBUG] 0x6392e98b: 00 00 01
[EMERG] Memory Training Error!
Change-Id: I4602ae356aa6e55ed0611b8ac9a206db127c297c
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
1. Rename set_cmos_mrc_cold_boot_flag() to soc_set_mrc_cold_boot_flag
in case a certain platform may not support this via CMOS data, and
the function could in turn calls mainboard defined method in the
future. Move the code into soc_util.c.
2. Remove redundant static get_system_memory_map() from cpx/romstage.c
and call the soc_util.c one.
Change-Id: Ib7d9bed9092814658f4a0b1d6dcf3c7d79178048
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The overridetree definitions for the USB ports wrongly double-nested
the ports, causing the generated SSDT to be incorrect, leading to
an error in dmesg:
ACPI BIOS error (bug): Could not resolve symbol \
[\_SB.PCI0.GP41.XHC1.RHUB.HS02.HS03], AE_NOT_FOUND
BUG=b:283778468
BRANCH=skyrim
TEST=untested, but same error/fix as frostflow variant.
Change-Id: Ic498afcc8b8e0224f344f405e2f1ef6184df1d6b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75340
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The overridetree definitions for the USB ports wrongly double-nested
the ports, causing the generated SSDT to be incorrect, leading to
an error in dmesg:
ACPI BIOS error (bug): Could not resolve symbol \
[\_SB.PCI0.GP41.XHC1.RHUB.HS02.HS03], AE_NOT_FOUND
BUG=b:283778468
BRANCH=skyrim
TEST=untested, but same error/fix as frostflow variant.
Change-Id: Ie40541ada508acfa5771ea800249b8a57b168e3b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75339
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The overridetree definitions for the USB ports wrongly double-nested
the ports, causing the generated SSDT to be incorrect, leading to
an error in dmesg:
ACPI BIOS error (bug): Could not resolve symbol \
[\_SB.PCI0.GP41.XHC1.RHUB.HS02.HS03], AE_NOT_FOUND
BUG=b:283778468
BRANCH=skyrim
TEST=build/boot frostflow, verify error no longer present in dmesg.
Change-Id: I0b87af6b2c04f9354e6f394a8f987fa660e49134
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75338
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This is needed to support 9-series PCH-H (e.g. Z97) and Broadwell
non-ULT CPUs (for which more magic is required).
Tested on Asrock Z97 Extreme6: Boots, but ME has to be disabled so that
the system remains on after 30 seconds. Apparently, something Broadwell
MRC.bin does results in the ME being unhappy, as there is no such issue
when not using MRC.bin at all (native RAM init). S3 resume is working.
Change-Id: I7b33660099fa75c5ad46aeeda17b1215729f96c3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Remove duplicated definitions of ARRAY_SIZE macro across util/ dir.
Instead of duplicates, use the one from commonlib/bsd/helpers.h file.
BUG=b:231765496
TEST=make -C util/cbfstool; make -C util/cbmem;
make -C util/intelmetool; make -C util/superiotool
Change-Id: I29b776586b4f0548d4026b2ac77095791fc9f3a3
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74474
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Grzegorz Bernacki
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Earlier the entire SPI ROM is mapped at the start of verstage and then
unmapped at the end of verstage. With CB:74606, this behavior has
changed. So unmap the hash table CBFS file after usage.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim. Perform cold, warm reboots and
suspend/resume cycles for 50 iterations each. Ensured that there is no
impact to boot time.
Change-Id: I5c605f8ba8bbd571b589b3cdf91e9cc71d711c1c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75092
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the SPI ROM is mapped completely when the boot device is
initialized. That mapping remains active throughout the execution time
of PSP verstage. Every 1 MiB of mapped SPI ROM region consumes 1 TLB
Slot in PSP for use during memory mapped or DMA access. With 16 MiB of
mapped SPI ROM + FCH devices + 4 reserved TLB slots, 31 out of 32 total
TLB slots is consumed. This leaves almost no scope for future expansion.
With upcoming programs possibly using 32 MiB SPI ROM, PSP will run out
of TLB slots to support 32 MiB.
Hence instead of mapping the entire SPI ROM upfront, get the SPI ROM SMN
address during the boot device initialization. Update the boot device
region operations to map and unmap the SPI flash with the desired offset
and size using the SVC call. Then anytime a memory mapped SPI ROM access
is performed: map the required area, read the data and immediately unmap
the area. There is no update required when using CCP DMA, since the
concerned SVC call performs mapping and unmapping of the required SPI
flash area implicitly.
With these changes, maximum of 8 slots(size of RO section) might get
used at any point in time during the PSP verstage execution.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim. Perform cold, warm reboots and
suspend/resume cycles for 50 iterations each. Ensured that there is no
impact to boot time.
Change-Id: Icd44ea7b2a366e9269debcab4186d1fc71651db2
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74606
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently unsigned PSP verstage binary is copied from ELF file only when
required in amdfw*.rom. If a signed PSP verstage binary is supplied
while building amdfw*.rom, then it is dropped. Copy the unsigned PSP
verstage binary always so that it can be used for signing directly from
the CI build infrastructure instead of a locally built binary.
BUG=None
TEST=Build Skyrim BIOS image and ensure that the unsigned PSP verstage
is part of the build artifacts.
Change-Id: If797dcfd20aa2991f3517904ef862406b9b9875c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75334
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set the DmaProperty in the device's _DSD so that the OS can treat the
device as untrusted.
BUG=b:278310256
TEST=cat /sys/bus/pci/devices/<wifi>/untrusted == 1
iperf3 -c <iperf3-server> -t 60 (No performance regressions seen)
Change-Id: I06369a19afa5b881b26f5c1eb243e2db41a9bb36
Signed-off-by: Mark Hasemeyer <markhas@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75095
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
CB:37152 was supposed to be uprev to Linux's kconfig, but it got this
one case wrong, Linux never returned "0" [1]. As a result, when an
option has default value different than 0, and it was changed to 0,
savedefconfig skips saving it. However, during the build from such
defconfig the option is assigned default value.
TEST=Set SEABIOS_DEBUG_LEVEL to 0 and see that savedefconfig writes
it to defconfig file.
[1] 7cf3d73b43
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Change-Id: I821e45dcec99904fab85f136298cbd0315237ff6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72650
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Set all GPIOs to their target functions and do not depend on FSP to
configure them. The board support has stabilized and was tested with
many PCIe devices. There is no need to detect CLKREQ signals so we may
hardcode them.
TEST=Boot MSI PRO Z690-A DDR4 to Linux and check if all ASPM and Clock
PM features' state on PCIe root ports are the same before and after
the change.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I01dc83ce23ca27525b8905665da942510f249824
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The upstream kernel privacy screen driver uses HID GOOG0010 to look for
firmware node to use. This method is used on other boards, e.g. redrix.
See: drivers/platform/chrome/chromeos_privacy_screen.c in linux sources.
Update jinlon gfx ACPI node to work with that.
BUG=b:279092050
TEST=privacy protection screen works with 5.15 and 4.19 kernels
Change-Id: Icba41e7f2be7292f713fea10dbe69b3ca128bde7
Signed-off-by: Kornel Dulęba <korneld@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75289
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
The Bochs graphics adapter remaps the legacy VGA ioports
(0x3c0 -> 0x3df) to its MMIO region at offsets 0400 - 041f.
Currently bochs_vga_write() calculates a wrong offset when
accessing these ioports, which causes the boot splash image
not displayed when using the legacy-free pci variant of the
Bochs graphics adapter.
TEST=Build coreboot for QEMU x86 i440fx with a boot splash image
included, boot coreboot.rom with QEMU with '-device secondary-vga'
and verify the boot splash image is correctly displayed.
Fixes: efaf1b32ba ("drivers/emulation/qemu/bochs: Rewrite driver")
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Change-Id: I4acc71e3d6ef5161ab62e6714c94b7643c4c0972
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75146
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
There is only a single place where we need the LVDS EDID string. Let's
call gm45_get_lvds_edid_str() right there. This simplifies the API and
helps to follow the execution flow.
The function is moved to avoid a forward declaration.
Change-Id: I86f3a88e6b661bcf60319edbe301e70304924727
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The PCI resource should only be probed as part of the device
.init process. We can simply do that first and know that we
can use the global `gtt_res` from then on.
This simplifies the signature of gm45_get_lvds_edid_str(), and
makes changes to the API user (lenovo/x200) necessary.
Change-Id: I6c96f715abfa56dcb1cd89fde0fbaef3f1cb63ae
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This patch adds an API to check FSP reset pending requests. This
information is useful to understand if FSP would like boot firmware to
issue any reset to complete the silicon initialization.
As per recent debug it has been found that, FSP is accumulating all
platform resets and executing a single reset from FSP Notify Phase.
As coreboot skipped calling into the FSP Notify APIs hence, it might
have missed the scope to issue the platform reset.
BUG=b:282266168
TEST=Able to build and boot google/rex and able to detect FSP reset
pending request.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibf7c996f09affa099c9124773fe2d581f370d1a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
GC6 - Low power mode for system idle on Nvidia GPU
In GC6I Before ramp of PEXVDD:
Deassert FBVDDQ Enable, no delay is needed before or after.
In GC6O After ramp of PEXVDD:
Assert FBVDDQ Enable, no delay is needed before or after.
BUG=b:280467267
TEST=built for Hades and Agah, tested on Agah
Signed-off-by: Eran Mitrani <mitrani@google.com>
Change-Id: I0277772b1d2f6f4e6a3f74b92035e8b36f2670ba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75302
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables stylus support by configuring the "GPP_D08" irqs for
rex SoC. This allows the SoC to detect a stylus device, when in use.
However stylus is not a wake up source for the rex.
BUG=b:282256460
Test=Stylus is detected on proto1 device.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I84a71aa664698e105b738f8680d0a4751ca1fc72
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Enable PSYS capability. PSYS is required to safeguard the system
stability if no charger IC.
BUG=b:281479111
TEST=emerge-dedede coreboot chromeos-bootimage & ensure the value is
passed to FSP by enabling FSP log & Boot into the OS
Change-Id: Ibe54acaf80700252558b82f194b9536b6117b84e
Signed-off-by: Chia-Ling Hou <chia-ling.hou@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75196
Reviewed-by: Reka Norman <rekanorman@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add igd device name in soc_acpi_name(), and src/drivers/gfx/generic
can generate device in GFX0 scope in SSDT.
BUG=b:277629750
TEST=emerge-rex coreboot then check SSDT on DUT
Signed-off-by: Won Chung <wonchung@google.com>
Change-Id: Id7a136b5234cf5c0f60ecf253ee78c123f1f573b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
With RAM init debug messages enabled, debug messages take up a lot of
flash space in romstage, with many repeated verbiage. By breaking
them up and factoring out the common verbiage, made possible with
printk(BIOS_DEBUG, "%s", ...), compiler can help deduplicate things
and make the romstage smaller.
When building for asus/p2b-ls with CONFIG_DEBUG_RAM_SETUP, this patch
shrunk romstage by 152 bytes.
Change-Id: I66e39e7901efbeb5ab72494ac02fc4d5e687c3a3
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74032
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The rationale behind this change is that multiple nested bridges using a
lot of bus numbers and IO resources is not likely to be a common hotplug
setup. When there is a large amount of hotplug ports using 32
subordinate busses results in boot failures (e.g. make qemu). 8K IO
busses for hotplug devices is also excessive in most use cases when only
64K is available in total (again make qemu results in failure to
allocate resources but does boot to payload).
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I8371958037d479e7d2053f49814735e15461ca6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74774
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch drops the assert check around
`FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN` config to ensure
`fsp_get_pch_reset_status()` can be used by all other FSP APIs to know
the status of the pending reset.
As per recent debug it has been found that, FSP is accumulating all
platform resets and executing a single reset from FSP Notify Phase.
As coreboot skipped calling into the FSP Notify APIs hence, it might
have missed the scope to issue the platform reset.
Going forward coreboot needs to implement the corresponding logic to be
able to identify any pending platform reset request and execute to
complete the silicon initialization flow.
BUG=b:282266168
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2c9e37fadc27eab820a3121e47e09529de34d10e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75309
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
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>
Phoenix has one more Type C port and two more USB2 ports which are used
as the legacy USB part of the two USB4 ports. The USB struct version
numbers have also changed, since it's a newer and incompatible version
of that struct.
TEST=After changing FSP to not hard-code the USB PHY config, but use the
configuration provided by coreboot, and applying this patch, the USB
connector on the USB2 port 4 lines works.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If52934595dd612154b97e7b90dbd96243146017a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73379
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Before the bootblock stage starts setting up the CAR mode, it sends
`POST_BOOTBLOCK_CAR` POST code. However, before the definition for
`POST_BOOTBLOCK_CAR` was introduced in the commit
0d34a50a36 , the value `0x20` was used.
At that point, `0x20` means "entry into CAR mode" and `0x21` means
"the cache memory region is cleared". Right now we are sending the
same POST code twice, which makes no sense.
So we can do the following (todo: drop me after we decided which one is
more appropriate):
1) Drop it (current patchset does exactly that)
2) Introduce POST code similar to POST_SOC_CLEARING_CAR and use it
before the cache memory region is cleared.
Change-Id: I5d9014c788abdf5a4338c9e199138d1e514450b3
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Things with prompts should not use selects, but should instead default
to y. If there's a reason they need to be selected, they should be able
to be hidden when they're selected.
This isn't one of those cases where a select is needed, so set the
default to y instead.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If6de339c3a1ceb3cd71008402bba49b5efc4af3f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75131
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The SPD format in the APCB has changed for Phoenix, and the injection
tool 'apcbtool' needs to be updated to match. Until this happens, the
APCB will be built containing the correct SPD.
BUG=b:281983434
TEST=Build
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If575f98511c796e93c5a12cd450a3a7985e39806
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
This hook is specifically for asus/p3b-f so its mainboard code has
a chance to put SPD away after RAM init completes. What it intends
to do is done when GPO gets programmed in ramstage (and it's safe
to do so), and no other board needs this hook, so drop it.
Change-Id: Ib7874b4d2b69fdaa5f3c5a3421a62a629c4154a4
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Make ACPI code print a debug warning message when a timeout is
detected in a loop waiting for a condition.
This timeout message won't be displayed when this function is used as
delay loop (ie. without checking variable condition).
The following is required to get this log in kernel log buffer:
echo 1 > /sys/module/acpi/parameters/aml_debug_output
Here is an example of generated code when waiting for variable L23E to
be 0.
Local7 = 0x08
While ((Local7 > Zero))
{
If ((L23E == Zero))
{
Break
}
Sleep (0x10)
Local7--
If ((Local7 == Zero))
{
Debug = "WARN: Wait loop timeout for variable L23E"
}
}
BRANCH=firmware-brya-14505.B
TEST=Boot to OS and check that the Debug print is added to the
function.
Change-Id: I3843e51988527e99822017d1b5f653ff2eaa7958
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73348
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Some devices using the MAX98373a smart amp have the speakers connected
to port SSP2 vs the default SSP1, so add a configuration item to be
able to specify that.
TEST=tested with rest of patch train
Change-Id: I11d8011c54946aa72a83c73fa88456b4bb5d7d95
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75231
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both the AMD AGESA reference code and the default coreboot
ACPI_CPU_STRING use hexadecimal numbers in the ACPI CPU object names, so
change the ACPI_CPU_STRING format string in the both the Stoneyridge
Kconfig and the common non-CAR AMD SoC config Kconfig which covers all
other AMD SoCs in soc/amd. All platforms where the P state and C state
SSDT from binaryPI (Stoneyridge) or FSP (Picasso) was used in coreboot
before it got replaced by native code, had at most 8 cores/threads, so
the mismatch never became apparent.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9d6822c5df01786ee541ce90734b75ed1a761fca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75250
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the chromeec driver to use the EC host command API. Large blocks
of repetitive code to set up EC calls are replaced with single function
calls to perform the same operation.
BUG=b:258126464
BRANCH=none
TEST=booted on rex
Change-Id: I0317405b1ed0c58568078133c17c8cfbc7c21d80
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73325
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The new util/chromeos/update_ec_headers.sh utility is used to update
ec_commands.h and introduce ec_cmd_api.h from the chrome EC repo.
ec_cmd_api.h is a new file from the chrome EC repo which defines the API
for communicating with the EC. It is a companion to the existing
ec_commands.h by defining functions corresponding to EC host command
opcodes and request/response struct definitions.
See $EC/docs/ec-host-command-api.md for details.
Generated using update_ec_headers.sh [EC-DIR].
The original include/ec_commands.h version in the EC repo is:
3e35858003 ec: Add another #line directive
The original include/ec_cmd_api.h version in the EC repo is:
59de61f2db zephyr: Add support for RNG devices
BUG=b:258126464
BRANCH=none
TEST=none
Change-Id: I30f20e34d31b7e19cf03f65fefd58ae64eef1d41
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73324
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a new utility for copying ec_commands.h and ec_cmd_api.h from
the chrome EC repo with the appropriate copyright header adjustment.
It is invoked as:
util/chromeos/update_ec_headers.sh [EC-repo]
where EC-repo is the top of the EC repo from which header files are to
be obtained.
The corresponding files in src/ec/google/chromeec are updated but not
committed. Also, a commit message is suggested with the original git
versions for reference.
BUG=b:258126464
Change-Id: Ib43c75d807dd925b2c4bff425c07a36b4b4582c4
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Traditionally, display init during vboot "verified/secure/normal
boot mode" relies on the VB2_CONTEXT_DISPLAY_INIT. This is the
default behavior for vboot, meaning skip display init during verified
boot mode.
However, if the intention is to show the OEM splash screen (using
BMP_LOGO config) during boot, then the policy enforced by vboot needs
to be overridden. This can be done by setting the BMP_LOGO config flag.
If BMP_LOGO is not enabled, then the vboot policy will be followed and
display init will be skipped.
This change was made to allow OEMs to show their splash screen during
boot, even if the system is in verified/secure/normal mode.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ice1f02ad5c02a6a7e74a97ed23c5f11c7ecfb594
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75197
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Generate formatted string and ACPI code to print debug string.
For example (with pcie_rp = 1):
acpigen_write_debug_sprintf("calling _ON for RP: %u", pcie_rp);
generates the following ACPI code:
Debug = "calling _ON for RP: 1"
With this new function, the following functions are not needed anymore
and therefore are removed by this patch.
- acpigen_concatenate_string_string()
- acpigen_concatenate_string_int()
- acpigen_write_debug_concatenate_string_string()
- acpigen_write_debug_concatenate_string_int()
BRANCH=firmware-brya-14505.B
TEST=Add above functions in the acpigen code and check the generated
SSDT table after OS boot. Check the debug messages is in the
kernel log when /sys/modules/acpi/parameters/aml_debug_output is
set to '1'.
Change-Id: Id4a42e5854516a22b7bc4559c2ed08680722c5ba
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-by: Musse Abdullahi <musse.abdullahi@intel.corp-partner.google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Fix the error below when running a coreboot image built with
`CONFIG_UBSAN=y`.
PCI: pci_scan_bus for bus 00
shift out of bounds src/arch/x86/include/arch/pci_io_cfg.h:13:20
ubsan: unrecoverable error.
GCC with `-fsanitize=shift` also flags this:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
So, make the constant unsigned.
TEST=emulation/qemu-i440fx with `CONFIG_UBSAN=y` stops later with
[ERROR] unaligned access src/lib/rmodule.c:152:27
[EMERG] ubsan: unrecoverable error.
Change-Id: Ib05d225ab9f22078d765009b4ee6ef0c63231eed
Found-by: UBSAN
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
By moving certain FW UI assets from RO to RW sections, 4 MiB is
sufficient for RO section. Split the resultant available 4 MiB equally
between 2 RW sections. This will help in getting to 16 MiB SPI flash for
the mainboard.
BUG=b:281567816
TEST=Build Myst BIOS image with the updated layout.
Cq-Depend: chromium:4519688
Change-Id: I09948ceac0a6a1cb109322fc4856b8b486318664
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75184
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Update USB port macros:
- change onboard ports to SHORT: MYSTIC LIGHT, LAN_USB1, PS2_USB1,
HUB to USB 2.0 headers, HUB to rear USB 2.0
- change USB type C header to LONG which caused hard lockups on the
port making it unable to enumerate in UEFI Payload and Linux
- add empty definitions for USBr ports
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I91198aa713e9084ff3906c267ee1b37b10c71843
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69820
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Since it's not obvious, add comments to acpigen_resource_word,
acpigen_resource_dword and acpigen_resource_qword to clarify out what
the magic number in byte 0 means. The most significant bit of byte 0
indicates if it is a small or large resource data type. In the case of
the MSB being 0, it's a small resource data type (aka type 0), and the
other bits encode bit the type and size of the item; if the MSB is 1,
it's a large resource data type (aka type 1), and the other bits just
encode the type and there are two separate bytes to encode the size.
Beware that the large resource's data type values in the ACPI
specification don't include the MSB that's set, but only the 7 lower
bits.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia6a6c9fb1bcde232122bb5899b9a0983ef48e12b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The detachable Starmie will use MIPI panels, which require reading
serializable data from the CBFS. So we add MIPI panel support to the
display configuration and align the configuration sequence with the
panels that use MIPI bridges.
The PMIC Datasheet:
TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:275470328
BRANCH=corsola
TEST=emerge-corsola coreboot chromeos-bootimage and display normally
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I6f079e54f0317ff2f685f0e3834ebd1ceb8e9fcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Error message ´Cannot map compressed file config without cbfs_cache' is reported.
Compressed parts of CBFS can not be used during bootblock stage.
Remove config from mb_log_list.
Will be added to verified items by CB:74752.
BUG=NA
TEST=booting and verify log on facebook FBG1701
Change-Id: Iacf023bc8b9c2ebc66137c4ea683589751a30d2f
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add _STA field entry for r8168 ACPI device and set to
ACPI_STATUS_DEVICE_HIDDEN_ON in order to hide device from
OS (Windows) as there is no driver needed (or available).
Windows correctly attaches drivers to the PCIe device, the
separate ACPI device is unused and unneeded.
Linux is unaffected as it does not use the ACPI device status.
Change-Id: Ib7ae99fffcb00e71421b93c2794119841aa239d3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75177
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adjust the touchpad HID/CID/HRV to allow coolstar's crostouchpad
Windows drivers to properly attach. Change the interrupt type
from EDGE to LEVEL.
TEST=build/boot samsung/lumpy, verify touchpad functional under
both Windows 10/11 and Linux, verify Windows overlay driver
correctly remaps top row keys.
Change-Id: Ie4268b4de5779ee148699c7bef8c700a99816f1e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Adjust the touchpad HID/CID/HRV to allow coolstar's crostouchpad
Windows drivers to properly attach.
TEST=build/boot google/parrot, verify touchpad functional under
both Windows 10/11 and Linux, verify Windows overlay driver
correctly remaps top row keys.
Change-Id: Ic164244eceb52221653bd60f7217f9a09e38c1b6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75180
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adjust the touchpad HID/CID/HRV to allow coolstar's crostouchpad
Windows drivers to properly attach. Change the interrupt type
from EDGE to LEVEL.
TEST=build/boot google/butterfly, verify touchpad functional under
both Windows 10/11 and Linux, verify Windows overlay driver
correctly remaps top row keys.
Change-Id: I971795becfb05fb42921ff6f40a20892f4f5654a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75179
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use board-specific ASL for PS2-attached trackpad rather than the EC/SIO
default, so that Windows installs a multitouch-capable driver rather
than the standard PS2 mouse driver.
TEST=build/boot Win11 on google/stout, verify trackpad is multitouch
capable.
Change-Id: Id93bbe53f35b1e2c35e36d8175889786b9f5de8b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75176
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In ACPI 1.0 the processor objects were inside the \_PR scope, but since
ACPI 2.0 the \_SB scope can be used for that. Outside of coreboot some
firmwares still used the \_PR scope for a while for legacy ACPI 1.0 OS
compatibility, but apart from that the \_PR scope is deprecated.
coreboot already uses the \_SB scope for the processor devices
everywhere, so move the \_SB scope out of the ACPI_CPU_STRING to the
format string inside the 3 snprintf statements that use the
ACPI_CPU_STRING.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I76f18594a3a623b437a163c270547d3e9618c31a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Don't set bit 2 of the return value of the _STA method in order for
Windows not to show a warning about an unknown device in the device
manager for this device.
TEST=The unknown device with device instance path ACPI\AMD0040\3
disappeared from the device manager in Windows 10 build 19045 on a
Mandolin board with a Picasso APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If005f06843956004c281fd70cf364171148cb9ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68962
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
VMX is enabled through a bit in the IA32_FEATURE_CONTROL MSR, which can
be locked. The MSR remains locked after a non-power cycle reset, though.
If the MSR is locked, coreboot bails out and leaves VMX in the state it
was found. Because of this, changes to the VMX enable option in the BMC
only take effect after the system is power cycled.
This behaviour is highly undesirable because users are likely not aware
that a power cycle is required for changes to VMX state to take effect.
So, if VMX is supported, the IA32_FEATURE_CONTROL MSR is locked and the
current VMX state does not match the requested state, then issue a full
reset. This will power cycle the system and unlock the MSR, so that the
desired VMX state can be programmed into the MSR. This is checked early
to avoid needlessly doing time-consuming operations (running FSP) twice
if we know we will need to power cycle the system anyway.
Note that a user may change the VMX setting after the newly-added check
but before the setting is read in ramstage to program the MSR, but this
is a non-issue as firmware settings need a reset to take effect anyway.
TEST: Toggle VMX setting in BMC and reboot without power cycle, observe
coreboot automatically issues a power cycle reset because the MSR
is locked and the VMX state differs. Verify that the system boots
properly with VMX in the correct state after having power cycled.
Change-Id: Id9061ba896a7062da45a86fb26eeb58927184dcb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75141
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Instead of having the maximum number of possible CPU objects defined in
the DSDT, dynamically generate the number of needed CPU devices in the
SSDT like it's done on all other x86 platforms in coreboot.
TEST=APU2 still boots and Linux doesn't show any ACPI errors with this
patch applied and it prints "ACPI: \_SB_.P000: Found 2 idle states".
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6f057ad130a27b371722fa66ce0a982afc43c6c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73073
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Instead of having binaryPI generate a PSTATE SSDT that uses \_PR_ as the
scope for the CPU objects and patching this SSDT in coreboot to use the
\_SB_ scope in patch_ssdt_processor_scope, request binaryPI to use the
\_SB_ scope instead by setting the late platform configuration option
ProcessorScopeInSb to true.
TEST=APU2 still boots and Linux doesn't show any ACPI errors with this
patch applied and it prints "ACPI: \_SB_.P000: Found 2 idle states".
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I411201b55cfee30ae41da4e6814679bdb49e9bf7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73386
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This mainboard contains in addition to its base variant, mc_ehl2, an LCD
panel driven through the PTN3460 eDP-to-LVDS bridge.
This patch enables the PTN3460 support by adding the device to
devicetree.cb and board-specific configuration parameters in
lcd_panel.c.
BUG=none
TEST=Boot with the LCD panel attached and observe whether the picture is
stable and free of artifacts coming from wrong resolution and timing.
Change-Id: I196d7ceeb7ac241c9b95db2ef791a5f3ff7890a7
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The Realtek RTL8111F NIC is currently not defined at all, nor as a child
device, resulting in the on_board flag not being set to 1. This means
that Linux / udev will call the device enp3s0 rather than eno0, as it's
appropriate for on-board ethernet devices.
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: I95f01a466a59234d1cbe2420f208bf58ae28fcc6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Adds the option to set the 'DmaProperty' in the device's _DSD.
This can be done by setting "add_acpi_dma_property"="true". If not set
(or set to false), the device descriptor generation behavior will remain
unchanged. The naming convention for the config option was chosen to
match that of other drivers.
This partially reverts commit 5609f7a684 ("drivers/pcie/generic: Clean
up driver") as the driver is now used on a couple mainboards which need
the DmaProperty.
Change-Id: I996fe4923948d13a20bf8b6b1a93dab0866d0fd4
Signed-off-by: Mark Hasemeyer <markhas@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Create the gothrax variant of the nissa reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0.).
BUG=279614675
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_GOTHRAX
Signed-off-by: Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com>
Change-Id: I129e4a55e4b87091e425a45392024d04f3977c79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74748
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
The return value of cse_get_bp_info() is an enum integer, where zero
means success and non-zero means failure. The function
store_cse_rw_fw_version() calls the function cse_get_bp_info() and
validates the return value as a boolean causing prematurely returns of
the parent API even if cse_get_bp_info() is successful.
This patch corrects this logical error by returning only if
cse_get_bp_info() fails.
TEST=Build and boot google/nivviks and verify that the ISH version info
command is only being sent during cold boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ice278e5ac69ff2f2c9f1936b76d71ae9deb6f855
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74998
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
At present coreboot_rsdp remains unset for QEMU, which results in
an incomplete LB_TAG_ACPI_RSDP coreboot table generated.
Fix this by assigning coreboot_rsdp properly.
TEST=Build coreboot for QEMU x86 i440fx (default) with U-Boot x86
as the payload, boot coreboot.rom with QEMU, and run 'acpi list'
from U-Boot shell to show the ACPI tables.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Change-Id: I5bc3f0528d4431fd388ca52b8865f9be0e1faf92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
For the sequenced controlled shutdown path, there's a 10ms delay
after the PEXVDD rail is disabled to permit discharge needed on
Agah/Proxima.
This can be dropped to 3ms for Hades designs Proto0 and forward.
Once Agah board is dropped, "if CONFIG" can be cleaned up/removed.
BUG=b:271167335
TEST=builds
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: I8a0d62ec76caff861adce2d6c0ba2d4e4064affa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75051
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the introduction of a new Linux version a problem has appeared
after a software initiated reset via CF9h register. The problem
manifests itself in the fact that the Linux kernel does not start after
the reboot. The problem is solved by setting bit 3 to 1 in Reset Control
Register (I/O port CF9h). This leads to the fact that the PCH will drive
SLP_S3 active low in the reset sequence. It leads to the same behavior
as in commit 04ea73ee78 ("siemens/mc_apl3: Set Full Reset Bit into
Reset Control Register") explained.
Change-Id: Ia8b7f997ca6234add569da751e1070144790e258
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
- VBT information: The link from 01.org is dead, but appears to have
been identical to the i915 page in the Linux kernel docs based on
snapshots on archive.org.
- Cgit: coreboot no longer has cgit running for the repos it hosts,
and these links redirect to the Gitiles list of repos hosted on
review.coreboot.org. Based on snapshots on archive.org, these used
to link to the individual repo or tree. Replace these with an
equivalent Gitiles link.
Change-Id: Id0bfee7b806c851fbe1dcf357e14d9b593e8569a
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
If the ME is disabled with the `me_state` CMOS setting, boot
times are approximately 5 seconds longer:
942:before sending EOP to ME 1,240,773 (5,599)
943:after sending EOP to ME 6,263,951 (5,023,177)
Total Time: 6,167,443
This is because the current code only checks if the ME is
disabled for CSE LITE SKUs. With this patch, boot times are
approximately 5 seconds quicker:
Total Time: 1,143,932
Tested on `starbook/adl` and `starbook/tgl`.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I182f30d4fbf43955747c6a7a0b284a43f9c5e4ef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74435
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Update header files for FSP for Meteor Lake platform to version 3165_81, previous version being 3084_85.
FSPM:
1. Change UPD name from 'GtExtraTurboVoltage' to 'GtAdaptiveVoltage'
2. Change UPD name from 'CoreVoltageAdaptive' to 'CoreAdaptiveVoltage'
3. Change UPD name from 'RingVoltageAdaptive' to 'RingAdaptiveVoltage'
4. Address offset changes
FSPS:
1. Remove deprecated UPD 'PcieDpc'
2. Address offset changes
BUG=b:280005256
TEST=Able to build and boot google/rex to ChromeOS.
Signed-off-by: Kilari Raasi <kilari.raasi@intel.com>
Change-Id: I67939ecf71166fca4f3d2d6cd4622215bebc5718
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74803
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Based on feedback and experiences from new coreboot users, it isn't
clear that Tutorial 1 is mainly intended to set up the toolchain and
will not produce a bootable ROM for their board. Thus, add a note
explicitly mentioning this with a short explanation.
The process of manually building and adding the payload is also unusual,
since payloads are usually handled automatically by the build system.
This adds a note in the summary to provide an explanation of this.
The savedefconfig output is also outdated, as Kconfig now outputs
additional lines (even though many of those are the same as the
defaults). This has caused confusion, leading users to think that they
may have configured coreboot incorrectly. Update this to the current
defconfig contents and add a note that this may change depending on the
coreboot version.
Change-Id: I13206aa05a425ddfe33ee35feff0db490585a59f
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73816
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Linux kernel recently updated the wording of their sign-off
procedure, changing the ambiguous "real name" requirement to "a known
identity" and dropping "no pseudonyms". Anonymous contributions remain
uncommittable [1]. As discussed in the April 19, 2023 leadership
meeting, update our policy to go along with Linux and flashrom (who also
updated their policy).
[1] Linux kernel commit d4563201f3
(Documentation: simplify and clarify DCO contribution example language)
Change-Id: Ie676334f7c1509524adcb8dbb78495fb4da35ede
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently, this only exists on the old wiki and the developers.html page
on coreboot.org, but it really ought to be somewhere in the new docs
alongside the other contribution guidelines. This was largely copied
from the text from the developers.html page.
Change-Id: If50b3827ab36234719f9a90239caec4612eb6762
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74825
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>
Intel's EHL FSP offers the possibility to select the connected hard
drive type to SATA ports. One has the option to choose between HDD ('0'
- default) and SSD ('1').
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: Idb03aff5b6c5df592b47e2f4abe4fe58ac7151ba
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74946
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>
Assigning duty_offset while duty_width==0 has no purpose.
Under intel/common/block, previous assignment for fadt->gpe0_blk
resolves GPE0_STS(0) from xeon_sp/ebg/.../soc_pm.h and also assigns
value matching pmbase + 0x60.
Change-Id: Iaf688d9471ac527ac20307cf16216abdab731a06
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74827
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FSP-M is normally memmapped and then decompressed. The SPI DMA
controller can actually read faster than mmap. So by reading the
contents into a buffer and then decompressing we reduce boot time.
It is interesting that FSP-M takes an additional 8ms to execute. I
suspect since we call it 50ms earlier it's having to wait for one of
its dependencies.
BUG=b:179699789
TEST=Boot guybrush and see 30ms reduction in boot time
| 970 - loading FSP-M | 0.316 | 0.997 Δ( 0.68, 0.05%) |
| 17 - starting LZ4 decompress (ignore for x86) | 0.026 | 13.874 Δ( 13.85, 0.96%) |
| 18 - finished LZ4 decompress (ignore for x86) | 64.361 | 0.337 Δ(-64.02, -4.43%) |
| 2 - before RAM initialization | 0.534 | 0.529 Δ( -0.01, -0.00%) |
| 950 - calling FspMemoryInit | 1.455 | 1.132 Δ( -0.32, -0.02%) |
| 951 - returning from FspMemoryInit | 207.695 | 216.537 Δ( 8.84, 0.61%) |
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I850b1576501753a355e7b23745e04802a0560387
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Introduce acpigen_write_BBN to generate the ACPI method object that
returns the base bus number for a PCI(e) host bridge. When called, the
base_bus_number argument must be the first PCI bus number that got
assigned to the corresponding host bridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib67bf42b9c77c262d8a02d8f28ac5cb8482136b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
There are 2 regex patterns defined to process the lines from *fw.cfg:
1) for lines with mandatory entries
2) for lines with mandatory + optional entries
Consolidate the regex pattern. Add enums for matching regex caller
groups so that the human readable group IDs can be used instead of magic
numbers.
BUG=None
TEST=Build Skyrim BIOS which only have mandatory entries. Build Guybrush
BIOS image which have both mandatory and optional entries. Confirm that
the amdfw.rom built before and after this change have matching SHA in
both Skyrim and Guybrush images. This ensures that the optional level
entries in Guybrush are handled as expected. Boot to OS in Skyrim.
Change-Id: I7289ddbbec4d5daefe64f59b687ba3a4af46d052
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
For early Sign of Life to work, we may need certain pin configurations
very early in boot (e.g. HDMI). This may happen before romstage GPIOs
are configured, and bootblock is not suitable for field upgrading
existing devices. Add a separate GPIO table that can be configured
when early graphics is invoked.
BUG=b:277861633
BRANCH=firmware-brya-14505.B
TEST=Builds and SoL functions on HDMI enabled variants
Change-Id: I7b3ce96a4166451e72aa70b3086eff3fb8b082b7
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Allow different gma-mainboards configs for different baseboards
as they support varying display interfaces. Set Brya to eDP only
and Brask to HDMI only.
BUG=b:277861633
BRANCH=firmware-brya-14505.B
TEST=Builds and SoL functions on both brya and brask varaints
Change-Id: Iaf3f35b009d53e50723e4aa82c0f4932783f9bb9
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Add _PLD support to GFX device so that each display output can store
its physical location of connection point. This is to be used primarily
for describing DP on USB-C ports in the future patches.
The upstream Linux kernel now has a feature to compare _PLD of Type C
connectors and DP connectors to link them together.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=c5c51b2420625faa1f0e363f21dba1de53806ff7
This feature allows us to tell which display output is used by which
USB-C port.
So, for the future boards, we want to add _PLD for each DP connector
matching with the corresponding USB-C port.
BUG=b:277629750
TEST=emerge-${BOARD} coreboot
Signed-off-by: Won Chung <wonchung@google.com>
Change-Id: I393207746a9e82c1fd7622ab3661d7b1232cb62f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch adds some of the variety of configuration options exported
by the Pericom Inc. PI7C9X2G608GP PCIe switch over its SMBus interface.
Currently implemented options are only used to adjust the switch
upstream port amplitude and de-emphasis levels in millivolts. Only
values specified in the switch datasheet (in tables 6-6 and 6-8) are
allowed.
Example of a devicetree.cb entry:
chip drivers/i2c/pi608gp
register "gen2_3p5_enable" = "true"
register "gen2_3p5_amp" = "AMP_LVL_MV(425)"
register "gen2_3p5_deemph" = \
"DEEMPH_LVL_MV(37, 5)"
device i2c 0x6f on
ops pi608gp_ops
end
end
Link to the datasheet:
https://web.archive.org/web/20210225074853/https://www.diodes.com/assets/Datasheets/PI7C9X2G608GP.pdf
BUG=none
TEST=Create devicetree.cb and Kconfig entries for this driver
in a mainboard containing the switch and verify, that the values read
out from the switch config space match the values programmed over the
SMBus.
Change-Id: Id191c4e97b99da58efd3ba38bf8cca3603ece4d5
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates
that the device should be shown in the user interface. This ports commit
c259d71928 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS")
back from Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5e724292431be7f7c2a0b6678b426831e3c19154
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74990
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates
that the device should be shown in the user interface. This ports commit
c259d71928 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS")
forward from Stoneyridge to the newer AMD SoCs.
TEST=On Mandolin the PCI Express Root Complex now shows up in the device
manager on Windows 10 and when switching the view to 'devices by
connection', all PCI(e) devices are shown below it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the PRERAM_CBMEM_CONSOLE_SIZE and
CONSOLE_CBMEM_BUFFER_SIZE hold a larger cbmem buffer size to contain
the entire FSP debug serial log.
The existing implementation was not appropriate, where the larger cbmem
size was even applicable for serial AP firmware (w/o FSP debug) image
as well.
This change is necessary to ensure that the FSP debug serial log is
always available, even in cases where the cbmem buffer size is
limited.
BUG=b:280481298
TEST=Able to build and boot google/rex with non-FSP serial AP image
and with FSP serial AP image. Able to see the AP log completely inside
the cbmem.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib35780fd558c8b6d9aa2e17241131ea4a58c2b9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
While Chromebook hardware originally would not have the
capacity to do suspend-to-disk (ACPI S4), the power management
code in EC should react to S4 request as if it was S5 request.
Change-Id: Ida9118919c8149d94f470847d0c4aad9c0b97d3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch makes CSE sync in romstage default enabled unless ramstage
config (SOC_INTEL_CSE_LITE_SYNC_IN_RAMSTAGE) chooses to override it.
TEST=Able to build google/marasov with this change where CSE sync is
performed early inside romstage.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3f5017fbcf917201eaf8233089050bd31c3d1917
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74805
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Use the OEM ID from CBI to determine the correct OEM board name.
ID mapping taken from ChromeEC source, branch firmware-fizz-10139.B.
TEST=build/boot multiple fizz variants, check that board name reported
correctly in SMBIOS tables.
Change-Id: I06251974ac73570b911920ed566a175e8e733710
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
DSM (Dynamic Speaker Management) uses calibration parameters stored in
a VPD (Vital Product Data) FMAP region to configure the audio output
via an ACPI _DSD table. This has no dependency on a ChromeOS, and can
be used by Linux/Windows drivers if appropriately configured.
Remove the dependency of DSM_CALIB (and the calibration file) on
CHROMEOS and replace it with VPD, so that non-CHROMEOS builds
can utilize this feature as well. Move files from underneath
vc/google/chromeos to underscore the point.
TEST=build/boot google/nightfury, dump ACPI, verify DSM calibraton
parameters present in _DSD table.
Change-Id: I643b3581bcc662befc9e30736dae806f94b055af
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Commit cbc5d3f34b ("soc/intel: Don't
report _S1 state when unsupported") added the `ACPI_S1_NOT_SUPPORTED`
option and commit 0eb5974def ("acpigen:
Add a runtime method to override exposed _Sx sleep states") added a
mechanism to override the enabled sleep states at runtime. However,
these were only hooked up to Intel sleepstates. so the options would
not have any effect on AMD platforms.
Apply the changes from these two commits to AMD sleepstates so that
both options can be used on AMD platforms as well.
Change-Id: I7d5ef2361e36659ac5c6f54b2c236d48713a07c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74959
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure the SuperIO and logical devices in the device tree. This
overrides the power-on default state.
UART1 was already enabled, and if ENABLE_EC_UART1 was selected in
Kconfig, the LPC UART1 I/O range was also already enabled.
The RTC/BRAM interface was enabled (and the BRAM1 base was 0x360 by
default), but the LPC I/O range was not opened previously. Now it is
open and BRAM bank 1 is accessible.
Mouse/Keyboard are not wired to anything on this board and are now
disabled.
UART2, SMFI, power channel 1, and power channel 2 were enabled
previously, but their LPC I/O ranges were not opened and they were not
accessible to the OS. Fan control is performed by the EC on this board
so there is no change.
SWUC and power channels 3-5 were disabled by default, no change.
Change-Id: I58a5a427737f4a2caa64326c110eb53ec00b347d
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74369
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
variant_board_sku() is missing dependences in order to work correctly
in romstage. Rather than more intrusive rework as its use is limited,
move the FPMCU early GPIO init back to ramstage. We still meet
sufficient power off time to fully power cycle the MCU.
BUG=b:245954151
TEST=Confirmed FPMCU is still functional on Nami and FP tests all pass
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: Ia428ec5aec1a0438e91bc48903bda043046b740e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74695
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add SOF chip driver entries for all variants, so that the correct audio
config is passed to the OS drivers.
TEST=build, boot Windows on wyvern variant, verify headphone output
and microphone functional under Windows using coolstar's SOF drivers.
Change-Id: I421c070eac321c2fc160b8f26868bcb1ec13001e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74815
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Add all SOF chip drivers to baseboard and use FW_CONFIG to determine
the correct option, to ensure the correct audio config is passed to the
SOF OS drivers.
TEST=build, boot Windows on several dedede variants, verify audio
functional under Windows using coolstar's SOF drivers.
Change-Id: I9452b11af614d8727aa8dd448e37f7a06faa450d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74818
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Now that we don't need to find a specific resource in the set resources
function any more, there's no need to use hard-coded indices for the
fixed resources. Instead use an index variable that gets incremented
after each fixed resource got added. The index now starts at 0 instead
of at 1, but now the only requirement is that those indices are unique.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ida5f1f001c622da2e31474b62832782f5f303a32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74849
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Remove explicit PNP 6e.1 configuration for UART. This had no effect,
the SuperIO is actually on I/O port 2e. Enabling the 8250IO driver is
sufficient to use the UART, the UART device is enabled by default.
Test: Build Mini v2 with and without CONFIG_ENABLE_EC_UART1, boot and
check output on serial.
Change-Id: Idbb39c81cadd633f4718f0682d231dc578d20325
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74362
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the custom lpc_set_resources implementation that does some register
access that has no effect and then calls pci_dev_set_resources and use
pci_dev_set_resources for set_resources in amd_lpc_ops instead.
The SPI controller's base address got configured early in boot in the
lpc_set_spibase call and the enable bits got set early in boot in the
lpc_enable_spi_rom call.
TEST=The contents of the SPI_BASE_ADDRESS_REGISTER at the beginning and
at the end of the call stay the same, so it's simply a no-op.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7a5e3e00b2e38eeb3e9dae6d6c83d11ef925ce22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since the 16MByte of memory-mapped SPI flash region right below the 4GB
boundary is both a fixed region and isn't decoded on a device below the
LPC device, but assumed to be decoded by the LPC device itself, it
shouldn't be reported as a subtractive resource, but as an MMIO resource
instead.
TEST=On mandolin the 16MByte MMIO-mapped SPI flash now show up as a
reserved region in the e820 memory map which wasn't the case before:
13. 00000000ff000000-00000000ffffffff: RESERVED
The Linux kernel doesn't show any new or possibly related errors.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: Ib52df2b2d79a1e6213c3499984a5a1e0e25c058a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add a new chip driver for boards which use SOF (Sound Open Firmware)
OS drivers, which will be attached to the HDAS device and generate
entries in an ACPI _DSD table for the OS driver to use. This will allow
the OS drivers to easily determine the correct topology for the speaker
and jack amplifiers and correct microphone configuration.
TEST=tested with rest of patch train
Change-Id: Ie0431b2002287f35245cbf959828e931d7f375b2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Now that MrChromebox's default edk2 branch supports Secure Boot, add a
Kconfig to enable it, and do so by default when MrChromebox's branch
is used and SMMSTORE_V2 is enabled (which is a prerequisite).
TEST=build/boot google boards link, panther, lulu,reef, ampton, akemi,
and banshee, verify Secure Boot options available in payload, Secure
Boot status reported properly by Linux/Windows.
Change-Id: I4be58c3315cabe08729d717c59203fdc6a3e2958
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74869
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the default branch used for MrChromebox's edk2 fork from 2022-07
to 2023-04. This updated branch has been rebased on the latest upstream
stable tag (edk2-stable202302), and adds support for UEFI Secure Boot and
TPM 1.2/2.0 management (though it does not currently support Google
CR50/Ti50 TPMs).
TEST=build/boot google boards link, panther, lulu,reef, ampton, akemi,
and banshee with edk2 payload selected.
Change-Id: I096eaa4e065db731a70ba238ba5a3bb49e5db867
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74868
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
At present the problem has only been reported with Alder Lake and
Raptor Lake FSP where MultiPhaseSiInit API is unable to return any ERROR
status. Hence, this patch ensures to select applicable W/A config to
read FSP return status from the FSP Reset HOB.
BUG=b:278665768
TEST=Able to select FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN for ADL/RPL SoC
code and call into this API to know the return status from
MultiPhaseSiInit FSP API.
Without this patch:
IshInit() Start
IshDisable() Start
IshPerformGlobalReset()
....
....
FSP returning control to Bootloader with reset required return
status 40000003
FspMultiPhaseSiInit Index-1 returned 0 <-- after control returns
into coreboot, the `status` from the FSP API is reset to `0`
instead 0x40000003. Hence, coreboot avoid hitting the reset.
With this patch:
IshInit() Start
IshDisable() Start
IshPerformGlobalReset()
....
....
FSP returning control to Bootloader with reset required return
status 40000003
FSP: handling reset type 40000003 <-- coreboot is able to understand
the reset request in proper.
GLOBAL RESET!
global_reset() called!
HECI: Global Reset(Type:1) Command
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I18a918cca7e19e03ed6020c55c86c64a94212963
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74785
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch calls into fsp_get_pch_reset_status() to get the
MultiPhaseSiInit API return status if
FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN is enabled.
Ideally FSP API should be able to return the status (both success and
error code) upon exiting the FSP API but unfortunately there are some
scenarios in ADL/RPL FSP where MultiPhaseSiInit API is unable to return
any ERROR status. Hence, this function can be considered as an
additional hook to read the FSP reset status by reading the dedicated
HOB without relying on the FSP API exit status code.
Any SoC platform that selects the FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN
config will call into this newly added API to get the FSP return status
from MultiPhaseSiInit.
BUG=b:278665768
TEST=Able to select FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN for ADL/RPL SoC
code and call into this API to know the return status from
MultiPhaseSiInit FSP API.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I749c9986e17e4cbab333b29425c9a4a4ba4128fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74784
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
This patch creates a function to read the FSP API Reset Status. This
function relies on the FSP Scheduled Reset HOB which holds the reset
type (warm/cold/shutdown) information along with any platform specific
reset need (like global reset).
Ideally FSP API should be able to return the status (both success and
error code) upon exiting the FSP API but unfortunately there are some
scenarios in ADL/RPL FSP where MultiPhaseSiInit API is unable to return
any ERROR status. Hence, this function provides an additional hook to
read the FSP reset status by reading the dedicated HOB without relying
on the FSP API exit status code.
Additionally, create FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN config option
to handle broken FSP API return status issue.
Any SoC platform that selects the `FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN`
config will call into this newly added API to get the FSP return status
from MultiPhaseSiInit.
BUG=b:278665768
TEST=Able to select FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN for ADL/RPL SoC
code and call into this API to know the return status from
MultiPhaseSiInit FSP API.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ief5d79736cc11a0a31ca2889128285795f8b5aae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
There is no platform-level implementation for USB port power management
in various sleepstates. This mainboard never evaluates the set GNVS
variables S3U0, S3U1, S5U0 and S5U1 in ASL or in its SMI handlers.
Change-Id: Ic7af2d608d95c6691f31ef1b8af72f96da20787c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There is no platform-level implementation for USB port power management
in various sleepstates. The mainboards changed here never evaluate the
set GNVS variables S3U0, S3U1, S5U0 and S5U1 in ASL or in their SMI
handlers.
Change-Id: Ia1bc5969804a7346caac4ae93336efd9f0240c87
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Add data.vbt files for all variants supported by current volteer
recovery image. Several boards use the same VBT, so place the "common"
VBT under the baseboard directory and set it as the default.
For variants with a unique VBT, override the default and use the file in
their respective variant directory. Select INTEL_GMA_HAVE_VBT for all
variants which have a VBT file.
TEST=build/boot various volteer variants
Change-Id: I728ab81938c78f600ff8931a8073d1f7de152c09
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74852
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These were hidden because no Windows drivers existed, but now that
they do, the ACPI devices need to be visible in order for the
drivers to properly attach.
TEST=build google/drobit, boot Windows, verify Windows drivers
correctly attach to PCM/IOM devices.
Change-Id: I1520a71e318674baa234fc6a2126d1d17933d983
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
In order for Windows to detect/load drivers for any child devices,
the PCI0 root device status must be enabled and visible.
TEST=build google/liara, boot Windows, verify PCI child devices
visible in Device Manager.
Change-Id: I3fb1ba11247f0811120a4cf8a4fd99342ae201de
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The change 'commit Iac37aaa5ede5e1cd ("Add Kconfigs to indicate
when CSE FW sync is performed")' adds support to choose CSE FW update
to be performed in ROMSTAGE or RAMSTAGE. The patch also introduced a
dependency on ME_RW firmware compression.
This patch removes the dependency between CSE FW sync in RAMSTAGE and
ME_RW firmware compression as these two are not related and should be
decoupled to support CSE FW sync in RAMSTAGE without the requirement
to compress ME_FW.
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I5ca4e4a993e4c4cc98b8829cbefff00b28e31549
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74796
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
cbfs_map() can allocate memory, so cbfs_unmap() should be
called before leaving the function.
BUG=b:278264488
TEST=Built and run with additional debugs on Skyrim device
to confirm that data are correctly unmapped
Change-Id: Ibf7ba6842f42404ad8bb415f8e7fda10403cbe2e
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Camera LED will blink several times as sensor is being probed during kernel boot.
Configure _DSC to ACPI_DEVICE_SLEEP_D3_COLD so that driver skips
initial probe during kernel boot and prevent privacy LED blink.
BUG=b:274634319
TEST=Build and boot on Craask. Verify & observe Camera LED blinking behavior.
Change-Id: I78ed5efe1e2c071d817c1e0455271886e89e63c7
Signed-off-by: Jimmy Su <jimmy.su@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74728
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The support for a spd.bin from CBFS was removed for all mc_ehl boards in
commit 833bb448c5 (mb/siemens/mc_ehl: Remove spd.bin from CBFS).
There is still a remaining comment in romstage_fsp_params.c referring to
the removed capability. This fix removes the spd.bin related part of the
comment to stay consistent with the code.
Change-Id: I669ee1c33d1d1c47764640982f71129195e63f14
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74801
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
With the profile ATLAS_PROF_REALTIME_PERFORMANCE it is desired to not
have the option to be able to enter sleep. The reason is that Microsoft
Windows goes to sleep after 30min of inactivity by default.
TEST: See that Microsoft Windows 11 has no 'Sleep' option in the start
menu.
Change-Id: I424db7e712a705c628aa3a10a486d3313404987a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74421
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
FADT duty_width/duty_offset fields, together with P_CNT (previously
P_BLK) IO address are provided with _PTC entry.
FADT p_lvl2/3_lat fields had values that disabled C2/C3 state
transitions so _CST entries are not required.
Change-Id: I629cd0793f6a64e955e197400efaa7d9d898e775
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add functionality to ensure that the FPMCU is power cycled long enough
on boot to ensure proper reset.
This solution relies solely on coreboot to sequence the power and reset
signals appropriately (150ms on boot).
-Confirmed power is off for 150ms on boot.
-Confirmed RCC_CSR of FPMCU indicates power cycle occurred.
-Confirmed reset is de-asserted approx 3ms after power application
(target >2.5ms)
BUG=b:245954151
TEST=Confirmed FPMCU is still functional on Nami and timings are
as expected.
Change-Id: I0a23bda96bc2ea90be81a2310605f75c55c0a839
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY
that points to same offset. Since the century field inside
RTC falls within the NVRAM space, and could interfere with
OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY.
There were no reference for the use of offset 0x48 for century.
Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Some of the chip.h files in the tree are missing the include guards.
This patch adds them in order to avoid potential redefinions of symbols
contained in these headers, when they are included multiple times in
static.c generated by sconfig.
Change-Id: I550a514e72a8dd4db602e7ceffccd81aa36446e3
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
VGA defined the extended ASCII set based on CP437, but the function
vga_write_text() accepts a signed char array.
This will cause unnecessary confusion that if we want to print u with
umlaut (code=129 in CP437), we need to explicitly cast it to -127 in
signed char.
Since we still want to leverage the built-in string utilities
which only accepts const char*, we still need to cast it to signed char
while processing, and cast it back to unsigned once we write into the
frame buffer.
BRANCH=brya
BUG=b:264666392
TEST=emerge-brya coreboot chromeos-bootimage
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: If555bbc05f40ce3f02339c0468afff6dda8b7ded
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
walkcbfs_asm is a simple CBFS implementation in assembly to find a file
on a system with memory-mapped SPI flash. It seems to be mostly unused
nowadays and is only still called for early microcode loading on some
old systems (e.g. FSP 1.1 and older).
Using this implementation with CONFIG_CBFS_VERIFICATION is unsafe
because it does not verify the hashes the way the normal CBFS code does.
Therefore, to avoid potential security vulnerabilities from creeping in,
this patch makes sure the code cannot be compiled in when
CBFS_VERIFICATION is active. That means it won't be supported on the old
boards using this for microcode loading.
Ideally CONFIG_CBFS_VERIFICATION should have a `depends on` to make this
dependency more obvious in menuconfig, but the configs actually using
this code are not easy to untangle (e.g. CONFIG_MICROCODE_UPDATE_PRE_RAM
is just set everywhere by default although only very few boards are
really using it, and a lot of different old Intel CPU models are linking
in src/cpu/intel/car/non-evict/cache_as_ram.S without being united under
a single Kconfig so that's not easy to change). To keep things simple,
this patch will just prevent the code from being built and result in a
linker error if a bad combination of Kconfigs is used together. Later
patches can clean up the Kconfigs to better wrap that dependency if the
affected boards are still of enough interest to be worth that effort.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I614a1b05881aa7c1539a7f7f296855ff708db56c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74243
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
which is based on Intel Sapphire Rapids Scalable Processor chipset
which was product launched on Jan. 10 2023.
The site-local/* files are Intel binaries that are not published yet
but coreboot build validation system would skip these binaries when
they are in "site-local" directory.
Please make sure you have the correct Intel binaries for your AC CRB
and place them to the right location accordingly.
CONFIG_PAYLOAD_FILE="site-local/archercity/linuxboot_bzImage" is
LinuxBoot payload, there are several ways to build it, one way is to
build it from the x86_64 qemu example from osf-builder:
git clone https://github.com/linuxboot/osf-builder
cd examples/qemu; make kernel
commit ae90fc0bb (soc/intel/xeon_sp/spr: Default to X2APIC support)
would enable DEFAULT_X2APIC_RUNTIME, your LinuxBoot kernel needs to
enable X2APIC support, otherwise need to set CONFIG_XAPIC_ONLY=y in
your defconfig.
Change-Id: I15aefc3edb2d22fc00d854850e948fe2048a992e
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71969
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MIPI panels will be used on the detachable variant starmie, and
there will be different MIPI panels used on starmie. In order to make
the different panels functional on unprovisioned devices, it needs
to pass the SKU ID and panel ID to the payload to load the matched
device tree for kernel. From the schematic, the starmie variant
will read the LCM ID from ADC channel 5.
BRANCH=corsola
BUG=b:275470328
TEST=boot starmie and see FW screen display
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I6339dc3c177fb8982f77fb3bd32dc00da735fce4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74135
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: cong yang <yangcong5@huaqin.corp-partner.google.com>
Match-any-character operators (eg. ".*") shall not match newline
characters for BANNER_REGEX, since given regular expression
matches newline explicitly.
Add REG_NEWLINE flag to `regcomp` call.
BUG=b:278718871
TEST=Boot firmware on skyrim, reboot.
Run `cbmem -2`.
`cbmem -2` returns second-to-last boot log.
Change-Id: I9e924349ead0fa7eea8b9ad5161138a4c4946ade
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch implements helper function get_cse_ver_from_cbfs() to
retrieve the CSE Lite version from CBFE RW's metadata and calls
the helper function from cse_check_update_status()
TEST=Verified CSE Lite version in coreboot boot log
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Change-Id: Ie1bf186adfc3f87826a7ce9b0167a6bbe6767299
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74755
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
By default, coreboot includes support for all the different types of SPI
ROMs. Excluding the unused ROM types shrinks ramstage by almost 4k.
BUG=b:267735039
TEST=Build & Boot ROM
BRANCH=Skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If6e402269d1f2cac8256d478eb36743441497bdf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72769
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Commit c7b8809f155a ("soc/amd/common/block/gfx: Use TPM-stored hash
for vbios cache validation") replaced checking the vbios signature
(first two bytes) with checking against a TPM-stored hash, but there
exists an edge case where the empty cache can be hashed and therefore
never updated with the correct vbios data. To mitigate this, re-add
the signature check to ensure that an empty cache will never be hashed
to TPM.
BUG=b:255812886
BRANCH=skyrim
TEST=build/boot skyrim w/selective GOP enabled, flash full firmware
image, ensure GOP driver is run until cache updated with valid data
and hashed to TPM.
Change-Id: Id06a8cfaa44d346fb2eece53dcf74ee46f4a5352
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
In order to make supported sleep states a runtime configuration option
use a variable. A follow-up patch will implement updating this variable
based on an SSDT generated IntObj.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6910c2c75e668e6f75a6f431813edeb59d52dd93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Since skylake Intel hardware does not support this sleep state. Trying
to enter S1 by having the OS enter sleep results in a system hang on at
least Alder lake (prodrive/atlas).
CONFIG_SOC_INTEL_COMMON_BLOCK_PMC is a good proxy whether devices
support 'skylake style' PMC PCI device for ACPI registers.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic9e19410696240755e8714db53a0525284f3a2da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Since mc_ehl4 was only a copy of mc_ehl1 in a first step, the default
value of the Kconfig switch EARLY_PCI_BRIDGE_FUNCTION must be set to
'0'. On this mainboard NC FPGA is connected to PCIe root port #1
(00:1c.0).
Change-Id: I15035523d8575d486c3f2d0ffe3916712ee89d7d
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Add Kconfig COMMON_ACPI_MADT_IOAPIC to replace platforms'
implementations of adding IOAPIC and IRQ override entries
for ACPI MADT tables.
Platforms that have a more complex MADT may continue to
add custom entries using CUSTOM_ACPI_MADT.
Change-Id: I0b77769f89cc319ad228eb37bc341e2150b8a892
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74348
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
According to ACPI Release 6.5 systems supporting PIC (i8259)
interrupt mechanism need to report IRQ vector for the SCI_INT
field. In PIC mode only IRQ0..15 are allowed hardware vectors.
This change should cover section 5.2.9 to not pass SCI_INT
larger than IRQ15. Section 5.2.15.5 needs follow-up work.
Care should be taken that ioapic_get_sci_pin() is called
after platform code has potentially changed the routing
from the default.
It appears touched all platforms except siemens/mc_aplX
currently program SCI as IRQ9.
Change-Id: I723c207f1dcbba5e6fc0452fe1dbd087fad290ee
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Adding EC_HOST_EVENT_PANIC to SCI mask allows the EC to interrupt the
Kernel when an EC panic occurs. If system safe mode is also enabled
on the EC, the kernel will have a short period to extract and save info
about the EC panic.
BUG=b:268342532
BRANCH=firmware-octopus-11297.B
TEST=Observe kernel ec panic handler run when ec panics
Signed-off-by: Rob Barnes <robbarnes@google.com>
Change-Id: I37e566e459f39f8bc2dafc3c3915260259730ca6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
These strings are now only expanded in lib/identity.c.
This improves ccache hit rates slightly, as one built object file
lib/version.o is used for all variants of a board. Also one built
object file lib/identity.o can become a ccache hit for successive
builds of a variant, while the commit hash changes.
Change-Id: Ia7d5454d95c8698ab1c1744e63ea4c04d615bb3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In the PPRs #57019 Rev 3.03 and #57396 Rev 3.04, SMITYPE_XHC3_PME,
SMITYPE_XHC4_PME and SMITYPE_CUR_TEMP_STATUS_5 are defined, so add those
defines. When doing the initial update for Phoenix, at least XHC3 and
XHC4 PME events were missing from the PPR. Those two are the PME events
of the two USB4 controllers. SMITYPE_XHC2_PME doesn't exist on this SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic6fff9175b73cc9d0fd324d4a568a5761b92d078
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This patch implements `soc_is_ish_partition_enabled()` override to
uniquely identify the SKU type between UFS and non-UFS to conclude
if ISH partition is enabled and need to retrieve the ISH version from
CSE FPT by sending HECI command.
TEST=Able to uniquely identify the UFS and non-UFS SKUs while booting
to google/marasov.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I7771aebb988f11d9d1b2824aa28e6f294fd67c25
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74532
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set the `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag to request End-Of-Post
right after PCI enumeration and handle the command response at
`BS_PAYLOAD_BOOT'.
With these settings we have observed a boot time reduction of about
100ms on google/rex.
TEST=Tests on google/rex with `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post after PCI initialization and EOP message received at
`BS_PAYLOAD_BOOT'.
Change-Id: I27b540eeddcada521eba91fcc51504831d6dc855
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This adds RTD3 RPMX mutex to the root port. It is shared between RTD3
and WWAN. The purpose of using this mutex is to prevent OSPM from
calling _ON and _OFF methods while WWAN kernel driver is calling _RST,
which accesses the GPIO pins.
BUG=NA
TEST=boot to OS and check the generated SSDT table for the root port.
The RPMX mutex should be generated under the root port.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I5b53765453bac0fc96e9651ab347069c7c8bf058
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73384
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This adds RTD3 RPMX mutex to the root port. It is shared between RTD3
and WWAN. The purpose of using this mutex is to prevent OSPM from
calling _ON and _OFF methods while WWAN kernel driver is calling _RST,
which accesses the GPIO pins.
BUG=NA
BRANCH=firmware-brya-14505.B
TEST=boot to OS and check the generated SSDT table for the root port.
The RPMX mutex should be generated under the root port.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I809eb84cb1a09deb168040e83041b65237a1b576
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73383
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
This patch creates .final hook to call into get ISH version function
if platform has required config
(`SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION`) support.
BUG=b:273661726
TEST=The ISHC version, 5.4.2.7779, was retrieved on the google/nivviks.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ib3f983d5de5b169474bcdb1e9e2934174a9dadf8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74209
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch stores the ISH in the CBMEM table. It verifies CSE has been
updated by comparing previous and current CSE versions. If it has, the
patch updates the previous CSE version with the current CSE version. It
then updates the CBMEM table with the current ISH version.
BUG=b:273661726
TEST=The current and old CSE and ISH versions are verified on the
google/nissa during cold and warm reboots.
Additionally, version updates are verified by a debug patch that
purposely updated the stored cse version.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ie5c5faf926c75b05d189fb1118020fff024fc3e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
The patch implements an API that stores the CSE firmware version in the
CBMEM table. The API will be called from RAMSTAGE based on boot state
machine BS_PRE_DEVICE/BS_ON_EXIT
Additionally, renamed ramstage_cse_fw_sync() to ramstage_cse_misc_ops()
in order to add more CSE related operations at ramstage.
This patch also adds a configuration option,
'SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION', which enables the storage
of firmware version information in CBMEM memory. This information can be
used to identify the firmware version that is currently installed on the
system. The option depends on the `DRIVERS_INTEL_ISH` config and
platform should be flexible enough to opt out from enabling this
feature.
The cost of sending HECI command to read the CSE FPT is significant
(~200ms) hence, the idea is to read the CSE RW version on every cold
reset (to cover the CSE update scenarios) and store into CBMEM to
avoid the cost of resending the HECI command in all consecutive warm
boots.
Later boot stages can just read the CBMEM ID to retrieve the ISH
version if required.
Finally, ensure this feature is platform specific hence, getting
enabled for the platform that would like to store the ISH version into
the CBMEM and parse to perform some additional work.
BUG=b:273661726
TEST=Able to build and boot google/marasov.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I923049d2f1f589f87e1a29e1ac94af7f5fccc2c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74256
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The mp2 PCI device is still present when no mp2 firmware is loaded. When
this device isn't explicitly enabled in the mainboard's devicetree, the
chipset devicetree default of the device being disabled is used. This
results in coreboot's resource allocator not allocating resources to
the device and since the bridge doesn't have enough MMIO space reserved,
the Linux kernel can't assign resources to it. Enable the mp2 device in
the mainboard's devicetree so that it gets its resources assigned by
coreboot.
BUG=b:277217097
TEST=builds
Change-Id: I21885c51ff08846b456675090946f381843ef5e6
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74277
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use coreboot's native PCI access functions instead of using the
vendorcode's PCI access functions to set up the CPU IO routing in
function 1 of the HT PCI device. This file still has room for
improvement, but at least it's now using coreboot-native functionality.
Stoneyridge has a nicer implementation, but looking into possibly
unifying those is out of scope for this patch.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ieecc0e5f6576a838d79220b061de81e21b5d976c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
When one of the General-Purpose PCIe bridges is not used, it doesn't
show up on the PCI bus at all, so coreboot notes it as an issue in the
devicetree. This happens even if the device is marked as off.
To solve this, we're marking the GPP bridge devices in devicetree as
hidden, so they'll only show up in devicetree if they're actually used
on a mainboard.
BUG=b:277997811
TEST=Build
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7b7577baa2dbb0ea7ebbcdb1a8ae81770e61d76f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74527
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When one of the General-Purpose PCIe bridges is not used, it doesn't
show up on the PCI bus at all, so coreboot notes it as an issue in the
devicetree. This happens even if the device is marked as off.
To solve this, we're marking the GPP bridge devices in devicetree as
hidden, so they'll only show up in devicetree if they're actually used
on a mainboard.
BUG=None
TEST=Don't see the "PCI: Leftover static devices:" warning for these in
the boot console.
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I517776e4dedc70e957a0c836ab3c2e5d49e156d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74526
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This change adds the VPU into the DMAR SATC table in order to support
the VPU IO virtualization.
BUG=None
TEST=Enabled the VPU, booted to kernel and verified that DMAR SATC table
includeded the VPU entry.
Change-Id: I6d4af7c9844e33483a1e616eaee061a90d0be6fc
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch refactors cse_fw_sync() function to include timestamp
associated with the CSE sync operation.This effort will ensure the
SoC code just makes a call into the cse_fw_sync() without bothering
about adding timestamp entries.
TEST=Able to build and boot google/marasov.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib5e8fc2b8c3b605103f7b1238df5a8405e363f83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
After the obsoletion of Processor() it is necessary to provide
_PTC package to define P_CNT IO address for clock throttling.
The platforms touched here already emit empty _PTC to disable
clock throttling.
Change-Id: I0e84c8ccd2772c9b3d61f71b74324c8d28f4eefe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74438
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After the obsoletion of Processor() it is necessary to provide
_CST package to define P_LVLx IO addresses for C2/C3 transitions.
The latency values from _CST will always replace those in FADT.
Change-Id: I3230be719659fe9cdf9ed6ae73bc91b05093ab97
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
srcclk_pin is 0-based and '0' is a valid clock source number. If
srcclk_pin is set to -1, then the clock will not be disabled in D3.
Therefore, clock source gating method should not be generated.
BUG=b:271003060
BRANCH=firmware-brya-14505.B
TEST=Boot to OS and check that rtd3 ACPI entries are generated as
expected. For those PCI devices with RTD3 driver whose srcclk_pin to
0, the RTD3 entries should not be missing due to check error.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Ia831b8fd17572cc35765bd226d1db470f12ddd41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73889
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
This patch sends the CSE EOP command asynchronous implementation early
as part of `soc_init_pre_device`.
Without this patch the duration between asynchronous CSE EOP send and
receive commands is not ample which causes idle delay while waiting
for EOP response.
The goal of the CSE async implementation is to avoid idle delay while
capturing the response from CSE EOP cmd. This patch helps to create
ample duration between CSE EOP command being sent and response being
captured.
TEST=Able to boot google/rex sku to ChromeOS and observed ~100ms of
boot time savings (across warm and cold reset scenarios)
Change-Id: I91ed38edbd5a31d61d4888e1466169a3494d635a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Parts of this file were still a copy of the file from the Mendocino SoC,
so update the file to match the PPR #57019 Rev 3.03 and the chipset
devicetree of the Phoenix SoC. Phoenix has 4 GFX/GPP PCIe bridges/ports,
the numbering scheme of the GPP PCIe bridges/ports was changed so that
the numbers match the device and function numbers, and there are new
device functions for the IPU and the USB4 controller and router devices.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie9429c03839bb0199a04cd6cafe9a955ebdacc91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74565
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the `TcssD3ColdDisable` option in devicetree, as it exists
in Kconfig. The setting is only used on `starlabs/starbook` which
selects D3COLD_SUPPORT so the UPDs will not change.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I50e49e900c96748edd5b678765e47cc0e0d9b280
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74476
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use D3COLD_SUPPORT Kconfig option to set the maximum support sleep
state. Report `4` in `_S0W` only when D3COLD_SUPPORT is enabled, as
if it is not, it will break S3 exit.
When D3COLD_SUPPORT is not enabled, return `3` (D3Hot).
This fixed S3 exit on both TGL and ADL. Tested on StarBook
Mk V and Mk VI.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I578d4933b6144aec79fe0b2eb168338ef82c0b9d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74406
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The Kconfig option SOC_INTEL_TIGERLAKE_S3 suggests that it's doing
something with S3, but it's actually disabling D3Cold support.
Remove it, and instead use D3COLD_SUPPORT so it's clear what the
option is doing.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Id43f3e5c8620d474831cc02fcecebd8aac961687
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74405
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update DXIO descriptors for birman-phoenix per schematic 105-D67000-00B
v0.7
Update devicetree to reference the updated DXIO descriptors.
TEST=boot birman and note the devices show up in the logs correctly
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I76cf6715b60a1857bf58349d70a623bf043594fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The Intel FSP used on ChromeOS platform has dropped the
`CpuFeaturesPei.ffs` module to opt for coreboot running this
additional feature programming on BSP and APs.
TEST=Able to build and boot google/rex without any boot regression.
Please refer to the boot time and SPI flash savings after dropping
the FSP feature programming:
Boot time savings=10ms
SPI Flash size savings=34KB
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iaed0a009813098610190b2a3a985b0748c0d51de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
CBFS library performs memory mapped access of the files during loading,
verification and de-compression. Even with MTRRs configured correctly,
first few file access through memory map are taking longer times to
load. Update the SPI DMA driver to load the files into CBFS cache, so
that they can be verified and de-compressed with less overhead. This
saves ~60 ms in boot time.
BUG=None
TEST=Build Skyrim BIOS image and boot to OS. Observe ~60 ms improvement
with the boot time. Performing additional test to confirm there are no
regressions.
Before:
=======
970:loading FSP-M
15:starting LZMA decompress (ignore for x86) 760,906 (60,035)
16:finished LZMA decompress (ignore for x86) 798,787 (37,881)
8:starting to load ramstage
17:starting LZ4 decompress (ignore for x86) 1,050,093 (13,790)
18:finished LZ4 decompress (ignore for x86) 1,054,086 (3,993)
971:loading FSP-S
17:starting LZ4 decompress (ignore for x86) 1,067,778 (3,313)
18:finished LZ4 decompress (ignore for x86) 1,068,022 (244)
90:starting to load payload
17:starting LZ4 decompress (ignore for x86) 1,302,155 (11,285)
18:finished LZ4 decompress (ignore for x86) 1,303,938 (1,783)
After:
======
970:loading FSP-M
15:starting LZMA decompress (ignore for x86) 709,542 (12,178)
16:finished LZMA decompress (ignore for x86) 739,379 (29,837)
8:starting to load ramstage
17:starting LZ4 decompress (ignore for x86) 1,001,316 (12,368)
18:finished LZ4 decompress (ignore for x86) 1,001,971 (655)
971:loading FSP-S
17:starting LZ4 decompress (ignore for x86) 1,016,514 (3,031)
18:finished LZ4 decompress (ignore for x86) 1,016,722 (207)
90:starting to load payload
17:starting LZ4 decompress (ignore for x86) 1,244,602 (10,313)
18:finished LZ4 decompress (ignore for x86) 1,244,831 (228)
Change-Id: Ie30b6324f9977261c60e55ed509e979ef290f1f1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Select SOC_INTEL_RAPTORLAKE to force coreboot to use the RPL FSP headers
for FSP as crota is using a converged firmware image.
BUG=b:267249674
BRANCH=firmware-brya-14505.B
TEST="FW_NAME=crota emerge-brya
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage"
Cq-Depend: chromium:4430832
Signed-off-by: Terry Chen <terry_chen@wistron.corp-partner.google.com>
Change-Id: I448c58f93fddc44904c1f5ef3f8939618eff536f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch enables all DDI ports on Rex board to support display port
tunneling and dual display on TBT dock.
BUG=b:273901499
TEST=Boot google/rex and connect two displays over a TBT dock and check the display functionality.
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I45ee5334fbb877bd58912c8d24920037f155dc42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74413
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add function needed to generate ACPI backlight control SSDT, along with
Kconfig values for accessing the registers.
Tested by adding gfx register on google/magpie. Backlight controls
work on Windows 10 and Linux 6.1.
Change-Id: Iaa9872cd590c3b1298667cc80354ed3efd91c6c8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
In order to accord with grub (see include/grub/i386/linux.h) and
comments for offsets of members of struct linux_params,
struct e820entry should be defined as __packed, otherwise,
sizeof(struct linux_params) will become 4224 (0x1080).
Fortunately, the affected area is usually not occupied.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I09955c90e4eec337adca383e628a8821075381d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The patch moves API that gets the CSE FW partition information into
CSE Lite specific file aka cse_lite.c because the consumer of this API
is the cse_lite specific ChromeOS devices hence, it's meaningful to
move the cse lite specific implementation inside cse_lite.c file.
BUG=b:273661726
TEST=Able to build and boot google/marasov with this code change.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I49ffaec467f6fb24327de3b2882e37bf31eeb7cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74382
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable early caching of the TOM region to optimize the boot time by
selecting `SOC_INTEL_COMMON_BASECODE_RAMTOP` config.
Purpose of this feature is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I3b68d13aa414e69c0a80122021e6755352db32fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73738
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable early caching of the TOM region to optimize the boot time by
selecting `SOC_INTEL_COMMON_BASECODE_RAMTOP` config.
Purpose of this feature is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
TEST=Able to build and boot Starlab ADL laptop to OS.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Iba554af4ff0896e133d20860ff72dd1a10ebd1e3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73736
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Boards with SOC_INTEL_COMMON_BLOCK_ACPI_CPU_HYBRID have
special handling for the time being.
Change of aopen/dxplplusu is coupled with sb/intel/i82801dx.
Change of emulation/qemu-i440fx is coupled with intel/i82371eb.
For asus/p2b, this adds MADT LAPIC entries, even though platform
has ACPI_NO_MADT selected. Even previously ACPI_NO_MADT creates
the MADT, including an entry for LAPIC address.
Change-Id: I1f8d7ee9891553742d73a92b55a87c04fa95a132
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In the non-timeout case in recv_ec_data_timeout, a message like this one
will get printed at BIOS_SPEW log level: "recv_ec_data_timeout: 0x00".
The "timeout" part of the function name corresponds to what the function
does, but the message will only be printed when not running into the
timeout which is a bit misleading and might suggest a problem when there
is none. To avoid this possible confusion, don't use the function name
in the printk, but use "Data from EC:" instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I521f67517f64fc64e24853d96730c3f9459f1ccc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74381
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This fixes the Jenkins build error when building INTEL_ARCHERCITY_CRB
that was caused by the API change in commit 36e6f9bc04. This patch removes the
broken API function and also adds package_id log print same as previous
commit mentioned above.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I89e14b40186007ab0290b24cd6bd58015be376b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74436
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
When a mainboard selects ACPI_SOC_NVS and CHROMEOS, CHROMEOS_NVS will be
selected. This causes vc/google/chromeec/acpi/chromeos.asl to be
included in the DSDT and chromeos_acpi_gpio_generate to be called when
generating the coreboot SSDT. When a mainboard also uses
DECLARE_NO_CROS_GPIOS(), this will cause variant_cros_gpio.count to be 0
and variant_cros_gpio.gpios to be NULL. chromeos_acpi_gpio_generate only
checked if the GPIO table was non-NULL, which caused the function to
exit early and not generate the OIPG package which causes the kernel to
complain about referencing the non-existing OIPG package. To avoid this,
only exit in the GPIO table pointer being NULL case if the number of
GPIOs is non-0.
TEST=Error about missing OIPG ACPI object in dmesg disappears on birman.
Before:
[ 0.241339] chromeos_acpi: registering CHSW 0
[ 0.241468] ACPI BIOS Error (bug): Could not resolve symbol [\CRHW.GPIO.OIPG], AE_NOT_FOUND (20220331/psargs-330)
[ 0.241703] ACPI Error: Aborting method \CRHW.GPIO due to previous error (AE_NOT_FOUND) (20220331/psparse-531)
[ 0.241933] chromeos_acpi: failed to retrieve GPIO (5)
[ 0.242011] chromeos_acpi: registering VBNV 0
[ 0.242113] chromeos_acpi: registering VBNV 1
[ 0.242284] chromeos_acpi: truncating buffer from 3072 to 1336
[ 0.242462] chromeos_acpi: installed
With the patch applied:
[ 0.242580] chromeos_acpi: registering CHSW 0
[ 0.242714] chromeos_acpi: registering VBNV 0
[ 0.242817] chromeos_acpi: registering VBNV 1
[ 0.242990] chromeos_acpi: truncating buffer from 3072 to 1336
[ 0.243249] chromeos_acpi: installed
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ie340003afb718b1454c2da4a479882b71714c3c7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74375
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch avoids cannonlake base config to select eNEM for CAR by
default. Rather allow other SoC config to choose the applicable CAR
mode between eNEM and NEM.
CML and WHL select eNEM whereas CFL decided to use NEM for CAR setup.
Here is some background about why CFL SoC platform decided to choose
NEM over eNEM:
It was found that some coffeelake CPUs like Intel i3 9100E fail to enter
CAR mode because some MSR used by NEM enhanced are lacking. According to
the Intel SDM CPUID.EAX=07h.ECX=0 reg EBX[12 or 15] should indicate the
presence of IA32_PAR_ASSOC and CPUID.EAX=10h.ECX[1 or 2] reg ECX[2]
should indicate IA32_L3_QOS_CFG and IA32_L2_QOS_CFG respectively but
even on a Intel coffeelake CPU that works with the NEM_ENHANCED these
CPUID bits are all 0 so there is no way of knowing whether NEM_ENHANCED
will work at runtime. Instead just always use regular NEM.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibeaa4d53279ff9cbcd0b2ac5f2ad71925872355b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Currently the xeon_sp code reassigns struct devices apic_id so that srat
entries can be added in a certain order.
This is not a good idea as it breaks thread local storage which contains
a pointer to its struct device cpu.
This moves the sorting of the lapic_ids to the srat table generation
and adds the numa node id in each core init entry. Now it is done in
parallel too as a bonus.
Change-Id: I372bcea1932d28e9bf712cc712f19a76fe3199b1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68912
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For security reasons, removing the efivars implementation of the option
API was considered. However, this use-case is not the "None"
option-backend (CONFIG_OPTION_BACKEND_NONE), so the SMM phase also does
not use the no-op in option.h. This causes linker errors when the
option API is called.
For example, src/soc/intel/common/block/pmc/pmclib.c and
src/console/init.c use `get_uint_option`.
Minimising code in SMM can be implemented as a follow-up.
Change-Id: Ief3b52965d8fde141c12266a716f254dd45559d5
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch retrieves details of a specified firmware partition table.
The information retrieved includes the current firmware version and
other information about the firmware partition. The patch communicates
with the ME using the HECI command to acquire this information.
BUG=b:273661726
Test=Verified the changes for ISH partition on nissa board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I0582010bbb836bd4734f843a8c74dee49d203fd8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Currently the DNOT function first checks to see if the current DNOT
value has already been reported. Add support to allow forcing regardless
if it had been sent already.
TEST=confirmed that when enabled, all events notify. When disabled, only
events on value change are notified.
BUG=b:271938907
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: I7a93cca6a8f922574dd46b46572b230755db9aa7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Create the taranza variant of the waddledee reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:277664211
BRANCH=dedede
TEST=util/abuild/abuild -p none -t google/dedede -x -a
make sure the build includes GOOGLE_TARANZA
Change-Id: Id64e48ff2acd6e827fe586a00376183930ddc7e1
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74295
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The BSP might have non-zero lapicid so set the topology accordingly,
without assuming it is 0. This fixes a cpu exception on at least Intel
Meteorlake. This was caused by FSP CPU PPI being giving incorrect
information about the BSP topology.
This problem was introduced by 8b8400a "drivers/fsp2_0/mp_service_ppi:
Use struct device to fill in buffer" which sets the PPI struct based on
struct device.
TESTED on google/rex
Change-Id: I3fae5efa86d8efc474c129b48bdfa1d1e2306acf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74374
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To quote the gnu make manual: "A phony target is one that is not really
the name of a file; rather it is just a name for a recipe to be executed
when you make an explicit request. There are two reasons to use a phony
target: to avoid a conflict with a file of the same name, and to improve
performance."
Change-Id: I337f4f2e0257a75ba204d21f8aa84292e8233082
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74309
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marvin Drees <marvin.drees@9elements.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Processor attached memory should not use reserved_ram_from_to and
treat the calculation of gi_mem_size size as 64MB.
By default SOC_INTEL_HAS_CXL is enabled for Sapphire Rapids platforms,
this should fix small total memory issue. Before the fix running
command 'free -g -h' under Linux shows the total memory is only 1.4Gi,
after the fix it's showing the expected total memory size 15Gi.
Tested=On AC without attaching CXL memory, the total memory size is
the same as de-selecting SOC_INTEL_HAS_CXL.
On OCP Crater Lake with CXL memory attached, CXL memory can be recognized
in NUMA node 1:
numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 .. 59
node 0 size: 95854 MB
node 0 free: 93860 MB
node 1 cpus:
node 1 size: 63488 MB
node 1 free: 63488 MB
node distances:
node 0 1
0: 10 14
1: 14 10
Change-Id: I38e9d138fd284620ac616a65f444e943f1774869
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74296
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Yavilla is a variant of yaviks which is almost identical
to yaviks, so is reusing the yaviks coreboot variant.
so update the GPIO tables to handle these based on fw_config.
BUG=b:277148122
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: I831b199055c931e7a4a393eeb9e75e83c8ae3c3a
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74264
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Yavilla will leverage yaviks FW build.
It has one additional USB Type-A0 port, support stylus and support WWAN.
Here update devicetree based on FW_CONFIG for yavilla's design.
-Enable USB2 port3 and USB3 port1 for USB2/3 Type-A0
-Enable USB2 port5 and USB3 port3 for WWAN
-Enable pen garage
-Enable rear mipi cam
-Enable Synaptics touchpad
BUG=b:277148122, b:276369170
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: I38dbcf5920d12adb1f84885bdfa4c2f2faf2eb9e
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
In CB:41119, I sort of made up a mechanism on the fly for how to make
the machine-parseable cbfstool print output extensible without breaking
backwards compatibility for older scripts. But I only explained it in
the commit message which is not very visible. This patch adds a comment
to the function that generates that output so that people who want to
change it can understand the intent.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0d18d59e7fe407eb34710d6a583cfae667723eb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This reverts commit 655f7362e1.
Reason for revert: Apparently, the change was not properly reviewed. It
not only contains conflicting name and description of the D3COLD
Kconfig, but also creates a conflict between existing devicetree and
Kconfig options for D3Cold/S3/S0ix.
Change-Id: I56ce8f59f8548fc58bc2b3b07c1314e2eed7061c
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Add supported memory parts in mem_parts_used list, and generate SPD ID
for these parts.
These new memory are added for yavilla.
DRAM Part Name ID to assigna
H58G66BK7BX067 4 (0100)
MT62F2G32D4DS-026 WT:B 4 (0100)
K3KL9L90CM-MGCT 4 (0100)
H58G66AK6BX070 5 (0101)
BUG=b:277148122
BRANCH=firmware-nissa-15217.B
TEST=run part_id_gen to generate SPD id
Change-Id: I3c48b9763f54e2e69f7c2d494fefbabedab2a389
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This reverts commit 4dba71fd25.
Add multiple fan support for dptf policies.
This also fixes the Google Meet resolution drop issue as per
b:246535768 comment#12. When system starts Google Meet video call,
it uses the hardware accelerated encoder as expected. But, as soon as
another system connects to the call, an immediate fallback is observed
from hardware to software encoder. Due to this, Google Meet resolution
dropped from 720p to 180p. This issue is observed on Alder Lake-N SoC
based fanless platforms. This same issue was not seen on fan based
systems. With the fix in dptf driver where fan configures appropriate
setting for only fan participant, not for other device participants,
able to see consistent 720p resolution.
BUG=b:246535768,b:235254828
BRANCH=None
TEST=Built and tested on Alder Lake-P Redrix system for two fans
support and on Alder Lake-N fanless systems. With this code change
Google Meet resolution drop not observed.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: Id07d279ff962253c22be9d395ed7be0d732aeaa7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73249
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With EC's lid switch implementation, there is no need to maintain the
lid switch state in mainboard. Hence remove LIDS ACPI object from
mainboard.
BUG=None
TEST=Build Skyrim BIOS image and boot to OS. Read the lid switch state
correctly through /proc/acpi/button/lid/LID0/state.
Change-Id: I0f8dc7216337268c421a475f54ee5b28abf33d08
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
With CB:16732, EC can provide default lid switch implementation(LID0
ACPI device). Up until that point, mainboard has been providing default
switch implementation. When EC provides lid switch implementation, the
lid switch state is read from EC either through MMAP or LPC interface.
Hence there is no need to keep mainboard's LIDS ACPI object in sync with
EC's lid switch state. Use only EC's lid switch state on boards using
EC's implementation. This paves the way to remove LIDS ACPI object on
those mainboards.
BUG=None
TEST=Build Skyrim BIOS image and boot to OS. Trigger lid open/close
events and ensure that they are detected properly through
/proc/acpi/button/lid/LID0/state.
localhost ~ # cat /proc/acpi/button/lid/LID0/state
state: open
localhost ~ # cat /proc/acpi/button/lid/LID0/state
state: closed
Ensure that the system behaves as expected based on powerd
configuration. After signin, system suspends/resumes for lid close/open.
On signin screen, system shuts down/boots for lid close/open.
Change-Id: I013574d7c21761f167ad38aeed27a419677b8000
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Intel Archer City CRB is a dual socket CRB with Intel Sapphire Rapids
Scalable Processor chipset. The chipset also includes Emmitsburg PCH.
It was tested with LinuxBoot payload on both dual and single socket
configurations.
The multisocket support depends on Change-Id:
I4a593252bb7f68494f4ccce215ac9cf1eb19b190
Change-Id: Ic02634cd615e2245e394f10aad24b0430cf5cd17
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71968
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
P2SB device is being hidden from coreboot by FSP-S. This breaks the
resource allocator which does not report P2SB BAR via intel common
block P2SB driver. Hook up the common block P2SB driver ops to
soc_enable function so that the resources will be reported. The P2SB
device must be set as hidden in the devicetree.
This fixes the silent resource allocation conflicts on machines with
devices having big BARs which accidentally overlapped P2SB BAR.
TEST=Boot MSI PRO Z690-A with multiple PCIe devices/dGPUs with big
BARs and see resource conflicts no longer occur.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I7c59441268676a8aab075abbc036e651b9426057
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Printing the value of a variable is not informative for a normal user,
so decrease the value from BIOS_INFO to BIOS_DEBUG.
Fixes: b9caac74a3 ("soc/amd/mendocino: Reinterpret smu_power_and_thm_limit")
Change-Id: I22f6293fd47633dfdbdae37b7257f47a5a4bb29c
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Fix a couple of bugs in the _OSC method for handling
"PCI Host Bridge Device" on Xeon-SP.
- Drop the Sleep. The code doesn't write to hardware at all, so
there's no need to sleep here.
- Make sure that the number of DWORD passed in Arg2 is at least 3.
The existing check was useless as it would not create the
DWordField, but then use it anyways.
- Add check for CXL 2 device method calls which provide a 5 DWORD
long buffer to prevent buffer overflows when invoking the
"PCI Host Bridge Device" method.
Test:
Boot on Archer City and confirm that no ACPI errors are reported
for _OSC.
Change-Id: Ide598e386c30ced24e4f96c37f2b4a609ac33441
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
Ioapic information in the devicetree was only used to set up mptables
but this generic driver was removed (ca5a793 drivers/generic/ioapic:
Drop poor implementation).
This removes the unused remainders from mainboard devicetrees.
Remove ioapic setup from sconfig.
Change-Id: Ib3fef0bf923ab3f02f3aeed2e55cf662a3dc3a1b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71789
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Add GPU power sequencing changes for the Hades baseboard and variant.
Some signals were added, moved or inverted.
Based on implementation from Agah.
Moved signals:
GPIO_1V8_PWR_EN GPP_E11
GPIO_NV33_PWR_EN GPP_E2
GPIO_NV33_PG GPP_E1
New signals:
GPIO_NV12_PWR_EN GPP_D0
GPIO_NV12_PG GPP_D1
Inverted signals:
GPIO_FBVDD_PWR_EN GPP_A19
ifdef's will be dropped once the Agah variant is retired.
BUG=b:269371363
TEST=builds and verified on Agah that DGPU is still detectable (lspci)
Change-Id: I0b8efe7a34102cf61d4f784103c4a4f9337213f7
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
mainboard_vbt_filename() used to assume that it is called after a call
to get_blc_pwm_freq_value() with a valid parameter, but currently it
is the first call of get_blc_pwm_freq_value(NULL), and will return 0,
so "data_led.vbt" is always returned, regardless of the actual type of
the panel.
Combined with the previous commit, in this commit
mainboard_vbt_filename() will explicitly read EDID string via
gm45_get_lvds_edid_str() and use this string to call
get_blc_pwm_freq_value().
Resolves: https://ticket.coreboot.org/issues/475
Tested on my x200s with LTD121EQ3B (LED), and x200 with LTD121EWVB
(CCFL).
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I2e080b29321b6989d1f26b6c67876b3d703042f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74181
Reviewed-by: Swift Geek (Sebastian Grzywna) <swiftgeek@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This patch updates the MTLRVP debug flash layout to optimize WP_RO to 4MB.
Changes for chromeos.fmd:
SI_BIOS:
RW_SECTION_A/B: Increase to 7.5MB.
RW_LEGACY: Introduce with 1MB.
RW_MISC: Increased to 1MB.
RW_UNUSED: 2MB (reserved)
WP_RO: Reduce to 4MB
Additionally, ensure RW_SECTION_B region starts at 16MB boundary in the
SPI Flash.
BUG=b:277143384
TEST=Able to build and boot intel/mtlrvp with FSP release and debug image.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie635e3cce1c3fd771e6a17e4b3c1bd700f4729bd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74254
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch updates the Rex debug flash layout to optimize WP_RO to 4MB.
Changes for chromeos.fmd:
SI_BIOS:
RW_SECTION_A/B: Increase to 7.5MB.
RW_LEGACY: Introduce with 1MB.
RW_MISC: Increased to 1MB.
RW_UNUSED: 2MB (reserved)
WP_RO: Reduce to 4MB
Additionally, ensure RW_SECTION_B region starts at 16MB boundary in the
SPI Flash.
BUG=b:277143384
TEST=Able to build and boot google/rex with FSP release and debug image.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4ab69eb24937d58c8bc5d3c0a6e5cb70b843a1ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch updates the MTLRVP flash layout to optimize WP_RO to 4MB.
Changes for chromeos.fmd:
SI_BIOS:
RW_SECTION_A/B: Reduce to 7MB.
RW_LEGACY: Reduce to 1MB.
RW_MISC: Increased to 1MB.
RW_UNUSED: 3MB (reserved)
WP_RO: Reduce to 4MB
Additionally, ensure RW_SECTION_B region starts at 16MB boundary in the
SPI Flash.
BUG=b:277143384
TEST=Able to build and boot intel/mtlrvp with FSP release and debug image.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibd1ea7a3a2cd21928b8e33473c7bdddfad17c636
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch updates the Rex flash layout to optimize WP_RO to 4MB.
The idea is to create more space inside FW_RW_A/B to accommodate
multiple blobs to boot google/rex with different Intel MTL SoC stepping.
Changes for chromeos.fmd:
SI_BIOS:
RW_SECTION_A/B: Reduce to 7MB.
RW_LEGACY: Reduce to 1MB.
RW_MISC: Increased to 1MB.
RW_UNUSED: 3MB (reserved)
WP_RO: Reduce to 4MB
Additionally, ensure RW_SECTION_B region starts at 16MB boundary in the
SPI Flash.
BUG=b:277143384
TEST=Able to build and boot google/rex with FSP release and debug image.
Change-Id: Iccf83b7bb66d0d5503e0ff9e9a819051296c6724
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74229
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch sends the CSE EOP command asynchronous implementation early
as part of `soc_init_pre_device`.
Without this patch the duration between asynchronous CSE EOP send and
receive commands is not ample whichcauses idle delay while waiting
for EOP response.
The goal of the CSE async implementation is to avoid idle delay while
capturing the response from CSE EOP cmd.
This patch helps to create ample duration between CSE EOP command
being sent and response being captured.
TEST=Able to boot google/marasov EVT sku to ChromeOS and observed
~30ms of boot time savings (across warm and cold reset scenarios).
Without this patch:
963:returning from FspMultiPhaseSiInit 907,326 (97,293)
...
...
115:finished elog init 967,343 (2,581)
942:before sending EOP to ME 967,821 (478)
…
16:finished LZMA decompress (ignore for x86) 1,017,937 (12,135)
943:after sending EOP to ME 1,067,799 (49,861)
…
…
1101:jumping to kernel 1,144,587 (13,734)
Total Time: 1,144,549
With this patch:
963:returning from FspMultiPhaseSiInit 918,291 (97,320)
942:before sending EOP to ME 918,522 (230)
...
...
16:finished LZMA decompress (ignore for x86) 1,029,476 (12,483)
943:after sending EOP to ME 1,033,456 (3,980)
...
...
1101:jumping to kernel 1,111,410 (14,007)
Total Time: 1,111,375
Change-Id: Idaf45ef28747bebc02347f0faa77cc858a4a8ef1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This change enables PCIe x1 slot. In addition, it turns off 3.3v and
12v power and assert PERST# when suspend and turn on the power and
deassert the PERST# when resume for the x1 slot.
NOTE: Kconfig flag and required GPIO pins are already configured.
- /soc/intel/meteorlake/Kconfig
select SOC_INTEL_COMMON_BLOCK_PCIE_RTD3
- gpio.c:
/* GPP_A18: X1_PCIE_SLOT3_PWR_EN */
PAD_CFG_GPO(GPP_A18, 1, DEEP),
/* GPP_A19: X1_DT_PCIE_RST_N */
/* SRCCLKREQ: GPP_C12: SRCCLKREQ3_GEN4_X1_DT_SLOT3_N */
PAD_CFG_NF(GPP_C12, NONE, DEEP, NF1),
BUG=b:224325352
BRANCH=None
TEST=Insert a SD card or NIC AIC on PCIe x1 slot and the AIC should
be detected and enabled at boot. For S0ix, run
'suspend_stress_test -c 1'. The RP6 should not cause any suspend and
resume issue.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Id2e92acf754569a22ea76a68c91aafce0075a742
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73054
Reviewed-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PCIe bridges need to provide the LTR (latency tolerance reporting)
maximum snoop/non-snoop values so that they are inherited by downstream
PCIe devices which support and enable LTR. Without this, downstream
devices cannot have LTR enabled, which is a requirement for supporting
PCIe L1 substates. Enabling L1ss without LTR has unpredictable behavior,
including some devices refusing to enter L1 low power modes at all.
Program the max snoop/non-snoop latency values for all PCIe bridges
using the same value used by AGESA/FSP, 1.049ms.
BUG=b:265890321
TEST=build/boot google/skyrim (multiple variants, NVMe drives), ensure
LTR is enabled, latency values are correctly set, and that device
power draw at idle is in the expected range (<25 mW).
Change-Id: Icf188e69cf5676be870873c56d175423d16704b4
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74288
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens. This removes
non-present devices from the SSDT and relieves the OS of the burden of
probing.
TEST=build/boot Windows/linux on drallion, verify touchscreen functional
in OS, dump ACPI and verify only i2c devices actually present on the
board have entries in the SSDT.
Change-Id: I3b91a628cd4a9edb5d5a7521529f39b75935e1d0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74239
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Ensure the GPIOs themselves are configured as level triggered, as well
as the devicetree entiures. I2C-HID spec requires LEVEL trigger, and the
drivers (both Linux and Windows) work better with LEVEL vs EDGE trigger.
TEST=tested with rest of patch train
Change-Id: I4fba55c938f401876798c2b32c5922523f32180f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
For touchscreens on sarien, drive the enable GPIO high starting in
romstage while holding in reset, then disable the reset GPIO in
ramstage. This will allow coreboot to detect the presence of i2c
touchscreens during ACPI SSDT generation (implemented in a subsequent
commit).
BUG=b:121309055
TEST=tested with rest of patch train
Change-Id: I3ce7bfc0fa4c03c0bb96bebaa3c3d256f886ecc4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add method variant_romstage_gpio_table() with empty implementation to
be used in a subsequent commit for touchscreen power sequencing.
Call method in romstage to program any GPIOs that may need to be set.
TEST=tested with rest of patch train
Change-Id: I11b72a10a4a105385fbcf1d795c020708a7a90d9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Without gpio.c compiled in, SMMSTORE will fail to initialize and hang.
Add a conditional inclusion so gpio.c is compiled in SMM when SMMSTORE
is selected.
TEST=build/boot google/banshee with SMMSTORE support enabled
Change-Id: If049cba98f13f060807058029306dcad2ada2d49
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Stylus reset GPIO needs to be held low in romstage, released
in ramstage for runtime i2c detection to pick it up.
TEST=build/boot AKALI360 variant, verify stylus detected in cbmem,
functional in OS.
Change-Id: I2e7f2a28f6b3a71b0c8fc367168cffbe3f064663
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Deselect the 'fixed resolution at boot' and 'eFP attached' options via
the Windows BMP tool. Fixes HDMI audio output under Windows 10/11.
TEST=build/boot Win 11 on Fizz, verify HDMI audio now functional.
Change-Id: Iecede735bc1266af837e791e6c024aec2f9a8a80
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74235
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel ADL-P USB Type-C ports are not compatible with Parade PS8815
retimer on USB U1/U2 transition. The usb_lpm_incapable config is
used to disable USB U1/U2 transition for these Type-C ports.
BUG=b:277149723
BRANCH=firmware-brya-14505.B
TEST=Plug in device and check LPM sysfs nodes are disabled
localhost ~ # cat /sys/bus/usb/devices/2-3/power/usb3_hardware_lpm_u1
disabled
localhost ~ # cat /sys/bus/usb/devices/2-3/power/usb3_hardware_lpm_u2
disabled
Change-Id: I618cd09f45ede0a76cf46b3e467ba87775dd5d9d
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74246
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ron Lee <ron.lee@intel.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Original lastbus configuration consumes constant memory size by
allocating 16 and 8 members arrays and the utilization is bad. Refactor
the lastbus structs to save memory usage.
BRANCH=none
BUG=none
TEST=bootblock.raw.bin size is reduced from 60328 bytes to 59048 bytes.
Change-Id: I07ff9ff7c75f03219e1792b92b62814293ef43fe
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74061
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This to fix following error using Clang-16.0.0:
/cb-build/coreboot-toolchain.0/clang/LENOVO_W500/mainboard/lenovo/t400/static.c:135:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
.backlight_enable = 0x01,
^~~~
/cb-build/coreboot-toolchain.0/clang/LENOVO_W500/mainboard/lenovo/t400/static.c:136:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
.dock_event_enable = 0x01,
^~~~
Change-Id: Icd35224877fee355e1bbb8a8e838cb047604babb
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This to fix following error using Clang-16.0.0:
/cb-build/coreboot-toolchain.0/clang/APPLE_IMAC52/mainboard/apple/macbook21/static.c:66:19: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
.c4onc3_enable = 1,
^
/cb-build/coreboot-toolchain.0/clang/APPLE_IMAC52/mainboard/apple/macbook21/static.c:75:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
.p_cnt_throttling_supported = 1,
^
Change-Id: I691b51a97b359655c406bff28ee6562636d11015
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73796
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This to fix following error using Clang-16.0.0:
CC romstage/mainboard/emulation/qemu-i440fx/static.o
build/mainboard/emulation/qemu-i440fx/static.c:31:17: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
.ide0_enable = 1,
^
build/mainboard/emulation/qemu-i440fx/static.c:32:17: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
.ide1_enable = 1,
^
Change-Id: I36cc19bc2908119fe940941e108ee217a7b26f50
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Currently coreboot presents the BSP core first, then efficient cores and
Performance cores as indicated below:
```
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2-3
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:2-3
```
Existing code presents mix of different cores to OS and causes CPU load
balancing and power/performance impact. So, the patch fixes this
disorder by ordering the Performance cores first, compute die efficient
cores next, and finally SOC efficient cores if they are present. This
is done to run the media applications in a power efficient manner,
please refer the ChromeOS patches for details:
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3963893
BUG=b:262886449
TEST=Verified the code on Rex system
After the fix:
```
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2-3
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:2-3
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
```
Change-Id: I21487a5eb0439ea0cb5976787d1769ee94777469
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Set the `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag to request End-Of-Post
right after PCI enumeration and handle the command response at
`BS_PAYLOAD_BOOT'.
With these settings we have observed a boot time reduction of about 20
to 30 ms on brya0.
BUG=b:268546941
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post after PCI initialization and EOP message received at
`BS_PAYLOAD_BOOT'.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Ib850330fbb9e84839eb1093db054332cbcb59b41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74215
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
coreboot supports three instances of sending EOP:
1. At CSE `.final' device operation
2. Early as with Alder Lake in chip_operations.init if
`SOC_INTEL_CSE_SEND_EOP_EARLY' is selected
3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if
`SOC_INTEL_CSE_SEND_EOP_LATE' is selected
Currently, Alder Lake uses #3 as it results in better and more stable
boot time. However, what would deliver even better result is to not
actively wait for CSE completion.
This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig
which split the action of sending EOP request and receiving EOP
completion response from the CSE.
This patch used in conjunction with #1 can significantly
improves the overall boot time on a Raptor Lake design. For example
`SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36
ms boot time improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 1 | 1020.052 | 971.272 |
| 2 | 1015.911 | 971.821 |
| 3 | 1038.415 | 1021.841 |
| 4 | 1020.657 | 993.751 |
| 5 | 1065.128 | 1020.951 |
| 6 | 1037.859 | 1023.326 |
| 7 | 1042.010 | 984.412 |
|----------+----------+-----------|
| Mean | 1034.29 | 998.20 |
| Variance | 4.76 % | 5.21 % |
The improvement is not stable but comparing coreboot and FSP
performance timestamps demonstrate that the slowness is caused by a
lower memory frequency (SaGv point) at early boot which is not an
issue addressed by this patch.
We also observe some improvement on an Alder Lake design. For example,
the same configuration on a kano board can deliver up to 10 ms boot time
improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 0 | 1067.719 | 1050.106 |
| 1 | 1058.263 | 1056.836 |
| 2 | 1064.091 | 1056.709 |
| 3 | 1068.614 | 1055.042 |
| 4 | 1065.749 | 1056.732 |
| 5 | 1069.838 | 1057.846 |
| 6 | 1066.897 | 1053.548 |
| 7 | 1060.850 | 1051.911 |
|----------+----------+-----------|
| Mean | 1065.25 | 1054.84 |
The improvement is more limited on kano because a longer PCIe
initialization delays EOP in the Late EOP configuration which make it
faster to complete.
CSME team confirms that:
1. End-Of-Post is a blocking command in the sense that BIOS is
requested to wait for the command completion before loading the OS or
second stage bootloader.
2. The BIOS is not required to actively wait for completion of the
command and can perform other operations in the meantime as long as
they do not involve HECI commands.
On Raptor Lake, coreboot does not send any HECI command after
End-Of-Post. FSP-s code review did not reveal any HECI command being
sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or
`END_OF_FIRMWARE' notifications.
If any HECI send and receive command has been sent the extra code
added in `cse_receive_eop()' should catch it.
According to commit 387ec919d9 ("soc/intel/alderlake: Select
SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first
boot after flashing of a Marasov board for instance) request coreboot
to perform a global request out of AFTER_PCI_ENUM notification. Global
request relies on a HECI command. Even though, we tested that it does
not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not
be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent
potential a global reset command to "conflict" with the EOP command.
This patch also introduces a new code logic to detect if CSE is in the
right state to handle the EOP command. Otherwise, it uses the
prescribed method to make the CSE function disable. The typical
scenario is the ChromeOS recovery boot where CSE stays in RO partition
and therefore EOP command should be avoided.
[DEBUG] BS: BS_PAYLOAD_LOAD exit times (exec / console): 0 / 14 ms
[INFO ] HECI: coreboot in recovery mode; found CSE in expected
SOFT TEMP DISABLE state, skipping EOP
[INFO ] Disabling Heci using PMC IPC
[WARN ] HECI: CSE device 16.0 is hidden
[WARN ] HECI: CSE device 16.1 is disabled
[WARN ] HECI: CSE device 16.2 is disabled
[WARN ] HECI: CSE device 16.3 is disabled
[WARN ] HECI: CSE device 16.4 is disabled
[WARN ] HECI: CSE device 16.5 is disabled
BUG=b:276339544
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post sent soon after FSP-s and EOP message receive at
`BS_PAYLOAD_BOOT'. Verify robustness by injecting a
`GET_BOOT_STATE' HECI command with or without `heci_reset'. The
implementation always successfully completed the EOP before
moving to the payload. As expected, the boot time benefit of the
asynchronous solution was under some injection scenario
undermined by this unexpected HECI command.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I01a56bfe3f6c37ffb5e51a527d9fe74785441c5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This patch introduces a new config named
`DROP_CPU_FEATURE_PROGRAM_IN_FSP` to avoid FSP running basic CPU
feature programming on BSP and on APs using the "CpuFeaturesPei.efi"
module.
Most of this feature programming is getting performed today in scope
of coreboot doing MP Init. Running this redundant programming in
scope of FSP (when `USE_FSP_FEATURE_PROGRAM_ON_APS` config is enabled)
results in CPU exception (for example: attempting to reprogram CPU
feature lock MSR is causing CPU exception).
SoC users should select this config after dropping "CpuFeaturesPei.ffs"
module from FSP-S Firmware Volume (FV). Upon selection, coreboot runs
those additional feature programming on BSP and APs.
This feature is by default enabled, in case of "coreboot running MP
init" aka `MP_SERVICES_PPI_V2_NOOP` config is selected.
At present, this option does not do anything unless any platform
eventually decides to drop FSP feature programming module and choose
coreboot CPU feature programming over it.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3be5329390401024d7ec9eed85a5afc35ab1b776
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
In Intel designs, internal processor errors, such as a processor
instruction retirement watchdog timeout (also known as a 3-strike
timeout) will cause a CATERR assertion and can only be recovered from by
a system reset.
This patch prevents the Three Strike Counter from incrementing (as per
Intel EDS doc: 630094), which would help to disable Machine Check Catastrophic error. It will provide more opportunity to collect more useful CPU traces for debugging.
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I286037cb00603f5fbc434cd1facc5e906718ba2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74158
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Restrict DPTC to 15W boards, since we only have 15W values defined in
the devicetree. This will revert the 6W boards back to their default
values, rather than (incorrectly) configuring them with 15W values.
BUG=b:253301653
TEST=Verify DPTC values are set for 15W boards
TEST=Verify DPTC values are set not set for 6W boards
Change-Id: I94f3974fce6358e3cbb0c30c1af33eb7ecb29ad7
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74127
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The FSP will return the TDP in the format 0xX0000, where 'X' is the
value we're interested in. For example: 0xF0000 (15W), 0x60000 (6W).
Re-interpret the value so the caller just sees the TDP directly, without
needing to re-interpret things themselves.
BUG=b:253301653
TEST=Manually verify value is correct
Change-Id: I632e702d986a4ac85605040e09c1afab2bbdc59d
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74126
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some systems the BSP cannot know how many CPUs are present in the
system. A typical use case is a multi socket system. Setting the enable
flag only on CPUs that actually exist makes it more flexible.
Change-Id: I6c8042b4d6127239175924f996f735bf9c83c6e8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68892
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the current design the relocatable parameters are used to know the
offset of the 32bit startpoint. This requires back and forward
interaction between the stub, the loader and the mp init code. This
makes the code hard to read.
This is static information known at buildtime, so a better way to deal
with this is to generate a header that contains this offset.
Change-Id: Ic01badd2af11a6e1dbc27c8e928916fedf104b5b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64625
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add possibility to clone edk2-platforms repository. Some edk2
repositories may use modules from edk2-platforms which contains
various feature packages for Intel platforms, e.g VT-d driver if DMA
protection is enabled.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Iabd0793dfdcb95260046dc992ff30ef581159db9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68872
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop devicetree setting X2apic as the same functionality is already
exposed in Kconfig.
To activate X2apic select X2APIC_ONLY or X2APIC_RUNTIME in
the "APIC operation mode".
Note: Your OS must have support for X2APIC. If you are using less
than 256 CPU cores select XAPIC_ONLY here.
Test:
- Booted to OS in X2APIC mode when X2APIC_ONLY or X2APIC_RUNTIME
was selected.
- Booted to OS in XAPIC mode when XAPIC_ONLY was selected.
Change-Id: I65152b0696a45b62a5629fd95801187354c7a93b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When 'use_rp_mutex' (default = 0) is set in the device tree, a root
port mutex will be added. This mutex is used in _ON and _OFF method,
where the GPIO reset and/or enable GPIO value is changed. The
companion driver, such as WWAN driver, needs to acquire this root
port mutex when accessing the same GPIO pins. Using this common mutex
prevents those invoked methods from being called from different thread
while one is not completed.
An example is that WWAN driver calling _RST method to reset the device
and does remove/rescan for the device while the pm runtime work might
call RTD3 _OFF.
For those root port without additional driver, this mutex is not needed.
BRANCH=firmware-brya-14505.B
TEST=boot to OS and check the generated SSDT table for the root port.
The RPMX mutex should be generated and _ON and _OFF should use this
mutex.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Ibc077528692b2d7076132384fb7bd441be502511
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
On Skyrim, there isn't a need for a sleep GPIO table. Remove the TODO
and filler table and function to reduce unnecessary function overhead.
BUG=None
BRANCH=Skyrim
TEST=Build Skyrim BIOS image.
Change-Id: Ia9d55a5e2295bb2e2c2957c4f5207362f616022c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73852
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
IF its first call is get_blc_pwm_freq_value(NULL), null dereference
will occur.
Now when the parameter is NULL, it will return the value of the static
blc_pwm_freq directly, so the original behavior is kept.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I32354aa0fe1a3ca725c2031f973ffad0bda81ad5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74179
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Update spd_gen and part_id_gen utilities to accommodate Phoenix platform
so that SPD can be generated for the memory parts used in that platform.
SPD requirements for Phoenix and Mendocino platforms are identical.
BUG=b:273383819
TEST=Run spd_gen and ensure that both Mendocino and Phoenix platforms
share the platform manifest for LP5 memory parts.
Change-Id: I7a12f73065864f08db8922c1a69eb503865a25b1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
This reverts commit 11f2f88a27.
Revert initial change as it was causing a boot failure when
transitioning into recovery mode.
BUG=b:276927816
TEST='emerge-brya coreboot chromeos-bootimage', flash and boot a skolas
SKU1 to kernel, then press Esc-Refresh-PowerButton to try to reboot into
recovery mode.
Change-Id: I91c8d0434a2354dedfa49dd6100caf0e5bfe3f4c
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74206
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the 'verstage_x86' make target for the mode_switch.S compilation
unit instead of making adding it to the 'verstage' target depending on
VBOOT_STARTS_BEFORE_BOOTBLOCK not being selected. The only case where
VBOOT_STARTS_BEFORE_BOOTBLOCK is selected is the verstage on PSP case,
so I find using the 'verstage_x86' target here a bit easier to
understand.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iab618d4b9e325b07a648b91fcdce99c63644fbfc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74196
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For compilation units that should be built for all stages that run on
the x86 cores in a newer AMD SoC, but can't be built for verstage on PSP
which is an ARM core, the 'all' target can't be used, since that would
result in the compilation unit also being added to the verstage target
in the verstage on PSP case. In order to not need to add a compilation
unit to the 'bootblock', 'verstage_x86', 'romstage', and 'ramstage'
targets in separate lines in the Makefile, introduce the 'all_x86'
target that adds a file to 'bootblock', 'verstage_x86', 'romstage',
'postcar', and 'ramstage'. The compilation units also need to be added
to the 'postcar' stage which is only present on the pre-Zen SoCs to be
able to also use the 'all_x86' target in common AMD code that is also
used in those pre-Zen SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9d0184182b931185990094d0874b49c0b5cb9f7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74150
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When enabled, the EC will mirror the firmware contained inside the
coreboot ROM. This allows it to be updated at the same time as
coreboot.
Enable the mirror flag if the installed EC firmware does not match
the target version or if a CMOS option, "manual_mirror_flag" is
set.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I377abbb37dc4d3e535e518a73e73969b25967daa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some third-party SSDs, from Samsung and WD, such as the 990 Pro and
WD Black 850X aren't initialised by coreboot, seemingly as coreboot
is too quick; debug builds work, and enabling hotplug does.
Add a cmos option `pci_hot_plug`, defaulting to enabled to allow these
SSDs to work.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I680211bc87153a5e6005d58040a94725c0973451
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This was added to solve Debian 10 not booting. Debian 10, which
now isn't the latest stable version works, so remove the
workaround that was included in the original port.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ic11f355eb218ff3bad00fff83537c99c1b6985bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72669
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Get boot performance timestamps from CSE and inject them into CBMEM
timestamp table.
990:CSME ROM started execution 0
944:CSE sent 'Boot Stall Done' to PMC 47,000
945:CSE started to handle ICC configuration 225,000 (178,000)
946:CSE sent 'Host BIOS Prep Done' to PMC 225,000 (0)
947:CSE received 'CPU Reset Done Ack sent' from PMC 516,000 (291,000)
991:Die Management Unit (DMU) load completed 587,000 (71,000)
0:1st timestamp 597,427 (10,427)
BUG=b:259366109
TEST=Able to see TS elapse prior to IA reset on Rex
Change-Id: I548cdc057bf9aa0c0f0730d175eaee5eda3af571
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73713
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
CSE performance data timestamps are different for version 1
Alder Lake/Raptor Lake and version 2 Meteor Lake. This patch
moves the current ADL/RPL timestamp definitions to a separate
header file. It marks current structure as version 1.
BUG=b:259366109
TEST=Boot to OS, check ADL/RPL pre-cpu timestamps.
Change-Id: I780e250707d1d04891a5a1210b30aecb2c8620d3
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73712
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
This patch updates the MTLRVP flash layout to allow CSE Lite FW
update and accommodate multiple ESx SoC stepping blobs.
SI_BIOS:
SI_EC: Removed
RW_SECTION_A/B: Increased by ~1.9MB.
RW_LEGACY: Reduce to 1MB.
RW_MISC: Reduce to 152KB.
- Drop RW_SPD_CACHE
- Optimize other sections
Additionally, moved RW_LEGACY under extended BIOS region.
For chromeos-debug-fsp.fmd
SI_BIOS:
RW_SECTION_A/B: Increased by ~1.2MB.
RW_LEGACY: Dropped
RW_MISC: Reduce to 152KB.
- Drop RW_SPD_CACHE
- Optimize other sections
BUG=b:271407315
TEST=Able to enable CSE update on MTLRVP and have free space
to add one more PUNIT FW to support different SoC stepping.
Signed-off-by: Usha P <usha.p@intel.com>
Change-Id: I8cfba861e6d3122b0795a5a8e589c67cebad9762
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73378
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Debug FSP is ~920KiB larger than release FSP and we don't have
sufficient space for MTL-P RVP flash layout.
Remove RW_LEGACY and split them into RW_SECTION_A/B so we can have a
room for it.
BUG=b:271407315
TEST=Build intel/mtlrvp with CONFIG_BUILDING_WITH_DEBUG_FSP.
Change-Id: Ief7dd39af018c4c1519ca80d1303085d8298cda6
Signed-off-by: Usha P <usha.p@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74193
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Add a driver to read and write EFI variables stored in a region device.
This is particularly useful for EDK2 as payload and allows to reuse
existing EFI tools to set/get options used by the firmware.
The write implementation is fault tolerant and doesn't corrupt the
variable store. A faulting write might result in using the old value
even though a 'newer' had been completely written.
Implemented basic unit tests for header corruption, writing existing
data and append new data into the store.
Initial firmware region state:
Initially the variable store region isn't formatted. Usually this is
done in the EDK2 payload when no valid firmware volume could be found.
It might be useful to do this offline or in coreboot to have a working
option store on the first boot or when it was corrupted.
Performance improvements:
Right now the code always checks if the firmware volume header is valid.
This could be optimised by caching the test result in heap. For write
operations it would be good to cache the end of the variable store in
the heap as well, instead of walking the whole store. For read
operations caching the entire store could be considered.
Reclaiming memory:
The EFI variable store is append write only. To update an existing
variable, first a new is written to the end of the store and then the
previous is marked invalid. This only works on PNOR flash that allow to
clear set bits, but keep cleared bits state.
This mechanisms allows a fault tolerant write, but it also requires to
"clean" the variable store for time to time. This cleaning would remove
variables that have been marked "deleted".
Such cleaning mechanism in turn must be fault tolerant and thus must use
a second partition in the SPI flash as backup/working region.
For now to cleaning is done in coreboot.
Fault checking:
The driver should check if a previous write was successful and if not
mark variables as deleted on the next operation.
Tested and working:
- Enumerate all existing variables
- Read variables
- Write variables
Change-Id: I8079f71d29da5dc2db956fc68bef1486fe3906bb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52564
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch avoids creating runtime ACPI for unused WIFI solutions.
For example: if the Rex SKU is with WIFI_CNVI then you don't need
to populate ACPI code for WIFI_PCIE.
FW_CONIG can be used for making those decisions.
TEST=No ASL entries being created for WIFI_PCIE if the FW_CONIG is
set to WIFI_CNVI.
Also, helped to save the boot time on google/rex (FSP-S API) by 9ms.
Change-Id: I60e4332d8d8c360fdf425b30513ff79209979e85
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74147
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The i2c.c compilation unit is added to all stages in all cases, so use
the all target instead of adding it to all stages separately. Also order
the all targets alphabetically.
TEST=Timeless build on Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie90380075a3c87d226cdcb0f41f7e94275eaaa42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The Intel Power and Performance (PnP) team requested to update the
following:
- TDC settings for RPL-U 15W variant should be 22A.
- TDC settings for RPL-P 28W variant should be 33A.
BUG=b:275694022
BRANCH=firmware-brya-14505.B
TEST=PnP validated performance impact with these settings on both
RPL-U 15W and RPL-P 28W
Change-Id: I1141414785a990b975e32ebc03e490b83082aab7
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74046
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Baieswara Reddy Sagili <baieswara.reddy.sagili@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch defines acpi_set_cpu_apicid_order() which orders the APIC IDs
based on APIC IDs of Performance cores and Efficient cores, calculates
the total core count and total Performance cores count, populates the
information in the cpu_apicid_order_info struct.
The helper function useful to present the Performance and Efficient
cores in order to OS through MADT table and _CPC object.
TEST=Verify the build for Gimble (Alder Lake board)
Change-Id: I8ab6053ffd036185d74d5469fbdf36d48e0021ce
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72131
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This updates energy performance preference value to all logical CPUs
when the corresponding chip config is true.
This patch is backported from
`commit 0bb2225718 ("soc/intel/alderlake: Add EPP override
support")`.
BUG=b:266522659
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8172276159fe3987dae36ec30ebceb76dd0ef326
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74154
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch updates the Rex flash layout to allow CSE Lite FW
update and accommodate multiple ESx SoC stepping blobs.
For default chromeos.fmd
SI_BIOS:
RW_SECTION_A/B: Increased by ~1.9MB.
RW_LEGACY: Reduce to 1MB.
RW_MISC: Reduce to 152KB.
- Drop RW_SPD_CACHE
- Optimize other sections
Additionally, moved RW_LEGACY under extended BIOS region.
For chromeos-debug-fsp.fmd
SI_BIOS:
RW_SECTION_A/B: Increased by ~1.2MB.
RW_LEGACY: Dropped
RW_MISC: Reduce to 152KB.
- Drop RW_SPD_CACHE
- Optimize other sections
BUG=b:262868089
TEST=Able to enable CSE update on google/rex and have free space
to add one more PUNIT FW for support different SoC stepping.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6146b36c4ce2c0141277eeb906d6ad1f503f3c78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66288
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
tsc_freq.c gets built into all stages, but the tsc_freq_mhz function it
implements calls the get_pstate_0_reg function which was only built into
ramstage. Since tsc_freq_mhz was only called in ramstage, commit
2323acab6a ("soc/amd/stoneyridge: implement and use get_pstate_0_reg")
didn't cause the build to fail, but better factor out the P-state-
related utility functions into a separate compilation unit and include
it in all stages that also include tsc_freq.c.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id3a3ee218f495be5e60a888944487704e7e8a1a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74145
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
monotonic_timer.c, tsc_freq.c and uart.c get added to all stage targets,
so just add those to the all stage targets. They still need to be added
to the smm stage target, since the all target doesn't add things to the
smm stage.
TEST=Timeless build results in identical image for Gardenia.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I16c02bc0ff54553f212b94d110abef6a7bdedbb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74144
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Debian removed Python 2 from their Sid repository and so it needs to be
removed from the Dockerfile as well.
Built and tested the Dockerfile with Python 2 removed. Still works.
Change-Id: If4e298dc275c1dfaf57cd4c3f8e5f89410318ec0
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71711
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Debug FSP is ~920KiB larger than release FSP and we don't have
sufficient space for rex flash layout.
Remove RW_LEGACY and split them into RW_SECTION_A/B so we can have a
room for it.
Note: This fmd will only used for internal testing/debugging and not for
the firmware in released devices.
BUG=b:262868089
TEST=Build google/rex with CONFIG_BUILDING_WITH_DEBUG_FSP.
Change-Id: I58b0af9c43c5d096dc80084497b39f13f67c25cd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Intel FSP has "debug" build which is not public, used for debugging by
approved developers. Add a Kconfig to indicate that coreboot is building
with debug version of FSP so we can adjust few things (i.e. flash
layout) in the case.
BUG=b:262868089
TEST=Able to build and boot google/rex.
Change-Id: I5555a2ab4182ad0036c42be6fea3d934ffd0db8c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74139
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
All AMD SoCs with Zen-based CPU cores are already using timestamps based
on the TSC counter, so use the existing common infrastructure instead of
reimplementing it in a similar way.
The behavior of the code changes slightly, but results in identical
timestamps. The timestamp_get implementation in soc/amd/common/block/cpu
divided the result of rdtscll() in timestamp_get by the result of
tsc_freq_mhz() and didn't override the weak timestamp_tick_freq_mhz
implementation that returns 1. The non AMD specific code returns the
result of rdtscll() in timestamp_get, but returns tsc_freq_mhz() instead
of 1 in timestamp_tick_freq_mhz, so we still get the correct timestamps.
TEST=The raw timestamps printed on the serial console are now multiplied
by the expected factor of the TSC frequency in MHz.
TEST=Normalized timestamps printed on the serial console by the x86 code
don't change significantly on Mandolin when comparing before and after
this patch. A slight variation in the timestamps is expected. An example
would be:
Before: CPU_CLUSTER: 0 init finished in 630 msecs
After: CPU_CLUSTER: 0 init finished in 629 msecs
TEST=The calculations of the time spent in verstage on PSP before
entering the bootblock on Guybrush result in similar times when
multiplying the value before the patch with the TSC frequency in the
case with the patch applied. The raw values printed on the serial
console by the verstage on PSP use the 1us time base, but the timestamp
logs that end up in CBMEM will be fixed up to use the same time base as
the x86 part of coreboot.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I57b732e5c78222d278d3328b26bb8decb8f4783e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Having L1.2 enabled on the SD port increases the kernel resume times by
between 30 & 40ms. This patch disables L1.2 on SD to get that time
back.
As with needing to have hotplug enabled on the SD card, this seems like
a driver issue, so hopefully that will get sorted out and this patch
can be reverted.
BUG=b:274025743
TEST=resume times are decreased.
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2c409fa2cd66c712c5ba7104635499d63fa0d2be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Set the `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag to request End-Of-Post
right after PCI enumeration and handle the command response at
`BS_PAYLOAD_BOOT'.
With these settings we have observed a boot time reduction of about 20
to 30 ms on brya0.
BUG=b:268546941
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post after PCI initialization and EOP message received at
`BS_PAYLOAD_BOOT'.
Change-Id: I81e9dc66f952c14cb14f513955d3fe853396b21c
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73922
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot supports three instances of sending EOP:
1. At CSE `.final' device operation
2. Early as with Alder Lake in chip_operations.init if
`SOC_INTEL_CSE_SEND_EOP_EARLY' is selected
3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if
`SOC_INTEL_CSE_SEND_EOP_LATE' is selected
Currently, Alder Lake uses #3 as it results in better and more stable
boot time. However, what would deliver even better result is to not
actively wait for CSE completion.
This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig
which split the action of sending EOP request and receiving EOP
completion response from the CSE.
This patch used in conjunction with #1 can significantly
improves the overall boot time on a Raptor Lake design. For example
`SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36
ms boot time improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 1 | 1020.052 | 971.272 |
| 2 | 1015.911 | 971.821 |
| 3 | 1038.415 | 1021.841 |
| 4 | 1020.657 | 993.751 |
| 5 | 1065.128 | 1020.951 |
| 6 | 1037.859 | 1023.326 |
| 7 | 1042.010 | 984.412 |
|----------+----------+-----------|
| Mean | 1034.29 | 998.20 |
| Variance | 4.76 % | 5.21 % |
The improvement is not stable but comparing coreboot and FSP
performance timestamps demonstrate that the slowness is caused by a
lower memory frequency (SaGv point) at early boot which is not an
issue addressed by this patch.
We also observe some improvement on an Alder Lake design. For example,
the same configuration on a kano board can deliver up to 10 ms boot time
improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 0 | 1067.719 | 1050.106 |
| 1 | 1058.263 | 1056.836 |
| 2 | 1064.091 | 1056.709 |
| 3 | 1068.614 | 1055.042 |
| 4 | 1065.749 | 1056.732 |
| 5 | 1069.838 | 1057.846 |
| 6 | 1066.897 | 1053.548 |
| 7 | 1060.850 | 1051.911 |
|----------+----------+-----------|
| Mean | 1065.25 | 1054.84 |
The improvement is more limited on kano because a longer PCIe
initialization delays EOP in the Late EOP configuration which make it
faster to complete.
CSME team confirms that:
1. End-Of-Post is a blocking command in the sense that BIOS is
requested to wait for the command completion before loading the OS or
second stage bootloader.
2. The BIOS is not required to actively wait for completion of the
command and can perform other operations in the meantime as long as
they do not involve HECI commands.
On Raptor Lake, coreboot does not send any HECI command after
End-Of-Post. FSP-s code review did not reveal any HECI command being
sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or
`END_OF_FIRMWARE' notifications.
If any HECI send and receive command has been sent the extra code
added in `cse_receive_eop()' should catch it.
According to commit 387ec919d9 ("soc/intel/alderlake: Select
SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first
boot after flashing of a Marasov board for instance) request coreboot
to perform a global request out of AFTER_PCI_ENUM notification. Global
request relies on a HECI command. Even though, we tested that it does
not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not
be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent
potential a global reset command to "conflict" with the EOP command.
BUG=b:276339544
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post sent soon after FSP-s and EOP message receive at
`BS_PAYLOAD_BOOT'. Verify robustness by injecting a
`GET_BOOT_STATE' HECI command with or without `heci_reset'. The
implementation always successfully completed the EOP before
moving to the payload. As expected, the boot time benefit of the
asynchronous solution was under some injection scenario
undermined by this unexpected HECI command.
Change-Id: Ib09dcf9140eb8a00807a09e2af711021df4b416f
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73619
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
In order for the code to find the correct VBIOS file in CBFS, remap the
revision ID in the RAVEN2_VBIOS_VID_DID case to the one that matches the
CBFS file name. This will make the code work as expected on devices with
the PCI ID RAVEN2_VBIOS_VID_DID and a revision != RAVEN2_VBIOS_REV.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I94412dc2e778e7c4f74e475cd49114a00a81b2ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74045
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a new port for the Intel DQ67SW desktop board. It is
microATX-sized with an LGA1155 socket and four DIMM sockets for DDR3
SDRAM.
A list of tested working and non-working features is in the
documentation page.
Change-Id: Ifc703f2d0ad45495e71d3f7799347430f5196791
Signed-off-by: Michael Büchler <michael.buechler@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Realtek RTL8111E NIC is currently not defined as a child device,
resulting in the on_board flag not being set to 1. This means that
Linux / udev will call the device enp4s0 rather than eno0, as is
appropriate for on-board ethernet devices.
This patch defines the NIC as a child device of PCIe port 6, so that
it's properly defined as an on-board device.
Change-Id: I2e1b65e4d27852297a739e332c52c15a8c81b858
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74090
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
To avoid having to calculate the length of a struct separately, rework
the code to give the struct a tag name, so that `sizeof()` can be used
instead. This involves refactoring the `get_emi_eeprom_vpd()` function
to return a struct instead of a union, so callers can no longer access
the EEPROM data as an array of bytes without additional code, but this
array view is only used inside `get_emi_eeprom_vpd()` when reading the
data from EMI.
Change-Id: Id1bc40939631baa131b5f60eadbfe42838294ebe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73983
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch avoids the redundant programming of SRAM BAR when
the SRAM PCI device is enabled. Rather read the PCH SRAM Base
Address Register while enabling crashlog feature.
Additionally, this patch relies on PCI enumeration to get the
SRAM BAR rather than hijacking the SPI temporary base address
which might have resulted in problems if SPI is disabled on
some platform with BAR being implemented.
TEST=Able to build and boot google/marasov and crashlog is working.
Change-Id: I8eb256aa63bbf7222f67cd16a160e71cfb89875a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
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).
BUG=b:273791621
TEST=emerge-nissa coreboot
Change-Id: I1a6013e0ad0c430d83bbbad4b92392c8c4815b0d
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This sets the location of the skyrim MP2 firmware within the mainboard's
blobs directory, and adds the Kconfig option to the mainboard directory
so that it can be enabled in a saved .config file.
The skyrim MP2 firmware is skyrim specific, so it should not be placed
in the main PSP AMD_BLOBS directory.
We will also only want to enable the MP2 firmware for chromeos builds as
it's not useful for non-chromeos builds.
BUG=b:259554520
TEST=Build MP2 firmware into image, see that it gets loaded
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I04be6f2d0b605d4eca37fd927a70310259dc106c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Instead of using the PSTATE SSDT generated by binaryPI, use the common
AMD code by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE. To
match the SSDT from binaryPI, set ACPI_SSDT_PSD_INDEPENDENT to n. There
are two differences to the binaryPI SSDT: Now coreboot includes the C1
state in the _CST package instead of just having the kernel add this due
to the ACPI_FADT_C1_SUPPORTED bit being set and the address of the
PS_STS_REG P state status MSR is written to the corresponding field of
the _PCT package instead of being 0.
TEST=On Careena the new P and C state ACPI packages are nearly identical
to the ones from the SSDT from binaryPI with the two functional
differences mentioned above.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icdf6bc8f0e0363f185a294ab84edcb51322e7eb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74023
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The C state ACPI packages binaryPI generates and passes to coreboot in
the PSTATE SSDT only include the C2 state, but the kernel will add the
C1 state to its usable C states in this case. The native C state code
will generate both the C1 and C2 state packages to be more complete and
also to be more in line with the other AMD SoCs.
The code added in this commit isn't used yet, but will be used as soon
as Stoneyridge will be using the common AMD generate_cpu_entries by
selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE once all needed
helper functions are implemented for Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06f90306ac196704e0102d0da6eab03f51513c29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Use get_pstate_core_freq instead of open-coding the calculations in
tsc_freq_mhz. In the case of the CPU frequency divider being 0,
get_pstate_core_freq will return 0; in this case that shouldn't happen,
TSC_DEFAULT_FREQ_MHZ will be used as frequency, since for the TSC
frequency it's better to err on the end of the expected frequency being
too high which will cause longer than expected delays instead of too
short delays.
Now that the code is using get_pstate_core_freq, this code is valid for
Glinda too, so also remove the comment on the
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option being selected in the Glinda
Kconfig. This Kconfig option will be renamed in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I01168834d4018c92f44782eda0c65b1aa392030d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Factor out the get_pstate_core_freq function from the SoC's acpi.c files
to both avoid duplication and to also be able to use the same function
in the TSC frequency calculation in a follow-up patch. The family 17h
and 19h SoCs use the same frequency encoding in the P state MSRs while
the family 1Ah SoCs use a different encoding. The family 15h and 16h
SoCs use another encoding, but since this isn't implemented in
Stoneyridge's acpi.c, this will be added in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Due to a non-constant TSC rate before the microcode update is applied,
the Performance Time Stamp Counter is used instead. To clarify this, add
a comment to the timestamp_get implementation. See commit 24079323d4
("soc/amd/stoneyridge: provide alternate monotonic timer") and the
description of the TscInvariant bit in CPUID Fn8000_0007_EDX Advanced
Power Management Information in the public version of BKDG #55072 Rev
3.09 for more details.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I824b372c36fa6f3eb912469b235a9474f6a58ff5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
There are two conditions within the config space dump code, one to
print offset, one at the end to put a newline. Tweak the printk
strings so the first conditioned printk does it all and move the
second printk out of the loop to the very end.
Change-Id: Ie9dc744406ba20412892df96720e88e24c3d52bc
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73887
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Meteor Lake onwards Intel FSP will generate the Trace Hub related
HOB if the Trace Hub is configured to save data in DRAM. This memory
region is used by Trace Hub to store the traces for debugging purpose.
This driver locates the HOB and marks the memory region reserved so
that OS does not use it.
Intel Trace Hub developer manual can be found via document #671536 on
Intel's website.
Change-Id: Ie5a348071b6c6a35e8be3efd1b2b658a991aed0e
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Fix the VGA_BIOS_ID IDs to match the PCI IDs in the VBIOS binaries and
the PCI ID Stoneyidge's map_oprom_vendev returns. This fixes the problem
that the display wasn't initialized due to not finding the VBIOS file in
CBFS. This bug in the Stoneyridge Kconfig was unmasked by commit
42f0396a10 ("device/pci_rom: rework PCI ID remapping in
pci_rom_probe").
TEST=Display in Careena lights up again.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4d1e6a3a65d7d7b07f49df9ce90620b79d9a2d78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74019
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Currently ifdtool --validate will not correctly validate the FMAP
against the IFD regions, since it will compare the IFD bios region with
an FMAP region called SI_BIOS.
It's probably a good idea to define default name for the BIOS FMAP
region like we have for 'COREBOOT' or 'FMAP' FMAP region.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I55eddfb5641b3011d4525893604ccf87fa05a1e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
On systems that do not provide their own *.fmd (Flashmap) file, we
fall back to a default flashmap file. That file however does not contain
the blobs (ME, GBE ...), that are usually placed below the BIOS Flashmap.
It can therefore easily happen that the placement of the blobs collides
with the placement of the BIOS region (e.g. if CBFS_SIZE is big enough).
The fmaptool can't catch that, since it does not know of the blobs
placement.
This patch basically maps the regions described in the IFD (Intel
Firmware Descriptor) to the default Flashmap.
Test: Build and see that build/fmap.fmd contains all blobs now (on intel
systems that are supported by the ifdtool)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I82cb252fff456773af69943e188480a4998736fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Set open-drain GPIOs for ChromeOS as input and bias-disable mode.
After applying this patch, the voltage of these pins will become the
expected value 1.8V (previously 1.0V), preventing wrong judgement of
low/high.
Reference document:
MT8188G_GPIO_Formal_Application_Spec_V0.3
BUG=b:274058085
TEST=build pass
Change-Id: I057716df6c59efb84fc395109db022b82ce528c4
Signed-off-by: jason-ch chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73963
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A core voltage ID larger than 0xff shouldn't happen, since SVI2's core
VID is only 8 bit long. In order for making it more difficult to use
this function in a wrong way that results in a very wrong voltage being
returned, also return 0 for those invalid core VID values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95417c45db86cd2373879cdad8a07fb9eb8dfdda
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74000
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of implementing the conversion from the raw serial voltage ID
value to the voltage in microvolts in every SoC, introduce the
SOC_AMD_COMMON_BLOCK_SVI[2,3] Kconfig options for the SoC to select the
correct version, implement get_uvolts_from_vid for both cases and only
include the selected implementation in the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I344641217e6e4654fd281d434b88e346e0482f57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73995
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set orientation to LB_FB_ORIENTATION_BOTTOM_UP to align the volume
up/down direction with menu up/down in FW screen.
BUG=b:274749478
TEST=see FW screen in portrait mode.
TEST=volume key behaves as expected
Change-Id: If32859c4bf256c97147622ff04a17fc2ec80303d
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Move EC FW from a CBFS file to an FMAP entry and rename the EC signature
section to EC_SIG.
An offset of (16M - 512K) was chosen to line up the EC FW before the
RW_MRC_CACHE.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9b19d92043790b10acd20fbfdf394d5bd67b8295
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70695
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This patch moves USB Port Status and Control (PORTSC) Reg definition
into IA common code to allow other SoC code to reuse it without
redefining the same for each SoC.
TEST=Able to build and boot google/taeko where USB wake is working.
Change-Id: I6b540eab282403c7a6038916f5982aa26bd631f8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Picasso and Cezanne use the serial voltage ID 2 standard to communicate
the CPU voltage to the voltage regulator module on the mainboard, while
Mendocino, Phoenix and Glinda use the serial voltage ID 3 standard for
this. Both standards encode the voltage in a different way, so add the
serial VID version number to the defines to clarify for which version
the define is.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8ddab8df27c86dc2c70a6dfb47908d9405d86240
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73994
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Mendocino uses the SVI3 standard for CPU core voltage control which uses
9 data bits instead of the 8 in the SVI2 case and also calculates the
actual voltages with a different formula. The Mendocino code uses the
correct formula since commit 8d2bfbce23 ("soc/amd/sabrina/acpi:
Correct VID decoding on Sabrina"), but the MSR definition in the PPR
hasn't been updated to show the additional bit. The definition of the
register that is mirrored by these MSRs descries this 9th CPU voltage ID
bit though. Since this bit is expected to be zero, this shouldn't cause
a change in behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I05acd239300836a34e40cd3f31ea819b79766e2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73969
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Atlas stores VPD (Vital Product Data) in an I2C EEPROM, which is only
connected to the EC. In order for the host (x86) to be able to access
the VPD, the EC reads the EEPROM contents into a buffer in EC RAM and
provides the host with read-only access to this EC RAM buffer through
EMI (Embedded Memory Interface) 0.
The VPD layout is designed to be extensible yet backwards compatible.
The code in coreboot uses the revision field to know which fields are
valid, and will populate the rest with fallback values.
Use the serial number and part number in VPD to populate SMBIOS tables.
Change-Id: I2d3d70fee22548daa73ef98af56c98e950dc5e9d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Implement initial support for EMI (Embedded Memory Interface), which
Microchip describes as "a standard run-time mechanism for the system
host to communicate with the Embedded Controller (EC) and other logical
components". EMI allows the host to access regions of EC memory without
requiring any assistance from the EC.
For now, Atlas only uses EMI 0. This change enables EMI 0, subsequent
commits will read data from it.
Change-Id: Ia899ae71e97f9fc259397dfb5fb84ca06545f5d8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
When encountering really incompatible memory configurations, post a
standard POST_RAM_FAILURE code when dying. Gone are the "HALT"
messages that no longer serve any good purpose, instead fatal messages
are edited to always end with "!" to make them stand out even with
loglevel prefix off.
Change-Id: Ie1b9e5a0415e4c64b1f4e935689263f62db012b2
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since we already have and use the pstate_msr union in get_pstate_info,
also pass it directly to the get_pstate_core_freq and
get_pstate_core_power function calls avoids having to sort-of convert
the msr_t type parameter in the implementations of those two functions.
In amdblocks/cpu.h a forward declaration of the pstate_msr union is used
since soc/msr.h doesn't exist in the two pre-Zen SoCs that also include
amdblocks/cpu.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I112030a15211587ccdc949807d1a1d552fe662b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73926
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SKU ID is not really used on Geralt. Both ADC channels 4 and 5 will
be used for LCM ID on derived projects. For Geralt reference board, only
PANEL_ID_LOW_CHANNEL is valid.
BRANCH=none
BUG=b:247415660
TEST=boot Geralt proto0 and see FW screen in DEV mode.
Change-Id: I77a3caadc1b0be5bf39dd2cf73ea1df88f9a09ea
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73874
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs which will be
implemented in a following patch. PPR #57254 Rev 1.52 was used as a
reference. This patch adds and uses the cpu_vid_8 bit which is the 9th
bit of the voltage ID specified in the SVI3 spec. The way the CPU
frequency is encoded in the PSTATE MSR has changed compared to Phoenix,
so also update the comment in the SoC's Kconfig file that the selected
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H is likely incompatible which will be
addressed in the future.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3d1878ce4d9bc62ac597e6f71ef9630491628698
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54 were used as a reference as
well as the reference code. This patch also adds and uses the cpu_vid_8
bit which is the 9th bit of the voltage ID specified in the SVI3 spec.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia024d32ae75cf2ffbc2a2e86a8b3af3dc6cbad61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Intel Client PCIe* controller expects each device should drive the
SRCCLKREQ#. If the GPIO is set to native mode for a device, which does
not support SRCCLKREQ#, then during RTD3 exit link would not be
established. Because controller samples the SRCCLKREQ# before
detecting the device and break L1 as the system might enter L1SS as
controller detects SRCCLKREQ# as de-asserted.
As a workaround the Pins must not be configured in Native Mode (CLKREQ
native function). Therefore here they are not configured at all.
source: 689882 (intel document ID)
So apparently hardware doesn't sample SRCCLKREQ Pin if it's not
configured as such.
That workaround suggestion however also brought a patch to FSP, which
in turn causes the same bug (even if SRCLKREQ are not configured).
Usually in order to make use of root port power saving features (e.g.
clock gating), the Root port must either be disabled or a CLKREQ Pin
must be configured. The patch however removed that check before
enabling power management for the rootport.
Workaround (until FSP is fixed):
pretend to FSP that the rootports have a CLKREQ Pin attached, by
supplying them in the FSP UPDs. That will cause FSP to configure the
CLKREQ Pin and enable power management for said rootport, but it will
not crash on L1 entry/exit. That has been done on the Atlas board
(as workaround) for a short period of time (before applying FSP Fix)
like this:
// RP 5 (the rootport you want to fix)
- memupd->FspmConfig.PcieClkSrcUsage[2] = 4;
// e.g. choose a clkreq pin that is not routed out
- memupd->FspmConfig.PcieClkSrcClkReq[2] = 0;
Furthermore disable CpuPcieRpClockReqMsgEnable FSP-M options to prevent
the same issue, but for CPU root ports. If not done the following will
happen in coreboot:
[DEBUG] PCI: 00:06.2 scanning...
[SPEW ] do_pci_scan_bridge for PCI: 00:06.2
[DEBUG] PCI: pci_scan_bus for bus 02
[DEBUG] PCI: 02:00.0 [1344/5410] enabled
[INFO ] PCIe: Common Clock Configuration already enabled
[INFO ] PCIE CLK PM is not supported by endpoint
[INFO ] ASPM: Enabled L1
[EMERG] CPU Index 9 - APIC 32 Unexpected Exception:18 @ 10:76aeb93f - Halting
[EMERG] Code: 0 eflags: 00000046 cr2: 00000000
[EMERG] eax: 00000000 ebx: 00000009 ecx: 00000000 edx: 00000000
[EMERG] edi: 00000009 esi: 76b218c4 ebp: 00000000 esp: 76b29100
[EMERG] 0x76aeb8f8: c4 2c 5b 5e 5f 5d c3 56
[EMERG] 0x76aeb900: 53 83 ec 14 65 a1 00 00
This patch is only a workaround for the issue and it will be reverted as
soon as FSP is fixed.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I324bc6ab158d4b3b5ae9d3bade21076b44bc8892
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Add platform cpu info for known microcode, print cpuid & processor
branding string. This will print as in the following example:
CPU: Intel(R) Xeon(R) Platinum 8468H
CPU: ID 806f6, Sapphire Rapids E3, ucode: 2b000130
CPU: AES supported, TXT supported, VT supported
Change-Id: I9c08fb924aad81608f554523432ab6a549b1b75f
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
While doing the initial port of this board, hda_verb.c was mainly put
together by guesswork and borrowing the pinouts from similar boards.
While it was mostly correct, not everything was tested properly.
This change takes the values of vendor BIOS version P1.80, obtained by
running `cat /sys/class/sound/hwC0D0/init_pin_configs` while booted
from the vendor firmware.
7.1 channel audio and front panel audio are now also tested.
Change-Id: I60b0f55c203f42b220f13cf943912f7428476792
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73935
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Fabian Groffen <grobian@gentoo.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Most of the code is taken from 2570p, adjusted with autoport, SuperIO
from 8470p and inteltool, GPIO config from inteltool via autoport.
The laptop works well under coreboot with SeaBIOS 1.16.1 payload,
running Debian GNU/Linux with kernel 6.1.15.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I854104516d5b6fbd78ee2989197000a7dbb85136
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73856
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This board inherited cmos.default and cmos.layout from asrock/h77pro4-m,
which has two CPU fan headers and a CMOS option to select which one will
provide the tachometer source.
However, the code for this was never implemented. Moreover, this board
only has one CPU fan header, rendering the option useless. This change
removes the option from cmos.layout and cmos.default.
Change-Id: Ib4580e243781e2340af2cefb825f26ee896c2bd3
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73931
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Of the 13 mainboards that implement mainboard_should_reset_usb() hook,
all but one do the same: Stop MRC from resetting USB when resuming
from S3 suspend.
This hook turns out is only here to facilitate a USB reset workaround
on samsung/stumpy for an old ChromeOS kernel which is no longer needed.
Drop the workaround, the hook, and headers no longer used.
roda/rv11/early_init.c is left with no useful code after this patch,
so drop it entirely from both bootblock and romstage.
Change-Id: Ib3a5a00c0a6b1528e39435784919223d16b3914e
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Having these two functions public allow "asynchronous"
HECI command implementation.
Typically, these function can be use to implement an asynchronous
End-Of-Post.
BUG=b:268546941
BRANCH=firmware-brya-14505.B
TEST=Successful compilation for brya0
Change-Id: I7d029bb9af4b53f219018e459d17df9c1bd33fc1
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The default SPD size is set to 256 bytes, instead of 512 for
LPDDR4/DDR4 if not overridden by the mainboard Kconfig. This caused
the SMBus libraries to read only the lower half of the DIMM SPD on
protectli/vault_ehl. The lower half of the SPD passed to FSP causes
a bug in DIMM change detection, which relies on the CRC of the
manufacturer bytes in the upper half of the SPD (CRC of zero bytes
always gives zero so no change was assumed). Setting the DIMM SPD size
to 512 fixes it.
Setting the SPD size in SoC will also avoid such problems in the future
Elkhart Lake ports. Elkhart Lake supports only LPDDR4/DDR4 so providing
the correct default of 512 bytes is an obvious thing to do.
TEST=Boot Protectli VP2420 (vault_ehl) with different DIMMs and see
FSP is retraining the memory instead of doing the fastboot with old
DIMM data.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I998ed8781951034419cadc26c04ff1e0a124b267
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73933
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames all references of `top_of_ram` (TOM) in IA common
`basecode` module (for example: functions, variables, Kconfig,
Makefile and comments) with `ramtop` aka top_of_ram to make it more
meaningful and to avoid conflicts with Intel SA chipset TOM registers.
BUG=Able to build and boot google/rex with the same ~49ms savings
in place.
Change-Id: Icfe6300a8e4c5761064537fb256cfecbe2afb2d8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73881
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the host supports CXL, get proximity domain info from FSP HOB. The
proximity domains may include both processor domains and CXL domains.
Add header definition for proximity domain.
Add CXL memory into memory map.
Change-Id: If3f856958a3e6ed3909240ee455bb639e487087f
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Add a new Kconfig CONFIG_ENABLE_FSP_ERROR_INFO option to enable
retrieval of FSP_ERROR_INFO_HOB from HobList created by FSP.
Such a HOB could be generated by Intel SPR-SP FSP.
This HOB data is defined in Intel®Firmware Support Package
External Architecture Specification v2.1 Doc#611786-2.1.
Change-Id: I812d1c22c1bbe5146630948ca6ca12c46ffd5504
Signed-off-by: Ray Han Lim, Ng <ray.han.lim.ng@intel.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Commit 6a6ac1e0b9 ("arch/x86/cpu: introduce and use
device_match_mask") added the device_match_mask element to the
cpu_device_id struct and uses it to be able to mask off for example the
stepping ID when checking for CPU table entry that matches the silicon
the code is running on. Commit 3ed903fda9 ("soc/intel/xeon_sp/spr: Add
Sapphire Rapids ramstage code") added a CPU table that was missing the
device_match_mask which results in this being 0, so the first entry of
the CPU table would match for any Intel CPU which isn't the intended
behavior. Also use CPU_TABLE_END instead of the final {0, 0, 0} array
element.
Likely all entries could be replaced by one entry that uses the
CPUID_ALL_STEPPINGS_MASK instead of the CPUID_EXACT_MATCH_MASK, but
that's out of scope for this fix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib0be2e9fe3c31487c83c9b1cf305a985416760b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
UBSAN complains about "shift out of bounds", likely because integer
literals are signed by default and the result of the operation will
shift into the sign bit, yielding a negative value. However, as the
negative value is then casted to an unsigned type, it works anyway.
To make UBSAN happy, make sure the two troublesome integer literals
are unsigned so that there's no sign bit to shift into.
Tested on out-of-tree Asrock Z97 Extreme6, UBSAN now dies elsewhere.
Link: https://ticket.coreboot.org/issues/449
Change-Id: Iaf8710a5ae4e05d9f41f40f9e3617e155027800c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72806
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Programming MTRR happens later in the
CONFIG_SOC_INTEL_COMMON_BLOCK_CPU_MPINIT codepath.
fast_spi_cache_bios_region() assumes an existing MTRR solution from
x86_setup_mtrrs_with_detect().
This fixes a problem introduced by 829e8e6 "soc/intel: Use common
codeflow for MP init".
Change-Id: I9b6130cf76317440ebe7a7a53e460e2b658d198e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73836
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Resolve this message:
[INFO ] PCI: Static device PCI: 00:16.3 not found, disabling it.
The ME KT is very unlikely to exist on a consumer device as it is only
used in combination with Intel AMT. AMT comes only with the corporate
ME variant, whilst this mainboard is consumer grade.
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: I15dd586db9cb4b2dd615b7bf78665df86a32cb9f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73829
Reviewed-by: Kevin Keijzer <kevin@quietlife.nl>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Since commit 2f6b7d557d ("amdfwtool: Move the filling of table headers
into functions"), the combo_psp_directory union element in the
embedded_firmware is unused and the new_psp_directory element is used in
all places, so replace the union of new_psp_directory and
combo_psp_directory with just the new_psp_directory struct element.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I35d339b3084ec8f93210095c233f5e68296d0013
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Replace the legacy ACPI Processor() object as it only
supports 8bit IDs and thus no more than 255 cores. Use the
new ACPI Device() object that supports more than 255 cores.
Test:
- Observed no ACPI errors on IBM/SBP1 and Linux 5.15 running
384 CPU cores in total.
- Verified on Intel ADL RVP with 20 cores that Linux 5.15 is
still working without errors.
Change-Id: I309c06b6824704c84fd16534655334a6f269904a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73578
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Intel Client PCIe* controller expects each device should drive the
SRCCLKREQ#. If the GPIO is set to native mode for a device, which does
not support SRCCLKREQ#, then during RTD3 exit link would not be
established. Because controller samples the SRCCLKREQ# before
detecting the device and break L1 as the system might enter L1SS as
controller detects SRCCLKREQ# as de-asserted.
As a workaround the Pins must not be configured in Native Mode (CLKREQ
native function). Therefore here they are not configured at all.
source: 689882 (intel document ID)
So apparently hardware doesn't sample SRCCLKREQ Pin if it's not
configured as such.
That workaround suggestion however also brought a patch to FSP, which
in turn causes the same bug (even if SRCLKREQ are not configured).
Usually in order to make use of root port power saving features (e.g.
clock gating), the Root port must either be disabled or a CLKREQ Pin
must be configured. The patch however removed that check before
enabling power management for the rootport.
Workaround (until FSP is fixed):
pretend to FSP that the rootports have a CLKREQ Pin attached, by
supplying them in the FSP UPDs. That will cause FSP to configure the
CLKREQ Pin and enable power management for said rootport, but it will
not crash on L1 entry/exit. That has been done on the Atlas board
(as workaround) for a short period of time (before applying FSP Fix)
like this:
// RP 5 (the rootport you want to fix)
- memupd->FspmConfig.PcieClkSrcUsage[2] = 4;
// e.g. choose a clkreq pin that is not routed out
- memupd->FspmConfig.PcieClkSrcClkReq[2] = 0;
Furthermore disable CpuPcieRpClockReqMsgEnable FSP-M options to prevent
the same issue, but for CPU root ports. If not done the following will
happen in coreboot:
[DEBUG] PCI: 00:06.2 scanning...
[SPEW ] do_pci_scan_bridge for PCI: 00:06.2
[DEBUG] PCI: pci_scan_bus for bus 02
[DEBUG] PCI: 02:00.0 [1344/5410] enabled
[INFO ] PCIe: Common Clock Configuration already enabled
[INFO ] PCIE CLK PM is not supported by endpoint
[INFO ] ASPM: Enabled L1
[EMERG] CPU Index 9 - APIC 32 Unexpected Exception:18 @ 10:76aeb93f - Halting
[EMERG] Code: 0 eflags: 00000046 cr2: 00000000
[EMERG] eax: 00000000 ebx: 00000009 ecx: 00000000 edx: 00000000
[EMERG] edi: 00000009 esi: 76b218c4 ebp: 00000000 esp: 76b29100
[EMERG] 0x76aeb8f8: c4 2c 5b 5e 5f 5d c3 56
[EMERG] 0x76aeb900: 53 83 ec 14 65 a1 00 00
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If2acdc16f37cdae0292f55d210b058f82179bfb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In cases where there are limitations on the connected device behind the
PCIe root port it can be necessary to limit the speed. The FSP parameter
'PcieRpPcieSpeed' allows to set the speed limit.
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: I9fc24de1682279e4ae4c090147a6ef7995b441bc
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic489b8e1332dde2511647c065ccbdef541bcbcc5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If92a4773c669ac2df45396eee52f6de780adbdca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
TEST=The coreboot-generated SSDT containing the P state packages stays
identical on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8dc293351f9941cfb8a9c84d9fb9a4fd76361d5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
[ERROR] PNP: 002e.b 62 io size: 0x0000000002 not assigned in devicetree
[ERROR] PNP: 002e.b 70 irq size: 0x0000000001 not assigned in devicetree
Set them to zero. This is also what the values are set to using vendor
firmware 1.90.
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: Ide5980224f042e3da289aa28a18042ee8505d943
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73812
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Resolve this message:
[INFO ] PCI: Static device PCI: 00:16.3 not found, disabling it.
The ME KT is very unlikely to exist on a consumer device as it is only
used in combination with Intel AMT. AMT comes only with the corporate
ME variant, whilst this mainboard is consumer grade.
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: Ie1f0bad276f5c124d8d52772330982bf1342c72e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Several FSP HOBs processing codes are similar to Intel Cooperlake-SP
codes in soc/intel/xeon_sp/cpx.
Register datasheet please reference Sapphire Rapids EDS Vol2 Doc#612246
and Emmitsburg PCH EDS Doc#606161.
Change-Id: Ia022534e5206dbeec946d3e5f3c66bcb5628748f
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch modifies the serial msg log_level at runtime to highlight
an ERROR if the DIMM count is zero. It would help to draw the
attention while parsing the serial msg and catch any underlying issue.
TEST=Able to see ERROR msg while booting google/rex with FSP v3064
Without this patch:
[DEBUG] 0 DIMMs found
With this patch:
[ERROR] No DIMMs found
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iacf41efecb4962f91cf322bbc50636dc44033e3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73756
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current VBT causes problems with Windows 10. Once the Intel driver
is used instead of the generic graphics driver, the display turns off
although the system keeps running normally. Linux has no issues. It had
been extracted from the vendor video BIOS, which in turn had been
extracted from the vendor firmware.
This change replaces the VBT with one that was dumped through debugfs
and the drm/i915 driver in Linux, booted from the vendor firmware at
version 2.10 (beta). It fixes the issue with the Intel graphics driver
on Windows 10.
Change-Id: Icbb3950b37dad5ed308f3bafb73b71859227d26b
Signed-off-by: Michael Büchler <michael.buechler@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73711
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Certain C source files for coreboot stages require fmap_config.h to
be present. When building coreboot using multiple jobs the dependency
is not always satisfied due to race condition and results in make
error. Work around it by adding fmap_config.h to stage C deps.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3a70beedf2eb1c018c5ff98163904253f9a87a61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69819
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Updating from commit id 9881bb93a:
2022-11-21 19:12:00 +0100 - (Merge "docs(spm): update threat model" into integration)
to commit id 4c985e867:
2023-03-14 19:53:19 +0100 - (Merge "fix(cpus): workaround for Neoverse V1 errata 2743233" into integration)
This brings in 547 new commits.
Note: commit id 1f49db5f solves the "LOAD segment with RWX permissions"
error when binutils 2.39 is used.
Change-Id: I35355040c6958d470d78002048e78a06fd7f6f02
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73735
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The HSPHY firmware must be downloaded to DMA-allowed host address
space. Check for DMA buffer presence and use it as the buffer for HSPHY
firmware to be downloaded from CSME.
TEST=Successfully load HSPHY firmware to CPU on MSI PRO Z690-A DDR4
with DMA protection enabled.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I88edda26a027b557eeaba80426a5b7be7199507d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68556
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new common block with VT-d/IOMMU support. The patch adds an
option to enable DMA protection with PMR. However the payload and
OS must support VT-d in order to properly handle I/O devices.
TEST=Enable DMA protection on MSI PRO Z690-A DDR4 and observe
the I/O devices like USB and NVMe fail to enumerate in UEFI
Payload (basically proving that DMA protection works).
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Id7edf982457c1139624e5cd383788eda41d6a948
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Add supported memory parts in mem_parts_used list, and generate SPD ID
for these parts.
DRAM Part Name ID to assign
MT62F512M32D2DR-031 WT:B 0 (0000)
H9JCNNNBK3MLYR-N6E 0 (0000)
H58G56BK7BX068 1 (0001)
MT62F1G32D2DS-026 WT:B 1 (0001)
K3KL8L80CM-MGCT 1 (0001)
H58G66BK7BX067 2 (0010)
MT62F2G32D4DS-026 WT:B 2 (0010)
K3KL9L90CM-MGCT 2 (0010)
BUG=b:273791621
BRANCH=firmware-nissa-15217.B
TEST=run part_id_gen to generate SPD id
Change-Id: I82919919ec33d6bf9d86132490df754873b5df88
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch passes a hint flag to QcLib on Lazor boards to tell it to
limit the DDR frequency for certain memory parts (8GB Hynix) to work
around a board-specific stability issue.
BRANCH=trogdor
BUG=b:267387867
TEST=Validated on qualcomm sc7180 development board
Change-Id: I45915cf93d2a57ff0c9710f2ac36dfb665eff1c6
Signed-off-by: Sudheer Kumar Amrabadi <samrabad@codeaurora.org>
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Create the yavilla variant of the nissa reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:273791621
BRANCH=firmware-nissa-15217.B
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_YAVILLA
Change-Id: I4539090da5e1db474a8f58a42aecc38659959f75
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add new memory MT62F2G32D4DS-026 WT:B to replace H9JCNNNBK3MLYR-N6E．
Add new memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
DRAM Part Name ID to assign
MT62F512M32D2DR-031 WT:B 0 (0000)
MT62F1G32D4DR-031 WT:B 1 (0001)
MT62F1G32D2DS-026 WT:B 2 (0010)
MT62F2G32D4DS-026 WT:B 3 (0011)
K3LKBKB0BM-MGCP 4 (0100)
BUG=b:273177939
BRANCH=None
TEST=emerge-skyrim coreboot
Signed-off-by: Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com>
Change-Id: I545bd8d9f88e7b3055acef4066769e6fcb766cc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73681
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adding EC_HOST_EVENT_PANIC to SCI mask allows the EC to interrupt the
Kernel when an EC panic occurs. If system safe mode is also enabled
on the EC, the kernel will have a short period to extract and save info
about the EC panic.
BUG=b:268377440
BRANCH=firmware-dedede-13606.B
TEST=Observe kernel ec panic handler run when ec panics
Change-Id: I24f929ae60a406d0091956dc6cab3e2876ca23e9
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The regex getting rid of lines containing a '*' didn't match anything
in any configs, so get rid of it. There's nothing in the amdfwtool
dataparse.c file that would match it either.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I05aaf46cfb479cebab9234a47574073335984a5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
After adding the ability to add paths into the amdfw.cfg file for the
amdfwtool, the dependency generation needs to be updated to not add
the firmware location in front of those values.
This also allows us to filter out the MP2 binaries as dependencies
based on whether or not the Kconfig value is set.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3a9b9c8246808dc60020a32a7d9d926bc5e57ccd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
If recovery APCB is not passed, amdfwtool will build amdfw*.rom with
AMD_BIOS_APCB_BK entry pointing to the same offset as AMD_BIOS_APCB
entry. This will help to save 40 KiB flash space in each FW slot. On
ChromeOS, this means saving ~120 KiB flash space.
BUG=b:240696002
TEST=Build and boot to OS in Skyrim.
Change-Id: Ib3bbc1eededae20b2cd48f514722a207c46536a0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73662
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If Recovery/Backup APCB is not passed, then AMD_BIOS_APCB_BK entry is
not populated. But PSP expects that bios directory entry to be
populated. Also on mainboards where both APCB and recovery APCB are same
(eg. Skyrim), 2 copies of the same APCB are added to amdfw*.rom. Update
amdfwtool to support not passing recovery/backup APCB. If the recovery
APCB is not passed, then populate AMD_BIOS_APCB_BK entry and make it
point to the same offset as AMD_BIOS_APCB entry.
BUG=b:240696002
TEST=Build and boot to OS in Skyrim. Ensure that the device can enter
recovery mode. Perform multiple suspend/resume cycles.
Change-Id: I031ba817573cd35160f5e219b1b373ddce69aa6b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73661
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Meteor Lake decides to enable early caching of the TOM region to
optimize the boot time by selecting `SOC_INTEL_COMMON_BASECODE_TOM`
config.
TEST=Able to build and boot google/rex to ChromeOS and reduce the boot
time by 77 ms.
Without this patch:
950:calling FspMemoryInit 936,811 (19,941)
951:returning from FspMemoryInit 1,041,935 (105,123)
With this patch:
950:calling FspMemoryInit 905,108 (20,103)
951:returning from FspMemoryInit 964,038 (59,929)
Change-Id: Iebb3485b052386b43d5bccd67a04e6115cbcc20d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73274
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables early caching of TOM region to optimize the boot
time if valid mrc cache is found (i.e. except the first boot after
flashing/updating few AP firmware image).
TEST=Able to build and boot google/rex to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia575ad0f99d5b0fd015e40b0862e8560700f6c83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch implements a module that can store the top_of_ram (TOM)
address into non-volatile space (CMOS) during the first boot and
use it across all consecutive boot.
As top_of_ram address is not known until FSP-M has exited, it
results into lacking of MTRR programming to cache the 16 MB TOM,
hence accessing that range during FSP-M and/or late romstage causing
long access times.
Purpose of this driver code is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
TEST=Able to build and boot google/rex to ChromeOS.
Without this patch:
950:calling FspMemoryInit 936,811 (19,941)
951:returning from FspMemoryInit 1,041,935 (105,123)
With this patch:
950:calling FspMemoryInit 905,108 (20,103)
951:returning from FspMemoryInit 987,038 (81,929)
Change-Id: I29d3e1df91c6057280bdf7fb6a4a356db31a408f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73272
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the microcode update can
be directly written to the raw value instead of needing to split it into
the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I51c84164e81477040a4b7810552d3d65c0e3656b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the bootblock_resume_entry
can be directly written to the raw value instead of needing to split it
into the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7ebab1784ec592e18c29001b1cf3ee7790615bf8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
When cbmem is initialized in romstage and postcar placed in the stage
cache + cbmem where it is run, the assumption is made that these are
all in UC memory such that calling INVD in postcar is OK.
For performance reasons (e.g. postcar decompression) it is desirable
to cache cbmem and the stage cache during romstage.
Another reason is that AGESA sets up MTRR during romstage to cache all
dram, which is currently worked around by using additional MTRR's to
make that UC.
TESTED on asus/p5ql-em, up/squared on both regular and S3 resume
bootpath. Sometimes there are minimal performance improvements
when cbmem is cached (few ms).
Change-Id: I7ff2a57aee620908b71829457ea0f5a0c410ec5b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37196
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This separates the SPL fusing function into a separate C file which can
be excluded if it is not needed. This allows the psp_set_spl_fuse()
function to be made static again as the state of the function will
always match the boot_state entry.
Move the required #defines to the common header file so they can be
used by both psp_gen2.c & spl_fuse.c.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ifbc774a370dd35a5c1e82f271816e8a036745ad5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73655
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Even though right now TSEG will always be located below 4GB, better not
make assumptions in the SMM relocation code. Instead of clearing the
higher 32 bits and just assigning the TSEG base and per-core SMM base to
the lower 32 bits of the MSR, assign those two base addresses to the raw
64 bit MSR value to not truncate the base addresses. Since TSEG will
realistically never be larger than 4GB and it needs to be aligned to its
power-of-two size, the TSEG mask still only needs to affect the lower
half of the corresponding MSR value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1004b5e05a7dba83b76b93b3e7152aef7db58f4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
It was used for printing the dependencies which is now taken by macro
DEP_FILES in soc/amd/common/Makefile.inc.
TEST=binary identical test on google/guybrush amd/chausie
Change-Id: I1b86df2cb2ed178cf0a263c50ccb3e2254a3852b
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73627
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move main body of PSP padding into a loop which can add a new combo
entry. In the loop, get the FW files from each fw.cfg, create new pack
of PSP, and fill the combo header. Currently Feature COMBO is still
not fully functional. But the non-combo case will not be affected for
sure.
The real changes are
1. Add a do-while loop.
2. Remove a "TODO" comment.
All other changes are re-indenting and re-filling.
Change-Id: I351192a4bc5ed9ec0bfa3f2073c9633b8b44246d
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58554
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Micron memory part MT62F1G32D2DS-023 and MT62F2G32D4DS-023 to LP5
global list. Attributes are derived from CCM005-1974498342-145. Also,
regenerate the SPD files for the SoC.
BUG=b:271188237
TEST=util/spd_tools/bin/spd_gen spd/lp5/memory_parts.json lp5
Change-Id: I6675a68b7a515bd6d21db3ea2da762b06dee017a
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
For now, combo index is 0, and only the first entry in config table is
used. The index will grow when there are more combo entries.
Add a command parameter to give fw.cfg for combo index 1. Process the
combo config in the future loop.
Change-Id: I00609d91defc08e17f937ac8339575f84b1bd37c
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
For simplicity, OEM devices are given a single codename per build variant. Winterhold was intended to be the lead device and was chosen as the code name for this OEM. Unfortunately, Winterhold was cancelled. We attempted to rename Winterhold to Whiterun to avoid future confusion. Again, unfortunately, since some devices were already built, changing the name requires a manual change to force the firmware to be taken by the DUT. This was not a reasonable path forward, so we're abandoning the naming to Whiterun.
This reverts commit af69de494e.
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: Idef95f0f4f369b235937e1806ce57c427e441f21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73583
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Picasso already uses the Cxxx ACPI CPU device naming scheme, due to it
being what the AGESA reference code uses. We initially relied on the
AGESA/FSP generated SSDT for the P- and C-state support before we had a
native implementation for this in coreboot. The Cxxx naming scheme can
also be used for the other AMD SoCs except Stoneyridge which is pre-Zen
and doesn't select SOC_AMD_COMMON_BLOCK_NONCAR. The main advantage of
using Cxxx instead of CPxx is that the Cxxx scheme supports systems with
more than 256 CPU threads.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I884f5c0f234b5a3942dacd60847b2f095f9c0704
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73620
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
amdfwtool always assumes that the PSP BIOS binary (type 0x62 BIOS
directory entry) is always compressed. On boards using vboot, sometimes
PSP BIOS binary is uncompressed - specifically when CBFS verification is
enabled and verified boot starts in bootblock. Add an option to indicate
PSP BIOS binary is uncompressed.
BUG=b:261792282
TEST=Build Skyrim BIOS with x86 verstage and CBFS Verification enabled.
Boot to OS.
Change-Id: I4d56c0ba451b194043ebb5cdb0f2b27482beef1f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
For Intel SPR-SP, the SAD device is hidden, so pcidev_path_on_bus()
returns NULL. Therefore use pci_s_write_config32() instead.
Move lock_pam0123() from finalize.c to util.c, to be together with
unlock_pam_regions().
Change-Id: Ib08d423d8c4d482612077b66dab3878018da8f2b
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This reverts commit b42ca4d0b2.
Reason for revert: The mirror flag "0x01" is mirror once, which
relies on the EC remembering that it's been mirrored. However, the
EC forgets this if it's been without power for 20 minutes or so.
Even if power is connected then, it'll instantly try to mirror and
it can't charge whilst doing it. It can either result in
incomplete EC firmware, or a loop where it's constantly trying to
mirror.
Change-Id: I79da9143cc63459e7e29431eff2cb14200424b37
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit 35354583cd.
Reason for revert: The mirror flag "0x01" is mirror once, which
relies on the EC remembering that it's been mirrored. However, the
EC forgets this if it's been without power for 20 minutes or so.
Even if power is connected then, it'll instantly try to mirror and
it can't charge whilst doing it. It can either result in
incomplete EC firmware, or a loop where it's constantly trying to
mirror.
Change-Id: Ie82cbafd4bea2416526e2847738802a05ed45582
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Only call cbfs_boot_map_optionrom/cbfs_boot_map_optionrom_revision once
and pass the already remapped PCI ID to it. This avoids the spurious
warning that the CBFS file wasn't found from the first
cbfs_boot_map_optionrom call in cases where the PCI ID needs to be
remapped to get the right ID for which a file in CBFS exists.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If7da78c69dd702280a78996a5823972516e0319b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73612
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on nipperkin device and verified that XHCI events string use
GPE 31.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I9c2a44f7d2eb47422ae8c585e5e01ea0b420d461
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69917
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AMD SoCs currently only log the GPE# when an XHCI controller wakes the
system. Add code to log XHCI wake events to the elog.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Change-Id: Ic0489e1df55c4e63cb8a306099e3f31c82eebd58
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
- Remove functions that are only called in one place.
- Add warning if user doesn't supply a platform, since that can lead to
dumps/layouts that do not include all IFD regions without the user
even reliazing it.
- Inform the User if IFD or Flashmap is not found.
- Inform the User if there is not a single match between FMAP and IFD
region
- Avoid printing usage if not specifically asked by the user.
It tends to obfuscate the original error message.
- Keep indentation consistent throughout the file.
- Remove typedefs (coreboot coding style)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I7bbce63ecb2e920530394766f58b5ea6f72852e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Winterhold boards populate either NVMe or eMMC, but not both.
This means that there is always one link that is unpopulated. The PCIe
configuration code takes longer to verify that a link is unpopulated
than to just train the link, so this slows down the boot by roughly
80ms vs the case when the device is present. Not training the device
at all lowers boot time by another 20ms, for a total of 100ms saved.
Looking at the NVMe CLKREQ signal before initializing the ports allows
us to identify which device is populated and only initialize that
device.
BUG=b:271569628
TEST=Boot Whiterun and eMMC or NVMe correctly work, boot time is lower.
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0b87f5e968cd1c87e62a1c0fbdee1fc0723f655d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73441
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Enable both L1.1 and L1.2 substates for the WiFi, SD card reader,
and SSD (both NVMe and eMMC). If a given device does not support
a particular substate, then it will not be enabled during PCIe
enumeration by coreboot.
BUG=b:270690572
TEST=build/boot multiple skyrim/whiterun/frostflow SKUs with different
storage configs, verify WiFi/SD card/SSD all functional and have L1
substates enabled insofar as they are supported by the device.
BRANCH=skyrim
Change-Id: Ib84df8b9d97282ae696414e52c4a65cfb0a81194
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
This patch updates PMC API name from `pmc_send_pci_enum_done` to
`pmc_send_bios_reset_pci_enum_done` to inform PMC IPC about BIOS done
is also set along with PMC enumeration being done.
BUG=b:270942083
TEST=Able to build and boot google/rex.
Change-Id: I1cf8cb1ecadeb68c109be6b0e751a3f2c448ae4f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Enable whiterun/winterhold platforms to send the fuse SPL (security
patch level) command to the PSP.
BUG=b:254568112
TEST=On a platform that supports SPL fusing, a message indicating
that fusing was requested will appear in the coreboot console log,
followed by a puff of smoke when the fuse is set and the message
"OK" again on the debug console. (Kidding about the smoke.)
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I45578597234ba672c89ac421b4626088faca27d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72914
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
This adds checks for three more error bits before requesting that the
SPL fuses are updated.
- While I'm here, I'm adding the include of types.h which was previously
done through other include files, but should be done independently.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I87a7d40850c4e9ddbb2d1913c1588a919fdb29d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Use the presence of an SPL (Software Patch Level) file to trigger the
function that reads and writes the SPL fuses. The current Kconfig
option will be used to decide to write the fuses. This allows us to
see the state of the SPL update bit which determines whether or not
SPL fusing is allowed and needed before enabling the fusing.
- Refactor a bit to prepare for following changes.
- Update phrasing
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7bd2798b984673a4bd3c72f3cab52f1c9a786c67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is
moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the
Kconfig symbol to the Kconfig file in this directory.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The implementations of get_pstate_info of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. The SoC-specific get_pstate_core_freq and
get_pstate_core_power functions remain in the SoC-specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe0494f1747f381a75b3dd71a8cc38fdc6dce042
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
With the exception of the generate_cppc_entries call, the
implementations of generate_cpu_entries of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. Since all SoCs that support CPPC already select the
SOC_AMD_COMMON_BLOCK_ACPI_CPPC Kconfig option, this can be used to only
call generate_cppc_entries for platforms where it is available.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71323d9d071b6f9d82852479b60dc56c24f2b9ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Split the big PSP FW data into two parts, head and body. The head
needs to be located at original specific location. The body address is
more flexible. So the big body will not cover other needed FWs like
EC.
Give the body a specific named AMDFWBODY, which should be defined in
flashmap.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Ia8b318f71632a2c9b97ce67486374dc24d23e63e
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of hoping that the default the C state control IO address in
binaryPI won't interfere with any other IO space usage in coreboot,
assign the ACPI_CSTATE_CONTROL value to the CStateIoBaseAddress platform
config structure element to make sure that binaryPI will use a known
address for the IO port based C state control. binaryPI will write this
address to the MSR_CSTATE_ADDRESS and will then also use these IO ports
in the _CST packages in the PSTATE SSDT, so changing this won't cause
a mismatch between those two.
The default CStateIoBaseAddress in the FT4 Stoneyridge binaryPI used on
Careena is 0x1770, so this didn't collide with any other IO space
registers, but it's still much better to tell binaryPI which exact IO
addresses to use.
TEST=On Careena MSR_CSTATE_ADDRESS now contains the ACPI_CSTATE_CONTROL
IO base address 0x420 and the PSTATE SSDT has the IO address 0x421 in
the _CST package entry for the second C state which are both the
expected values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I207202802427d4bf00f283bcbd83a174ab0a2846
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
There will be a loop to set up the combo layout. The combo header only
needs to be created once. This change is actually to move the creation
of combo header outside of the loop.
Change-Id: If6ba3d10dfc598133b9adbbb2b6658f356455608
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66854
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Realtek RTL8111E NIC is currently not defined as a child device,
resulting in the on_board flag not being set to 1. This means that
Linux / udev will call the device enp3s0 rather than eno0, as is
appropriate for on-board ethernet devices.
Additionally, the comment in devicetree.cb stating that PCIe port 6
is the ethernet controller is incorrect. It's actually port 4.
This patch moves the comment to the right port, and defines the NIC
as a child device of said port, so that it's properly defined as an
on-board device.
Link: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/TFWNW3Y7IWTFD4KIBVNQYW3DODJ6SSC2/
Change-Id: Ie1e3a757a6bd6c7dd1702ced177d13711978dcc4
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73516
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Fabian Groffen <grobian@gentoo.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5157fc031c5b19d8633132222520f582620208c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4f5743dd2e4dfdfeb3ffb2e9b964bdc75c84e6c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3669c66094f0137081888ebdd1af838e2ea269b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id97fcb74ff3d48994a3181d9c31cbbeb5a76c60a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6bd8879ce5968b24893b43041be98db55a4c3c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce the get_cstate_info helper function that populates the caller-
provided cstate_values array with the data returned by the SoC-specific
get_cstate_config_data function. From the array get_cstate_config_data
returns, only the ctype, latency and power fields are used, so the rest
can be left uninitialized. Those 3 fields are compile-time constants.
For each entry, write_cstate_entry will generate the corresponding
resource information from the given data. In the C1 case where ctype is
1, the state is entered via a MWAIT instruction, while the higher C
states are entered by doing an IO read from a specific IO address. This
IO address is x - 1 bytes into the IO region starting at
MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by
reading from the C state IO base address + 1. This resource information
is generated during runtime, since the contents of MSR_CSTATE_ADDRESS
aren't necessarily known at compile-time.
MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass
a buffer with space for the maximum number of C state entries. This
maximum number corresponds to the number of IO addresses the CPU traps
beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more
than 3 or maybe 4 C states will be available though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
EC_HOST_EVENT_GPU was renamed from
EC_HOST_EVENT_USB_CHARGER and thought to no longer
be used. It was subsequently removed in
I9e3e0e9b45385766343489ae2d8fc43fb0954923
Add back the mask for this event as it is infact
required on certain Brya (Agah) and Hades variants.
Signed-off-by: Tarun Tuli <taruntuli@google.com>
BUG=b:216485035,b:258126464,b:266631157
BRANCH=none
TEST=D-notifier events are received again from EC
Change-Id: I9d7bf52efa9572e1bbd2f307420e09a7398a1ca9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73217
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
In a recent coreboot leadership meeting, the decision was made to allow
(but not require) braces around single line statements if the author
wishes to put them in.
This patch removes the checks for single line statement blocks, while
still checking for other issues in braces.
Just because they're allowed now, please do not reformat the entire
codebase to add them. coreboot has a policy of not making widespread
changes to the entire codebase unless something actually violates the
style guidelines.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I137b10889ec880959c4c1b035dc54bf8ebf32488
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73515
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The XHCI code does not currently contain a structure that corresponds
to the XHCI capability registers. These registers contain various
useful information about the controller. Create a`xhci_capability_regs`
struct to address this.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Change-Id: If38bfde726bd4e5dd314456f25a2b08acd3cd20c
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
When building libflashrom ontop of libpayload, meson calls the lpgcc
wrapper with -xc but without a file to obtain information about the C
compiler. To make this work guard $_LIBGCC with -xnone in the lpgcc
wrapper. -xnone tells the compiler to interpret the following files of
libpayload by their suffix, not the privious given -x option.
Change-Id: I9e037ff44c0a6d0585d8a6f8aeabae6e651142e2
Signed-off-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70117
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Instead of having binaryPI generate a PSTATE SSDT that uses \_PR_ as the
scope for the CPU objects and patching this SSDT in coreboot to use the
\_SB_ scope in patch_ssdt_processor_scope, request binaryPI to use the
\_SB_ scope instead by setting the late platform configuration option
ProcessorScopeInSb to true.
TEST=Careena still boots and Linux doesn't show any ACPI errors with
this patch applied. With only patch_ssdt_processor_scope removed, but
the ProcessorScopeInSb option not set, Linux will complain that it can't
resolve the \PR.P00x symbols.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If88820a0f5df923f129e2e3b5335f5f0e38ee7f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
It is necessary to increase the AVDD/AVEE of TPS65132s PMIC to +-5.7V
for powering on BOE_TV110C9M_LL0. So we set the default value to +-5.7V
and program the value to the EEPROM when configuring the display at the
first time. In this way, TPS65132s could load the correct setting from
the EEPROM after booting into kernel.
BUG=b:268292556
TEST=test firmware display pass and AVDD/AVEE is +-5.7V on Geralt.
Change-Id: I29236818444cac84d42386a371cd8934048ff948
Signed-off-by: yangcong <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73443
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
To support an RPL SKU on taeko, taeko must use the FSP for RPL.
Select SOC_INTEL_RAPTORLAKE for taeko so that it will use the RPL
FSP headers for taeko.
BUG=b:270242461
BRANCH=firmware-brya-14505.B
TEST=cherry-pick Cq-Depends, then "emerge-brya intel-rplfsp
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage",
flash and boot taeko to kernel.
Signed-off-by: Joey Peng <joey.peng@lcfc.corp-partner.google.com>
Cq-Depend: chrome-internal:5544049, chromium:4302529
Change-Id: Ic97400555dabb237325e7c4a8d5edcbb4779cdb1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73371
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This board is based off b75pro3-m, which is very similar. Compared to
it, it just lacks a COM1 header, and the secondary ASMedia SATA3
controller.
Tested with:
CPUs:
- Core i5-3330
- Core i5-3470
- Core i7-3770
RAM:
- single bank 4GB CL11
- two banks 4+4GB CL9
- two banks 8+8GB CL10
OS:
- Gentoo Linux LiveUSB, KDE desktop (Linux 5.15.72)
Working:
- GRUB2 payload with embedded default config for boot from USB, disk
- UEFI EDK2 payload
- Intel ME stripped
- Native raminit
- Integrated graphics with libgfxinit (HDMI, DVI and VGA)
- (boot from) SATA2, SATA3, ports
- Rear USB 2 and 3 ports (supports boot)
- Internal USB 3.0 ports
- Realtek GbE NIC
- 2.0 channel audio via lineout jack output
- ACPI (power button triggers OS event)
Untested:
- Internal USB 2.0 ports
- eSATA port
- 7.1 channel audio
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: Ia6a6eb3e922920f4afbcb7828cd2b779b9caebcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73097
Reviewed-by: Kevin Keijzer
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The legacy ACPI CPU control registers in IO space where the first 4 IO
locations control the CPU throttling value don't exist any more on the
Zen-based CPUs. Instead this IO address is written to MSR_CSTATE_ADDRESS
in set_cstate_io_addr which will cause accesses from the 8 IO addresses
beginning with ACPI_CSTATE_CONTROL to be trapped in the CPU core. Reads
from those IO addresses will cause the CPU to enter low C states.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c34e201cc0add1026edd7a97c70aa57f057782b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Finally figured out why ACPI_GPE0_BLK only being 4 bytes after
ACPI_CPU_CONTROL won't work and its due to the CPU trapping 8 IO
addresses from ACPI_CPU_CONTROL on for C state control. This is set up
in set_cstate_io_addr by writing the ACPI_CPU_CONTROL value into
MSR_CSTATE_ADDRESS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iedf53bbdae6ca65224601aad5cd1163df4b54131
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Picasso and newer don't implement the P_CNT register to control the CPU
duty cycle and also trap the C state control IO addresses directly in
the CPU, so those won't reach the FCH. This register is unused in the
Picasso code and not even defined any more in the Cezanne PPR. The
Picasso PPR does define this register, but since it's useless and might
even just be a leftover form a pre-Zen CPU generation, drop the define.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3820db542c4714a100c7d36de673daa1a06e4a67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the duty_offset and duty_width FADT field in
acpi_fill_fadt for all SoC except Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib63b24891d44298841153dfc500b030619e1a5ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Picasso neither has the corresponding P_CNT register implemented nor
writes a _PTC ACPI object that would specify the P_CNT register. The
Picasso UEFI reference code also sets the duty_width FADT entry to 0.
This also aligns the Picasso code with the Cezanne code in this regard.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I74645e5c4e54a2ad6bc7f9e72f5f656027a79860
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The ASRock B75 Pro3-M port was lacking a cmos.default and cmos.layout,
which means nvramtool could not be used to change any nvram values, and
the defaults were always being used.
I have "borrowed" the files from the similar h77pro4-m port, which
work fine for the b75pro3-m. I can now adjust things like gfx_uma_size
and power_on_after_fail, which are quite useful to be able to modify.
Additionally, this board did not have a data.vbt, so I extracted
vbt.bin from the VGABIOS and added it.
Change-Id: I40822f2f7b013b7ac0658d66d7972b447066d593
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73451
Reviewed-by: Fabian Groffen <grobian@gentoo.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
On the ASRock B75 Pro3-M, resuming from S3 has always been broken;
see commit 928c6c6336 (mainboard/asrock: add ASRock B75 Pro3-M).
This was because 3VSBSW# was not enabled during S3, causing the
board to reboot instead of resume. This change enables 3VSBSW#
during S3, which leads to S3 resume working normally.
Another issue with this board was that hardware monitoring was not
working. The nct6775 Linux kernel module could not be loaded, due to
the device having a base I/O port of 0. This change also enables the
Super I/O properly, so that sensors-detect can find the sensor and
the kernel module can be used.
Change-Id: I6e504fe4b60da1d7b9830bea5029101bb8cebcb5
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73450
Reviewed-by: Fabian Groffen <grobian@gentoo.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only Frostflow supports the stylus, so remove the gpio-keys ACPI node
from Skyrim.
The Kconfig value DRIVERS_GENERIC_GPIO_KEYS is still enabled for all
Skyrim variants, since coreboot will drop the driver from the BIOS image
if there are no references to it (in the devicetree). If some other
design ends up using the stylus in the future we won't have to bring it
back.
BUG: none
TEST: build_packages --board=skyrim chromeos-bootimage --autosetgov
Change-Id: I9ffe215741b72b678d74405769f35167d8ded4b5
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Add a config "USE_NAU8318" to enable NAU8318 support.
NAU8318 is another speaker used in Geralt. NAU8318 supports beep
function via GPIO control. So we configure the GPIO pins and pass them
to the payload.
BUG=b:250459803
BRANCH=none
TEST=Verify beep function through CLI in depthcharge successfully.
Change-Id: I21009a20809f398de4628ff0c11bcbd0e7591443
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73413
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The XHCI device functions currently use functions that require a
access to the device tree. Create variant of these functions that can
operate with a resource* as an argument and refactor the existing
device*-based functions to operate by calling the resource*-based
variants. This is useful for stages like SMM that may not have access to
the device tree.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on skyrim device, verified that XHCI ACPI tables are still
generated correctly.
Change-Id: If5a74f9529d5dc6031ec968ef5f40a9cad5ffbc4
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69914
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
In certain cases data within protected memmory areas like SMRAM could
be leaked or modified if an attacker remaps PCI BARs to point within
that area. Add support to the existing SMM runtime to allow storing
PCI resources in SMRAM and then later retrieving them.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I23fb1e935dd1b89f1cc5c834cc2025f0fe5fda37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Remove the last slash '/' from directories in excludelist, so that they
will be correctly filtered by grep.
Fixes:
grep: util/goswid: Is a directory
grep: util/nvidia/cbootimage: Is a directory
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I90cc2cff9a98bbd0af344156332b970bfd6430b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The SPL parameter for DPTC settings is not available for STT-enabled
platforms. It needs to be removed to avoid confusing STT calculations.
BUG=b:265267957
BRANCH=none
TEST=Run the WebGL aquarium with 5000 fish and verify that
there are no power drop peaks.
Change-Id: I8e6dad7d24883f8aadce83ebac401ecd4137d61a
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
On platforms with more than 255 cores the ACPI CPU string
would overflow and generate duplicates. Fix that by changing
the string to hex and use 3 digits.
Test:
Able to boot without ACPI errors on IBM/SBP1 which has
384 actives cores.
Change-Id: I1887928da0c049c27e2ec129f49051b24048b33b
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
oryp10 is nearly identical to the oryp9, with the differences being:
- Uses DDR5 RAM instead of DDR4 RAM
- Uses Realtek ALC1306 instead of TI TAS5825M
- Has an option for OLED display
Change-Id: I0cf46cb5d10098dd31f0dc3c620db0c7e20ffba4
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Align support for enable wake-on-usb attach/detach as was
introduced in Cannon Lake in commit 811284125f
("soc/intel/cannonlake: Add UWES ASL into xhci.asl").
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:230398487
BRANCH=none
TEST=Verify USB-A device could wake up Moli.
Signed-off-by: Scott Chao <Scott_Chao@wistron.com>
Change-Id: Icbc427a89413f5fe3a4a533135cc2c39349a9580
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73173
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The skolas baseboard is no longer needed, so this change removes the
baseboard files for skolas and adjusts the config settings to that
variants that used to select BOARD_GOOGLE_BASEBOARD_SKOLAS now
select BOARD_GOOGLE_BASEBOARD_BRYA and SOC_INTEL_RAPTORLAKE.
BUG=b:271470530
TEST="emerge-brya coreboot chromeos-bootimage", flash image-skolas.bin
onto a skolas and verify it boots to kernel.
Change-Id: I34cae7e471851aa52a64ce3af7bb506dc67f806b
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
As discused earlier, the callback name 'mb_adjust_cfg' was considered
too generic. The new naming is chosen to be consistent with other
drivers' callback names designed to be used at mainboard level.
Also other functions, namely 'mb_get_edid' and 'mb_select_edid_table'
are renamed accordingly.
BUG=none
TEST=Builds for siemens/mc_apl{1,4,5,7} and siemens/mc_ehl boards
complete successfully.
Change-Id: I4cbec0e72e5f03e94df0faa36765d1a6cd873a7a
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
CXL (Compute Express Link) [1] is a cache-coherent interconnect
standard for processors, memory expansion and accelerators.
CXL memory is provided through CXL device which is connected
through CXL/PCIe link, while regular system memory is provided
through DIMMs plugged into DIMM slots which are connected to
memory controllers of processor.
With CXL memory, the server's memory capacity is increased.
CXL memory is in its own NUMA domain, with longer latency
and added bandwidth, comparing to regular system memory.
Host firmware may present CXL memory as specific purpose memory.
Linux kernel dax driver provides direct access to such differentiated
memory. In particular, hmem dax driver provides direct access to
specific purpose memory.
Specific purpose memory needs to be represented in e820 table as
soft reserved, as described in [2].
Add IORESOURCE_SOFT_RESERVE resource property to indicate (memory)
resource that needs to be soft reserved.
Add soft_reserved_ram_resource macro to allow soc/mb code to add
memory resource as soft reserved.
[1] https://www.computeexpresslink.org/
[2] https://web.archive.org/web/20230130233752/https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.32&id=262b45ae3ab4bf8e2caf1fcfd0d8307897519630
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Ie70795bcb8c97e9dd5fb772adc060e1606f9bab0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52585
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
To support 32M flash, the non-vboot also need to split amdfw. Just as
the deleted comment says, we need this feature now.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Ic058cfaeebd1a947227cfa9be2db4eb22702aa28
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69857
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
To support 32M flash, the non-vboot also need to split amdfw.
The amdfw.rom is the default filename added to CBFS.
Keep the default filename and then we don't have to change all the
CBFS definition.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Id77b11422d4549cf57a1cd8980c7a9cf3597d1bc
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72702
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Hook up microcode from 3rdparty repo for:
- 06-b7-01 (CPUID signature: 0xb0671)
Verified microcode blob was in CBFS on Clevo PD50SNE (system76/serw13),
which has an i9-13900HX.
Change-Id: If91ff9233a5e1dd1db76edf33a76c55f5dddc9b4
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Handle the new host event EC_HOST_EVENT_BODY_DETECT_CHANGE.
Previously, the EC sent the host event EC_HOST_EVENT_MODE_CHANGE when
body detection changed between lap/desk mode. However, that event is a
wake event, which resulted in spurious AP wake events being triggered
when the EC detected lap/desk mode changes while the AP was suspended.
To resolve this, the new host event EC_HOST_EVENT_BODY_DETECT_CHANGE was
added, which will not be a wake event. This CL adds handling for the new
event to acpi/ec.asl to switch DPTC tables when a change is detected.
BRANCH=none
BUG=b:261141172
TEST=bodydetectmode on|off, verify host event is received
Change-Id: Iabeb7891489a209f45504804355f1fa817082976
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73298
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The upcoming mc_ehl4 variant is the first Siemens Elkhart Lake mainboard
without a TPM. For this reason, the corresponding Kconfig switches must
be moved to variant level. To prevent Jenkins build from complaining,
the TPM is removed in the following patch.
Change-Id: Ic73ccd1b52e57c1cf1dd7337b0e28beaadbece8e
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The commit fcff39f0ea ("vc/siemens/hwilib: Rename 'maxlen' to
'dstsize'") changed the 'dstsize' input parameter type from uint32_t to
size_t.
This patch changes also the return parameter, which is often directly
compared with the aforementioned input parameter value. This should
introduce no change on 32-bit builds and stay consistent across the
project in the case of 64-bit builds and avoid comparisons of integers
of different width here.
BUG=none
TEST=No changes to hwilib behavior on any of the siemens/mc_apl1 or
siemens/mc_ehl variants.
Change-Id: I0a623f55b596297cdb6e17232828b9536c9a43e6
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Add a new flag "--utc" to allow the user to choose if
elogtool should print timestamps in Local Time or in UTC.
It is useful for generating automated crash reports
including all system logs when users are located in
various regions (timezones).
Add information about timezone to timestamps printed
on the console.
Signed-off-by: Wojciech Macek <wmacek@google.com>
Change-Id: I30ba0e17c67ab4078e3a7137ece69009a63d68fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
The Common Clock Configuration (CCC) is a PCIe feature for cases where
the upstream and downstream device of a link share the same reference
clock. After a change in this setting a link re-training is mandatory
to make it effective.
On recent Intel platforms (tested on Elkhart Lake) the FSP code which is
executed before coreboot performs the PCI scan already enumerates all
PCI buses for its internal uses. While this is done, all the PCI express
features of a link are configured, which includes CCC. If the link
supports common clock, FSP performs the link re-training already. When the
execution flow is returned to coreboot, the same link treatment is
applied again (coded in 'pciexp_tune_dev()') and CCC is enabled a second
time, just a few milliseconds after FSP did this already.
Because enabling CCC requires a link re-training, there are two link
re-trainings on the PCIe link within a few milliseconds (one from the FSP
code and one from coreboot) which can lead to issues with a connected
PCIe device on this link. In particular, link issues were discovered
with a Pericom PCIe switch (PI7C9X2G608) on mc_ehl1 where the link has
stalled for a while after the second re-training. This in turn leads to
non-initialized PCI devices on the bus after coreboot has finished.
This patch checks if CCC is already enabled on a link and does not
perform the steps to enable it again in coreboot which safes a link
re-training (and thus execution time) and a potential link stability
issue.
Test=Check log output on mc_ehl1 which shows the following lines:
[DEBUG] PCI: pci_scan_bus for bus 09
[DEBUG] PCI: 09:00.0 [8086/1533] enabled
[INFO ] PCIe: Common Clock Configuration already enabled
Change-Id: I747fa406a120a215de189d7252f160c8ea2e3716
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73310
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The DRAM scramble feature enhances DRAM data protection. When it's
enabled, the written DRAM data will be scrambled and hence can prevent
the data from being hacked.
This feature would make debugging more difficult (for example ramoops
would be lost after reset). Therefore, add a new config to allow
enabling or disabling the feature from coreboot, without having to
maintain two versions of the DRAM calibration blob.
BUG=b:269049451
TEST=build pass and check scramble enable or disable successfully
Signed-off-by: Xi Chen <xixi.chen@mediatek.corp-partner.google.com>
Change-Id: Ib4279bc1cc960fae9c9f5da39f4448a5627288d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73176
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The currently used panel type could work with 500 ms but increasing
the value to 1 second allows to use a wider range of LVDS LCD panels,
as many of them specify the delay of 1 s as minimum.
BUG=none
TEST=Test link stability using a panel with minimum re-power delay of
1 s.
Change-Id: I2dd86e791c1212b67a80d7e6cfc474ad91b26c6b
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72804
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
When the EFS data is being packed, the pointer should be at EFS
header.
After that, it should be at body location.
TEST=binary identical test on amd/birman amd/chausie amd/majolica
amd/gardenia pcengines/apu2 amd/mandolin
Change-Id: Ia81e2bdf9feb02971723f39e7f223b5055807cd8
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of adding the P-state number to the PSTATE_0_MSR number to get
the P-state MSR number for the rdmsr call, provide a macro that directly
calculates the MSR number for a given power state. Also drop the unused
PSTATE_[1..4]_MSR definitions which also didn't cover all P-state MSRs
available in the hardware.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If85acf556efe82c209e1608e56c05f7a2a748403
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The latency values in the _CST package override the values in the
p_lvl2_lat and p_lvl3_lat FADT fields. In Picasso, Cezanne, Mendocino,
Phoenix and Glinda generate_cpu_entries generates the _CST packages for
each CPU device. The coreboot code for Stoneyridge doesn't generate _CST
packages for the CPU objects, but those are provided via the PSTATE SSDT
binaryPI generates and agesa_write_acpi_tables gets and adds to the ACPI
tables. The AGESA reference code also sets those two FADT entries to the
equivalents of ACPI_FADT_C2_NOT_SUPPORTED and ACPI_FADT_C3_NOT_SUPPORTED
so this also matches the AGESA behavior.
From the ACPI 6.4 spec: "Values provided by the _CST object override
P_LVLx values in P_BLK and P_LVLx_LAT values in the FADT."
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1116a3013576b18b6f521604d6b0a9d75b971e0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Use the ACPI_SCI_IRQ definition for both the PIC and APIC IRQ number in
the fch_irq_map table. Before the PIC mapping was set to PIRQ_NC, but
both mb/google/kahlee and the other amd mainboards using newer SoCs set
both the PIC and APCI IRQ number to ACPI_SCI_IRQ, so change this here to
match the other mainboards.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I29dde7ca8d2ecf00d8174c2d793ef1ad55ae3e28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73322
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We need to considering the case the EFS header is given as a relative
address and the other, body location, is given as an absolute one. So
we convert both of them to relative and check the validation.
For relative address case, the location should be between
0 and data size.
Change-Id: I7898bfbca02f5eb1c0fb7c456dc1935bddf685b1
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
If ctx.address_mode is "physical", it will keep as "physical".
If ctx.address_mode is "relative to table", it will be changed as
"relative to BIOS".
Because the "current table" is the whole flash, the code worked well.
TEST=Binary identical test on amd/birman amd/chausie amd/majolica
amd/gardenia pcengines/apu2 amd/mandolin
Change-Id: I9acb54cc5de149d8a705bb05bf351c44b7d3ced1
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Select `HAVE_HYPERTHREADING` and hook up the hyper-threading setting
from the FSP to the option API so that related mainboards don't have to
do that. Unless otherwise configured (e.g. the CMOS setting or
overridden by the mainboard code), the value from the Kconfig setting
`FSP_HYPERTHREADING` is used.
Port of commit a182faeb88 ("soc/intel/alderlake: Hook up FSP hyper-threading setting to option API")
Change-Id: I0b3e1a4049312c6b1ec950382c92274e0350001f
Signed-off-by: Eran Mitrani <mitrani@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Enable HAS_RECOVERY_MRC_CACHE config and add RECOVERY_MRC_CACHE FMAP
section to cache the MRC training data in recovery mode.
BUG=b:270569389
TEST=Build and boot to OS in Skyrim. Ensure that the Type 0x63 BIOS
directory entry is populated with the appropriate MRC_CACHE FMAP
section.
Change-Id: I3f0f41c20b61c96473e887521f84f3ad240adc2b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73250
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
To support an RPL SKU on osiris, osiris must use the FSP for RPL.
Select SOC_INTEL_RAPTORLAKE for osiris so that it will use the RPL
FSP headers for osiris.
BUG=b:270640775
BRANCH=firmware-brya-14505.B
TEST=cherry-pick Cq-Depends, then "emerge-brya intel-rplfsp
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage",
flash and boot osiris to kernel.
Cq-Depend: chromium:4290627, chrome-internal:5516851
Change-Id: If8de42a82fd85ffa8b9836e6024f119bc798f4fc
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73242
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bob Moragues <moragues@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
It's sufficient to generate CPU devices for all available CPU cores/
threads instead of for the maximum number of possible CPU cores/threads.
TEST=google/careena with 2 cores still boots and Linux doesn't complain
about ACPI errors due to referenced but not present CPU objects.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6850edfa305304060092cb5480f4296f4f5ddacc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
On boards with RECOVERY_MRC_CACHE FMAP section, populate type 0x63 BIOS
directory entry in RO with that section. If the RECOVERY_MRC_CACHE
section is not present, then fall back to RW_MRC_CACHE.
BUG=b:270569389
TEST=Build and boot to OS in Skyrim. Ensure that the Type 0x63 BIOS
directory entry is populated with the base and size of appropriate MRC
cache.
Change-Id: I49ec4f64e33c4d5780a7fe6a5540eab42b6cec9f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
If a mainboard has RECOVERY_MRC_CACHE and the recovery mode is enabled,
then use APOB data from that section and make any updates to that
section. Otherwise continue to use DEFAULT_MRC_CACHE section.
BUG=b:270569389
TEST=Build and boot to OS in Skyrim.
When in normal mode, DEFAULT_MRC_CACHE is used.
Normal Mode Boot1:
------------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[INFO ] APOB RAM hash differs from flash
[SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x0/0x1e000
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] SF: Successfully erased 122880 bytes @ 0x0
[INFO ] Updated APOB in flash
Normal Mode Boot2:
-----------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] APOB hash matches flash
When the device is in recovery mode, RECOVERY_MRC_CACHE is used.
Recovery Mode Boot1:
--------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[INFO ] APOB RAM hash differs from flash
[SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x650000/0x1e000
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] SF: Successfully erased 122880 bytes @ 0x650000
[INFO ] Updated APOB in flash
Recovery Mode Boot2:
--------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] APOB hash matches flash
Switch from Recovery Mode to Normal Mode:
-----------------------------------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] APOB hash matches flash
Switch from Normal Mode to Recovery Mode:
-----------------------------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] APOB hash matches flash
Change-Id: I93f357e407c98b6e5fca495f4f779fad54a3430f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Update ec_commands.h from the EC repo at:
"8441cf4 Add host event: EC_HOST_EVENT_BODY_DETECT_CHANGE"
This is an exact copy of the EC repo's ec_commands.h with the
exception of updating the copyright message.
BUG=b:261141172
BRANCH=none
TEST=built coreboot for skyrim
Change-Id: I9892c0c3518f63d357459861e8fa1b7f5f494e68
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73258
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Because the ChromeOS boards don't fill a manufacturer in for the memory
SPDs, that information isn't available from the FSP. We can get the
Manufacturer ID based on the memory name from CBI instead. Use this
information to fill in an ID so that the manufacturer name is available
in the SMBIOS information.
BUG=None
TEST=Look at dmidecode output
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I810c3191180dd3b566d7ea64006f29b625b10526
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The DMI error correction type was not being filled in, so was reporting
as "Error Correction Type: <OUT OF SPEC>". This patch fixes that.
Since it's now filling in information for both Type 16 & 17, rename
the function to reflect that.
BUG=None
TEST=dmidecode now reports the type correctly.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I6b51612d808c63de1acd2be952cb6c152f8a1be5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This patch optimizes CPU MP Init related configs being used within
multiple SoC directory and moving essential configs into common code
to let the SoC user to choose as per the requirement.
TEST=Able to build and boot google/kano and google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I12adcc04e84244656a0d2dcf97607bd036320887
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Changing the pointer outside the function is not allowed.
Check if it overflows everytime it changes.
TEST=Binary identical on amd/birman amd/chausie amd/majolica
amd/gardenia pcengines/apu2 amd/mandolin
Change-Id: I2c295b489d833201f1ba86a7759ea7dc0e1e672f
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This reverts commit 363202b435.
Reason for revert: Seeing some bit flips on the SPI bus, but cannot
repro reliably on local builds. Going to downgrade back to 50 MHz
to see if builder builds are more stable on each variant as a result.
Signed-off-by: Shelley Chen <shchen@google.com>
Change-Id: I4fe76bac915e3b3c794821cd160a66824e38ea83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73214
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
DRAM Part Name ID to assign
MT62F512M32D2DR-031 WT:B 0 (0000)
MT62F1G32D4DR-031 WT:B 1 (0001)
MT62F1G32D2DS-026 WT:B 2 (0010)
H9JCNNNBK3MLYR-N6E 0 (0000)
K3LKBKB0BM-MGCP 3 (0011)
BUG=b:265190498
BRANCH=None
TEST=emerge-skyrim coreboot
Signed-off-by: Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com>
Change-Id: I860f10552e4e4180e09ab805ca82b108fdc8f21a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73049
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Elkhartlake based SoCs uses Intel's Management Engine (ME), version 15.
This patch selects ME 15 specification defined at common code and
removes elkhartlake SoC specific ME code and data structures.
BUG=b:260309647
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I3186f509c63b3a892c72cb1fa08fc094735d6eeb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73245
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Alderlake based SoCs uses Intel's Management Engine (ME), version 16.
This patch selects ME 16 specification defined at common code and
removes alderlake SoC specific ME code and data structures.
BUG=b:260309647
Test=Build verified for brya.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ib94e4662c735b1c31c8dfca1cfa881e6fa4070fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73244
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch adds ME specific source code at common location in order to
reduce maintenance efforts at SoC level and improve readability. The
functionality and code are redundant for various SoC platforms and
require more maintenance.
BUG=b:260309647
Test=Build verified for brya and rex.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ic6622662fd3b8bcc9d9ac8bd6ffa732f5d78801a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73133
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch includes ME specification datastructures for various ME
versions. Including the ME specification in common code will help
current and future SoC platforms to select the correct version based on
the applicable configuration. It might be also beneficial if two
different SoC platforms would like to use the same ME specification and
not necessarily share the same SoC directory.
BUG=b:260309647
Test=Build verified for brya and rex.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I83df41d7180d2df419849a0c01c728ff0fe75378
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73129
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rather than explicitly checking for Recovery or Developer mode via
vboot, use display_init_required() so that vboot is not required, and
other instances where the display is needed pre-OS (such as when
applying a critical system update) are covered as well.
With this change, SoCs implementing selective GOP init will need to
select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required()
to not assert on compilation.
BUG=b:255812886
TEST=build/boot skyrim
Change-Id: Iac7e06863764a9f21c8a50fc19050cb5a6627df2
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Rather than explicitly checking for Recovery or Developer mode via
vboot, use display_init_required() so that vboot is not required, and
other instances where the display is needed pre-OS (such as when
applying a critical system update) are covered as well.
Select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required()
to function properly (and not assert on compilation).
BUG=b:255812886
TEST=build/boot skyrim
Change-Id: If2fee71bcc11468fd2db0abaafe4ea35e2953993
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Define some actions based on probe results for audio:
- Disable the SoundWire GPIOs when I2S option is selected.
- Disable the I2S GPIOs when SoundWire option is selected.
- Disable all the GPIOs when no audio is enabled.
BUG=b:269497731
TEST=Test that GPIOs are configured based on the current
value of the fw_config field in cbi.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I0ed452a0d08e6779add318d9bbd1e97b50b6aea9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
In order to improve gpio merge mechanism. Change iteration override
to padbased table override. And the following patch will change fw
config override with ramstage gpio table override.
Port of commit 7aef2b1294 ("mb/google/nissa: Apply gpio padbased
table override")
BUG=none
TEST=Verify devbeep at depthcharge console
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I2ee86bbec7d25a35d726f29ad79891f1054bf52c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73182
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The reset bit mapping was incorrectly assigned to GPIO groups. The
reset mapping for Community 0 actually reflects the GPD reset mapping.
Change the Community 0 reset mapping to the correct default map and fix
the GPD reset mapping.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I2b9d093ca7ea0f5087f49671ca457c0b45927918
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Introduce at new config option CONFIG_FSP_PUBLISH_MBP_HOB to control
the creation of ME_BIOS_PAYLOAD_HOB (MBP HOB) by FSP.
This new option is hooked with `SkipMbpHob` UPD and is always disabled
for RPL & ADL-N based ChromeOS platforms.
It is not disabled for ADL-P based platforms because ADL-P FSP relies
on MBP HOB for ChipsetInit version for ChipsetInit sync. As ChipsetInit
sync doesn't occur if no MBP HOB, so it results S0ix issue. This
limitation is addressed in the later platforms so creation of MBP HOB
can be skipped for ADL-N and RPL based platforms.
This made skip_mbp_hob SOC chip config variable redundant which is also
removed as part of this change.
BUG=none
TEST=Build and boot to Google/Taniks.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Ia396b633a71aedf592c45b69063ee0528840fd2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
MX98357A is not a soundwire codec, so move it out of
drivers/intel/soundwire node.
BUG=none
TEST=Build and boot MTL-P RVP to Chrome OS. Verify I2S audio card
enumeration and no max98357a entry under /sys/bus/soundwire/devices.
Signed-off-by: Yong Zhi <yong.zhi@intel.com>
Change-Id: I24fc7084ea18445c341eed012cfacde8de126fd8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Usha P <usha.p@intel.com>
Alderlake based SoCs uses Intel's Management Engine (ME), version 16.
This patch selects ME 16 specification defined at common code and
removes alderlake SoC specific ME code and data structures.
BUG=b:260309647
Test=Build verified for brya.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I94cb8a9cbb6167d1a11a012efbd6a135a8692969
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73135
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The coreboot-common acpi_create_fadt writes a pointer to the FACS table
into both firmware_ctrl and x_firmware_ctl_l FADT fields and sets
x_firmware_ctl_h to zero. When x_firmware_ctl_[l,h] is non-zero, the
pointer in firmware_ctrl will be ignored, but that's what is already
done on Cezanne and newer.
TEST=Linux doesn't complain about any new ACPI problem on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib9eab4dcf828f28a60c6312ec96872aac4cfb266
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the ARM_boot_arch FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id2d24a9b8d5b04271eb4da6a622b5bba66dbc501
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73188
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the ARM_boot_arch FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ica968db1228a2d63e83f2b6c4ea57c5f02bf1504
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73187
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This patch makes EC wake up AP from s3/s0ix for OS shutdown/hibernate
when the state of charge drops to low_battery_shutdown_percent.
BUG=b:255465618
TEST=emerge-nissa chromeos-bootimage (EC: https://crrev.com/c/4243898)
Verify system resumes from s0ix and then enter S5 on nivviks with steps:
1. disconnect AC
2. powerd_dbus_suspend --disable_dark_resume=false
3. fakebatt 5
4. fakebatt 4
Change-Id: I63b5246432687e38ddfc5733ac3a115c3456d7e9
Signed-off-by: Ivan Chen <yulunchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73082
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
MT8188 supports port0/port1 download. The hardware needs a trapping pin
to select the port to use. When port1 is selected, the phy of port1 will
be switched to port0. That is, port1 connector will be the physical line
of port0. Since port0 phy isn't initialized in coreboot, switch back to
port1 phy.
BUG=b:269059211
TEST=can detect USB2 devices in depthcharge.
Change-Id: Ic97d0bd9d0233883196b2e73ac2a22cd8ea9466b
Signed-off-by: Shaocheng Wang <shaocheng.wang@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Add functionality such that the FPMCU is power cycled long enough
on boot to ensure proper reset.
This solution relies solely on coreboot to sequence the power and reset
signals appropriately (150ms on boot).
BUG=b:245954151
TEST=Confirmed FPMCU is still functional on Nami.
Confirmed power is off for 150ms seconds on boot.
Confirmed RCC_CSR of FPMCU indicates power cycle occurred.
Confirmed reset is de-asserted approx 3ms after power application
(target >2.5ms)
Change-Id: I21eb85dc11e0ea0eb5de8a6092b01663d3c3df91
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68820
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
VGA defineds the extended ASCII set based on CP437, but there is a bug
on printing them: in vga_write_at_offset(), we perform a bitwise or
between 'unsigned short' and 'signed char':
```
p[i] = 0x0F00 | string[i];
```
If we want to show an extended ASCII character, string[i] will be
negative and this bitwise operation will fail due to their implicit
casting rule: convert signed char to unsigned short by adding 65536.
To fix this, we need to cast the string to unsigned char manually
somewhere. Since we still want to leverage the built-in string utilities
which only accepts const char*, we still preserve the original
prototypes before, and cast it until we write into the frame buffer.
BRANCH=brya
BUG=b:264666392
TEST=emerge-brya coreboot chromeos-bootimage
and verify drawing characters with code > 127.
Change-Id: I9cd65fe9794e5b0d338147924f28efd27fc8a1e8
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Package C state demotion is now disabled for all RPL SoCs from within
soc/intel/alderlake/fsp_params, so no need to duplicate that in the
skolas devicetree.cb.
BUG=268296760
BRANCH=firmware-brya-14505.B
TEST=Boot and verified that S0ix issue is resolved.
Change-Id: I1c630e2efbdddd18a5423c79b73269e9b1be79c7
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The EFS entry at offset 0x14 can point to either the first level PSP
directory table or to the PSP combo directory structure that was used
before the introduction of the AMD A/B recovery scheme. This scheme is
not to be confused with the VBOOT scheme. The PSP verstage code checks
if the header this entry points to begins with the PSP_COOKIE, which
indicates the entry is a first level PSP directory table. Due to that,
the EFS entry at offset 0x14 is always expected to point to a PSP
directory table, so rename combo_psp_directory to new_psp_directory to
match the actual usage. This EFS entry that points to the PSP directory
table is called new_psp_directory, since the entry at EFS offset 0x10
was used on some early AMD chips to point to the older PSP directory
table and that one is already called psp_directory. amdfwtool uses the
same naming scheme for those two PSP directory table pointers.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I10f19ee63f8d422433dba64402d84fd6bb9e0f9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73083
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ctags tool (called by ctags-project target) currently complains
about not finding certain files.
The project_filelist.txt generation includes the compiler
generated "*.d" files, except for files found in build/util. Most file
paths in these "*.d" files are file paths relative to the root
directory of coreboot. Some projects though are compiled separately from
coreboot (e.g. payload, vboot, util). Some of these (e.g. util, vboot)
are also put into the build directory of coreboot and relative file
paths are relative to these projects instead of coreboot. This has the
uncanning side effect that the ctags Makefile target can't find these
files, since they are not relative to the coreboot root directory.
This patch also excludes the build/external directory from those files,
since they contain 'separately' compiled projects like 3rdparty/vboot.
That fixes the ctags-project Makefile target.
Change-Id: I16294171c29a0d5fd25a31018846f1013e130ee0
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71517
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>
If BIOS_DONE MSR is supported, set it after ReadyToBoot, because FSP
programs certain registers via Notify phase ReadyToBoot and it cannot
be modified by FSP after coreboot has set BIOS_DONE MSR, therefore we
try to set BIOS_DONE MSR as late as possible to avoid this.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Change-Id: I4f19a7c54818231ebbccd2b6f8b23f47b117eb1f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71964
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
To make MIPI/eDP panel functional on unprovisioned devices, it requires
passing SKU ID and panel ID info to the payload(depthcharge) to load the
corresponded device tree for kernel.
BUG=b:247415660
TEST=cbmem -1 |grep "SKU Code".
Change-Id: Id2254729b7bd621d1e9bc520e8f40916d0f81030
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73076
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The platform supports a discrete LPC TPM module. However, ME firmware
enables PTT by default and descriptor is configured for SPI TPM on the
platform's original firmware. So disabling PTT in ME is not enough,
because it falls back to SPI TPM. Ensure PTT is disabled in ME and SPI
TPM is disabled in descriptor soft straps.
TEST=Boot VP4650 and see LPC TPM is recognized by coreboot.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3764e085f2eb5ae957b9087d150320def7af4fc6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68920
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Some users of MSI Z690-A board reported non-working IGD display
during post using various CPUs. As not all PCI IDs were hooked,
coreboot didn't detect GOP-provided framebuffer nor passed the
framebuffer information to the payload, causing a black screen.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I07584e07182ee56b61b6f751100431589d1cbe83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elias Souza <eliascontato@protonmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Add NO_S0IX_SUPPORT for boards that do not support, or do not want
to support S0IX.
As all the boards in the tree that do this, don't support D3Cold,
add D3COLD_SUPPORT that defaults to `n` when NO_S0IX_SUPPORT is
selected to disable D3Cold support.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I03378cc7bb76fd65fcec81018e47f6288d437cd8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Besides crashlog, there's also other errors such as MCA error, which
should be recorded in BERT table. With current code, BERT table is
not generated if crashlog is not enabled. Add if statement for
SOC_INTEL_CRASHLOG so that MCA error can be recorded in BERT table
when crashlog is not supported.
For some server mainboard, crashlog is supported through BMC instead
of host firmware.
Also check if BERT region is generated when crashlog is not enabled.
Change-Id: I323ca889eef2b246fc4e062582d2d11b4213316f
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
pmc_lock_smi() and pmc_lockdown_config() have PCH specific
implementations. Move them from common lockdown.c and pmc.c
into lbg/soc_pmutil.c.
Move sata_lockdown_config() and spi_lockdown_config() to
lbg/lockdown.c.
While here, fix some coding style issues.
Change-Id: I9b357ce877123530dd5c310a730808b6e651712e
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Simon Chou <simonchou@supermicro.com.tw>
Reviewed-by: Jian-Ming Wang <jianmingW@supermicro.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This patch improves `incomplete` debug messages for missing ACPI
name PCI devices.
Additionally, using the proper PCI device B:D:F to locate the device
with the missing ACPI name.
Finally, modify the msg time from Debug to Warning to make it more
purposeful.
TEST=Able to build and boot google/rex.
Without this patch:
```
[DEBUG] dev->path.devfn=10
[DEBUG] dev->path.devfn=a2
[DEBUG] dev->path.devfn=b0
```
With this patch:
```
[WARN] Missing ACPI Name for PCI: 00:02.0
[WARN] Missing ACPI Name for PCI: 00:14.2
[WARN] Missing ACPI Name for PCI: 00:16.0
```
Change-Id: I605e59de8cbec18c9a56eaa6e90a34f36ea4cdd9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73072
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch fixes the wrong warning msg around `Unknown min d_state`
with having proper PCI Bus/Device/Function number to help to parse
the log better.
With this patch:
[WARN ] Unknown min d_state for 20
[WARN ] Unknown min d_state for 50
[WARN ] Unknown min d_state for 98
[WARN ] Unknown min d_state for 9a
[WARN ] Unknown min d_state for f9
With this patch:
[WARN ] Unknown min d_state for PCI: 00:04.0
[WARN ] Unknown min d_state for PCI: 00:0a.0
[WARN ] Unknown min d_state for PCI: 00:13.0
[WARN ] Unknown min d_state for PCI: 00:13.2
[WARN ] Unknown min d_state for PCI: 00:1f.1
Change-Id: Iccaf26882ce5998469b2be6cf5bc7082f193cb29
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
According to the author of the mainboard scaleway/tagada, the mainboard
is not used anymore. Since the mainboard is not publicly available for
purchase and not used anywhere else, the usual deprecation process
of 6 months is not needed.
Thus, to reduce the maintenance overhead for the community, support for
the following components will be removed from the master branch and will
be maintained on the release 4.19 branch. Also, add a note to the 4.20
release notes.
* Mainboard Scaleway Tagada
Change-Id: Ifb83b8f2b1dc40cbef657e52c629948dc466ec6e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72915
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`stddef.h` should only provide the definitions defined by ISO or Posix.
The included `commonlib/bsd/helpers.h` provide a lot of non standard
definitions that may interfere with definitions from the application.
Change-Id: Ia71edbc3ffe6694ff4b971decf3a41f915264bc8
Signed-off-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70116
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the correct defaults for VGA_BIOS_ID and VGA_BIOS_FILE in
Mendocino's Kconfig instead of relying on the board's .config files
providing the correct settings. Those settings are per-SoC and not
per-board, so this is valid for all boards using the Mendocino APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I09c537d3801123e7ffc01608171918b0396b7a5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add the correct defaults for VGA_BIOS_ID and VGA_BIOS_FILE in Cezanne's
Kconfig instead of relying on the board's .config files providing the
correct settings. Those settings are per-SoC and not per-board, so this
is valid for all boards using the Cezanne APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67101d518c6b873ad89932ae39c2deb2ed6a4c29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add a new baseboard for hades, an Intel RPL based reference design.
Also, add variants for the reference boards hades. This commit is
a stub which only adds the minimum code needed for a successful build.
Need update gpio and memory DQ pins after final shchematic comes out.
BUG=b:269371363
TEST=abuild -a -x -c max -p none -t google/brya -b hades
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Ib7fbdf997df8225cc7814a34f8b4e4e04884dbf9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
The way the PSP_APCB_FILES list is created will always insert at least a
space into it. When tested by the if, this space will prevent the else
clause from ever running and never generate a build error.
Remove the non-functional check. Instead, mainboards should select
warn_no_apcb or die_no_apcb to generate a warning message or build error
if the APCB is missing.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ic96846d74df2dc279e13b22f2a83b6f893954fe8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73009
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The way the PSP_APCB_FILES list is created will always insert at least a
space into it. When tested by the if, this space will prevent the else
clause from ever running and never generate a build error.
Remove the non-functional check. Instead, mainboards should select
warn_no_apcb or die_no_apcb to generate a warning message or build error
if the APCB is missing.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I26b96966495dc35a8b4a0cb7d5a841f3812f2a70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73007
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The way the PSP_APCB_FILES list is created will always insert at least a
space into it. When tested by the if, this space will prevent the else
clause from ever running and never generate a build error.
Remove the non-functional check. Instead, mainboards should select
warn_no_apcb or die_no_apcb to generate a warning message or build error
if the APCB is missing.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ib9fe0f05739fb19da2494629dc1d5aaa0ca6431f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73006
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Kconfig option for VBOOT_ARMV8_CE_SHA256_ACCELERATION, which will
use ARMv8 Crypto Extension for SHA256[1] instead of software
implementation.
This will speed up firmware verification in verstage.
[1] https://crrev.com/c/4170144
BUG=b:263514393
BRANCH=corsola
TEST='calculating body hash (SHA2)' get 13 msecs improvement on
Tentacruel.
Before:
509:finished calculating body hash (SHA2) 161,548 (14,490)
After:
509:finished calculating body hash (SHA2) 155,101 (1,187)
Change-Id: I02671338fd9e0deb5294dbb7c03528061edc18c4
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72711
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id ffb34f48:
PRESUBMIT: disable automatic git cl presubmit
to commit id 5b8596ce:
2sha256_arm: Fix data abort issue
This brings in 15 new commits.
Change-Id: I27a2dbd83114d7f5c075e0823f0c7948b82da694
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Fix RTD3 timing for adlrvp_p_ext_ec and adlrvp_rpl_ext_ec.
BUG=none
BRANCH=firmware-brya-14505.B
TEST=Insert a SD card or NIC AIC on PCIe slot1 and run
'suspend_stress_test -c 1'. The RP8 should not cause suspend issue.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I792c55a6361d1eae55cc6f668a03dc2503120fe1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72422
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
_ON() calls _STA() at the beginning. If _STA() indicates the device is
ON, it exits immediately. The solution is to move this _STA() check
into the ONSK logic. In general cases, ONSK remains '0'.
NOTE: RTD3 provides a way to skip _OFF() and _ON() methods following
by a device reset such as WWAN device. When such device calls its
_RST(), it increments OFSK. When the following _OFF() is called, it
was scheduled to skip, it will also increments ONSK. Similarly, when
the following _ON() is called, it checks if the previous _OFF was
skipped or not. If skipped, it needs to do the same. In normal
suspend/resume cases, these two variables remains '0'. No _OFF() and
_ON() calls are skipped.
entire generated code:
Method (_ON, 0, Serialized) // _ON_: Power On
{
If ((ONSK == Zero))
{
Local0 = \_SB.PCI0.RP01.RTD3._STA ()
If ((Local0 == One))
{
Return (One)
}
Acquire (\_SB.PCI0.R3MX, 0xFFFF)
EMPG = Zero
Local7 = 0x06
While ((Local7 > Zero))
{
If ((AMPG == Zero))
{
Break
}
Sleep (0x10)
Local7--
}
Release (\_SB.PCI0.R3MX)
\_SB.PCI0.PMC.IPCS (0xAC, Zero, 0x10, 0x00000020, 0x00000020,
0x00000020, 0x00000020)
\_SB.PCI0.STXS (0x015E)
If ((NCB7 == One))
{
L23R = One
Local7 = 0x14
While ((Local7 > Zero))
{
If ((L23R == Zero))
{
Break
}
Sleep (0x10)
Local7--
}
NCB7 = Zero
Local7 = 0x08
While ((Local7 > Zero))
{
If ((LASX == One))
{
Break
}
Sleep (0x10)
Local7--
}
}
}
Else
{
ONSK--
}
}
BUG=b:249931687
BUG=b:241850118
TEST=Use above functions and check the generated SSDT table after OS
boot.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Id1ea2e78e98d334a90294ee6cdd14ae2de9b9b62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72826
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the flash size is over 16M, the absolute address could be lager
than 16M, which can not be taken by CBFS. For the relative address, it
is more flexible.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
TEST=binary identical test on birman and mayan when
CONFIG_BIRMAN_HAVE_MCHP_FW and CONFIG_MAYAN_HAVE_MCHP_FW are set as
y.
Change-Id: I65be3039cd3449bfb481ad87281b72e88a58bd45
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72960
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
VPD variable 'smm_log_level' can be read and passed to SMM for
overriding SMM log level. By default it's zero therefore it disables
most of the SMM log. When we need to see SMM log we can set this VPD
to a larger value to enable it.
Implement mainboard_set_smm_log_level() that reads VPD variables for SMM
log level.
Change-Id: I90d471d1d070d9a0f1a82ca9da8a2c034c9fd574
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71992
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
This patch marks unused USB ports (USB2.0/TCSS) empty to avoid
prompting wrong dmesg as below.
```
usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
```
Mainboard variants to override the USB ports as per the target
board design.
TEST=Able to build and boot google/rex with all USB ports are
working as expected.
Change-Id: Ic3d21151a22f2318413f480f3386bf2dbf696307
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73027
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add a Kconfig RUNTIME_CONFIGURABLE_SMM_LOGLEVEL that enables
mainboard to override mainboard_set_smm_log_level for SMM log level.
This can let SMM have different log level than other stages for
more flexibility.
Another reason is that getting certain data that requires searching
from flash VPD or CMOS is not very ideal to be done in SMM, so in this
change the value can be passed via the member variable in struct
smm_runtime and be referenced directly in SMM.
One example is that mainboard can get the desired SMM log level from
VPD/CMOS, and pass SMM console log level via the variable and in SMM
it can be referenced in get_console_loglevel() override function
directly.
Tested=On OCP Delta Lake, verified SMM log level can be overridden.
Change-Id: I81722a4f1bf75ec942cc06e403ad702dfe938e71
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49460
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Some platforms have an onboard speaker which could be used as an
indicator of successful boot or critical error, e.g. in die_notify
function. The function assumes that SPKR GPIO is properly configured
by the platform code.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I8189b3462bb5140af352fa786db3a6a2a45076f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68100
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Add new memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
1) Samsung K3KL8L80CM-MGCT
2) Hynix H58G56BK7BX068
3) Micron MT62F1G32D2DS-026 WT:B
4) Micron MT62F512M32D2DR-031 WT:B
5) Hynix H58G56BK8BX068
BUG=b:264340545
BRANCH=firmware-brya-14505.B
TEST=FW_NAME=omnigul emerge-brya coreboot
Change-Id: I1f650c7e90804e871572f42ac925da85afd7f9d3
Signed-off-by: Jamie Chen <jamie_chen@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72886
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyle Lin <kylelinck@google.com>
- Make variables for the release name and the tarballs instead of
writing them out every time.
- Skip some more unnecessary files when creating the tarballs.
- Remove unnecessary check for the commit ID. It's now a required field.
- Correctly get and save the time of the last release for use in
creating the tarballs.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I56cd5e2dcf01ee55e5d45e837db2f89904b06ddd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73004
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Adjust timing parameters on i2c1 and i2c2 to meet timing requirements.
For SCL, the t-high time is now over the min 600ns requirement
for 400KHz operation (measure at over 700ns). Also, this change
does not violate other parameters - rise time, setup time and hold time.
BUG=b:264704732
TEST=Verified all timings meet spec now
Change-Id: I0e92b2c9c25e7fb5fa7082af3f4a88da168c3ef2
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72675
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Since it actually depends on the SoC type whether the old PSP
directory table pointer or the new comboable PSP directory table
pointer is used in EFS, get this information from the SoC ID instead
of passing the comboable flag for the SoCs that need to use the new
comboable PSP directory table pointer.
TEST=Binary identical on amd/majolica, pcengines/apu2, amd/gardenia
Change-Id: I0c3f21065939d1b13c2607aba16cbef74dd8d389
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add a FMAP region to support caching GOP-driver-modified VBIOS tables.
Select SOC_AMD_GFX_CACHE_VBIOS_IN_FMAP if CHROMEOS && RUN_FSP_GOP.
Default USE_SELECTIVE_GOP_INIT to y if CHROMEOS && RUN_FSP_GOP.
BUG=b:255812886
TEST=build/boot skyrim, verify cached VBIOS data differs from VBIOS
in CBFS, cached VBIOS data is used when not booting in recovery
or developer modes.
Change-Id: I5857fa4a15250bf6478bffa96b16200e318492b1
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This patch overrides `SkipExtGfxScan` UPD as the Rex device is
equipped with an on-board graphics device hence, skip scanning
external GFX devices.
BUG=b:228002764
TEST=Able to save ~1ms+ boot time on google/rex.
FSP FPDT Data is showing the timestamp between those function calls.
Without this patch:
[INFO ] CheckOffboardPcieVga/5b7cc220-e183-481c-87f427a92d8db88f -> 979684 -> 22
[INFO ] CheckOffboardPcieVga/5b7cc220-e183-481c-87f427a92d8db88f -> 980815 -> 1131
With this patch:
`CheckOffboardPcieVga` is not getting called.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I20aa09e80671ab94e639787f40b95b740bbe5efb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add support for the selective GOP init feature by only running the FSP
GOP driver when necessary: if the FMAP cache is invalid, or if the
board is booted in either recovery or developer mode.
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: I7ddadc254e05aca0fdd7a9567160a9329cb0e15c
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Write the SHA256 hash of the cached VBIOS data when saving to FMAP,
and use it to validate the data read from FMAP on subsequent boots.
Add TPM2 as a dependency to the selection of VBIOS_CACHE_IN_FMAP.
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: I9c8f23b000b90a1072aeb7a57d3b7b2b2bc626dc
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72402
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add methods to store and retrieve the hash of the data stored in the
VBIOS cache FMAP region. Add a dedicated index in TPM NVRAM to store
the hash, and methods to calculate/read/write it.
Modeled after mrc_cache_hash_tpm.{c,h}
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: I030017d3bf956b8593bc09073ad6545b80a5b52b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Make does its work in two distinct phases. The first one basically
initializes and expands all variables, which are not in a recipe and
the second expands all variables inside recipes and then executes the
recipes if necessary.
Currently on some mainboards it can happen that cpu_microcode_bins
variable is filled with microcode paths AFTER swid-files-y is expanded
in the prerequisite for the sbom rule. That causes the
"$(build-dir)/intel-microcode-%.json pattern matching rule not to be
invoked. At the time, when the recipe is executed however (second phase
of make), swid-files-y will now contain the cpu microcode paths from
cpu_microcode_bins. That causes the goswid tooling to fail since the
necessary files were never created, since
"(build-dir)/intel-microcode-%.json" target was never executed.
In order to trigger the expansion of swid-files-y at the second make
phase (after cpu_microcode_bins is fully filled), this patch makes use
of make's secondary expansion feature.
Before on some boards (including samsung/lumpy) the goswid tool
complained about not finding the microcode sbom files.
Test: build samsung/lumpy with CONFIG_SBOM_MICROCODE=y
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I884469a388fd48be89d74ccda686dd8f299d63eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72660
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The "which" command is not a posix command. Additionally, if a file
is not found, it outputs "command not found", so when checking to see
if the response is "", that doesn't work.
"command -v" is a posix compliant replacement that doesn't put out any
text if the command is not found, so is more suitable in this case
anyway.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I22207e818c847d50998f90c9abd55a3cb4bb2ab3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The correct ACPI device for DPTM is TCPU; fixing this puts the
participant devices under the correct parent device, and allows
Windows to properly go into S0ix.
TEST=builb/boot Win11 on google/banshee, verify Si0x functional.
Change-Id: I1b3e2655d4d42e008dead9bc87b73ce02868fdfa
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72920
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Instead of using PCI_DEVFN(SMBUS_DEV, SMBUS_FUNC), use the equivalent
SMBUS_DEVFN define.
Even though the FCH IOAPIC is in the LPC part of the FCH, it needs the
IVRS IOAPIC table's source_dev_id field set to SMBUS_DEVFN which is the
function 0 of the FCH PCI device. LPC is function 3 of the FCH device.
When assigning LPC_DEVFN to source_dev_id, the kernel from Ubuntu
2022.04 LTS complains about the IOAPIC part of the IVRS table being
wrong:
AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found
AMD-Vi: Disabling interrupt remapping
With SMBUS_DEVFN being used as source_dev_id, no such error is reported.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I8470d67b2513031e75fb422d4c1c181e017ace0a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
APOB on Phoenix is larger, so expand the reserved DRAM and MRC_CACHE
regions to fit. This requires moving memory addresses around to prevent
overlapping memory linker errors.
TEST='./util/scripts/testsoc -K PHOENIX -K GLINDA' successfully builds
all boards
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I42af7230ca5f09ba66b2b3c4f99ac3feac7feeea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Glinda and Phoenix have different requirements, so split the birman FMD
files to better apply to each SoC.
TEST='./util/scripts/testsoc -K PHOENIX -K GLINDA' successfully builds
all boards
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ia2dbaeb8af04fb1d1224c397d728929c50800dfe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The EFS must be located at the 128K offset. The combination of EC,
MRC_CACHE, and FMAP push the start of the coreboot CBFS region to 128K,
leaving no room for the CBFS headers for the EFS.
Move the MRC_CACHE region to the end of the image. This matches the
chromeos MRC_CACHE layout.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I3919fba40f22ee84b0a3eee1ac7b6e48c076d713
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The EFS must be located at the 128K offset. The combination of EC,
MRC_CACHE, and FMAP push the start of the coreboot CBFS region to 128K,
leaving no room for the CBFS headers for the EFS.
Move the MRC_CACHE region to the end of the image. This matches the
chromeos MRC_CACHE layout.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I15e29443d2735342a5a43339f5bb095e5115349c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This change adds some new acronyms to the list, clarifies a couple of
points, and fixes a couple formatting issues.
I was planning on leaving this open for a bit and continuing to add
to the patch. If anyone else wants to help, please feel free to update
this patch as you see fit.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I07212849640e8ef14e3c4a41ade29498a4578bc6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Some of the eDp panels use 6bit color depth as default.
Set the default color depth configuration to 6 bit when there
is no match with the supported color depths.
BUG=b:255870643
TEST=Validated on sc7280 Zombie development board
Change-Id: I2cea10ad417a05f020e4c418f15212fee06a2369
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72744
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fw.cfg should combine the SOC name.
This is for future combo feature. Each entry in combo has its own
fw.cfg.
The soc_id in struct cb_config can only be available after the fw.cfg
is processed.
Some functions which take soc_id as a parameter can be simplified.
3/5 (and the key one with same change ID)
of split changes of https://review.coreboot.org/c/coreboot/+/58552/28
Change-Id: Ib0eead1f2156542ea03d58145f5ad67683bf9b52
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58552
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
For MDN, PHX, & Glinda platforms, the Keyboard Reset functionality has
been moved from GPIO 129 to GPIO 21.
Additionally, the issue where the system would reset when the KBDRST_L
pin went low even when not configured for Keyboard reset seems to have
been fixed, so remove that text.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iefe7e00d63777577b59ee98cb974b07afea1fd12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72912
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
One of the main functions performed by the FSP GOP driver is to modify
the ATOMBIOS tables (part of the VBIOS) in memory based on the display
output configuration. This device-specific modified VBIOS can be cached
in a FMAP region specific for that purpose, then loaded into memory
instead of the "generic" VBIOS, saving the ~130ms execution time of the
GOP driver.
As this approach only works when no pre-OS display output is needed,
limit its use to ChromeOS builds, with the GOP driver enabled, and
not booting in either recovery or developer modes.
SoCs supporting this feature will need to selectively run the FSP GOP
driver as needed, using the same criteria used here to determine
whether to load the VBIOS from CBFS or from the FMAP cache.
Boards utilizing this feature will need to add a dedicated FMAP region
with the appropriate name/size, and select the required Kconfig options.
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: Ib9cfd192500d411655a3c8fa436098897428109e
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Using a &uint64_t as a string argument does not include the required
NULL character termination. Update the format string to only print the 8
desired characters and not continue printing stack memory until a NULL
is found.
Before:
[EMERG] Invalid UPD signature! FSP provided "AMD_01_M;....`", expected was "CEZANE_MAMD_01_M;....`".
After:
[EMERG] Invalid UPD signature! FSP provided "AMD_01_M", expected was "CEZANE_M".
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ib334daa8518a92e0cf3d22c4d95908f4c84afe04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72911
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit ae20d4c78f ("mb/google/volteer: Fix USB4 enabling for volteer
family") reworked the USB4/TBT config for volteer, but drobit variant
was missed for some reason. Add the missing USB4/TBT entries.
TEST=build/boot Windows on drobit, verify USB4/TBT functional.
Change-Id: I43d771eeaf29b4e141b222ccb05af5cb7ceedc6f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72141
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Commit 525c61f74e ("mb/google/hatch: Implement touchscreen power
sequencing") contained a copy/paste error; KOHAKU's enable GPIO is set
twice in ramstage, and the reset GPIO not at all, leading the
touchscreen to not be detected.
Correct the copy/paste error by replacing the 2nd instance of GPP_C12
with GPP_D15.
TEST=build/boot Windows/Linux on KOHAKU, verify touchscreen works.
Change-Id: I08d35f1e2a951cdaa463daa34df2134fdc8c65c8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Enables display backlight control under Windows.
VBT extracted from stock ChromeOS firmware Google_Drallion.12930.543.0.
TEST=build/boot Win11 on drallion, verify OS backlight control
available and functional.
Change-Id: I85065f22b825a7616fa4ac632c42ae7972091e24
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Under Win11, a longer delay after asserting reset is needed for the
Goodix touchscreen to init properly. Increase the reset delay to match
that used for the Goodix touchscreen by other volteer variants (120ms).
TEST=build/boot Win11, Linux on eldrid variant with Goodix touchscreen,
verify functional.
Change-Id: I489f037f0bbade9567aad2ad64404a5ac66965d9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some older devices use the vpd key 'ethernet_mac' vs 'ethernet_mac0'
for the first/only LAN NIC, so don't treat the key lookup as an error.
If no MAC is able to be found, another error will be printed later
in the driver init.
TEST=build/boot google/fizz, dump cbmem log, verify 'ethernet_mac0'
lookup failure printk output at warning level.
Change-Id: If5226f4686a819a7020fd14f130181420ee1462b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Move the missing APCB warning to the end of the build and make it stand
out better. Prior to this patch, the warning would appear as one of the
first build messages and easily be missed due to the rest of the build
messages.
TEST=build with and without proper APCBs being found, warning message
appears only when APCB is not found and stands out more
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Iabe32636b8e31fe781519533a329a08535bd661a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Instead of having a magic entry in the CPU device ID table list to tell
find_cpu_driver that it has reached the end of the list, introduce and
use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is
compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID
instead of the 0 in the CPU_TABLE_END definition.
TEST=Timeless build for Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
1. add functions to generate if greater than conditions:
acpigen_write_if_lgreater_op_op:
if (op1 > op2)
acpigen_write_if_lgreater_op_int:
if (op > val)
acpigen_write_if_lgreater_namestr_int:
if (namestr > val)
2. add function to assignal value to a namestr
acpigen_write_store_namestr_to_op:
namestr = val
TEST=Use above functions and check the generated SSDT table after OS
boot.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Iffe1b23362a7ab58bdc2aa8daf45cd6f086ee818
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72825
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When enable_gpio is used as active low output, the _STA returns
incorrect value.
Also, simply the logic for _STA method.
When enable pin is used for _STA:
| polarity | tx value| get_tx_gpio() | State |
| active high | 0 | 0 | 0 |
| active high | 1 | 1(active) | 1 |
| active low | 0 | 1(active) | 1 |
| active low | 1 | 0 | 0 |
When reset pin is used for _STA:
| polarity | tx value| get_tx_gpio() | State |
| active high | 0 | 0 | 1 |
| active high | 1 | 1(active) | 0 |
| active low | 0 | 1(active) | 0 |
| active low | 1 | 0 | 1 |
Generated _STA method:
Ex: for using active low power enable GPIO pin GPPC_H17:
Method (_STA, 0, NotSerialized) // _STA: Status
{
Local0 = \_SB.PCI0.GTXS (0x5C)
Local0 ^= One
Return (Local0)
}
TEST=Check the SSDT when booted to OS.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Ie6f1e7a5b3e9fd0ea00e1e5b54058a14c6e9e09e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72421
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This includes mb/dell/e6400 and ec/dell/mec5035, the latter being
the EC on the E6400. Also link to my repo containing research
and documentation I wrote for the MEC5035.
Change-Id: I5b521e6b1fce5b076be6f0392d99aafac35b0084
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Mainboard name is Compal JBL00. This is based on the GM45/ICH9M chipset
and uses DDR2 RAM. The EC is a SMSC MEC5035 which has internal flash, so
there's no issue about making sure to include the EC firmware in the
BIOS region. This only supports the variant with integrated graphics
only, the version with a discrete Nvidia Quadro NVS 160M is not
supported.
This port was based on the Lenovo T400 port.
Working:
- USB EHCI debug (lower USB port on right side)
- Keyboard
- Touchpad/trackpoint
- VGA
- Displayport
- ExpressCard
- Audio
- Ethernet
- mPCIe WiFi
- mPCIe Bluetooth (uses USB)
Not working:
- Brightness hotkeys
- Physical Wireless switch
- SD card slot: Linux outputs an "irq 18: nobody cared" message when
inserting a card, after which it disables the IRQ
Unknown/untested:
- Dock
- Smartcard (slot and contactless)
- Firewire
- eSATA
- TPM
- Battery (my battery is at the end of its lifespan)
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Change-Id: I516ebbf4390a3f6d242050da8d35dc267b8b3a28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59704
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
For Carrizo, the soc name was set as UNKNOWN.
The change is supposed to be binary unmodified, except the SPI
settings. According to the spec, the Stoneyridge and Carrizo have the
same definition of SPI setting in EFS.
Change-Id: I9704a44773b2f541f650451ed883a51e2939e12a
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Move eMMC init from depthcharge into coreboot to remove it from the
critical boot path. Doing so saves us almost 35ms on villager:
before change:
finished storage device initialization 50,783
after change:
finished storage device initialization 16,255
BUG=b:254092907,b:218406702
BRANCH=None
TEST=flash new FW onto villager and make sure can boot from eMMC
Change-Id: I1af1ec162029120332e7f531f75c3780266d322b
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add NO_S0IX_SUPPORT for boards that do not support, or do not want
to support S0IX.
As all the boards in the tree that do this, don't support D3Cold,
add D3COLD_SUPPORT that defaults to `n` when NO_S0IX_SUPPORT is
selected to disable D3Cold support.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I04abc7efe2db06ae6daba9e09835441b62ee44f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This is required to prevent the EC from shutting down the system after
about 15 seconds after being turned on. If the EC doesn't receive a
command meaning "CPU OK" it assumes that the processor has failed and
flashes a diagnostic code on the keyboard LEDs to indicate this.
This also enables the keyboard and trackpad/trackpoint interfaces.
Parts of this code were derived from yet-to-be merged code in CB:44975
(ec: Add support for MEC5055 for Dell laptops) written by Iru Cai.
Tested on a Dell Latitude E6400
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Change-Id: Ia420cd51e9a64be5eee4af2c0d113618575522b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59703
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update ec_commands.h from the EC repo at:
"8b6f7de2a7 fan: update fan stalled value reporting"
This is an exact copy of the EC repo's ec_commands.h with the
exception of updating the copyright message.
BUG=b:258110734
BRANCH=none
TEST=built coreboot for brya
Change-Id: I4ce15e1af40cc54a6cf2ebd6f5d5adf8953dee60
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This is a format-only change: Reformat ec_commands.h using clang-format
according to the EC repo's current formatting style.
The command is:
clang-format --style=file:$EC/.clang-format -i ec_commands.h
where $EC points to the chromeos EC repo.
The EC repo has recently adpoted the practice of formatting all files
through clang-format using its own style. So, run ec_commands.h through
the EC's clang-format so future updates don't get overwhelmed by
inconsequential style changes.
BUG=b:258110734
BRANCH=none
TEST=built coreboot for brya
Change-Id: Icbd6d00922dc5fd4c44ee109d54cea612e15db06
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch enables PCI Express Advanced Error Reporting Capability for
WWAN, WLAN, and SSD root ports. On enabling PCIE_RP_AER, PCIE device
will automatically report (if any error) about the error nature to the
corresponding PCIe root port.
BUG=b:224325352
BRANCH=None
TEST=Build and boot mtlrvp to ChromeOS.
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Iab8619818e2219b41287b895513eb04b0464401e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Use common sdhci driver in coreboot to initialize eMMC for sc7280.
This should allow us to initialize eMMC earlier in the boot process,
taking it out of the critical path.
BUG=b:254092907
BRANCH=None
TEST=emerge-herobrine coreboot chromeos-bootimage
Change-Id: Ifa88da500e82b44d7523f2e68763e01399c89f4d
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71829
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Porting from depthcharge changes for supporting eMMC driver
functionality with standard SDHC controller on Qualcomm chipsets.
sdhci_msm_init() needs to be run before the standard
sdhci_mem_controller initiailzation.
BUG=b:254092907
BRANCH=None
TEST=emerge-herobrine coreboot
Change-Id: I6f4fd1360af1082b335f9cc3046871ce9963b5d0
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72634
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adding a attach callback function pointer in case a platform needs
to execute anything before the standard initialization of the sdhci
mem controller.
BUG=b:254092907
BRANCH=None
TEST=emerge-herobrine coreboot
Change-Id: I0f37ec09d083922cad5ecd3c47b184cf3311fe2d
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Port over the remaining AMD SoCs to use CPUID_FROM_FMS. The Glinda CPUID
still needs to be updated to the actual CPUID, but for now just change
it to use CPUID_FROM_FMS.
TEST=Resulting image of timeless build for Gardenia (Stoneyridge),
Majolica (Cezanne), Chausie (Mendocino), Mayan (Phoenix) and Birman
(Glinda) don't change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia508f857d06f3c15e3ac9f813302471348ce3d89
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72862
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a macro to get the raw CPUID leaf 1 EAX value from a given set
of CPU family, model and stepping. The processor type in bits 12 and 13
is assumed to be always be zero; at least this is the case for all
CPUIDs that are currently in the coreboot tree. This can be used to
make the device values in the CPU device ID tables easier to read.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idab77453712b14983b1d02ca365f7924239fc2bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72856
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use CPUID_ALL_STEPPINGS_MASK to only need one CPU device ID table entry
per family & model combination and not one per stepping.
TEST=Mandolin with a Picasso APU with PICASSO_B1_CPUID (0x00810f81)
still finished mpinit and boots successfully even though now only
PICASSO_B0_CPUID (0x00810f80) with CPUID_ALL_STEPPINGS_MASK specified as
device match mask. When commenting out the line with PICASSO_B0_CPUID
as a negative test, mpinit fails as expected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00ba43834ad86ecffa09d60599b17d122acd0b99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72848
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of always doing exact matches between the CPUID read in
identify_cpu and the device entries of the CPU device ID table,
offer the possibility to use a bit mask in the CPUID matching. This
allows covering all steppings of a CPU family/model with one entry and
avoids that case of a missing new stepping causing the CPUs not being
properly initialized.
Some of the CPU device ID tables can now be deduplicated using the
CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this
patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0540b514ca42591c0d3468307a82b5612585f614
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since all SoCs define the df_mmio_control union for the bits used in the
code, data_fabric_print_mmio_conf can take advantage of that and also
print a decoded version of those bits.
Output on Mandolin before the patch:
=== Data Fabric MMIO configuration registers ===
idx control base limit
0 93 fc000000 febfffff
1 93 10000000000 ffffffffffff
2 93 d0000000 f7ffffff
3 1093 fed00000 fedfffff
4 90 0 ffff
5 90 0 ffff
6 90 0 ffff
7 90 0 ffff
Output on Mandolin with the patch:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06e1d3a3e9abd664f59f2bb852394e7f723f2b30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
In contrast to Mendocino and all other AMD SoCs in the coreboot tree,
Rembrandt, on which Mendocino is based on, has a DF_MMIO_REG_SET_SIZE of
3 instead of 4, so the next data fabric MMIO register is 3 DWORDs after
the last one instead of the 4 DWORDs on the other SoCs. This was checked
against PPR #56558 Rev 3.04.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I454ad5d182f0040db93c9b3a83941333392c6061
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
To be able to handle a special case, add a per-SoC define for
DF_MMIO_REG_SET_SIZE instead of having this hard-coded as 4 in the
DF_MMIO_* macros. To avoid some duplication, also introduce the
DF_MMIO_REG_OFFSET macro.
TEST=Output from data_fabric_print_mmio_conf doesn't change on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67420a2973c8ef9a7f0ce19ddc0013de69731689
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The address mode is an internal mode which AMD FWs use. Regular
developers don't have to know that. Just report the relative address
every time. For the cases head and body are split, the address of body
is also reported.
Change-Id: I77d9aac0b3d996363341c1d2dae049ec344b39aa
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This patch adds ACPI configuration for USB2/3 ports for mtlrvp as per
schematics. This helps in generating corresponding ACPI code at runtime
that includes port information.
BUG=b:224325352
BRANCH=None
TEST=Able to build and boot MTLRVP. Connect USB device and check if
corresponding enumeration of USB device (14.0) is observed on executing
lspci.
00:14.0 USB controller: Intel Corporation Device 7e7d (rev 01)
00:14.1 USB controller: Intel Corporation Device 7e7e (rev 01)
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Ie150247661322e3944be15dc70f66033266d8aac
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72787
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch describes the TCSS USB ports for mtlrvp as per schematics.
This patch describes TCSS ports for UPC_TYPE_C_USB2_SS_SWITCH as below,
tcss_usb3_port1: USB3 Type-C Port C0
tcss_usb3_port2: USB3 Type-C Port C1
tcss_usb3_port3: USB3 Type-C Port C2
tcss_usb3_port4: USB3 Type-C Port C3
BUG=b:224325352
BRANCH=None
TEST=Able to build and boot MTLRVP to ChromeOS. Verify the enumeration
of xhci (0d.0) as part of lspci. Also verify the enumeration of Type-C
ports as part of cbmem -c.
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I0054ac4e3d1d9b97cfea615831ec8f3d3e00c9e0
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72785
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables FM350GL 5G WWAN support for mtlrvp.
BUG=b:224325352
BRANCH=None
TEST=Build and boot mtlrvp to ChromeOS. Ensure that WWAN module 00:1c.6
is enumerated as part of lspci and cbmem -c in AP console. Also verify
generation of PXSX Device as part of SSDT. Able to connect WiFi and
access internet.
cbmem -c:
\_SB.PCI0.RP07: Enable RTD3 for PCI: 00:1c.6 (Intel PCIe Runtime D3)
\_SB.PCI0.RP07: Enable WWAN for PCI: 00:1c.6 (Fibocom FM-350-GL)
SSDT:
Scope (\_SB.PCI0.RP07)
{
Device (PXSX)
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I870cc0782fb989f1bdbe369a4a12630a62729d8e
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72779
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for samsung boards lumpy and stumpy. 0x8000 unused
flash space is allocated for RW_NVRAM.
Previously BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES was selected for
CPU_INTEL_HASWELL, CPU_INTEL_MODEL_{2065X,206AX} and others (see [2]).
However, there seems to be no particular reason on those platforms.
We've dropped the config for haswell. Now drop it for
CPU_INTEL_MODEL_{2065X,206AX}, so that VBOOT_VBNV_FLASH can be enabled.
[1] https://web.archive.org/web/20230115020833/https://issuetracker.google.com/issues/235293589?pli=1
[2] commit 6c2568f4f5
("drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config")
BUG=b:235293589
TEST=./util/abuild/abuild -a -t SAMSUNG_LUMPY -x
Change-Id: I833edd4f7a328b21e81c971ba8a9aec0aad7d3d3
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70296
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
This change adds 2 command line parameters, --skip_set and --skip_unset
that allows abuild to skip boards with particular Kconfig values either
set or not set.
Note that it only works on BOOL type variables.
This can be set on the abuild command line, or the JENKINS_ABUILD_OPT=
variable on the make command line.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I43336484cf25f83065ec7facf45c123d831024b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Since things are done a bit differently on Stoneyridge, it's probably
safer to run a test instead of assuming that the test on Picasso was
sufficient to be reasonably sure that this will also work as expected on
Stoneyridge.
TEST=No change of ACPI-related messages in dmesg with this patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I432752fae8be08d3cbd7d30215b350c4528c7206
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Create the constitution variant of the brask reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:267539938
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_CONSTITUTION
Change-Id: Idb6089561d3aa5aac4448f9d46347c731f027e9c
Signed-off-by: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72730
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of just printing the register contents, normalize the contents
of the base and limit registers to actual MMIO addresses and then print
those. This will hopefully avoid some confusion caused by the shifted
addresses.
Output on Mandolin before the patch:
=== Data Fabric MMIO configuration registers ===
Addresses are shifted to the right by 16 bits.
idx control base limit
0 93 fc00 febf
1 93 1000000 ffffffff
2 93 d000 f7ff
3 1093 fed0 fedf
4 90 0 0
5 90 0 0
6 90 0 0
7 90 0 0
Output on Mandolin after the patch:
=== Data Fabric MMIO configuration registers ===
idx control base limit
0 93 fc000000 febfffff
1 93 10000000000 ffffffffffff
2 93 d0000000 f7ffffff
3 1093 fed00000 fedfffff
4 90 0 ffff
5 90 0 ffff
6 90 0 ffff
7 90 0 ffff
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I62eeb88ddac6a7a421fccc8e433523459117976a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This moves the definition for POST_BOOTBLOCK_CAR from the intel-specific
postcodes into the common postcode list, and uses it for the
cache-as-RAM init as needed.
Because POST_BOOTBLOCK_CAR was set to 0x20 in some spots and 0x21 in
most of the others, the values were consolidated into 0x21. This will
change the value on some platforms.
Any conflicts should get sorted out later in the conversion process.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8527334e679a23006b77a5645f919aea76dd4926
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch enables PCIe port for WWAN as per mtlrvp schematics
BUG=b:224325352
BRANCH=None
TEST=Build and boot mtlrvp to ChromeOS. Ensure that WWAN module
gets enumerated with cbmem -c.
\_SB.PCI0.RP07: Enable RTD3 for PCI: 00:1c.6 (Intel PCIe Runtime D3)
\_SB.PCI0.RP07: Enable WWAN for PCI: 00:1c.6 (Fibocom FM-350-GL)
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Ib372db9642a3c7b3a21a112fa0e6e0b4bc88a9ea
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72777
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Mendocino SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1ed0407826f579eb14169246b7b14ba677c20e8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Cezanne SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6953da5e0f1966aa3022364d9a9c72ebafc698cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Picasso SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia265f3eebf5e48c185d2e4bf4ef74f8eab7c9606
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Stoneyridge SoC, remove it form the global
NVS and add an ACPI object for this in the DSDT of the mainboards that
use it in their ACPI code. Eventually the LIDS object should probably be
moved to the EC's ACPI code, but that's out of scope for this patch.
TEST=google/liara doesn't show ACPI errors in Linux' dmesg
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I778c4189607035b4765c6cb8b2e74030dcf9069f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This simplifies the code flow of the cpu init. APL can do CPU init after
calling FSP-S, while GLK needs to do that before. This is now reflected
directly in the cpu ops rather than using
CONFIG_SOC_INTEL_COMMON_BLOCK_CPU_MPINIT as a proxy.
Change-Id: I7fd1db72ca98f0a1b8fd03a979308a7c701a8a54
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
By default this limits PCI buses to CONFIG_MMCONF_BUS_NUMBER.
Some platforms have multiple PCI root busses (e.g. xeon_sp), where bus
numbers are limited. This provides a basic check. On some platforms it
looks like programming 0xff to the subordinate bus number confuses and
hangs the hardware.
Change-Id: I0582b156df1a5f76119a3687886c4d58f2d3ad6f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This patch removes the configuration of GPP_A12 for mtlrvp. Garfield
Peak (WLAN) doesn't use GPP_A12 for WAKE_N. Configuring GPP_A12 pin
prevents system entering G3 (reboots) on issuing shutdown -h now. Hence
configuring GPP_A12 as PAD_NC.
BUG=b:224325352
BRANCH=None
TEST=On issuing 'shutdown -h now' system enters G3
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I5e46b8afd3e0055440fd3c3db4aa5a9f1d4aa556
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Usha P <usha.p@intel.com>
We don't need flashrom support just for vboot payloads. The current
default (USE_FLASHROM=1) is mostly harmless, especially if libflashrom
is not present (the autodetection in vboot_reference just spits out a
pkg-config error but doesn't actually fail the build), but it's better
to be clear we don't need it.
BUG=b:172225709
TEST=build
Change-Id: I53bcc2d1e7666646ddad58ba3717cfdd321014e8
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72716
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
NVMe PCIe 9-12 using clk_src1 and clk_req2 mapping to hardware design,
Due to inconsistency between PMC firmware and FSP, we need to set
clk_src to clk_req number, not same as hardware mapping in coreboot.
Then swap correct setting to clk_src=1,clk_req=2 in mFIT.
BUG=b:265720813
TEST=build firmware and veirfy suspend function on DUT.
Cq-Depend: chrome-internal:5351299
Change-Id: Ia057dfa98cb9293d9e212edb4e4ac198e94e8985
Signed-off-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72051
Reviewed-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add configuration to bump up the SPI flash bus speed from 66 MHz to 100
MHz starting the board version of the current phase.
BUG=b:260127676
TEST=Build and boot to OS in Frostflow with 100 MHz SPI bus speed.
Observe that the boot time improved by 100 ms compared to 66 MHz SPI
flash bus speed.
firmware log:
SPI fast read speed: 100 MHz
At 66 MHz:
Total Time: 1,563,384
At 100 MHz:
Total Time: 1,462,570
Change-Id: I9435f4ad0d3541b040703dc9a453badbd080dc09
Signed-off-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72694
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Fix:
cc1: error: src/vendorcode/amd/pi/00670F00: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/binaryPI: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/Include: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/Proc: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/Proc/Common: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/Proc/CPU: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/Proc/CPU/Family: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/Proc/Fch: No such file or directory [-Werror=missing-include-dirs]
cc1: error: src/vendorcode/amd/pi/00670F00/Proc/Fch/Common: No such file or directory [-Werror=missing-include-dirs]
Change-Id: I745f4fc421c91c413fe0d3155d3494ed9704eeb6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The PCI Device ID Assignments table from PPRs #57019 Rev 1.65 and
PPR #57396 Rev 1.54 were used as a reference. Some devices will need to
have ops added in future patches. Since the xhci_2 device isn't there
any more, also drop it from the mainboard devicetrees. The actual USB
port configuration on xhci_0 and xhci_1 is updated in the next patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I49721bc44fa1e2a0118a8c3ac79a36aee64be687
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Now that the PCIe ports on device 1 are added, rename the aliases for
the PCIe ports on device 2 to have a common naming scheme. For phoenix
the device alias names are based on the device and function number the
bridge is connected to.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5f5698408019bb9222b599dd78540ca1b187b56d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72737
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only the PCIe ports on the functions of device 2 were present in the
devicetree and had the amd_external_pcie_gpp_ops ops assigned. Add the
missing PCIe ports on the functions of device 1 and assign the
amd_external_pcie_gpp_ops ops to them.
This SoC uses a slightly different naming scheme for its PCIe GPP ports.
Previously the PCIe GPP bridge number from the PCI Device ID Assignments
table from the PPR was used. Those bridge numbers are one less than the
function numbers of the device. This is due to function 0 being a dummy
bridge to avoid having to shuffle around the function numbers when the
first bridge is unused, since the PCIe specification mandates the
function 0 to be implemented if any other function on the same device is
implemented. In order for the device aliases to be consistent with the
PCIe device and function numbers which is way more commonly used and
also what lspci shows and what goes into the DXIO descriptors, change
the naming scheme of the aliases.
This was checked with PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib5c62c1df585877d9b6986a462a3636d4f2eb4c7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72736
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This enables L1.2 for the SSD port.
link_hotplug is unused on Mendocino, so remove it while I'm here, just
as code cleanup. This has no functional difference.
Enabling L1.2 on other devices currently causes problems. Debug is
ongoing.
BUG=b:265890321
TEST=Build & boot, look at states enabled in lspci. Test device
functionality.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8940856a127c8a4ba45148cbbf07a08b621beb4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Commit b171f76812 ("soc/amd/*: Hook up GPP bridges ops to devicetree")
missed adding the amd_external_pcie_gpp_ops ops to the gpp_gfx_bridge
PCIe ports, so add them. Those devices were previously covered by the
PCI_DID_AMD_FAM17H_MODEL60H_PCIE_GPP_D1 PCI device ID in the list that
got removed in the referenced commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I55434bf486569b32901b3840193a09cc5955abb2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This allows us to use the same file for PCO, CZN, MDN, PHX, & Glinda.
PCO supports the warm reset, and future chips can support it by setting
the SOC_AMD_SUPPORTS_WARM_RESET option.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib6459e7ab82aacbe57b4c2fc5bbb3759dc5266f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72658
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adding EC_HOST_EVENT_PANIC to SCI mask allows the EC to interrupt the
Kernel when an EC panic occurs. If system safe mode is also enabled
on the EC, the kernel will have a short period to extract and save info
about the EC panic.
BUG=b:266696987
BRANCH=None
TEST=Observe kernel ec panic handler run when ec panics
Change-Id: I9b50ab3c0bcef192ef89f173852cda222f1533c7
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
This patch enables CNVi_BT Core and Wifi for mtlrvp based on mtlrvp
schematics.
1. Enable CNVi BT Core in device tree
2. Enable CNVi Wifi (pci 14.3) device in device tree
BUG=b:224325352
BRANCH=None
TEST=Able to observe corresponding UPD configuration with FSP dump and
able to boot mtlrvp (LP5/DDR5) to ChromeOS.
CNVi Mode = 1
Wi-Fi Core = 1
BT Core = 1
BT Audio Offload = 0
BT Interface = 1
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I22575bf31b540f9dc1149a2766268285001b72f4
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72695
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarily share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ib96fcb86fd2c3fe16f23c8f038f4930a832a5b01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Some reserved address range listed in Alder Lake Platform Firmware
Architecture Specification document 626540 section 6.4 ADL - System
Memory Map such as North TraceHub ranges were missing. Details about
North TraceHub (aka. Intel TraceHub) can be found in Intel Trace
Hub (Intel TH) Developer's Manual document 671536.
BUG=b:264648959
TEST=Compilation successful
Change-Id: I14803a7297c8c5edefe564d92bfe7314f6769942
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The testsoc script was pulling in odd results when the -K option matched
options in sources, Makefiles, and device trees. Adding another grep to
limit the list to just Kconfig matches ensures that only actual
mainboards are built.
TEST="./util/testsoc -K PICASSO" no longer tries to build mainboard "0"
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I3860df4520a5594fb9c1a06e75487520b7d5d275
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72655
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If we show the user early signs of life during CSE FW sync or MRC
(re)training, log these to the eventLog (ELOG_TYPE_FW_EARLY_SOL).
These can be used to ensure persistence across global reset (e.g. after
CSE sync) so that they can be later retrieved in order to build things
such as test automation ensuring that we went through the SOL
path/display initialized.
BUG=b:264648959
TEST=event shows in eventlog after CSE sync and/or MRC
Change-Id: I8181370633a1ecff77b051d3110f593c3eb484a2
Signed-off-by: Tarun Tuli <taruntuli@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71295
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Contents of the EDID are passed by a reference to an array
of length 0x80, for which the macro 'PTN_EDID_LEN' has already
been around.
This patch makes use of this macro within the driver and mainboard
implementation utilizing it.
BUG=none
TEST=A successful build of mc_apl{1,4,5,7} and mc_ehl3 mainboards.
Change-Id: If7d254aaf45d717133bb426bd08f8f9fe5c05962
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This is regarding issues observed on multiple Brya and Nissa
variant such as Skolas and Nivviks. Issue is that once coreboot
sets GPE_EN bit for the GPIO pin and locks it, kernel is not able
to change the control bit. Hence kernel is not able to control the
IRQ on the pin when required.
This issue was root caused to the patch which was setting GPE_EN
bits for the GPIOs before locking.
Ref: commit 38b8bf02d8
("intelblocks: Add function to program GPE_EN before GPIO locking")
This patch skips the locking for GPP_F14 to allow kernel to
configure it later during reboot or shutdown as required.
BUG=b:254064671
BRANCH=None
TEST=Shutdown works on Skolas and Brya board with the patch.
Signed-off-by: Maulik Vaghela <maulikvaghela@google.com>
Change-Id: I7e4a6ac4668028bcd5fa400b9aa8eccf36a79620
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72648
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is an existing issue for skolas boards where board wakes up
from shutdown immediately due to touchpad wake signal.
This issue was root caused to the patch which was setting GPE_EN
bits for the GPIOs before locking.
Ref: commit 38b8bf02d8 ("intelblocks: Add function to program GPE_EN before GPIO locking")
Later issue was found to be with GPP_F14 configuration for skolas
boards. While shutting down, kernel is not able to disable IRQ for
touchpad due to GPE_EN register getting locked and it is preventing
shutdown of the board.
This patch skips the locking for GPP_F14 to allow kernel to
configure it later.
BUG=b:254064671
BRANCH=None
TEST=Shutdown works on Skolas board with the patch.
Nissa Bug: 234097956
Signed-off-by: Maulik Vaghela <maulikvaghela@google.com>
Change-Id: I09cf1af1f5ab11b06073755374ee8a306984d557
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72426
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Otherwise configurations in src/mainboard/ocp/tiogapass/Kconfig
cannot be selected by
make defconfig KBUILD_DEFCONFIG=configs/builder/config.ocp.tiogapass
Change-Id: I88d5619269a6a9c09e84061642206a17c91db042
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72642
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Wellsburg is IFDv2 compatible in most fields, but not in all.
It only has 8 regions and the flash master bits match the defines for
IFDv1 and thus has an "IFDv1.5" descriptor.
Add a new enum for IFDv1.5 descriptor and use them to properly operate
on this IFD.
The 'SPI programming guide' is inconsistent and mentions 6 regions
in one place, but 7 regions in another chapter. Tests showed that it
actually supports 7 regions.
Add support using the -p argument to specify Wellsburg platform.
The previous patch made sure that only 8 regions are used and that no
corruption can happen when operating in IFDv2/IFDv1.5 mode.
Tested on Intel Grangeville.
Documents used:
Intel Document Id: 516552
Intel Document Id: 565117
Change-Id: I651730b05deb512478d059174cf8615547d2fde4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Co-developed-by: Julian Elischer <jrelis@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
With New Crypto upgrade we need to have 1 block of 4Kb increase in
romstage, by which we can see an improvement of Boot performance
by 100 msec.
BUG=b:218406702
TEST=Validated on qualcomm sc7280 development board
Boot performance improved by 100 msec observed.
Change-Id: I9f5c8a79993fc1c529fae5cea4c4182663643ddd
Signed-off-by: Sudheer Kumar Amrabadi <quic_samrabad@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72646
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
During boot, gpi_firmware_load gets called twice because there are
2 serial engines. Thus gsi_fw blob is also decompressed twice and is
written to base addresses of SEs. This is redundant.
Perform the decompression once on first call and save the header
in static variable which can be reused in next call.
BUG=b:262426214
TEST=Validated on qualcomm sc7280 development board
Saving of 80ms observed while testing with 130 boot cycles.
Change-Id: If98a3974f0791dffdf675c02cc28375d0485c485
Signed-off-by: Vijaya Nivarthi <vnivarth@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71927
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarily share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I58faed286718f5eab714cd39001177e50feb4f8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72414
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarily share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ic42c67163fe42392952499293e91e35537cb9147
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarily share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I34d3c4a60653fe0c1766cd50c96b8d3fe63637d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The D-state list lists the devices with the corresponding
D-state that the devices should be in, in order to enter LPM.
DPTF is not mentioned in Intel's document 595644 as one of
the devices.
This CL removes it to avoid a potential error seen in ADL
devices as mentioned in commit 3fd5b0c4cdeb ("soc/intel/adl:
remove DPTF from D-states list used to enter LPM")
TEST=Built and tested on Rex, saw SSDT generated properly.
BUG=b:231582182
Signed-off-by: Eran Mitrani <mitrani@google.com>
Change-Id: I9192ed9a7fb59ebba14f6d5082b400534b16ca72
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72603
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- The 4.19 release notes included a list of outstanding issues formatted
as a markdown table, which is not supported by Recommonmark. Reformat
as an embedded reStructuredText table.
- The table of boards supported on the 4.18 branch did not include row
separators causing all rows to be rendered in a single row of cells.
- Technotes/console.md had a typo in the rST table formatting which
generated warnings in the Sphinx build, causing the table to not be
rendered in the resulting html.
Change-Id: I86e2c5d6d20e6002b87efc4688fc11b24b341227
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Currently there is a problem, where two Displayports are not working. To
be precise: TCP0 and TCP1 (Type-C Port 0/1) are not working.
Setting the lane count of the TCP0 and TCP1 to x1 works fine.
Setting the lane count of the TCP0 and TCP1 to x2 does not work.
Setting the lane count of the TCP0 and TCP1 to x4 does not work.
The reason for that is currently unknown.
This change sets the lane count of the TCP0 and TCP1 Port to x1 length
in the VBT binary.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I182b528275152bf5adcb01a56816afd65674aed3
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72610
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Markdown does not render newlines unless there is an empty line in
between the lines of text. Several command examples and a list were
missing these empty lines, causing their content to be rendered inline
with the preceding text.
Fix this by adding triple backticks around code blocks and bullet points
to rows of text in a list.
Change-Id: I9c1d2b81acdeb378346c68bced0cdbfeeb81bf26
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72625
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In CB:71614 Kyösti pointed out that ACPI_GPE0_BLK is the wrong address
to assign to proc_blk_addr; the correct one would be ACPI_CPU_CONTROL.
When looking a bit closer into this, it turned out that
acpigen_write_processor is generating deprecated AML opcodes, so replace
the acpigen_write_processor call with a call to the newly added
acpigen_write_processor_device function that also doesn't have the
proc_blk_addr and proc_blk_len parameters. The information about the IO
port for entering C-states is already written into an SSDT by
acpigen_write_CST_package which is likely also the reason why the wrong
proc_blk_addr value wasn't noticed for a very long time.
TEST=Mandolin still boots Ubuntu 22.04 LTS and Windows 10 and no
possibly related errors show up. Linux gets the expected C-state
information from the _CST package inside the processor device scope.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie67416e19e431029dd12da66ad44ddfa8586df03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The ACPI PROCESSOR_OP has been deprecated in ACPI 6.0 and dropped in
ACPI 6.4 and is now permanently reserved. As a replacement, DEVICE_OP
with the special HID ACPI0007 should be used instead. This special HID
was introduced in version 3 of the ACPI spec. To have a function to
generate this, acpigen_write_processor_device is introduced. The CPU
index is used as UID which can be assumed to be unique.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifb0da903a972be134bb3b9071f81b441f60917d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72469
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This register isn't used in coreboot and isn't defined in the Picasso
PPR #55570 Rev 3.18.
To enter a lower C-state, a read request to a special IO port is done.
The base address of this group of IO ports is configured in
set_cstate_io_addr via the MSR_CSTATE_ADDRESS and that read won't leave
the CPU. IIRC trying to put the MMIO mapping for entering the lower
C-states into the _CST package didn't work as expected when it was tried
on I think Cezanne.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib189993879feaa0a22f6810c4bd5c1a0bc8c5a27
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarily share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I7dfd331e70f6d03c88248ca5147dbe6785a8e69d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
It turns out that the [0xfa000000-0xfaffffff] range conflicts with
some North TraceHub address space ranges ([0xfad00000-0xfadfffff] and
[0xfacfc000-0xfacfffff]).
Experiments have established that this conflicting range results in an
unpected PIPE A underrun issue reported by i915 and some visible
flickers on the display during boot.
The [0xf0000000-0xffffffff] range is a crowded memory space with
resources statically assigned to some devices but also some ranges
used at various point in the boot flow by the FSP.
To not run into any other potential conflicts, we want to pick a
unused memory space. But at this early stage of the boot, we do not
have full knowledge of what memory space is going to be used by the
FSP. As a result, we decided to pick the [0xaf000000-0xafffffff] range
as:
1. It does not conflicting with any coreboot memory space usage
2. It is the address the FSP uses by default for GFX MMIO BAR0 and as
such should not conflict with any FSP memory space usage.
BUG=b:264648959
BRANCH=firmware-brya-14505.B
TEST=No flickers observed on boot
Change-Id: I6a00350ff4007bb7692d2ff6598b946cc6123302
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72605
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Functionality wise nothing changed, except that the first misspellings
caused SBOM_BIOS_ACM_PATH and SBOM_SINIT_ACM_PATH to not work before.
- Fix misspelling of CONFIG_BIOS_ACM_PATH -> CONFIG_SBOM_BIOS_ACM_PATH
- Fix misspelling of CONFIG_SINIT_ACM_PATH -> CONFIG_SBOM_SINIT_ACM_PATH
- Put SBOM_COMPILER_ handling into Kconfig instead of Makefile
- Reorder CONFIG_ paths (for readablity)
- Add in code comments (for readablity)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If67bc3bd0d330b9b5f083edc4d1697e92ace1ea0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This uses a simpler form of #if to check if CONFIG_SAVE_MRC_AFTER_FSPS
is enabled, referencing the Kconfig variable only once and defaulting
to the original behavior if not.
Change-Id: I4711c1474d9a3a5c685dd31561619c568fab075c
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72587
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the PSE GBE0 MAC has been disabled on this board in
commit 343644006f ("mb/siemens/mc_ehl3/devicetree.cb:
Remove TSN GbE 0"), therefore disable the corresponding
GPIOs as well.
BUG=none
TEST=Test link detection and IP assignment on the remaining
ports (PSE GBE1 and PCH GBE0) of mc_ehl3.
Change-Id: Ifa055f58894688471d68b9b93fcb994fdcb2a568
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72449
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds initial romstage code and spd data for LP5 memory
parts for MTL-RVP. This also configures memory based on the board id.
Memory - x32 LPDDR5
Vendor/Model - Micron/MT62F2G32D8DR-031 WT:B
Board ID -
0b0000 - Empty spd hex file
0b0001 - DDR5 (Empty spd hex file)
0b0010 - LPDDR5 (MT62F2G32D8DR-031 WT:B)
BUG=b:224325352
TEST=Able to boot intel/mtlrvp (LP5 SKU) to ChromeOS
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Change-Id: I15b352eb246aed23da273e56490c7094eae9d176
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch selects USE_UNIFIED_AP_FIRMWARE_FOR_UFS_AND_NON_UFS for
Google/Marasov variant which intends to achieve a unified AP firmware
image across UFS and non-UFS skus.
Note: Enabling this config would introduce an additional warm reset
during the cold-reset scenarios due to the function disabling of the
UFS controller as results we are expecting ~300ms higher boot time
(which might not be user visible because `cbmem -t` can't include
impacted boot time due to in-between resets).
BUG=b:264838335
TEST=Able to enter S0ix on Marasov NVMe sku after disabling UFS
during boot path.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie8b8814cdb5e0d97a382cebfe82868ada5762341
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Now that we support >1 Xeon-SP, XEON_SP_COMMON_BASE no longer
reflects the socket type. This uses SOC_INTEL_* Kconfig variables and
returns the correct socket type for Cooper Lake-SP.
Signed-off-by: David Hendricks <ddaveh@amazon.com>
Change-Id: I142de5f040f3b76e352f27c00fe9e50787df5712
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When Kconfig SAVE_MRC_AFTER_FSPS is selected, save MRC training
data after FSP-S instead of FSP-M. For now only SPR-SP server
FSP supports this.
This issue surfaces with SPR-SP, because of the memory type
(DDR5 support) and memory capacity (more memory controllers, bigger
DRAM capacity). Therefore Intel decided to save MRC training data after
FSP-S with SPR-SP FSP.
Change-Id: I3bab0c5004e717e842b484c89187e8c0b9c2b3eb
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71950
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This functionality is used in multiple places, so factor it out into a
function. Compared to acpigen_write_processor_cnot, the buffer size is
decreased from 40 to 16 bytes, but the format string specified by
CONFIG_ACPI_CPU_STRING results in 9 chars and a NULL byte which will fit
into the buffer without any issue. I've seen the CPU devices being put
into another scope within \_SB, but even in that case that would be 14
chars and a NULL byte whist still fits into the 16 byte buffer. For
acpigen_write_processor and acpigen_write_processor_package this doesn't
change any edge case behavior. In the unrealistic case of the format
string resulting in a longer CPU device string, this would have been a
problem before this patch too.
Also drop the curly braces of the for loop in
acpigen_write_processor_package. This makes the code a bit harder to
read and isn't a very good idea, but with the curly braces in place, the
linter breaks the build :(
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5d8291a2aaae2011cb185d72c7f7864b6e2220ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72452
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
ACPI_CPU_STRING specifies the format string for the scope of the
processor devices in the generated ACPI code. Also point out that the
resulting string will be truncated to at most 15 chars to fit into the
16 byte buffer used in two functions in acpigen.c.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1fb1db8adeecd783c835a500d28a13b823cda155
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72451
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Not all Chrome-EC devices have a keyboard or use Vivaldi for key
remapping, so demote the printk output when the EC doesn't support
it from ERROR to INFO. Adjust the printk text for clarity.
Change-Id: I14059f4e3e56ff891f302601d5acc1bb842cffc1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72474
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current CMOS option causes Linux to not boot, as the GRUB EFI
loader will report an incorrect parameter.
Update the CMOS option so that the corresponding UPD is changed when
the wireless is set to disable, so that the root port for the wireless
is also disabled.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I607d700319d6a58618ec95b3440e695c82dff196
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71896
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change the Type-C USB 2.0 interface to a standard port, as the
Type-C macro will not work in Linux (dmesg says the cable is
faulty),
This makes the port work reliably in Linux, tested with:
* Manjaro 21
* Ubuntu 22.04
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I6dbf31b6e4603685297e9e5203b0db6ac1b9e24a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72387
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add functions that allow checking and changing PTT state at runtime.
Can be useful for platforms that want to use dTPM instead and have no
means to stitch ME firmware binary with disabled PTT.
The changing function also checks for the current feature states via
HECI to ensure that the feature state will not be changed if not
needed.
TEST=Successfully switch to dTPM on Comet Lake i5-10210U SoC.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I8426c46eada2d503d6ee72324c5d0025da3f2028
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Return generic coreboot error codes from the mb_adjust_cfg
callback used in mainboards instead of '-1' constant and
a driver-specific success-indicating define.
BUG=none
TEST=Boards siemens/mc_apl{1,4,5,7} and siemens/mc_ehl3
build correctly.
Change-Id: I5e0d4e67703db518ed239a845f43047f569b94ec
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The D-state list lists the devices with the corresponding
D-state that the devices should be in, in order to enter LPM
DPTF is not mentioned in Intel's document 595644 as one of
the devices.
This CL removes it to avoid an error seen after it was added
to that table:
"ACPI Error: AE_NOT_FOUND, While resolving a named reference
package element - \_SB_.PCI0.DPTF (20200925/dspkginit-438)"
TEST=Built and tested on anahera and saw the error is gone
BUG=b:231582182
Change-Id: I00eddd7e4cc71a0c25e77ff53025dee5bf942de1
Signed-off-by: Eran Mitrani <mitrani@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Depending on the actual issue and the experience of the contributor,
"Easy projects" might not be an appropriate description for Coverity
issues and similar things.
Thus rename this section to "Small projects" and also update references
to it.
Change-Id: I3bdefd9f37440ab3ae493095b7fb5c76394d2ba1
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72447
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
add functions for concatenate OP
add debug message containing concatenated string with string, value, or
OPs
Ex1: to print string with another string provided from C side:
acpigen_write_debug_concatenate_string_string("Wait loop Timeout! var=",
name, LOCAL6_OP);
will generate:
Concatenate ("Wait loop Timeout! var=", "L23E", Local6)
Debug = Local6
Ex2: to print string with a value:
acpigen_write_debug_concatenate_string_int("ModPHY enabling for RP:",
pcie_rp, LOCAL0_OP);
will generate:
Concatenate ("ModPHY enabling for RP:", 0x05, Local0)
Debug = Local0
Ex3: to print string with an ACPI OP:
acpigen_write_debug_concatenate_string_op("while Loop count: ",
LOCAL7_OP, LOCAL6_OP)
will generate:
Concatenate ("while Loop count: ", Local7, Local6)
Debug = Local6
TEST=Add above functions in the acpigen code and check the generated
SSDT table after OS boot
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I370745efe3d6b513ec2c5376248362a3eb4b3d21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72126
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Enable early POST code display on this variant using
the common mc_apl1 baseboard functionality.
BUG=none
TEST=Boot on mc_apl5 and observe that POST codes are
displayed before DRAM training.
Change-Id: I390e0ab09ca830637e7a991db77e994d6c358e75
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72386
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Alder Lake PEIM graphics driver executed as part of the FSP does
not wait for the panel power cycle to complete before it initializes
communication with the display. It can result in AUX channel
communication time out and PEIM graphics driver failing to bring up
graphics.
If we have performed some graphics operation in romstage, it is
possible that a panel power cycle is still in progress. To prevent any
issue with the PEIM graphics driver it is preferable to ensure that
panel power cycle is complete.
This patch replaces commit ba2cef5b54
("soc/intel/common/block/early_graphics: Introduce a 200 ms delay")
workaround patch.
BUG=b:264526798
BRANCH=firmware-brya-14505.B
TEST=Developer screen is visible in the recovery flow
Change-Id: Iadd6c9552b184f7d6ec8df9d0d392634864ba50b
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72419
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
We were using the libgfxinit `Initialize' function with the
`Clean_State' parameter because the more appropriate `Update_Output'
function was not performing all the necessary clean up operations for
the PEIM driver to be successful when libgfxinit was used in romstage.
Thanks to a lot of experiments and some log analysis efforts, we were
able to identify the missing operation and fix the `Update_Output'
function (cf. https://review.coreboot.org/c/libgfxinit/+/72123).
The `initialized' global variable is now unnecessary as we track the
initialization in the Ada code instead.
Since the `Update_Output' function does not return any value, this
patch modifies the `gma_gfxstop' prototype accordingly. This does not
have any impact as the return value was not used anyway.
BUG=b:264526798
BRANCH=firmware-brya-14505.B
TEST=Developer screen is visible
Change-Id: I53d6fadf65dc09bd984de96edb4c1f15b64aeed0
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72125
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch restricts the dump of the vebose graphics output settings
to configuration with the `DEBUG_ADA_CODE' flag set.
BUG=b:264526798
BRANCH=firmware-brya-14505.B
TEST=Configuration dump is seen only if DEBUG_ADA_CODE is set
Change-Id: Iadd6c9552b184f7d6ec8df9d0d392634864ba50c
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72418
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
CLKREQ Pins are intentionally not configured, because there seems to be
a current Issue with FSP, that causes pci devices to not work if CLKREQ
Pins are configured by coreboot. The msi/ms7d25 mainboard seems to have
a similar issue and the cause is also documented in it's gpio.c file.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Iba35076af194de0e85de60ebc93d62fda24e9c24
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Add the remaining DDR2 code to program the registers for memory
timings, ODT, RCOMP, and refresh mode; and perform receive-enable
calibration.
TEST: DDR2 systems boot
- Tested on a Dell Latitude E6400
- Tested on a Compal JHL90
TEST: Ensure DDR3 systems still boot
- Tested on a Thinkpad X200
Change-Id: I6d9a1853fea9e29171d7c2f9ffe7086685c9efad
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34834
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move DDR3 memory I/O init to its own function and add DDR2 memory I/O
init. Read I/O init is common to both DDR2 and DDR3.
TEST: DDR2 systems boot (with the rest of the patch train)
- Tested on a Dell Latitude E6400
- Tested on a Compal JHL90
TEST: Ensure DDR3 systems still boot
- Tested on a Thinkpad X200
Change-Id: Ic4d5130f527249d3a5b98bae778cdf21a1753b04
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34833
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Split JEDEC init into common and DDR3 specific parts and add the DDR2
specific init code. This also replaces raw `mchbar_clrsetbits32` calls
with a dedicated `jedec_command` function.
TEST: DDR2 systems boot (with the rest of the patch train)
- Tested on a Dell Latitude E6400
- Tested on a Compal JHL90
TEST: Ensure DDR3 systems still boot
- Tested on a Thinkpad X200
Change-Id: I7a57549887c0323e5babbf18f691183412a99ba9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34827
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add initial support for DDR2. This also changes GM45 raminit to
internally work in units of 1/256 ns for both DDR2 and DDR3 instead of
the 1/8 ns MTB assumed for DDR3, which simplifies the handling of time
values. DDR3 time values are thus scaled by a factor of 32 accordingly.
TODO:
- DDR2 JEDEC init
- Memory IO init
- Register programming
TEST: DDR2 systems boot (with the rest of the patch train)
- Tested on a Dell Latitude E6400
- Tested on a Compal JHL90
TEST: Ensure DDR3 systems still boot
- Tested on a Thinkpad X200
Change-Id: I265938d58c30264fd5d4f7b89da7b689058b8cf8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34826
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the `hyper_threading` CMOS option from most boards, as it's most
likely not working properly and causing problems. The main reasons to
remove the option are:
* The used enum is backwards (0 ---> Enable, 1 ---> Disable)
* Platform/SoC code does not honor the `hyper_threading` option
Also, remove the now-unused enum used by the `hyper_threading` option.
Change-Id: Ia8980a951f4751bc2e1a5d0e88835f578259b256
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69523
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Getting an error from the Kernel on Rex devices:
> ACPI Error: AE_NOT_FOUND, While resolving a named reference
> package element - \_SB_.PCI0.FSPI (20210730/dspkginit-438)
FSPI is defined in src/soc/intel/meteorlake/chipset.cb:
device pci 1f.5 alias fast_spi on end
This CL adds the corresponding FSPI device to the DSDT to prevent
the error mentioned above.
See commit feed8e4bd9 ("soc/intel/adl/acpi: add FSPI to DSDT") for
the corresponding ADL CL.
TEST=Built and tested on brya by verifying the error is gone.
Signed-off-by: Eran Mitrani <mitrani@google.com>
Change-Id: Id8d2a1b5e074f036345e028b117d420bf36a9042
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Current size of the cbmem premem buffer (8KB) is sometimes insufficient
to contain the complete debug log causing the cbmem console buffer to
indicate overflow.
This patch increases the premem cbmem buffer size to 16KB so that
the complete debug log can be stored in it.
TEST=Make sure that logs from all the boot stages can be seen using
'cbmem -c'.
Change-Id: I60c68322c52191eabf7e06b4be06e66f90ff8751
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71290
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Before, the Intel HDA PCIe device was showing up in the lspci tool, but
Audio wasn't working.
This patch enables the corresponding FSP-M settings to make it work.
Tested on Prodrive Atlas with Themis carrier board on Windows 10 and
Linux 6.1.0-rc3.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I144618c453c1e6a3e759afc7532a4ac4a71814c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently ASPM cannot be disabled by individual mainboards, if the
soc Kconfig includes SOC_INTEL_COMMON_PCH_CLIENT. Other options like
PCIEXP_CLK_PM and PCIEXP_L1_SUB_STATE are already configurable by
individual mainboards if needed. This change makes PCIEXP_ASPM one of
these configurable options.
Test: build prodrive/atlas and see that build/config.h lists the
option CONFIG_PCIEXP_ASPM as disabled.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ic9c049f1d225bc21d8da5bd208651ad847ae0c6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72117
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The mp2 PCI device is still present when no mp2 firmware is loaded. When
this device isn't explicitly enabled in the mainboard's devicetree, the
chipset devicetree default of the device being disabled is used. This
results in coreboot's resource allocator not allocating resources to the
device and since the bridge doesn't have enough MMIO space reserved, the
Linux kernel can't assign resources to it. To fix this problem, enable
the mp2 device in the mainboard's devicetree so that it gets its
resources assigned by coreboot. An equivalent change was verified on
Chausie.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1076ccacc6f51bf195b8280a6df5ad1849771519
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72196
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The mp2 PCI device is still present when no mp2 firmware is loaded. When
this device isn't explicitly enabled in the mainboard's devicetree, the
chipset devicetree default of the device being disabled is used. This
results in coreboot's resource allocator not allocating resources to the
device and since the bridge doesn't have enough MMIO space reserved, the
Linux kernel can't assign resources to it. To fix this problem, enable
the mp2 device in the mainboard's devicetree so that it gets its
resources assigned by coreboot.
TEST=Fixes the resource allocation for the mp2 PCI device.
dmesg output before the patch:
[ 0.210616] pci 0000:04:00.7: [1022:164a] type 00 class 0x118000
[ 0.210631] pci 0000:04:00.7: reg 0x18: [mem 0x00000000-0x000fffff]
[ 0.210641] pci 0000:04:00.7: reg 0x24: [mem 0x00000000-0x00001fff]
[ 0.210649] pci 0000:04:00.7: enabling Extended Tags
[ 0.240570] pci 0000:04:00.7: BAR 2: no space for [mem size 0x00100000]
[ 0.240572] pci 0000:04:00.7: BAR 2: failed to assign [mem size 0x00100000]
[ 0.240574] pci 0000:04:00.7: BAR 5: assigned [mem 0xd05c6000-0xd05c7fff]
dmesg output after the patch:
[ 0.210483] pci 0000:04:00.7: [1022:164a] type 00 class 0x118000
[ 0.210501] pci 0000:04:00.7: reg 0x18: [mem 0xd0500000-0xd05fffff]
[ 0.210515] pci 0000:04:00.7: reg 0x24: [mem 0xd06c6000-0xd06c7fff]
[ 0.210524] pci 0000:04:00.7: enabling Extended Tags
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I680ef9798f2f0e7e0646f0fd30bef58398b7bf19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72197
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently most of the FSP debug messages (when enabled) are truncated due to insufficient size of cbmem buffer.
Increase premem cbmem console size to 0x16000 bytes and cbmem buffer size to 0x100000 bytes so that cbmem buffer can contain most of the debug logs when FSP debug messages are enabled.
TEST=Verify output of 'cbmem -c' when FSP debug messages are enabled but MRC debug message.
Change-Id: I0273fb14916f213b686270a9dec4c1b47612af4d
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71289
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Current size of the cbmem buffer (128KB) is insufficient to contain the
complete debug log causing the cbmem console buffer to wrap.
This patch increases cbmem buffer size to 256KB so that the complete
debug log can be stored in it.
TEST=Make sure that logs from all the boot stages can be seen using
'cbmem -c'.
Change-Id: I2099386dd87a010c3a5937bd896620270f587b1c
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71288
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
EBG (Emmitsburg) PCH is used in Intel SPR-SP chipset.
Its datasheet is Intel doc# 606161.
Add Intel Emmitsburg PCH GPIO pin definitions.
Also common code change is made to support Intel Emmitsburg PCH:
a. Instead of 2 PAD registers per GPIO, it has 4 PAD registers.
b. The register address space may not be contiguous from one GPIO
group to the next GPIO group.
Change-Id: Ia0d9179544020b6abb0be1ecd275a9a46356db8a
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This patch implements a new API to make the UFS controller function
disabled. Additionally, perform a warm reset post disabling the UFS
controller to let PMC know about the state of the UFS controller
and disable the MPHY clock.
BUG=b:264838335
TEST=Able to build and boot Google/Marasov successfully.
From the AP log, I am able to confirm that UFS is function disabled
using PSF.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I940a634f70f8c97ef1234866d4c5a1ff224c6e24
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch makes it easy for OEMs to keep a unified AP firmware image
to boot different SKUs with UFS and non-UFS as boot media.
With a unified image while booting on non-UFS SKU is exhibiting S0ix
failure due to UFS remain enabled in the strap although FSP-S is
making the UFS controller function disabled.
The potential root cause of this behaviour is although the UFS
controller is function disabled but MPHY clock is still in active
state.
A possible solution to this problem is to issue a warm reboot (if
boot path is S5->S0 or G3->S0) after disabling the UFS and let PMC
read the function disable state of the UFS for disabling the MPHY
clock.
Mainboard users with such board design where OEM would like to use
an unified AP firmware to support both UFS and non-UFS sku booting
might need to choose this config to allow disabling UFS while booting
on the non-UFS SKU.
Note: selection of this config would introduce an additional warm
reset in cold-reset scenarios due to function disabling of the UFS
controller.
BUG=b:264838335
TEST=Able to build and boot Google/Marasov successfully.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0a811d8f4aad41dab6f8988329eaa1d590a4637a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch calls into `pmc_clear_pmcon_pwr_failure_sts()` to clear
GEN_PMCON_x register status bits after determining the
`prev_sleep_state`.
Having those bits being set across reboot might be misleading.
For example: although the last boot was not due to power failure but
the power failure bit still remains the same (unless cleared).
Note: clearing `GBL_RST_STS` bit earlier than FSP-M/MRC having an
adverse effect on the PMC sleep type register which results in
calculating wrong `prev_sleep_state` post a global reset, hence,
just clearing the power failure status bits rather than clearing
the complete PMC PMCON_A register.
BUG=b:265939425
TEST=Able to clear the GEN_PMCON_A register power failure bits aka
BIT16 and BIT14 on google/marasov platform over next boot to avoid
having its persistent effect.
Without this patch:
pm1_sts: 0100 pm1_en: 0000 pm1_cnt: 00001c00
...
GEN_PMCON: d0215238 00002200
With this patch:
pm1_sts: 0100 pm1_en: 0000 pm1_cnt: 00001c00
...
GEN_PMCON: d1001038 00002200
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4f5dfe0251aeb85b667fbfc44fbf17b025aec090
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch overrides `SaGv` FSP-M UPD to enable SaGv feature to be
able to train memory (DIMM) at different frequencies.
On all latest Intel based platforms SaGv is expected to be enabled
to support dynamic switching of memory operating frequency.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I7cf52b966c1355c1f2bd4ae7c256fa4252a90666
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72136
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
This patch converts below chip configs from camel case to snake
case to match with the other chip configs belongs to the chip
structure.
- SaGv
- RMT
Additionally, updated the `sagv` help text and operation as
applicable based on the FSPMUPD.h file (belongs to the vendorcode).
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I62e521cf3f46e888e2c995d83ac7dc666de1af82
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72135
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
This patch implements an API named `pmc_clear_pmcon_pwr_failure_sts()`
to clear power failure status bits of PMC General PM Configuration A/B
based on the underlying SoC.
Based on the available PMC register definitions between Sky Lake till
latest Meteor Lake platform, the SoC platform that selects
SOC_INTEL_MEM_MAPPED_PM_CONFIGURATION config has power failure bits
mapped into the MMIO mapped GEN_PMCON_A register where else for the
other SoCs, those power failure bits are belongs to the PCI config
space mapped GEN_PMCON_B register.
BUG=b:265939425
TEST=Able to build the google/marasov.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Icbbe47ccfd489edf9c38f52bdf7cf2de7aa9eedf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72053
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
If a CSE update is going to happen and early graphics is supported by
the mainboard, an on-screen text message is displayed to inform the
end user.
CSE update can take a while and an impatient end user facing a black
screen for a while may reset the device unnecessarily.
BUG=b:264648959
BRANCH=firmware-brya-14505.B
TEST=On screen text message during CSE update observed on skolas
Change-Id: I28c4fef9345d577be287b76a2a767b5c852ec742
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72098
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 78ee4889dc ("soc/amd/cezanne/acpi: Add support for RTC
workaround") added a workaround for the Cezanne silicon. This was copied
to the Mendocino code, but from both the discussion in b:209705576 and
the referenced amd_pmc_verify_czn_rtc function in drivers/platform/x86/
amd/pmc.c that is only called if pdev->cpu_id == AMD_CPU_ID_CZN is true
Mendocino doesn't need that workaround, so remove it.
TEST=Running suspend_stress_test -c 5 on Chausie shows no errors
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7d0b35ef8cf88ff0b9bed8820b8da32c2058cc1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72091
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes the build failure with 'make -j' where the build
fails at "$(MAKE)... savedefconfig" as that rule doesn't have the
dependency on kconfig/conf.
Normally make takes care of all dependencies, so parallel builds
work well. However if you have recursive make calls, i.e. make
calling make like in these recipes, there is no single make with a
global view of the dependencies anymore, and then multiple "makes"
can try to build the same file concurrently. Adding that explicit
dependency on build/util/kconfig/conf makes sure the recursive make
is only called later when the top-level make already finished
building build/util/kconfig/conf.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Id44ab44618b0ddfb3c2472c469499429118bf76d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72070
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes
alphabetic ordering of included headers.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I3138edd8125601b6c9dff5f9252a4bba8385146d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
MAINBOARD_BLOBS_DIR is defined the same way by
picasso/cezanne/mendocino/phoenix/glinda and unused by stoneyridge, so
move it to a common area.
This makefile variable is currently only used to locate APCB blobs for
the different mainboards.
Add a Kconfig option to point to the APCB blobs directory. This allows
simple overriding to locations such as site-local.
TEST=Timeless builds
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I0702fdb97fbc2c73d97994ab4d5161ff0f467518
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69410
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Because the EFS is now fixed at 0xff020000, the ChromeOS RO region needs
to be moved to the bottom of the ROM area to cover that space.
The RO Region 6MiB, but you can't actually set 6MiB as RO - it's either
4 or 8MiB, so that's adjusted. To leave some room for the RW_LEGACY
region, the two RW regions are adjusted to 3MiB each, which should be
plenty.
The GBB region had to be moved from the front of the WP_RO region to the
end to avoid conflicting with the EFS, which needs to be inside the
coreboot cbfs area.
Also get rid of AMD_FWM_POSITION_INDEX. The FWM position is no longer
needed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I683155ec0f4e6a62d862b9e2fa76af45f4cd5493
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Update the mem_parts_used.txt, generate Makefile.inc and
dram_id.generated.txt for this part.
DRAM Part Name ID to assign
MT62F1G32D2DS-026 WT:B 4 (0100)
K3KL8L80CM-MGCT 4 (0100)
H58G56BK7BX068 4 (0100)
BUG=b:259467147
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot
Signed-off-by: Terry Chen <terry_chen@wistron.corp-partner.google.com>
Change-Id: I204e871129a1b15d7c373d579e10a7b9ab6deabe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71906
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Needs to be selected for ChromeOS mainboards even for non-ChromeOS
builds, else Thunderbolt/USB4 doesn't work under Windows (and likely
Linux as well).
TEST=build/boot Windows on drobit/banshee, verify TB functional
Change-Id: Iee3f99840f0c6cc384d9fdef6dff55bcbfc0380f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72140
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds new macros (i.e. SUS Power Failure and Power Failure)
from the APL EDS vol 1 (doc 569262) to be able to implement common
code API to clear the power failure status bits.
Note: as per the EDS those newly added power management failure bits
are RO and shouldn't change any functionality of the existing APL SoC
code. The reason behind adding those macro definitions is to fix the
compilation issue due to code change targeted for the Intel SKL and
Xeon-SP.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0bbf11ada2b2f8735173be69ad157b8055021126
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72130
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds new macros (i.e. SUS Power Failure and Power Failure)
from the DNV EDS vol (doc 558579) to be able to implement common
code API to clear the power failure status bits.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6ed962eae79154a8faea382dbe8367133cb05eda
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72134
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Enable early POST code display on this variant using
the common mc_apl1 baseboard functionality.
BUG=none
TEST=Boot on mc_apl6 and observe that POST codes are
displayed before DRAM training.
Change-Id: I2a52c241c383f8ebcf05052e9bc0ba13e63e3728
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72116
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Move logic previously used only in the mc_apl2 variant to
the mainboard level so that other variants can also make
use of it without code duplication.
This functionality on the mc_apl6 variant will be enabled
in a follow-up patch.
BUG=none
TEST=Boot on siemens/mc_apl2 and observe that the POST
codes are displayed before DRAM training.
Change-Id: I762e328ad06c047d911ce1fc40f12a66cbd14e11
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
From Cezanne on, the TMPS, TCRT and TPSV fields are unused in both the C
and ACPI code, so they can be removed. Also remove the unused fields
that were previously used for PCNT and PWRS. The LIDS field is only used
in the ACPI code, but keep if for now, since it would require a bigger
rework to remove it from the global NVS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie1c3c25591deadb27b7bf38a81dcd6fe746de55b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72096
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Cezanne on, the TMPS, TCRT and TPSV fields are unused in both the C
and ACPI code, so they can be removed. Also remove the unused fields
that were previously used for PCNT and PWRS. The LIDS field is only used
in the ACPI code, but keep if for now, since it would require a bigger
rework to remove it from the global NVS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5a9b0a24f57a81b98c7553517fe5f25ff63c5316
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72095
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Cezanne on, the TMPS, TCRT and TPSV fields are unused in both the C
and ACPI code, so they can be removed. Also remove the unused fields
that were previously used for PCNT and PWRS. The LIDS field is only used
in the ACPI code, but keep if for now, since it would require a bigger
rework to remove it from the global NVS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I884d6a7dedb73028f8942fdda86b0c9910fa996a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72094
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Cezanne on, the TMPS, TCRT and TPSV fields are unused in both the C
and ACPI code, so they can be removed. Also remove the unused fields
that were previously used for PCNT and PWRS. The LIDS field is only used
in the ACPI code, but keep if for now, since it would require a bigger
rework to remove it from the global NVS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib4034e959d167fb1e08ee5b15e21fb93bc89db8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72093
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All field definitions in the IndexField object match both the info in
the PPR #57243 revision 3.02 and also match the defines in soc/amd/
mendocino/include/soc/amd_pci_int_defs.h. The IndexFieldvonly defines
the subset of the IRQ mapping registers that are used or likely needed
in the future. This is handled in the same way for the other AMD SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6b0adfecc99945de69b4853f4423b4c10951d3e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72092
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the addition of the mc_ehl3 board variant, a few
points about commenting the code arose either from the
review or during the implementation itself.
This patch unifies structure of these files, which
have a similar structure across more Siemens boards
utilizing the PTN3460 eDP-to-LVDS bridge.
BUG=none
TEST=Check that images for the affected boards can be
built.
Change-Id: I59820362e1f87e296c5548b9c3cecba4d2710fe7
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72068
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This board contains in addition to its base variant, mc_ehl2,
an LCD panel driven through the PTN3460 eDP-to-LVDS bridge.
This patch enables the PTN3460 support by adding the device to
devicetree.cb and board-specific configuration parameters in
lcd_panel.c, based upon a similar implementation in siemens/mc_apl7.
BUG=none
TEST=Boot with the LCD panel attached and observe whether
the picture is stable and free of artifacts coming from wrong
resolution, timing etc.
Change-Id: Ib8a1a6f47053406e42554c2dd33684165d54be08
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70692
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The {read,write}{16,32}() functions used in this file come from the
mmio.h header, so include it directly.
BUG=none
TEST=Read out the SD card controller (device 1a.1) PCI registers
in Linux and check whether the values reflect the ones defined
in this file.
Change-Id: Iff7b55ef2bf98371b7d7d9114ccf3ebed64772a2
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72009
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Use acpi_align_current to align the ACPI tables on a 16 byte boundary.
This changes the alignment of the HEST, IVRS, SRAT and SLIT tables from
8 bytes to 16 bytes. The alignment of the ALIB and PSTATE SSDT tables
was already 16 bytes before, so the alignment of those isn't changed.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8933e3731b67012bcae0773db2f7f8de7cd31b56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72055
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce at new config option CONFIG_FSP_PUBLISH_MBP_HOB to
control the creation of ME_BIOS_PAYLOAD_HOB (MBP HOB) by FSP.
This new option is hooked with `SkipMbpHob` UPD and is always
disabled for ChromeOS platforms.
This made skip_mbp_hob SOC chip config variable redundant
which is also removed as part of this change.
BUG=none
TEST=Build and boot to Google/Rex.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Iaba1ea29a92a63d2b287e1ccdea1a81ec07b9971
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71997
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Currently most of the FSP debug messages (when enabled) are truncated
due to insufficient size of cbmem buffer.
Increase premem cbmem console size to 0x16000 bytes and cbmem buffer
size to 0x100000 bytes so that cbmem buffer can contain most of the
debug logs when FSP debug messages are enabled.
BUG=b:265683565
TEST=Verify output of 'cbmem -c' when FSP debug messages are enabled
but MRC debug message.
Note: Still 350/2200 lines of premem messages are missing.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I120423e1dd2bc468cf9cec6da1246ac3c0a155e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72048
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Current size of the cbmem buffer (128KB) is insufficient to contain the
complete debug logs which is more than 166KB hence, cbmem console buffer has wound off to contain the maximum possible debug messages within the allocated buffer as results, we are seeing truncated debug message while looking into the cbmem console.
This patch increases cbmem buffer size to 256KB so that the complete
debug log can be stored in it.
BUG=b:265683565
TEST=Make sure that logs from all the boot stages can be seen using
'cbmem -c'.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Ibeabb61d60491b831252b7161c9d3181fbe09e73
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72047
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Ice Lake is unmaintained and the only user of this platform ever
was the Intel CRB (Customer Reference Board). As it looks like, it was
never ready for production as only engineering sample CPUIDs are
supported.
As announced in the 4.19 release notes, remove support for Intel
Icelake code and move any maintenance on the 4.19 branch.
This affects the following components and their related code:
* Intel Ice Lake SoC
* Intel Ice Lake CRB mainboard
* Documentation
Change-Id: Ia796d4dc217bbcc3bbd9522809ccff5a46938094
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72008
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The parameter 'maxlen' can be a bit confusing as it actually is
referring to the size of the destination memory block where the
requested parameter is stored to. Rename it to 'dstsize' and change
the type to size_t to be more clear here.
In addition, add a comment line for this parameter in the description
of the function 'hwilib_get_field()'.
This patch has no impact to the generated binary (checked with timeless
build).
Change-Id: I572dc0f3ff3d0c177d608332a88991396b82c2fd
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72045
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Skyrim doesn't use the firmware TPM, so remove the binary from the
image.
Note that because this was not used, removing it doesn't change the boot
time.
BUG=None
TEST=Boot
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia627b128c3346a2556c5306de7506519d1f2d70c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The Picasso SoC code generates a CRAT ACPI table which is not done for
Cezanne and newer. A significant part of the Picasso CRAT generation
code can likely be moved to the common AMD SoC code and then used in all
SoCs, but this still needs to be checked.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8f1ebe74f0376c60396dbd80e64676d1374ed811
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72027
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This changes the alignment of the CRAT and IVRS tables from 8 bytes to
16 bytes.
TEST=Mandolin still boots Linux and the position and size of the ACPI
tables in memory shown by dmesg hasn't changed.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I88df331c8410d8dca41a414543f051f5e4656ff1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The patch fixes indication of incorrect `prev_sleep_state` on the next
boot after global reset trigger. The existing code misses an important check about `if PCH doesn't set the WAK_STS` while checking power
failure. As a result, every early warm/global reset is considered
as power failure after looking into the PMC MMIO CON-A register
alone (as ignoring the ACPI PM_CTRL.WAK_STS bit).
As per the code comment this code logic is expected to check the power
failure reason if PCH doesn't set the WAK_STS while waking from G3
state.
Without this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 5` although the SLP_TYP is zero and WAK_STS bit
is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 5
With this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 0`. It matches with the SLP_TYP is zero and
WAK_STS bit is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib43d3402f94f47dc576fb99a6b2a7acf6f0af220
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71982
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch fixes indication of incorrect `prev_sleep_state` on the next
boot after global reset trigger. The existing code misses an important check about `if PCH doesn't set the WAK_STS` while checking power
failure. As a result, every early warm/global reset is considered
as power failure after looking into the PMC MMIO CON-A register
alone (as ignoring the ACPI PM_CTRL.WAK_STS bit).
As per the code comment this code logic is expected to check the power
failure reason if PCH doesn't set the WAK_STS while waking from G3
state.
TEST=Able to build and boot google/dragonegg.
Without this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 5` although the SLP_TYP is zero and WAK_STS bit
is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 5
With this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 0`. It matches with the SLP_TYP is zero and
WAK_STS bit is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0e5a6e54abc7c03a2fbffa308db20c392e2a600b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71983
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch fixes indication of incorrect `prev_sleep_state` on the next
boot after global reset trigger. The existing code misses an important check about `if PCH doesn't set the WAK_STS` while checking power
failure. As a result, every early warm/global reset is considered
as power failure after looking into the PMC MMIO CON-A register
alone (as ignoring the ACPI PM_CTRL.WAK_STS bit).
As per the code comment this code logic is expected to check the power
failure reason if PCH doesn't set the WAK_STS while waking from G3
state.
TEST=Able to build and boot google/dedede.
Without this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 5` although the SLP_TYP is zero and WAK_STS bit
is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 5
With this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 0`. It matches with the SLP_TYP is zero and
WAK_STS bit is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Id2c1f24a8fa54eea512b5bd3dd91423f9892687d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71984
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The patch fixes indication of incorrect `prev_sleep_state` on the next
boot after global reset trigger. The existing code misses an important check about `if PCH doesn't set the WAK_STS` while checking power
failure. As a result, every early warm/global reset is considered
as power failure after looking into the PMC MMIO CON-A register
alone (as ignoring the ACPI PM_CTRL.WAK_STS bit).
As per the code comment this code logic is expected to check the power
failure reason if PCH doesn't set the WAK_STS while waking from G3
state.
TEST=Able to build and boot google/volteer.
Without this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 5` although the SLP_TYP is zero and WAK_STS bit
is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 5
With this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 0`. It matches with the SLP_TYP is zero and
WAK_STS bit is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0e48b110826f16d13d18c138fce03a56c85b9d1c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71985
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The patch fixes indication of incorrect `prev_sleep_state` on the next
boot after global reset trigger. The existing code misses an important check about `if PCH doesn't set the WAK_STS` while checking power
failure. As a result, every early warm/global reset is considered
as power failure after looking into the PMC MMIO CON-A register
alone (as ignoring the ACPI PM_CTRL.WAK_STS bit).
As per the code comment this code logic is expected to check the power
failure reason if PCH doesn't set the WAK_STS while waking from G3
state.
TEST=Able to build and boot google/taeko.
Without this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 5` although the SLP_TYP is zero and WAK_STS bit
is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 5
With this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 0`. It matches with the SLP_TYP is zero and
WAK_STS bit is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I52f9c261f4eea34e6d2300c8de97ee018d886189
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71987
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch fixes indication of incorrect `prev_sleep_state` on the next
boot after global reset trigger. The existing code misses an important check about `if PCH doesn't set the WAK_STS` while checking power
failure. As a result, every early warm/global reset is considered
as power failure after looking into the PMC MMIO CON-A register
alone (as ignoring the ACPI PM_CTRL.WAK_STS bit).
As per the code comment this code logic is expected to check the power
failure reason if PCH doesn't set the WAK_STS while waking from G3
state.
TEST=Able to build and boot google/rex.
Without this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 5` although the SLP_TYP is zero and WAK_STS bit
is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 5
With this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 0`. It matches with the SLP_TYP is zero and
WAK_STS bit is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Idc40045445cccc5b34fb49901d9ef548f2f0560b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71986
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch fixes indication of incorrect `prev_sleep_state` on the next
boot after global reset trigger. The existing code misses an important check about `if PCH doesn't set the WAK_STS` while checking power
failure. As a result, every early warm/global reset is considered
as power failure after looking into the PMC MMIO CON-A register
alone (as ignoring the ACPI PM_CTRL.WAK_STS bit).
As per the code comment this code logic is expected to check the power
failure reason if PCH doesn't set the WAK_STS while waking from G3
state.
TEST=Able to build and boot google/hatch.
Without this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 5` although the SLP_TYP is zero and WAK_STS bit
is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 5
With this patch:
Observation: Resuming after a warm reset is considered as
`prev_sleep_state 0`. It matches with the SLP_TYP is zero and
WAK_STS bit is set.
pm1_sts: 8100 pm1_en: 0000 pm1_cnt: 00000000
GEN_PMCON: d1215238 00002200
....
prev_sleep_state 0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I05a2fab75c3d931651885db0003ab8c5748a1568
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71934
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I73bac9560d0ff315d6fe6f4efc3ee9011f77c660
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72036
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Iccf37a340880e4b5a18f51c3add9a15a74e1d7b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72030
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes
alphabetic ordering of included headers.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I55fa5941a9255f60c2aa23b90d16cf342d6f458f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72032
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes
alphabetic ordering of included headers.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: If069e66f2762eb373d35d635c09226ac5be99c7d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72039
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes
alphabetic ordering of included headers.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I02fe236506abbc0d97982747cfcf3c0e9ef4897a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72040
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes
alphabetic ordering of included headers.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I8135dc918cb04c854dc003966b7657806a42bad9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72042
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes
alphabetic ordering of included headers.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I12497d46e58aae41ec8dcb5d567267579dc12fc6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72041
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes
with the common gpio.h which includes soc/gpio.h which includes
intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes
alphabetic ordering of included headers.
BUG=b:261778357
TEST=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I349a2b24ecdee347548b5c7b292c5075e6150a19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72033
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch refactors the mainboard_romstage_entry() function to avoid
redundant chipset programming caused by global reset due to CSE FW
sync operation. Hence, keeping only the minimal and mandatory
operations required to perform CSE FW sync successfully.
This would help to optimize the boot flow by removing redundant
programming like SA, SMBUS twice in every CSE FW update path.
TEST=Able to build and boot Google/Rex successfully.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I1a13fac1e99341991d8dd818d4ab8a20d209a94c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71933
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the mainboard_romstage_entry() function to avoid
redundant chipset programming caused by global reset due to CSE FW
sync operation. Hence, keeping only the minimal and mandatory
operations required to perform CSE FW sync successfully.
This would help to optimize the boot flow by removing redundant
programming like SA, SMBUS twice in every CSE FW update path.
TEST=Able to build and boot Google/Marasov successfully.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iba9767ef51d7fc7ecf9de14454105865433ba041
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71932
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The AMD SoCs no longer have a variable position for EFS - it's now fixed
at 0xff020000 - 128KiB into the 16MiB ROM decode region.
It's a little more complex than that because the chip can be larger than
16MiB, and the entire ROM can be decoded if mapped above the 4GiB
boundary, but we don't currently support doing that in coreboot, so this
is enough for now.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I343a875ba9aa8294a090f2eff7b5dfb5e86334f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71769
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Old wiki is outdated for years but Kconfig help messages
of some payloads still reference it.
This commit changes those links to the corresponding page at
doc.coreboot.org.
Change-Id: I81653f1b010d8a3ac4dfc4c6ad4fa714ce5d59a1
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This change skips the MBP HOB creation since coreboot doesn't
use it and also helps to reduce the boot time by ~10msec.
Boot time data:
Before:
* 955:returning from FspSiliconInit 897,278 (33,603)
After:
* 955:returning from FspSiliconInit 864,543 (21,273)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia97cca560869fcfd55e65c2e1719cceec6f3ab7c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71873
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These are the final 4.19 release notes before tagging the release.
Final updates to statistics and removal of comments saying "planned" and
"Upcoming" will be removed after the release is tagged.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie20ad22732ce2e1d92e47b8e48268c6a5a34ca5b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71942
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that multiple platforms are trying to initialize eMMC in coreboot
instead of depthcharge, lets move common functionality into commonlib
instead of copying the same functionality between multiple platforms.
Note for consistency, changed name of set_early_mmc_wake_status() to
mmc_set_early_wake_status(). Also adding an mmc_send_cmd1() function
for retrieving the Operating Conditions Register (OCR) contents.
BUG=b:218406702
BRANCH=None
TEST=emerge-herobrine coreboot chromeos-bootimage
flash onto villager device and make sure still boots ChromeOS
Change-Id: Id00535b05bbd379081712601ef10e762c1831747
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
MSR_PPIN_CTL may need to be read more than once, so lock PPIN CTL
MSR at a late BS_PAYLOAD_LOAD boot state.
This MSR is in platform scope and must only be locked once on each
socket. Add a spinlock to do so.
Tested=On OCP Craterlake single socket, rdmsr -a 0x04e shows 1.
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: I8deb086339267cf36e41e16f189e1378f20b82f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71144
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Select HSP config to indicate that the SoC includes Hardware Security
Processor. This will allow PSP verstage to get and report the HSP state.
BUG=None
TEST=Build Skyrim BIOS image and boot to ChromeOS on Skyrim. Verify
that HSP is reported during the boot sequence.
Change-Id: I22446c2bd6202529367da040c09449e6b26f9d7a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Get Hardware Security Processor(HSP) state in PSP Verstage through the
SVC call and report it in cbmem logs.
BUG=b:198711349
TEST=Build Skyrim BIOS image and boot to OS in Skyrim.
Change-Id: Ic4875d1732f22783a90434329188192b106168f4
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Add an SVC call to get the state of Hardware Security Processor (HSP) in
AMD SoCs. This SVC call will be used from PSP verstage to get and
report HSP state.
BUG=b:198711349
TEST=Build Skyrim BIOS image and boot to OS. Ensure that the HSP state
is read and reported in the firmware logs.
Change-Id: I7fe3363d308a80cc09e6bdadd8d0bb1d67f7d2bf
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71207
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update settings for touchpad I2C frequency and data hold time.
I2C frequency and data hold time need to meet touchpad spec.
- I2C frequency: 380kHz - 400kHz
- Data hold time: 0.3us - 0.9us
BUG=b:262320419
TEST=On winterhold, touchpad i2c measurement from vendor,
Frequencies: 395 kHz, Data hold time: 0.66 us
Change-Id: I40fa6f9e88656d4ec02a4120f75a2a9413b5abaa
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO.
There's no reason to require explicit disablement however, so drop the
superfluous 'disable' flag, and change the _CRS generation to check if
the GPIOs will be exported via the 'has_power_resource' flag instead.
This mirrors the change made for drivers/i2c/generic.
TEST=untested, as no boards selected this option.
Change-Id: Icb60502a4a7c5e7a1fcf1ee60e23c77e00d6de7b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71851
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO.
There's no reason to require explicit disablement however, so drop the
superfluous 'disable' flag, and change the _CRS generation to check if
the GPIOs will be exported via the 'has_power_resource' flag instead.
This mirrors the change made for drivers/i2c/generic.
TEST=untested, as no boards selected this option.
Change-Id: I4f95d0e453d89b7e1978d3efac304518304495d1
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71850
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO.
Previously, we flagged as an error any device which set the
'has_power_resource' flag but did not set 'disable_gpio_export_in_crs.'
There's no reason to require explicit disablement however, so drop the
superfluous 'disable' flag, and change the _CRS generation to check if
the GPIOs will be exported via the 'has_power_resource' flag instead.
BUG=b:265055477
TEST=build/boot skyrim, dump SSDT and verify touchscreen GPIOs only
listed under PRx, not under _CRS.
Change-Id: I837ae6c6fe4b8e1c4e10686406cba06bdb7759d2
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
There was a typo in the config disabling bootblock
should have been:
# CONFIG_VBOOT_STARTS_BEFORE_BOOTBLOCK is not set
As the line moved, it is the missing underscore after CONFIG,
preventing it from working as intended.
The other changes are updates to allow it to match what we get by
copying it to .config, then running:
make olddefconfig; make savedefconfig
Change-Id: Ic41a91e0a6ecd254a86d0872da19a0d4d321b8e3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71840
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When pulling in commonlib/storage/pci_sdhci.c into herobrine, am
seeing an "error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]", so fixing that.
BUG=b:254092907
BRANCH=None
TEST=emerge-herobrine coreboot
Make sure that we can build without errors
Change-Id: Ib1718f156708a619f7eeb181e19b1a8c620de1f8
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71828
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
0xF8000000 was taken from old platform during phoenix porting, updating
it to 0xE0000000 to make room for 256 pci busses which is required for
usb4 and hotplug support. mmconf size gets set to 0x10000000 when 256
busses are used.
Change-Id: Ic143171f5650aff5db48c8f477d7aca3e7f5c1e7
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71870
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The smu_sx_entry function is identical for all AMD SoCs, so introduce it
as common code that can be selected to be included in the build via the
SOC_AMD_COMMON_BLOCK_SMU_SX_ENTRY Kconfig option. The only SoC-specific
difference in this function is the ID of the SMC_MSG_S3ENTRY message
which is defined in each SoC's soc/smu.h include file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I49758e9333a351d8e50e8f1b53a7f00fbe89866c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71875
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
If a discoverable device (e.g. a PCI device) does not appear in the
devicetree (typically because it is removable), coreboot enables it
by default. Disable the SATA2 (device for SATA ports 4 and 5, which
is not used in AHCI mode) and Thermal devices on W520 as well. Both
devices were only disabled on the T520.
Tested, this change fixes a long boot time when using MrChromebox's
edk2 payload on the W520, likely related to the following errors:
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 0
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 1
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 2
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 3
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 4
Change-Id: I0b0483aae05fa84d97987a93db634b740f830e18
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71857
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested with the following drives:
- Crucial P5 Plus (CT500P5PSSD8)
- Kingston KC3000 (SKC3000S/512G)
- Sabrent Rocket NVMe 4.0 (SB-ROCKET-NVMEe4-500)
- Samsung 970 EVO (MZ-V7E250)
- Samsung 970 EVO Plus (MZ-V7S250)
- Samsung 980 PRO (MZ-V8P2T0)
- WD Black SN850X (WDS100T2XD0E)
- WD Blue SN580 (WDS500G2B0C)
- WD Green SN350 (WDS240G2G0C)
Test:
- Drive is functional and has no unrecoverable errors on boot
- Drive is functional and has no unrecoverable errors after S0ix
Change-Id: I51492c97c48f760d4aa9e4a2b2e57b0f1a06d090
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Tested with the following drives:
- Crucial P5 Plus (CT500P5PSSD8)
- Kingston KC3000 (SKC3000S/512G)
- Sabrent Rocket NVMe 4.0 (SB-ROCKET-NVMEe4-500)
- Samsung 970 EVO (MZ-V7E250)
- Samsung 970 EVO Plus (MZ-V7S250)
- Samsung 980 PRO (MZ-V8P2T0)
- WD Black SN850X (WDS100T2XD0E)
- WD Blue SN580 (WDS500G2B0C)
- WD Green SN350 (WDS240G2G0C)
Test:
- System still asserts `SLP_S0#` during suspend (power LED blinks)
- `slp_s0_residency_usec` still increases after suspend
Change-Id: I919d75cb2a88c0d623c46e44c506ec2d85567995
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
The DDR5 board is almost identical to the DDR4 one. The only major
difference is the board's DDR5 memory design.
TEST=Boot MSI PRO Z690-A board successfully to Ubuntu 22.04. Memory:
Crucial CT8G48C40U5.M4A1 in all 4 slots.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I652a879d1616df4708fe4690797ad98384897f53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Use 'enum cb_err' values for below cse lite functions instead of true or
false.
Functions whose return values updated in this patch:
1. cse_set_next_boot_partition()
2. cse_data_clear_request()
3. cse_set_and_boot_from_next_bp()
4. cse_boot_to_rw()
5. cse_fix_data_failure_err()
TEST= Do boot test on Gimble.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I7fec530aeb617bab87304aae85ed248e51a6966b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Fix:
cc1: error: 3rdparty/blobs/mainboard/asrock/h110m: No such file or directory [-Werror=missing-include-dirs]
cc1: error: 3rdparty/blobs/mainboard/acer/aspire_vn7_572g: No such file or directory [-Werror=missing-include-dirs]
...
Change-Id: Icc43e40514a12944fa180197ffe3230ff9800de9
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71585
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Now that the next generation of APUs is officially announced, we can
unmask morgana.
The chip formerly known as Morgana is actually Phoenix.
Surprise!
This patch just changes the name across the entire codebase.
Note that the fw.cfg file will stay pointing to the
3rdparty/amd_blobs/morgana/psp directory until the amd_blobs_repo is
updated.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Ie9492a30ae9ff9cd7e15e0f2d239c32190ad4956
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71731
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It has been reported that the PEIM graphics driver may temporarily
fail communication with the display if the time between libgfxinit
turning off the displays and the PEIM driver initialization is too
short. 200 ms has been identified as a safe delay.
This is a temporary workaround and an investigation is in progress to
come up with a better and long term solution.
BUG=b:264526798
BRANCH=firmware-brya-14505.B
TEST=Developer screen is systematically seen
Change-Id: I4ea15123eed1a4355c5ff7d815925032d4151de1
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71656
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If memory training is going to happen and early graphics is supported
by the mainboard, an on-screen text message is displayed to inform the
end user.
Memory training can take a while and an impatient end user facing a
black screen for a while may reset the device unnecessarily.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=On screen text message during MRC training observed on skolas
Change-Id: I4ea15123eed1a4355c5ff7d815925032d4151de0
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70300
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces an early graphics driver which can be used in
romstage in cache-as-ram mode. The implementation relies on
`libgfxinit' and provide VGA text mode support.
SoCs wanting to take advantage of this driver must implement the
`early_graphics_soc_panel_init' function to set the panel power
sequence timing parameters.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=Graphics bring up observed on skolas with extra patches
Change-Id: Ie4ad1215e5fadd0adc1271b6bd6ddb0ea258cb5b
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70299
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Maulik Vaghela <maulikvaghela@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel provides a Real-Time Tuning Guide for Elkhart Lake to improve
real-time behaviour of the SoC (see Intel doc #640979). It describes,
amongst knobs for the OS, a couple of firmware settings that need to be
set properly to reduce latencies in all the subsystems. Things like
clock and power gating as well as low power states for peripherals and
buses are disabled in this scenario.
This patch takes the mentioned UEFI parameters from the guide and
translates them to FSP-M and FSP-S parameters. In addition, a chip
config switch guards this tuning which can be selected on mainboard
level if needed.
When this real-time tuning is enabled, the overall system performance
in a real-time environment can be increased by 2-3%.
Change-Id: Ib524ddd675fb3ea270bacf8cd06cb628e895b4b6
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
pertinent header file
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarilly share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot Google/rex
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ib3dafd6c030c0c848aa82b03bb336cc8fad14de3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71627
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
pertinent header file
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarilly share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot Google/brya.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ic14305b0479a8c57531d9930946eded7ac518b09
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71625
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch that introduced the selection of software connection manager,
CB:64561 - 060df17f1d (soc/intel/alderlake/acpi: Add Kconfig options for
SCM and FCM) added a default to enable the software configuration
manager directly in the choice.
This leads to warnings when running make menuconfig:
src/soc/intel/alderlake/Kconfig:439:
warning: defaults for choice values not supported
src/soc/intel/meteorlake/Kconfig:337:
warning: defaults for choice values not supported
src/soc/intel/tigerlake/Kconfig:299:
warning: defaults for choice values not supported
I'm not sure why the Kconfig linter didn't catch this, but this
issue is currently breaking the build for me. This patch fixes
it so that instead of setting the default directly, a new Kconfig
value is selected that then sets the default correctly.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I674046a93af8f7c2f3003900804deefa89dae295
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71776
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Not all ports have retimers. Add a property to denote that a particular
port has a retimer (instead of assuming that all ports have retimers).
BUG=b:263964979
TEST=Verified on guybrush; SSDT shows retimer-switch on port1 when
device tree is updated accordingly.
Change-Id: I754323236d2912777b63cede0fce2ccf7882cfea
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71663
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A mainboard port needs to:
- select `CONFIG_MAINBOARD_HAS_EARLY_LIBGFXINIT'
- implement the Ada package `GMA.Mainboard' with a single function
`ports' that returns a list of ports to be probed for displays.
- set the desired `GFX_GMA_DEFAULT_MMIO' IO memory address to use
in romstage (and ramstage) for the graphic device.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=libgfxinit compiles in romstage.
libgfxinit successfully executes in romstage and ramstage using
the requested MMIO setting on skolas.
Change-Id: I3c2101de10dc5df54fe873e43bbe0f1c4dccff44
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70276
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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).
BUG=b:263920313
TEST=Boot to OS on craask eMMC and NVMe SKUs with both unprovisioned
fw_config and fw_config set correctly.
Change-Id: I4167ee4d00b9ae8fe074c6f5e7a2d5a7382bfe6d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
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).
BUG=b:251055188
TEST=Boot to OS on yaviks eMMC and UFS SKUs with both unprovisioned
fw_config and fw_config set correctly.
On UFS SKU with fw_config set, eMMC no longer shows up in lspci.
(On eMMC SKU, UFS and ISH were already disabled by the coreboot PCI scan
so there's no change in behaviour.)
Change-Id: I31402cb49cffefd98b6fed971f249528448b1d0d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
IFDv1 always has 8 regions, while IFDv2 always has 16 regions.
It's platform specific which regions are used or are reserved.
The 'SPI programming guide' as the name says is a guide only,
not a specification what the hardware actually does.
The best to do is not to rely on the guide, but detect how many
regions are present in the IFD and expose them all.
Very early IFDv2 chipsets, sometimes unofficially referred to as
IFDv1.5 platforms, only have 8 regions. To not corrupt the IFD when
operating on an IFDv1.5 detect how much space is actually present
in the IFD.
Fixes IFD corruption on Wellsburg/Lynxpoint when writing a new
flash layout.
Change-Id: I0e3f23ec580b8b8402eb1bf165e3995c8db633f1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
The patch adds Kconfigs to define scaling factor for Efficient and
Performance cores instead of using hard coded values in the soc code.
Also, the patches uses the Kconfigs directly to calculate the core's
nominal performance. So, we don't need to implement soc function
soc_get_scaling_factor() to get the scaling factor data for different
core types. Hence, soc_get_scaling_factor() function is removed.
TEST=Build the code for Gimble and Rex. Also, I have verified that
build system logs error when the Kconfigs are undefined.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I55e4d815116ef40c5f33be64ab495e942bf35ee8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71687
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the watchdog timer reaches 0, the timer value won't reset to the
default value unless there is an external reset or a kick. It will
result in the watchdog failing to trigger the reset signal.
We kick the watchdog to reset the timer to the default value. Also,
because WDT hardware needs about 94us to synchronize the registers,
add a 100us delay before triggering the reset signal.
BUG=b:264003005, b:264017048
BRANCH=corsola
TEST= Reboot successfully with the following cmd
stop daisydog
sleep 60 > /dev/watchdog&
Signed-off-by: Runyang Chen <runyang.chen@mediatek.corp-partner.google.com>
Signed-off-by: Kuan-Hsun Cheng <allen-kh.cheng@mediatek.com>
Change-Id: Ic4964103d54910c4a1e675b59c362e93c2213b19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71754
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When AP boots up after Cr50 firmware update and reboot, AP finds
that Cr50 reset is required for Cr50 to pick the new firmware so
it trigger Cr50 reset and power off the system, AP expects system
will power on automatically after Cr50 reset. However this is not
the case for Chromebox, Chromebox EC set AP_IDLE flag when system
is shutting down, when AP_IDLE flag is set in EC, the system stays
at S5/G3 and wait for power button presssend. It cause an issue in
factory that the operator needs to press power button to power on
the DUT after Cr50 firmware update.
This patch sends EC command to direct EC to clear AP_IDLE flag
after AP shutdown so AP can boot up when Cr50 reset.
BUG=b:261119366
BRANCH=firmware-brya-14505.B
TEST=DUT boots up after Cr50 firmware update in factory test flow
Change-Id: If97ffbe65f4783f17f4747a87b0bf89a2b021a3b
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70773
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces a new config named `DEFAULT_ADL_NEM` and
allows respective brya variants with Alder Lake ESx samples to
choose NEM over eNEM as eNEM was fuse disabled till ESx.
TEST=The boot flow related to eNEM and NEM behaviour remains the
same with and without this patch.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibbd492a3d210739120c7ad16415cb7912f5b70ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
In cases where there are limitations on the mainboard it can be
necessary to limit the used SATA speed even though both, the SATA
controller and disk drive support a higher speed rate. The FSP parameter
'SataSpeedLimit' allows to set the speed limit.
This patch provides a chip config so that this FSP parameter can be
set as needed in the devicetree on mainboard level.
Change-Id: I610263b34b0947378d2025211ece4a9ec8fbfef6
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71229
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens. This removes
non-present devices from the SSDT and relieves the OS of the burden of
probing.
BUG=b:121309055
TEST=build/boot Windows/linux on multiple dedede variants, verify all
touchscreens functional in OS, dump ACPI and verify only i2c devices
actually present on the board have entries in the SSDT.
Change-Id: I91e03bd1d96a6b2f0c3813665910133db0d6c308
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The GPIOs themselves are configured as level triggered, and the drivers
(both Linux and Windows) work better with LEVEL vs EDGE triggering.
TEST=tested with rest of patch train
Change-Id: I212533ffdfb05f841e722c130b52c2976272e670
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
For touchscreens on dedede variants, drive the enable GPIO high
starting in romstage, then disable the reset GPIO in ramstage. This will
allow coreboot to detect the presence of i2c touchscreens during ACPI
SSDT generation (implemented in a subsequent commit).
Since the fast majority of dedede variants have a touchscreen option,
and those that do use the same GPIOs for enable/reset, set the GPIOs for
touchscreen operation in the baseboard and then override for the few (3)
variants that do not have a touchscreen.
BUG=b:121309055
TEST=tested with rest of patch train
Change-Id: Ib95e23545cc3e8589ddbd9e18cd0533bec9333e0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Add method variant_romstage_gpio_table() with empty weak implementation
to allow variants to override as needed for touchscreen power
sequencing (to be implemented in a subsequent commit). Call method
in romstage to program any GPIOs the variant may need to set.
TEST=tested with rest of patch train
Change-Id: Ic216827a4b53d1d35913efca63a43d4672791c54
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The dGPU used for some Brya projects requests 33 bits of address
space for one of its BARs via the Resizable BAR mechanism
(requires 6GB).
This Kconfig is currently set at 32 bits for brya, so the allocation currently is capped at 32 bits (4GB). This patch sets the limit to 33
bits for brya boards, which is enough for the GPU.
BUG=b:214443809
TEST=all of the dGPU PCI BARs on agah can be successfully allocated
Change-Id: Ia791be5108fb07a256ae62fc2aee2f057909ef12
Signed-off-by: Tarun Tuli <tarun@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
get_cpu_index() helper function returns cpu's index based on it's APIC
id position from the ascending order list of cpus' APIC IDs.
In order to calculate the cpu's index, the helper function needs to
traverse through each cpu node to find their APIC IDs. So, the function
traverse the CPU node list from the cpu whose APIC ID is 0 assuming it
is the first cpu node in the list. This logic works fine where BSP's
APIC ID is 0. But, starting from MTL, APIC ID for BSP need not be 0 as
APIC ID numbering first get assigned for CPU Die Efficient cores, then
Performance cores.
Please refer section# 6.1 of doc#643504 for more details on APIC IDs.
Considering the APIC Id allotment for MTL cores, as existing code
traversing begins from the cpu that has APIC Id#0 which may not be the
first cpu node in the list so index calculation results in wrong value.
The patch addresses above described issue by traversing all the CPU
nodes to calculate the cpu index. Also, prevents inconsistent report
of /sys/devices/system/cpu/cpu*/cpufreq/* and
/sys/devices/system/cpu/cpuXX/acpi_cppc on each reboot.
TEST=Verified that the get_cpu_index helper function returns the correct
index id for a CPU on Rex.
The coreboot log with code instrumentation, before this patch:
[DEBUG] my_apic_id:0x10 cpu_index: 0x6
[DEBUG] my_apic_id:0x11 cpu_index: 0x6
[DEBUG] my_apic_id:0x42 cpu_index: 0x6
[DEBUG] my_apic_id:0x21 cpu_index: 0x6
[DEBUG] my_apic_id:0x40 cpu_index: 0x6
[DEBUG] my_apic_id:0x31 cpu_index: 0x6
[DEBUG] my_apic_id:0x39 cpu_index: 0x6
[DEBUG] my_apic_id:0xa cpu_index: 0x3
[DEBUG] my_apic_id:0x0 cpu_index: 0x0
[DEBUG] my_apic_id:0x8 cpu_index: 0x2
[DEBUG] my_apic_id:0x4 cpu_index: 0x2
[DEBUG] my_apic_id:0x28 cpu_index: 0x6
[DEBUG] my_apic_id:0x2 cpu_index: 0x1
[DEBUG] my_apic_id:0x38 cpu_index: 0x6
[DEBUG] my_apic_id:0x29 cpu_index: 0x6
[DEBUG] my_apic_id:0xe cpu_index: 0x5
[DEBUG] my_apic_id:0x6 cpu_index: 0x2
[DEBUG] my_apic_id:0x20 cpu_index: 0x6
[DEBUG] my_apic_id:0x30 cpu_index: 0x6
[DEBUG] my_apic_id:0x19 cpu_index: 0x6
[DEBUG] my_apic_id:0xc cpu_index: 0x4
[DEBUG] my_apic_id:0x18 cpu_index: 0x6
We can see same cpu_index for multiple cores before fix.
After this patch..
[DEBUG] my_apic_id:0x10 cpu_index: 0x8
[DEBUG] my_apic_id:019 cpu_index: 0xb
[DEBUG] my_apic_id:0x11 cpu_index: 0x9
[DEBUG] my_apic_id:0x18 cpu_index: 0xa
[DEBUG] my_apic_id:0x40 cpu_index: 0x14
[DEBUG] my_apic_id:0x30 cpu_index: 0x10
[DEBUG] my_apic_id:0x42 cpu_index: 0x15
[DEBUG] my_apic_id:0xc cpu_index: 0x6
[DEBUG] my_apic_id:0x2 cpu_index: 0x1
[DEBUG] my_apic_id:0x29 cpu_index: 0xf
[DEBUG] my_apic_id:0xe cpu_index: 0x7
[DEBUG] my_apic_id:0x20 cpu_index: 0xc
[DEBUG] my_apic_id:0x0 cpu_index: 0x0
[DEBUG] my_apic_id:0x31 cpu_index: 0x11
[DEBUG] my_apic_id:0x28 cpu_index: 0xe
[DEBUG] my_apic_id:0x21 cpu_index: 0xd
[DEBUG] my_apic_id:0xa cpu_index: 0x5
[DEBUG] my_apic_id:0x38 cpu_index: 0x12
[DEBUG] my_apic_id:0x8 cpu_index: 0x4
[DEBUG] my_apic_id:0x4 cpu_index: 0x2
[DEBUG] my_apic_id:0x39 cpu_index: 0x13
Change-Id: I69e5e6231dd18b43d439340aaed50eb9edeca3b7
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70751
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch makes the call into TXT lib in order to disable the TXT
if SoC user haven't selected the `INTEL_TXT` config. Disabling TXT
would be helpful to access VGA framebuffer prior calling into FSP-M.
TEST=Able to perform disable_txt and unlock memory which helped to
access VGA framebuffer prior calling into FSP-M.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I9dd7c5492a5f45eef0dd9e836cc2da1844c78919
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71575
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add ACPI DmaProperty for gladios.
BUG=b:239513596
TEST=Verified SSDT on gladios unit.
Before:
Scope (\_SB.PCI0.RP01)
{
Device (RLTK)
{
Name (_HID, "R8168") // _HID: Hardware ID
Name (_UID, 0xD0E889DD) // _UID: Unique ID
Name (_DDN, "Realtek r8168") // _DDN: DOS Device Name
Name (_ADR, 0x00000000) // _ADR: Address
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x07,
0x03
})
}
}
After:
Scope (\_SB.PCI0.RP01)
{
Device (RLTK)
{
Name (_HID, "R8168") // _HID: Hardware ID
Name (_UID, 0xD0E889DD) // _UID: Unique ID
Name (_DDN, "Realtek r8168") // _DDN: DOS Device Name
Name (_ADR, 0x00000000) // _ADR: Address
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x07,
0x03
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("70d24161-6dd5-4c9e-8070-705531292865"),
Package (0x01)
{
Package (0x02)
{
"DmaProperty",
One
}
}
})
}
}
Change-Id: I1c4f6ff7b3eda114f4f365a963c089fe584d8aee
Signed-off-by: Robert Chen <robert.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71699
Reviewed-by: Kevin Chiu <kevin.chiu.17802@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
PRMRR is used by many Intel SOC features, not just Intel SGX.
As of now SGX and Key Locker are the features that need PRMRR.
Untie it from Intel SGX specific files and move to common cpulib.
Also rename PRMRR size config option. Use the renamed PRMRR size
config option to set the PRMRR size.
TEST=Able to set PRMRR size using config.
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Change-Id: I0cd49a87be0293530705802fd9b830201a5863c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70819
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
This patch decouples useful TXT related operations from the romstage.c
file alone and moves them into a helper txtlib.c. This effort will be
helpful for SoC users to perform TXT related operations
(like Disabling TXT) even without selecting INTEL_TXT config.
At present, those helper functions are only available upon selecting
INTEL_TXT which is not getting enabled for most of the SoC platform in
the scope of the Chromebooks.
TEST=Able to access functions from txtlib.c even without selecting
INTEL_TXT config.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iff5b4e705e18cbaf181b4c71bfed368c3ed047ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Sometimes, server platforms may have more than one socket on server
board. However, there's no field to store information about which
socket the DIMM comes from in dimm_info structure.
This patch adds soc_num field in dimm_info structure to store socket
ID of the DIMM.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I1b9e2b87fda2d7c32ecb8ce9d989795c8b869cea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Also disable TCO timer through calling tco_configure().
If tco_configure() is not called, the TCO timeout would
trigger SMI periodically about every 2 seconds with SMM log:
"TCO_STS: BIT18 TIMEOUT"
Tested=On AC CRB, does not see periodic SMI log.
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Change-Id: I2d307ad16109ae11862dd5e5acc0f12f47b22582
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71141
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
If cbmem_top is not 1M aligned there will be a hole between DPR base
and cbmem_top that the allocator will consider as unassigned memory.
Resources could incorrectly be assigned to that region and the final
MTRR solution will also try to skip that hole, therefore using a lot
more variable MTRRs than needed.
TESTED on Archer City 2S system: Uses 1 variable MTRR in the final
setup instead of 7.
Change-Id: I198f8d83bcfcdca3a770bd7f9a7060d5782a49fe
Signed-off-by: Arthur Heymans <arthur.heymans@9elements.com>
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71142
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Software Connection Manager doesn't work with Linux 5.13 or later,
resulting in TBT ports timing out. Not advertising this results
in Firmware Connection Manager being used and TBT works
correctly.
Add Kconfig options to chose between SCM (Software Connection
Manager) and FCM (Firmware Connection Manager). FCM is primary, as
it's more compatible save for ChromeOS devices as ChromeOS uses
SCM.
Linux patch:
torvalds/linux@c6da62a
c6da62a219d028de10f2e22e93a34c7ee2b88d03
Tested with StarBook Mk VI (i7-1260P).
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Iac31d37c0873f41f7b14e1051fe214466d1ebdd8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This patch adds the support to enable/disable package c-state demotion
feature from the devicetree based on mainboard requirement.
Port of commit 4be8d9e80d ("soc/intel/adl: Add support to configure
package c-state demotion")
BUG=none
TEST=Boot to the OS on Google/Rex.
Snippet from FSP log:
[SPEW ] PkgCState Demotion : 0x1
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I0a4b0b181349ce41035524482add4336cf83a68b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71654
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch configures max Pkg C-state to Auto which limits the max
C-state to deep C-state.
Port of commit af42906efa ("soc/intel/alderlake: Set max Pkg C-states
to Auto")
BUG=none
TEST=Boot to the OS on Google/Rex.
Snippet from FSP log:
[SPEW ] PkgCStateLimit : 0xFF
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Ic403ab83a594b04920d5cf600432939687a2598b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Because skyrim is loading ramstage from SPI with the DMA engine, the
size of the compressed image is less important to load speed than
decompression time.
Because the LZ4 decompression is so much faster than LZMA, compressing
with LZ4 saves us roughly 30ms in boot time.
For size, we're spending roughly 57KiB:
fallback/ramstage 0x9b00 stage 130864 LZMA (305316 decompressed)
fallback/ramstage 0x9b00 stage 189126 LZ4 (305316 decompressed)
Right now we have 2MiB empty space in Skyrim's RO before this change,
and roughly 550KiB empty space in RW, so there aren't currently any
size worries.
Just for fun, I also tested uncompressed ramstage, and it was still
18ms faster than LZMA, but that makes it roughly 12ms slower than LZ4.
BUG=b:264409477
TEST=Boot skyrim, look at boot speed.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Iedde6fc2db9d702c0ff2b0081e7baa254ac6699f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71675
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Previously, LZMA was included in romstage because it was almost always
needed to decompress ramstage. When compressing ramstage with LZ4, but
using LZMA compression for FSP-M, we still need the LZMA decompression
to be present, so update when the Makefile includes the LZMA decoder.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Id52d25a13420f05db8b2b563de0448f9d44638e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When ramstage is loaded asynchronously, as on the skyrim boards, the
faster decompression of LZ4 allows for faster boot times than the
tighter compression of LZMA.
To make this change, the name of the existing ramstage_compression
option needs to be updated.
BUG=b:264409477
TEST=Boot skyrim, look at boot speed
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I27dd1a8def024e0efd466cef9ffd9ca71717486a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71673
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the dibbi variant of the waddledee reference board by
copying the template files to a new directory.
BUG=b:260934018
BRANCH=dedede
TEST=util/abuild/abuild -p none -t google/dedede -x -a includes
GOOGLE_DIBBI
Change-Id: I3b8d4e7f8a53323f56567cbbc03bab7f8804f286
Signed-off-by: Liam Flaherty <liamflaherty@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71709
Reviewed-by: Adam Mills <adamjmills@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new ram_id:0000 for Micron MT62F1G32D2DS-026 WT:B.
Add new ram_id:0010 for Micron MT62F512M32D2DR-031 WT:B
The RAM ID table has been assigned as:
DRAM Part Name ID to assign
K3KL8L80CM-MGCT 0 (0000)
H58G56BK7BX068 0 (0000)
MT62F1G32D2DS-026 WT:B 0 (0000)
K3KL9L90CM-MGCT 1 (0001)
H58G66BK7BX067 1 (0001)
MT62F2G32D4DS-026 WT:B 1 (0001)
MT62F512M32D2DR-031 WT:B 2 (0010)
BUG=b:263296326, b:263216451
BRANCH=None
TEST=FW_NAME=markarth emerge-skyrim coreboot
Change-Id: I3a0d3edb813ef91bfdc68f7400be64fb679dfc04
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71619
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Enable eNEM for all nissa variants. This is mostly done to be consistent
with other recent Intel platforms. It's not strictly necessary since on
nissa the LLC size is larger than the total code + data size used in
CAR. There is no change in boot time.
BUG=None
TEST=Boot to OS on craask
Change-Id: Iad48976e405403ab61c71d8f72e0616ea8b85ebd
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71707
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
When EC_GOOGLE_CHROMEEC_INCLUDE_SSFC_IN_FW_CONFIG is enabled and
SSFC is not set, it will treat missing SSFC as zero, so Kano needs
to set the ov2740 to 0 to avoid probing wrong mipi camera.
Before patch
>fw_config match found: UFC=UFC_MIPI_OVTI2740
>fw_config match found: AUDIO=MAX98373_NAU88L25B_I2S
>fw_config match found: AUDIO=MAX98373_NAU88L25B_I2S
>fw_config match found: AUDIO=MAX98373_NAU88L25B_I2S
>fw_config match found: UFC=UFC_MIPI_OVTI2740
>fw_config match found: ZYDRON_UFC=UFC_MIPI_HI556
>fw_config match found: UFC=UFC_MIPI_OVTI2740
>fw_config match found: STYLUS=STYLUS_PRESENT
After patch
>fw_config match found: UFC=UFC_MIPI_OVTI2740
>fw_config match found: AUDIO=MAX98373_NAU88L25B_I2S
>fw_config match found: AUDIO=MAX98373_NAU88L25B_I2S
>fw_config match found: AUDIO=MAX98373_NAU88L25B_I2S
>fw_config match found: UFC=UFC_MIPI_OVTI2740
>I2C: 00:20 disabled by fw_config
>fw_config match found: UFC=UFC_MIPI_OVTI2740
>fw_config match found: STYLUS=STYLUS_PRESENT
BUG=b:262939431
TEST=Boot on kano and check functional with ov2740 camera.
Change-Id: I46fac6c820d6006956680a07198db82225630905
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This is support for adding legacy VGA support into romstage.
Support for this is being provided by libgfxinit.
The current use case allows us to initialize the display
before memory init (prior to physical memory init) to inform
the user when lengthy memory training is needed.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=VGA code compiles for romstage
Change-Id: I81309871e8db71657b2a9816708141f121d767d3
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70278
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch disables the stage cache to save boot time.
Note: S3 is not POR for Intel MTL mobile skus.
Boot time is reduced by ~8ms.
Boot time before:
4:end of romstage 1,391,225 (13,724)
100:start of postcar 1,403,339 (12,114)
Boot time after:
4:end of romstage 1,380,262 (5,618)
100:start of postcar 1,392,323 (12,060)
Change-Id: I9775fc628f345a514894f30435a374e2ffa057c1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71695
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The patch addresses Intel heterogeneous cores as `Efficient` and
`Performance` cores instead of `small` and `big` cores. It is to ensure
coreboot code has uniform reference to the heterogeneous cores. So, the
patch renames all `small` and `big` core references to `efficient` (eff)
and `performance` (perf) cores respectively.
TEST=Build the code for Brya and Rex boards
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I98c9c0ed86b211d736a0a1738b47410faa13a39f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71639
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add below mentioned functions:
is_sgx_configured_and_supported():
Checks if SGX is configured and supported
is_keylocker_configured_and_supported():
Checks if Key Locker is configured and supported
check_prm_features_enabled():
Checks if any of the features that need PRM are configured
and supported. As of now SGX and Key Locker are the only
features that need PRM.
Also, call check_prm_features_enabled() from get_valid_prmrr_size()
to make sure PRM dependent features are enabled and configured before
returning PRMRR size.
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Change-Id: I51d3c144c410ce4c736f10e3759c7b7603ec3de9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
To support an RPL SKU on omnigul, omnigul must use the FSP for RPL.
Select SOC_INTEL_RAPTORLAKE for omnigul so that it will use the RPL
FSP headers for omnigul.
BUG=b:263060849
BRANCH=None
TEST=FW_NAME=omnigul emerge-brya intel-rplfsp
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage
Change-Id: If3cfbaeff0472012cb8f30ed8fff3bf5cac23f85
Signed-off-by: jamie_chen <jamie_chen@compal.corp-partner.google.com>
Change-Id: I6a0afb04bea4940e13ea62c2cd0a09500b8b5335
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71702
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Although S3 is supported on nissa, only S0ix is used on user devices,
so we can ignore optimising the S3 resume time. Disable the stage
cache to save boot time at the cost on increasing the S3 resume time.
Boot time is reduced by ~6 ms. This is mostly from adding postcar to
the stage cache, which is slow since TSEG is not cached in romstage.
Adding ramstage and FSP-S take negligible time.
The S3 resume time is increased by ~89 ms total from loading and
decompressing ramstage and FSP-S.
Boot time before:
3:after RAM initialization 573,295 (931)
4:end of romstage 583,569 (10,274)
100:start of postcar 587,729 (4,160)
Boot time after:
3:after RAM initialization 571,527 (830)
4:end of romstage 575,712 (4,185)
100:start of postcar 579,866 (4,153)
S3 resume time before:
101:end of postcar 368,904 (0)
10:start of ramstage 369,165 (260)
971:loading FSP-S 385,742 (16,577)
30:device enumeration 407,105 (21,362)
S3 resume time after:
101:end of postcar 363,101 (0)
8:starting to load ramstage 363,101 (0)
15:starting LZMA decompress (ignore for x86) 382,802 (19,701)
16:finished LZMA decompress (ignore for x86) 431,620 (48,817)
9:finished loading ramstage 431,850 (230)
10:start of ramstage 431,927 (76)
971:loading FSP-S 448,357 (16,430)
17:starting LZ4 decompress (ignore for x86) 474,420 (26,062)
18:finished LZ4 decompress (ignore for x86) 474,627 (206)
BUG=b:247940538, b:192032803
TEST=Boot and S3 suspend/resume on craask
Change-Id: I8015dc0808ee19cac67c2a6573d52781c6120e8c
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71677
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
On recent Intel ChromeOS devices, although S3 is still supported, only
S0ix is used on user devices, so we don't care about optimising S3
resume time. Disabing the stage cache saves boot time at the cost of
increasing the S3 resume time. E.g. on nissa this reduces boot time by
6 ms and increases S3 resume time by 89 ms.
BUG=b:247940538, b:192032803
TEST=Build and boot on nissa with MAINBOARD_DISABLE_STAGE_CACHE
selected.
Change-Id: I243a401a112a12bb824c5447a8fecc99500f7739
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Updating from commit id 196b0843e9 :
to a09b792e6a : Makefile: Remove old include directories
This brings in 9 new commits.
Fix:
cc1: error: firmware/lib/cryptolib/include: No such file or directory [-Werror=missing-include-dirs]
cc1: error: firmware/lib20/include: No such file or directory [-Werror=missing-include-dirs]
Change-Id: I292d3a4046c1a1890a640747cbbd00e79e5e56b4
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71582
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch will enable Kconfig SOC_INTEL_CSE_LITE_SKU option required
to enable CSE-Lite SKU for MTL-RVP. On enabling the respective Kconfig
option, CSE reboots the system into CSE_RW FW region on cold reboot.
BUG=b:224325352
TEST=Able to boot intel/mtlrvp to ChromeOS and also able to observe
CSE boot to RW FW region as part of coreboot console log,
localhost ~ # cbmem -c | grep cse
[DEBUG] cse_lite: Number of partitions = 3
[DEBUG] cse_lite: Current partition = RW
[DEBUG] cse_lite: Next partition = RW
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I325405cc304d245871396317c11ac7a5b062a5bd
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71638
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
DRAM Part Name ID to assign
K3KL8L80CM-MGCT 0 (0000)
H58G56BK7BX068 0 (0000)
K3KL9L90CM-MGCT 1 (0001)
H58G66BK7BX067 1 (0001)
MT62F2G32D4DS-026 WT:B 1 (0001)
BUG=b:263296326, b:263216451
BRANCH=None
TEST=FW_NAME=markarth emerge-skyrim coreboot
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Change-Id: I4f00d444bd59443ecba29c6c155d676bab7a3d82
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chao Gui <chaogui@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Create the markarth variant of the skyrim reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0.)
BUG=b:262092858
BRANCH=None
TEST=util/abuild/abuild -p none -t google/skyrim -x -a
make sure the build includes GOOGLE_MARKARTH
Change-Id: Ifbace841ca56d8659aaffdc31fb2bc4367d96f82
Signed-off-by: Chao Gui <chaogui@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
BUG=none
TEST=Verify presence of subsystem ID for fast_spi device on google/rex.
lspci output before this patch:
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device [8086:7e23]
lspci output after this patch:
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device [8086:7e23]
Subsystem: Intel Corporation Device [8086:7e23]
Note: UPD SiSkipSsidProgramming was set to 1 for above test.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I08c7a5a3fdc7389b315e85180c16d1ec335fbba2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Select SOC_INTEL_RAPTORLAKE to force coreboot to use the RPL FSP headers
for FSP.
Since we use RPL FSP and it will support ADL as well, we rename
"Gaelin4ADL" to "Gaelin".
BUG=b:258603624
BRANCH=firmware-brya-14505.B
TEST=emerge-brask coreboot
Cq-Depend: chrome-internal:5227091, chromium:4113361
Change-Id: Ie7349f3670aeec166228e7df55300cd30d0ca16c
Signed-off-by: Mike Shih <mikeshih@msi.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Fix:
CC romstage/mainboard/amd/pademelon/static.o
cc1: error: src/vendorcode/amd/pi/00670F00/Lib: No such file or directory [-Werror=missing-include-dirs]
CC romstage/mainboard/amd/gardenia/static.o
cc1: error: src/vendorcode/amd/pi/00670F00/Lib: No such file or directory [-Werror=missing-include-dirs]
CC romstage/mainboard/google/kahlee/static.o
cc1: error: src/vendorcode/amd/pi/00670F00/Lib: No such file or directory [-Werror=missing-include-dirs]
CC romstage/mainboard/google/kahlee/static.o
cc1: error: src/vendorcode/amd/pi/00670F00/Lib: No such file or directory [-Werror=missing-include-dirs]
Change-Id: I038f87f564ed0415035d92bf0d79a9f8ae2227a4
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
For some reason, the Windows LPEA drivers won't attach without
_HRV (hardware version) defined for the GPIO controllers.
Add it, using value taken from Intel baytrail/valleyview edk2
reference code.
TEST=boot Windows 10/11 on google/rambi, verify LPEA drivers load
properly.
Change-Id: Iaa6e1b3f68537e012e4a58175d5334a8aa2f4178
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71200
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
For some reason, the Windows i2c drivers won't attach without
_HRV (hardware version) defined for the i2c controllers.
Add it, using value taken from Intel baytrail/valleyview edk2
reference code.
TEST=boot Windows 10/11 on google/rambi, verify i2c drivers load
properly.
Change-Id: I590acd1f1b75f6bf2bf278e67eec1dcc24bcc15d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Change the IRQ triggering from edge to level for cypress touchpad
on peppy variant for compatibility with Windows drivers.
TEST=boot Linux 5.x/6.x, Windows 10/11 on peppy, verify touchpad
functional.
Change-Id: Iecf6cb919bf16ec9180ca050e7eafe55247337ed
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens. This removes
non-present devices from the SSDT and relieves the OS of the burden of
probing.
BUG=b:121309055
TEST=build/boot Windows/linux on drallion, verify touchscreen functional
in OS, dump ACPI and verify only i2c devices actually present on the
board have entries in the SSDT.
Change-Id: I67c3d1fc3d34e9b67ddb26afcaad3a47ffa92e2f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The GPIOs themselves are configured as level triggered, and the drivers
(both Linux and Windows) work better with LEVEL vs EDGE triggering.
TEST=tested with rest of patch train
Change-Id: I1bdbf017bc7480f59cec85c70d6e71dac294dcd2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71192
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
For touchscreens on drallion, drive the enable GPIO high starting in
romstage while holding in reset, then disable the reset GPIO in
ramstage. This will allow coreboot to detect the presence of i2c
touchscreens during ACPI SSDT generation (implemented in a subsequent
commit).
BUG=b:121309055
TEST=tested with rest of patch train
Change-Id: I6825345f35a7415020e77edf781139f0c9b5f875
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add method variant_romstage_gpio_table() with empty implementation to
be used in a subsequent commit for touchscreen power sequencing.
Call method in romstage to program any GPIOs that may need to be set.
TEST=tested with rest of patch train
Change-Id: I0ad0c18a8b61e59a943a453882bf74762bac4700
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch provides an API to allow users to output multi-line
messages using VGA framebuffer.
The current limitation with multiline message is that,
vga_line_write() function is unable to understand newline character
hence, eventually output multiple lines separated with a newline
character with a single line statement.
This patch ensures to parse the entire string and split it into
multiple lines based on the newline character and print each line
separately to the VFG framebuffer.
User can choose to align the output video message as per given choice
between left/center/right of the screen
(i.e. enum VGA_TEXT_ALIGNMENT ).
Additionally, added macros to define the horizontal screen alignment
as well. Ideally if user would like to print the video message at the
middle of the screen then the vertical alignment would be
`VGA_TEXT_CENTER` and horizontal alignment would be
`VGA_TEXT_HORIZONTAL_MIDDLE`.
TEST=Able to build and boot Google/Taeko.
While output a video message such as :
"Your device is finishing an update. This may take 1-2 minutes.\nPlease
do not turn off your device."
Without this patch:
Your device is finishing an update. This may take 1-2 minutes. nPlease
do not turn off your device.
With this patch:
(in Left Alignment):
Your device is finishing an update. This may take 1-2 minutes.
Please do not turn off your device.
(in Right Alignment):
Your device is finishing an update. This may take 1-2 minutes.
Please do not turn off your device.
(in Center Alignment):
Your device is finishing an update. This may take 1-2 minutes.
Please do not turn off your device.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib837e4deeba9b84038a91c93a68f03cee3474f9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71265
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for boards using SOC_INTEL_BRASWELL.
Currently BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is selected for
CPU_INTEL_HASWELL, SOC_INTEL_BRASWELL and others (see [2]). However,
there seems to be no particular reason on those platforms. We've dropped
the config for haswell. Now do the same for SOC_INTEL_BRASWELL, so that
VBOOT_VBNV_FLASH can be enabled.
VBOOT_VBNV_FLASH is enabled for the following boards:
- facebook/fbg1701: A 0x2000 RW_NVRAM region is allocated, with the
FW_MAIN_A(CBFS) size reduced by 0x2000.
- google/cyan, intel/strago: Repurpose RW_UNUSED as RW_NVRAM.
[1] https://issuetracker.google.com/issues/235293589
[2] commit 6c2568f4f5
("drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config")
BUG=b:235293589
TEST=./util/abuild/abuild -t FACEBOOK_FBG1701 -a (with VBOOT selected)
TEST=./util/abuild/abuild -x -t GOOGLE_CYAN -a
TEST=./util/abuild/abuild -x -t INTEL_STRAGO -a
Change-Id: I46542c2887b254f59245f20b8642b023a7871708
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
When VBOOT is enabled, the COREBOOT region (of size 0x09B000) is not
large enough. Therefore, adjust vboot-rw.fmd (which is used only with
VBOOT) layout by moving 0x10000 space from FW_MAIN_A(CBFS) region to
COREBOOT(CBFS) region.
TEST=./util/abuild/abuild -t FACEBOOK_FBG1701 -a (with VBOOT selected)
Change-Id: I1bc0d6981b873ca631cc4cc0720ab212700a65aa
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
There is an ongoing effort to deprecate VBOOT_VBNV_CMOS [1] and replace
with VBOOT_VBNV_FLASH. However, the rambi's CAR is too small for early
flash access in romstage:
/usr/local/google/home/yupingso/projects/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd:
Cache as RAM area is too full
/usr/local/google/home/yupingso/projects/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd:
section .car.mrc_var VMA [00000000fe008000,00000000fe00ffff] overlaps
section .car.data VMA [00000000fe000000,00000000fe008787]
make: *** [src/arch/x86/Makefile.inc:194:
coreboot-builds/GOOGLE_RAMBI/cbfs/fallback/romstage.debug] Error 1
More precisely, DCACHE_RAM_SIZE is 0x8000, and the current .car.data
size is 0x76c0. If BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is unselected,
then the _bss region will increase by 0x10c8 bytes (for global variables
such as `elog_mirror_buf` and `sfg`), so that .car.data will exceed
0x8000.
Since rambi has reached its AUE (2021-09-01), disable
MAINBOARD_HAS_CHROMEOS and VBOOT configs.
[1] https://issuetracker.google.com/issues/235293589
BUG=b:235293589
TEST=./util/abuild/abuild -t GOOGLE_RAMBI -a
TEST=./util/abuild/abuild -x -t GOOGLE_RAMBI -a
Change-Id: Id56795dd0653784b4d7141142ebef0b19a46ddc3
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71545
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This patch adds a new section to the coding style which codifies
existing practices about how to handle errors and how to use the die()
and assert() macros. Also clean up some references to Linux-specific
facilities that do not exist in coreboot in the adjacent function return
type guidelines, and add a small blurb of documentation to the
definition of the assert() macro itself.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ice37ed9f995a56d69476e95a352209041b337284
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70775
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Replace the intelblocks/gpio.h and soc/gpio.h includes with the
common gpio.h which will include soc/gpio.h which will include
intelblocks/gpio.h
BUG=b:261778357
TEST=Able to build and boot Google/brya.
Change-Id: Ia90a8ea7b4ee125657c7277e3e14018cfe5423a9
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71266
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add devicetree and GPIO configuration for MTL-RVP
Changes include,
1. Add initial devicetree to support MTL-RVP board & variant
2. Add initial setup for ramstage gpio config
BRANCH=none
BUG=b:224325352
TEST=Able to build with the patch and boot the mtlrvp to chromeOS
using subsequent patches in the train.
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I3173c3f32b36d24467431df3652badd70efeab93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch adds initial bootblock code. This also configures required
GPIOs for early board initialization.
1. Add bootblock file for MTL-RVP
2. Add early gpio config for MTL-P variant in gpio.c
BRANCH=none
BUG=b:224325352
TEST=Able to build with the patch and boot the mtlrvp platform to
ChromeOS with the subsequent patches in the train
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I9c0893e52036147c5f6bbfafc6d818e9d3460bed
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
On Marasov, 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 Marasov.
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
After:
$ cat /sys/devices/pci0000\:00/0000\:00\:12.0/untrusted
1
Change-Id: I4b65b8909c41b06852fe7771375029bd2e76e111
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71263
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
1. Replace all pcidev_path_on_root() and is_dev_enabled()
functions combination with is_devfn_enabled().
2. Remove unused local variable of device structure type
(struct device *).
3. Replace pcidev_path_on_root() and dev->enabled check with
is_devfn_enabled() call.
TEST=Able to build and boot without any regression seen on MTL.
Port of 'commit 50134eccbd ("soc/intel/alderlake: Make use
of is_devfn_enabled() function")'
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I54bbd2bdba69a19e0559738035916fa7ac60faaa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch moves API "smbios_cpu_get_max_speed_mhz()"
to common code from board specific. This API was made
generic in 'commit d34364bdea ("soc/intel/alderlake:
Utilize `CPU_BCLK_MHZ` over dedicated macro")'
BUG=NONE
TEST=Boot and verified that SMBIOS max speed value is
correct on brya and rex.
(brya) dmidecode -t : "Max Speed: 4400 MHz"
(rex) dmidecode -t : "Max Speed: 3400 MHz"
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I87040ab23319097287e191d7fc9579f16d716e62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70879
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
python3-setuptools installed via apt-get is not currently working to
build dtc from git.kernel.org. Falling back to setuptools version
58.2.0 allows it to build again.
The failure message was:
/usr/lib/python3/dist-packages/setuptools/installer.py:27:
SetuptoolsDeprecationWarning: setuptools.installer is deprecated.
Requirements should be satisfied by a PEP 517 installer.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I04cb6d776c3748f9a4b0cfc4ffd4f46458560d3d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71500
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With enabling FSP Notify Phase APIs, it has chance to issue a global
reset in FSP after CSE EOP (with selecting SOC_INTEL_CSE_SEND_EOP_EARLY
), which CSE already in idle mode and cause failure. For this reason we
should drop SOC_INTEL_CSE_SEND_EOP_EARLY in all ADL sku and select
SOC_INTEL_CSE_SEND_EOP_LATE instead.
BUG=b:261544011
BRANCH=firmware-brya-14505.B
TEST=tested and verified on Marasov, make sure this kind of global
reset can be executed successfully.
Signed-off-by: Tracy Wu <tracy.wu@intel.corp-partner.google.com>
Change-Id: I29736ca8efee64dd03feb48404241ee6295b7c72
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Contents of unsigned AMDFW in RW sections are verified twice in PSP
verstage - first time by vboot verifying the firmware body, second time
by CBFS verification while the file is loaded to update PSP about the
boot region. This redundant verification adds to boot time. Minimize the
redundancy by splitting the EFS header from the AMDFW body and keep them
as 2 separate CBFS files. This helps to improve the boot time by another
25 ms.
BUG=None
TEST=Build Skyrim BIOS image and boot to OS. Observe boot time
improvement of ~25ms.
Before:
6:end of verified boot 363,676 (16)
11:start of bootblock 641,392 (277,716)
After:
6:end of verified boot 361,655 (16)
11:start of bootblock 616,967 (255,312)
Change-Id: Ib18a4f5c6781e5a7868e9395c0f1212da0823100
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70839
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support to write EFS and AMDFW body to separate files. This is done
through passing an optional --body-location parameter to the amdfwtool.
If that option is not passed, then EFS will be written in the same file
as the AMDFW body. This will help to keep the minimum data to be
loaded/mapped from CBFS in PSP verstage.
BUG=None
TEST=Build and boot to OS in Skyrim.
Change-Id: I79325c81394cf8a0c663752d094adf6660896127
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70778
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens/digitizers.
This removes non-present devices from the SSDT and relieves the OS of
the burden of probing.
BUG=b:121309055
TEST=build/boot Windows/linux on all poppy variants, verify all
touchscreens functional in OS, dump ACPI and verify only i2c devices
actually present on the board have entries in the SSDT.
Change-Id: I4c1d8ae8c41c1f4283718a86fccbf5ae4fc399b6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70921
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For touchscreens/digitizers on poppy variants, drive the enable
GPIO high and hold in reset in romstage, then release from reset in
ramstage. This will allow coreboot to detect the presence of i2c
touchscreens/digitizers during ACPI SSDT generation (enabled in a
subsequent commit).
TEST=tested with the rest of patch train
Change-Id: I90ac4f09c343a28328f7d30254f0448cbe0c78b3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Due to a high I2C bus load on the mainboard I2C frequency of 400 kHz
leads to poor signaling. Therefore limit the I2C speed to 100 kHz for
this bus. In addition, add a generic I2C device with 100 kHz bus speed
to the devicetree so that the OS will not switch to higher clock rates,
too.
Test= Measure the I2C signals at coreboot and OS runtime and ensure the
clock is always at 100 kHz.
Change-Id: I6b0a642cd3f5b77331663ac8c76ed0a116ae77ca
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71227
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When PTN3460_EARLY_INIT is selected, the PTN3460 (DP-2-LVDS-bridge) will
be initialized before all devices are initialized. This is necessary to
get a valid EDID data set into the PTN3460 before the graphic controller
is initialized in order to be able to show a splash screen.
For ptn3460_init() to work properly the I2C bus this bridge is connected
to needs to be initialized. As this I2C bus initialization would be done
too late in the normal flow, it needs to be called here explicitly
before ptn3460_init() to initialize the I2C bus with the needed
conditions. Otherwise the default I2C settings of the controller will be
used which results in a clock rate too high for this mainboard.
Test=Measure I2C bus signals and make sure that the clock is <= 400 kHz.
Change-Id: I1775fb7c2d29f765224d0e7c7ff9fcd4dbf847c5
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71226
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On broadwell devices, coreboot currently disables and hides the ME PCI
interface by default, without any way to opt out of this behavior.
Add a Kconfig option to allow for leaving the ME PCI interface
enabled, but set the default to disabled as to leave the current
behavior unchanged.
Change-Id: If670d548c46834740f4e21bb2361b537807c32bf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
On lynxpoint devices, coreboot currently disables and hides the ME PCI
interface by default, without any way to opt out of this behavior.
Add a Kconfig option to allow for leaving the ME PCI interface
enabled, but set the default to disabled as to leave the current
behavior unchanged.
Change-Id: I994cb5b05829eddad2e423a7440a9458f9952370
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch fills in a generic platform info structure based on the
inputs from the SoC dptf header file (soc/dptf.h).
It will help to make things common and drop unnecessary back and
forth call between common code and SoC code.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3521882495485cef686655abd65337515bae5faa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71111
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add DEVAPC_DEBUG option and set this option to disabled by default.
This option prevents DEVAPC log flooding during the boot process. Enable
this option when we need to debug DEVAPC issues.
TEST=DEVAPC log is disabled by default.
Change-Id: I26bc0378b8a766c6a8cc4903d64a921c3e96b93f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71158
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The touchscreen reset GPIO is configured as PAD_CFG_TERM_GPO with an
internal pull-down, which puts it in a state of contention when the
reset pin is released / set to high. Fix this by changing the reset
GPIO to PAD_CFG_GPO like all other poppy variants use for the
touchscreen reset.
TEST=build/boot nocturne, touchscreen still works.
Change-Id: I1ad4bb9d4194485990f54ffa7bae05f5c9a39deb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71185
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens. This removes
non-present devices from the SSDT and relieves the OS of the burden of
probing.
BUG=b:121309055
TEST=build/boot Windows/linux on multiple hatch variants, verify all
touchscreens functional in OS, dump ACPI and verify only i2c devices
actually present on the board have entries in the SSDT.
Change-Id: I2eae486eaa5e42cfe42ecc066a58b09fe2bd9138
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71062
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIOs themselves are configured as level triggered, and the drivers
(both Linux and Windows) work better with LEVEL vs EDGE triggering.
TEST=tested with rest of patch train
Change-Id: I580348d0aabb24f0241d6e9992c5a17942bd57ab
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71061
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
For touchscreens on hatch variants, drive the enable GPIO high starting
in romstage, then disable the reset GPIO in ramstage. This will allow
coreboot to detect the presence of i2c touchscreens during ACPI SSDT
generation (implemented in a subsequent commit).
BUG=b:121309055
TEST=tested with rest of patch train
Change-Id: I86c5f41b7820eaf5252c276ae854a4206e09385f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71059
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add method variant_romstage_gpio_table() with empty weak implementation
to allow variants to override as needed for touchscreen power
sequencing (to be implemented in a subsequent commit). Call method
in romstage to program any GPIOs the variant may need to set.
TEST=tested with rest of patch train
Change-Id: I1939387b5bb98d6d282fd044e9ce8780dbe0d2c5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on berknip/morphius, verify all
touchpad functions work correctly.
Change-Id: I9d8362719ddbfe523dd83964556b05bb8f1bb1ba
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71138
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on lindar, verify all touchpad
functions work correctly.
Change-Id: If2deedbd572b771c1e7793a3b3c37a3114aa2a48
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The current implementation of the MCRS had several issues with BARs
and MMCONF not being available:
[ 0.156231] pci 0000:00:02.0: BAR 2: assigned to efifb
[ 0.165302] pci 0000:00:18.2: can't claim BAR 0 [mem 0xddffc000-0xddffcfff 64bit]: no compatible bridge window
[ 0.192896] pci 0000:00:18.2: BAR 0: assigned [mem 0x280000000-0x280000fff 64bit]
...
[ 0.138300] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.138300] PCI: not using MMCONFIG
[ 0.148014] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.149674] [Firmware Info]: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] not reserved in ACPI motherboard resources
[ 0.149679] PCI: not using MMCONFIG
[ 0.155052] acpi PNP0A08:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
This new MCRS, tested on the Star Lite Mk IV, resolves these issues:
[ 0.158786] pci 0000:00:02.0: BAR 2: assigned to efifb
[ 0.197391] pci 0000:00:1f.1: BAR 0: assigned [mem 0x280000000-0x2800000ff 64bit]
...
[ 0.138460] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.138460] PCI: not using MMCONFIG
[ 0.150889] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.152548] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ib6fc58efc9aadb5828251e0260622dac7ea3ef2b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66244
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on coral, verify all touchpad
functions work correctly.
Change-Id: I161eb953bf8bceb353cf43803ee948c522928892
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71076
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on nami, verify all touchpad
functions work correctly.
Change-Id: I0611da8bbea41565e603a1a1b7cc20226ba21c62
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on bobba, verify all touchpad
functions work correctly.
Change-Id: I4fd66be21eeff5f37b58a8922c49683a28685064
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on liara, verify all touchpad
functions work correctly.
Change-Id: I89ca02629803882e7ed2048a5a26868fc2de41a9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on akemi/kohaku, verify all touchpad
functions work correctly.
Change-Id: Icb552caa69428908e5e3342139b578a145fa2797
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot ChromeOS, Linux 5.1x, Windows 10 on dewatt, verify all
touchpad functions work correctly.
Change-Id: I00efde6f007d57166cd82f76d2f389dedce57466
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=boot Linux 5.1x, Windows 10 on drawcia, verify all touchpad
functions work correctly.
Change-Id: I43eb5bc394a3fbfd4109f2e6c274ec66fc01d46d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The currently assigned ACPI HID 'PNP0C50' is not a valid per Windows
WHQL validation tests. To ensure compatibility with both Windows and
Linux, set the HID to 'SYNA0000' and CID to 'ACPI0C50' as previously
done for other boards (eg, google/lulu).
TEST=untested on brya, but tested under Windows/Linux on all other
boards in the tree using Synaptics touchpads.
Change-Id: Ia9351185b918f2d6f2d2be110b88e8310d37a03f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Audio codec RT1011_ALC5682I_I2S is listed as a fw_config option in the
baseboard, but missing from the HDA device probe list in the variant
overridetrees, preventing it from being detected at boot.
TEST=build/boot lindar, verify audio codec identified and HDA device not
disabled by fw_config.
Change-Id: Ib40b095688aac5cf4e0a60dcac250023c4f04c9f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens. This removes
non-present devices from the SSDT and relieves the OS of the burden of
probing.
BUG=b:121309055
TEST=build/boot Windows/linux on multiple reef variants, verify all
touchscreens functional in OS, dump ACPI and verify only i2c devices
actually present on the board have entries in the SSDT.
Change-Id: I8c90074515b1c7d3ab742768d7bbd904fec256d4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71154
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIOs themselves are configured as level triggered, and the drivers
(both Linux and Windows) work better with LEVEL vs EDGE triggering.
TEST=tested with rest of patch train
Change-Id: I1000df10eea5670bf1bc8d04c736150b6a5e26a1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71153
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
For touchscreens on reef variants, drive the enable GPIO high starting
in romstage, then disable the reset GPIO in ramstage. This will allow
coreboot to detect the presence of i2c touchscreens during ACPI SSDT
generation (implemented in a subsequent commit). As the GPIOs are
already correct in ramstage, only the romstage ones need to be set.
BUG=b:121309055
TEST=tested with rest of patch train
Change-Id: I10d1789c8de23653bac81e1f9604a47f93fa3f7d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71152
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add method variant_romstage_gpio_table() with empty weak implementation
to allow variants to override as needed for touchscreen power
sequencing (to be implemented in a subsequent commit). Call method
in romstage to program any GPIOs the variant may need to set.
TEST=tested with rest of patch train
Change-Id: Id3ab412183e5c5d534b2e1dea3222c729c25118b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now that power sequencing has been implemented, switch from using ACPI
"probed" flag to "detect" flag for all i2c touchscreens. This removes
non-present devices from the SSDT and relieves the OS of the burden of
probing.
BUG=b:121309055
TEST=build/boot Windows/linux on multiple volteer variants, verify all
touchscreens functional in OS, dump ACPI and verify only i2c devices
actually present on the board have entries in the SSDT.
Change-Id: I0448d12a36f522b715e1fbeb8d37eb5a925ebc93
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71183
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIOs themselves are configured as level triggered, and the drivers
(both Linux and Windows) work better with LEVEL vs EDGE triggering.
TEST=tested with rest of patch train
Change-Id: I269361f90a838d7766ad429afe82ef885f0d9371
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71182
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For touchscreens on volteer variants, drive the enable GPIO high
starting in romstage, then disable the reset GPIO in ramstage. This will
allow coreboot to detect the presence of i2c touchscreens during ACPI
SSDT generation (implemented in a subsequent commit).
BUG=b:121309055
TEST=tested with rest of patch train
Change-Id: Ie4c3b94594253ced6a875af78e6390cda8dcbc7d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71181
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add method variant_romstage_gpio_table() with empty weak implementation
to allow variants to override as needed for touchscreen power
sequencing (to be implemented in a subsequent commit). Call method
in romstage to program any GPIOs the variant may need to set.
TEST=tested with rest of patch train
Change-Id: Ib3c2a0e849006b7bf70cbd0bf6f32aa01ccf1bc4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71180
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Root Complex Event Collector Endpoint Association Extended
Capability is defined in section 7.9.10 of PCIe 5.0 spec.
Add its Extended Capability ID, association bitmap for RCiEPs
register, and RCEC associated bus numbers register.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I7bede8ed88304a2925e6e1e4128bcdd625ee0e53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Different PCHs have different definitions for registers. Here create
a lbg folder and move lbg specific codes to this folder so that we
can add new PCH code under xeon_sp folder.
* Create lbg folder and move lbg specific codes from pch.c to soc_pch.c
under lbg folder.
* Rename lewisburg_pch_gpio_defs.h to gpio_soc_defs.h and move to lbg
folder.
* Rename gpio.c to soc_gpio.c and move to lbg folder.
* Move pcr_ids.h to lbg folder.
* Move lbg specific codes from pmutil.c to soc_pmutil.c under lbg
folder.
* Create and revise makefile for files under lbg folder.
TEST=Can boot into OS on OCP Delta Lake.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I06555ed6612c632ea2ce1938d81781cd9348017a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There seem to be some recurring vague concerns about the alignment of
coreboot table entries. While the existing implementation has been
producing tables with a well-defined alignment (4 bytes) for a long
time, the code doesn't always make it very clear. This patch adds an
explicit constant to codify that alignment, assertions to check it after
each entry, and adds explicit padding to the few entry structures that
were relying on compiler padding to return a correct sizeof() value.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaeef29ef255047a855066469e03b5481812e5975
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70158
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
This patch avoids hardcoding to the `use_eisa_hids` variable instead
relying on the SoC config to choose if the SoC platform supports
EISA HID.
If any SoC platform has the support then the `use_eisa_hids` variable
would be set to `true` based on the selection of `DPTF_USE_EISA_HID`
config.
Note: Prior to Tiger Lake, all DPTF devices used 7-character EISA
IDs. If selected, the 7-character _HIDs will be emitted,
otherwise, it will use the "new" style, which are regular
8-character _HIDs.
Ideally, the platform prior to Tiger Lake would set `use_eisa_hids`
to `true` and platform posts that would set `use_eisa_hids` to
`false`.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I869bebc8e17c1e65979ca3431308d69771a34fa3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71110
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch makes the SoC specific callback code more readable by adding
`soc_` prefix into the `get_dptf_platform_info()`.
In nutshell this patch renames `get_dptf_platform_info()` to
`soc_get_dptf_platform_info()`.
TEST=Able to build Google/Rex without any compilation issue.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I27d6a146d5928e1742f82f85f51ad42656f46344
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
dapc_init flow is the same on MT8186, MT8188 and MT8195. So move this
function to common/devapc.c
TEST=emerge-corsola coreboot; emerge-cherry coreboot;
emerge-geralt coreboot
TEST=devapc log is shown as expected and the system boots to kernel
Change-Id: I979c3a3721a82d40c9e2db7fbe62e14a9bbd53d8
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71137
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
It's true that vbnv_udc_enable_flag() is called after vbnv_init()
(that's why the assertion was added). However, the former is called in
the ramstage, while the latter in verstage. This means that
vbnv_initialized will be false in ramstage, which leads
to the assertion failure:
[EMERG] ASSERTION ERROR: file 'src/security/vboot/vbnv.c', line 88
Since the ctx->nvdata will be restored in ramstage (by vb2api_reinit()),
simply remove the assertion. So, the patch drops assert call from
vbnv_udc_enable_flag() function.
TEST=Verify Rex system boots to OS without assert error.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I49022155239febd5c5be5cf2c5eca2019ca61c12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Select SOC_INTEL_RAPTORLAKE to force coreboot to use the RPL FSP headers
for FSP as kano is using a converged firmware image.
BUG=b:253337338
BRANCH=firmware-brya-14505.B
TEST=Cherry-pick Cq-Depends, then "FW_NAME=kano emerge-brya
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage",
disable hardware write protect and software write protect,
flash and boot kano in end-of-manufacturing mode to kernel.
Cq-Depend: chrome-internal:5246998, chromium:4119763
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Change-Id: I30ab7d829a6cb45b4e0cd38747501ba0eb6bd6cd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71175
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adapted from WIP (and now abandoned) patches CB:25334, 26308, 26309.
Update the nhlt_soc_add_*() methods for max98373, max98927, and rt5514
codecs to program the render and feedback slot numbers as appropriate.
TEST=boot Windows on google/eve, atlas, nocturne, and rammus. Verify
audio functional with both Google project campfire drivers as well as
coolstar's AVS audio drivers.
Change-Id: Ib8c6e24ba539e205bd5bbd856ecff43b2c016c2e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Adapted from WIP (and abandoned) patch CB:25334, this patch:
1. Ensures SSP endpoint InstanceId is 0
2. Adds capability_size parameter at the end of the nhlt
3. Adsd more config_type enum values to accommodate feedback stream
4. Programs virtual_slot values for max98373, max98927,
and rt5514 nhlt files
5. Adds NHLT feedback_config parameters
Default feedback configs are added here to the max98373, max98927, and
rt5514 codecs; in a follow-on patch, these will be overridden at the
board level.
TEST=tested with subsequent patch
Change-Id: I59285e332de09bb448b0d67ad56c72a208588d47
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Contrary to mc_ehl2, which this variant is based on, this board
doesn't contain the TI XIO2001 PCIe-to-PCI bridge, which makes the
attempts to modify the bridge's registers unnecessary.
Change-Id: I6597ceb78e4c790c08a0dfa9535dece33a8f95b8
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70854
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Switch from using ACPI "probed" flag to "detect" flag for all i2c
touchscreens and digitizers. This removes non-present devices from the
SSDT and relieves the OS of the burden of probing.
Test: build/boot Windows/Linux on various octopus variants, verify
touchscreens/digitizers functional, dump ACPI tables and verify only i2c
devices actually present on the board have entries in the SSDT.
Change-Id: I67c5bbae42e96ae21d37309e382b635321e6ef01
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63214
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIOs themselves are configured as level triggered, and the drivers
(both Linux and Windows) work better with LEVEL vs EDGE triggering.
TEST=tested with rest of patch train
Change-Id: I13bc6920a0dfaf769091b1764a7584902d1f85d6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63213
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For octopus variants with a touchscreen/digitizer, drive the enable and
reset GPIOs high in romstage, then disable the reset GPIOs in ramstage.
Where available, only set the GPIOs for SKUs which have a touchscreen.
This will allow coreboot to detect the presence of i2c touchscreens
during ACPI SSDT generation (implemented in a subsequent commit).
TEST=tested with rest of patch train
Change-Id: Ia725b4054069c0a4f60afd7e0bca6e2fd5fdcbba
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63212
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add method variant_romstage_gpio_table() with empty weak implementation
to allow variants to override as needed for touchscreen power
sequencing (to be implemented in a subsequent commit). Call method
in romstage to program any GPIOs the variant may need to set.
TEST=tested with rest of patch train
Change-Id: I4a8e11945ae64b000051989089e0ebae22896c6b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70905
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support to report previous PSP boot failure to verified boot. This
is required specifically on mainboards where the signed AMDFW blobs are
excluded from vboot verification.
BUG=b:242825052
TEST=Build Skyrim BIOS image and boot to OS in Skyrim. Corrupt either
one of SIGNED_AMDFW_A/B sections or both the sections to ensure that the
appropriate FW slot is chosen.
Cq-Depend: chromium:4064425
Change-Id: Iada0ec7c373db75765ba42cb531b16c2236b6cc3
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70382
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an SVC command to get the previous boot status. If there is any
pre-x86 boot failure in the previous boot cycle, PSP stores it in warm
reset persistent register and triggers a warm reset. PSP verstage on the
subsequent boot gets the previous boot status and reports any failure to
the vboot before a FW slot is selected.
BUG=b:242825052
TEST=Build Skyrim BIOS image and boot to OS in Skyrim. Trigger a failure
scenario by corrupting certain firmware blobs and observe that PSP
reports the failure boot status. On a normal boot, observed that PSP
reports successful boot.
Change-Id: I440deee560b72c80491bfdd7fda38a1c3a4299e5
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70381
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables building ChromeOS for mtlrvp.
Patch includes,
1. Add cros_gpios for mtlrvp
2. Add chrome OS configuration in Kconfig
3. Add Chromeos.c
BUG=b:224325352
TEST=Able to build with the patch and boot the mtlrvp platform with the
subsequent patches in the train (CB: 69886)
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Ia428941bd8269714c3edca6c7b0c2a3fbf08bd75
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70724
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Power resource for Bluetooth device is not configured correctly in the
device tree. Fix Bluetooth devicetree configuration.
BUG=b:262785310
TEST=Build Skyrim BIOS image and boot to OS. Ensure that the DUT is able
to connect to a Bluetooth headset.
Change-Id: Id980424349537be35860dec04cc823d419cefe2f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71068
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
smm_relocation_handler is run for each thread but IA32_SMRR_PHYS_BASE
and IA32_SMRR_PHYS_MASK are core scope, need to avoid writing the
same MSR that has been locked by another thread.
Tested=On OCP Crater Lake, rdmsr -a 0x1f3 can see all cores set the lock
bit.
Change-Id: I9cf5a6761c9a9e1578c6132ef83e288540d41176
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
This patch adds files required for ramstage and SMM.
1. Add file required for ramstage (mainboard.c)
2. Add smihandler.c for SMM
BUG=b:224325352
TEST=Able to build with the patch and boot the mtlrvp platform with the
subsequent patches in the train
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I377c4ff954a900c7b5193d7cab5554c6c02573ee
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70723
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch will initialize EC for mtlrvp which includes,
1. Add configuration (& choice) for CHROME_EC and INTEL_EC (WINDOWS_EC)
2. Add respective ACPI configuration
3. Add ec.c required for ramstage
4. Program EC ranges as part of devicetree.cb
5. Enable VBOOT in Kconfig
BUG=b:224325352
TEST=Able to build with the patch and boot the mtlrvp platform with
CHROME_EC using subsequent patches in the train
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Change-Id: I662d7f79050d35e152d97dc5c2118a4af56223bc
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66101
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id 2047412:
2022-11-29 17:52:03 +0800 - (Elkhart Lake MR5 FSP)
to commit id 6f2f17f:
2022-12-14 12:36:46 -0700 - (Deleted old Release Notes and Integration Guides)
This brings in 6 new commits:
6f2f17f Deleted old Release Notes and Integration Guides
3868f73 Updated for SGXFlex - New UPDs available
a649f0f Whitley FSP 2.2.0.3A
f99be62 Merge branch 'master' of https://github.com/intel/FSP
1787bc7 Updated IoT ADL-PS MR1 (3404_00) FSP
1e833b0 Elkhart Lake MR5 FSP
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I1dbd85ef06b057305428d42dd6cd6de0f2618439
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Updating from commit id e8efa5d:
2022-05-30 15:47:07 +0530 - (sc7180/boot: Update qclib blobs binaries from 44 to 46)
to commit id 33cc4f2:
2022-10-26 14:21:20 +0530 - (sc7280/qtiseclib: Update qtiseclib blobs binaries and release notes from 63 to 69)
This brings in 10 new commits:
33cc4f2 sc7280/qtiseclib: Update qtiseclib blobs binaries and release notes from 63 to 69
6c82214 sc7180/boot: Update qclib blobs binaries from 48 to 50
e570e02 Reland "sc7280/cpucp: Update cpucp blobs binaries and release notes version from 060 to 063"
6206ab8 Revert "sc7280/cpucp: Update cpucp blobs binaries and release notes version from 060 to 063"
82bbf78 sc7280/aop: Update aop blobs binaries and release notes version from 379 to 410
e3a760d sc7180/boot: Update qclib blobs binaries from 46 to 48
741abaa sc7280/boot/shrm: Update qclib blobs binaries from 30 to 35
436cb87 sc7280/cpucp: Update cpucp blobs binaries and release notes version from 060 to 063
3f44ba0 sc7180/qtiseclib: Update qtiseclib blobs binaries and release notes update from 044 to 050
eef51c6 sc7280/qcsec: Update qcsec blobs binaries and release notes for 27
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I72b91e384b74e4e44864ef5f29be78ebac4262fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This patch fixes a hidden issue present inside FSP-S while coreboot
decides to skip performing MP initialization by overriding FSP-S UPDs
as below:
1. CpuMpPpi ------> Passing `NULL` as coreboot assume FSP don't need
to use coreboot wrapper for performing any
operation over APs.
2. SkipMpInit -----> Set `1` to let FSP know that coreboot decided
to skip FSP running CPU feature programming.
Unfortunately, the assumption of coreboot is not aligned with FSP when
it comes to the behaviour of `CpuMpPpi` UPD. FSP assumes ownership of
the APs (Application Processors) upon passing `NULL` pointer to the
`CpuMpPpi` FSP-S UPD.
FSP-S creates its own infrastructure code after seeing the CpuMpPpi
UPD is set to `NULL`. FSP requires the CpuMpPei module, file name
`UefiCpuPkg/CpuMpPei/CpuMpPei.c`, function name `InitializeCpuMpWorker`
to perform those additional initialization which is not relevant for
the coreboot upon selecting the SkipMpInit UPD to 1 (a.k.a avoid
running CPU feature programming on APs).
Additionally, FSP-S binary size has increased by ~30KB (irrespective of
being compressed) with the inclusion of the CpuMpPei module, which is
eventually not meaningful for coreboot.
Hence, this patch selects `MP_SERVICES_PPI_V2_NOOP` config
unconditionally to ensure pass a valid pointer to the `CpuMpPpi` UPD
and avoid APs getting hijacked by FSP while coreboot decides to set
SkipMpInit UPD.
Ideally, FSP should have avoided all AP related operations when
coreboot requested FSP to skip MP init by overriding required UPDs.
TEST=Able to drop CpuMpPei Module from FSP and boot to Chrome OS on
Google/Redrix, Kano, Taeko devices with SkipMpInit=1.
Without this patch:
Here is the CPU AP logs coming from the EDK2 (open-source)
[UefiCpuPkg/CpuMpPei/CpuMpPei.c] when coreboot sets `NULL` to the
CpuMpPpi UPD.
[SPEW ] Loading PEIM EDADEB9D-DDBA-48BD-9D22-C1C169C8C5C6
[SPEW ] Loading PEIM at 0x00076F9A000 EntryPoint=0x00076FA24E2
CpuMpPei.efi PROGRESS CODE: V03020002 I0
[SPEW ] Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
[SPEW ] Notify: PPI Guid: F894643D-C449-42D1-8EA8-85BDD8C65BDE,
Peim notify entry point: 76FA0239
AP Loop Mode is 2
GetMicrocodePatchInfoFromHob: Microcode patch cache HOB is not found.
CPU[0000]: Microcode revision = 00000000, expected = 00000000
[SPEW ] Register PPI Notify: 8F9D4825-797D-48FC-8471-845025792EF6
Does not find any stored CPU BIST information from PPI!
APICID - 0x00000000, BIST - 0x00000000
[SPEW ] Install PPI: 9E9F374B-8F16-4230-9824-5846EE766A97
[SPEW ] Install PPI: 5CB9CB3D-31A4-480C-9498-29D269BACFBA
[SPEW ] Install PPI: EE16160A-E8BE-47A6-820A-C6900DB0250A
PROGRESS CODE: V03020003 I0
With this patch:
No instance of `CpuMpPei` has been found in the AP UART log with FSP
debug enabled.
This patch is backported from
commit 8409f156d5 (soc/intel/alderlake:
Remove dependency of FSP-S CpuMpPei Module)
Change-Id: I7d9fb37ca1cd4bf325edc951ee7293e459fa2ea4
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70600
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
The details about how the CPU multiprocessor init (MP) has migrated
from coreboot to FSP can be found in
https://doc.coreboot.org/soc/intel/mp_init/mp_init.html.
The major reason behind this migration is to support the Intel
proprietary and restricted CPU feature programming which can't be
performed if coreboot sets the BIOS_DONE or BIOS Reset CPL as part
of coreboot MP Init flow (prior to calling FSP-S). Hence, the new
flow introduced with Tiger Lake platform forced having monolithic
MP Init peformed by FSP (using coreboot MP PPI wrapper code).
The last 3-4 years of FSP doing MP Init has demonstrated ample
issues during platform bringup which is specific to UEFI MP Service
implementation and not relevant to open source coreboot. This new
flow makes the debug and validation aspect complicated where
any FSP MP Init code changes should have been validated with coreboot
MP PPI wrapper else might cause some failure, unfortunately,
the validation commitment has never been met, hence, issue debugging
is the only solution that remains in practice.
Most importantly, the restricted feature programming which demanded
closed source MP Init (for features like SGX and C6DRAM) has never
been enabled in coreboot (starting with Alder Lake, the SGX feature
has been dropped).
This patch attempts to decouple FSP-S doing MP Init from the rest
of the FSP-S silicon init and introduces 2nd MultiPhase SI init
which allows bootloader to perform the mandatory SoC programming
before FSP-S has done with PM programming (a.k.a set the reset CPL).
The core/uncore BWG suggests the minimum SoC programming before
BIOS Reset CPL is set. coreboot uses the MultiPhaseSI Init Index 2
to perform the required CPU programming before enabling the BIOS
Reset CPL.
This implementation would allow us to get rid of FSP running CPU
feature programming and additionally make several EDK2 MP service
modules optional (those are packed to create FSP-S blob).
In summary, this change would allow coreboot to utilize open source
MP init without running into FSP-S related code blocks.
Note: At present, Intel Meteor Lake FSP doesn't have support for
MultiPhase SI Init, Index 2 (submitted a FSP code changes over
chrome-internal to enable this feature to decouple MP Init from
FSP-S init).
This patch is backported from
commit b6c3a0325b (soc/intel/alderlake:
Implement MultiPhase SI Init Index 2 callback).
BUG=b:233199592
TEST=Build and boot google/taeko to ChromeOS.
Perform several thousands cycles of suspend test and power cycle
without running into any issue.
Change-Id: I2ea1a8bb2b142e39c2bc9d248b7fd0041366c0db
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70558
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch implements mps2_noop_get_number_of_processors() API with
minimal information required for Intel MTL FSP to utilise the
`MP_SERVICES_PPI_V2_NOOP` config.
The major difference between Intel ADL and MTL FSP in terms of doing
CPU feature programming aka utilizing MP PPI wrapper code is that,
starting with MTL, FSP has dropped the `SkipMpInit` UPD.
It means now, coreboot doesn't have any way to skip FSP doing MP Init
operation. But during ADL, coreboot had introduced the
MP_SERVICES_PPI_V2_NOOP config that is used to skip FSP about
actually running any CPU feature programming on APs.
The idea is to use the same config even in MTL to provide only the
must have information (to bypass any assert in FSP during debug image)
to FSP.
Passing `FSP_UNSUPPORTED` from mps2_noop_get_number_of_processors()
results in `assert` while compiling FSP in debug mode hence,
implementing the function to pass only the information about BSP being
the active processor along with passing `FSP_SUCCESS` (eventually it
makes FSP happy and doesn't run into any issue in debug and/or release
mode).
TEST=Able to build and boot Google/Rex and Google/Kano while
coreboot skip calling into FSP for doing MP init.
Change-Id: I75d7e151699782210e86be564b0055d572cacc3f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70555
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Remove flag in VBTs for 'Use fixed resolution at boot' to allow FSP/GOP
display init to use native panel resolution instead.
TEST=build/boot multiple google/octopus variants with edk2 payload,
verify boot logo not distorted/stretched.
Change-Id: Ia31ff28379282619dfa22a955bee1a768bb54bb8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Boot menus are too small at native 4K res on some panels, so
set fixed display resolution to 1920x1090p
TEST=build/boot KOHAKU with 4K display, verify boot menu text legible.
Change-Id: I82563c83de7ab302151f60d86b8a6824330d03ea
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
coreboot has been keeping a mirror of all the toolchain packages used
for releases for quite a while now. This adds an option to fetch the
packages from the coreboot mirror directly to buildgcc.
This can help with both our releases and when one of the various
servers experiences interruptions or changes a path.
To do this, the URL and filename needed to be split apart, which led to
quite a few changes in the buildgcc script.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7df58dca152e7bfe9fde34d290e05b52515b20d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70053
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
It's hidden behind the configuration option `CONFIG_ROMSTAGE_LIBHWBASE'.
This also adds some glue code to use the coreboot console for debug
output and our monotonic timer framework as timer backend.
Running Ada code in romstage and more particular libhwbase brings a few
challenges as global initialized variables are not supported in
Cache-As-Ram mode.
1. The libhwbase dynamic mmio driver implementation makes the Gnat
compiler generate some global initialized variables.
For this reason, when compiled for romstage or for romstage and
ramstage the static mmio driver is enforced (`HWBASE_STATIC_MMIO').
2. The Gnat compiler generates elaboration functions to initialize
program data at runtime. These elaboration functions are called by
the romstage_adainit() function.
The data references symbols suffixed by `_E'. Even though these
symbols, at compilation time, do not contain any data and are
filled with zeros, the Gnat compiler installs them in the .data
section.
Since these symbols are actually filled with zeros, it is safe to
install them in the .bss section.
cf. https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/elaboration_order_handling_in_gnat.html#elaboration-code
This patch requires the libhwbase
https://review.coreboot.org/c/libhwbase/+/69854 CL.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=libhwbae compiles for romstage and loads successfully
Change-Id: I670249d33506e886a683e55d1589cb2bf9b16aa3
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70275
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If selected, libgnat is linked into romstage. In addition, a call to
romstage_adainit() is added to support Ada program data
initialization.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=Ada code compiles for romstage and loads successfully
Change-Id: I74f0460f6b14fde2b4bd6391e1782b2e5b217707
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70274
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Hexdump command is not available in coreboot-sdk. Replace it with
equivalent implementation using commands that are present in the
container.
TEST=Passed "VP46XX" as prefix variable and it produced the same
crc32 result before and after the change.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Icad93933335b8c5ebd8fee74cc9aaed36bb56482
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
According to Intel doc#630774, BIOS should clear Host Interrupt Status
if it has read all the slots of the message from the ME circular buffer.
Since this is not found in client ME document, add a Kconfig
SOC_INTEL_CSE_SERVER_SKU that only clears interrupt status for Server
ME SKU.
On SPR-SP, if mainboard calls get_me_fw_version via HECI-1, with the
change can avoid seeing below Linux warning during boot with Linux
v5.12:
[ 17.868929] irq 16: nobody cared (try booting with the "irqpoll" option)
[ 17.883819] CPU: 10 PID: 0 Comm: swapper/10 Not tainted 5.12.0
[ 17.902412] Hardware name: Wiwynn Crater Lake EVT2/Crater Lake-Class1
[ 17.922327] Call Trace:
[ 17.927780] <IRQ>
[ 17.932253] dump_stack+0x64/0x7c
[ 17.939640] __report_bad_irq+0x37/0xb1
[ 17.948206] note_interrupt.cold.11+0xa/0x63
[ 17.957713] handle_irq_event_percpu+0x6a/0x80
[ 17.967626] handle_irq_event+0x2a/0x50
[ 17.976163] handle_fasteoi_irq+0x9e/0x140
[ 17.985305] __common_interrupt+0x38/0x90
[ 17.994255] common_interrupt+0x7a/0xa0
[ 18.002821] </IRQ>
[ 18.007514] asm_common_interrupt+0x1e/0x40
Change-Id: I1cf21112870e53a11134d43e461b735ead239717
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
In some cases, fw_config is used for ids like sar_id, sku_id etc.
To avoid calling fw_config_probe over and over, hence provide the
method to return the value then caller can use the switch case
instead of if else statement.
TEST=get fw_config field value on nivviks.
[INFO ] fw_config get field name=DB_USB, mask=0x3, shift=0, value =0x1
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Iae89668e8fe7322d5a4dcbf88a97d7ed36619af5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70745
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
With commit 34a7e66faa ("util/cbfstool: Add a new mechanism to
provide a memory map"), builds are failing on 32-bit platforms with:
../cbfstool/cbfstool.c:397:30: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
printf("Image SIZE %lu\n", image_size);
~~~ ^~~~~~~~~~
%zu
Change the format specifier from %lu to %zu.
TEST=`emerge-cherry coreboot-utils` now succeeds
Change-Id: I3602f57cf91c330122019bfa921faef6deb2b4ce
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70848
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add a new mc_ehl variant, which is based on mc_ehl2 implementation.
This patch uses a copy of mc_ehl2 with changes only in naming
as a starting point for the new mc_ehl3 variant.
Follow-up patches will introduce the functional changes against
mc_ehl3.
Change-Id: Ie8c18b4f16d88b175ce576c2ef4c2e6ee0b4c306
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70688
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
With commit 0110e1abe0 ("util/genbuild_h: Update printf %d to %s for
sh compatability"), the ChromeOS coreboot build is failing with:
In file included from src/lib/version.c:4:
/build/nissa/tmp/portage/sys-boot/coreboot-0.0.1-r5473/work/build/nivviks/build.h:10:32: error: 'v1' undeclared here (not in a function)
10 | #define COREBOOT_MAJOR_VERSION v1
| ^~
src/lib/version.c:35:46: note: in expansion of macro 'COREBOOT_MAJOR_VERSION'
35 | const unsigned int coreboot_major_revision = COREBOOT_MAJOR_VERSION;
| ^~~~~~~~~~~~~~~~~~~~~~
/build/nissa/tmp/portage/sys-boot/coreboot-0.0.1-r5473/work/build/nivviks/build.h:11:32: error: 'v9308' undeclared here (not in a function)
11 | #define COREBOOT_MINOR_VERSION v9308
| ^~~~~
src/lib/version.c:36:46: note: in expansion of macro 'COREBOOT_MINOR_VERSION'
36 | const unsigned int coreboot_minor_revision = COREBOOT_MINOR_VERSION;
| ^~~~~~~~~~~~~~~~~~~~~~
This is because the ChromeOS coreboot repo has a tag which is not in the
expected <major>.<minor> format:
$ git tag
v1.9308_26_0.0.22
Change genbuild_h.sh to only use the version from `git describe` if it's
in the expected <major>.<minor> format.
TEST=ChromeOS coreboot build now succeeds, with versions set to 0:
#define COREBOOT_MAJOR_VERSION 0
#define COREBOOT_MINOR_VERSION 0
Building upstream coreboot, the versions are still set correctly:
#define COREBOOT_MAJOR_VERSION 4
#define COREBOOT_MINOR_VERSION 18
Change-Id: I81b2317a83cdec4cc2aad60af2990e5e3f4ad694
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Usha P <usha.p@intel.com>
On nissa, sending EOP late improves boot time by about 57ms.
Before (SOC_INTEL_CSE_SEND_EOP_EARLY):
943:after sending EOP to ME 931,206 (58,431)
943:after sending EOP to ME 932,911 (58,427)
943:after sending EOP to ME 930,908 (58,429)
943:after sending EOP to ME 941,357 (61,748)
943:after sending EOP to ME 933,289 (62,050)
943:after sending EOP to ME 939,578 (62,453)
943:after sending EOP to ME 932,491 (62,050)
943:after sending EOP to ME 929,693 (62,655)
943:after sending EOP to ME 942,247 (62,654)
943:after sending EOP to ME 936,984 (61,751)
After (SOC_INTEL_CSE_SEND_EOP_LATE):
943:after sending EOP to ME 1,107,816 (3,498)
943:after sending EOP to ME 1,053,286 (25,212)
943:after sending EOP to ME 1,124,095 (3,511)
943:after sending EOP to ME 1,098,591 (3,498)
943:after sending EOP to ME 1,107,772 (3,499)
943:after sending EOP to ME 1,080,008 (45,969)
943:after sending EOP to ME 1,081,754 (8,024)
943:after sending EOP to ME 1,109,193 (4,102)
943:after sending EOP to ME 1,088,866 (4,201)
943:after sending EOP to ME 1,081,684 (4,203)
BUG=b:247902068
TEST=EOP time is improved on nissa (measurements above).
Change-Id: I2389831b4ab62f247193b5b0c5ec201e12eaa3db
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70849
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Utilities like kconfig/conf now will be built inside tests build tree.
It will eliminate possible colisions of target names when using test
framework in more than one place (see CB:70110)
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I4c1eb901c921f4ec6ee8985b154362153c5fd0e7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70359
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch allows for linking selected files with system libc. This
allows for creating libraries interacting with filesystem, standard I/O
and other parts of system. Until now it was only possible using CMocka
proxy functions or functions not masked by code under test.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I652362ba61a25e974d706357fc36479ccee763e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Increase the default linear framebuffer max height/width for desktops
so that native display resolution works properly on 2160p and 1440p
ultrawide displays.
TEST=build/boot google/fizz, verify libgfxinit display init works
properly on 3440x1440p and 3840x2160p displays.
Change-Id: I95a1f1275a4faea195b73997c648023119807958
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70369
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The original value of the `DevIntConfigPtr` is unknown, and there's no
way to be absolutely certain that it actually points to usable memory.
Instead of copying the data, update the pointer's address to reference
the global variable directly. It is assumed that FSP does not write to
the memory pointed by `DevIntConfigPtr`. Confirming this assumption is
pointless; one might as well reimplement FSP instead.
Change-Id: I90594cc09e3fa2aef98658441c323a44a869635b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65217
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
This will help to integrate RO SPL table in RO partitions such that it
is used before PSP verstage is loaded. After PSP verstage, SPL table in
RW partition gets used.
BUG=b:243470283
TEST=Build Skyrim BIOS image and boot to OS.
Change-Id: Ic2061f66381d7e9a8018e6f28aa0bc2ca6010f6f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70777
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To support an RPL SKU on lisbon, lisbon must use the FSP for RPL.
Select SOC_INTEL_RAPTORLAKE for lisbon so that it will use the RPL
FSP headers for lisbon.
BUG=b:246657849
BRANCH=firmware-brya-14505.B
TEST=FW_NAME=lisbon emerge-brask intel-rplfsp
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage
flash and boot lisbon to kernel.
Signed-off-by: Kevin Chiu <kevin.chiu.17802@gmail.com>
Change-Id: Ie60c357ef0a2af2fec90df4a54e56f51ceb927d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Clang generates R_X86_64_32S symbols that get truncated.
TESTED:
- prodrive/hermes boots with GCC and clang
- MTRR are properly cleared (tested by filling in both
MTRR_FIX_64K_00000 and MTRR_FIX_4K_F8000 before clearing)
Change-Id: I6a5139f7029b6f35b44377f105dded06f6d9cbf9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Implement native USB initialisation for Lynx Point. This is only needed
when MRC.bin is not used.
TO DO: Figure out how to deal with the FIXME's and TODO's lying around.
Change-Id: Ie0fbeeca7b1ca1557173772d733fd2fa27703373
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64179
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Implement native DMI init for Haswell and Lynx Point. This is only
needed on non-ULT platforms, and only when MRC.bin is not used.
TEST=Verify DMI initialises correctly on Asrock B85M Pro4.
Change-Id: I5fb1a2adc4ffbf0ebbf0d2d3a444055c53765faa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There are two ways to control backlight in geralt:
1. MIPI/eDP panel => control backlight via the GPIOs.
(`backlight chip enable` and `PWM dimming control`)
2. eDP OLED panel => enable backlight via `backlight chip enable` and
control dimming over AUX.
For MIPI/eDP panels(#1), both "backlight enable" and "PWM control" GPIOs
will be passed from coreboot. For eDP OLED panel(#2), only the
"backlight enable" GPIO will be passed. If depthcharge successfully gets
the GPIOs, it will use them to control backlight.
BUG=b:244208960
TEST=test firmware display pass for eDP and MIPI panels on MT8188 EVB
Change-Id: I866fa219722241008e2b0d566b29edf2f6d9321f
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70744
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
dw_i2c_soc_dev_to_bus will return -1 if it failed to find an I2C bus
number for a device. In this case return -1 instead of implicitly
casting the -1 to an unsigned int and passing that as bus number to
dw_i2c_transfer. The dw_i2c_base_address call inside _dw_i2c_transfer
already ended up handling this error case correctly, but better handle
the error more directly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06b6005cee0c5c43855cb5b388a9911fc286c984
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70828
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
If the temporary nvdata storage inside the vboot context is already
initialized then return immediately without reinitializing from the
backup NV storage. This allows vbnv_init to be called more than once.
Also the check to enable USB Device Controller (UDC) happens after
NVdata is initialized. Hence the nvdata in vboot context can be used
instead of reading from the backup storage again.
BUG=b:242825052
TEST=Build Skyrim BIOS image and boot to OS in Skyrim.
Change-Id: Id72709e2fc3fe6a12ee96df8df25e55cf11e50a7
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Updating from commit id 148e5b83:
Makefile: Fix and simplify the RUNTEST test wrapper
to commit id 196b0843:
create_new_keys: use single AP RO Verification root key pair
This brings in 30 new commits.
Change-Id: Iedfc6cf0ff2dc1913a7a41a4302dc1951abf8a8a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The calculation for mem_chip_info_total_density_bytes() may already
overflow in the intermediate 32-bit calculations before being assigned
to the 64-bit result variable. Fix that.
Fixes Coverity issue: CID 1501510
BRANCH=corsola
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I73da014c953381974c6ede2b17586b68675bde2d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Improve the eSPI pin configuration setup so that a failure in there
won't call die() and stop booting at this point, but return an error to
the caller so that the rest of the eSPI configuration will be skipped.
This will prevent an early boot failure if the EC is missing or the eSPI
interface is in a non-functional state. Also slightly shorten the
function names so that the code still fits into 96 chars.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ice2d3a791d6a464eff4fb69d02aeca0bfe580be2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70730
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Test framework can be used as a base for other test-like utilities - for
example look at screenshoot utility in depthcharge. Sometimes CMocka is
not required and even makes things problematic. Thanks to this patch one
can set -no_test_framework parameter to instruct framework not to
include and link selected test against CMocka library.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I01dc7c6c50e6ae2f7f71bd6752c2d5f2cc7c3cdc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Drops the `FIXME` comment and relevant code as this patch enables
VMX and VTD.
This patch also fixes the problem of additional reboot on every warm
boot due to overriding the CPU soft-strap.
TEST=No extra reboot seen while issuing warm reset from kernel
console.
without this patch:
950:calling FspMemoryInit 1,225,259 (20,537)
951:returning from FspMemoryInit 10,334,707 (9, 109,447)
with this patch:
950:calling FspMemoryInit 1,225,259 (20,537)
951:returning from FspMemoryInit 1,334,707 (109,447)
Change-Id: Ib130698e7255876c5a12abc93dd7d8a34dfae968
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70553
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With 1ms delay, reset is de-asserted too soon, before power is fully
up, causing a glitch to the reset signal. The issue is resolved with
4ms delay.
TEST=tested on dratini device and observed the issue is resolved.
BUG=b:260253945
Change-Id: I5c3edbc6ac90d5042c2d3c5b01573d4bb1ea676d
Signed-off-by: Eran Mitrani <mitrani@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70666
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The device tree documentation was promoting using a GPIO wake event and
a GPE wake event. We should only ever have one. This wasn't actually
causing a problem because the wake bit was set on the `irq` property,
but the IO-APIC can't actually wake the system, so it was a no-op.
This change fixes up the markdown so it's formatted correctly, and also
adds a section explaining what the different wake configurations are.
BUG=b:243700486
TEST=mdformat
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifcdbd5371408784bf9b81c1ade90263de8c60e0f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67385
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This updates a number of things:
- Move the cache directory under the .local directory
- Reformat & clean up with perltidy. Add the perltidy command line.
- Add username and email aliases to clean up duplicates and unknown
email addresses.
- Use full length commit IDs
- Collect patch commenters
- Check variables before using them as key values
- Ignore patch submit time, just collect the date
- Get stats about large patches
- Format the output better
Example output:
Statistics from commit c35f281934 to commit f8fbf0917c
Patch, Date, Owner, Author, Submitter, Inserted lines, Deleted lines, Subject, Reviewers, Commenters
"f8fbf0917c722378454b07c2e8ec1a3f87b324ae", 2022/12/10, Frank Chu, Frank Chu, Martin Roth, 22, 1, "mb/google/brya/var/marasov: Change FSP board type to Type3", "Frank Chu, Eric Lai" , "-"
"5778e06771627a5541ca2b137e783f47257f05ec", 2022/12/10, Dinesh Gehlot, Dinesh Gehlot, Subrata Banik, 30, 1, "soc/intel/meteorlake: Drop casts around `soc_read_pmc_base()`", "Kapil Porwal, Elyes Haouas" , "Subrata Banik"
"ed8bdefcdf6c19258febb9931d1e8eb12b958bcc", 2022/12/10, Jamie Ryu, Jamie Ryu, Felix Held, 76, 3, "mb/intel/mtlrvp: Add MTL-P RVP board ids", "Usha P,
Sridhar Siricilla, Eric Lai, Subrata Banik" , "Eric Lai, Subrata Banik, Harsha B R, Angel Pons"
- Total Commits: 985
- Average Commits per day: 17.85
- Total lines added: 61475
- Average lines added per commit: 62.41
- Number of patches adding more than 100 lines: 49
- Average lines added per small commit: 37.82
- Total lines removed: 758022
- Average lines removed per commit: 769.57
- Total difference between added and removed: -696547
=== Authors - Number of commits ===
Author ,Ptchs ,Revws , Cmnts , Sbmts , Email , Prcnt, Last commit ,
Earliest_commit
Elyes Haouas , 126 , 90 , 28 , 0 , ehaouas@noos.fr ,12.79%, 2022/12/10 , 2022/10/17
Arthur Heymans , 107 , 99 , 28 , 40 , arthur@aheymans.xyz ,10.86%, 2022/12/10 , 2022/10/17
=== Authors - Lines added ===
Martin Roth , 10103, 16.434%
Kyösti Mälkki , 6044, 9.832%
Arthur Heymans , 3314, 5.391%
=== Authors - Lines removed ===
Arthur Heymans , -741944, 97.879%
Felix Held , -3031, 0.400%
Kyösti Mälkki , -1680, 0.222%
=== Reviewers - Number of patches reviewed ===
Angel Pons , 272, 27.614%
Eric Lai , 201, 20.406%
Felix Held , 106, 10.761%
=== Submitters - Number of patches submitted ===
Name , #, total%, Own, own%, Other, other%
Felix Held , 482, 48.934%, 56, 11.62%, 426, 88.38%
Martin Roth , 179, 18.173%, 42, 23.46%, 137, 76.54%
Subrata Banik , 54, 5.482%, 31, 57.41%, 23, 42.59%
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie1694116ab36ca4db25d13935adadca10e50068f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Now that gpio.h will only include the defines in the IASL case, gpio.h
can be included instead of soc/gpio.h in the files that will be directly
or indirectly included in the DSDT.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifc8d8fe4e4148e5b5628f32778368d1fc7f44e5b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70510
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When gpio.h gets directly or indirectly included in the DSDT ar an
assembly file, everything but the preprocessor defines for the GPIOs
shouldn't be included to keep IASL or the assembler happy.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I046ed87d3947ba5b1fcd0bdd4cffcda57bc13404
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70509
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 nivviks and yaviks.
BUG=b:259716145
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
Change-Id: Iaddb24580bda77df0c70ff58eb098213f8b509ad
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.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. Allow adding
DmaProperty to the _DSD of the ISH device. This will result in the
kernel marking the device as untrusted.
BUG=b:249846505
TEST=Check SSDT is correct, and kernel detects the DmaProperty and
firmware-name properties.
SSDT entry on yaviks with both add_acpi_dma_property and firmware_name
set in devictree:
Scope (\_SB.PCI0.ISHB)
{
Name (_DSD, Package (0x04) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"firmware-name",
"adl_ish_lite.bin"
}
},
ToUUID ("70d24161-6dd5-4c9e-8070-705531292865"),
Package (0x01)
{
Package (0x02)
{
"DmaProperty",
One
}
}
})
}
Change-Id: Ie1539fc757e72e995e98c3ecf83e705e3bede8c0
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch skips sending CONN IPC command to PMC if system is resuming
from S3.
Sending CONN IPC command as part of `tcss_configure_dp_mode()` function
results into ERROR while system is resuming from S3.
Additionally, skip `configure_aux_bias_pads()` during S3 resume.
BUG=b:260984500
TEST=Able to test on Google/Rex.
Without this patch:
[ERROR] pmc_send_ipc_cmd status: fatal
[ERROR] Port 1 connect request failed
[SPEW ] [TCSS] TcssInit() - End
With this patch:
No error seen during S3 resume.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I1dab7dc8b4ad76ca0c9630456803c1b9a320fe40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70222
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tranferring a bit to DC through Skuid to update the regulator
node in order to support pro and non-pro
BUG=b:248187555
TEST=Validate boards are detected correctly on PRO and NON_PRO SKUs
Signed-off-by: Sudheer Kumar Amrabadi <quic_samrabad@quicinc.com>
Change-Id: Iec392c03c2e2c79d20b1fcb79236ca9e048bfd07
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68385
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The API socinfo_pro_part() returns 1 for Pro and 0 for NON_PRO SKUs. To
reduce the binary footprint for chipinfo structure, change its members
range from uint32_t to uint16_t. Add helper functions for reading and
matching jtagid. Modified socinfo_modem_supported() API to utilize
helper functions.
BUG=b:248187555
TEST=Validate boards are detected correctly on PRO and NON_PRO SKUs
Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
Change-Id: Id9f23696384a6c1a89000292eafebd8a16c273ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68384
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When printing a date, genbuild_h is printing it as two digits, using
a leading zero if the value is below 10.
The shells like bash, dash, etc don't fully import the numbers 08 and
09 when using the printf conversion specifier %d. They apparently
interpret the numbers as octal and only import the leading 0, dropping
the 8 or 9. This isn't an issue for 01 to 07, because those are valid
octal numbers, so %d prints them without an issue. Because 08 and 09
are not valid octal, various shells return different errors:
Example shell returns for 'printf "%d" 08':
bash: printf: 08: invalid octal number
dash: printf: 08: not completely converted
fish: 008: value not completely converted
yash: printf: `08' is not a valid integer
sash: printf: 08: not completely converted
To prevent this, just print all of the values as strings.
zsh just seems to ignore the possibility of the value being octal
and prints the value as a single digit 0-9.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I97b6aa74d74379f6bdc1f0fceecc8002cc36ca09
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70478
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 4c3749884d ("cpu/x86/mtrr: Print cpu index number when set up
MTRRs for BSP/APs") added the CPU index number to some prints, but used
%x as format specifier. The cpu_index() call however has a return type
of unsigned long, so %lx needs to be used instead. For consistency, also
change the type of the cpu_idx local variable in commit_fixed_mtrrs to
unsigned long and adjust the printk format specifier accordingly.
TEST=The code builds again on my computer
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4b68f8355932b2b75db5f453a0a735185b24b02f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70664
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The size of a pointer changes between a 32 and 64 bit coreboot build. In
order to be able to use a 32 bit FSP in a 64 bit coreboot build, change
the pointer in the UPDs to a uint32_t to always have a 32 bit field in
the UPD for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5db2587ff74432a0ce1805d8d7ae76d650693eea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Both eDP and MIPI interfaces are supported in geralt project, so we can
initialize the different displays according to the panel ID.
This patch also generalizes the display initialization. So
`configure_edp_panel_backlight` and `power_on_edp_panel` can be removed.
BUG=b:244208960
TEST=test firmware display pass for MIPI panel on MT8188 EVB.
Change-Id: I7ae9318f56c70446516e197635acaffb8197ab53
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70406
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both eDP and MIPI interfaces are supported in geralt project. Therefore,
we put the eDP panel data in panel_geralt.c to have the consistent
interface `get_active_panel` function.
BUG=b:244208960
TEST=emerge-geralt coreboot
Change-Id: Ib35b3cab31bae4109b9715242201425580339536
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70405
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are eDP and MIPI panels supported in geralt. We put the panels'
specified functions - `power_on()` and `configure_panel_backlight()` in
panel_geralt.c. Also provide the common interface `get_active_panel()`
in panel.c to generalize the display initialization. Since each board
may support a different set of MIPI panels, we put the MIPI data in a
separate file panel_geralt.c.
BUG=b:244208960
TEST=emerge-geralt coreboot
Change-Id: Ie928759e020a916f29f0364201a3cf202dc512c3
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The EN_PP3300_SD gpio (GPP_H13) was configured as a no-connect, but
should be configured as an output.
This change configures GPP_H13 on brya0 and skolas to be an output.
BUG=b:261901759
BRANCH=firmware-brya-14505.B
TEST="emerge-brya coreboot chromeos-bootimage" and verify skolas boots.
Change-Id: Ia3f01e877a5fea3af9a6e746523ed395f3af3b8a
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70512
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Changes include:
- FirmwareVersionInfoHob.h is removed to use new header file
FirmwareVersionInfo.h.
BUG=b:260183604
TEST=Verified Google/Rex0 build with all the patch in relation chain
and verified the version output prints no junk data.
Signed-off-by: Saurabh Mishra <mishra.saurabh@intel.com>
Change-Id: I06fd89f201e9e4100524e58033086327ad4ffc7b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Changes include:
- Add config for Meteor Lake SoC to select FirmwareVersionInfo.h
using 'DISPLAY_FSP_VERSION_INFO_2'
BUG=b:260183604
TEST=Verified Google/Rex0 build with all the patch in relation chain
and verified the version output prints no junk data.
Signed-off-by: Saurabh Mishra <mishra.saurabh@intel.com>
Change-Id: I789db9d280c45639eca6ceafea65b96a93a395cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Introduce the `USE_NATIVE_RAMINIT` Kconfig option, which should allow
booting coreboot on Haswell mainboards without the need of the closed
source MRC.bin. For now, this option does not work at all; the needed
magic will be implemented in subsequent commits. Add a config file to
make sure the newly-introduced option gets build-tested.
Change-Id: I46c77586f9b5771624082e07c60c205e578edd8e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64176
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
BUG=b:259716145
TEST=Dump SSDT and see that _PRW and _DSD for CNVi device contains
the value from the devicetree on google/redrix.
Before:
Scope (\_SB.PCI0.WFA3)
{
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x6D,
0x03
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("70d24161-6dd5-4c9e-8070-705531292865"),
Package (0x01)
{
Package (0x02)
{
"DmaProperty",
One
}
}
})
...
}
After:
Scope (\_SB.PCI0.CNVW)
{
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x6D,
0x03
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("70d24161-6dd5-4c9e-8070-705531292865"),
Package (0x01)
{
Package (0x02)
{
"DmaProperty",
One
}
}
})
...
}
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Ia4ffedcb53afe350694eb03a144d12f714190cc4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70447
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The directory src/vendorcode/mediatek/mt8195/dramc/include never
existed, and was added in commit b0b8dc37
(vendor/mediatek: Add MT8195 dram initialization code).
Found using 'Wmissing-include-dirs' command option.
Change-Id: Iec349e816a1b646f1ea5fa1db13e05a78ffe1af8
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70464
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ChromeOS build system performs ASAN builds by appending
-fsanitize=address to CFLAGS and LDFLAGS. Currently, the ASAN build of
ifdtool fails with linker errors because the Makefile does not respect
LDFLAGS.
Modify the Makefile to respect LDFLAGS from the environment. This
is consistent with the Makefiles of most other coreboot utils.
BUG=b:255462682
TEST=`USE=asan emerge-nissa coreboot-utils` now succeeds with CL:4018976
Change-Id: I1a497562d4d979829edb47c4c4b3f2c64266324e
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70054
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit 52ccd293d7 ("mb/google/brya: Implement shutdown function for
dGPU") started unconditionally adding MPTS to the SSDT. On variants
with HAVE_WWAN_POWER_SEQUENCE selected, MPTS is already added to the
DSDT via wwan_power.asl. The duplicate definition results in a kernel
error:
ERR kernel: [ 0.109237] ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)
ERR kernel: [ 0.109242] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20210730/psobject-220)
Don't add MPTS to the SSDT if HAVE_WWAN_POWER_SEQUENCE is selected.
There are no variants which use both, so this should only result in
empty MPTS methods being removed.
BUG=b:260380268
TEST=On pujjo, the SSDT no longer contains an empty MPTS method, there's
no kernel error, and the WWAN power-off sequence is met.
Change-Id: I9f411aae81ea87aa9c8fc7754c3709e398771a32
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70146
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The size of a pointer changes between a 32 and 64 bit coreboot build. In
order to be able to use a 32 bit FSP in a 64 bit coreboot build, change
the pointer in the UPDs to a uint32_t to always have a 32 bit field in
the UPD for this. Also make sure that the address of the lcl_usb_phy
struct is located below the 4GB boundary, so that the truncation to 32
bits won't result in pointing to a different memory location than
intended. In this error case, which I don't expect to happen, print an
error and write 0 to mcfg->usb_phy_ptr so that the FSP will use its
default values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1394aa6ef5f401e0c7bdd4861f1e28ae46e56e4f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70505
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The following are considered "expected" situations, where we shouldn't
print error messages as in other unexpected errors:
1. When the previous boot is in recovery mode, under certain config
combination the normal MRC cache would have been invalidated.
Therefore the "couldn't read metadata" error is expected to show in
the current normal boot. Special-case this situation by printing a
different message.
2. If the platform doesn't have recovery cache (!HAS_RECOVERY_MRC_CACHE)
and vboot starts before romstage (!VBOOT_STARTS_IN_ROMSTAGE), then
there should be no region for recovery cache. In this case, "failed
to locate region type 0" will be shown. Since it's pretty clear from
the code that this is the only case for the error to happen, simply
change it to BIOS_DEBUG. Also remove a duplicate message when
mrc_header_valid() fails.
BUG=b:257401937
TEST=emerge-corsola coreboot
TEST=Ran `cbmem -1 | grep ERROR` in recovery boot
TEST=Ran `cbmem -1 | grep ERROR` in normal boot following recovery boot
BRANCH=corsola
Change-Id: Ia942eeecaca3f6b2b90bac725279d2dc6174e0fd
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69542
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PP1800_GPU_X should dynamically move from GPP_E18 to GPP_F12
depending on board revision.
PP0950_GPU_X (PEX) should remain on GPP_E10 for all board
revisions.
BUG=b:242752623
TEST=dGPU is functional on both revisions of the board
Change-Id: I20994fcac4d7b98ee893d5eb98b096c037d31d6c
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70320
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Both TRAP and TRP0 are now only defined for i82801gx ASL.
This fixes an issue with updating to IASL 20221020, with many
intel platform builds failing with:
dsdt.asl 38: TRP0 = 0
Error 6084 - ^ Object does not exist (TRP0)
The error was ignored with older IASL.
Change-Id: Ie8a59803f4a27a8315c16bde401f8ca90ee814a7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Update the top level readme file to reflect the updated documentation
and project status.
This is mostly a rewrite, but some text was just reformatted.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2cd59d75da47b287029a9fc5eeddefaf99198965
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch moves TCSS firmware latency related macros from SoC
specific tcss.h to IA common tcss.h
Additionally, ensure other structure definitions belonging to the
IA common code tcss.h are not causing compilation issues for ASL files
(due to including FW latency macros) hence, guarded against
`!defined(__ACPI__)`.
TEST=Able to build and boot Google/Rex and Google/Kano.
Change-Id: Id51545ef714979c6ba09a2b468231b1f4bab0be7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70487
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `soc_read_pmc_base()` function returns an `uintptr_t`, which
is then casted to a pointer type for use with `read32()` and/or
`write32()`. But since commit b324df6a54 ("arch/x86:
Provide readXp/writeXp helpers in arch/mmio.h"), the
`read32p()` and `write32p()` functions live in `arch/mmio.h`.
These functions use the `uintptr_t type for the address parameter
instead of a pointer type, and using them with the
`soc_read_pmc_base()` function allows dropping the casts to pointer.
BUG=none
TEST=Build and Boot verified on google/rex
Port of 'commit f585c6eeea ("soc/intel: Drop casts
around `soc_read_pmc_base()`")'
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I914190f2d2d0507c84b19340159990f9b62ce101
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70272
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, the `USE_LEGACY_8254_TIMER` Kconfig option is the only way
to enable or disable the legacy 8254 timer. Add the `legacy_8254_timer`
CMOS option to allow enabling and disabling the 8254 timer without
having to rebuild and reflash coreboot. If options are not enabled or
the option is missing in cmos.layout, the Kconfig setting is used.
BUG=none
TEST=Build and Boot verified on google/rex
Port of 'commit bc35bed18e ("soc/intel/*: Allow configuring
8254 timer via CMOS")'
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ibf6c43ddecb3da325c22228205243bb6af00d1d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70423
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes the `unknown` voltage field issue in processor SMBIOS
table.
This patch is backported from
commit 30e8fc1f4e (soc/intel/alderlake:
Fix unknown voltage in SMBIOS)
TEST=Able to see meaningful voltage data in the SMBIOS table.
Without this patch:
localhost ~ # dmidecode -t 4
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: CPU0
Type: Central Processor
Family: Pentium Pro
...
Voltage: Unknown
With this patch:
localhost ~ # dmidecode -t 4
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: CPU0
Type: Central Processor
Family: Pentium Pro
...
Voltage: 0.8 V
Change-Id: I0cd7c1e3c0746309600e4480f4822a4d72147041
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70424
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The validation process verifies that hardware components comply with
the standard hardware specifications. For instance, PCI express
implementation must comply with the hardware PCIe specification
requirements: Electrical, Configuration, Link Protocol and Transaction
Protocol. To perform these tests the hardware must be configured in a
particular state: some feature related to power management need to be
turned off, hot plug should be enabled...
This patch sets the appropriate FSP Updateable Product Data flags to
get the hardware in the proper configuration:
- Enable PCIe hotplug on all ports
- Set clock sources to run free
- Set the FSP compliance test mode flag
This patch is backported from
commit 096ce1444e (soc/intel/alderlake:
Support PCIe hardware compliance test mode)
Change-Id: Idd7a1adf0f53b014093ba70fee599dbb7887a0fc
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70416
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When an enabled root port without pcie_rp clock being specified, the
empty structure provides invalid info, which indicates '0' is the
clock source and request. If a root port does not use clock source, it
should still need to provide pcie_rp clock structure with flags set to
PCIE_RP_CLK_SRC_UNUSED. If flags, clk_src, and clk_req are all '0', it
is considered that pcie_rp clock structure is not provided for that
root port.
Add check and skip PCIe CLKSRC programming without a clock structure.
In addition, a root port can not use a free running clock or clock set
to LAN.
Note that ClockUsage is either free running clock, LAN clock, or the
root port number which consumes the clock.
This patch is backported from
commit edf71a08b4 (soc/intel/alderlake:
Skip PCIe source clock assignment if incorrect)
Change-Id: Ie9179880a57796d8595874325203280590d7ee9d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70415
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In some cases, partner may assign same clkreq on more than one devices.
This could happen when one device is in baseboard dev tree and another
one is in override dev tree.
This change adds a clkreq overlap check and shows a warning message.
This patch is backported from
commit ff553ba8b3 (soc/intel/alderlake:
Check clkreq overlap)
Change-Id: Ifc1c57578eca376685196ad497d9db825d63aa76
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70414
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures to be able to drive SYS_SLP_S0IX_L `low` based
on the state of the system while `SLP_S0_L` signal is `low` (while
the system is in S0ix).
Implemented runtime ASL method (MS0X) being called by PEPD device
_DSM to configure `SLP_S0_GATE (GPP_H14)` PIN at S0ix entry/exit.
Scope (\_SB)
{
Method (MS0X, 1, Serialized)
{
If ((Arg0 == One))
{
\_SB.PCI0.CTXS (0x75)
}
Else
{
\_SB.PCI0.STXS (0x75)
}
}
BUG=b:256807255
TEST=Able to see SYS_SLP_S0IX_L goes low in S0ix.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie6b5e066f228ea5dc79ae14dd803fc283fd248ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70196
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace the amdblocks/gpio.h and soc/gpio.h includes with the common
gpio.h which will include soc/gpio.h which will include amdblocks/gpio.h
in the AMD SoC case.
Since baseboard/ec.h and indirectly baseboard/gpio.h files will get
included in the DSDT, the soc/gpio.h includes in those aren't replaced
with a gpio.h include for now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib982e338b5c6bc145ec1a8f6dd75175a42dfb426
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70436
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace the amdblocks/gpio.h and soc/gpio.h includes with the common
gpio.h which will include soc/gpio.h which will include amdblocks/gpio.h
in the AMD SoC case.
Since baseboard/ec.h and indirectly baseboard/gpio.h files will get
included in the DSDT, the soc/gpio.h includes in those aren't replaced
with a gpio.h include for now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifa82c10d10e4438b0437b78ddd95b5e823805571
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70435
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the initial code for mtlrvp_p_ext_ec variant board
which includes
1. support for 2 mainboards (Chrome EC and Windows EC) by
adding overridetree.cb to corresponding directory
2. Move devicetree to baseboard/mtlrvp_p
3. Update mainboard name in Kconfig and Kconfig.name
4. Add config option to select corresponding overridetree.cb
Subsequent patches include patch train starting from (CB - 66102)
BUG=b:260654043
TEST=Able to build with the patch and boot the mtlrvp platform with the
subsequent patches
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I83948aa5e9fcaadee4745e313360773c48142f89
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Usha P <usha.p@intel.com>
selfboot.c blocks the payload that does not target RAM. But MT8173 loads
and runs BL31 payload in SRAM. Make the exception by implementing
`payload_arch_usable_ram_quirk()`.
TEST=load and initialize BL31 successfully
Change-Id: I8951b1c4673cdae7d1ad0c11d7d6c12376acd328
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70344
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable LPC SPI DMA. This helps with ~20ms boot time improvement while
loading various components synchronously.
BUG=None
TEST=Build Skyrim BIOS image and boot to OS. Observe a boot time
improvement of ~20 ms.
Before:
Total Time: 1,503,032
After:
Total Time: 1,485,536
Change-Id: I4dd57d46ae9bd664d57178d34b5beda872ed2cdb
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70383
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
INSTALL and PREFIX variables will not be overwritten. Also, mkdir was
replaced by a tool from the INSTALL variable to be compatible with other
cross-compilation buildsystems (like Yocto).
Overwriting variables generates problems when we use different
buildsystem like Yocto where tool names are stored in environment
variables. This change may make building the utility easier - the user
of different buildsystem will not have to remember to pass correct tool
names when issuing the make command.
Also, this change does not affect the rest of users - if the variable
was not set before, then it will be configured as before.
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Change-Id: Ia8dd67d18392e1e11d9160b187ef1a874d69ff5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70105
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Build variables like CC, INSTALL, and PREFIX, should not be
overwritten by the Makefile. This generates problems when we use
different buildsystem like Yocto where tool names are stored in
environment variables. This change may make building util tool
easier - the user of different buildsystem will not have to remember
to pass correct tool names during running the make command.
Also, this change does not affect the rest of users - if the variable
was not set before, then it will be configured as before.
Signed-off-by: Maciej Gabryelski <maciej.gabryelski@3mdeb.com>
Change-Id: If5c88bde0ae00f0211a250906cbdedfe4f59c67b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70102
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The original version of the mem_chip_info structure does not record rank
information and does not allow precise modeling of certain DDR
configurations, so it falls short on its purpose to compile all
available memory information. This patch updates the format to a new
layout that remedies these issues. Since the structure was introduced so
recently that no firmware using it has been finalized and shipped yet,
we should be able to get away with this without accounting for backwards
compatibility.
BRANCH=corsola
Cq-Depend: chromium:3980175
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If34e6857439b6f6ab225344e5b4dd0ff11d8d42a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68871
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Xixi Chen <xixi.chen@mediatek.corp-partner.google.com>
The size of a pointer changes between a 32 and 64 bit coreboot build. In
order to be able to use a 32 bit FSP in a 64 bit coreboot build, change
the pointer in the UPDs to a uint32_t to always have a 32 bit field in
the UPD for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I419fef73d2881e323487bc7fe641b2ac4041cb17
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70135
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
DTTS indicated Dynamic Thermal Table Switching.The proposal would like
to develop the schematic for switching 6 thermal table by lid status,
machine body mode and temperature. After entering the OS, the thermal
table would be table A. If the “Motion” or “Lid status change” is
detected. The thermal table would switch to laptop mode or lid close
mode.
Once the higher environment temperatures are detected,the thermal
table would switch to the corresponding power throttle table (B, D or
F). Based on these table switching mechanisms, no matter how the
end-user uses Chromebook,they could enjoy more humanized thermal
designs.
Release Over Over Release .
Temp. Temp. Temp. Temp. .
-------------------------------------------------------- .
Desktop mode Table A Table B 50C 45C .
Lid open (Default) .
-------------------------------------------------------- .
Desktop mode Table C Table D 55C 50C .
Lid close .
-------------------------------------------------------- .
Laptop mode Table E Table F 45C 40C .
-------------------------------------------------------- .
On the proposal, the transmission rules are list below:
1. Table A is the default table after booting.
2. A, C, E (Release Temp) can switch to each other.
3. B, D, F (Over Temp) can switch to each other.
4. A and B, C and D, E and F can switch to each other.
5. If Lid open/close or mode switch event trigger, temperature release
tables will translation to each other, temperature over tables will
translation to each other.After that event trigger, EC will check the
new temperature condition and decide if the temperature need to be
trigger.For example, if table A will switch to table D, table A will
switch to C with Lid close event, if temperature is over 55C, EC will
trigger temperature to switch form table C to D.
6. EC will trigger 3 times body-detection events during power on boot
without any body-mode and lid status change. For this case if the
previous table label is on same group, we will based on the temperature
to decide the table.
For example, assume table A is current table. When the temperature
reaches 50C, than the table is switched from A to B. The current table
is B. When the temperature is downgrade below 45C, the table is
switched form B to A. The same rule is for C and D, E and F.
BRANCH=none
BUG=b:232946420
TEST=emerge-skyrim coreboot
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: I866e5e497e2936984e713029b5f0b6d54cbc9622
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
LARS has two variants, LARS and LILI, which are differentiated via
the customization_id field in the VPD. To make differentiation easier
outside of ChromeOS (ie, for Windows/Linux drivers), set the SKU ID
based on VPD so it can be easily read via SMBIOS.
Modeled after similar code in google/reef (snappy variant).
TEST=build/boot lili variant, verify sku1 populated in SMBIOS tables.
Change-Id: I148462b6f86b25fa8db26ea6e1537d1a5e47984b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are four requirements for the SMI to hit a printk()
this commit now removes.
Build must have DEBUG_SMI=y, otherwise any printk() is a no-op
inside SMM.
ASL must have a TRAP() with argument 0x99 or 0x32 for SMIF value.
Platform needs to have IO Trap #3 enabled at IO 0x800.
The SMI monitor must call io_trap_handler for IO Trap #3.
At the moment, only getac/p470 would meet the above criteria
with TRAP(0x32) in its DSDT _INI method. The ASL ignores any
return value of TRAP() calls made.
A mainboard IO trap handler should have precedence over
a southbridge IO trap handler. At the moment we seem to have
no cases of the latter to support, so remove the latter.
Change-Id: I3a3298c8d9814db8464fbf7444c6e0e6ac6ac008
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
CONFIG_VBOOT_CBFS_INTEGRATION images are signed differently than normal
images. futility needs to be able to tell this difference, and it parses
the `config` file included in CBFS to do this. This change codifies that
dependency in Kconfig so that nobody can accidentally break this by
turning off config file inclusion.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2b2d245b850bc65abb4e72f20b4e360312c828f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70157
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The intention of CB:69710 was that the expanded config file introduced
there would be a strict superset of the old version and could be used in
all the same cases. This is generally true except for a small oversight:
if a boolean Kconfig is `default y`, but was manually set to `n` by the
user, the new `config` file does not include a line for it. Running
`make olddefconfig` on such a file will again introduce the option as
`y`. It turns out that `make olddefconfig` actually parses those
"load-bearing comments" in that case.
This patch fixes the problem by also generating the minimal defconfig
(like before CB:69710), and then just appending the non-comment lines
from the full config that don't appear in it already. This ensures that
any "load-bearing comments" in the defconfig remain in the file and the
result of Kconfig utilities regenerating a full config from there will
again be the same as before CB:69710. In addition, it clearly separates
the "minimal defconfig" part of the file from the rest, making it easy
for people to extract that if they need it; while also keeping all the
config values in one file to make it easy to grep for a certain value.
Also eliminate that random backslash in the recipe that doesn't seem to
have any good reason to exist and was probably a typo to begin with.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I52ba5d20d3536498fae79d529acf7135f97ef1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Properly handle meminfo DIMMs with `dimm_size` of 0, which represent
empty slots. This allows platform code to create dummy meminfo DIMMs
so that SMBIOS tables have type 17 entries for empty DIMM slots.
Change-Id: I17ae83edf94483bd2eeef5524ff82721c196b8ba
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64035
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the MRC cache is updated in romstage, immediately after
returning from FSP-M. Since cbmem is not cached in romstage, the update
is slow (~6 ms on nissa). Specifically, the new MRC data returned by the
FSP is stored in the FSP reserved memory in cbmem, so hashing the new
data is slow.
Move the MRC cache update to ramstage, where cbmem is cached. On nissa,
this saves ~5 ms of boot time.
Before:
552:finished loading ChromeOS VPD (RW) 631,667 (16)
3:after RAM initialization 637,703 (6,036)
4:end of romstage 650,307 (12,603)
After:
552:finished loading ChromeOS VPD (RW) 631,832 (15)
3:after RAM initialization 633,002 (1,169)
4:end of romstage 645,582 (12,580)
In ramstage, save_mrc_data() takes ~138 us.
BUG=b:242667207
TEST=MRC caching still works as expected on nivviks - after clearing the
MRC cache, memory is retrained on the next boot, but cached data is used
on subsequent boots.
Change-Id: Ie6aa2dee83a3ab8913830746593935d36a034b8d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add retry up to 10 seconds maximal in ipmi_get_device_id.
Without this retry, on OCP Craterlake with BMC version v2022.28.1,
there's a chance that ipmi_get_device_id failed then ipmi device
won't be enabled.
Change-Id: I2b972c905fb0f8223570212432a4a10bd715f3f7
Signed-off-by: Yiwei Tang <tangyiwei.2022@bytedance.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
This replaces the mechanism with --ext-win-base --ext-win-size with a
more generic mechanism where cbfstool can be provided with an arbitrary
memory map.
This will be useful for AMD platforms with flash sizes larger than 16M
where only the lower 16M half gets memory mapped below 4G. Also on Intel
system the IFD allows for a memory map where the "top of flash" !=
"below 4G". This is for instance the case by default on Intel APL.
TEST: google/brya build for chromeos which used --ext-win-base remains
the same after this change with BUILD_TIMELESS=1.
Change-Id: I38ab4c369704497f711e14ecda3ff3a8cdc0d089
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch creates initial common code structure for board_id
implementation for intel rvp platforms. Board_id helps in
identifying the platform with respect to CHROME_EC and INTEL_EC
(Windows_EC). Changes include
1. Create initial board_id.c and board_id.h
2. Modify the Makefile to include src/ec/intel directory
BUG=b:260654043
TEST=Able to build with the patch and boot the mtlrvp platform with the
subsequent patches in the train
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: If133f6a72b8c3e1d8811a11f91e4556beb8c16e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Previously, running "make printall" when there was no .config available,
the system would give an error that printall wasn't a valid target. This
is because it was only in an invalid if clause. This change adds it to
the other branch of the if clause so it will print out a notice of what
the issue is.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I20670ae875be67ac2edf877c53de4702c4fc7c7d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There shouldn't be any change to functionality here - this should be
strictly cleanup.
- STYLE: Put variables inside braces.
- SHELLCHECK: Instead of 'var= ' to clear a variable, use 'var=""'
- SHELLCHECK: Put commands and command variables inside quotes.
- SHELLCHECK: Don't use variables inside the printf commands.
- OTHER: COREBOOT_BUILD needed a date format when the variables in the
our_date() function were put into quotes. This format matches the
output of 'LANG="" LC_ALL=C TZ=UTC0 date'
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3303caee5c7a53c9df579e6f48d2c3d075a8c278
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
- 'git describe --match [0-9].[0-9]*' was giving me an error, so use
the basic 'git describe' command instead.
- If a .coreboot-version file exists, use that to determine the version.
This fixes the problem for coreboot releases.
- Don't run git for the versions unless it's being built from a valid
git repository. Use 0.0 as the default version for timeless or unknown.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5fae2f012cc9b9914d8803af8dd58a885358cb1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The `HyperThreading` FSP UPD is set according to the `hyper_threading`
CMOS option using the value of the `FSP_HYPERTHREADING` Kconfig option
as fallback in case options are disabled or otherwise unavailable. The
`HyperThreadingDisable` devicetree setting isn't used by any mainboard
but it overwrites the value of the FSP UPD. Remove it so that the CMOS
and Kconfig options work as intended.
Change-Id: Iea60b89f6f970eb9aee8c7bec026ab5c2df30205
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69534
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ELOG_CROS_DIAG_RESULT_* codes should be consistent with the enum
definition of enumerated histograms.
Hence add comments based on the requirements of enum histograms in
histogram guidelines.
BUG=b:4047421
TEST=none
Change-Id: I1a1a7c863d5aa9496649f81dc94fd79a6ad482df
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70145
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The DSI CMDQ offset of MT8186 is different from previous SoCs.
Therefore, we define two versions for DSI register header files. The v1
is for MT8173/MT8183/MT8192 and the v2 is for MT8186/MT8188.
BUG=b:244208960
TEST=build pass
BRANCH=corsola
Change-Id: I3d13ca03b72554ab7be2b194db32a4f961f38dad
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70183
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For geralt project, we also support MIPI panel as our firmware display.
So add this patch to configure ddp to choose eDP display or MIPI panel
display.
BUG=b:244208960
TEST=test firmware display pass for both eDP and MIPI panel on MT8188
EVB.
Change-Id: I06f38b1889811274588c26e9284da4d502acf38b
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70181
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
C5, C6 and slfm depend on the southbridge and the northbridge to be able
to provide this functionality, with some just lacking the possibility to
do so. Move the devicetree configuration to the southbridge.
This removes the need for a magic lapic in the devicetree.
Change-Id: I4a9b1e684a7927259adae9b1d42a67e907722109
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch adds PCIe based SD controller at RP 7 (from RP 11) with
Proto 1 schematics dated 11/30.
Additionally, added the RTD3 entries for the SD controller.
Finally, ensured that EN_PP3300_SD (GPP_D03) is configured in
bootblock and SD_PERST_L (GPP_D02) is configured in romstage to
meet the power cycle requirement.
BUG=b:242917011
TEST=Able to build and boot Google/Rex. SD card detection is due
for the Proto 1 hardware.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I23d53e4d61ec36d2145f9e5816d97d13eb5b219e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70064
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
This patch drops the usage of reading `board_id()` while performing
the GPIO configuration.
The reason to drop the board_id check is to ensure that GPIO
configuration for MLB (mainboard) would remain the same and the only
GPIO PIN configuration that differs would be due to usage of having
different DBs (daughter board) which will be taken care using
CBI (and fw_config.c file) in coreboot.
Additionally, drop unused early GPIO default configuration table.
BUG=b:260804656
TEST=Able to perform the GPIO configuration and able to boot
Google/Rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I96cafd1c904001cbf4199977e9e721afe5eab470
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Enable this feature, and it can use the probe statement in devicetree
to cache of fw_config field as oem string.
TEST=With CBI FW_CONFIG field set to 0x1561
localhost ~ # dmidecode -t 11
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
Handle 0x0009, DMI type 11, 5 bytes
OEM Strings
String 1: AUDIO-MAX98357_ALC5682I_I2S
String 2: CELLULAR-CELLULAR_PCIE
String 3: UFC-UFC_MIPI
String 4: WFC-WFC_MIPI
String 5: DB_SD-SD_GL9755S
Change-Id: I6cb35eb9c0fbe32764ca76bb7a929cc92fc38404
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70228
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
NVMe is determined by a logical bit 1, not the physical SKU pin.
Thus, (logical) sku_id & 0x2 == 0x2 would mean that the device has
NVMe enabled on it. Previously, I thought that it was tied to a
physical pin, but this is not correct.
BUG=b:254281839
BRANCH=None
TEST=flash and boot on villager and make sure that NVMe is not
initialized in coreboot.
Change-Id: Iaa75d2418d6a2351d874842e8678bd6ad3c92526
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70230
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The devices in the list that was introduced in commit c66ea98577
("soc/intel/alderlake: provide a list of D-states to enter
LPM") are all internal. This CL skips the external buses (which caused
the addition of packages to non-existant paths such as
"_SB.PCI0.RP1.MCHC", and warnings from the kernel)
BUG=b:231582182
TEST=Built and tested on anahera by verifying SSDT contents
Change-Id: I3785b2b2af85d96e2e1296b6cfdefcd72080b5fe
Signed-off-by: Eran Mitrani <mitrani@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70163
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Per Intel doc 621483, 26.1.1 - NMI_STS_CNT, 8254 timer is required
for Speaker Data output (buzzer) at GPP_B14 NF1, as it is using
8254 timer counter 2 output. However when 8254 timer is used, S0ix
will not work as 8254 has to be gated instead. For further info on
s0ix requirements, refer to Intel doc 610002 (Modern Standby Unified
Checklist).
This CL also disables s0ix because it is not required by the
platform.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Ib5e7787a47509ed09818d8515d21a80196fb1ec6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67553
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Galago Pro 6 (galp6) is an Alder Lake-P board.
Tested with a custom edk2 UefiPayloadPkg.
Working:
- PS/2 keyboard, touchpad
- Both DIMM slots (with NMSO480E82-3200EA00)
- M.2 NVMe SSD (with MZVL2500HCJQ)
- All USB ports
- All USB ports
- SD card reader
- Webcam
- Ethernet
- WiFi/Bluetooth
- Integrated graphics using Intel GOP driver
- Backlight controls on Windows 10 and Linux 6.1
- HDMI output
- DisplayPort output over USB-C
- Internal microphone
- Internal speakers
- Combined headphone + mic 3.5mm audio
- S0ix suspend/resume
- Booting Pop!_OS Linux 22.04 with kernel 6.0.6
- Internal flashing with flashrom v1.2-1087-gde016a17
Not working:
- Detection of devices in TBT slot on boot
Change-Id: I8940fb3777d7f18393ef50baec32f9445b375648
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
This patch selects SOC_INTEL_CSE_SEND_EOP_LATE config to let IA
common code to skip sending CSE EOP cmd during finalize operation
rather uses boot state machine (either payload load or payload boot)
to delay in sending EOP cmd to CSE.
BUG=b:260041679
TEST=Able to boot to Google/Rex with this patch and observed ~150ms
savings in boot time
Without this patch:
942:before sending EOP to ME 1,795,702 (354)
943:after sending EOP to ME 1,950,526 (154,824)
With this patch:
942:before sending EOP to ME 2,051,406 (35,484)
943:after sending EOP to ME 2,057,583 (6,177)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I7d44d5eff890ac78e3075d49cc249f740686dd0d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69999
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch allows to send late EOP cmd to CSE (after CSE .final)
using boot state machine (either BS_PAYLOAD_BOOT or BS_PAYLOAD_LOAD)
if the SoC user selects SOC_INTEL_CSE_SEND_EOP_LATE config.
Rename `set_cse_end_of_post()` to `send_cse_eop_with_late_finalize()`
to make the function name more meaningful with its operation.
BUG=b:260041679
TEST=Able to boot Google/Rex after sending CSE EOP late.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: If4c4564befcd38732368b21f1ca3e24b68c30e0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69978
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch creates an API that can perform essential CSE operation
after sending the late EOP command to the CSE and prior booting to OS.
Lists of operation are
- Perform global reset lock
- Put HECI1 to D0i3 and disable the HECI1 if the user selects
- Set D0I3 for all HECI devices.
BUG=b:260041679
TEST=Able to boot Google/Rex after sending CSE EOP late.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I10131ea9b553a62f0d632783c4dbad96d35d6563
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69977
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors common code to allow cse_final() function to send
EOP cmd if the SoC user selects `SOC_INTEL_CSE_SET_EOP` kconfig.
This patch helps cse_final_ready_to_boot() and
cse_final_end_of_firmware() function for being meaningful with its
operation and let cse_final() being that outer layer to perform three
operations based on the selected kconfig.
1. send cse eop command
2. perform cse_final_ready_to_boot() operations
3. perform cse_final_end_of_firmware() operations
Additionally, ensures the platform that choose to send EOP late
(like JSL and TGL) is not being impacted due to this code refactoring
hence, skip calling into CSE.final if SoC selects
`SOC_INTEL_CSE_SEND_EOP_LATE` config.
BUG=b:260041679
TEST=Able to send EOP command successfully for Google/Taeko.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I412291c9378011509d3825f9b01e81bfced53303
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69975
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Presently, coreboot supports two instances of sending EOP cmd to
the Intel CSE.
1. Sending EOP cmd to CSE during `.final` operation from cse pci driver.
2. Starting with Alder Lake, the recommendation was to send EOP to CSE
earlier than CSE `.final` operation. Since then it's referred to as
`Sending EOP Early`. This method helped to save the CSE EOP
response time significantly.
During Meteor Lake platform, CSE EOP response time has become
non-deterministic and we have figured that sending EOP command later
than CSE .final operation is actually helping to optimize the boot time
significantly (around ~150ms savings compared to sending from `.final`
ops and ~5sec compared to sending CSE early).
Hence, this patch intended to create yet another kconfig for sending
CSE late (specifically after `.final` operation). The idea for this
newer config is to use the boot state machine for sending CSE EOP cmd.
The patch train in this series would add the specific changes to allow
sending EOP late and perform other essential operations required prior
booting to OS as coreboot decided to skip calling into FSP Notify phase.
Starting with Jasper Lake, coreboot sends EOP before loading payload
hence, this config is applicable for those platforms.
The current plan is that Intel Jasper Lake, Tiger Lake and Meteor Lake
platform will select this newer config from SoC code.
BUG=b:260041679
TEST=Able to send EOP command successfully for Google/Taeko.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iea512cd5b79d61dd5d5a962079baf525027c831f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69976
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patches for kconfig need to be in a format compatible with the quilt
tool, and usually also contain a header with some additional info like
the git commit. This header is in the same format as patches produced by
`git format-patch`, but the diff style git uses is incompatible with
quilt and there does not seem to be a straightforward way to format the
diff section to work.
Add some documentation for a method I found to go from a git commit to a
quilt compatible patch with git headers.
Change-Id: I7a8bbe41e0864be1d28116742b6b8b3fc440cc31
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch ensures dropping of the duplicate macro introduced with
'commit 9e4488ab06 ("soc/intel/{adl,cmn}: Add/Remove LTR
disqualification for UFS")'
`PCH_PWRM_BASE_SIZE` macro represents the size of the PMC MMIO range
which can be used as is even in ufs.asl file.
BUG=b:252975357
TEST=Build and boot nirwen and see no issues in PLT runs.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic967c609e1330eca1b9e1143e7efd78db011f317
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70180
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Commit 2c102232e8 ("mb/amd/chausie,google/skyrim: increase
RW_MRC_CACHE size to 120 kByte") increased the MRC cache size, but with
the change the default AMD_FWM_POSITION_INDEX which is 5 for the 16MByte
flash size, the amdfw part won't be placed on the expected position,
since the cbfs header is in that exact location and cbfstool places the
amdfw part right after that. Change the AMD_FWM_POSITION_INDEX to 4 for
the non-chromeos builds to work around this.
TEST=Non-chromeos chausie build now boots and doesn't fail any more
before releasing the x86 cores from reset
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I89fe1d0672139e04070f05c6c8fa8955edcfc7ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70133
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of using a fake lapic device hook up the cpu cluster to chip
cpu/intel/model_206ax.
The lapic device is also not needed as the mp init will allocate it for
the BSP at runtime.
Change-Id: Id3b1c4ca027e2905535e137691c3e3e60417dbf3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The patch logs CSE RO's write protection information for Meteor Lake
platform. As part of write protection information, coreboot logs status
on CSE RO write protection and range. Also, logs error message if EOM
is disabled, and write protection for CSE RO is not enabled.
Port of commit abe0d810f0 ("soc/intel/alderlake: Log CSE RO write
protection info for ADL").
BUG=none
TEST=Verify the write protection details on google/rex.
Excerpt from google/rex coreboot log:
[DEBUG] ME: WP for RO is enabled : YES
[DEBUG] ME: RO write protection scope - Start=0x4000, End=0x396FFF
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Idb072a873a8b8323532799f5fc64f995c9f0a604
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.corp-partner.google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
When retrieving the SKU id value through the sku_id() function in
mainboard_needs_pcie_init(), we only want the values in the lower 5
bits as we can only represent SKU id up to 27. Everything in the
higher bits should be masked out because they are not needed.
BUG=b:254281839
BRANCH=None
TEST=Make sure that NVMe is not initialized
Tested on a herobrine board with SKU id 0
Change-Id: I0e786ec392b5e1484cb2ff6d83a8d4fdd698950c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70164
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, we are getting the sku id from the EC every time we call
the sku_id() function. However, this will never change so we only
need to retrieve it once. Inserting exit condition if sku id is
already set, then don't get it from the EC again.
Also, removing the ram_code function, which does nothing right now.
There is already a weak stub_function for this in
src/lib/coreboot_table.c that already does the same thing.
BUG=b:260740438,b:182963902
BRANCH=None
TEST=make sure image still boots to login on herobrine device
Change-Id: Ia787968100baf58a41ccce0cf95ed3ec9ce1758a
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70162
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Clang warns about structs inside a union also needing the packed
attribute.
This files is copied from the chromeec project, so it adds comment next
to the coreboot specific changes as a reference.
TEST: google/vilboz remains the same with BUILD_TIMELESS=1 and gcc.
Change-Id: I8b5233618081db86caedcb2d14870974e109ed9b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Fast VMode nmakes the SoC throttle when the current exceeds the I_TRIP
threshold.
FSP silicon discards the request if the Voltage Regulator or SoC does
not support the feature.
BUG🅱️259057787
TEST:Verify that the feature is enabled by reading from pcode
No PnP regression observed
BRANCH=firmware-brya-14505.B
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I7e318534f1429af8ec06048430966344ddd346a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69579
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Jeremy Compostella <jeremy.compostella@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 095c931cf1.
Previously cpu_info() was implemented with a struct on top of an
aligned stack. As FSP changed the stack value cpu_info() could not be
used in FSP context (which PPI is). Now cpu_info() uses GDT segments,
which FSP does not touch so it can be used.
This also exports cpu_infos from cpu.c as it's a convenient way to get
the struct device * for a certain index.
TESTED on aldrvp: FSP-S works and is able to run code on APs.
Change-Id: I3a40156ba275b572d7d1913d8c17c24b4c8f6d78
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69509
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add ACPI DmaProperty for ethernet devices.
BUG=b:259716145
TEST=Verified SSDT on google/osiris.
Before:
Scope (\_SB.PCI0.RP01)
{
Device (RLTK)
{
Name (_HID, "R8168") // _HID: Hardware ID
Name (_UID, 0xD0E889DD) // _UID: Unique ID
Name (_DDN, "Realtek r8168") // _DDN: DOS Device Name
Name (_ADR, 0x00000000) // _ADR: Address
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x07,
0x03
})
}
}
After:
Scope (\_SB.PCI0.RP01)
{
Device (RLTK)
{
Name (_HID, "R8168") // _HID: Hardware ID
Name (_UID, 0xD0E889DD) // _UID: Unique ID
Name (_DDN, "Realtek r8168") // _DDN: DOS Device Name
Name (_ADR, 0x00000000) // _ADR: Address
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x07,
0x03
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("70d24161-6dd5-4c9e-8070-705531292865"),
Package (0x01)
{
Package (0x02)
{
"DmaProperty",
One
}
}
})
}
}
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I647593fd02644d30cd21b60d8305c0ec55dc64cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70017
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Right now cbmem uses a fix path to reach coreboot src path (../../).
This makes it impossible to compile cbmem out of the coreboot tree (e.g.
copy just the cbmem directory elsewhere and compile).
This patch adapts the technique from cbfstool and adds a variable called
'TOP' which points to coreboot root directory and which can be
overridden at build time by providing it to make as an argument. This
will enable a stand-alone build of cbmem.
Change-Id: I2732f75310e10716e5aa74e094e0bf628ad22f0b
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69686
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Name a variable based on its utility. `is_external` variable adds
`ExternalFacingPort` _DSD property to an ACPI device hence
rename it to `add_acpi_external_facing_port`.
BUG=b:259716145
TEST=Build google/rex with this flag and verify it in SSDT at
runtime.
SSDT snippet:
Name (_DSD, Package (0x04) // _DSD: Device-Specific Data
{
ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"),
Package (0x01)
{
Package (0x02)
{
"HotPlugSupportInD3",
One
}
},
ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
Package (0x01)
{
Package (0x02)
{
"ExternalFacingPort",
One
}
}
})
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I65100283ed9b65037c9890f28ecab41fcfa25d83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69970
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GCC 12 incorrectly warns about an array out of bounds issue:
```
$ make V=1 # emulation/qemu-i440fx
[…]
CC ramstage/arch/x86/ebda.o
x86_64-linux-gnu-gcc-12 -MMD -Isrc -Isrc/include -Isrc/commonlib/include -Isrc/commonlib/bsd/include -Ibuild -I3rdparty/vboot/firmware/include -include src/include/kconfig.h -include src/include/rules.h -include src/commonlib/bsd/include/commonlib/bsd/compiler.h -I3rdparty -D__BUILD_DIR__=\"build\" -Isrc/arch/x86/include -D__ARCH_x86_32__ -pipe -g -nostdinc -std=gnu11 -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough -Wshadow -Wdate-time -Wtype-limits -Wvla -Wdangling-else -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer -fstrict-aliasing -ffunction-sections -fdata-sections -fno-pie -Wno-packed-not-aligned -fconserve-stack -Wnull-dereference -Wreturn-type -Wlogical-op -Wduplicated-cond -Wno-unused-but-set-variable -Werror -Os -Wno-address-of-packed-member -m32 -Wl,-b,elf32-i386 -Wl,-melf_i386 -m32 -fuse-ld=bfd -fno-stack-protector -Wl,--build-id=none -fno-delete-null-pointer-checks -Wlogical-op -march=i686 -mno-mmx -MT build/ramstage/arch/x86/ebda.o -D__RAMSTAGE__ -c -o build/ramstage/arch/x86/ebda.o src/arch/x86/ebda.c
In file included from src/arch/x86/ebda.c:6:
In function 'write_ble8',
inlined from 'write_le8' at src/commonlib/include/commonlib/endian.h:155:2,
inlined from 'write_le16' at src/commonlib/include/commonlib/endian.h:178:2,
inlined from 'setup_ebda' at src/arch/x86/ebda.c:35:2,
inlined from 'setup_default_ebda' at src/arch/x86/ebda.c:48:2:
src/commonlib/include/commonlib/endian.h:27:26: error: array subscript 0 is outside array bounds of 'void[0]' [-Werror=array-bounds]
27 | *(uint8_t *)dest = val;
| ~~~~~~~~~~~~~~~~~^~~~~
[…]
```
[In GCC 12 the new parameter `min-pagesize` is added and defaults 4 kB.][1]
It treats INTEGER_CST addresses smaller than that as assumed results of
pointer arithmetics from NULL while addresses equal or larger than that
as expected user constant addresses. For GCC 13 we can represent results
from pointer arithmetics on NULL using &MEM[(void*)0 + offset] instead
of (void*)offset INTEGER_CSTs.
[1]: https://web.archive.org/web/20220711061810/https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
TEST=No compile error with gcc (Debian 12.2.0-3) 12.2.0
Change-Id: I6e36633f42cb4dc5af53212c10c919a86e451ee0
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Later soc/intel/common/smbus addresses TCO2_STS as a separate
16-bit register, while baytrail and braswell assumes 32-bit
wide TCO1_STS to extend as TCO2_STS.
In src/soc/intel/denverton_ns:
#define TCO2_STS_SECOND_TO 0x02
In soc/intel/baytrail,braswell:
#define SECOND_TO_STS (1 << 17)
Elsewehere
#define SECOND_TO_STS (1 << 1)
It's expected that we remove the first (1 << 17) case and only
access TCO2_STS as a separate 16-bit register. For now, use
unique names to avoid confusion.
Change-Id: I07cc46a9d600b2bf2f23588b26891268e9ce4de0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tree is inconsistent with the use of TCO register space offsets and
related preprocessor defines. The legacy space was offset from ACPI
PM base by 0x60, but this changed with later platforms. The convenient
way is to define the TCO registers relative to its base address and
subtract 0x60 here, but this change cannot be easily done tree-wide or
in one go.
For the transient period, apply TCO_SPACE_NOT_YET_SPLIT flag until
all platforms use a clean style of tco_{read,write} accessor functions
instead of {read,write}_pmbase16(), or worse, inw/outl().
Change-Id: I16213cdb13f98fccb261004b31e81a9a44cb6e3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit 9f0e21a4da.
It should be allowed for i82801gx/early_init.c to have
#include <southbridge/intel/common/pmutil.h>
But there is a conflict:
src/southbridge/intel/common/pmutil.h:
#define TCO1_CNT 0x68
src/southbridge/intel/common/tco.h:
#define TCO1_CNT 0x08
Followup works resolve the difficulties around the offset
0x60 used for TCO register bank, tree-wide.
Change-Id: I827558a0e0ef1c4d1f866756df51cd1b2abfc7a0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Fix compilation issue due to enum macro redefinition by safeguarding
definitions with DISPLAY_FSP_VERSION_INFO_2 in SoC Kconfig.
Back-ported from commit f7e8adac7b ("edk2-stable202005: Update
MdePkg/Include/IndustryStandard/SmBios.h") to fix compilation issue due
to enum macro redefinition.
BUG=b:260183604
TEST=Verify MTL Rex0 build with the patch
and verify the version output prints no junk data.
Signed-off-by: Saurabh Mishra <mishra.saurabh@intel.corp-partner.google.com>
Change-Id: Ibc65d05a8b4bd232b91184ff8cd52a20cd3538ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Enable NVMe GPIOs based on fw_config and add NVMe to devicetree.
Note, eMMC and NVMe are not probed in devicetree. On first boot in
factory, the device needs to boot with unprovisioned fw_config, so all
storage devices should be enabled when unprovisioned. Currently,
devicetree disables all probed devices when unprovisioned. If we want
eMMC and NVMe to be probed, support needs to be added for enabling
probed devices when unprovisioned.
BUG=b:259211172
TEST=Verified by ODM. On craask, LTE and WCAM still work. On craaskneto,
eMMC and NVMe SKUs can both boot.
Change-Id: I76a056cddff2246cfb5bb26ddbdfc333b49d9aaf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69958
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch creates an API for CSE-Lite specific SKU to retrieve the
Write Protect (WP) information (`cse_log_ro_write_protection_info`)
like WP range and limit, if the region is write-protected or not etc.
BUG=none
TEST=Able to compile the cse_lite.c file for google/kano without
any error.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8f4b7880534ded5401b6f8d601ded88019c636c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69968
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
As for mainboard mc_ehl1, a hard real-time dependency is also required
for this mainboard. The L1 prefetcher on Elkhart Lake is too aggressive
which in the end leads to an increased number of cache misses. Disabling
the L1 prefetcher boosts up the performance (in some cases by more than
10 %) in this specific use case.
Change-Id: I07b27dd672533e693a6c2987d16f54333850760e
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
`is_untrusted` is eventually ended up by adding DMA property _DSD which is similar to what `add_acpi_dma_property` does for WWAN drivers, hence it
makes sense to have a unified name across different device drivers.
BUG=b:259716145
TEST=Verified that the _DSD object is still present in the SSDT.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I4e0829a76a193b0a1e1e0f2b7ce2119bb00dd696
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69937
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A previous CL ("Add missing ACPI device path names",
commit d22500f0c61f8c8e10d8f4a24e3e2bf031163c07) caused some errors
from the Kernel on Brya devices (see Tim's comment on patchset 8):
> ACPI Error: AE_NOT_FOUND, While resolving a named reference
> package element - \_SB_.PCI0.FSPI
FSPI is defined in src/soc/intel/alderlake/chipset.cb:
device pci 1f.5 alias fast_spi on end
This CL adds the corresponding FSPI device to the DSDT to prevent
the error mentioned above.
TEST=Built and tested on brya by verifying the error is gone.
BUG=b:231582182
Change-Id: I11e89ad2a5d47f6b579f755b0a41399ee3cb856c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69920
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On a 32-bit host, uintptr_t is defined as 'unsigned int' instead of
'unsigend long int' like on a 64-bit host. When cbfstool is built on a
32-bit host, the printk format specifier '%lx' expects a 'long int'
while new_addr is of type 'uintptr_t', aka 'unsigned int'.
This in the end leads to a build error.
To fix this and make it build on both, 32- and 64-bit hosts, use PRIxPTR
as the format specifier. This macro will be resolved at compile time in
the right way on both, 32- and 64-bit hosts.
Test=Build cbfstool on 32- and 64-bit hosts.
Change-Id: Ia917d2ed31778f3a29c0a6c7368f74c15319b099
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69682
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The current IPU ES entry value is always set to true for RPL and
kernel picks the ES version of the main IPU FW even for the production
bootloader but loading is not successful due to the authentication
failure.
On Raptor Lake silicon, the production binaries are backward
compatible with ES parts.
This change removes the IPU ES support ACPI entry since the
kernel needs to load the production IPU main firmware on both the
ES/QS parts.
BUG=b:258125833
TEST=Verify the Camera functionality by enabling the IPU secure mode
on RPL variants with both ES/QS silicon.
Signed-off-by: Jim Lai <jim.lai@intel.com>
Change-Id: I9fd8ea0dd6ffdb16961bb017ba4388bf99e4d5bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69929
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Perform a codec reset before configuring to avoid potential issues like
oryp5 had before 86f410479c ("mb/system76/oryp5: Reset HDA before
configuring").
Inspecting proprietary firmware for multiple boards shows that this is
always done as well.
Change-Id: I64c1fd23f708f77a81fad0bc889f42d4df3f6e61
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66918
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
For the most part, this doesn't change any post codes, simply making the
existing post-codes into macros.
picasso/romstage.c did get a couple of post codes removed to match the
other files.
The POST_ROMSTAGE and POST_BOOTBLOCK codes are intended to become global
at some point, while the POST_AGESA and POST_PSP codes would stay AMD
specific.
Change-Id: I007a09b6a3ed3280bac674cd74e298ec5c408ab7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Taken from Linux which also updated these files.
Clang only works with this syntax, so this fixes builds for arm.
TESTED on qemu vexpress-a9 and verstage on google/vilboz with
BUILD_TIMELESS=1, binaries remain the same.
Change-Id: Ia320dc2c460c99d934b8f17dee7748a9def4e750
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63058
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch provides the functionality to enable downshift on Marvell
PHY. By setting a downshift counter, the PHY is correspondingly often
attempted to establish Gigabit link before the PHY downshifts to the
next highest speed. The range is limited to 8 trials. To activate
downshift, a software reset must follow to take effect.
Change-Id: I4224eab6c1fc13824d53556c80435bc130a13bdb
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69853
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This mainboard has three Marvel PHYs connected to the internal SOC GbE
controllers. The default LED status after HW reset of this PHYs shows a
different mode than what is needed. LED[2] is not connected on this
mainboard.
This patch sets the following LED status:
LED[0] - 7 = On - 1000 Mbps Link, Off - Else
LED[1] - 1 = On - Link, Blink - Activity, Off - No Link
LED[2] - not connected
TEST=Try different register values to verify LED feature.
Change-Id: I51d817bc720bf787279777f503efdc17dbb1274d
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69387
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This driver enables the usage of an external Marvell PHY 88E1512 which
should be connected to a SOC internal MAC controller. In a first step it
is only the framework of the driver. Functionality will follow with a
second patch.
Change-Id: I24011860caa7bb206770f9779eb34b689293db10
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69384
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the MDIO access for the TSN GbE device by placing
the MDIO read and write functions into mdio_bus_operations struct which
is assigned to the .ops_mdio member of the PCI device struct. In this
way the MDIO interface of the TSN GbE device is exposed and can be used
by other drivers if needed.
Change-Id: I5d1b9dd2f2ba8c18291fff314c13f0c3851784aa
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This patch extends the available device paths with a new device 'mdio'.
MDIO is the 'Management Data Input/Output' called interface which is
used to access an Ethernet PHY behind a MAC to change settings. The real
payload data path is not handled by this interface.
To address the PHY correctly on the MDIO bus, there is a 5 bit address
needed, which often can be configured via pins on the mainboard.
Therefore, the new introduced device has an 'addr' field to define its
address. If one wants to use a MDIO device in devicetree, the syntax is
straight forward (example):
device mdio 0x2 on end
As the MDIO interface is driven by the MAC, most likely this MDIO device
will be hooked in as a child device of the (PCI attached) MAC device.
With the new introduced ops_mdio a new interface is added to provide an
API for read and write access over MDIO.
Change-Id: I6691f92c4233bc30afc9029840b06f74bb1eb4b2
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69382
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch skips setting D0I3 bit for all HECI devices by FSP.
The learning being made from Alder Lake platform showed that the CSE
EOP cmd response time is highly nondeterministic and letting the EOP
cmd issued by FSP makes the response time even worse.
The idea being pursued during Alder Lake platform is to let FSP skip sending the EOP cmd and coreboot sends it at the last minute
(late sending of EOP) to ensure there is ample time for CSE to come
to a state where the response to the EOP is almost immediate.
There were a number of refactoring being done to ensure the EOP cmd
can be sent at the later stage.
#1: Ensure FSP is not putting those HECI devices into the D0i3. (SoC specific change)
#2: Modify the CSE related boot state based operation to allow a
proper window for sending late EOP cmd. (Common Code Specific change)
The entire refactoring helps us to save ~60ms of boot time.
Without those code change EOP sending timestamp as below:
943:after sending EOP to ME 1,248,328(61,954))
With those code change EOP sending timestamp as below:
943:after sending EOP to ME 1,231,660 (2,754)
Port of commit d6da4ef69e ("soc/intel/alderlake: Skip setting D0I3
bit for HECI devices") to incorporate the #1 which is a SoC specific
code change.
BUG=none
TEST=FSP-S UPD dump suggested `DisableD0I3SettingForHeci` UPD is
set to `1`.
Excerpt from google/rex coreboot log:
[SPEW ] DisableD0I3SettingForHeci : 0x1
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I1c3765ce41f192ab5f5ff176e0a2b49b312d18d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The brask doesn't include a real chassis so we don't need to configure
the fan setting in the overridetree.cb. Instead, we can leave the fan
running at full speed after the device boot up.
BUG=b:259643676
BRANCH=firmware-brya-14505.B
TEST=flashed the bios to the device and make sure the fan spinned
at full speed.
Change-Id: I6075b6171ca4d7b907679efd0ce7e355759385bc
Signed-off-by: Zhuohao Lee <zhuohao@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69791
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Update the fields that need to be updated directly in the local static
usb_phy_config struct instead of dereferencing the pointer written to
the corresponding UPD field. This will allow updating the type of UPD
field in a follow-up commit to enable 64 bit coreboot builds.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I44a9fe719e6803fc957fee3db13b261489ed313d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69896
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This ports forward part of commit df09680626 ("soc/amd/picasso: Add
support for 64bit builds") to the newer AMD SoCs.
Use -Wl instead of -l to get the output format that the commands in the
Makefile expect to extract the value for PSP_BIOSBIN_SIZE. Without this
change, readelf will split the output into two lines in case of a 64 bit
coreboot build. This results in invalid amdcompress and amdfwtool
command lines which will cause the amdfwtool call to fail with
Error: BIOS binary destination and uncompressed size are required
With the old readelf -l command we get this output in a 64 bit build:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000080 0x0000000002030000 0x0000000002030000
0x0000000000010000 0x0000000000010000 RWE 0x10
while we get the correct output in a 32 bit build:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000060 0x02030000 0x02030000 0x10000 0x10000 RWE 0x20
With readelf -Wl we also get the expected output in a 64 bit build:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x0000000002030000 0x0000000002030000 0x010000 0x010000 RWE 0x10
TEST=This fixes the 64 bit build on Cezanne with some follow-up patches
applied.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I35f9feda4d0da3546592dfac233ca66732bd5464
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69895
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
All parameters of DPTC_INPUT() need to be configured on devicetree
when SOC_AMD_COMMON_BLOCK_ACPI_DPTC is enabled. The parameters without
configurations on devicetree would be 0 when
SOC_AMD_COMMON_BLOCK_ACPI_DPTC is enable. Follow AMD DevHub document
#57316. Configure vrm_current_limit_mA, vrm_maximum_current_limit_mA
and vrm_soc_current_limit_mA on devicetree with thermal table config E
as default table for SMT. Since the dynamic thermal table switching
mechanism is still under cooking, after discussing with thermal team,
suggest adopting config E(limit Soc not reach to max power) as default
thermal config to avoidany thermal-related issue during phase build.
Once the dynamic thermal table switching mechanism is finished, will
change the default value to config A.
BUG=b:258572474, b:248976976, b:259167917, b:257394883
TEST=emerge-skyrim coreboot
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: Ic1e7a46cac4119c7237d96a7bd0d23c8db028680
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
This patch helps to save 10.200ms of booting time without any issue
seen during MP Init. All cores are out from reset and alive.
Port the Alder Lake 'commit 6526e78967 ("soc/intel/alderlake: Select X86_INIT_NEED_1_SIPI Kconfig for RPL")' also to Meteor Lake.
Additionally, no performance degradation is observed while running
benchmarks.
BUG=b:211770003
TEST=Able to boot Google, Rex to ChromeOS with all cores enabled.
Without this patch:
30:device enumeration 1,480,217 (28,232)
With this patch:
30:device enumeration 1,472,466 (18,334)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iec21470b9b34514169789c39bdc3be4e4ff6c7b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69851
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For the most part, this just moves the existing post codes into macros
so that they're not just bare numbers.
cache_as_ram.S:
Post code 0x28 was previously pointless with just a single jump between
it and post code 0x29, car_init_done. This code was removed, and the
0x28 value was used to differentiate the car_nem_enhanced subroutine
from the other 0x26 post codes used before calling the clear_car
subroutine.
All other post codes remain identical.
POST_BOOTBLOCK and POST_CODE_ZERO are expected to become global, whereas
the POST_SOC codes are expected to be Intel only.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I82a34960ae73fc263359e4519234ee78e7e3daab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69865
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This moves a lot of post code values, but unifies them between
platforms, so that the same value means the same thing as much as
possible.
The P4-netburst code was the most extensive and most different, so that
dictated the majority of the values. Three were two values there that
didn't match the other files, so those two values, 0x22 & 0x29 have
duplicate entries in the table.
The rest of the entries are similar between platforms, though the values
for many of them were moved to match the P4-netburst values.
POST_BOOTBLOCK and POST_POSTCAR values are intended to eventually become
global, while POST_SOC would be specific to the Intel platforms.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If13e40b700a41d56bca85510d68da0ab31a235a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69866
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It shouldn't be assumed that all variants of skyrim will use the same
gpio for TPM interrupts.
Use the PSP's new mailbox command to tell it what gpio the tpm interrupt
comes in on.
BUG=b:248193764
TEST=tast run <ip> hwsec.TPMContest
Verify log entry:[DEBUG] PSP: Setting TPM GPIO to 18...OK
Use incorrect GPIO in mailbox cmd and verify TPMContest test
failed.
Signed-off-by: Mark Hasemeyer <markhas@google.com>
Change-Id: I9f4005e10987caf9f32e5ac99ff5f2b9467e586c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69874
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot only supports a small subset of the targets that LLVM supports.
It's not needed to enable all possible targets. Thus limit the targets
to the following ones:
* X86
* RISC-V
* AArch32
* AArch64
* PowerPC
Change-Id: I9938bf176b5fe2b0a631c3b1ae858f988898a196
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69841
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur.heymans@9elements.com>
For nissa, the ISH main firmware will be included in the CSE region in
flash instead of loading it from rootfs. So remove the ISH
firmware-name.
BUG=b:234776154
TEST=Boot to OS on nirwen and yaviks UFS SKUs. Check ISH firmware is not
loaded by kernel, and device still goes to S0i3.
Cq-Depend: chrome-internal:5102230
Change-Id: I68f963e17bc0dbf9db9adaaa3f96f06b8737523b
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69868
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Following warnings occur when compiling with
`i386-elf-gcc (coreboot toolchain v2022-09-18_c8870b1334) 11.2.0`
drivers/serial/8250.c:75: [-Werror=unused-variable]
Move variable declaration inside the
`#if !CONFIG(LP_PL011_SERIAL_CONSOLE)` block
drivers/udc/dwc2.c:505: [-Werror=format=]
use `%zd` to match type `size_t`
Change-Id: Id285c24cba790f181fa203f3117e5df35bed27c4
Signed-off-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69764
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
With the addition of the clang tests, the jenkins builds are taking a
really long time to run the tests. This change allows the
"what-jenkins-does" build to be split into separate builds on jenkins.
Additionally, some jenkins builds like coverity don't need (or want)
to build clang or even the linters.
Update help with the variables.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0f8ac68c1bc8f8ff9be62d80db850355e742ee74
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This tests building a single target with scanbuild so to make sure that
option hasn't been broken. Since it's a different type of build, it
hasn't previously been tested with what-jenkins-does.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8a74dac203f4d38c0cb30a0b64724e6f9095b9dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This gets rid of the duplicated directory and xml filename and uses the
--name argument to abuild instead, which also updates the test name in
the junit xml file.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ibe538da42280696190b0a7a0c63fd86a63e40214
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Previously, the testclass variable was only updated with the chromeos
or Kconfig option values, and the output directory and xml file names
were updated independently.
With the --name option, all of these can be set simultaneously. This
also prevents jenkins from seeing clang and gcc tests as the same
because the testclass variable wasn't updated.
If --name is not set, all behavior is as it was previously.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8f52779b92d213386a3eb371d1f30ee32ed48b85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69859
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-tools target, make test-tools from what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id62d6bb1e729892ec123ea970ca8a31e03a812d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-abuild target, make test-abuild from what-jenkins-does.
The test-abuild target had not been updated to use the ABUILD_OPTIONS
variable, so update it with the commands from what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4552193894c16301defb851eb3db4bdfbfa49803
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-lint target, make test-lint with the --junit argument from
what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2f90df76126f453fbcd91f4c4af5d784ac2dbe88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having the what-jenkins-does target clean up before building,
have it call the test_cleanup target.
Clean the tegra targets.
Remove distclean from test_cleanup target - I don't think that's
expected, and people might be upset by having their .config deleted.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia9d585df05343365c89e49b1c01dba9ba865003f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
CBFS_MCACHE is currently experiencing overflow with CBFS verification
enabled. Reduce the pre-x86 cbmem console size from ~5.5 KiB to 4 KiB.
This reduction along with the available free space in PSP shared buffer
(32 KiB) helps to increase the CBFS_MCACHE size from 8 KiB to required
14 KiB.
BUG=b:259342909
TEST=Build and boot to OS in Skyrim. Ensure that there are no CBFS
mcache overflows.
FMAP: area COREBOOT found @ 80a000 (8347648 bytes)
VB2:vb2_digest_init() 0 bytes, hash algo 2, HW acceleration unsupported
CBFS: mcache @0x00019a40 built for 67 files, used 0x19a0 of 0x1c00 bytes
CBFS: Found 'apu/amdfw_a' @0x0 size 0x3ff80 in mcache @0x0001b640
VB2:vb2_digest_init() 262016 bytes, hash algo 2, HW acceleration enabled
Ensure that firmware_CbfsMcache FAFT test is successful.
Change-Id: I35e1a8c6d73e0870b6a43aac604f83a0b6c3aabe
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69827
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
If no boards are tested by abuild, an error is currently shown because
no boards failed, but no boards passed either. Account for this
possibility.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I097d3c728ca1acc652d5a1b7b49e57d01b0e513b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The patch parses CPU and PCH Trace Hub modes from the debug area in the
Descriptor Region. The modes can be updated in the debug area in order
to configure the CPU and PCH Trace Hub modes. The debug area's offset
starts from the SPI Flash offset:0xf00.
For runtime debugging, the OEM Section in the Descriptor Region is being
used as debug area. The OEM Section details are documented in the SPI
Programmer Guide of CSE Lite kit.
TEST=Build code for Gimble
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I61241c5c1981ddc4b21581bb3ed9f531da5f41b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64437
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
One register configuring multi-pin functions was outside of the Global
Configuration Registers space and skipped in the initial port patches.
Replicate the vendor configuration and set the Super I/O pin for PECI
functionality.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I90f142a1a9ee27dd061fc71b791bd4c7df97da6b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68711
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add initial CEDT (CXL Early Discovery Table) support based on
CXL spec 2.0 section 9.14.1.
Add functions to create CEDT table (revision 1), and create CEDT
CXL Host Bridge Structure (CHBS) and CXL Fixed Memory Windows
Structure (CFMWS).
TESTED=Create CEDT table on Intel Archer City CRB, dumped the
CEDT table and examined the content.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I4fbce78efc86ad9f2468c37b4827a6dadbdc6802
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
The change being reverted [1] caused all the Kconfig dependency files
to be generated at the top level of coreboot's build directory.
This reverts that behavior and puts the dependencies back where we're
used to them being.
[1] 1b9e740a81
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic4b48831705c3206e7c2e09f01d072d1cde9c9c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69535
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is a note about the default I2C speed of this being 400 kHz
despite the logic in rx6110sa.c sets the fallback (correctly) to
100 kHz.
This information originally comes from the fact the dw_i2c bus
controller default speed is 400 kHz. This is irrelevant to
the default speed of this device as it can be used with any
bus controller.
BUG=none
TEST=coreboot builds correctly (no functional changes).
Change-Id: Ic0ffe5667574c59e1c1df952b84b8a3680b53341
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69545
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After DisplayPort is plugged into type-C port, its hpd signal
instantly presents and EC has mux_info for dp and hpd. This change
fixes the DP detection flow to avoid the 1 second delay while no DP
is connected. If DP is present, there will be requests towards PMC
through the sequence of connect, safe mode, dp and hpd mode.
BUG=b:247670186
TEST=Built image and validated the DisplayPort preboot feature on Rex.
Change-Id: I7cb95ec7fcc7e1a86e86466e6d45390eedcc4531
Signed-off-by: zhaojohn <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69694
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Set `EnableTcoTimer=1` in order to keep FSP from
1) enabling ACPI Timer emulation in uCode.
2) disabling the PM ACPI Timer.
Both actions are now done in coreboot.
`EnableTcoTimer=1` makes FSP skip these steps in any possible case
including `SkipMpInit=0`, `SkipMpInit=1`, use of the MP PPI or FSP
Multiphase Init. This way full control is left to coreboot.
Port of commit 0e905801f8 ("soc/intel: transition full control over PM
Timer from FSP to coreboot").
NOTE: This will have a huge power impact when it's enabled. If TCO timer
is disabled, uCode ACPI timer emulation must be enabled, and WDAT table
must not be exposed to the OS.
BUG=none
TEST=Boot to OS on google/rex.
Excerpt from google/rex coreboot log:
[SPEW ] EnableTcoTimer = 1
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I2693f0390e6c9fa92fec366ab87589c3bcea9027
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch deselects `USE_PM_ACPI_TIMER` kconfig to ensure that
ACPI PM timer remains disabled.
The PM timer (by PMC IP) consumes more power and blocks S0ix so the
timer is emulated by ucode to save power and unblock S0ix.
TEST=Able to boot Google, Rex and ensure PMC MMIO register 0x18fc
BIT 1 is set.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2a23b417ff7fb6328323380a7df46b4b397fc8eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69685
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The coreboot build system automatically adds a `config` file to CBFS
that lists the exact Kconfig configuration that this image was built
with. This is useful to reproduce a build after the fact or to check
whether support for a specific feature is enabled in the image.
However, the file is currently generated using the `savedefconfig`
command to Kconfig, which generates the minimal .config file that is
needed to produce the required config in a coreboot build. This is fine
for reproduction, but bad when you want to check if a certain config was
enabled, since many configs get enabled by default or pulled in through
another config's `select` statement and thus don't show up in the
defconfig.
This patch tries to fix that second use case by instead including the
full .config instead. In order to save some space, we can remove all
comments (e.g. `# CONFIG_XXX is not set`) from the file, which still
makes it easy to test for a specific config (if it's in the file you can
extract the right value, if not you can assume it was set to `n`). We
can also LZMA compress it since this file is never read by firmware
itself and only intended for later re-extraction via cbfstool, which
always has LZMA support included.
On a sample Trogdor device the existing (uncompressed) `config` file
takes up 519 bytes in CBFS, whereas the new (compressed) file after this
patch will take up 1832 bytes -- still a small amount that should
hopefully not break the bank for anyone.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I5259ec6f932cdc5780b8843f46dd476da9d19728
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Instead of creating a dummy I2C device in order to force Linux to
decrease the I2C bus speed, use the own 'bus_speed' field of RV3028
device config structure.
Linux should always set the bus speed to the speed of the slowest
device sitting on the bus. Hence the dummy device is not needed
here anymore.
BUG=none
TEST=See if the RV3028 RTC is visible and working (date/time can
be set/read) in Linux. At the time, a driver modification is needed
to add a match table for the "MCRY3028" ACPI HID. A proper kernel
patch is pending.
Change-Id: I6e269dc67d1fe2a6747fcf3bee224def7b553f08
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69544
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Add ACPI generation callback to the driver after obtaining the
ACPI HID "MCRY3028" for this device from Microcrystal AG (VID: "MCRY").
Also add I2C bus speed field to the device config structure, which
is a required ACPI entry.
BUG=none
TEST=Disassemble the SSDT table and see whether the device entry
"MC28" is generated correctly. Also check whether the RV3028 driver
in Linux (drivers/rtc/rtc-rv-3028.c) is bound correctly after adding
an ACPI match table to it containing the HID. A proper kernel patch
is pending.
Change-Id: I3b8cf5c8dc551439755992ff05b6693e91cc3f21
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Issue:
Device can't wake up using power key.
Root cause and solution:
EINT event mask register is used to mask EINT wakeup sources. All
wakeup sources are masked by default. So we add a driver here to unmask
all wakeup sources.
BUG=none
TEST=wake the device up by power key on MT8188 EVB.
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Change-Id: I94b20909b0b8d77f75c41bc745f892baded7a54b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69688
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
On Herobrine, we will determine if we have an NVMe device based on SKU
id. Basically, if bit 0 is 2 (or Z), then we know that we have an
NVMe device and thus will need to go through PCIe initialization.
Otherwise, we know that we are booting an eMMC device.
BUG=b:254281839
BRANCH=None
TEST=build firmware image and boot and make sure we can boot up Tested
on villager, which does not have NVMe and made sure that it boots
still. Check cbmem dump to make sure that device configuration
entry is still low since it's not initializing PCIe devices:
40:device configuration 730,203 (1,295)
Change-Id: I1fa0ad392ba6320fdbab54b3b5dc83ac28cd20ba
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69690
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement mainboard_needs_pcie_init() for herobrine in order to
determine if we need to initialize the pcie links. When the SKU id is
unknown or unprovisioned (for example at the beginning of the factory
flow), we should still initialize PCIe. Otherwise the devices with
NVMe will fail to boot.
BUG=b:254281839
BRANCH=None
TEST=emerge-herobrine coreboot
Change-Id: I8972424f0c5d082165c185ab52a638e8b134064c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Modify the chromeos FMD file for nissa variants to redistribute the
buffer in SI_ME region obtained due to CSE size optimizations to SI_BIOS
region.
1. Modify SI_ALL region size to 3712K. SI_DESC remains at 4K and SI_ME
is 3708K.
2. Modify SI_BIOS region to 12672K. This results in an addition of 32K
buffer each to FW_MAIN_A/B regions.
BUG=b:228936671
BRANCH=firmware-nissa-15217.B
TEST=Verify CSE FW update with new FMD and ME RW blobs on craask.
Cq-Depend: chrome-internal:5094491
Change-Id: I5ead2f81850a2aa79e677c7f271db672e235750a
Signed-off-by: Krishna P Bhat D <krishna.p.bhat.d@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
+-----------+-------+-------+---------+-------------+----------+
| Setting | AC LL | DC LL | ICC MAX | TDC Current | TDC Time |
| |(mOhms)|(mOhms)| (A) | (A) | (msec) |
+-----------+-------+-------+---------+-------------+----------+
| IA | 2.8 | 2.8 | 80 | 43 | 28000 |
+-----------+-------+-------+---------+-------------+----------+
| GT | 3.2 | 3.2 | 40 | 23 | 28000 |
+-----------+-------+-------+---------+-------------+----------+
- IA TDC current from 20A to 43A.
- GT TDC current from 20A to 23A.
BUG=b:256754175
TEST=Build test image and use PTAT to check IA and GT value
Signed-off-by: Johnny Li <johnny_li@wistron.corp-partner.google.com>
Change-Id: Ife36655f077bae567bff3c3e33f779c990cf5ed9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69135
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Yang <paul.f.yang@intel.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
revert commit 1b9e740a8 (kconfig: fix failing to generate auto.conf) [1]
The above change caused all of the enabled kconfig options to be written
into the top level build directory. We don't want that, so go back to
the old behavior for the coreboot tree.
[1] 1b9e740a81
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2904f69a5d85337ad0a6b48590ccd4b4a6e38b70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Simply return the current resource settings in the _PRS method. This
means that coreboot has to correctly set up the resources on the
device. This won't result in any regression as without _PRS the ACPI
OS would not know what resources settings are valid, so it would never
use _SRS.
Change-Id: I2726714cbe076fc7c772c06883d8551400ff2baa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64218
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This patch adds unique device-locators, bank-locators and
asset-tags to the smbios type17 tables by making use of a
DIMMs controller-ID. This way we avoid name clashes when,
for example, two DIMMs share the same channel-ID and DIMM-ID
but have a distinct controller-ID.
Signed-off-by: David Milosevic <David.Milosevic@9elements.com>
Change-Id: I8aef79faa43f2475485f581c675ee152e580f678
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The dimm_info structure (defined in src/include/memory_info.h)
currently does not hold information about the DIMM's
node/controller ID.
This patch extends the dimm_info structure by adding a new field for
the node ID, called node_num. Also, adapt the dimm_info_fill()
function accordingly to populate the newly-added field.
Background: These changes are necessary for the Atlas mainboard, where
we are currently experiencing issues with the DIMMs device/bank
locator. Our 2 DIMMs share the same CHANNEL and DIMM ID but have a
distinct NODE ID. By looking at the smbios table we see
Channel-0-DIMM-0 for both DIMMs. Thus, we need their NODE IDs in order
to distinguish them.
This patch was tested by building and booting for the Alderlake-P
RVP board, which has the same DIMM slot configuration as the
Prodrive Atlas mainboard.
Signed-off-by: David Milosevic <David.Milosevic@9elements.com>
Change-Id: I6ffa5bdff0ba0e3c4a4a51f2419291fd1278cd68
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68525
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update touchscreen setting.
Change hid as panel team request to fix touchscreen with no function.
The panel team verification result is on b/251378772 comment#17.
BUG=b:251378772
TEST=Build/boot ChromeOS on winterhold, ensure touchscreen is
functional.
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: I07d446111b1c18bfe15d00b6eacff23382cd461a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
None of the touchscreens (over I2C) used in the rex program requires
exporting GPIOs in the ACPI _CRS method.
This can cause i2c devices to malfunction or cause timing
sequence violations if ACPI exports a PowerResource for the
device that uses GPIOs that are also exported in _CRS.
BUG=none
TEST=Able to build and boot Google, Rex platform.
Without this patch:
[ERROR] I2C: 00:10: Exposing GPIOs in Power Resource and _CRS
With this patch:
None
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I578a60eff27f94d6dc94b900604bc7560337d60b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69612
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As per Intel doc #627331 Section 3.6.1 "Intel CSME Production Machine
Determination", from ADL onwards there are three criteria which
determine whether a device is in production mode:
1. Fuses are programmed
2. SPI descriptor is locked
3. Manufacturing variables are locked
When logging whether the device is in manufacturing mode, 1 and 2 are
already checked. Add a check for 3 as well.
Also add logs for each individual criteria so it's easy to tell why the
overall Manufacturing Mode is set or not.
BUG=b:255462682
TEST=On a nivviks which has not gone through EOM:
Before:
[DEBUG] ME: Manufacturing Mode : YES
[DEBUG] ME: SPI Protection Mode Enabled : NO
After:
[DEBUG] ME: Manufacturing Mode : YES
[DEBUG] ME: SPI Protection Mode Enabled : NO
[DEBUG] ME: FPFs Committed : NO
[DEBUG] ME: Manufacturing Vars Locked : NO
On an anahera which has gone through EOM:
Before:
[DEBUG] ME: Manufacturing Mode : NO
[DEBUG] ME: SPI Protection Mode Enabled : YES
After:
[DEBUG] ME: Manufacturing Mode : NO
[DEBUG] ME: SPI Protection Mode Enabled : YES
[DEBUG] ME: FPFs Committed : YES
[DEBUG] ME: Manufacturing Vars Locked : YES
Change-Id: Iac605baa291ab5cc5f28464006f4828c12c748fe
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69324
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `hyper_threading` CMOS option was hooked up to the wrong enumeration
and lacked a default value in `cmos.default`. Thus, use the correct enum
for the `hyper_threading` option, remove the now-unused "backwards" enum
and provide a default value in `cmos.default`.
Change-Id: I2ee9ced2881ed5e348e84a35e8abd6b7a363d936
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69491
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When ACPI GPE0 block was extended to 64 events or 8 bytes,
ACPI PM register space was slightly modified. After
adjustment, PM2_CNT register moved to 0x50 where register
SS_CNT was previously defined to be.
For platforms that have a valid use for PM2_CNT==0x50 in
their FADT, remove overlapping definition of SS_CNT.
On i82801dx/gx ACPI GPE0 supports 32 events, reset_gpe0_status()
incorrectly addressed also GPE0_EN register. For a bit cleaner
implementation, define GPE0_HAS_64_EVENTS.
Change-Id: Iec83e9010146ebd487a61f542ac5c6f4c6a60833
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
If TSEG is not enabled, smm_region() should not reserve the region, so
add a test for T_EN flag in ESMRAMC.
For the SMM_ASEG case this moves CBMEM immediately below top-of-ram.
Change-Id: I2da4b846d0767afe00e98fdee375914c1875ddf5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
As per Intel doc #729124 Section 3.6.1 "Intel CSME Production Machine
Determination", from ADL onwards there are three criteria which
determine whether a device is in production mode:
1. Fuses are programmed
2. SPI descriptor is locked
3. Manufacturing variables are locked
When logging whether the device is in manufacturing mode, #1 and #2 are
already checked. Add a check for #3 as well.
TEST=Build and boot MTL RVP
Snippet from coreboot log:
[DEBUG] ME: Manufacturing Mode : YES
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I495a7d8730716fc92e8c57b2caef73e8bb44d30b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Update header files for FSP for Meteor Lake platform to
version 2404_00, previous version being 2364_00.
FSPM:
1. Address offset changes
2. Rename `PlatformDebugConsent` to `PlatformDebugOption`
FSPS:
1. Address offset changes
Additionally, incorporate the UPD name change for MTL romstage.
BUG=b:255481471
TEST=Able to build and boot Google, Rex to ChromeOS.
Signed-off-by: vjadeja-intel <vikrant.l.jadeja@intel.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I63ef4ecb6569141542a3b9bf4ee8cbcd2946582e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Follow Dynamic Thermal Table Switching proposal to initialize
thermal table config E as default table for SMT.
Since the dynamic thermal table switching mechanism is still
under cooking, after discussing with thermal team, suggest
adopting config E(limit Soc not reach to max power) as default
thermal config to avoid any thermal-related issue during phase
build. Once the dynamic thermal table switching mechanism
is finished, will change the default value to config A.
BUG=b:232946420, b:258572474
TEST=emerge-skyrim coreboot
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: I4aa90304e1e7bda7d580de2582129191e9eb0e76
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Create the crystaldrift variant of the skyrim reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:240970782
BRANCH=None
TEST=util/abuild/abuild -p none -t google/skyrim -x -a
make sure the build includes GOOGLE_CRYSTALDRIFT
Signed-off-by: Chao Gui <chaogui@google.com>
Change-Id: Ibb3ebaa7e4af1a03173b93b8c4fbd342f7cd7100
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Now that coreboot performs the necessary power sequencing, switch
from using the 'probed' flag to 'detect' for all I2C touchscreens.
This alleviates ChromeOS from having to probe to see which
touchscreen model is actually present, prevents breaking ACPI spec
by generating device entries with status 'enabled and present'
which aren't actually present, and improves compatibility with
upstream Linux and Windows.
BUG=b:121309055
TEST=build/boot ChromeOS and Linux on zork, ensure touchscreen is
functional, and ACPI device entry generated for correct touchscreen
model.
This mirrors the changes made for skyrim in commit 22683fab
(mb/google/skyrim: Use detect vs probed flag for touchscreens)
Change-Id: Idfe899bd535507c56f0825c6538246441b3b0827
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69457
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As all variants have a touchscreen option, in baseboard tables set the
enable GPIO high and hold in reset during romstage, then release reset
in ramstage. This will allow the touchscreen to make use of the runtime
I2C detect feature (enabled in a subsequent commit) so that an ACPI
device entry is created only for the touchscreen actually present.
This mirrors the change to skyrim in commit f90ff456
(mb/google/skyrim: Implement touchscreen power sequencing)
Change-Id: Ifdd75cd96e7b6880085a3f47214b92948a56aa2e
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69456
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch uses index 0x10 for IOE P2SB memory resource allocation
instead of static 0.
Additionally, switches to `mmio_resource` from `mmio_resource_kb`.
TEST=Able to build and boot Google/Rex and observed log as below.
Without the code change:
[SPEW ] PCI: 00:13.0 resource base 3fff0aa0000 size 1400 align 0
gran 0 limit 0 flags f0000200 index 0
With the code change:
[SPEW ] PCI: 00:13.0 resource base 3fff0aa0000 size 1400 align 0
gran 0 limit 0 flags f0000200 index 10
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I44caac73e245f536f3a22baafa1a6a0370e1dd37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
As all variants have a touchscreen option, in baseboard table set the
enable GPIO high and hold in reset during romstage, then release reset
in ramstage. This will allow the touchscreen to make use of the runtime
I2C detect feature (enabled in a subsequent commit) so that an ACPI
device entry is created only for the touchscreen actually present.
This mirrors similar changes made for skyrim, guybrush, and zork.
TEST=tested with rest of patch train
Change-Id: Id235815904dfc093549a1ed529e19974010977c7
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69547
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that coreboot performs the necessary power sequencing, switch
from using the 'probed' flag to 'detect' for all I2C touchscreens.
This alleviates ChromeOS from having to probe to see which
touchscreen model is actually present, prevents breaking ACPI spec
by generating device entries with status 'enabled and present'
which aren't actually present, and improves compatibility with
upstream Linux and Windows.
BUG=b:121309055
TEST=build/boot ChromeOS and Linux on barla/liara, ensure touchscreen
is functional, and ACPI device entry generated for correct touchscreen
model.
Change-Id: I142a6cdb6e8cef51fd925d34362a19a8736982a5
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69548
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename variant_romstage_gpio_table() to baseboard_romstage_gpio_table()
since the GPIO table comes from the baseboard (and is not overridden by
any variant).
Drop the __weak qualifier as this function is not overridden.
This mirrors similar changes made for skyrim, guybrush, and zork.
Change-Id: I772bd2d74fd6778ffaa1e0809cc53f8d43b153f3
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69546
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Disable GPIO export in ACPI _CRS for touchscreens which set the
register "have_power_resource." This eliminates the error:
[ERROR] I2C: <bus:addr>: Exposing GPIOs in Power Resource and _CRS
TEST=build/boot barla/liara, verify touchscreen functional, no error in
cbmem log.
Change-Id: Ifa8248755f346df37faf7a3182651bf190b0c33d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69549
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some nissa devices want to disable boot from SD card. Since nissa has a
single shared depthcharge target, add a program-wide fw_config to allow
disabling it.
BUG=b:253003881
TEST=With depthcharge change, set SD_BOOT_DISABLE on nivviks and check
SD card is not initialised in depthcharge.
Change-Id: I1a3a533e4e74e48d9ce4a9678b812cb62ce2066b
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69541
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SI_ME subregions were added to support using the CSE stitching tools
(cse_serger). Use of the stitching tools has been reverted and probably
won't be re-enabled soon, so the subregions are not currently used by
anything. They also don't match the actual region sizes chosen by the
FIT tool, so remove them to avoid confusion. The other option would be
to manually keep them in sync with the sizes chosen by the FIT tool, but
this would be extra manual effort without much benefit.
BUG=None
TEST=Build and boot on nivviks
Change-Id: I993e07a060445ab8de1b0e40a023e8248867c53c
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69540
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Now that we have a common init_tables in all mainboards using AMD SoCs,
both the population of the fch_pic_routing and fch_apic_routing arrays
and the definition of those arrays can be moved to the common AMD SoC
code to not have the code duplicated in all mainboards.
BUG=b:182782749
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I8c65eca258272f0ef7dec3ece6236f5d00954c66
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68853
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `hyper_threading` CMOS option was hooked up to the wrong enumeration
and lacked a default value in `cmos.default`. Thus, use the correct enum
for the `hyper_threading` option, remove the now-unused "backwards" enum
and provide a default value in `cmos.default`.
Change-Id: I56b0320f9210cde8ff58db176d2b7d2207c98aa9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69521
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rewrite the Kahlee IRQ mapping handling to be in line with the newer AMD
SoCs to allow making the largest part of the corresponding code common
for all AMD SoCs in the coreboot tree.
The PIC-mode IRQ numbers for both PIRQ_ASF and PIRQ_SDIO were 0 in the
data tables which is the PIT IRQ which looks very wrong to me, so it was
changed to PIRQ_NC. Since the ASF and likely also the SDIO controller
are unused, this shouldn't change runtime behavior. The data tables also
had non 0 and non 0x1f entries in the following locations the internal
BKDG #55072 revision 3.04 describes as unused: 0x31, 0x33, 0x35-0x37,
0x40, 0x50-0x53. The entry at 0x32 is also non 0 and non 0x1f and the
description in the BKDG says that it controls the IRQ mapping of another
internal PCI device, but that PCI device doesn't exist in the SoC.
TEST=No obvious IRQ-related breakage on google/liara
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Change-Id: I9b3bfca33d88ef3989b63f4fe6c301e0e485b7e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68851
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the new fsp_hob_iterator_get_next_guid_extension function in
fsp_find_extension_hob_by_guid instead of iterating through the HOB list
in this function.
TEST=AMD_FSP_DMI_HOB is still found and the same type 17 DMI info is
printed on the console.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4d4ce14c8a5494763de3f65ed049f98a768c40a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Drop the find_resource_hob_by_guid implementation and use the new
fsp_hob_iterator_init and fsp_hob_iterator_get_next_guid_resource
functions in fsp_find_range_hob.
TEST=Mandolin still finds the TSEG range HOB and uses the correct TSEG
location.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00786cbeea203fba195ddc953c3242be544a7d70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use the newly added functions to iterate over the FSP HOBs to report the
resources used by FSP to the resource allocator instead of open coding
the iteration over the HOBs in the SoC code.
TEST=Patch doesn't change reported resources on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67ca346345c1fa08b008caa885d0a00d2d5afb12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Introduce iterator function to go through the HOBs that will be used in
follow-up commits both from the rest of the common FSP HOB access code
and from SoC-specific code that needs to access specific HOBs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If86dde2a9f41d0ca7941493a92f11b91a77e2ae0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This disables MP table generation for the affected boards
since interrupt routing entries would now be completely missing.
The mechanism itself is flawed and redundant. The mapping
of integrated PCI devices' INTx pins to IOAPIC pins is
dependent of configuration registers and needs not appear
in the devicetree.cb files at all.
The write_smp_table implementation would skip writing
any entry delivering to destination IOAPIC ID 0. This
does not follow MP table specification.
There were duplicate calls to register_new_ioapic_gsi0(),
with another present under southbridge LPC device.
Change-Id: I383d55ba2bc0800423617215e0bfdfad5136e9ac
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69488
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The weak implementation of write_smp_table() is not useful
without DRIVERS_GENERIC_IOAPIC and related entries in
devicetree.cb. No interrupt routing entries are present
in the generated MP table.
Change-Id: I71a209e95ae1fe8c1c90b61c6ac0fb0e7bcc7eca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69490
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The weak implementation of write_smp_table() is not useful
without DRIVERS_GENERIC_IOAPIC and related entries in
devicetree.cb. No interrupt routing entries are present
in the generated MP table.
Change-Id: Ib50a7656cef40d0d3ffcc408cc0858c1dae7b9e5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Update the default processor sting from decimal to hex to increase
the default number of Processor NamedObjects from 100 to 256
ie: CP00-CP99 is now CP00-CPFF
This fixes MADT table generation for system up to 256 cores.
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Change-Id: Id60a39d99fa77d1d89ad655ddecdebcc8a422f74
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69325
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There doesn't seem to be a datasheet available for the NCT6685D, but
there is one for the NCT6686D. The 85D seems to return the same ID as
the 86D, and the registers do seem to be returning valid data other than
LDN 0xf which returns all 1s. The LDN and register layout appears to be
identical to the NCT6687D-W.
Tested on a Lenovo ThinkCentre M900 with a NCT6685D.
Change-Id: I4de0e7b86422a14ab9ccb15b7571597611d755d5
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The jenkins build complains about this now that clang has been added.
src/mainboard/emulation/qemu-q35/cpu.c:37:1: error:
attribute '__packed__' is ignored, place it after "union" to apply
attribute to type declaration [-Werror,-Wignored-attributes]
__packed union save_state {
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id8faa24239505d808d09c00d825344edc7c4b7d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Until now tcg-2.0/tss.c was just assuming certain buffer size and
hash algorithm. Change it to accept digest type, which the call sites
know.
Also drop `uint8_t *out_digest` parameter which was always `NULL`
and was handled only by tcg-1.2 code.
Change-Id: I944302b502e3424c5041b17c713a867b0fc535c4
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68745
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
This replaces 'SPDX-License-Identifier' tags in all the files under
soc/mediatek/mt8195 for better code re-use in other open source
software stack.
These files were originally from MediaTek and follow coreboot's main
license: "GPL-2.0-only". Now MediaTek replaces these files to
"GPL-2.0-only OR MIT" license.
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Change-Id: I79a585c2a611dbfd294c1c94f998d972118b5c52
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66625
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This removes the dev_index argument from the google_chromeec_reboot
API. It's always set to 0, so don't bother passing it.
BUG=b:258126464
BRANCH=none
TEST=none
Change-Id: Iadc3d7c6c1e048e4b1ab8f8cec3cb8eb8db38e6a
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69373
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot already has a ram failure post code defined, but the ram test
functions weren't using it, and were using 0xea instead.
This changes those failures to display 0xe3, the value defined in
post_codes.h by POST_RAM_FAILURE.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I21ef196e48ff37ffe320b575d6de66b43997e7eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69202
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The function pci_scan_bus had 3 post codes in it:
0x24 - beginning
0x25 - middle
0x55 - end
I got rid of the middle postcode and used 0x25 for the code signifying
the end of the function. I don't think all three are needed.
0x24 & 0x25 postcodes are currently also used in intel cache-as-ram
code. Those postcodes should be adjusted to avoid conflicting.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I19c9d5e256505b64234919a99f73a71efbbfdae3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Doing this in C code is way easier to understand. Also the thread local
storage is now in .bss instead of the AP stack. This makes it more
robust against stack overflows, as APs stacks overflow in each other.
TESTED: work on qemu.
Change-Id: I19d3285daf97798a2d28408b5601ad991e29e718
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69435
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Depending on whether qemu emulates an amd64 or i386 machine the SMM
save state will differ. The smbase offsets are incompatible between
those save states.
TESTED: Both qemu-system-i386 and qemu-system-x86_64 (v7.0.50) have a
working smihandler, ASEG and TSEG.
Change-Id: Ic6994c8d6e10fd06655129dbd801f1f9d5fd639f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55138
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Hook up the new EC driver.
Tested:
- Fn hotkeys work (brightness, display, volume, tp toggle, ...)
- Display lid
- Sleep/wake
- Camera (including Fn toggle)
- Bluetooth (both CNVi and PCIe card)
- Wi-Fi (both CNVi and PCIe card)
- CMOS options
Known issues:
- Touchpad toggle needs OS setup; see CB:68791
- UCSI is not implemented; see CB:68791
Change-Id: I6c4637936761cd62571b5d19fe2afd65560f49a0
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59850
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Hook up the new EC driver.
Tested:
- Fn hotkeys work (brightness, display, volume, tp toggle, ...)
- Display lid
- Sleep/wake
- Camera (including Fn toggle)
- Bluetooth (both CNVi and PCIe card)
- Wi-Fi (both CNVi and PCIe card)
- CMOS options
Known issues:
- Touchpad toggle needs OS setup; see CB:68791
- UCSI is not implemented; see CB:68791
Change-Id: I28ac401ada2945bb58fe862895458b10fed505fe
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68795
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a driver for the ITE IT5570E EC in combination with Clevo
vendor EC firmware. The interface is mostly identical on various laptop
models. Thus, we have implemented one common driver to support them all.
The following features were implemented:
- Basics like battery, ac, etc.
- Suspend/hibernate support: S0ix, S3*, S4/S5
- Save/restore of keyboard backlight level during S0ix without the need
for Clevo vendor software (ControlCenter)
- Flexicharger
- Fn keys (backlight, volume, airplane etc.)
- Various configuration options via Kconfig / CMOS options
* Note: S3 support works at least on L140CU (Cometlake), but it's not
enabled for this board because S0ix is used.
Not implemented, yet:
- Type-C UCSI: the EC firmware seems to be buggy (with vendor fw, too)
- dGPU support is WIP
An example of how this driver can be hooked up by a board can be seen in
in change CB:59850, where support for the L140MU is added.
Known issues:
- Touchpad toggle:
The touchpad toggle (Fn-F1) has two modes, Ctrl-Alt-F9 mode and
keycodes 0xf7/0xf8 mode. Ctrl-Alt-F9 is the native touchpad toggle
shortcut on Windows. On Linux this would switch to virtual console 9,
if enabled. Thus, one should use the keycodes mode and add udev
rules as specified in [1]. If VT9 is disabled, Ctrl-Alt-F9 mode could
be used to set up a keyboard shortcut command toggling the touchpad.
- Multi-fan systems
The Clevo NV41MZ (w/o dGPU) has two fans that should be in-sync.
However, the second fan does not spin. This needs further
investigation.
[1] https://docs.dasharo.com/variants/clevo_nv41/post_install/
Testing the various functionalities of this EC driver was done in the
changes hooking up this driver for the boards.
Change-Id: Ic8c0bee9002ad9edcd10c83b775fc723744caaa0
Co-authored-by: Michał Kopeć <michal.kopec@3mdeb.com>
Co-authored-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68791
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This EC code is for the Byte, a Cezanne Mini PC. The EC is different
to the Cezanne StarBook Mk VI. Rename it to `-desktop`, so the laptop
variant becomes the primary.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I25f812cb1c6cefca1ebbe3bee5d20cf521dd60af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68319
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When no HOB list is found, not only adding the resources reported by the
FSP were skipped, but also adding the GNB IOAPIC resource was skipped.
Fix this bug by moving the reporting of the GNB IOAPIC resource before
the resources reported in the FSP HOBs to not skip the IOAPIC resource
when there's no HOB list.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9174c8d7e5e94144187d27210e12f2dca3a6010f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69460
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The WCH CH347 presents a USB CDC serial port on interface 4 while in
operating modes 0, 1, and 3. Mode 0 also presents a UART on interface
2 but this is ignored for compatibility with the other modes. Mode 2
uses vendor defined HID usages for communication and is not currently
supported. Like the FT232H the data format is hard coded to 8n1.
Tested using a CH347 breakout board and a Dell Latitude E6400.
Change-Id: Ibd4ad17b7369948003fff7e825b46fe852bc7eb9
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68264
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Without a cast the aritmetics of
tat = einj + sizeof(acpi_einj_smi_t)
is the same as
tat = (uintptr_t)einj + size(acpi_einj_smi_t) * size(acpi_einj_smi_t)
So it overshoots the intended offset by a lot.
This issue only came apparent because now einj is in the small IMD
region which is close to TSEG. With the wrong aritmetics the tat
pointer ended up inside TSEG which is not accessible from the OS
causing exceptions.
TEST: observe that tat pointer is inside the small IMD below
TSEG (0x78000000 on our setup).
"acpi_create_einj trigger_action_table = 0x77ffe89c"
Change-Id: I3ab64b95c33eef01b2048816a21e17855bcb2f54
Signed-off-by: Arthur Heymans <arthur.heymans@9elements.com>
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Skyrim platforms have I2C3 controller which is shared between PSP and
X86. In order to enable cooperation, PSP acts as an arbitrator. Enable
SOC_AMD_COMMON_BLOCK_I2C3_TPM_SHARED_WITH_PSP, so that proper driver is
binded on the OS side.
BUG=b:241878652
BRANCH=none
TEST=Build kernel and firmware. Run on skyrim and verify TPM
functionality.
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: I2a3de8cb2b9241e2d81e02df49f317ac0408d5bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67675
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The EC_CMD_USB_PD_PORTS host command returns a
struct ec_response_usb_pd_ports, not a
struct ec_response_charge_port_count.
Luckily, both structs have the same memory layout, so this is simply a
name change.
BUG=b:258126464
BRANCH=none
TEST=none
Change-Id: I0d7710ca8a45f0ea3939f58bbba6bab31ff41919
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69370
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Simplify the implementation of setting the keyboard backlight PWM
value. Host command stubs typcially don't need to examine the host
command's return value as stored in cmd_code because that level of
detail is not very interesting. Higher value error codes are returned in
actual result structures.
This host command can return EC_RES_ERROR for out of range PWM values
which is already a generic error and unlikely to happen since we already
limit the range to 0..100 here. Finally, none of the callers in coreboot
check the return value.
BUG=b:258126464
BRANCH=none
TEST=none
Change-Id: If17bc4e31baba02ba2f7ae8e7a5cbec7f97688c5
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69369
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add an ACPI method to handle EC_HOST_EVENT_PANIC (bit 24) events.
EC panic is not covered by the standard (0-F) ACPI notify values.
Arbitrarily choosing B0 notify, which is in the 84-BF device specific
ACPI notify range.
This will be a no-op until the kernel driver is also updated to handle
this event.
BUG=b:258195448
BRANCH=None
TEST=Observe event with modified cros_ec_lpc driver
Signed-off-by: Rob Barnes <robbarnes@google.com>
Change-Id: Iafa642c1c50f9a0083a8e618e1eabec9a7ce39b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69391
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update SX9324 related settings based on tunned values from the ODM.
This patch supports both legacy and upstream Linux's SX9324 driver.
BUG=b:242662878
TEST=i2cdump -y -f 13 0x28
(Verified register values on Pujjo)
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I34d8073ffe93e6939f8da0cd7efb8667c0e9ac37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69366
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This finds all the boards using a specified Kconfig option and runs both
CrOS and non-CrOS abuilds on them to make sure they're working.
Nobody wants to run the full what-jenkins-does build on their host
machine. Hopefully this can help get some tests run locally before
pushing to coreboot.org.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ifc71c28bf64a805f203a815a9468ff9fe882aad3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The deadlock prevention is also needed with CONFIG_X2APIC_RUNTIME when
the cpu is in x2apic mode.
TESTED: Fixes SMI generation on xeon_sp hardware with
CONFIG_X2APIC_RUNTIME.
Change-Id: I6a71204fcff35e11613fc8363ce061b348e73496
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67239
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
DTTS is Dynamic Thermal Table Switching Proposal.
DTTS needs one bit to save the body detection result from EC.
Define mode change STTB bit for Desktop (1) and laptop (0).
This bit is Switch thermal table by body detection status.
BUG=b:232946420
TEST=emerge-skyrim coreboot
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: I37b3a0d8f6546361c8d5501e98e3e1b0d814fce3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68077
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit eb76a455cd
and applies minor fixes to make it build again.
PARALLEL_MP was working prior to board removal and no
relevant SMI handlers were implemented. So NO_SMM choice
is now selected.
Change-Id: Ia1cd02278240d1b5d006fb2a7730d3d86390f85b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of including pci_int_defs.asl in each board's DSDT, include it
in the common soc.asl. This moves the PRQM OperationRegion and the PRQI
IndexField defined in pci_int_defs.asl into the \_SB scope, but those
are defined inside the \_SB scope both in the Picasso reference code and
for the AMD SoCs from Cezanne on.
TEST=Both Linux and Windows still boot and don't show ACPI errors on
Mandolin after moving this inside the \_SB scope
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib4e7bfb15de184cc43cd17c8249be0f59405793f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
This code was never tested with SSE enabled. Now qemu enables it and
FX_SAVE encroaches on the save states. Without SSE enabled the handler
just happened to be aligned downwards enough to have the save states
fit. With SSE enabled that's not the case. The proper fix is to give the
code setting up stubs the right base address, which is the same as for
the TSEG codepath.
Change-Id: I45355efb274c6ddd09a6fb57743d2f6a5b53d209
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69233
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
In Linux, the I2C speed defaults to 400 kHz if there is no device
registered in ACPI which requests a different speed. Due to board
limitations (layout, bus load), 400 kHz are too fast which results in a
timing violation. Therefore, add a dummy I2C device to both used I2C
buses (I2C1 and I2C2) with a speed of 100 kHz. This will limit the bus
speed in Linux accordingly.
Change-Id: I507c53c9ec7f763cef18903609231b1a66ed98fa
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
According to measurements Elkhart Lake seems to drive the internal I2C
controllers with 100 MHz instead of the common 133 MHz. The datasheet
itself is quite vague on this definition, just one place mentions that
it is 100 MHz (register description for offset 0x94).
This patch changes the I2C controller base frequency to 100 MHz. The
verification was done by measuring the set up resulting I2C clock for
both 100 and 400 kHz.
Change-Id: I7c826bbb01b53e3661746e49f25441565068d1c2
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
There are SoCs (for instance Intel Elkhart Lake) that do use 100 MHz as
the base clock for I2C controllers. To support them properly add a
frequency setting for 100 MHz to the designware I2C controller driver.
Change-Id: I9ea11c6a41fd3758b771a416251e108cbe722769
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
On certain mainboards due to hardware design limitations, certain SPI
Read Modes eg. (Dual I/O 1-2-2) cannot be supported. Add ability to
override SPI read modes in boards which do not have hardware
limitations. Currently there is an API to override SPI fast speeds.
Update this API for mainboards to override SPI read mode as well.
BUG=b:225213679
TEST=Build and boot to OS in Skyrim. Observe a boot time improvement of
~25 ms with 100 MHz SPI speeds.
Before:
11:start of bootblock 688,046
14:finished loading romstage 30,865
16:FSP-M finished LZMA decompress (ignore for x86) 91,049
Total Time: 1,972,625
After:
11:start of bootblock 667,642
14:finished loading romstage 29,798
16:FSP-M finished LZMA decompress (ignore for x86) 87,743
Total Time: 1,943,924
Change-Id: I160b56f6201a798ce59e977ca40301e23ab63805
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
SX9324 driver is updated per Linux's documentation found at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml
Supporting logic for the deprecated SX932x driver is hence guarded by
DRIVERS_I2C_SX9324_SUPPORT_LEGACY_LINUX_DRIVER
This patch by itself does not introduce functional changes to any board.
The legacy SX932x Linux driver never reached upstream Linux and is only
available in ChromeOS kernel fork of 4.4 and 5.4. Linux later accepted
a different implementation named SX9324 and has been available since
5.4. Ideally all variants should adopt the new driver; however, during
the transition phase, coreboot must support both drivers. It is better
to have a single firmware build that can work with both Linux kernel
drivers by specifying both sets of properties. Legacy driver support
should be deleted once all variants finish migration.
BUG=b:242662878
TEST=Dump ACPI SSDT then verify _DSD entries related to the legacy
SX932x driver are identical w/ and w/o this patch
(Tested on Craask and Nivviks)
Change-Id: I42cd6841c3a270c242ed2e739db245e858eadb3b
Signed-off-by: Victor Ding <victording@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69192
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add Fingerprint SPI, and power-off FPMCU during romstage.
For reference see CL:66915 for a similar change to Brya's power sequence
SHA: 2b523ce631 ("Invoke power cycle of
FPMCU on startup")
TEST=Tested on Rex - setup and logged in using fingerprint
Change-Id: I4e6be24e72a8232ae2c958a01cf8ea9a272d7365
Signed-off-by: Eran Mitrani <mitrani@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66992
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch introduces support signing and verification of firmware
slots using CBFS metadata hash verification method for faster initial
verification. To have complete verification, CBFS_VERIFICATION should
also be enabled, as metadata hash covers only files metadata, not their
contents.
This patch also adapts mainboards and SoCs to new vboot reset
requirements.
TEST=Google Volteer/Voxel boots with VBOOT_CBFS_INTEGRATION enabled
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I40ae01c477c4e4f7a1c90e4026a8a868ae64b5ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66909
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel FSPs of XEON server platforms define FSPX_CONFIG
instead of FSP_X_CONFIG, which is expected by coreboot.
Re-define in the common code.
Update coreboot code to use FSP_X_CONFIG consistently.
Tested=On OCP Delta Lake, boot up OS successfully.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Change-Id: Ifa0e1efa1618fbec84f1e1f23d9e49f3b1057b32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The functions create_bpdt_hdr and create_cse_layout
in bpdt_1_6.c are defined to return pointers but
not integers as was previouly implemented.
Reported-by: Coverity(CID:1469323)
Reported-by: Coverity(CID:1469353)
Signed-off-by: Solomon Alan-Dei <alandei.solomon@gmail.com>
Change-Id: Idb78d94be7a75a25ad954f062e9e52b1f0b921dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This patch replaces static index 0 for PMC read resources with PCI
configuration offset 0x10 (PWRMBASE).
TEST=Able to build and boot Google, Rex to OS.
Without this change:
[SPEW ] PCI: 00:1f.2 resource base fe000000 size 10000 align 0 gran
0 limit 0 flags f0000200 index 0
With this change:
[SPEW ] PCI: 00:1f.2 resource base fe000000 size 10000 align 0 gran
0 limit 0 flags f0000200 index 10
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iee2523876a8045e70effd5824afc327d1113038b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Fix readouts from the hardware monitor on Fintek F71808A Super I/O.
The HWM port is +5 to the base address stored in LDN 0x4 at index 0x60/0x61.
Referred to util/superiotool/winbond.c and the Linux kernel driver f71882fg.
Tested on a HP 500-319na (Memphis-S / IPM87-MP).
Signed-off-by: Ravi Mistry <rvstry@protonmail.com>
Change-Id: I2b2b98c62f9305c6f4885c2ce3b1444801dcb9d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The headers added are generated as per FSP v3361.07
In the future, when Alder Lake and Raptor Lake fsp align, Raptor Lake
fsp headers can be deleted and Raptor Lake soc will also use headers
from alderlake/ folder.
BUG=b:254054169
BRANCH=firmware-brya-14505.B
TEST=Boot to OS
Signed-off-by: Selma Bensaid <selma.bensaid@intel.com>
Change-Id: If486867477c88ad3e2ec5041ef94a0c364f5dfd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Enable x86 SHA accelerator for use by VBOOT library. This is useful when
CBFS verification verifies the hash of the file being loaded in x86.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim. Observe a boot time improvement of
~10 ms with CBFS verification enabled.
Change-Id: I14efe7be66f28f348330580d2e5733e11603a023
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68954
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently build rules allow using x86 SHA extensions for all coreboot
stages when enabled. On some SoCs where verstage can run in non-x86
environment, x86 SHA extension cannot be used. Update build rules
accordingly such that x86 SHA extensions can be used in AMD SoCs. This
is particularly useful when CBFS verificiation is enabled which verifies
the hash of the CBFS file being loaded.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim. Observe that hardware acceleration
is used when a CBFS file is loaded and observe an overall improvement of
10 ms.
Change-Id: I4f388e963eb82990cda41d3880e66ad937334908
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68953
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
RTD3,_ON method sometimes can create delays during system boot.
Even when the power is already up, kernel still tries to call _ON
method to power up device, but it's unnecessary.
RTD3._STA returns device power, so _ON method can check _STA and see
if the power on process can be skipped
BUG=b:249931687
TEST=system can boot to OS with RTD3 pcie storage and save ~80 ms on
Crota. Suspend stress test passes 100 cycles
Change-Id: I296ce1b85417a5dbaca558511cd7fc51a3a38c84
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This contains the following commits:
* 835724d: mainboard/starlabs/starbook: Update the EC binaries
for StarLabs
* ecbe941: soc/mediatek: Update capitalization of coreboot
* 0e4444e: soc/mediatek/mt8188: Update MCUPM firmware from
v1.01.02 to v1.01.03
* 88570f6: mainboard/starlabs/starbook/adl: Update the EC binary
to 1.01 by Sean Rhodes
* f8e84db@ mainboard/starlabs/cezanne/starbook: Add EC binary
1.02 by Sean Rhodes
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I7afd43102718f211fe8d4fd69061dcdce5bfc323
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now that coreboot performs the necessary power sequencing, switch
from using the 'probed' flag to 'detect' for all I2C touchscreens.
This alleviates ChromeOS from having to probe to see which
touchscreen model is actually present, prevents breaking ACPI spec
by generating device entries with status 'enabled and present'
which aren't actually present, and improves compatibility with
upstream Linux and Windows.
BUG=b:121309055
TEST=build/boot ChromeOS and Linux on guybrush, ensure touchscreen is
functional, and ACPI device entry generated for correct touchscreen
model.
This mirrors the changes made for skyrim in CB:67779.
Change-Id: Ib6a76b969d3a245eccde5352231eb7e36736f2e0
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
As all variants have a touchscreen option, in baseboard table set the
enable GPIO high and hold in reset during romstage, then release reset
in ramstage. This will allow the touchscreen to make use of the runtime
I2C detect feature (enabled in a subsequent commit) so that an ACPI
device entry is created only for the touchscreen actually present.
Variants/SKUs which do not have a touchscreen (if any) can use the
romstage/ramstage GPIO override tables to set the associated enable/
reset GPIOs to NC.
This mirrors the change to skyrim in CB:67778.
BUG=b:121309055
TEST=build/boot guybrush with rest of patch series
Change-Id: I9b3356b8b3a0e68a307838a4b18775d25b32e548
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The patch sets the EPP to 50% (0x80) for Vell. With EPP at 50%, the Vell
system demonstrated better power improvement without sacrificing the
performance.
PLT Results(Perf) with EPP@40% and EPP@50%:
EPP@40%: Device1-656 mins, Device2-664 mins.
EPP@50%: Device1-678 mins, Device2-677 mins.
In short, with EPP@50%, PLT KPI ran for more than 13 to 22mins compared
to EPP@40%.
Branch=firmware-brya-14505.B
BUG=b:215526166
TEST=Verified code build for Vell board
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I41b15b84025d25cf59dac2d85826a3de9d725bae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Only a subset of variants has proximity sensors.
This patch by itself does not introduce functional changes to any board.
It is mainly to ease migrating SX9324 from the legacy driver to the
linux one - allowing gradual migration variant by variant.
BUG=b:242662878
TEST=Dump ACPI SSDT then verify they are identical w/ and w/o this patch
Change-Id: Ic00e0d9eafcef2c9eaf32571fecf6190777cec36
Signed-off-by: Victor Ding <victording@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69191
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIO debounce timebase bit 4 is only 183uS on Picasso. On the other
SoCs it is 244uS. This affects the 1mS and 2mS actual debounce times
slightly.
Time PCO Others
1mS 0.915mS 1.220mS
2mS 2.013mS 2.684mS
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Id84bef75e6ab134778721ca269d763a4bb2ddde5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69209
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fingerprint(FP) feature is only for volmar,and it's not for zavala.
Add FPMCU_MASK field in fw_config to disable the FP function for
zavala, and reserve FP function for shipped volmar.
Define the value as following:
field FPMCU_MASK 10
option FPMCU_ENABLED 0
option FPMCU_DISABLED 1
end
BUG=b:250807253
TEST=build firmware and verify the fp function in volmar DUT.
write `disable=1` and 'enable=0' in FPCMU_MASK field.
check the fp function and run `ectool --name cros_fp version`
It works as expected.
Signed-off-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Change-Id: I867771904811459697056662d5e29c545a1a9474
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68917
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In function 'set_power_limits' there is a path to bail out early if the
Kconfig switch SOC_INTEL_DISABLE_POWER_LIMITS is selected. In this case
reading the MSR PLATFORM_INFO is useless and can be avoided. So read it
right before the value is needed.
This was found by the scanbuild.
In addition, fix an unnecessary line break to increase code readability.
Change-Id: Ibdededdfd56287fb9b9223e78033a3cd6425e1a2
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO. I'm making this an error because we should really clean these up.
BUG=b:210694108
TEST=Boot guybrush and see error:
> I2C: 02:5d: ERROR: Exposing GPIOs in Power Resource and _CRS
> \_SB.I2C1.H05D: Goodix Touchscreen at I2C: 02:5d
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifcc42ed81fff295fb168a0b343e96b3a650b1c84
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Morgana/Glinda have a different register mapping for data fabric access,
although the registers themselves are mostly compatible. The register
layouts defined by each soc capture the differences and the common code
can use those.
Move the register offsets to soc headers and update the offsets for
morgana/glinda per morgana ppr #57396, rev 1.52 and glinda ppr #57254,
rev 1.51
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9e5e7c85f99a9afa873764ade9734831fb5cfe69
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The DDR RFIM is a frequency shifting RFI mitigation feature required by
the Intel integrated Wi-Fi firmware(CNVi) for Meteor Lake. Please refer
to Intel technical white paper 640438_Intel_DDR_Mem_RFIM_Policy_Enable
once it is externally available. This change has backport changes from
commit hash 6f73a20 (soc/intel/alderlake: Move CnviDdrRfim property to
drivers) and provides the CNVi RFIM support for Meteor Lake.
BUG=b:248391777
TEST=Booted to OS on Rex. Looked the DDR_DVFS_RFI_CONFIG_PCU_REG
register at the offset 0x5A40 of Mchbar and verified the BIT0
(RFI_DISABLE bit) is 0.
Change-Id: I87110bc10b98a27a8f274680597b15a1df488824
Signed-off-by: zhaojohn <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67789
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of having callbacks into serial console code to set up the
coreboot table have the coreboot table code call IP specific code to get
serial information. This makes it easier to reuse the information as the
return value can be used in a different context (e.g. when filling in a
FDT).
This also removes boilerplate code to set up lb_console entries by
setting entry based on the type in struct lb_uart.
Change-Id: I6c08a88fb5fc035eb28d0becf19471c709c8043d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68768
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add an option on Atlas to enable IBECC (In Band Error Correction Code),
which is currently needed for endurance testing.
Test: start atlas mainboard with Linux. See in dmesg that
IBECC (EDAC igen6) driver is loaded. Inject a fake error via debugfs
and see in dmesg that Linux handles it.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I71ee2401136e2dc70b3164db6c99af03a3e1f346
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Instead of having the config option PAYLOADS_NONE inside the choice of
payloads, make that a separate choice that enables the payload menu.
If the no_payload option is selected, this hides the other options
and keeps them out of the saved config file and config.h
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I932c65630261a5b39809abf4dfbda5bf932c6684
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
EWL (Enhanced Warning Log) is a FSP HOB generated by FSP-M that may
contain several warnings/errors related to core, uncore and memory, etc.
mainboard can override it in its romstage.c for its own
Enhanced Warning Log check.
Change-Id: I6f542e71d20307397c398fd757d9408438f681ed
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69143
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some of the cbmem area names have gotten longer, and were making the
output of cbmem -l look bad, so expand the name area to 20 characters.
Instead of printing a blank area if the name isn't recognized, call it
unknown.
Change the method of printing the title to match the way the actual text
of the table is printed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I9d91d21c6ad418d9fee9880550fb6cb9e41e93f0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This reverts commit a8172c329f.
In the aforementioned patch, we allowed MCUPM to access secure
registers and set the domain to DOMAIN_2.
Additional attribute settings are also required when a hardware is
set to a specific domain. Otherwise, there would be violation between
hardware. Since MT8188 is in bring-up stage, we simply enable access
register permission for the DOMAIN_0 by default. So remove the wrong
setting for MCUPM, SCP and SSPM.
We will complete DEVAPC setting when the settings are confirmed.
Change-Id: I5d9809f6e84b8d10bc2e6f2ea5a442e676ad3bf9
Signed-off-by: Liju-Clr Chen <liju-clr.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69139
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, we're building support for all memory types into every board,
and letting the linker remove anything that isn't needed. This is okay,
but it'd be nice to be able to build in just what's actually needed.
This change adds options to specify both what is used and what is not.
By doing it that way, the default values don't change, but platforms can
start removing support for memory types that are not needed. When all
platforms (SoCs, CPUs and/or Northbridge chips) specify what memory
types they support, the defaults on the options to use a particular
memory type can be set to no, and the options not to use a memory type
can be removed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I07c98a702e0d67c5ad7bd9b8a4ff24c9288ab569
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68992
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This reverts commit 1bb9786da3 ("cpu/x86/mp_init.c: Set a bogus
initial lapic_id"), since it breaks MP init on amd/mandolin:
[INFO ] CPU #0 initialized
[INFO ] Initializing CPU #3
[INFO ] Initializing CPU #1
[INFO ] Initializing CPU #2
[EMERG] CPU: missing CPU device structureCPU: vendor AMD device 810f81
[DEBUG] CPU: family 17, model 18, stepping 01
[DEBUG] microcode: patch id to apply = 0x08108109
[INFO ] microcode: being updated to patch id = 0x08108109 succeeded
[INFO ] CPU #1 initialized
[ERROR] MP record 3 timeout.
[INFO ] bsp_do_flight_plan done after 1206 msecs.
[ERROR] MP initialization failure.
[EMERG] mp_init_with_smm failed. Halting.
TEST=The board boots again with the revert applied
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic1cae88f7345f9ff79e8f6e574521095b57c8cb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69186
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The current tool is a shell script that mixes data collection and HTML
generation and is generally a pain to work with. It takes 15 minutes to
run.
The new tool is written in go, collects all data first, then generates
the output HTML from the data and a single template, and finishes in
10 seconds.
The goal in this version is to produce output as similar as possible to
the output of the shell script. Some difference will remain because the
shell script returns some trash data whose reproduction would require
more effort than is worth.
Change-Id: I4fab86d24088e4f9eff434c21ce9caa077f3f9e2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59958
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Add function needed to generate ACPI backlight control SSDT, along with
Kconfig values for accessing the registers.
Tested by adding gfx register on system76/lemp11. Backlight controls
work on Windows 10 and Linux 6.1.
Change-Id: I1cc33bf0121ff44aea68a7e3615c5e58e2ab6ce2
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69076
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
To make it easier to build the tests with debug symbols, add a check for
the "GDB_DEBUG" environment variable. If set, build with -g and -Og to
enable the symbols and disable optimization.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3a644dcccb7e15473413b775da8f70617afaefce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Replace `while (...);` with `do {} while (...);` so that it's easier to
distinguish polling loops from something else, like function calls. The
`{}` can be understood as "nothing", so that the construct is naturally
read as "do nothing while (...)".
Another reason to prefer this method is that Jenkins does not complain.
Change-Id: Ifbf3cf072f8b817b2fdeece4ef89bae0822bb6e6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Correct the capitalization of ELOG_CROS_DIAG_TYPE_STORAGE_HEALTH from
"Storage Health Info" to "Storage health info", which is already widely
used in depthcharge diagnostics tools.
BUG=b:254405481
TEST=none
Change-Id: Ia6c1df9e8d2ee6f8ae11b962e76b52f3c6663c42
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Now that coreboot performs the necessary power sequencing, switch
from using the 'probed' flag to 'detect' for all I2C touchscreens.
This alleviates ChromeOS from having to probe to see which
touchscreen model is actually present, prevents breaking ACPI spec
by generating device entries with status 'enabled and present'
which aren't actually present, and improves compatibility with
upstream Linux and Windows.
BUG=b:121309055
TEST=build/boot ChromeOS and Linux on skyrim, ensure touchscreen is
functional, and ACPI device entry generated for correct touchscreen
model.
Change-Id: Id9e3089decf0f94a1358929684ce248e52cbe41f
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Leakage from the SPI CS line onto the FPMCU VDD rail was preventing
the FPMCU from fully shutting down on AP reset.
Instead of simply turning off the power rail, now ensure the CS
line is not driven high until late in coreboot.
This ensures it is completely off for the requisite minimum of 200ms
(now measured at approx 1100ms).
BUG=b:245953688
TEST=Confirmed FPMCU is still functional on Kohaku.
Confirmed FpRebootPowerCycle unit test now passes
BRANCH=Hatch
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: I1e7e32f61c3ac1b3154d42821cc1dd4c5d3de303
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68819
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to Intel doc# 575683 the PECI bus should be low when idle and
is pulled up by clients with strong drive. However, for unknown reasons
the bus stays high on this board, blocking s0ix entry.
The PECI reference schematic in the ASPEED AST2400 BMC datasheet
(actually not related to this board) says that a pull-down is *required*
for the idle state.
This might be just a requirement of this BMC, since this is nowhere
documented in Intel datasheets, schematics or elsewhere. However,
configuring a weak pull-down (20 k) on the PECI pad indeed solves this
problem for now.
Change-Id: I85193000af67cd2c0465bdbb58cdd51b68fd5b4f
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68794
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to Intel doc# 575683 the PECI bus should be low when idle and
is pulled up by clients with strong drive. However, for unknown reasons
the bus stays high on this board, blocking s0ix entry.
The PECI reference schematic in the ASPEED AST2400 BMC datasheet
(actually not related to this board) says that a pull-down is *required*
for the idle state.
This might be just a requirement of this BMC, since this is nowhere
documented in Intel datasheets, schematics or elsewhere. However,
configuring a weak pull-down (20 k) on the PECI pad indeed solves this
problem for now.
Change-Id: Ib5a6b0ad3553c2cf795037d6a1982102bcb04644
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68793
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To support an RPL SKU on gladios, gladios must use the FSP for RPL.
Select SOC_INTEL_RAPTORLAKE for gladios so that it will use the RPL
FSP headers for gladios.
BUG=b:239513596
BRANCH=None
TEST=FW_NAME=gladios emerge-brask intel-rplfsp
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage
Signed-off-by: Kevin Chiu <kevin.chiu.17802@gmail.com>
Change-Id: Ic30f7fe30eb0a3151cdf46fff609819056b2fbfe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Enable the MEI in device trees of some Ibex Peak, Cougar Point and
Panther Point boards where they have been disabled.
Change-Id: I4327d19d3ed1a93a6466057f6eceed49ab9441c5
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Assuming variants have a touchscreen by default, set the enable GPIO
high and hold in reset during romstage, then release reset in ramstage.
This will allow the touchscreen to make use of the runtime I2C detect
feature (enabled in a subsequent commit) so that an ACPI device entry
is created only for the touchscreen actually present.
Variants/SKUs which do not have a touchscreen (if any) can use the
romstage/ramstage GPIO override tables to set the associated enable/
reset GPIOs to NC.
BUG=b:121309055
TEST=build/boot skyrim with rest of patch series
Change-Id: Ic4d7ac8f951bb94da2216a24dc85a96275c9d449
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Only minor changes in kconfig this time that shouldn't
affect us.
TEST=`util/abuild/abuild -C` output (build.h and build.conf) remains
the same
Change-Id: I77cc8517128a973c345c41da2c483b78eeaee89f
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Only minor changes in kconfig this time that shouldn't
affect us.
TEST=`util/abuild/abuild -C` output (build.h and build.conf) remains
the same
Change-Id: Icc83c929dd1ea2d98e1a789560ce26886ded1f12
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68914
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Only minor changes in kconfig this time that shouldn't affect us.
TEST=`util/abuild/abuild -C` output (build.h and build.conf) remains
the same
Change-Id: I46f43182ce9ec1b6a5923cb77dcd6e335e44c87a
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Linux 5.16 saw a significant rewrite in the boolean handling which
reduces our change set. On the other hand, it's all new code.
Comparing the config.build and config.h files generated by
`util/abuild/abuild -C`, only a few lines of comment in the header
changed.
Change-Id: I52984e15a48236ddf228707aec85e90f71aa4382
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66045
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
- X86 architecture is maintained, so mark it as such.
- Legacy AMD chips are supported for odd fixes.
- Remove maintainers whose emails are bouncing.
- Remove maintainers who don't have +2 rights in gerrit.
- According to the instructions, we should use S: Orphan, not Orphaned.
- Update incorrect email addresses.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib6d47a8c34482c81ff96dbeec760852cba01dabc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68709
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
- AMD reference boards are maintained at least for odd fixes.
- Google panther has become a variant of Beltino, so remove it.
- Remove people whose email addresses are bouncing email.
- Remove people who responded to my email about being a maintainer and
asked to be removed.
- Alphabetize list
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic6ecaae77df2f2edaf724160bce04c038cbd115e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68707
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The mainboards are broken out into individual entries in hopes that it
will be easier for someone to claim ownership than if they were lumped
into a single "Orphaned Mainboards" group.
The theory behind this is that a single mainboard is really the easiest
piece of coreboot to maintain. Hopefully some less-experienced people
will be interested in stepping up to take over ownership of a mainboard.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I9542b3a7cd87fa8656bc0982c08061e9d0513745
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Don't set bit 2 in _STA in order for Windows not to show a warning about
an unknown device in the device manager for this device. Since the _STA
object just returns a constant, a name definition can be used instead of
a method definition.
TEST=The unknown device with device instance path ACPI\AAHB0000\0
disappeared from the device manager in Windows 10 build 19045 on a
Mandolin board with a Picasso APU.
Just shutting down and then booting it again won't clear some internal
state in Windows, so a reboot is needed instead for the change to become
visible.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8cb1712756c3623cc3ea16210af69cde0fa18f62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The SPD data for DRAM init has moved into the hwinfo data structure and
is therefore not used from spd.bin anymore. spd.bin will not receive any
updates, changes will only be done in hwinfo. There is no reason to keep
spd.bin around so remove it for both variants.
Change-Id: Ie6091b655ba7ff2e01b684266ce34b85593b8623
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch ensures the P2SB PCI device resource is getting reserved
so that the resource allocator is not assigning this resource to any
other PCI device during the PCI enumeration.
BUG=b:254207628
TEST=Able to ensure on the Google/Rex device, the PCI enumeration
is not assigning the P2SB BAR (0xE000_0000) to TBT Root Port3.
Instead the 0xE000_0000 address is being assigned to the P2SB
PCI device.
Without this patch:
[SPEW ] PCI: 00:07.3 resource base e0000000 size c200000 align
20 gran 20 limit ec1fffff flags 60080202 index 20
[DEBUG] GENERIC: 1.0
[DEBUG] NONE
[SPEW ] NONE resource base e0000000 size c200000 align 12 gran
12 limit ec1fffff flags 40000200 index 10
With this patch:
[SPEW ] PCI: 00:07.3 resource base e1000000 size c200000 align
20 gran 20 limit ed1fffff flags 60080202 index 20
[DEBUG] GENERIC: 1.0
[DEBUG] NONE
[SPEW ] NONE resource base e1000000 size c200000 align 12 gran
12 limit ed1fffff flags 40000200 index 10
......
[DEBUG] PCI: 00:1f.1
[SPEW ] PCI: 00:1f.1 resource base e0000000 size 1000000 align
0 gran 0 limit 0 flags f0000200 index 10
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib0789b442af23f6be81c666e284633ef342dffe0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Acpigen inline helper functions are causing problems while compiling
coreboot with function instrumentation. Sometimes functions are not
inlined and are causing linking errors. Forcing inlining fixes problems
like that, as these functions would normally be inlined anyway.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ibf747573940fe5e76199f327f4e5bc32b4f8c470
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
This allows platforms that support AMD's STB (Smart Trace Buffer) to
print the buffer at various points in the boot process.
The STB is roughly a hardware assisted postcode that captures the
time stamp of when the postcode was added to the buffer. Reading
from the STB clears the data.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8d78c0e86b244f3bd16248edf3850447fb0a9e2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Update touchscreen setting.
ELAN900C is the I2C over hid device with slave address 0x10.
MELF0410 is the pure I2C device with slave address 0x34.
The LCD team verification result is on b/251378772 comment#11.
BUG=b:251378772
TEST=Build/boot ChromeOS on winterhold, ensure touchscreen is
functional.
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: I568346d2abc39d9427e49c3b21f38db0184b8b44
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
The line length limit in coreboot's coding style guidelines applies to
the final file, while checkpatch currently checks the patch line length.
Since patches´ lines start with a `+` (only added content is checked),
the line length being checked is one character longer than the actual
content.
Increase max_line_length by 1 to take this into account.
Change-Id: I8da45bb0d5fbe7d0e12c8b181cf01e5685186bf6
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
The patch fixes the typecasting issue, that is conversion from 'int' to
'unsigned long long int'. This changes value from '0x8000 0000' to
'0xFFFF FFFF 8000 0000'.
During unit testing, the argument is getting changed to an unexpected
number which is resulting to an exception when IA32_HWP_REQUEST MSR is
updated. In this update, the MSR's reserved bits are getting updated, so
this causes exception.
TEST= Verified the code on the Gimble.
No exception is seen after the fix.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I35d382c792b9df260381b7696f3bbff43d6c4dc2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
ELAN updated the datasheet of component 4599 (qualification 10511)
to version 0.6 (upload date: Oct 24, 2022), decreasing i2c delay
during power-on sequence from 300 ms to 150 ms.
BUG=b:232893949
TEST=Manually checked touchscreen works after reboot and suspend
(on kernel v5.10)
Signed-off-by: Paz Zcharya <pazz@google.com>
Change-Id: I17e1f7d419637f6dff4049484ce1836ad98017ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68868
Reviewed-by: Eran Mitrani <mitrani@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Adjust timeout for final SIPI to satisfy some to-be-launched
server processors.
Add a spew print to display how long it takes for the APs
to be ready. This is intended to facilitate only troubleshooting
and trend analysis.
Change-Id: Id958f18bdcb34d76df8aa443161123252524328e
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68262
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for Haswell.
Currently BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is selected for
CPU_INTEL_HASWELL (see [2]). However, there seems to be no
particular reason on those platforms. Flashconsole works on Broadwell,
at least, and it writes to flash as early as bootblock. Therefore,
remove BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES, so that VBOOT_VBNV_FLASH
can be enabled.
[1] https://issuetracker.google.com/issues/235293589
[2] commit 6c2568f4f5 (CB:45740)
drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config
BUG=b:235293589
TEST=./util/abuild/abuild -t LENOVO_THINKPAD_T440P -a (with VBOOT)
Change-Id: If1430ffd6115a0bc151cbe0632cda7fc5f6c26a6
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch helps to save 10.200ms of booting time without any issue
seen during MP Init. All cores are out from reset and alive.
Additionally, no performance degradation is observed while running
benchmarks.
Refer to Intel Technical White Paper number:751003 for more details.
BUG=b:211770003
TEST=Able to boot to ChromeOS with all cores are enabled.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I1886bc5e60c2f6bc1e2f9d3c8d9c11799d2b53c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Enable early POST code output for this mainboard, using
the NC FPGA device on PCIe.
This requires the parent PCI bridge to be initialized early.
BUG=none
TEST=boot on siemens/mc_apl2 and observe whether the POST
codes coming from before FSP-M init are visible
Change-Id: Ice5fe26e11d0513e6bb0a20f1d8f0483d7b3dc6a
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The brask DDR4 is set to interleave, due to the limited number of
gaelin PCB layers and the traces need to be smooth,
we will use non-interleave for gaelin DDR4.
BUG=b:255399229, b:249000573
BRANCH=firmware-brya-14505.B
TEST=Build "emerge-brask coreboot" and pass MRC memory training
Change-Id: I34413343e3f7c283f49fbbdd277d9da39c09f9f8
Signed-off-by: Raymond Chung <raymondchung@ami.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68806
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Updating from commit id b827ddb9:
2022-09-01 06:37:33 +0000 - (tests: Ensure auxfw sync runs after EC sync)
to commit id 148e5b83:
2022-10-25 09:36:59 +0000 - (Makefile: Fix and simplify the RUNTEST test wrapper)
This brings in 28 new commits:
148e5b83 Makefile: Fix and simplify the RUNTEST test wrapper
a9c47c41 futility/cmd_show: set uninitialized variable
e18a6cda gscvd: presume GBB flags are zero when hashing the RO space contents
0b0aee9c gscvd: refactor discovering GBB in the image
ff1749cb futility: add option to save ro_gscvd section in a blob
84c65cd3 vboot_reference: Check OS/firmware mismatch and report to UMA
9a1be550 cmd_update: avoid variable name aliasing
d0f7fdf6 treewide: Fix copyrights and extra new lines at end of file
0ca75fd1 tpm_lite: Fix copyrights, line endings, extra new lines at end of file
4ca43a34 crossystem: arm: Retry if we fail to read a GPIO
f1a7efc0 futility: updater: Scan patch files for the signer_config manifest
64803227 futility: updater: Support patching GSCVD
2aa69d0c futility: Remove validate_rec_mrc command
0ca7a9e4 firmware: host: futility: Add CBFS metadata hash support
aaeb307f futility: Use ccd update mode for suzyq ti50
aa44b7cf vboot: gbb_flags_common should treat ccd_ti50 like ccd_cr50
ff8bb2d9 futility: Address double free
6a33a0fc treewide: Fix license headers to conform with linter
b2b4f767 DIR_METADATA: Add V2 Test Plans.
5346938c futility gscvd: add option to print out root key hash
5790c0aa gscvd: add support for reading ranges from the image
499e5743 gbb_flags_common.sh: Restore tmpfile cleanup trap
f3f9d2a6 scripts/OWNERS: Fix engeg email chromium -> google
ce620761 tests: Remove --allow-multiple-definition linker option
956c2efb futility: Skip picking apart an x86 kernel if has the EFI stub
9f2e9804 Avoid build failures on recent distros
62cc7885 subprocess: Log subprocess arguments when running
3bd35108 2api: Add a new entry point for only loading and verifying the kernel
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I9a16d6e02cee34140ec375ed6166f47560459140
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68540
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
a) Add LTR disqualification in D3 to ensure PMC ignores LTR
from UFS IP as it is infinite.
b) Remove LTR disqualification in _PS0 to ensure PMC stops
ignoring LTR from UFS IP during D3 exit.
c) Add Kconfig (SOC_INTEL_UFS_LTR_DISQUALIFY) check to apply
this LTR WA.
BUG=b:252975357
TEST=build and boot nirwen and see no issues in PLT runs
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: I88772b0b7dde1fca0130472a38628e72dfd6c26c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch introduces a config option for SoC code to choose
the applicable SoC workaround.
For now, we have introduced `SOC_INTEL_UFS_OCP_TIMER_DISABLE`
to apply UFS OCP timeout disable workaround.
At present ADL SoC only selects so, and in future MTL and others
should check with Intel prior selecting this kconfig.
It's the placeholder to add more workaround in required going forward.
BUG=none
TEST=Able to build and boot Google/Brya.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia2364d2de9725256dfa2269f2feb3d892c52086a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68309
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This ports the changes to the way the fch_pic_routing and
fch_apic_routing arrays get populated from Mandolin to Guybrush, Skyrim
and Zork. This is a preparation to move the init_tables implementation
to the common AMD SoC code in a later patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie550238dfa0d4c7cebe849966d40fa0b1984a0f6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This ports the changes to the way the fch_pic_routing and
fch_apic_routing arrays get populated from Mandolin to Bilby, Birman,
Chausie and Majolica. This is a preparation to move the init_tables
implementation to the common AMD SoC code in a later patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia957056b60dafbc52a9809a4563a348ad7443376
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce mb_get_fch_irq_mapping to access the FCH IRQ routing mapping
information and use it in init_tables to get the mapping instead of
directly accessing the array's contents. This is a preparation to move
the init_tables implementation to the common AMD SoC code in a later
patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9c39ea9de5ebbf70d2c5a87bfdfe270796548c5c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68847
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Enable GPP clk req disabling for disabled PCIe devices. If a clk req
line is enabled for a PCIe device that is not actually present and
enabled then the L1SS could get confused and cause issues with
suspending the SoC.
BUG=b:250009974
TEST=Ran on skyrim proto device, verified that clk reqs are set
appropriately
Change-Id: I6c840f2fa3f9358f58c0386134d23511ff880248
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68139
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently the GPP clk req configuration code assumes that the size of
the config array is `GPP_CLK_OUTPUT_COUNT`. This commit changes that
code to use the `ARRAY_SIZE` macro instead.
BRANCH=guybrush
BUG=b:250009974
TEST=Ran on nipperkin device, verified that clk req settings are
correct.
Change-Id: I3ff555843c6f5aa38acd8300e0dc2da4e33fb4b7
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Instead of using magic constants for the fch_pic_routing and
fch_apic_routing array sizes, define FCH_IRQ_ROUTING_ENTRIES in the
common code headers and use this definition. This also allows to drop
the static assert for the array sizes. In the Stoneyridge mainboard code
the equivalent arrays are named mainboard_picr_data and
mainboard_intr_data; also use FCH_IRQ_ROUTING_ENTRIES as fixed array
size there.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2d7ee46bd013ce413189398a144e46ceac0c2a10
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68818
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable RO verification by GSC and CBFS verification.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled using
x86 verstage and PSP verstage.
Change-Id: Idd22a521a913705af0d2aca17acd1aa069a77f29
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
CBFS verification on boards where VBOOT starts before bootblock eg. PSP
verstage has been accommodated by keeping metadata hash outside the
bootblock. Hence the dependency can be removed.
BUG=b:227809919
TEST=Build and boot to OS in skyrim with CBFS verification enabled using
both x86 verstage and PSP verstage.
Change-Id: I0a3254728a51a8ee7d7782afcea15ea06d93da7d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66947
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Crypto engine prefers the buffer from SRAM. CBFS verification may pass
the mapped address of a CBFS file from SPI flash. This causes PSP crypto
engine to return invalid address. Hence if the buffer is from SRAM, pass
it directly to crypto engine. Else copy into a temporary buffer before
passing it to crypto engine.
BUG=b🅱️227809919
TEST=Build and boot to OS in skyrim with CBFS verification enabled using
both x86 verstage and PSP verstage.
Change-Id: Ie9bc9e786f302e7938969c8093d5405b5a85b711
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add region/range of SPI ROM to be verified by Google Security Chip
(GSC).
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled.
Change-Id: If8a766d9a7ef26f94e3ab002a9384ba9d444dd1f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Do not compress PSP BIOS image when CBFS verification is enabled.
Otherwise when a file is added to CBFS, cbfstool is not able to find the
metadata hash anchor magic in the compressed PSP BIOS image.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled for
both x86 and PSP verstage.
Change-Id: Iaed888b81d14ede77132ff48abcfbeb138c01ce4
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68136
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
With CBFS verification enabled, CBFS file header + file name + metadata
consumes more than 64 bytes. Hence reserve additional space aligned to
the next 64 bytes.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled.
Change-Id: I2b7346e2150835443425179048415f3b27d89d89
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66944
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change ensures that amdfw.rom binary containing metadata hash
anchor is added before any file is added to CBFS. This will allow to
verify all the CBFS files that are not excluded from verification.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled using
x86 and PSP verstages.
Change-Id: Id4d1a2d8b145cbbbf2da27aa73b296c9c8a65209
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Metadata Hash is usually present inside the first segment of BIOS. On
board where vboot starts in bootblock, it is present in bootblock. On
boards where vboot starts before bootblock, it is present in file
containing verstage. Update cbfstool to check for metadata hash in file
containing verstage besides bootblock.
Add a new CBFS file type for the concerned file and exclude it from CBFS
verification.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled using
x86 and PSP verstages.
Change-Id: Ib4dfba6a9cdbda0ef367b812f671c90e5f90caf8
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66942
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To enable RO CBFS verification in AMD platforms with PSP verstage,
metadata hash for RO CBFS is kept as part of verstage. This means any
updates to RO CBFS, before WP is enabled, requires updating the
metadata hash in the verstage. Hence keep the metadata hash outside the
signed range of PSP verstage. This means the metadata hash gets loaded
as part of loading PSP verstage while still being excluded from the
verification of PSP verstage.
This change keeps the metadata hash outside the PSP footer data. This
will help to keep it outside the signed range of PSP verstage & aligned
to 64 bytes.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled with
both x86 and PSP verstage.
Change-Id: I308223be8fbca1c0bec8c2e1c86ed65d9f91b966
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68135
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On boards where vboot starts before bootblock, build metadata_hash in
verstage. This will allow to enable CBFS verification for such
platforms.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim with CBFS verification enabled using
x86 verstage and PSP verstage.
Change-Id: I4269069b66ed66c7b1a47fdef2fd0a8054b2e6a1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68134
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add build rules to build amdfwread tool. Also mark this as a dependency
either while building tools or amdfw.rom.
BUG=None
TEST=Build and boot to OS in Skyrim with CBFS verification enabled.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I3fee4e4c77f62bb2840270b3eaaa58b894780d75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66939
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Upcoming AMD SoCs use recovery A/B layout. Update amdfwread tool to
handle it.
Also add a generic read_header function to read different header types.
BUG=None
TEST=Run amdfwread tool against both Skyrim and Guybrush BIOS images to
dump the Softfuse entry.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I6576eaebc611ab338885aed2ee087bf85da3ca15
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66554
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Optional arguments that involve printing information from the firmware
image is mapped to bit fields with bit 31 set. But instead of just
setting bit 31, bits 27 - 31 are set. Fix AMDFW_OPT* bit mask.
BUG=None
TEST=Build and use amdfwread to read the Soft-fuse bits from Guybrush
BIOS image. Observed no changes before and after the changes.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I0d88669bace45f3332c5e56527516b2f38295a48
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66573
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* AMD_ADDR_PHYSICAL refers to physical address in the memory map
* AMD_ADDR_REL_BIOS is relative to the start of the BIOS image
* AMD_ADDR_REL_TAB is relative to the start of concerned PSP or BIOS
tables
Update the relative_offset implementation accordingly. Though
AMD_ADDR_REL_SLOT is defined it is not used. Removing that to simplify
the relative_offset implementation so that it can be used for both PSP
and BIOS firmware tables. Hence update the relative_offset function
signature as well.
BUG=None
TEST=Build and use amdfwread to read the Soft-fuse bits from Guybrush
BIOS image. Observed no changes before and after the changes.
Change-Id: I74603dd08eda87393c14b746c4435eaf2bb34126
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Select SOC_INTEL_RAPTORLAKE to force coreboot to use the RPL FSP headers
for FSP as kano is using a converged firmware image.
BUG=b:253337338
BRANCH=firmware-brya-14505.B
TEST=Cherry-pick Cq-Depends, then "FW_NAME=kano emerge-brya
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage",
disable hardware write protect and software write protect,
flash and boot kano in end-of-manufacturing mode to kernel.
Cq-Depend: chrome-internal:5046060, chromium:3967356
Change-Id: I75da3af530e0eafdc684f19ea0f6674f6dc10f01
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch moves DRIVERS_INTEL_USB4_RETIMER config from Meteor Lake
SoC to Rex mainboard to maintain the symmetry with previous
generation ChromeOS devices (Brya and Volteer).
BUG=none
TEST=Able to build and boot to Google/Rex with USB4 functionality
remaining intact.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I38360f6f1f2fcb4b0315de93c68f00d77e63003c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Move the Raydium touchscreen to the baseboard devicetree. Since only the
liara variant uses a level IRQ as I2C devices are supposed to, all other
board variants still override this to use an edge IRQ which were added
as a workaround to make the touchscreen work on the other devices. Right
now it's unclear to me if that edge IRQ workaround was only needed
temporarily and can now be removed, so I'll keep it as it was for now.
If this turns out to be no longer needed on the other variants, the
overrides can be dropped in the future.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic621c1a5856e9e280a25b0668010a1ee5bbb61e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68770
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
When CONFIG_DEBUG_SMI is enabled SMM handler performs console hardware
initialization that may interfere with OS. Here we store the state
before console initialization and restore state before SMM exit.
Tested=On not public yet system, after exiting smm, uart console can
still work well.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: Ifa5042c24f0e3217a75971d9e6067b1d1f56a484
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
After some measurements it turned out that Elkhart Lake uses a higher
CSR clock internally from which the MDIO clock is derived. In order to
stay compliant with the specification, the MDIO clock needs to be lower
than 2.5 MHz. Therefore, the divider needs to be 102 and not 62.
This patch changes the define to match the new divider value and uses
this new define at the appropriate place.
Test=Measure the MDIO clock rate on mc_ehl2 which results in 2 MHz.
Change-Id: Idf498c3547530dfa395f54488ef244e787062e34
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
The highly real time driven application executed on mc_ehl1 has shown
that the L1 prefetcher on Elkhart Lake is too aggressive which in the
end leads to an increased number of cache misses. Disabling the L1
prefetcher boosts up the performance (in some cases by more than 10 %)
in this specific use case.
Change-Id: Id09a7f8f812707cd05bd5e3b530e5c3ad8067b16
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68668
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Depending on the real workload that is executed on the system the L1
prefetcher might be too aggressive and will populate the L1 cache ahead
with data that is not really needed. In the end, this will result in a
higher cache miss rate thus slowing down the real application.
This patch provides a devicetree option to disable the L1 prefetcher if
needed. This can be requested on mainboard level if needed.
Change-Id: I3fc8fb79c42c298a20928ae4912ee23916463038
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68667
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- For display, only vdosys0_pwr_con and edp_tx_pwr_con settings are
required.
- For audio, it requires powering on adsp_ao_pwr_con,
adsp_infra_pwr_con and audio_pwr_con.
- Add new power domain data `ext_buck_iso_bits` for buck isolation
control.
BUG=b:244208960
TEST=access display registers successfully.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I7f00bda0cc5c7f8dea55a564a0ff10ae601115b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
MT8195 supports 2P mode and MT8188 supports 1P mode. A new struct
member `input_mode` is added to `struct mtk_dpintf` for
differentiation. We also move SoC-specific data `dpintf_data` to soc
folder.
BUG=b:244208960
TEST=emerge-cherry coreboot.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I6d138b0ff75e005518bc8fcce06df20924b2a6ba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Enable SSE2 (and SSE) when compiling for x86_64. Compilers often assume
SSE2 is present and enabled when targeting x86_64.
This fixes:
- lzma decompression code is compiled with the -Ofast flag
- 'everything' when compiling with clang.
This mostly affects qemu targets, which did not have this flag selected
yet.
TESTED on qemu.
Change-Id: I3cdc584c97016e15513df663a54a7bdb549a73e4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44869
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
For some nissa variants, there are build configurations that need to use
different blobs, but otherwise are identical. Currently, they use the
same choice of board config and configure blob paths appropriately. This
avoids duplication within the Kconfig file, but the resulting firmware
images can be difficult to distinguish, since they report the same
FRID.
Add a prompt string for MAINBOARD_PART_NUMBER so it can be overridden
and round-tripped through make oldconfig, allowing customisation of the
reported FRID and other MAINBOARD_PART_NUMBER-derived values with
minimal overhead.
BUG=b:253966060
BRANCH=None
TEST=CL:3960290 MAINBOARD_PART_NUMBER configs apply successfully
Signed-off-by: Sam McNally <sammc@chromium.org>
Change-Id: I3497d7fa1c04c8fa2592025c771d9dbc65632e6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
We've seen failures because the binaries were not being built into the
image. In particular, the APCB is modified by the coreboot build
process, so if the APCB isn't built correctly to support the correct
number of SPDs, the build can fail.
The mendocino FSP binaries are not yet pushed, so the build is currently
pointing at the cezanne binaries. The mendocino FSP will be pushed when
the mendocino chips are released for sale.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I31d11c5327416f4339930373c447531ae9f79d28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
For recent X86 CPUs, the 0x15 CPUID instruction will return Time Stamp
Counter Frequence. For CPUs that do not support this instruction, EDK2
must include a different library which is the reason why this must be
configured at build time.
If this is enabled, and the CPU doesn't support 0x15, it will fail to
boot. If is not enabled, and the CPU does support 0x15, it will still
boot but without support for the leaf. Consequently, disabled it by
default.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4f0f43ce50c4f6f7eb03063fff34d015468f6daa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Add a config for FIVR in devicetree for both, mc_ehl1 and mc_ehl2
variants in order to provide the real delay value for the VCC supply
rail. This delay is needed to enable proper switching between different
VCC levels based on current system state.
Change-Id: Ibccb8ea1b42ccd2ff0a37cbd9651528a2a55ebd6
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
the "x86 PIC code ebx" workaround done previously
by commit 689e31d18b ("Make cpuid functions usable
when compiled with PIC") does not work for x86_64
(the upper dword of rbx is set to 0)
the GCC bug that needed the workaround was fixed
in version 5 (see GCC bug 54232)
Change-Id: Iff1dd72c7423a3b385a000457bcd065cf7ed6b95
Signed-off-by: Matei Dibu <matdibu@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66345
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Apollo Lake seems to start with PCIe root ports unusable/uninitialized
before FspMemoryInit() is called and FSP-M properly initializes these
root ports.
However, we need the root ports accessible before FspMemoryInit() in
certain cases, such as emitting POST codes through a PCIe device.
For the initialization to happen properly, certain register writes
specified in Apollo Lake IAFW BIOS spec, vol. 2 (#559811), chapter
3.3.1 have to be done.
BUG=none
TEST=Boot on siemens/mc_apl2 with NC_FPGA_POST_CODE enabled and check
that the POST codes are emitted before FspMemoryInit().
Change-Id: If782bfdd5f499dd47c085a0a16b4b15832bc040e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68223
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On nissa, the pre-x86 time is not part of the 1s firmware boot time
target. Including the pre-x86 timestamps causes confusion since the boot
time appears to be greater than 1s, so disable the Kconfig on nissa.
We're not doing any analysis or optimisation of the pre-x86 time on
nissa anyway, this work will start from MTL onwards. Also, the Kconfig
is already disabled on the brya firmware branch, so this will result in
the same behaviour as brya.
Before:
Total Time: 1,205,840
After:
Total Time: 995,300
BUG=b:239769532
TEST=Boot nivviks, check "1st timestamp" is the first timestamp.
Change-Id: I885071c9e0ff9c8fac9444b382567d38a19c3c15
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68553
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Not all kahlee variants use the RT5682 audio codec, so split the
baseboard audio ACPI into two parts and only include the asl for
the codec(s) actually needed for a given variant.
TEST=build/boot aleena, liara variants and verify no ACPI present
for RT5682 codec (which is not present on the boards).
Change-Id: Icb7df4f8e51495ad3cb40113cd00810fd27dcd00
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Update generated FSP headers for Alder Lake N from v3301.00 to v3343.04.
Changes include:
- FspsUpd.h: 1. Add PchFivrVccstIccMaxControl UPD
BUG=b:254374913
BRANCH=None
TEST=Build using "emerge-nissa intel-adlnfsp" and boot Nissa.
Change-Id: I20b13d3dff2951e6ec3aa754c8954989a3b4e176
Signed-off-by: Shaik Shahina <shahina.shaik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68424
Reviewed-by: Reka Norman <rekanorman@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Built from a mixture of autoport output, other variants, schematics and
expert guesswork. I don't have this board, but the code has been tested
by someone else and boots successfully (first try) with TianoCore. It's
reasonable to assume most things work, as this board is very similar to
the already-supported variants.
Change-Id: I3d8df483e5573f77782b7d18b1410b391bfe387d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61541
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To allow testing of code that uses msr calls, separate the actual
calls into a separate header file, This allows the tests to emulate
the msr access without replacing the rest of the msr.h definitions.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I102709fec346f18040baf9f2ce6e6d7eb094682d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67917
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Create the gladios variant of the brask reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:239513596
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_gladios
Signed-off-by: Kevin Chiu <kevin.chiu.17802@gmail.com>
Change-Id: I3dc99d97d8e30d9641f56616222dd68e3a0d548d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change is to skip sending the MBP HOB since coreboot doesn't
use it and also helps to reduce the boot time by ~40 ms.
Boot time data
Before:
* 955:returning from FspSiliconInit 1,656,985 (274,416)
After:
* 955:returning from FspSiliconInit 1,593,036 (233,286)
BUG=b:252410202
TEST=Verified that boot time is reduced by ~40 msec.
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I0d4f66940529b8d38d9658c769feba8b5c9b715e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68418
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch adds the support to enable/disable skipping MBP HOB
from the devicetree based on mainboard requirement.
Porting the feature from commit 2bc54e7c00
("soc/intel/alderlake: Add support to skip the MBP HOB")
TEST=Build and boot to verify that the right value has been passed to
the FSP.
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I360d33617b9d2626fce5600e861214b0747f57b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Now that the SoC-specific UART controller data and the common code part
are cleanly separated, move the code to the common AMD UART support
block folder. The code is identical to the UART code in Cezanne,
Mendocino, Morgana and Picasso while Stoneyridge doesn't use the parts
related to the MMIO device driver.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id9429dac44bc02147a839db89d06e8eded7f1af2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce and use soc_get_uart_ctrlr_info to access the uart_info array
to further decouple uart_info from the code as preparation to factor out
most of the code to a common implementation. In order to slightly reduce
the number of function calls, pass the size of and pointer to uart_info
to get_uart_idx as a parameter instead of calling again
soc_get_uart_ctrlr_info in get_uart_idx despite all callers already
having the information form the soc_get_uart_ctrlr_info call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I80278f1a098b389d78f8e9a9fb875c4e466dc5db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce and use soc_get_uart_ctrlr_info to access the uart_info array
to further decouple uart_info from the code as preparation to factor out
most of the code to a common implementation. In order to slightly reduce
the number of function calls, pass the size of and pointer to uart_info
to get_uart_idx as a parameter instead of calling again
soc_get_uart_ctrlr_info in get_uart_idx despite all callers already
having the information form the soc_get_uart_ctrlr_info call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8cfea274f4c9e908c11429199479aec037a00097
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce and use soc_get_uart_ctrlr_info to access the uart_info array
to further decouple uart_info from the code as preparation to factor out
most of the code to a common implementation. In order to slightly reduce
the number of function calls, pass the size of and pointer to uart_info
to get_uart_idx as a parameter instead of calling again
soc_get_uart_ctrlr_info in get_uart_idx despite all callers already
having the information form the soc_get_uart_ctrlr_info call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iab1aec44c55570aa8085aeaf68ec69fe6de0f2ba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce and use soc_get_uart_ctrlr_info to access the uart_info array
to further decouple uart_info from the code as preparation to factor out
most of the code to a common implementation. In order to slightly reduce
the number of function calls, pass the size of and pointer to uart_info
to get_uart_idx as a parameter instead of calling again
soc_get_uart_ctrlr_info in get_uart_idx despite all callers already
having the information form the soc_get_uart_ctrlr_info call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I474e47059eaebcf0b9b77f66ee993f1963ebee77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Initialize the two GPIOs of the SoC UART if it's used for serial console
to be sure that the I/O mux is configured correctly without having to
rely on the bootblock_mainboard_early_init call to do this. This brings
Stoneyridge more in line with the other AMD SoCs. Since this code will
be factored out to the common AMD SoC code in a follow-up patch, the
function prototype is added to southbridge.h instead of creating a new
uart.h header file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id4aa6734e63dad204d22ce962b983cde6e3abd62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce and use an array of soc_uart_ctrlr_info to align Stoneyridge
with the other AMD SoCs in order to allow commonization of the AMD SoC
UART code. Since the current Stoneyridge code doesn't provide or use
UART MMIO device operations, only the base addresses of the UART
controllers from this array are used for now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie868cd3e2f77b0f7253c9f6d91dd3bbc3e4b6b0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
We are required to boot with eMMC enabled in the BIOS to store modem
calibration data. Thus, it doesn't make sense to enable NVMe at boot
time since we will never boot from NVMe w/o eMMC. We may as well take
the boot time reduction (~100ms) by eliminating NVMe initialization.
BUG=b:185426670, b:254281839
BRANCH=None
TEST=Boot after disabling NVMe and make sure that it still boots
Note that we are able to see a little over 100ms in boot time
savings with this change.
Before: 40:device configuration 824,021 (102,701)
After: 40:device configuration 717,402 (44)
Cq-Depend: chromium:3964185
Change-Id: I94f614ba0369c073617949285c0781aef5c6263f
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We need to boot eMMC for modem calibration, there is not need for BIOS
to initialize NVMe anymore as the kernel will do so. Removing the pci
device from the device tree as a first step.
BUG=b:185426670, b:254281839
BRANCH=None
TEST=Boot after removing from the herobrine device tree.
Change-Id: I802dd1361bc56a24ab3d65e6782bc611b7b75ee3
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add new memory parts in the mem_parts_used.txt and generate the
SPD ID for the parts. The memory parts being added are:
DRAM Part Name ID to assign
MT62F512M32D2DR-031 WT:B 0 (0000)
H9JCNNNBK3MLYR-N6E 0 (0000)
MT62F1G32D4DR-031 WT:B 1 (0001)
H9JCNNNCP3MLYR-N6E 1 (0001)
MT62F2G32D8DR-031 WT:B 2 (0010)
H9JCNNNFA5MLYR-N6E 3 (0011)
BUG=b:250470704, b:247683159
BRANCH=None
TEST=FW_NAME=frostflow emerge-skyrim coreboot
Signed-off-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Change-Id: I34584092c938539c91d65501ebe34b00212b34d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This reverts commit 672bd9bee5.
Reason for revert: Gmeet resolution dropped. When system starts
Gmeet video call, it uses the hardware accelerated encoder as per
the expectation. But, as soon as another system connects to the call,
the immediate fallback observed from hardware to software encoder.
Due to this, Gmeet resolution dropped from 720p to 180p.
Currently, this issue observed on AlderLake-N SoC based fanless
platforms. This issue is not seen on fan based systems.
BUG=b:246535768,b:235254828
BRANCH=None
TEST=Built and tested on Alderlake-N systems. With this revert
Gmeet resolution drop not observed.
Change-Id: Idaeaeaed47be44166a7cba9a0a1fac50d2688e50
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Baieswara Reddy Sagili <baieswara.reddy.sagili@intel.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
This README.md file specifies the expectations and agreements implied by
contributing code to the coreboot src/vendorcode directory.
Licenses, structure, formatting and the like are all the responsibility
of the contributors, however as the code is a part of the coreboot
codebase, members of the coreboot community are allowed to modify the
code to the extent deemed necessary.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib7e2aedce9383158d03be342cb10ae18d85146ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67485
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Librem Mini has a UART (accessible with soldering), which is very
useful for work on coreboot. It can be used for coreboot/SeaBIOS/Linux
boot logs, or as a general purpose UART.
Change-Id: I38ad5f19da6af5ed286ad3583f34b824a3660916
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68551
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure the Intel iGPU as primary video adapter if enabled according
to EEPROM settings. The default is to use the ASPEED BMC as primary
video adapter, which only has a VGA output and the remote KVM output.
For now, use the FSP GOP driver to light up the iGPU. There are several
issues with libgfxinit on the Hermes, probably due to the unusual setup
of the iGPU's display outputs. They are routed to a mezzanine connector
for a piggy-back sub-board, of which there are two models. The Poseidon
piggy-back has two DisplayPort outputs and an HDMI output coming from a
MegaChips LSPCON. The Avalanche piggy-back routes all three DisplayPort
outputs from the iGPU into a FPGA, which acts as a DisplayPort sink.
Note that the FSP GOP only initializes at most 2 iGPU display outputs.
However, all three outputs function properly once OS (Windows, Linux)
graphics drivers take over.
Additionally, update the config file that Prodrive uses to build
coreboot images so that the iGPU can be used as primary.
TEST=Verify that the iGPU's outputs work properly in pre-OS, Windows and
Linux, on both the Poseidon and Avalanche piggy-backs.
Change-Id: I24d9ebc2055dc246e7f257aa2f3853b22c8af370
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62649
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On the intel/glkrvp
compressed:
- romstage: 29659
- verstage: 31303
non compressed:
- romstage: 46244
- verstage: 47012
On qemu (with some additional patch to not run XIP)
compressed:
- romstage: 11203
non compressed:
- romstage: 13924
Even with a small romstage the size improvements are substantial,
which should result in a speedup when loading the stage. On the
up/squared loading romstage is sped up by 9ms.
TESTED: successfully boot the up/squared & google/vilboz.
Change-Id: I6906c8b6df45f2433d92d2ff1d1748cc4926c73a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Some platform run early stages like romstage and verstage from CAR
instead of XIP. This allows to link them like other arch inside the
_program region. This make in place LZ4 decompression possible as it
needs a bit of extra place to extract the code which is now provided by
the .bss.
Tested on up/squared (Intel APL).
Change-Id: I6cf51f943dde5f642d75ba4c5d3be520dc56370a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48156
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The ISH build target used for nissa is called adl_ish_lite: CL:3925007,
and by default the binary is installed as
/lib/firmware/intel/adl_ish_lite.bin
We could change the installed name, but it's nicer to keep it consistent
with the build target, so change the name in coreboot instead.
BUG=b:234776154
TEST=Build and boot nirwen, check firmware name is updated in SSDT
Change-Id: I983a38d08e758cf5a12a3f91a601c7e57d42c0cb
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Remove the ACPI ALS device from the EC configuration for newer devices,
because some do not have light sensors, and those who do have their ALS
presented through the new EC sensor interface already.
Inspired from commit ("f13e2501525f ("UPSTREAM: mainboard/google/eve: Remove ACPI ALS device")
BUG=b:253967865
BRANCH=none
TEST=Boot a device and ensure that 'acpi-als' device is not present
in /sys/bus/iio/devices.
Change-Id: Ibcfa9e8c5a4679d557150998fd255789d3f8a272
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68493
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SAR-related Kconfigs are only used by ChromeOS, and should be guarded
properly as such (as most other boards do).
TEST=build glados w/o CONFIG_CHROMEOS, verify SAR-related Kconfigs not
selected.
Change-Id: Id8abf68ed2e9720b5580f7965208dbe36460af07
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68458
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SAR-related Kconfigs are only used by ChromeOS, and should be guarded
properly as such (as most other boards do).
TEST=build reef w/o CONFIG_CHROMEOS, verify SAR-related Kconfigs not
selected.
Change-Id: I4fe3092e620bcbc33b0411ea69e55154fc118aa4
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68457
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the GSC is ready for the next transaction, it triggers a
GSC_AP_INT_ODL (active low) pulse with 100us duration to notify the AP.
Currently the TPM IRQ is configured as EDGE_RISING. Changing it to
EDGE_FALLING would speed up each register access by 100us. On Kingler,
this saves 20ms for the boot time (0.93s -> 0.91s).
BUG=b:235185547
TEST=emerge-corsola coreboot
TEST=Kingler booted without TPM errors
BRANCH=none
Change-Id: Id282e0f35694bd151781845cbd5aa4b389a30ddc
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
When "make symlink" is run, it looks for symlink.txt files recursively
under site-local directory, and make symbolic links accordingly.
"make clean-symlink" removes the symbolic links made.
One application is for development of support for new processors and/or
new mainboards, where new directories are added, along with some common
code changes.
Change-Id: I3fa119675ecca1626d70375a61e8a71abec6a53b
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Setting up HT resource seems to be copied from the old native family10
code. It is however not used as no device has a child device below 18.0
in any of the fam15tn board device trees.
Setting up HT resources is therefore done by AGESA and resource
allocation mostly happens to work.
Change-Id: I7edf19f71095fb38161f19d511997cdc2fe0d76c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Setting up HT resource seems to be copied from the old native family10
code. It is however not used as no device has a child device below 18.0
in any of the fam15tn board device trees.
Setting up HT resources is therefore done by AGESA and resource
allocation mostly happens to work.
Change-Id: Id95e2dec4a6f3e70234fff1df67ee61e08731400
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68411
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>
X9SAE has a PS/2 controller for keyboard and mouse but its definition
in ACPI used to be missing, and X9SAE used to use a generic SuperIO
support initially generated by autoport, so the full NCT6776 support
is added here like x9scl.
Test result:
Log lines like
i8042: PNP: No PS/2 controller found.
i8042: Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
become
i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at
0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
and more sub-devices within SuperIO is handled by the PNP driver.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: Ie5e73e8c3fc4e57c6683d7a7ca70e96c64dd9366
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68446
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Rename soc/amd/common/block/cpu/smm/smi_ampc_helper.c to smi_apmc.c and
add the fch_apmc_smi_handler function.
Remove the duplicated function from picasso, cezanne, mendocino, and
morgana SoC.
The stoneyridge soc does not implement the APM_CNT_SMMINFO handler, so
give the handler a unique name that does not conflict with the common
handler name.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I2e6fb59a1ee15b075ee3bbb5f95debe884b66789
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68441
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The 4.19 release is planned for January 2023. Please add any updates to
the coreboot code that are should go into the notes between now and
then. This helps in that you get to phrase the update the way you want,
and it lessens the load for the release managers.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Ib5a7ddfc6cb1a8e0a485c1e1810631c86f4083c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68459
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Configure FSP S UPDs to allow coreboot to handle the lockdown.
The main change here is setting `Write Protection Support` to 0,
as the default is Enabled, which shouldn't allow writes (even though
it seems to).
The UPDs are identical on APL and GLK, but all ones configured
in this patch have been there since their initial releases.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I1f6e5344cab2af7aa6001b9ec0f07b043a9caa8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Several EC host commands check for support of a given feature or msg
version, and a non-zero response does not necessarily indicate an actual
error. Since the caller is (should be) handling the non-zero response to
the host command, demote the EC printk from ERR to SPEW to clean up the
console log and prevent non-errors from causing false failures in
firmware tests.
BUG=b:238961053
Change-Id: Ib7afc0b7e5b571acb56252f7adb518a6b2716b62
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68259
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the "_DEPRECATED_" tag from ChromeOS diagnostics event and add a
subtype: "ELOG_CROS_DIAGNOSTICS_LOGS" under it.
The data of "ELOG_CROS_DIAGNOSTICS_LOGS" (0x02) contains:
* An uint8_t of subtype code
* Any number of "ChromeOS diagnostics logs" events
Each "ChromeOS diagnostics log" represents the result of one ChromeOS
diagnostics test run. It is stored within an uint8_t raw[3]:
* [23:19] = ELOG_CROS_DIAG_TYPE_*
* [18:16] = ELOG_CROS_DIAG_RESULT_*
* [15:0] = Running time in seconds
Also add support for parsing this event. The parser will first calculate
the number of runs it contains, and try to parse the result one by one.
BUG=b:226551117
TEST=Build and boot google/tomato to OS,
localhost ~ # elogtool list
0 | 2022-09-26 04:25:32 | Log area cleared | 186
1 | 2022-09-26 04:25:50 | System boot | 0
2 | 2022-09-26 04:25:50 | Firmware vboot info | boot_mode=Manual recovery
| recovery_reason=0x2/0 (Recovery button pressed)
| fw_tried=A | fw_try_count=0 | fw_prev_tried=A
| fw_prev_result=Unknown
3 | 2022-09-26 04:25:50 | EC Event | Keyboard Recovery
4 | 2022-09-26 04:26:01 | Memory Cache Update | Normal | Success
5 | 2022-09-26 04:26:06 | System boot | 0
6 | 2022-09-26 04:26:07 | Firmware vboot info | boot_mode=Diagnostic
| fw_tried=A | fw_try_count=0 | fw_prev_tried=A
| fw_prev_result=Unknown
7 | 2022-09-26 04:26:07 | Diagnostics Mode | Diagnostics Logs
| type=Memory check (quick), result=Aborted, time=0m0s
| type=Memory check (full), result=Aborted, time=0m0s
| type=Storage self-test (extended), result=Aborted, time=0m1s
Change-Id: I02428cd21be2ed797eb7aab45f1ef1d782a9c047
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add initial fw config as per config.star.
BUG=b:253199788, b:245158908, b:244113761, b:244012065
TEST=emerge-rex coreboot. Make sure that ACPI tables are equivalent
before and after this change with CBI.FW_CONFIG set to 0x1561.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I66f8b3e4ab414c03b8d63fdd31e0f3f424619340
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68220
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@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:251055188
TEST=On yaviks eMMC and UFS SKUs, boot to OS and
`suspend_stress_test -c 10`
Change-Id: I6b3a20f3c14d5e9aa8d71f6ca436b5a682310797
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68365
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id 7805999e6:
2022-09-05 16:42:34 +0200 - (Merge changes from topic "st-nand-updates" into integration)
to commit id c45d2febb:
2022-10-12 15:56:24 +0200 - (Merge "fix(ufs): retry commands on unit attention" into integration)
This brings in 288 new commits.
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Change-Id: I4137cab0a1a352e94e21f105717ae0b6c515b75b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68386
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The PCIe port descriptor list seems to be specific to Merlin Falcon and
Prairie Falcon has a different PCIe root port configuration. Since I
neither have the board nor the different APUs, I just add a comment
about this instead of trying to come up with a PCIe port descriptor list
that may or may not work properly on Prairie Falcon APUs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8e1eb67a8f684297bbefc6e2593250d7bd45593f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68407
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Stoneyridge is a SoC so it makes sense to statically use ops instead of
matching them to PCI DID/VID at runtime. In contrast to the other AMD
SoCs in the coreboot tree the PC driver used the PCI ID of the first HT
PCI device function, so add the ops to the device 0x18 function 0
devicetree entry in this patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I500521701479aa271ebd61e22a1494c8bfaf87fb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68408
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Disable the unused PCIe root ports that are disabled in the PCIe port
corresponding descriptor list passed to AGESA/binaryPI. This descriptor
list is in src/mainboard/google/kahlee/variants/baseboard/OemCustomize.c
and it only has B0D2F2 (gpp_bridge_1) and B0D2F4 (gpp_bridge_3) enabled.
Since the PCIe engines marked as unused in the port descriptor list
won't show up as PCI devices, don't enable those PCI devices in the
devicetree so that coreboot won't complain about static PCI devices not
being found on the PCI bus.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If8378e343a2eb13de66171cf4f38d77ae3401016
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68382
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add chipset devicetrees for Stoneyridge and Carrizo, which is also
supported by the Stoneyridge code, but has more external PCIe ports and
devices. The mainboard's devicetrees will be changed to use the aliases
defined in the chipset devicetree in follow-up patches. This is a
preparation to statically assign the ops for the internal devices
statically in the SoC devicetree instead of dynamically adding them in
ramstage.
BKDG #55072 Rev 3.04 was used to check the PCI devices and functions and
the MMIO addresses.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia45260b1168ed1d99993adfb98475da5b5c90d11
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68316
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When using a Merlin Falcon APU, explicitly enable the PCIe root port at
B0D3F1. B0D3F0 is only a dummy PCI device function, but needs to also be
enabled in order for the actually used function to be usable. Prairie
Falcon doesn't have and PCI device 3 on bus 0, so remove D3F0 from the
common mainboard devicetree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I01f9b9ac2a9ebd5899a093d97eb5b2d76d309f66
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68315
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PCI devices that aren't present in the devicetree will be treated as
enabled. Since the chipset devicetree that will be added in a follow-up
patch disables this device by default, explicitly enable the IOMMU
device on the Stoneyridge mainboards that don't disable it to keep the
same behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4a2cdd00abe8309244829dc633dd8a9ca0038dfa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68313
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the devicetree files are passed to util/sconfig without being
processed by the C preprocessor, using #if in the devicetree won't give
the behavior that might be expected. Instead sconfig treats the #if as a
comment, but still processes all other lines. To get the intended
behavior, replace the C preprocessor usage in the devicetree by moving
the APU-specific parts to override devicetrees that get selected
according to the selected APU type.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iddd317b27a838849fa40c0fb77d942609104cf04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68312
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Switch from gpio_configure_pads() to gpio_configure_pads_with_override()
so variants can override romstage GPIO defaults. Rename baseboard
function and add an weak empty override function to be used by variants.
Will be used for touchscreen power sequencing in a follow-on commit.
Change-Id: I45586237919cd07a171beac57f3510e26338f67f
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Create the zombie variant of the herobrine reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:249180463
BRANCH=None
TEST=util/abuild/abuild -p none -t google/herobrine -x -a
make sure the build includes GOOGLE_ZOMBIE
Signed-off-by: Maulik Vaghela <maulikvaghela@google.com>
Change-Id: Ifecf0a6323b20012defbf14bd16ce2f1f41f4714
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bob Moragues <moragues@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
HP Z220 series has PCI slot(s) but Interrupt Routing Table in ACPI
used to be missing, so one is added.
Note that the values within the added one are obtained from my own SFF
variant. If other variants have different values, please add them in a
manner similar to mb/gigabyte/ga-b75m-d3h/acpi/pci.asl.
Test result:
Log lines like
pci 0000:00:1e.0: can't derive routing for PCI INT A
ath9k 0000:04:00.0: PCI INT A: no GSI
disappeared from dmesg.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I8522b25ac46db2054302c8f2418927c722b157e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68334
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a missing period, use "SoC" with lowercase 'o' to refer to a "System
on a Chip", fix up the redundant "CRB board" expression (that stands for
"Customer Reference Board board"), switch the position of a verb and its
adverb ("never was" ---> "was never") to sound more natural, and replace
"depreciate" with "deprecate" for semantic correctness.
Change-Id: Ic821a9030d4ff32c76765f51f1feb0f5503d4cc0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68330
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `eeprom_read_serial()` function could return a non-NULL terminated
string if the serial in EEPROM has `HERMES_SN_PN_LENGTH` (32) non-NULL
characters. Make this impossible by adding an additional character for
a NULL byte in the static buffer, which always gets set to 0 (NULL).
Change-Id: I306fe1b6dd3836156afca786e352d2a7dca0d77c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68322
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This reverts commit 4b5ba94363.
Reason for revert: This optimization is causing the non-serial enabled
tot BIOS to not boot. To get tot back into good shape, will revert
for now and reevalute this fix and resubmit at a later time.
BUG=b:218406702
BRANCH=None
TEST=reboot from AP console (on herobrine) after flashing
image-herobrine.bin.
prior to fix the device would never boot to login prompt.
after rever the device would boot to login prompt again.
Change-Id: Iaac5f2fb2120f6aa41a0ce9a763d50fd7b9a3ec7
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
The decompression is critical for speed of boot. So we sacrifice some
generated code size to optimize for speed.
This change speeds up the LZMA decompression between 3% and 6% at a
cost of just over 2k of additional code space.
BUG=b:223985641
TEST=Majolica
The test is done on Majolica and the result is listed below.
Time saved:
We tested the boot time with each flag for 10 times. The duration of
each decompression process is listed as below.
Load FSP-M Load ramstage Load payload
Ofast Os Ofast Os Ofast Os
------------------------------------------
62543 62959 20585 22458 9945 10626
62548 62967 20587 22461 9951 10637
62560 62980 20588 22478 9951 10641
62561 62988 20596 22478 9954 10643
62569 62993 20596 22479 9954 10643
62574 63000 20605 22492 9958 10647
62575 63026 20615 22495 9959 10647
62576 63038 20743 22614 9960 10647
62587 63044 20758 22625 9961 10647
62592 63045 20769 22637 9961 10647
-----------------------------------------
average 62568 63004 20644 22521 9955 10642
(unit: microseconds)
Size sacrificed:
The size of object file with -Os:
./build/ramstage/lib/lzmadecode.o: file format elf32-i386
4 .text.LzmaDecode 00000d84 00000000 00000000 00000076 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
The size of object file with -Ofast:
./build/ramstage/lib/lzmadecode.o: file format elf32-i386
4 .text.LzmaDecode 00001719 00000000 00000000 00000080 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
(Output by running "objdump -h ./build/ramstage/lib/lzmadecode.o")
We can see that size is increased from 3460 bytes to 5913 bytes, a
change of 2453 bytes or 171%.
Change-Id: Ie003164e2e93ba8ed3ccd207f3af31c6acf1c5e2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Makes it possible to configure the maximum allowed/supported DDR memory
frequency on a per mainboard basis.
Test
- Define maximum memory frequency in mainboard devicetree.cb
- Boot into Linux and run 'sudo dmidecode --type 17' to check memory
speed
- Boot into Linux and run 'phoronix-test-suite benchmark ramspeed'
Change-Id: I9e0c7225e2141e675a20b8e3f0dbe8c0b3a29b28
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68097
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The SoC Intel Quark is unmaintained and various efforts to revive it
failed. Thus, deprecate the following components with the 4.18 release.
* Intel Quark SoC
* Intel Galileo mainboard
The support for these components will be dropped with the release 4.20.
Change-Id: I738ad74da043649107473dc0c2e6adf343e4cd35
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68260
Reviewed-by: ron minnich <rminnich@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Windows hardware tests require this field not be "Reserved".
The System76 EC firmware does not report the wake type, so it is not
possible to know if the system was powered on from the power switch or
Wake-on-LAN. In the case WoL is used, this will report the wrong value.
Change-Id: I4653c6bce2a5f0a88281fc810df5646e44f90674
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66837
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
BRANCH=none
BUG=b:234776154
TEST=build and boot Nirwen UFS, copy ISH firmware to host
file system /lib/firmware/intel/adln_ish.bin
check "dmesg |grep ish", it should show:
ish-loader: ISH firmware intel/adlnrvp_ish.bin loaded
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: I89782b0b7dde1fca0130472a38628e72dfd5c26c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
First of all, make sure that `get_board_settings()` never returns NULL.
If there's a problem, return predefined values for board settings.
If the board settings definition differs between coreboot and the BMC,
the CRC will not match. Allow coreboot to use the BMC settings provided
by older BMC firmware revisions which have less settings, if the CRC of
the first N bytes matches the expected CRC.
TEST=Boot coreboot master with BMC FW R04.05, observe board settings
being honored even though coreboot's definition has an extra option.
Change-Id: I0f009b21ef0850a2af6edef1818c770171358314
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67381
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The tool "include-what-you-use" analyzes each file's headers and makes
recommendations for header files to add and remove. There are
additional scripts as part of the package that will make these changes
directly based on the recommendations, but due to the way coreboot
compiles code in/out base on Kconfig options, this isn't really safe for
the project to use.
It is a good starting point though.
To use, set the IWYU kconfig option, then build with the command:
make -k
Because this doesn't actually build any files, the -k option is needed
or make will stop after looking at the first file.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I084813f21a3c26cac1e4e134bf8a83eb8637ff63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Julius Werner <jwerner@chromium.org>
There is no option to calculate or generate the serial number and UUID
on this platform. Enable CBFS UUID and serial by default so anybody
can easily populate the missing fields.
TEST=Add UUID and serial CBFS files, boot the platform and see both
UUID and serial number are populated correctly.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ic8af889f12617d4ab6a27c6f336276c04f26244c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64640
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When system_uuid CBFS file is present and contains the UUID
in a string format, the driver will parse it and convert to binary
format to populate the SMBIOS type 1 UUID field.
TEST=Add UUID file and boot MSI PRO Z690-A DDR4 WIFI and check with
dmidecode if the UUID is populated correctly.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I22f22f4e8742716283d2fcaba4894c06cef3a4bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64639
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some mainboards have a header connected to the SPI bus, which can be
used to connect a second flash chip and override the onboard flash. This
allows one to boot coreboot on the system without ever having to flash
the onboard flash. HP boards with this header all seem to use the same
2x8 or 2x10 header layout, so document the pinout.
Change-Id: Ic2bf1244adfb78872340f212519c6ab33e26646a
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67818
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is not critical functionality and doesn't need a build-time error.
Having it as a build time error causes a chicken & egg issue where
the chipset needs to be added before it can be added to this file, but
the header file fails the build because the chipset is unknown.
It's not practical to exclude these files from the new platform builds
because the PSP functionality is thoroughly embedded into the coreboot
structure.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Ib02bbe1f9ffb343e1ff7c2bfdc45e7edffe7aaed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Fix shell variable "LINTDIR" so that helper_functions.sh can be found.
TEST=`./util/lint/lint lint-stable --junit` no longer prints "cannot
open /helper_functions.sh: No such file"
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I68f2e65fa1c9297ad6b58b77576deaeef8bd76e3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
A spelling mistake in the markdown reference to the coreboot vs EDK II
bootflow diagram was previously fixed, but the actual filename was not
changed resulting in a broken reference.
Change-Id: I512646e9af312ba2e1db8f597f6fffa8d54a3515
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67782
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Create the frostflow variant of the skyrim reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:240970782
BRANCH=None
TEST=util/abuild/abuild -p none -t google/skyrim -x -a
make sure the build includes GOOGLE_FROSTFLOW
Signed-off-by: Chao Gui <chaogui@google.com>
Change-Id: I937e6562094968824e73bfa20390b3ec8b24dfa0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Adjust the EEPROM layout to account for two new fields: board part
number and product part number. In addition, put them in a Type 11
SMBIOS table (OEM Strings). Also, rename a macro to better reflect
its purpose.
Change-Id: I26c17ab37859c3306fe72c3f0cdc1d3787b48157
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67759
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Until recently, there were two options to build edk2, UefiPayloadPkg and
CorebootPayloadPkg. Now, there is only one, UefiPayloadPkg but soon,
there will be Universal Payload.
It makes more sense, as the official edk2 repository doesn't work with
coreboot, to have the build target and repository separate. That will
allow for building either UefiPayloadPkg or Universal Payload from the
official repository, MrChromebox' fork or a custom repository.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: If7f12423058ef69838741f384495ca766ccea083
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66080
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Add the `eeprom_read_serial()` function to read serials from the EEPROM.
Note that there's only one buffer now: this means only one serial can be
accessed at the same time, and the buffer needs to be cleared so that it
does not contain old data from other serials. Given that the serials are
copied one at a time into SMBIOS tables, having one shared buffer is not
a problem.
Change-Id: I5c9781e4e599043be756514cfd6dd86dedcf580c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67275
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCH's SGPIO pads are connected to a buffer chip that is powered from
the always-on +3V3_AUX rail. For some cursed reason, when the SGPIO pads
stay configured as SGPIO when a Poseidon system shuts down, voltage from
the +3V3_AUX-powered buffer chip will leak into the +5V rail through the
SATA backplane. Just pulling the SGPIO pads low before the system powers
off stops the +5V rail from being cross-powered.
This issue has only been observed in S5, but it's very likely other
sleep states are affected as well. Thus, always pull the SGPIO pins
low before entering ACPI S3 or deeper because the power supply will
turn off in these states as well.
TEST=Obtain a Poseidon system, verify that the +5V rail is cross-powered
after going to S5. We measured 0.17V on our system, but voltages as
high as 0.6V were measured on other systems. Verify that unplugging
the SGPIO cable going to the SATA backplane results in the +5V rail
voltage dropping to 0V, which indicates that the voltage leakage is
exclusively coming from the SGPIO and SATA backplane. Finally, make
sure that the +5V rail voltage drops to 0V after going into ACPI S5
with this patch applied and the SGPIO cable connected.
Change-Id: Ic872903d5fcdd1c17e02b4c06d5ba29889fbc27d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
To be able to change the MAC addresses, it is necessary that the
controllers are in D0 power state. As of FSP MR3, Intel has set the
controllers to D3 power state at the end of FSP-S TSN GbE
initialization. This patch sets the state back to D0 before the
programming of the MAC addresses.
Test:
- Build coreboot with FSP MR4 for mc_ehl2 mainboard
- Boot into Linux and check MAC addr via 'ip a'
Change-Id: I4002d58eb4332ba45c35d07820900dfd2c637f21
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67976
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
apu/amdfw_a was only getting added to CBFS when VBOOT_SLOTS_RW_AB was
selected, but needs to be added in the RW_A only case as well
(VBOOT_SLOTS_RW_A). Since VBOOT_SLOTS_RW_AB selects VBOOT_SLOTS_RW_A,
we can guard amdfw_a and _b separately and both will be added in the
RW_AB case.
TEST=build google/zork with VBOOT_SLOTS_RW_A or VBOOT_SLOTS_RW_AB
selected, ensure amdfw_a and amdfw_b are added to correct CBFS regions
as appropriate.
Change-Id: Ic8048e869d7449eeb1ac10bfec4a5646b848d6a8
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68126
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
apu/amdfw should be restricted to the RO region only when building with
VBOOT + any RW region (RW_A or RW_A + RW_B); it is not tied to ChromeOS
in any way. Fix guarding to match newer AMD platforms (eg, CZN/MDN).
TEST=build google/zork without CHROMEOS, with VBOOT_SLOTS_RW_A
Change-Id: I32d7fa7a4b3d41107cfdba96128a4a75f7066c6f
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68125
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
RaptorLake introduces the support of the Voltage Regulator Fast Vmode
feature. When enabled, it makes the SoC throttle when the current
exceeds the I_TRIP threshold. This threshold should be between
Iccmax.app and Iccmax and take into account the specification of the
Voltage Regulator of the system.
This change provides a mean to:
1. Enable the feature via the `vr_config->enable_fast_vmode'. If no
I_TRIP value is supplied FSPs picks an adapted I_TRIP value for
the current SoC assuming a Voltage Regulator error accuracy of
6.5%.
2. Set the I_TRIP threshold via the `vr_config->fast_vmode_i_trip'
field.
These new fields are considered independent from the other `vr_config'
fields so that the board configuration does not have to unnecessarily
supply other VR settings to enable Fast VMode.
Information about the Fast VMode Feature can be found in the following
Intel documents:
- 627270 ADL and RPL Processor Family Core and Uncore BIOS
Specification
- 724220 RaptorLake Platform Fast V-Mode
- 686872 RaptorLake Lake U P H Platform
BUG=b:243120082
BRANCH=firmware-brya-14505.B
TEST=Read I_TRIP from the Pcode and verify consistency with
a few `enable_fast_vmode' and `fast_vmode_i_trip' settings.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I313acf01c534d0d32620a9dedba7cf3b304ed2ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66917
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
An optional dGPU can be connected to the second PEG bridge:
-[0000:00]-+-00.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller
+-01.0-[01]--
+-01.1-[02]----00.0 NVIDIA Corporation GK208M [GeForce GT 730M]
It's possible that the 01.0 bridge is never populated, but we have to
leave it on anyway so 01.1 can be enumerated.
Change-Id: Ieab7a7bf3b31b4ee9d9f12b5d827d866c87356e1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Lite Mk IV's can enable fast charging, with support up to 100W
via USB-C PD 3.0.
The default for this is disabled, as it can reduce battery life
span. This patch adds the option to enable fast charging, by
writing 0x01 to 0x18 in the EC space.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ie01eb59d3f41b242190973fd9c58b1494320c12a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add variant specific cmos files, which avoid options like "Thunderbolt"
existing in platforms that don't support such options.
This change also removes entries that were never used, including:
* smi_handler
* usb_always_on
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I359e5c5bbf29eb474f2d3bc42a8e80afc0a5d38a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66296
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently, after the PCIe link is initialized, we wait 100ms every
time the link is not up anymore. However, this causes significant
delay. Assuming the first check is false, we'd like to increase the
frequency of checks for the link to be up. Changing to check every
10ms instead. This seems to save about 90ms in the device
configuration stage of bootup on herobrine.
BUG=b:218406702
BRANCH=None
TEST=reboot from AP console (on herobrine)
prior to fix (from cbmem dump):
40:device configuration 919,391 (202,861)
after fix (from cbmem dump):
40:device configuration 826,294 (112,729)
Change-Id: Ic67e7207c1e9f589b34705dc24f5d1ea423e2d56
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: mturney mturney <quic_mturney@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Intel Core i5-10210U can have the following IGD Device IDs
0x9B21/0x9B41/0x9BAC/0x9BCA/0x9BCC according to Intel ARK. Some of
these IDs were not present in coreboot source nor hooked to the
common graphics driver. Add the missing IDs so that the graphics
driver will probe on the mentioned processor and detect the
framebuffer.
TEST=Boot Protectli VP4650 with i5-10210U and see framebuffer is
detected when using FSP GOP and libgfxinit.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Iee720a272367aead31c8c8fa712bade1b6e53948
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67975
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 37a89d519d ("ec/lenovo/h8/acpi: Replace Not() with ASL 2.0
syntax") mixed up boolean and bit-wise operators while replacing Not()
with ASL 2.0 syntax. Thus, fix that.
Built dsdt.aml of lenovo/x230 and differs, but it remains the same when
this commit is applied after commit 37a89d519d.
Change-Id: Ifa848aafb5480acaac4fabffcf90a3dbf5248e43
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66380
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To support an RPL SKU on brya0, brya0 must use the FSP for RPL.
Select SOC_INTEL_RAPTORLAKE for brya0 so that it will use the RPL
FSP headers for brya0.
BUG=b:248126749
BRANCH=firmware-brya-14505.B
TEST=cherry-pick Cq-Depends, then "emerge-brya intel-rplfsp
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage",
flash and boot brya0 to kernel.
Cq-Depend: chromium:3893035, chrome-internal:4983198
Change-Id: I2dd84757532d734ad97b74ba960537d937fb313e
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
1) Make the skolas FW_CONFIG field defintions compatible with the
brya0 FW_CONFIG field definitions to support skolas being a SKU of
brya0, and in sync with the config.star definitions for the FW_CONFIG
field for brya0 and skolas.
- brya0 specific changes:
1) remove WFC_MIPI_OVTI5675 definition (was 1)
2) redefine WFC_MIPI_OVTI8856 from 2 to 1
3) define new WFC_MIPI_KBAE350 camera type as 2
- skolas specific changes:
1) remove WFC_MIPI_OVTI5675 definition (was 1)
2) redefine WFC_MIPI_OVTI8856 from 2 to 1
3) define new WFC_MIPI_KBAE350 camera type as 2
2) Add support back in for UFC_MIPI_OVTI5675 in brya0 now that FW_CONFIG
defines are fixed.
BUG=b:248126749
TEST="emerge-brya coreboot chromeos-bootimage", flash brya0 and
verify it boots successfully to kernel and that WFC, UFC, and audio
works on skolas and brya0.
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Change-Id: I3be26e0a05f4dc08e5dc3f6ef7b71bdd8fd4f859
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67929
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
On newer systems such as Alder Lake it has been noticed that Intel PTT
control area is not writable until PTT is switched to ready state. The
EDK2 CRB drivers always initialize the command/response buffer address
and size registers before invoking the TPM command. See STEP 2 in
PtpCrbTpmCommand function in
tianocore/edk2/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c
Doing the same in coreboot allowed to perform PTT TPM startup
successfully and measure the components to PCRs in ramstage on an
Alder Lake S platform.
TEST=Enable measured boot and see Intel PTT is started successfully
and no errors occur during PCR extends on MSI PRO Z690-A DDR4 WIFI.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ia8e473ecc1a520851d6d48ccad9da35c6f91005d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63957
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
The delayed return of certain fetch instruction from memory to
the UFS causes the OCP fabric to timeout on the transaction
and become non-responsive.
As recommended by the SoC and IP teams,program the
OCP fabric register to avoid the timeout in the OCP fabric.
This patch adds the following changes
1. Program the OCP fabric registers in the PS0 routine.
2. Move the ssdt contents of UFS to dsdt asl code to avoid
duplication of UFS device creation
BUG=b:240222922
TEST=Build and boot Nirwen UFS board, observe no system hang
during Chrome PLT test.
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: I949a4538ea5c5c378a4e8ff7bb88546db1412df2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Select the config to separate the AMDFW binary from the verified boot
section.
BUG=b:203597980
TEST=Build Skyrim BIOS image and boot to OS with PSP verstage passing
the hash table and PSP verifying the binaries against the hash table.
Observe boot time improvement of ~120 ms while operating SPI bus at 66
MHz with PSP verstage enabled.
Before this patch series:
508:finished loading body 1,978,053,432 (201,518)
After this patch series:
508:finished loading body 7,948,797,849 (83,460)
Change-Id: I78ec6d28b4c5fc40bdade47489d58180a54dee4d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
MSI PRO Z690-A WIFI DDR4 and MSI PRO Z690-A DDR4 are basically the
same boards, except the latter has no WiFi populated. Check the CNVi
WiFi presence and return correct SMBIOS product name string.
TEST=Check SMBIOS product name on both WiFi and non-WiFi variants in
Linux.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5fedbce413dfb6a589a406d1e34e3e114ca6a40f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68078
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adjust the Makefile to look for SPD source Makefile. The current
SPD guard isn't set up correctly and is attempting to build the
APCB with SPD when SPD isn't present.
BUG=b:249988439
TEST=util/abuild/abuild -x -t GOOGLE_MORTHAL --verbose
util/abuild/abuild -x -t GOOGLE_SKYRIM --verbose
util/abuild/abuild -x -t GOOGLE_WINTERHOLD --verbose
Change-Id: I9cf13acb1188309ea6a1e6bdacc37d80b01f70a8
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68018
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Copy AMD PSP fw hash table into memory, then pass it to the PSP.
The PSP will use this hash to verify it's the correct firmware bundled
with coreboot build and not replaced.
BUG=b:203597980
TEST=Build Skyrim BIOS image with the hash table and boot to OS after
PSP verified the binaries against the hash table.
Change-Id: I84bea97c89620d0388b27891a898ffde77052239
Signed-off-by: Kangheui Won <khwon@chromium.org>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60291
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add build rules to separate signed PSP/AMDFW. Also add build rules to
add the generated hash table containing SHA digest of individual PSP FW
components into CBFS. This will allow verified boot to load and verify
less components from SPI rom which means faster boot time.
BUG=b:206909680
TEST=Build Skyrim with modified fmap and Kconfig
Change-Id: If54504add72b30805b6874bee562e0b9482782b9
Signed-off-by: Kangheui Won <khwon@chromium.org>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67260
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generate SHA256/SHA384 hash of the signed firmware so that PSP verstage
can pass it to PSP. The PSP will use these hashes to verify the
integrity of those signed firmwares.
BUG=b:203597980
TEST=Build Skyrim BIOS image.
Change-Id: I50d278536ba1eac754eb8a39c4c2e428a2371c44
Signed-off-by: Kangheui Won <khwon@chromium.org>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60290
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enabling this config will put signed amd firmwares into
SIGNED_AMDFW_[AB] region which is outside FW_MAIN_[AB]. Vboot only
verifies FW_MAIN_[AB] so these regions will not be verified by vboot,
instead the PSP will verify them.
As a result we have less to load and verify from SPI rom which means
faster boot time.
BUG=b:206909680
TEST=Build Skyrim with modified fmap and Kconfig.
Change-Id: If4fd3cff11a38d82afb8c5ce379f1d1b5b9adfbf
Signed-off-by: Kangheui Won <khwon@chromium.org>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59867
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for separating signed firmwares into another CBFS. If
sig_opt flag in AMD/PSPFW file header is 1, it means that the firmware
is signed against AMD chain of trust and will be verified by PSP. If
those firmware binaries are put outside FW_MAIN_[AB], vboot can skip
redundant verification, improving overall verification time.
BUG=b:206909680
TEST=Build amdfwtool. Build Skyrim BIOS image and boot to OS.
Change-Id: I9f3610a7002b2a9c70946b083b0b3be6934200b0
Signed-off-by: Kangheui Won <khwon@chromium.org>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59866
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Checkpatch script recommends to use __packed instead of
__attribute__((packed)). Currently the build rule for amdfwtool does not
include the required header file with __packed definition. Update the
compiler flag to include the required header file.
BUG=None
TEST=Build amdfwtool.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I448cbad533608dd5c2bd4f2d827fcc5db5dee5cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67384
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the lisbon variant of the brask reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:246657849
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_LISBON
Signed-off-by: Kevin Chiu <kevin.chiu.17802@gmail.com>
Change-Id: Ia31752765657054b28ea16b046b63c38a72f95bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
CB:67670 recently changed the format of the MRC metadata header, but
left the signature the same. That kinda defeats the purpose of having a
signature which is to make a data structure recognizable (because now
the same signature can refer to two different structures that cannot be
otherwise distinguished). While we don't know of any use case where
anything other than coreboot currently parses this data structure (other
than a ChromeOS-internal utility that's about to be removed), it's
probably better to still switch to a different signature for the new
header format just to stay on the safe side (e.g. if we ever need to
start parsing this somewhere else in the future).
CB:67670 only landed a week ago so hopefully the old signature + new
format variant hasn't had much time to escape into the wild yet.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic08b23862720db832a08dc4c6818894492f43cc3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68012
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Each of the tools that used git had similar functionality. This combines
all of that into a single script that gets sourced by each. This makes
maintenance much easier.
By doing this and updating each of the scripts to do the correct thing
if the script isn't being run in a git repository, it makes them work
much better for the releases, which are just released as a tarball,
without any attached git repository.
Change-Id: I61ba1cc4f7205e0d4baf993588bbc774120405cb
Signed-off-by: Martin Roth <martin@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
- Update spelling.txt with Lintian changes
- Remove words that are going to mess up code
- Add comments to the header about what words should be removed, along
with where the files
- Add Makefile to sort the list
Note that this undoes some of the sorting that Patrick introduced in
commit CB:38632 - ID: 805b291830
I just cannot reproduce his sort order, even using the script he put
into the commit message.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic131d5b08409f43eb700dcc8f125af00cff53d71
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64893
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The parsing of the PMU binary subprogram and instance numbers only
worked correctly for the cases where the ID in the name in the fw.cfg
file was between 0 and 9, but returned wrong results if it was between a
and f. Switch to using strtol with a base of 16 instead of subtracting
the char '0' from the char in the filename in
find_register_fw_filename_bios_dir to fix this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic5fd41daf9f26d11c1f86375387c1d7beac04124
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This area relates to storing of AP RO verification information.
CONFIG_VBOOT_GSCVD is enabled by default for TPM_GOOGLE_TI50 and
guybrush is using TPM_GOOGLE_CR50.
Signed PSP verstage has the FMAP embedded. Since CB:67376 shifted the
RO section up by 8K, they were misaligned. Hence marking this area as
unused instead of removing the same to work around ChromeOS
infrastructure shortcoming.
Signed-off-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Change-Id: Id852e5b5c1f777992a96a75143757f4df8d975b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67901
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It turns out that one can use Kconfig options to specify values for
devicetree options, as long as the resulting expression is a compile
time constant. Use this to configure SaGv for Atlas: enable it by
default, but allow SaGv to be disabled manually for convenience when
testing. Enabling SaGv makes MRC train the RAM multiple times, which
takes a significant amount of time.
For further info on SAGV on ADL, please refer to Intel Doc 655258
(Alder Lake Datasheet) section 5.1.3.2.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I3c6ac25d414122c408f2348d12dba8dce909e567
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable DPTC and No Battery Mode for Skyrim. This allows Skyrim to boot
without a battery or with a critically low battery.
DPTC remains disabled for the Winterhold and Morthal variants until it
can be tested on those boards.
BRANCH=none
BUG=b:217911928
TEST=Boot skyrim with low & no battery
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Icc4084476916cc8e142908d8e58baf7124568b8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67211
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change the TPM I2C freqeuncy to 1 MHz for nivviks and nereid, and in
the baseboard. Other nissa devices will be changed after verification.
This saves 11 ms of boot time on nivviks and nereid.
400 kHz:
504:finished TPM initialization 272,304 (35,730)
...
512:finished TPM PCR extend 526,250 (23,729)
513:starting locking TPM 526,250 (0)
514:finished locking TPM 535,106 (8,855)
6:end of verified boot 543,927 (8,821)
1 MHz:
504:finished TPM initialization 266,293 (30,747)
...
512:finished TPM PCR extend 513,711 (20,108)
513:starting locking TPM 513,711 (0)
514:finished locking TPM 521,311 (7,599)
6:end of verified boot 528,893 (7,581)
BUG=b:249201598
TEST=On nivviks and nereid, all timing requirements in the spec are met.
Frequencies:
nivviks - 972.01 kHz
nereid - 968.99 kHz
Change-Id: I9dd783527d4215ed7d79d69853a1f321ea2d8a28
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Commit c7204b5a4 [mb/google/guybrush: Enable backlight in the OS]
disabled the GPIO for the display backlight in favor of using ACPI
to enable it, but this breaks display output for payloads which do
not/can not enable the backlight GPIO themselves (edk2, grub, SeaBIOS).
Re-enable the GPIO for display backlight so that payloads other than
depthcharge work properly.
TEST=build/boot google/dewatt with Tianocore payload, verify payload
display visible.
Change-Id: I2519d779954ed89486045aa7de0b18f1c31a4374
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67246
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Example for Alder Lake PTT:
Handle 0x004C, DMI type 43, 31 bytes
TPM Device
Vendor ID: INTC
Specification Version: 2.0
Firmware Revision: 600.18
Description: Intel iTPM
Characteristics:
TPM Device characteristics not supported
OEM-specific Information: 0x00000000
TEST=Execute dmidecode and see the type 43 is populated with PTT
on MSI PRO Z690-A WIFI DDR4
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I05289f98969bd431017aff1aa77be5806d6f1838
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Mendocino supports LP5x but currently doesn't support SPDs that use the
LP5x memory type, 0x15. This commit updates set 1 SPDs, which are
currently only used for mendocino, to use 0x13 for their memory type.
BUG=b:245509394
TEST=Generated SPDs, verified that only set 1 have changed to 0x13
Change-Id: I46606cb5ff871296d0214e1f781c3b22e93d24ea
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67747
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Fix the warning below when building GA-945GCM-S2L with 64-bit:
src/arch/x86/idt.S:216: Warning: no instruction mnemonic suffix given and no register operands; using default for `iret'
Change-Id: Ibbc106714e25293951a71d84fea0a660f41f9c02
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61336
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
skiboot's Makefile always executes $(CC) to determine whether its clang
or GCC and not setting CROSS for clean target results in this annoying
output (assuming `powerpc64-linux-gcc` isn't available):
make[2]: powerpc64-linux-gcc: No such file or directory
Change-Id: I242b2d7c1bdf1bbd70fd4e4e0605341fe8301ca5
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67053
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
This patch adds ACPI configurations of 8MP YHUX and 2MP CJFKF28-1
as world- and user-facing cameras of Rex.
BUG=b:246413264
TEST=Verified world- and user-facing cameras using Chrome Camera App on
Google/rex device.
Signed-off-by: Daniel Kang <daniel.h.kang@intel.com>
Change-Id: Iaaa16e491a66500606b3a9eb1d87f396641778e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Add support for the following two new memory parts to support a new
SKU that has two memory options that brya0 does not have:
MT53E2G32D4NQ-046 WT:C
MT53E512M32D1NP-046 WT:B
BUG=b:248126749
TEST="emerge-brya coreboot chromeos-bootimage", flash a skolas with
an image-brya0.serial.bin and verify it boots successfully to kernel.
Change-Id: I28667918e5a183339febdc054465effeac8bddbe
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67879
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Having to use a runtime configurable option backend like CMOS just to
specify the value of the "fn_ctrl_swap" option is annoying. Introduce
a new Kconfig option to allow specifying the fallback value, which is
only used when the option backend cannot provide a value.
Change-Id: I00bb3cd60c443fc0c8adb82e8e0c436dfc5de24b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67836
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use just one function to get the chipset powerstate and add an argument
to specify the powerstate claimer {RTC,ELOG,WAKE} and adjust the
failure log accordingly.
TEST: compile tested and qemu emulation successfully run
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: I8addc0b05f9e360afc52091c4bb731341d7213cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The current IPU ES entry value is always set to true for ADL-N and
kernel picks the ES version of the main IPU FW even for the production
bootloader but loading is not successful due to the authentication
failure.
Alderlake-N silicon has the same CPU id for all the SKU's and
also the production binaries are backward compatible with ES parts.
This change removes the IPU ES support ACPI entry since the
kernel needs to load the production IPU main firmware on both the
ES/QS parts.
BUG=b:248249032
TEST=Verify the Camera functionality by enabling the IPU secure mode
on ADL-N variants with both ES/QS silicon.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I75b222e6f2b1ccdc5b6c448eb60afff3c1da3a8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
In order that GPP_H13 not use the GPIO override programming from its
baseboard (brya), explicitly program GPP_H13 to a output HIGH instead
of relying on the 20K pullup from the baseboard.
BUG=b:240617195
TEST=SSD still functional
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Iddedebe2d5cfc0123932b14980d1268bcb147703
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
The next rev of this board will move the dGPU PEXVDD enable pin from
GPP_E10 to GPP_F12. This patch handles both the old and newer revisions
by using an ACPI Name to hold the GPIO # for PEXVDD enable. It also
cleans up the GPIO handling a little bit between board revs.
BUG=b:242752623
TEST=dGPU is functional and power sequencing tests still pass on board
rev 2
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Icc7968777f86ab07561b0a861b7d22ec714d1c34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
On Banshee, when the privacy switch is toggled the camera is
disconnected. Which means that we will never be able to tell the user
that the privacy switch is enabled when the camera is on, making the
virtual control unusable.
Remove the description.
BUG=b:248219472
BRANCH=firmware-brya-14505.B
TEST=none
Change-Id: I1a241bd889c0c1aae039510a0620748b2f7a6806
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The headers added are generated as per FSP v3361.03
In the future, when Alder Lake and Raptor Lake fsp align, Raptor Lake
fsp headers can be deleted and Raptor Lake soc will also use headers
from alderlake/ folder.
BUG=b:247855492
BRANCH=firmware-brya-14505.B
TEST=Boot to OS
Signed-off-by: Selma Bensaid <selma.bensaid@intel.com>
Change-Id: I267a0aefca18492bcbcfbf7acbe271887f0a39cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67748
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Instead of defining NUM_FIXED_MTRRS in both cpu/x86/mp_init.h and
cpu/x86/mtrr/mtrr.c in two different ways that will evaluate to the same
value, define it once in include/cpu/x86/mtrr.h which is included in
both C files.
TEST=Timeless build for amd/mandolin results in identical firmware image
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71cec61e22f5ce76baef21344c7427be29f193f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The current MRC cache update process is slow (28 ms on nissa), because
cbmem is not cached in romstage. Specifically, the new MRC data returned
by the FSP is stored in the FSP reserved memory in cbmem, so operations
on the new data (computing the checksum, comparing to the old data) are
slow.
Replace the data checksum in the MRC header with a hash, and compare
hashes instead of comparing the full data. This has two benefits:
1. The xxhash function is faster than computing an IP checksum (4 ms vs
14 ms on uncached data on nissa).
2. There's no need to memcmp() the full MRC data, which takes 14 ms on
nissa.
Before:
550:starting to load ChromeOS VPD 867,930 (4,664)
3:after RAM initialization 896,020 (28,090)
4:end of romstage 906,274 (10,254)
After:
550:starting to load ChromeOS VPD 864,820 (4,649)
3:after RAM initialization 869,652 (4,831)
4:end of romstage 879,909 (10,257)
BUG=b:242667207
TEST=Check that MRC caching still works as expected on nissa. Corrupt
the MRC cache and check that memory is retrained.
Change-Id: I1b7848d1d05e555b61e0f1cb605550dfe3449c6d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67670
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Recently published Intel CedarIslandFSP binary contains PE images in
FSP-M and FSP-S. This causes coreboot boot hang on DeltaLake servers.
PI spec PI_Spec_1_7_final_Jan_2019 on uefi.org talks about FV files
requiring to support SECTION_PE32 sections and FSP specification
states that FSP images are created in alignment with PI specification.
FSP images are relocated at build time and run time using the func
fsp_component_relocate. That code only supported TE image relocation
so far.
The change required to add support for pe_relocate in fsp-relocate.c
I had to move a few functions to top of file as they need to be used
by pe_relocate but were placed below the te_relocate function. I chose
to place pe_relocate function next to te_relocate.
The code supports PE32 format, not PE32+, at this time.
Links for PE and FSP specs are provided below for reference.
Link= https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf
Link= https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
TESTED=
This code is tested with FSP version 33A for DeltaLake boot which has
FSP-M and FSP-S as PE32 sections. This FSP version does not boot on
DeltaLake without this change.
Change-Id: I01e2c123d74f735a647b994aa66419c9796f193e
Signed-off-by: Eddie Sharma <aeddiesharma@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nathaniel L Desimone <nathaniel.l.desimone@intel.com>
Instead of redefining the register address in smihandler.c, use the
existing definitions from include/cpu/x86/lapic_def.h.
TEST=Timeless build for lenovo/g505s which includes this file in the
build results in identical firmware image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id22f9b5ce53c7bced6bbcc3f5026d4c793b34f78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67776
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
'Mendocino' was an embargoed name and could previously not be used.
Update references for consistency with the correct naming convention.
BUG=b:245727030
TEST=builds and boots to kernel
Cq-Depend: chrome-internal:4878294
Cq-Depend: chromium:3763392
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: Ic0248a872dfc92486658aa9bd92bed755dbf59d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67750
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add new PSP svc call to pass psp firmware hash table to the PSP.
psp_verstage will verify hash table and then pass them to the PSP.
The PSP will check if signed firmware contents match these hashes.
This will prevent anyone replacing signed firmware in the RW region.
BUG=b:203597980
TEST=Build and boot to OS in Skyrim.
Change-Id: I512d359967eae925098973e90250111d6f59dd39
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67259
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the devicetree driver example into a separate page under the
drivers category, and link to it from both the devicetree page and
the drivers index page. This makes more sense from a grouping
perspective and makes the info easier to find.
Change-Id: Ic3ca80b93a0020737c7ccb5313a0877172022e1a
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add SOC_INTEL_COMMON_PCH_CLIENT which is specific to Apollo
Lake. This is used to select the options that Apollo Lake
requires, without the ones specific to a PCH as Apollo Lake
doesn't have a PCH.
This change also enables SOC_INTEL_COMMON_PCH_LOCKDOWN for
Apollo Lake.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I084a05f904a19f3b7e9a071636659670aa45bf3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently the `pch_pirq_init()` function in lpc_lib.c will program
PIRQ IRQs for all PCI devices discovered during enumeration. This
may not be correct for all devices, and causes strange behavior
with the Nvidia dGPU; it will start out with IRQ 11 and then after
a suspend/resume cycle, it will get programmed back to 16, so the
Linux kernel must be doing some IRQ sanitization at some point.
To fix this anomaly, explicitly program the IRQ to 16 (which we
know is what IRQ it will eventually take).
BUG=b:243972575
TEST=`lspci -vvv -s1:00.0|grep IRQ` shows IRQ 16 is programmed
at boot and stays consistent after suspend/resume.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I66ca3701c4c2fe5359621023b1fd45f8afd3b745
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67746
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to Nvidia, the GC6 flag (DFEN) should not get cleared after
a successful GC6 entry; the kernel driver will not re-inform ACPI
that the exit should be GC6 exit as well.
BUG=b:243888246
BRANCH=brya
TEST=tested by Nvidia
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I220795928d03f269de48278ea0ab57de7253fad5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67745
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The hatch and puff baseboards have diverged enough to where it makes
more sense to split them into separate boards. Copy the mb/google/hatch
directory into a new dir 'puff' and strip out all boards and items
related to the hatch baseboard. Remove all puff-related items from the
original hatch directory. Clean up and alphabetize Kconfig selections.
Test: build and boot akemi hatch variant and wyvern puff variant.
Change-Id: I8c7350f3afcff3ddefc6fa14054a3f9257568cd3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62970
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fast SPI driver reports the BIOS window as reserved so that the OS
is aware of this region. Now that platforms which supports an extended
BIOS window are added to this driver, add the extended range as reserved
as well if it is enabled. And since this is now handled in the SPI
driver itself, remove the extended BIOS region reporting from
common systemagent code.
Change-Id: Ib5c735bffcb389be07c876d7b5b2d88c545a0b03
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67529
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
There are two classes of SPI controllers on Intel chipsets:
* generic usable SPI controllers
* SPI controller hosting the BIOS flash (fast SPI controller)
While the first class can be used for generic peripheral attachment the
second class mostly controls the BIOS flash and a TPM device (if
enabled). The generic SPI driver is not fully applicable to the fast SPI
controller. In addition, the fast SPI controller reports the reserved
MMIO range used for the BIOS flash mapping so that the OS is aware of
this range.
This patch moves the fast SPI controller of all known SoCs to the
fast SPI driver in common code. In addition, the PCI device for the
fast SPI controller is removed from the function 'spi_soc_devfn_to_bus'
as this is a callback of the generic SPI driver.
Change-Id: Ia881c1d274acdcf7f042dd8284048a7dd018a84b
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Create Kconfig options and boot state machine callback in ramstage for
an early initialization of the PTN3460 DP-to-LVDS bridge. This allows
showing the bootsplash screen on mainboards utilizing this chip during
the PCI device enumeration.
BUG=none
TEST=Select PTN3460_EARLY_INIT config switch in mainboard Kconfig and
check the log for "Attempting PTN3460 early init" message. If the
board (e.g. siemens/mc_apl7 in this case) is also configured for
showing the bootsplash logo, it should be now visible.
Change-Id: I5424d062b3fb63c78cfced3971376353be11c504
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67681
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All cherry boards (tomato, dojo) share the same SKU ID encoding, in the
sense that a device has NVMe storage if and only if the BIT(1) of SKU ID
is set (otherwise eMMC). Therefore, instead of hard coding the list of
NVMe (PCIe) SKU IDs, we check the BIT(1) to decide whether to initialize
PCIe.
In addition, in preparation for UFS devices coming in the future,
reserve BIT(3) (which is unset for all of current SKUs) for them.
BUG=b:237953117, b:233327674
TEST=emerge-cherry coreboot
BRANCH=cherry
Change-Id: I9b30338645a87f29f96a249808b90f1ec16f82df
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
CB:63475 inadvertently disabled the STM by moving its load point
off of the MSEG boundry, which is a hardware requirement. In
addition, the BIOS resource list cannot be located within the
MSEG. This patch fixes the issue by moving the STM load point
to the MSEG boundry and placing the bios resource list just below
the MSEG where the STM setup functions can find it.
Fixes: commit 5747f6c (cpu/x86/smm_module_loader.c Rewrite setup)
Signed-off-by: Eugene Myers <edmyers@tycho.nsa.gov>
Change-Id: I7359939063bb1a172fcb701551c099edebfbedd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67665
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes AP hanging issue caused by the handshaking between
MCUPM and CPUfreq driver.
CPUfreq hardware failed to read MCUPM registers due to DEVAPC
permission. Therefore, update the DEVAPC settings to fix this issue.
BUG=none
TEST=CPUfreq in kernel test pass.
Change-Id: I6b30b01fc0be052182599709cbcc9139e6d09742
Signed-off-by: Liju-Clr Chen <liju-clr.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67724
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch provides a workaround which skips requesting IOM for D3 cold
entry sequence.
BUG=b:244082753
TEST=Verified MUX configuration after hot plugging Type-C devices on
Rex and MTL RVP boards.
Change-Id: I17bcde75360c4b2b40885d355702e3e5f45d770a
Signed-off-by: zhaojohn <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch introduces new target: junit.xml-unit-tests, which builds and
runs unit-tests. It also creates build log containing build logs. This
feature allows for one to see build failures in Jenkins dashboard.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I94184379dcc2ac10f1a47f4a9d205cacbeb640fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67372
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch makes dedede EC wake up AP from s0ix when the state of
charge drops to low_battery_shutdown_percent.
Demonstrated as follows:
1. Boot OS.
2. Run powerd_dbus_suspend.
3. On EC, run battfake 4.
4. System resumes.
BUG=b:244253629
TEST=Verified on dedede
Change-Id: I39234d2b9e739383b5f96be49077f8c9831fa0fa
Signed-off-by: Ivan Chen <yulunchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
FSP silicon 3347 changed the default value of the EnergyEfficientTurbo
Updateable Product Data (UPD), enabling the Energy Efficient Turbo
feature by default. This feature prevents the cores from entering
Turbo frequency under heavy load.
As a result of this FSP change, coreboot explicitly disables this
feature to stay consistent with commit `caa5f59279e Revert
"soc/intel/alderlake: Enable energy efficiency turbo mode"'.
BRANCH=firmware-brya-14505.B
BUG=b:246831841
TEST=verify that bit 19 of MSR 0x1fc is set. 'iotools rdmsr 0 0x1fc'
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I7498f87eb4be666b34cfccd0449a2b67a92eb9db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
On ADLRVP with LP5 memory, MRC team recommends enabling ECT(Early
Command Training) to avoid hang during boot process.
BRANCH=firmware-brya-14505.B
TEST=Booted to OS on ADLRVP with LP5 memory.
Signed-off-by: Zhixing Ma <zhixing.ma@intel.com>
Change-Id: I2472707825bbbdd8e5c12a714e0d40ea0b458838
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Skolas board is based on Raptor Lake SoC, not Alder Lake. The code
change sets CPU power limit values as performance configuration based
on various Raptor Lake SoC SKUs as per the document #686872.
BUG=b:242869605
BRANCH=None
TEST=Built and tested on skolas board
Change-Id: Ieb3ca4ff77039412ef56da49e1b438f5e0b9db02
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Coverity is throwing a bunch of "maybe uninitialized" errors for tu
struct. Initialize the tu struct with zero.
BUG=b:182963902,b:216687885
TEST=Validated on qualcomm sc7280 development board.
Monitor name: LQ140M1JW49
Change-Id: Ie249ad4f53abc91376445420712364a28618a15a
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
This patch adds power state 1/2/3 threshold setting interfaces
and pass the settings to FSP.
BUG=b:229803757
BRANCH=None
TEST=Add psi1threshold and psi2threshold to overridetree.cb and
enable FSP log to ensure the settings are incorrect.
Signed-off-by: Gaggery Tsai <gaggery.tsai@intel.com>
Change-Id: I0330ede4394ebc2d3d32e4b78297c3cb328660d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67463
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Add a variant specific S0ix hook to fill the SSDT table to disable and
enable camera during suspend and resume respectively.
BUG=b:206911455
TEST=Build Boten BIOS image. Ensure that camera is disabled during
suspend and enabled during resume.
Change-Id: I3229b22b8d8651bf2d9df25b10ce6749efde7cf6
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Henry Sun <henrysun@google.com>
Reviewed-by: Shou-Chieh Hsu <shouchieh@google.com>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Maulik Vaghela <maulikvaghela@google.com>
The µcode updates for Broadwell come from coreboot's blobs submodule
and have not been updated in at least 7 years. Use the µcode updates
available in the intel-microcode submodule. This change forgoes some
µcode updates for old Broadwell ULT/ULX steppings with CPUID 0x306d2
and 0x306d3, as well as an old µcode update for Haswell ULT/ULX CPUs
with CPUID 0x40651 in favor of a newer intel-microcode revision that
was already being used: when the µcode updates are concatenated into
one file, the newer µcode update revision would be placed before the
older revision, so the latter would never be used.
Change-Id: I67f8a58552bd211095c183e6f7a219d60e3be162
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67526
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Commit 27126f135d (cpu/intel/haswell: add
Crystal Well CPU IDs) introduced new Haswell CPUIDs but did not include
any µcode updates for them. It is unknown how this could have worked as
the initial µcode inside the CPU can be quite unstable. Intel CPUs with
support for FIT (Firmware Interface Table) can have their µcode updated
before the x86 reset vector is executed.
The µcode updates for Crystal Well CPUID 0x40661 can be found inside the
intel-microcode submodule. There are no publicly available µcode updates
for Crystal Well CPUID 0x40660 as it is a pre-production stepping, which
is not meant to be used anymore. Hook up the available µcode updates for
Crystal Well CPUs.
Change-Id: If5264f333e681171a2ca4a68be155ffd40a1043b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
There are two types of Haswell/Broadwell platforms: Trad(itional) with
separate CPU and PCH packages, and ULT/ULX where the CPU and PCH share
one package. Mainboards can specify which platform type they are using
the `INTEL_LYNXPOINT_LP` Kconfig option. There are so many differences
between Trad and ULT/ULX that it's not worth doing runtime detection.
The CPUIDs are different for Trad and ULT/ULX platforms, and so are the
µcode updates. So, including Trad µcode updates in a coreboot image for
an ULT/ULX mainboard makes no sense, and vice versa.
Adapt the Makefile so that only relevant µcode updates are added. Also,
add a few comments to indicate which updates correspond to which CPUs.
TEST=Run binwalk on coreboot.rom to verify included µcode updates for:
- Asrock B85M Pro4 (Haswell Trad)
- HP Folio 9480M (Haswell ULT/ULX)
- Purism Librem BDW (Broadwell ULT/ULX)
Change-Id: I6dc9e94ce9fede15cbcbe6be577c48c197a9212a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
FSP-M is not run XIP so it can be compressed. This more than halves
the binary size. 364544 bytes -> 168616 bytes.
On the up/squared this also results in a 83ms speedup.
TESTED: up/squared boots.
Change-Id: Ic76b51f0f3007b59ccb9f76b6a57bb9265dab833
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48158
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
On the intel/glkrvp
compressed:
- romstage: 29659
- verstage: 31303
non compressed:
- romstage: 46244
- verstage: 47012
On qemu (with some additional patch to not run XIP)
compressed:
- romstage: 11203
non compressed:
- romstage: 13924
Even with a small romstage the size improvements are substantial,
which should result in a speedup when loading the stage. On the
up/squared loading romstage is sped up by 9ms.
TESTED: successfully boot the up/squared & google/vilboz.
Change-Id: Iac24d243c4bd4cb8c1db14a8e9fc43f508c2cd5d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Configure FSP S UPDs to allow coreboot to handle the lockdown.
The main change here is setting `Write Protection Support` to 0,
as the default is Enabled, which shouldn't allow writes (even though
it seems to).
The UPDs are identical on APL and GLK, but all ones configured
in this patch have been there since their initial releases.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I35185b498315511f3236758caebfe2f9c28fd04a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65039
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adjust the EEPROM layout to account for two new fields: board part
number and product part number. In addition, put them in a Type 11
SMBIOS table (OEM Strings).
TODO: This currently stores the "raw" part numbers, should we add a
prefix to the SMBIOS strings?
Change-Id: I85fb9dc75f231004ccce2a55ebd9d7a4867fcb93
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67276
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use dynamic power and thermal configuration (DPTC) via ACPI ALIB calls
to throttle the SOC when there is no battery or critically low battery,
to enable the SOC to boot without overwhelming the AC charger and
browning out.
DPTC is not enabled for low/no battery mode with this CL. It will be
enabled for Skyrim in a following CL.
BRANCH=none
BUG=b:217911928
TEST=Boot skyrim
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Ifeddb99e97af93b40a5aad960d760e4c101cf086
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67189
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add VRM DPTC limit registers. These are required when throttling the SOC
for low/no battery mode to prevent the SOC from overwhelming the
charger.
b/245942343 is tracking passing these additional fields to the FSP and
having the FSP configure them.
BRANCH=none
BUG=b:217911928
TEST=Build skyrim
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Ie62129d967192f9a9cf654b1854d7dbe4324802a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67378
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update acpigen_write_alib_dptc() to support "low/no battery mode",
which throttles the SOC when there is no battery connected or the
battery charge is critically low.
This is in preparation for enabling this functionality for Mendocino.
BUG=b:217911928
TEST=Build zork
TEST=Boot nipperkin
TEST=Boot skyrim
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Icea10a3876a29744ad8485be1557e184bcbfa397
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66804
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are platforms equipped with AMD SoC where I2C3 controller
connected to TPM device is shared between X86 and PSP. In order to
handle this, PSP acts as an I2C-arbitrator, where x86 (kernel) sends
acquire and release requests to be accepted by PSP.
Introduce new CONFIG for Mendocino SoCs similar to what we have for
Cezanne.
BUG=b:241878652
BRANCH=none
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: I015a24715271d2b26c0bd3c9425e20fb2987a954
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
ELAN6918 Power Sequencing seems not perfectly matching
with the previous platforms and setting GPP_C06 to high prior
to the power sequencing is actually makes it work.
Ideally Power Sequencing should be as below for ELAN6918 (in ACPI)
`POWER enabled -> RESET deasserted -> Report EN enabled`
But below sequence is only working currently:
`Report EN enabled (ramstage) -> POWER enabled (ACPI) -> RESET
deasserted (ACPI)`
BUG=b:247029304
TEST=Verified ELAN touch panel is working as expected after booting
Google/rex device to ChromeOS.
Change-Id: Ideaeb0faa882b8e603534bbface51ea76923d436
Signed-off-by: Eran Mitrani <mitrani@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
The lbtable contains the memory entries that have fields unnaturally
aligned in memory. Therefore, we need to perform an aligned_memcpy() to
fix the issues with platforms that don't allow unaligned accesses.
BUG=b:246887035
TEST=cbmem -l; cbmem -r ${CBMEM ID}
Change-Id: Id94e3d65118083a081fc060a6938836f6176ab54
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
gcc12+ will require riscv architecture selection to come not only with
featurei suffixd charactersa, it also comes with feature_ful suffix_ed
words_mith. Much creative, very appreciate.
To accommodate for this madness, enable the already existing (but off by
default) support for that in our gcc11 build, support using by detecting
the compiler's behavior in xcompile and pass that knowledge along to our
build system.
Then cross our fingers and hope for the best!
Change-Id: I5dfeed766626e78d4f8378d9d857b7a4d61510fd
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The patch updates comment on HFSTS1.spi_protection_mode.
The spi_protection_mode indicates SPI protection status as well as EOM
status (in a single staged EOM flow). Starting from TGL platform, staged
EOM flow is introduced. In this flow, spi_protection_mode alone doesn't
indicate the EOM status.
For information on EOM status, please refer secton# 3.6.1 in doc#
612229.
TEST=Build code for Gimble
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I19df5cfaa6d49963bbfb3f8bc692d847e58c4420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
SOC_AMD_COMMON_BLOCK_ACPI_DPTC can be enabled conditionally for any
skyrim boards, similar to mainboard/google/zork/Kconfig. This makes the
value dptc_tablet_mode_enable redundant.
This CL removes dptc_tablet_mode_enable so DPTC is controlled entirely
with the Kconfig value SOC_AMD_COMMON_BLOCK_ACPI_DPTC. This means DPTC
is only included for boards that actually enable it.
BRANCH=none
BUG=b:217911928
TEST=emerge-skyrim coreboot
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: I73fca5a16826313219247f452d37fb526ad4f4df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
SOC_AMD_COMMON_BLOCK_ACPI_DPTC can be enabled conditionally for any
guybrush boards, similar to .mainboard/google/zork/Kconfig This makes
the value dptc_tablet_mode_enable redundant.
This CL removes dptc_tablet_mode_enable so DPTC is controlled entirely
with the Kconfig value SOC_AMD_COMMON_BLOCK_ACPI_DPTC. This means DPTC
is only included for boards that actually enable it.
BRANCH=none
BUG=b:217911928
TEST=emerge-guybrush coreboot
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: I07f1266fa80a6c9ee4ec3b3ba970a70c6c72fb54
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Moving the config value SOC_AMD_COMMON_BLOCK_ACPI_DPTC to
soc/amd/picasso/Kconfig and conditionally enabling it for only Morphius
boards makes the value dptc_tablet_mode_enable redundant.
This CL removes dptc_tablet_mode_enable so DPTC is controlled entirely
with the Kconfig value SOC_AMD_COMMON_BLOCK_ACPI_DPTC. This means DPTC
is only included for boards that actually enable it.
BRANCH=none
BUG=b:217911928
TEST=Build zork
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Ic54a9bb491234088be8184bec8b09e2e31ffa298
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
AMD CPUs have a convenient MSR that allows to set the SMBASE in the save
state without ever entering SMM (e.g. at the default 0x30000 address).
This has been a feature in all AMD CPUs since at least AMD K8. This
allows to do relocation in parallel in ramstage and without setting up a
relocation handler, which likely results in a speedup. The more cores
the higher the speedup as relocation was happening sequentially. On a 4
core AMD picasso system this results in 33ms boot speedup.
TESTED on google/vilboz (Picasso) with CONFIG_SMI_DEBUG: verify that SMM
is correctly relocated with the BSP correctly entering the smihandler.
Change-Id: I9729fb94ed5c18cfd57b8098c838c08a04490e4b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Some PCI IDs were missing, and at least one (SPT's fast SPI
device in a generic SPI driver) was wrong. Hence, this patch
actually changes behavior depending on the devices actually
present in a machine.
In this patch the Skylake devicetree is written in a single-line
style. Alternative, the device operations could be put on a separate
line, e.g.
device pci 00.0 alias system_agent on
ops systemagent_ops
end
Tested on Kontron/bSL6. Notable in the log diff is that the
CSE and SATA drivers are hooked up now.
Change-Id: I8635fc53ca617b029d6fe1845eaef6c5c749db82
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Currently we only have runtime mechanisms to assign device operations to
a node in our devicetree (with one exception: the root device). The most
common method is to map PCI IDs to the device operations with a `struct
pci_driver`. Another accustomed way is to let a chip driver assign them.
For very common drivers, e.g. those in soc/intel/common/blocks/, the PCI
ID lists grew very large and are incredibly error-prone. Often, IDs are
missing and sometimes IDs are added almost mechanically without checking
the code for compatibility. Maintaining these lists in a central place
also reduces flexibility.
Now, for onboard devices it is actually unnecessary to assign the device
operations at runtime. We already know exactly what operations should be
assigned. And since we are using chipset devicetrees, we have a perfect
place to put that information.
This patch adds a simple mechanism to `sconfig`. It allows us to speci-
fy operations per device, e.g.
device pci 00.0 alias system_agent on
ops system_agent_ops
end
The operations are given as a C identifier. In this example, we simply
assume that a global `struct device_operations system_agent_ops` exists.
Change-Id: I2833d2f2450fde3206c33393f58b86fd4280b566
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
parse_microcode_blob() returns success when it reaches max_fit_entries
microcode. It makes the FIT table size verification in
fit_add_microcode_file() useless. This patch makes
parse_microcode_blob() error out if max_fit_entries is reached.
Note that this size verification is critical as a FIT table only
partially listing the microcode patches can lead to boot failures as
recently observed on Raptor Lake-P.
BRANCH=firmware-brya-14505.B
BUG=b:245380705
TEST=compilation errors out when trying to stitch more than
CONFIG_CPU_INTEL_NUM_FIT_ENTRIES microcode patches.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Id9c5fb6c1e264f3f5137d29201b9021c72d78fde
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67454
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Haswell and Broadwell platforms usually stitch six microcode
patches. It has worked so far with the default value of four thanks a
bug which is being fixed by `util/ifittool: Error out if microcodes do
not fit the FIT table' commit.
BUG=b:245380705
TEST=Jenkins build without failing on the FIT table size
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I23bf79a3e8918499f6c51e6ef829312d5872181a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move enabling SOC_AMD_COMMON_BLOCK_ACPI_DPTC from
soc/amd/picasso/Kconfig to mainboard/google/zork/Kconfig and
conditionally enable it only for Morphius boards.
This reduces which boards/variants have DPTC enabled to only those that
actually use it.
BRANCH=none
BUG=b:217911928
TEST=Build zork
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Iddebcf5dbadae135c8110e2afd9ad76ef7dcc09d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67637
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the FSP binary check logic is fixed to only check the FSP files
if ADD_FSP_BINARIES is selected, the default paths for the not yet
published Cezanne FSP binaries can be added without breaking abuild.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9950a1fe7bd1b21109cca9631de1a8f1d265d9b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add support for having different Security Patch Level (SPL) table files
in the read-only and the read-write A/B partitions. This allows the SPL
table file in the main or RO FMAP partition to only cover the embedded
firmware binaries in that partition and have a separate SPL file in the
RW A and B partitions that covers the embedded firmware binaries in the
RW partitions.
BUG=b:243470283
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1ba8c370ce14f7ec88e7ef2f9d0b64d6bb4fa176
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Turn off the LAN power which is controlled by GPP_A10 in S0ix states.
For an USB device, the S0ix hook is needed for the on/off operationas
to take place.
BUG=b:245426120
BRANCH=firmware-dedede-13606.B
TEST=emerge-shotzo coreboot
check LAN LED off in S0ix states
check LAN function ok after suspending 500 loops
check SSDT table has MS0X entry
Scope (\_SB)
{
Method (MS0X, 1, Serialized)
{
If ((Arg0 == One))
{
\_SB.PCI0.CTXS (0x41)
}
Else
{
\_SB.PCI0.STXS (0x41)
}
}
}
Change-Id: I3fcab4a73239b4f006839c0c81e9b4cc74047b77
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67528
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Some PLLs are not used in firmware, so we should keep them as hardware
default values. If their modules want to set them, the corresponding
drivers should set them in the kernel stage.
BUG=b:233720142
TEST=build pass.
Signed-off-by: Garmin Chang <Garmin.Chang@mediatek.com>
Change-Id: I9bee18005ffed7fc1785c7fd3c0370c8293064ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67547
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
vpp_sel and ethdr_sel are vdosys clock source select mux.
Steps to change to support 4K source:
1. Change vpp_sel source to mainpll_d6 to run at 416MHz.
2. Change ethdr_sel source to univpll_d6 to run at 416MHz.
BUG=b:233720142
TEST=build pass.
Signed-off-by: Garmin Chang <Garmin.Chang@mediatek.com>
Change-Id: I24f133b9b383fd019983cb29a213b47717148e97
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67545
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To improve boot time, raise little CPU from 500MHz to 2GHz at romstage
(before DRAM calibration).
FW logs:
Check CPU freq: 1999968 KHz, cci: 1600012 KHz
TEST=cpu freq and cci freq run correctly.
BUG=b:244251006
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: Ic1bed53669baa15f797c9a952455376a39d29cf3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67544
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The observed CPU big core frequency is double compared with the current
PLL setting. Therefore fix the wrong setting for PLL register
APMIXED_ARMPLL_BL.
Moreover, we also fix some wrong settings for other PLLs.
TEST=CPU frequency of big core CPU is correct and bootup correctly.
BUG=b:244215537
Signed-off-by: Garmin Chang <Garmin.Chang@mediatek.com>
Change-Id: I9126f439d7a5136b2fb8d66f103ef427a0b08a99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67543
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since mono_time is now 64-bit, the utility functions interfacing with
mono_time should also be 64-bit so precision isn't lost.
Fixed build errors related to printing the now int64_t result of
stopwatch_duration_[m|u]secs in various places.
BUG=b:237082996
BRANCH=All
TEST=Boot dewatt
Change-Id: I169588f5e14285557f2d03270f58f4c07c0154d5
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add the 'detect' flag to the Elan touchpad, so coreboot can determine
which touchpad type is present at runtime and generate the correct
ACPI entry for it (the Synaptics touchpad already has the flag).
Test: build/boot google/nami, verify touchpad works under Linux/Windows
Change-Id: I437d1d470552d55496dfe611f441331127c64250
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The current HWIDs for ADL RVP are reported as invalid by Chrome on
ChromeOS; fix it by generating new valid HWIDs with the following
commands:
```
./util/chromeos/gen_test_hwid.sh ADLRVPM
./util/chromeos/gen_test_hwid.sh ADLRVPN
./util/chromeos/gen_test_hwid.sh ADLRVPP
```
BUG=b:243899466
Change-Id: Iad6f47e67c2d35363b042aabec8b3317d5bfc111
Signed-off-by: Victor Ding <victording@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67532
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Problem: OTA is triggering warmboot, where DDR is
in self-refresh mode. Due to which DDR training
is not going well.
Change: Verify reboot type in case of OTA. If it is warmboot, will
force for cold boot inorder to trigger DDR training
BUG=b:236990316
TEST=Validated on qualcomm sc7180 development board.
Test observation: Cold boot is triggered forcefully,
if current reboot is warmboot in case of OTA
Signed-off-by: Venkat Thogaru <quic_thogaru@quicinc.com>
Change-Id: I908370662292d9f768d1ac89452775178e07fc78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67406
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add go.mod containing the full name of the project according to the
docs [1]: review.coreboot.org/coreboot.git/util/intelp2m, and also,
based on this, rename the internal packages to point to the absolute
path. This will allow Go Managing Dependencies System to integrate
packages from intelp2m to third-party Go written on the Go language [1].
This also requires fixing the Golang compiler version in go.mod: use
go1.18 [2], the latest up-to-date version.
[1] https://web.archive.org/web/20220910100342/https://go.dev/doc/modules/managing-dependencies
[2] https://web.archive.org/web/20220910100206/https://tip.golang.org/doc/go1.18
[ TEST ]
1) Import the coreboot project into some go project:
$cd path/to/go-project
$go get review.coreboot.org/coreboot.git
go: downloading review.coreboot.org/coreboot.git v0.0.0-20220903004133
-39914a50ae16
go: added review.coreboot.org/coreboot.git v0.0.0-20220903004133
-39914a50ae16
Thus, 'go get' correctly downloaded the contents of the repository.
2) Import intelp2m:
$cd path/to/go-project
$go get review.coreboot.org/coreboot.git/util/intelp2m
review.coreboot.org/coreboot.git/util/intelp2m imports
./config: "./config" is relative, but relative import paths are
not supported in module mode
review.coreboot.org/coreboot.git/util/intelp2m imports
./parser: "./parser" is relative, but relative import paths are
not supported in module mode
Thus, the problem is in the package names, but after this patch, the
import should be without errors.
3) Import a repository with an incorrect url:
$cd path/to/go-project
$go get review.coreboot.org/coreboot/test
go: unrecognized import path "review.coreboot.org/coreboot/test":
reading https://review.coreboot.org/coreboot/test?go-get=1:
404 Not Found
This has not happened in previous cases.
Change-Id: I12efae31227129b8c884af10fb233f398c4094e7
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This reverts commit f83b7d494e.
It turns out we have tests which use `futility validate_rec_mrc` to
validate the MRC cache, which includes verifying the data checksum.
Revert this to allow the tests to pass while we figure out how to fix
this.
BUG=b:245277259, b:242667207
TEST=None
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: Id913d00584444c21cb94668bdc96f4de51af7cee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The following boards are setting DTPC tablet mode values without
corresponding device tree values, meaning they are effectively setting
"random" values for tablet mode:
1. Cezanne
2. Mendocino
The device tree has tablet mode disabled, so the code should never be
exercised, but this CL removes it entirely to cleanup "dead" code.
BRANCH=none
BUG=b:217911928
TEST=Build nipperkin
TEST=Boot skyrim
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Ide96f255b69670d1b4c37ca2f94cc3504a958b57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Refer to PCI Express Base rev6.0 v1.0, 4.2.7 Link Training and Status
State Rules, Lane Error Status is normal to record the error when link
training. To make sure Lane Error Status is correct in OS runtime,
add a Kconfig PCIEXP_LANE_ERR_STAT_CLEAR that clears the PCIe lane error
status register at the end of PCIe link training.
Test=On Crater Lake, lspci -vvv shows
bb:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)
(prog-if 00 [Normal decode])
Capabilities: [a30 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn- PerformEqu-
LaneErrStat: LaneErr at lane: 0
Signed-off-by: Wilson Chou <Wilson.Chou@quantatw.com>
Change-Id: I6344223636409d8fc25e365a6375fc81e69f41a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Linux always "turns on" a PowerResource when it boots, regardless of
_STA, so the _ON routine should be idempotent. In this case, it all is,
except for the LTR restore, which would restore a value of 0 when _ON is
run the first time, which means that LTR is disabled on the root port
from then on, as the save/restore routines will keep saving/restoring
that 0. THis patch fixes the problem by moving the power checks from
PGON/PGOF to GCOO/GCOI.
BUG=b:244409563
TEST=boot agah and verify that LTR is still enabled on the root port
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4ed78323608eede5b8310598f1f1115497ab2b5b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67278
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
The Linux kernel runtime D3 framework expects a PCIe device to have a
power resource in order to be properly power-manageable. The _PR0/_PR3
values were pointing at the PEG0 Device, which is not a PowerResource,
so this must have confused the RTD3 framework and RTD3 was not
functional. Removing the _PR0/_PR3 fixes the problem.
BUG=b:243888246
TEST=echo auto > /sys/bus/pci/devices/0000:01:00.0/power/control;
sleep 10;
echo on > /sys/bus/pci/devices/0000:01:00.0/power/control
After this there are no longer errors seen in dmesg about failing
to place the device into D0.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I83fa1e5fabd3257b097c10e7a13c9861872685ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
On some platforms the HFSTS4 bit 19 does not indicate active PTT.
Instead of ME HFSTS4, use TXT FTIF register to check active TPM for
the current boot. Discrete TPM shall be deactivated when PTT is
enabled so this always should return true value of PTT state.
Leave the old method for backwards compatibility if TXT FTIF would not
be applicable for older microarchitectures.
Based on DOC #560297.
TEST=Check if PTT is detected as active on MSI PRO Z690-A DDR4 WIFI
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3a55c9f38f5bb94fb1186592446a28e675c1207c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Instead of just printing the fatal errors, do early return so that
boot up time will be reduced during display init failure. Remove malloc
allocation and make tu a local variable.
Change-Id: I51f7a86d143128d2c426fb8940ff34a66152b426
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66975
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Refactor AMD DPTC tablet mode in preparation for adding low/no battery
DPTC settings.
1. Refactor and simplify acpigen_write_alib_dptc() into the following
functions:
- acpigen_write_alib_dptc_default()
- acpigen_write_alib_dptc_tablet()
2. Add device tree register value dptc_tablet_mode_enable to control
whether DPTC tablet mode is enabled for a variant.
3. Add dptc.asl to perform the necessary ACPI checking before modifying
the DPTC settings.
BRANCH=none
BUG=b:217911928
TEST=Build zork
TEST=Build nipperkin
TEST=Boot skyrim
Change-Id: I2518fdd526868c9d5668a6018fd3570392e809c0
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66994
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Thermal configuration registers are now located behind PMC PWRMBASE
for MeteorLake as well (same as ADL). Hence, using thermal common code
to sets the thermal low threshold as per mainboard provided
`pch_thermal_trip`.
Note: These thermal configuration registers are RW/O hence, setting
those early prior to FSP-S helps coreboot to set the desired low
thermal threshold for the platform.
TEST=Dump thermal configuration registers PWRMBASE+0x150c etc on
Google/rex prior to FSP-S shows that registers are now programmed
based on 'pch_thermal_trip' and lock register BIT31 is set.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I1d6b179a1ed43f00416d90490e0a91710648655e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67462
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch drops redundant MCHBAR programming in romstage as bootblock
already done with MCHBAR setting up.
TEST=Able to boot Google/Rex to ChromeOS and MCHBAR is set to correct
value as per iomap.h
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic2c05f47ab22dc7fe087782a1ce9b7b692ea157e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Unit-tests had more strict warning setings than main build. Sometimes it
can cause unit-tests builds to fail even if code compiles correctly when
building normal coreboot image.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ia219ccc8631b069436497eb45a1552a0910f7aa1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Add functionality such that the FPMCU is power cycled and has its reset
sequenced on boot.
This has been added such that we do not need to update the bootblock.
We are required to do this as bootblock exists in read-only flash for
devices that have already been manufactured and so have no method of
updating the sequencing there.
Power remains off during coreboot (after briefly being turned on in the
unchangeable bootblock).
Once control is handed over to the Kernel, it takes care of sequencing
the power and reset appropriately and ensures the FPMCU is unpowered for
>200ms on boot.
BUG=b:240626388
TEST=Confirmed FPMCU is still functional on Vell and Anahera.
Confirmed power is off for approximately 6 seconds on boot (target
>200ms).
Confirmed reset is de-asserted approx 5ms after power application
(target >2.5ms)
Change-Id: I9694f8837e0a72eaed42a5eeee92b0f120269086
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66915
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
1. There are two power sources for CPU:
- Logic power (VPROC).
- SRAM power (VSRAM_PROC).
2. There is a constraint between VPROC and VSRAM_PROC:
- 0mV <= VSRAM_PROC - VPROC <= 250mV.
With software control, the constraint might not always hold. Therefore,
we enable hardware tracking from PMIC MT6366 to ensure the constraint
is met automatically.
BUG=b:236353282, b:241615706
TEST=meet the constrain correctly when adjusting the voltage.
Signed-off-by: Sen Chu <sen.chu@mediatek.corp-partner.google.com>
Change-Id: I6012c57e60c009f1d599b57aab1c2526ee789208
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67436
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Config I2C high / low time in device tree to ensure I2C
CLK runs accurately at I2C_SPEED_FAST (400 kHz).
EE measured touchscreen/audio runs at 385.5/397.9kHz after tuning.
BUG=b:244403643
BRANCH=firmware-dedede-13606.B
TEST=Build and check after tuning I2C clock is under 400kHz
Change-Id: I7d9503e5f92295432e31f09ae791eaa18eac9d4d
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67242
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Configure _DSC to ACPI_DEVICE_SLEEP_D3_COLD so that the driver skips
initial probe during kernel boot and prevent privacy LED blink.
BUG=b:194979741
BRANCH=firmware-brya-14505.B
TEST=Build and boot skolas to OS. Verify entries in SSDT.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I3c32dd71ab454227b15913bda7f542230e5568db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Historically, ChromeOS devices have worked around the problem of OEMs
using several different parts for touchpads/touchscreens by using a
ChromeOS kernel-specific 'probed' flag (rejected by the upstream kernel)
to indicate that the device may or may not be present, and that the
driver should probe to confirm device presence.
Since c636142b, coreboot now supports detection for i2c devices at
runtime when creating the device entries for the ACPI/SSDT tables,
rendering the 'probed' flag obsolete for touchpads. Switch all touchpads
in the tree from using the 'probed' flag to the 'detect' flag.
Touchscreens require more involved power sequencing, which will be done
at some future time, after which they will switch over as well.
TEST: build/boot at least one variant for each baseboard in the tree.
Verify touchpad works under Linux and Windows. Verify only a single
touchpad device is present in the ACPI tables.
Change-Id: I47c6eed37eb34c044e27963532e544d3940a7c15
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67305
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The previous VBT binary was not properly configured, there were DP
display issues on some of the ports and resulted in hangs when FSP
debug was used. The updated VBT fixes all the issues.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I788240e36a9a90a5342ee9761f2c61ebf4caa9a4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67426
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCIe WWAN module used on rex requires control over 4 signals to
successfully power it on. It is desirable to do this before passing
control to the payload, because the modem requires a ~10 seconds
initialization phase before it can be used.
The corrected sequence looks like:
1) Drive device into full reset and enable power in bootblock
2) Deassert FCPO in romstage, after power rails stabilize
3) Deassert WWAN_RST#, then WWAN_PERST# in ramstage
BUG=b:244077118
TEST=FM350 could be enumerated via lspci
Measured signals to check start-up Timing Sequence, tpr/ton1/ton2.
Tpr = 572mS
Ton1 = 6.3s
Ton2 = 6.3+4.17ms
Signed-off-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Change-Id: I6cda9348ef7f54efe5ba2358040596a1c2da1b13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67332
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the missing spaces to two log message, like the one below.
WARNING: Device PCI: 03:00.0 requests a BAR with34 bits of address space, which coreboot is notconfigured to hand out, truncating to 29 bits
Change-Id: If933d8fb0db5b58ff12f043cc73172a3f6ffc624
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Missing power limit setting for Alder-Lake-N 7W soc.
Document reference: 645548 and 646929
BUG=b:245440443
BRANCH=None
TEST=Build FW and test on nivviks board and there is no error
message "unknown SA ID: 0x4617, skipped power limits configuration."
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Change-Id: Iefe17f5b574cc319fe9aad3850401a8aa8e31270
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Change the name of the CALIBRATION_REGION definitions used in two
separate locations. This conflict was causing an error for the
lint-001-no-global-config-in-romstage test.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If6734f2a7d9be669586ea350fb9979fcd422b591
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, the "loading FSP-S" timestamp is added in fsp_silicon_init().
However, most Intel platforms actually load FSP-S earlier than this, in
soc_fsp_load(). So the timestamp is added in the wrong place.
Add the timestamp in fsps_load() instead, after the load_done early
return so that it will only be added for the first call.
Before:
949:finished CSE firmware sync 961,833 (17,998)
17:starting LZ4 decompress (ignore for x86) 1,018,328 (56,495)
18:finished LZ4 decompress (ignore for x86) 1,018,797 (469)
30:device enumeration 1,035,096 (16,298)
971:loading FSP-S 1,048,082 (12,986)
954:calling FspSiliconInit 1,049,331 (1,249)
After:
949:finished CSE firmware sync 959,355 (16,370)
971:loading FSP-S 978,139 (18,784)
17:starting LZ4 decompress (ignore for x86) 1,015,796 (37,656)
18:finished LZ4 decompress (ignore for x86) 1,016,271 (475)
30:device enumeration 1,032,567 (16,295)
954:calling FspSiliconInit 1,046,867 (14,300)
BUG=b:239769975
TEST="loading FSP-S" is added in the right place on nivviks (see above).
Change-Id: Ib26cf96ae97766333fe75ae44381d4f7c6cc7b61
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Having a CSE Lite SKU's firmware is not necessarily depending
on the underlying hardware nor on having ChromeOS installed as
already mentioned in commit f3419b29b7 ("soc/intel/common/cse:
Drop dependency on CHROMEOS for SOC_INTEL_CSE_LITE_SKU").
For example RVP Boards sometimes have a CSE LITE FW, if Chrome board
related stuff is tested, which doesn't necessarily imply a ChromeOS
being used. It is therefore changed to an option, which can be
changed in menuconfig.
Change-Id: I4da7feab881ae43528c9d852cc842ac93fa9c6de
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67078
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To test the linters, we want to invert the results so that any test that
passes shows up as a failure. This will allow us to verify that all of
the linters are working correctly.
This will be tested nightly as well as on changes to the lint tools.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia8024c6ab0c91fd9f630f37dc802ed3bc6b4608c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Comparing the APOB in RAM to flash takes a significant amount of time
(~11ms). Instead of comparing the entire APOB, use a fast hash function
and compare just that. Reading, hashing, and comparing the hash take
~70 microseconds.
BUG=b:193557430
TEST=compile and boot to OS in chausie with and without this option set
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I241968b115aaf41af63445410660bdd5199ceaba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67301
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
coreboot unit-tests framework requires tests to use
cb_run_group_tests() instead of cmocka_run_group_tests() for Jenkins
to work correctly. Wrapper ensures that each test has its own report
file and does not overwrite results of other tests.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Iead63cab0465f37b2da0c7b3ef256057e3a191a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67371
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This updates the SPD utility and generated SPDs for LP5X to use memory
type code 0x15 (LPDDR5X) instead of 0x13 (LPDDR5). This is done based on
Intel Tech Advisory Doc ID #616599 dated May 2022, page 15.
SPDs were regenerated with:
"util/spd_tools/bin/spd_gen spd/lp5/memory_parts.json lp5"
This only affects the SPDs for 2 memory parts for Intel SoCs and the
only board referencing these is rex.
BUG=b:242765117
TEST=inspected SPD hex dump
Change-Id: Iadb4688f1cb4265dab1dc7c242f0c301d5498b83
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67265
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
dptc_enable is being treated as a bool, so convert to explicitly be a
bool.
BRANCH=none
BUG=b:217911928
TEST=Build zork
TEST=Build guybrush
TEST=Build skyrim
Change-Id: I0e93d892b3b8016221812c8b9ec6c257dcf13ef5
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67188
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Due to layout restrictions on mc_ehl2, the SD-card interface is limited
to operate in DDR50 mode. The alternative modes SDR104 and SDR50 are not
supported. Limit the capabilities in the SD card controller to DDR50
mode only so that the SD card driver in OS will choose the right mode
for operation even if the attached SD card supports higher modes.
Change-Id: Idc7f1466ec71f4218f6b957cadeeffadd069eb2d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Since the latest redesign a new RTC was introduced on mc_ehl2. Instead
of the old RX6110SA the new Micro Crystal RTC RV3028 is used now. Since
the address of this new RTC conflicts with an EEPROM on I2C bus 2, the
new RTC was moved to I2C bus 1.
As the mainboard is not finished yet, there are no incompatibility
issues with this change. Every new mainboard will have the new RTC and
the older mainboards are not delivered yet.
Change-Id: I3dd00855b8c9b22bdea21d3c8563cdb392868751
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This patch adds a driver for a new RTC from Micro Crystal. Supported
features are:
* configure backup voltage switchover via devicetree
* configure backup capacitor charging mode via devicetree
* set date if a voltage drop on backup voltage was detected
to either a user definable (devicetree) or coreboot build date
Change-Id: I37176ea726e50e4e74d409488981d7618ecff8bb
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Updating from commit id e0a6a512b:
2022-02-03 22:59:34 +0100 - (Merge changes from topic "msm8916" into integration)
to commit id 7805999e6:
2022-09-05 16:42:34 +0200 - (Merge changes from topic "st-nand-updates" into integration)
This brings in 1030 new commits.
Change-Id: I981956fbdcbcfa4ce185652478b9bb30d40f5686
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Some of the pll settings are incorrect, which cause problems in GPU
after booting into kernel.
- MFGPLL opp_ck_en bit isn't located at MFGPLL_CON1, so we need to fix
it to enable MFGPLL properly.
- Switch SPMI clock muxes to 260M to avoid kernel hang while probing
SPMI kernel driver.
TEST=GPU bringup correctly.
BUG=b:233720142
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Change-Id: I971109a5f72e3307899daaf5a5f26022124b559b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67355
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
The header file `compiler.h` is automatically included in the build by
the top level makefile using the command:
`-include $(src)/commonlib/bsd/include/commonlib/bsd/compiler.h`.
Similar to `config.h`, 'kconfig.h`, and 'rules.h`, this file does not
need to be included manually, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5d3eb3f5e5f940910b2d45e0a2ae508e5ce91609
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The header file `rules.h` is automatically included in the build by the
top level makefile using the command:
`-include src/soc/intel/common/block/scs/early_mmc.c`.
Similar to `config.h` and 'kconfig.h`, this file does not need to be
included manually, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I23a1876b4b671d8565cf9b391d3babf800c074db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67348
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Without these, all SuperSpeed ports are wired to EHCI #2.
"superspeed_capable_ports" and "xhci_switchable_ports" should fit both
CMT and SFF variants, while "xhci_overcurrent_mapping" should be
consistent with the first 4 elements of mainboard_usb_ports[].
With this commit, SuperSpeed devices plugged in SuperSpeed ports are
wired to the XHCI on my own Z220 SFF.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: Ifddecfd1d32ed6ab84d7eed8dc2d85d83cbebbcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67089
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, if for some reason, the file-size command is called on an
empty string, the build will hang waiting for stdin input to cat.
Since wc accepts a file, this cat was unnecessary anyway. Put the file
name in quotes so an empty string will result in calling wc on an
actual null file instead of just leaving the filename blank. This
results in an error, and will probably halt the build.
BUG=214790407
TEST=Build default build.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I3dacf1968ed897a8ebd00f95583c2f254a7fb55a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This patch fixes a hidden issue present inside FSP-S while coreboot
decides to skip performing MP initialization by overriding FSP-S UPDs
as below:
1. CpuMpPpi ------> Passing `NULL` as coreboot assume FSP don't need
to use coreboot wrapper for performing any
operation over APs.
2. SkipMpInit -----> Set `1` to let FSP know that coreboot decided
to skip FSP running CPU feature programming.
Unfortunately, the assumption of coreboot is not aligned with FSP when
it comes to the behaviour of `CpuMpPpi` UPD. FSP assumes ownership of
the APs (Application Processors) upon passing `NULL` pointer to the
`CpuMpPpi` FSP-S UPD.
FSP-S creates its own infrastructure code after seeing the CpuMpPpi
UPD is set to `NULL`. FSP requires the CpuMpPei module, file name `UefiCpuPkg/CpuMpPei/CpuMpPei.c`, function name `InitializeCpuMpWorker`
to perform those additional initialization which is not relevant for
the coreboot upon selecting the SkipMpInit UPD to 1 (a.k.a avoid
running CPU feature programming on APs).
Additionally, FSP-S binary size has increased by ~30KB (irrespective of
being compressed) with the inclusion of the CpuMpPei module, which is
eventually not meaningful for coreboot.
Hence, this patch selects `MP_SERVICES_PPI_V2_NOOP` config
unconditionally to ensure pass a valid pointer to the `CpuMpPpi` UPD
and avoid APs getting hijacked by FSP while coreboot decides to set
SkipMpInit UPD.
Ideally, FSP should have avoided all AP related operations when
coreboot requested FSP to skip MP init by overriding required UPDs.
TEST=Able to drop CpuMpPei Module from FSP and boot to Chrome OS on
Google/Redrix, Kano, Taeko devices with SkipMpInit=1.
Without this patch:
Here is the CPU AP logs coming from the EDK2 (open-source)
[UefiCpuPkg/CpuMpPei/CpuMpPei.c] when coreboot sets `NULL` to the
CpuMpPpi UPD.
[SPEW ] Loading PEIM EDADEB9D-DDBA-48BD-9D22-C1C169C8C5C6
[SPEW ] Loading PEIM at 0x00076F9A000 EntryPoint=0x00076FA24E2
CpuMpPei.efi PROGRESS CODE: V03020002 I0
[SPEW ] Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
[SPEW ] Notify: PPI Guid: F894643D-C449-42D1-8EA8-85BDD8C65BDE,
Peim notify entry point: 76FA0239
AP Loop Mode is 2
GetMicrocodePatchInfoFromHob: Microcode patch cache HOB is not found.
CPU[0000]: Microcode revision = 00000000, expected = 00000000
[SPEW ] Register PPI Notify: 8F9D4825-797D-48FC-8471-845025792EF6
Does not find any stored CPU BIST information from PPI!
APICID - 0x00000000, BIST - 0x00000000
[SPEW ] Install PPI: 9E9F374B-8F16-4230-9824-5846EE766A97
[SPEW ] Install PPI: 5CB9CB3D-31A4-480C-9498-29D269BACFBA
[SPEW ] Install PPI: EE16160A-E8BE-47A6-820A-C6900DB0250A
PROGRESS CODE: V03020003 I0
With this patch:
No instance of `CpuMpPei` has been found in the AP UART log with FSP
debug enabled.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8ebe0bcfda513e79e791df7ab54b357aa23d295c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66706
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In order to fix the USB port of type-C dongle has no function after
reboot/shutdown, modify ufp which is in google_chromeec_usb_pd_get_info
from the bit1 of type-c role (PD_CTRL_RESP_ROLE_DATA).
BUG=b:239138412
TEST=Built coreboot image and verified that using this patch can detect
usb drive after reboot.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: I73a4a6ec37129388783599125f067068d155d93f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67168
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
index I/O argument to getopt_long is not the index to argv. Instead it
is an index into the optlong array corresponding to the parsed option.
Also getopt() uses a global variable optind to track the index of the
next argument to be processed. Use the optindex variable as an index to
extract the filename from argv.
BUG=None
TEST=Build and use amdfwread to read the Soft-fuse bits from Guybrush
BIOS image. Observed no changes before and after the changes.
Change-Id: I33c74a0c8e12c5af76954524cf7294b7541d286b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66553
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds source file dependencies to utilities so that they are rebuilt
when the source is changed. Previously, binaries were only built if they
did not already exist and never rebuilt to reflect source file changes.
BUG=none
TEST=verified binaries are rebuilt when source files are touched.
Change-Id: I4775fe0e00e0f5d4f8b4b47331d836aba53c0e69
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
We currently have two competing mechanisms to limit the placement of
resources:
1. the explicit `.limit` field of a resource, and
2. the IORESOURCE_ABOVE_4G flag.
This makes the resource allocator unnecessarily complex. Ideally, we
would always reduce the `.limit` field if we want to "pin" a specific
resource below 4G. However, as that's not done across the tree yet,
we will use the _absence_ of the IORESOURCE_ABOVE_4G flag as a hint
to implicitly lower the `limit` of a resource. In this patch, this
is done inside the effective_limit() function that hides the flag
from the rest of the allocator.
To automatically place resources above 4G if their limit allows it,
we have to allocate from top down. Hence, we disable the prompt for
RESOURCE_ALLOCATION_TOP_DOWN if resources above 4G are requested.
One implication of the changes is that we act differently when a
cold-plugged device reports a prefetchable resource with 32-bit
limit. Before this change, we would fail to allocate the resource.
After this change, it forces everything on the same root port below
the 4G line.
A possible solution to get completely rid of the IORESOURCE_ABOVE_4G
flag would be rules to place resources of certain devices below 4G.
For instance, the primary VGA device and storage and HID devices
could be made available to a payload that can only address 32 bits.
For now, effective_limit() provides us enough abstraction as if the
`limit` would be the only variable to consider. With this, we get
rid of all the special handling of above 4G resources during phase 2
of the allocator. Which saves us about 20% of the code :D
Change-Id: I4c7fcd1f5146f6cc287bd3aa5582da55bc5d6955
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65413
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `IORESOURCE_ABOVE_4G` flag was only explicitly set for our dummy
device that reserves resources behind a hotplug port. The current re-
source allocator implicitly extends this to all devices below the port,
including real ones. Let's make that explicit, so future changes to the
allocator can't break this rule.
Change-Id: Id4c90b60682cf5c8949cde25362d286625b3e953
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66719
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add option to resource allocator v4 that restores the top-down
allocation approach at the domain level.
This makes it easier to handle 64-bit resources natively. With
the top-down approach, resources that can be placed either above
or below 4G would be placed above, to save precious space below
the 4G boundary.
Change-Id: Iaf463d3e6b37d52e46761d8e210034fded58a8a4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41957
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
For TPM2, vb2api_secdata_firmware_create() is already called from
setup_firmware_space() from _factory_initialize_tpm(). Therefore move
the duplicate call from factory_initialize_tpm() to TPM1's
_factory_initialize_tpm().
Change-Id: I892df65c847e1aeeabef8a7578bec743b639a127
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The lint script just did very basic argument parsing and required the
sub-command and --junit argument to be in specific locations. I'm
adding additional commands, so the first step is to add true command
line parsing.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7118c29e6c5d785b35a7ae12cf5984c43ebc3ab9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67191
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel platforms have soft straps stored in the SI_DESC FMAP section
which can alter boot behavior and may open up a security risk if they
can be modified by an attacker. This patch adds the SI_DESC region to
the list of ranges covered by GSC verification (CONFIG_VBOOT_GSCVD).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0f1b297e207d3c6152bf99ec5a5b0983f01b2d0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66346
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CL:3825558 changes all vb2_digest and vb2_hash functions to take a new
hwcrypto_allowed argument, to potentially let them try to call the
vb2ex_hwcrypto API for hash calculation. This change will open hardware
crypto acceleration up to all hash calculations in coreboot (most
notably CBFS verification). As part of this change, the
vb2_digest_buffer() function has been removed, so replace existing
instances in coreboot with the newer vb2_hash_calculate() API.
Due to the circular dependency of these changes with vboot, this patch
also needs to update the vboot submodule:
Updating from commit id 18cb85b5:
2load_kernel.c: Expose load kernel as vb2_api
to commit id b827ddb9:
tests: Ensure auxfw sync runs after EC sync
This brings in 15 new commits.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I287d8dac3c49ad7ea3e18a015874ce8d610ec67e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
elog_gsmi_cb_mainboard_log_wake_source is called from SMI and causes
eSPI transactions. If the SMI interrupts an ongoing eSPI transaction
from the OS it will conflict and cause failures. Removing this call to
avoid conflicts. This can be re-enabled after refactoring
google_chromeec_get_mask to use ACPI MMIO.
This is a copy of CB:63280 but for skyrim.
BUG=b:227163985, b:243557044
TEST=suspend/resume skyrim and no longer see EC wake sources in elog.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iac56840fe15101bc556d8cce9960f761c6ea7181
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Enabling Bus Master isn't required by the hardware, so we shouldn't
need to enable it at all. However, some payloads do not set this bit
before attempting DMA transfers, which results in functionality
failure. For example: in this case, unable to see the developer screen
in Depthcharge.
In the prior IA SoC platform, FSP/GFX PEIM does the BM enabling for
the IGD BAR resources but starting with the MTL platform, it fails
to do so resulting into inability to see the Pre-OS display.
BUG=b:243919230 ([Rex] Unable to see Pre-OS display although GFX
PEIM Display Init is successful during AP boot)
TEST=Able to see the developer screen with eDP/HDMI while booting
the Google/Rex.
Also, this change doesn't impact the previous platforms
(ADL, TGL, CML etc.) where the BM is default enabled.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I9ad9eee8379b7ea1e50224e3fabb347e5f14c25b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
As part of investigating b/240690391 I noticed that we were missing
the daughter board ports. Not all SKUs have these ports connected,
but it doesn't hurt to have the extra ACPI nodes.
BUG=none
TEST=build
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Id6fc34acbfa30bc15e697043bf93bcf584256128
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
A new ChromeOS automated test will be introduced to check the cbmem log
of diagnostic boot mode. Because the diagnostic boot does not allow
booting into kernel, the test must perform AP reset and then check the
cbmem log afterwards. However, the memory content might not be written
back to memory (from CPU cache) during AP reset because of the cache
snooping mechanism on x86. Hence, some API to flush cache is needed.
Implement dcache_* to allow flushing cache proactively in x86. To avoid
unnecessary flush, check dma_coherent before calling dcache_* functions,
which will be always true in x86. Therefore, this change won't affect
the original functionality.
BUG=b:190026346
TEST=FW_NAME=primus emerge-brya libpayload
Cq-Depend: chromium:3841252
Signed-off-by: Hsin-Te Yuan <yuanhsinte@google.com>
Change-Id: I622d8b1cc652cbe477954a900885d12e6494d94d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add the headers for 2.2.3.1, which includes the following changes
over 2.2.0.0:
• [Implemented]GLK: XHCLKGTEN Register setting causes S0ix entry
failure in less than 5 cycles when a USB2 Ethernet Dongle is
connected. Refer GLK BIOS Spec Volume1 CDI# 571118 under chapter
7.20.6 for new Register settings.
• [Implemented] [GLK/GLK-R] DDR4 16Gb SDP Memory support for Gemini
Lake/Gemini Lake – R
• [Update] MRC new version update to 1.38.
• [Fixed][GLK-R][WLAN] Removed the DSW function - Wake on LAN from
S4 issue with latest Wifi driver.
[Update] MRC new version update to 1.39. Included fix for
MinRefRate2xEnable and support for Rowhammer mitigation.
• [Fixed] Disable Dynamic DiffAmp and set CTLE from 7 to 5. This
change specific to DDR4 memory configuration.
• GLK Klocwork Fix
• [Update] MRC new version update to 1.40.
Added in a separate directory as the default. The 2.2.0.0 headers
were left and will be used for Google boards, as some offsets have
moved.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I09498368b116c2add816eeada2fa4d0dba6e5765
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Whilst UefiPayloadPkg is always built with support for 32-bit
and 64-bit, this is not the case for all edk2 targets. Move this
to the build command so they can be specified on each target.
Also add the `-s` switch, which stands for quiet to suppress edk2
printing War and Peace whilst building.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: If94abd4e28917718c76ad5945966e7be668c8f61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66364
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Compile-time support of DPTC is controlled by
EC_ENABLE_AMD_DPTC_SUPPORT in each variant's ec.h file. This CL removes
EC_ENABLE_AMD_DPTC_SUPPORT and replaces it with the Kconfig value
SOC_AMD_COMMON_BLOCK_ACPI_DPTC.
Each variant's run-time support of DPTC continues to be controlled by
the variant's overridetree.cb "dptc_enable" value.
BRANCH=none
BUG=b:217911928
TEST=Build zork
TEST=Boot skyrim
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Ic101e74bab88e20be0cb5aaf66e4349baa1432e3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add support for loading SPM firmware from CBFS to SPM SRAM. SPM needs
its own firmware to enable SPM suspend/resume function which turns off
several resources such as DRAM/mainpll/26M clk when linux system
suspend.
SPM is an essential component on MediaTek SoC, so we initialize PPM
in soc_init(). For MT8188, SPM will handshake with DPM to do
initialization, so we need to call spm_init() after dpm_init().
This SPM flow adds 33ms to the boot time.
firmware log:
mtk_init_mcu: Loaded (and reset) spm_firmware.bin in 25 msecs
SPM: spm_init done in 33 msecs, spm pc = 0x400
TEST=spm pc is 0x400 which is in idle state.
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I1a1f49383e0ceadc259a18272fc1c277b65406ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The unit of current_clk in pmif_ulposc_check() should be MHz. We use
pmif_get_ulposc_freq_mhz() to get the default hardware value in MHz.
Without this modification, the judgement in pmif_ulposc_check() is
alway wrong due to the wrong unit.
TEST=build pass.
BUG=b:233720142
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I3bf80a23bb35ff657023eb4b7e009fa233f61244
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add basic DEVAPC (device access permission control) driver.
DEVAPC driver is used to set up bus fabric security and data protection
among hardwares. DEVAPC driver groups the master hardwares into
different domains and gives secure and non-secure property. The slave
hardware can configure different access permissions for different
domains via DEVAPC driver.
1. Initialize DEVAPC.
2. Set master domain and secure side band.
3. Set default permission.
TEST=check logs of DEVAPC ok.
BUG=b:236331724
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Change-Id: Iad3569bc6f8ba032d478934ba839dc4b5387bafc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add initialization of DPM drvier for DRAM low power mode.
DPM is an essential component on MediaTek SoC, so we initialize DPM
in soc_init().
This DPM flow adds 22ms to the boot time.
coreboot logs:
CBFS: Found 'dpm.dm' @0x156c0 size 0xfc in mcache @0xfffdd110
mtk_init_mcu: Loaded (and reset) dpm.dm in 6 msecs (422 bytes)
CBFS: Found 'dpm.pm' @0x15800 size 0x3c59 in mcache @0xfffdd140
mtk_init_mcu: Loaded (and reset) dpm.pm in 16 msecs (18910 bytes)
TEST=build pass
BUG=b:236331724
Signed-off-by: Xi Chen <xixi.chen@mediatek.corp-partner.google.com>
Change-Id: I46baa7b49e90d53dd4d1d95af9c46622faf30419
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66969
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The headers added are generated as per FSP v3301.03
In the future, when Alder Lake and Raptor Lake fsp align, Raptor Lake
fsp headers can be deleted and Raptor Lake soc will also use headers
from alderlake/ folder.
BUG=b:243693364
BRANCH=firmware-brya-14505.B
TEST=Boot to OS
Signed-off-by: Selma Bensaid <selma.bensaid@intel.com>
Change-Id: Idbd39ed53d4ba05248a0e83c104846960253931e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
CB:66978 introduced an incorrect condition to check for the presence of
SPD binaries to be injected into APCB_SBR_D5.gen. This caused the SPDs
to be not injected into the APCB and hence the system fails to boot. Fix
it by updating the path of the SPD binaries correctly.
BUG=b:244173966
TEST=Build and boot to OS in Skyrim.
Change-Id: I5efa634fafdcc4769dfad5f533d5512e7c03644f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Set bluetooth enable_delay_ms to 200ms. 200ms is the lowest common
denominator between the two BT chipsets.
BUG=b:233369179,b:236289478
BRANCH=guybrush
TEST=Connect to headset, suspend and reboot, headset still functions
Change-Id: Id4c23de37351d28d02aaa797fa19ff49e9dfa76c
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65180
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
The current subsystem ID used by the amps may end up getting used
again for future products, therefore this CL updates the subsystem
ID to 103C8C08, which was specifically generated for this amp.
BUG=b:202484541
BRANCH=brya
TEST='FW_NAME=vell emerge-brya coreboot'
Change-Id: I399d8d99ead4fb6fdfa24c2a7a3e3d5e63603b8b
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The CPPC table value for UEFI BIOS has been changed. The code has been
merged to AGESA. We can get the value by dumping ACPI table. Then we
align the coreboot code with the new value.
BUG=b:190420984
Change-Id: I091ab3bbc5f94961f8b366a3fa00f50f5c9fa182
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Commit 0e7cf3d81d (soc/intel/alderlake:
Fix DDR5 channel mapping) fixed a bug in SoC code that messed up DDR5
SPD address mapping. Atlas uses the 0x50/0x52 addresses. However, the
SoC code bug required commit 044883615d
(mb/prodrive/atlas: Update correct SPD address) so that at least some
RAM would work. Now that the SoC code bug is fixed, the workaround is
no longer needed, so use the correct SPD address mapping.
TEST=Boot Atlas and verify that both memory channels work
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I352d8f36eec63cffd3f63ab6e7421db16ca30163
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Building futility with OpenSSL 3.0 (default in latest Debian sid)
results in a number of warnings that various declarations have been
deprecated. Since we (and futility) have warnings as errors enabled,
this causes the building of futility to fail, killing the entire
coreboot build.
To work around this until futility is updated, turn off the warnings
about deprecated declarations.
Bug 243994708 has been filed to get futility updated. This workaround
can be removed when futility builds cleanly with the latest libsssl-dev.
BUG=b:243994708
TEST=Futility build doesn't fail with libssl-dev > 3.0
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I54e27e09b0d50530709864672afe35c59c76f06e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tom Hiller <thrilleratplay@gmail.com>
The size of the input parameter to RESET_SYSTEM svc call is expected to
be 4 bytes. Fix the reset_system type from enum to uint32_t.
BUG=b:243476183
TEST=Build and boot to OS in Skyrim with PSP verstage. Trigger a system
reset to ensure that the system is reset successfully.
Change-Id: I6319a1dfc89602722c1c2b1c4ee744493ae8b33f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67117
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If we have a PCIe root port without `ops_pci` or without
`get_ltr_max_latencies`, the parent device wouldn't be PCI.
Hence, check for a PCI path early.
Change-Id: I358cb6756750bb10d0a23ab7133b917bfa25988b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This workaround was added since reading the firmware version on Ti50
versions < 0.0.15 will cause the Ti50 to become unresponsive. No one is
using Ti50 this old anymore, so remove the workaround.
BUG=b:224650720,b:236911319
TEST=Boot to OS on nivviks with Ti50 0.22.4. Check the log contains the
firmware version:
[INFO ] Firmware version: Ti50/D3C1 RO_B:0.0.26/- RW_B:0.22.4/ti50_common:v095c
Change-Id: I3628b799e436a80d0512dabd356c4b2566ed600a
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67138
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The qemu package doesn't exist anymore or it was renamed. Instead of
installing QEMU for all available architectures, install only the
packages which ship architectures that are supported by coreboot.
* qemu-system-arm
* qemu-system-misc (for RISC-V)
* qemu-system-ppc
* qemu-system-x86
Change-Id: Ifc46a8c9fcb1ab3c38dc8cbbc906882e93a719d7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tom Hiller <thrilleratplay@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When MRC_SAVE_HASH_IN_TPM is selected, mrc_data_valid() uses the TPM
hash to verify the MRC cache data, not the checksum. However, we still
calculate the checksum when updating the cache. Skip this calculation
when MRC_SAVE_HASH_IN_TPM is selected to save boot time.
On nissa, this reduces boot time by ~14 ms:
Before:
3:after RAM initialization 854,298 (28,226)
After:
3:after RAM initialization 849,626 (14,463)
Note, the reason the calculation is so slow is that the new MRC data
lives in CBMEM, which is not yet marked as cacheable in romstage.
BUG=b:242667207
TEST=MRC caching still works as expected on nivviks. After clearing
the MRC cache, memory training happens on the next boot, but doesn't on
subsequent boots.
Change-Id: Ifbb75ecfa17421c0565aec1f3eb48d950244f821
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Define fields of sdram_params and enable MEDIATEK_BLOB_FAST_INIT to
run fast calibration for MT8188 using blob.
DRAM fast calibration logs:
DRAM-K: Fast calibration passed in 19530 msecs
dram size (romstage): 0x200000000
TEST=Fast calibration pass.
BUG=b:233720142
Signed-off-by: Xi Chen <xixi.chen@mediatek.com>
Change-Id: I2468d971fe861cbd09cc86c8a5a1fb531bfe78d7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
- Use common SoC drivers for DRAM calibration support.
- Remove emi.h because sdram_size() is already declared in
common/include/soc/emi.h.
- Add dramc_param.h and dramc_soc.h to prepare for implementation of
DRAM full calibration.
TEST=build pass
BUG=b:233720142
Signed-off-by: Xi Chen <xixi.chen@mediatek.com>
Change-Id: I2f88d971fe861cbd09cc86c8a5a1fb531bfe78d7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch disables LID based shutdown requests.
Google/Rex platform receives a forced shutdown request while
booting to depthcharge due to EC wrongly detecting the LID is being
closed.
For now disable the LID based shutdown behaviour in depthcharge unless
the EC issue gets resolved.
BUG=b:243920003
TEST=Depthcharge no longer sees the force shutdown request now.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I03e33ea4d04dc48331d1cf98c47786b2a184c258
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
If an inserted region's base wasn't aligned, the resulting range should
still cover the original end (original region's base + size) and not the
aligned-down base + size.
Change-Id: I8f1c9456d6dbab4fa868de5c93fa3656397e54c1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66607
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PNOT() should be called when the battery status changes, to give the SOC
an opportunity to handle it. This is in preparation for the low/no
battery boot changes.
This CL also updates the PNOT() comments to better match the name of the
function and why it's called.
BRANCH=none
BUG=b:217911928
TEST=Boot skyrim
Change-Id: I8b74313d242fd4959315a67579eb6c5f49a31a76
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66993
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Clear the SMBIOS region before writing SMBIOS tables.
On librem_mini and librem_mini_v2, CBMEM allocations are offset by 4K
for reboots relative to the cold boot. This means the unused SMBIOS
region could contain the first 4K of the ACPI tables from the last boot
(including the signature), which prevents Linux from booting.
The CBMEM 4K offset appears to be due to FSP allocating memory
differently between cold boot and reboot, this appears to be normal and
causes the CBMEM base address to change.
It is not clear why Linux examines an ACPI signature found in this
region, but boot logs over serial confirm that it sees the corrupt
table. The table is supposed to be found just below 1M, and kernel
source appears to look in this region, but it is definitely finding the
corrupt table in CBMEM.
Normal cold boot:
[ 0.008615] ACPI: RSDP 0x00000000000F6190 000024 (v02 COREv4)
[ 0.008619] ACPI: XSDT 0x0000000099B480E0 00005C (v01 COREv4 COREBOOT 00000000 CORE 20220331)
[ 0.008624] ACPI: FACP 0x0000000099B4A2A0 000114 (v06 COREv4 COREBOOT 00000000 CORE 20220331)
[ 0.008634] ACPI: DSDT 0x0000000099B48280 00201F (v02 COREv4 COREBOOT 20110725 INTL 20220331)
...
Reboot with corrupt table:
[ 0.008820] ACPI: RSDP 0x00000000000F6190 000024 (v02 COREv4)
[ 0.008823] ACPI: XSDT 0x0000000099B480E0 00005C (v01 COREv4 COREBOOT 00000000 CORE 20220331)
[ 0.008828] ACPI: ???G 0x0000000099B4A2A0 20002001 (v00 ?G?$ 47020100 ?, 47020100)
[ 0.008831] ACPI: �y 0x0000000099B4A3C0 54523882 (v67 ?_HID? A�? 65520D4E al T 20656D69)
...
There are no specific errors but it returns to the firmware soon after,
presumably due to a fault. This appears to be so early in the boot
that panic=0 on the kernel command line has no effect.
Test: build/boot Librem Mini, Librem Mini v2 and reboot.
Change-Id: Ia20d0b30160e89e8d96add34d7e0e881f070ec61
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66377
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, memranges_steal() steals at the lowest possible address.
This is actually reflected by the test code that checks if the *base*
of the READONLY_TAG range changes. Furthermore, the test ends with the
memranges restored, so revise the comment on the final state.
Change-Id: Idef71ce464280c6805145f229de9e8913ba850bc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66606
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Follow the "619907 Alder Lake-S and Raptor Lake-S Platform" and "685472 Intel® Dynamic Tuning Technology (Intel® DTT)" to override tdp pl1 in 15w cpu MSR to 55w and in 28w cpu MSR to 64w.
BUG=b:236294162
TEST=emerge-brask coreboot and check MSR_Package Power Limit-1 in 15w and 28w CPU is correct.
Signed-off-by: Raihow Shi <raihow_shi@wistron.corp-partner.google.com>
Change-Id: Icb3d7c72b672fbd3e2a9f7ad1f2d1cb2ffc798c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66910
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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.
Signed-off-by: John Zhao <john.zhao@intel.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8dcee90080c6e70dadc011cc1dbef3659fdbc8f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66951
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors p2sb_execute_sideband_access() to be able to
handle SBI operations in both SMM and non-SMM scenarios.
Prior to FSP-S operation being done, the IOE P2SB device will be
visible on the PCI bus hence, performing the SBI operation using IOE
P2SB doesn't involve unhide/hide operation.
Post FSP-S, the IOE P2SB device is hidden.
Additionally, SBI operations can't be performed as is. The only
possible way to send SBI is inside SMM mode and to do that, coreboot
needs to unhide the P2SB device prior to sending the SBI and hide
it post sending SBI.
As a result, the p2sb_execute_sideband_access() function has been
refactored to manage these cases seamlessly without users of the
p2sb_execute_sideband_access() actually being bothered about the
calling mode.
BUG=b:239806774
TEST=Able to perform p2sb_execute_sideband_access() function call in
both SMM and non-SMM mode without any hang/die.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iafebd5190deb50fd95382f17bf0248fcbfb23cb8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Only 16 MByte of the SPI flash can be mapped right below the 4 GB
boundary.
In case of a larger SPI flash size, still only the 16 MByte region
starting at 0xff000000 can be configured as WRPROT and be reserved for
the MMIO mapped SPI flash region. The next 16 MByte MMIO region starting
at address 0xfe000000 contain for example the LAPIC MMIO region, the
ACPIMMIO region and the UART/I2C controller MMIO regions which shouldn't
be configured as WRPROT. Reserving this region for the MMIO mapped SPI
flash would also result in an overlap with the MMIO resources mentioned
above.
In the case of a smaller SPI flash, reserving the full 16 MByte flash
MMIO region makes sure that the resource allocator won't try to put
anything else in the lower parts of the 16 MByte SPI mapping region.
To avoid the issues described above, always reserve/cache the maximum
amount of 16 MBytes of flash that can be mapped below 4 GB.
TEST=On boards with 16 MByte SPI flash chips, the resulting image of a
timeless build doesn't change with this patch. Verified this on Chausie
(Mendocino), Majolica (Cezanne), Cereme (Picasso) and Google/Careena
(Stoneyridge). On Mandolin (Picasso) with an 8 MByte flash, the
resulting image of a timeless build is different, but neither the
coreboot console output nor the Linux dmesg output shows any errors that
might be related to this change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie12bd48e48e267a84dc494f67e8e0c7a4a01a320
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66700
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Because the poweron state of some of the WWAN GPIOs is the
asserted state, this patch fixes the poweron sequence so that the
WWAN module is always correctly powered on, in both cold and warm
reboot scenarios.
BUG=b:233564770
TEST=USE="project_crota emerge-brya coreboot" and verify it builds
without error.
Signed-off-by: Terry Chen <terry_chen@wistron.corp-partner.google.com>
Change-Id: I4ec8312c30392b9ca0a3e0321cb4578e76ec5787
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This commit adds support for LP5X SPDs. The SPD format is identical to
LP5 except that the memory type is set to 0x15 instead of 0x13. Since
they are essentially the same, LP5/5X parts share the same parts JSON
file and SPD directory. LP5X parts are distinguished by the optional
`lp5x` attribute. This commit also updates two existing LP5X memory
parts with the correct attribute.
BUG=b:242765117
TEST=Generated SPDs, verified that SPDs generated from LP5X parts match
their LP5 counterparts except for memory type byte.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I67df22bc3fd8ea45fe4dad16b8579351eb4d0d8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Create the morthal variant of the skyrim reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:240970782
BRANCH=None
TEST=util/abuild/abuild -p none -t google/skyrim -x -a
make sure the build includes GOOGLE_MORTHAL
Signed-off-by: Moises <moisesgarcia@google.com>
Change-Id: I25c25f067a040e6930f4fc60fadb8be85dc8eda6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
The agah EC code will monitor adapter current to choose corresponding
DPTF oem variable table. When it changes, this event will send to the
ACPI FW through host event and then pass onto the DPTF kernel driver.
This patch adds support for that feature.
BUG=b:238921409
TEST=add Printf() calls to the ACPI,
and check these Printf() will show up in the kernel log
when EC send oem variable table change notify.
Change-Id: I1dbbfd9b3d65b56d77050c9ba9957e54530c3a0e
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66574
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current edk2 makefile will work in a directory that's name is
derived from the repository, such as `mrchromebox` or `starlabsltd`.
Move this under a directory, so that it can be ignored by git and
so that the makefile can be adjusted to use file targets, rather
than phony recipes with wildcards.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: If0c80dbc59130f229b78cab9578115e14172301d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66356
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements EFI_PEI_MP_SERVICES_PPI structure definitions
with APIs that return mp_api_unsupported().
The reason behind this change is to fix an FSP issue where FSP assumes
ownership of the APs (Application Processors) upon passing a `NULL`
pointer to the CpuMpPpi FSP-S UPD.Hence, this patch implements
`MP_SERVICES_PPI_DEFAULT` config to fill EFI_PEI_MP_SERVICES_PPI with
`mp_api_unsupported` APIs.
Later this data structure can be passed to the CpuMpPpi UPD to avoid
APs from getting hijacked by FSP while coreboot decides to set
SkipMpInit UPD.
TEST=Able to build and boot Google/Taeko with this patch.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I31fcaa2aa633071b6d6bfa05dbe891ef87978d2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
BIOS must send the IP_LOAD HECI command to fetch the firmware for CPU
PCIe Gen5 and upload it via CPU REG BAR prior FSP Silicon Init.
Implementation based on public Slimbootloader's
"Silicon/AlderlakePkg/Library/CpuPcieHsPhyInitLib".
TEST=Boot MSI PRO Z690-A and see the HSPHY FW is loaded.
PCIe x16 Gen3 GPU card started working in the PCIE 5.0 slot.
[DEBUG] HECI: Sending Get IP firmware command
[DEBUG] HECI: Get IP firmware success. Response:
[DEBUG] Payload size = 0x6944
[DEBUG] Hash type used for signing payload = 0x3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I6c6c11581e3d3d9bab0131fae6ef487cafe98080
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Intel GPIO pad supports 4 bits pad mode, PAD_CFG_DW0[13:10] for pins
that native function 8 to 15 is assigned. This adds native function
definitions from NF8 to NF15 and updates PAD_CFG0_MODE_MASK to support
4 bits pad mode configuration.
Since PAD_CFG_DW0[16:13] is reserved for pins that NF8 or higher is not
assigned, this change would not cause an issue but Kconfig option is
added to minimize an impact and support 4 bits pad mode configuration.
BUG=b:239690757
TEST=build and verify pad mode configuration with Meteor Lake mtlrvp
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Change-Id: Iefd2daa92a86402f2154de2a013ea30f95d98108
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
fix the following checkpatch errors:
WARNING:BRACES: braces {} are not necessary for any arm of this statement
354: FILE: src/arch/x86/smbios.c:354:
+ if (CONFIG_ROM_SIZE >= 1 * GiB) {
[...]
+ } else {
[...]
WARNING:BRACES: braces {} are not necessary for single statement blocks
561: FILE: src/arch/x86/smbios.c:561:
+ if (leaf_b_threads == 0) {
+ leaf_b_threads = 1;
+ }
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: I14c29e4358cad4cd5ef169ebab7079db2129d8fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Commit 6dac0c54cd makes the linter checking for license headers on all
files from the src directory. Since this TAGS file doesn't have one,
it's causing a linter error and it makes the QA system complain.
However, the TAGS file doesn't need a license header and thus add it to
the exception list.
Usually the build tests detect such issues, but commit 1d7a9debf2,
which introduced that file, was merged independently from the other
commit, which modifies the linter. Also, the patch that is introducing
this file was based on an older commit at which the patch modifying the
linter wasn't merged yet and so this issue was hidden.
Change-Id: I78da3fa70c39b709478a384da8769fc058ca18ce
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66938
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements API to program TME core activation MSR 0x9FF.
Write zero to TME core activate MSR will translate the
TME_ACTIVATE[MK_TME_KEYID_BITS] value into PMH mask register.
Note: TME_ACTIVATE[MK_TME_KEYID_BITS] = MSR 0x982 Bits[32-35]
TEST=Able to build and boot Google/Redrix.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I48cf8e255b294828ac683ab96eb61ad86578e852
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66752
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Firmware is typically delivered as one large binary image that gets
flashed. Since this final image consists of binaries and data from
a vast number of different people and companies, it's hard to
determine what all the small parts included in it are. The goal of
the software bill of materials (SBOM) is to take a firmware image
and make it easy to find out what it consists of and where those
pieces came from. Basically, this answers the question, who supplied
the code that's running on my system right now? For example, buyers
of a system can use an SBOM to perform an automated vulnerability
check or license analysis, both of which can be used to evaluate
risk in a product. Furthermore, one can quickly check to see if the
firmware is subject to a new vulnerability included in one of the
software parts (with the specified version) of the firmware.
Further reference:
https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
- Add Makefile.inc to generate and build coswid tags
- Add templates for most payloads, coreboot, intel-microcode,
amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM,
intel ME and compiler (gcc,clang,other)
- Add Kconfig entries to optionally supply a path to CoSWID tags
instead of using the default CoSWID tags
- Add CBFS entry called SBOM to each build via Makefile.inc
- Add goswid utility tool to generate SBOM data
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This patch removes the static kconfig being used to fill in TME enable
FSP UPD. Instead use`is_tme_supported()` and `CONFIG(INTEL_TME)` to check
if the CPU has required TME support rather than hardcoding.
TEST=FSP debug log shows `TmeEnable` UPD is set appropriately for the
TME-supported CPU SKUs.
As per FSP-M debug log:
Without this CL, Alder Lake-P CPU SKU without TME support:
[SPEW ] TmeEnable = 0x1
With this CL, Alder Lake-P CPU SKU without TME support:
[SPEW ] TmeEnable = 0x0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8aa2922baaf2a49e6e2762d31eaffa7bdcd43b0a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66750
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reading firmware_version register is supported on Ti50 version
0.22.4. Therefore correct the help text of the Kconfig option
TI50_FIRMWARE_VERSION_NOT_SUPPORTED.
Also change the message level to BIOS_WARNING.
BUG=b:234533588
TEST=emerge-corsola coreboot
BRANCH=none
Change-Id: I66a0ef896c9dc4cd0f586555a55dbcd1cfd863f9
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66906
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andrey Pronin <apronin@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
As per the Alder Lake FAS coreboot shall detect the existence of TME
feature by running the CPUID instruction:
CPUID leaf 7/sub-leaf 0
Return Value in ECX [bit 13]=1
If TME is supported then only access to TME MSRs are allowed otherwise
accessing those MSRs would result in GP#.
TEST=Able to detect the existence of TME feature across different
Alder Lake and Meteor Lake CPU SKUs.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibd4fcf15a66d27748ac7fbb52b18d7264b901cd8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66749
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
The `INTEL_TME` Kconfig option has a prompt, which means it is meant to
be user-configurable. However, it has been selected from Alder Lake and
Meteor Lake Kconfig, so `INTEL_TME` cannot be disabled on them. Replace
the `select INTEL_TME` statements with default values in order for this
option to be user-configurable on all platforms that support it.
Change-Id: Ib37c108fcc1004840b82be18fd23c340a68ca748
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66756
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This reverts commit 2b19d547c0.
A power and performance analysis performed on Alder Lake demonstrated
that with an EPP (Energy Performance Preference) at 50% along with
EET (Energy Efficient Turbo) disabled, the overall SoC performance are
similar or better and the SoC uses less power.
For instance some browser benchmark results improved by 2% and some
multi-core tests by 4% while at the same time power consumption
lowered by approximately 7.6%.
BUG=b:240669428
TEST=verify that EPP is back to the by default 50% setting
`iotools rdmsr 0 0x774'
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I76d3914e51c5320af4c202558e1e7c57b7c0de54
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Baieswara Reddy Sagili <baieswara.reddy.sagili@intel.com>
Reviewed-by: Saurabh Mishra <mishra.saurabh@intel.com>
Reviewed-by: Usha P <usha.p@intel.com>
The current reset delay is not enough to make touchscreen IC ready,
ILITEK feedback their requiremt is 400ms in spec T2.
After changing the reset_delay_ms and check touchscreen works,
ILITE also change the IRO to low level trigger.
This CL is to reflect that.
BUG=b:235929123
BRANCH=firmware-dedede-13606.B
TEST=check touchscreen function work
Change-Id: I126b2d74c1d7a1799e2f67a8ab01cba074447c06
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Disable INTEL_LPSS_UART_FOR_CONSOLE to stop debug output on UART 2.
This decreases boot time on all boards by around 60%.
TGL before:
Total Time: 10,110,807
TGL after:
Total Time: 3,851,641
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I8f8d5cd46e87e7dafe0669b4a29c872b1789eb60
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The ALC269 does not support the hardware equaliser, so remove the
entries related to this, as they have no effect.
Revert to the ALC269 defaults which work correctly with Linux. This
also corrects the subsystem id from 0x10ec111e to 0x10ec10d0.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I82647f67730ec344591f7dbd759a421c116d4fdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66687
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The functionality of sb_enable_lpc is implemented in the common LPC
support code as lpc_enable_controller. This gets called by the common
lpc_early_init which also calls lpc_disable_decodes and lpc_set_spibase.
The lpc_set_spibase call was already done in bootblock_fch_early_init,
so the main change in code behavior is that now lpc_disable_decodes gets
called during early FCH initialization. The lpc_enable_port80 and
sb_lpc_decode calls after the lpc_early_init code will reenable some of
the decodes.
TEST=Successfully boots on google/liara, cbmem and dmesg logs look clean
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia58a6f609fa149a6c09ed99f08bdc4f05eb56f96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66841
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCI config space of the SMBus device has a secondary mapping as an
ACPIMMIO bank. Since the PCI device is on bus 0, it's already available
early in boot after the enable_pci_mmconf call, so there's no need to
use the ACPIMMIO mapping instead of the PCI config space mapping.
Verstage on PSP could theoretically access the PCI config space via the
0xcf8/0xcfc register pair, but since verstage on PSP doesn't have the
ACPIMMIO mapping anyway, we won't loose any functionality here.
Change-Id: I5c8ce8de0a6ab0ed41e7e8a5980d0f0510aaa993
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change is to skip sending the MBP HOB since coreboot doesn't
use it and also helps to reduce the boot time by ~40msec on ADL-N.
Boot time data:
Before:
* 955:returning from FspSiliconInit 956,832 (110,268)
After:
* 955:returning from FspSiliconInit 944,528 (74,213)
BUG=b:241850107
TEST=Verified that boot time is reduced by ~40msec and also S0i3
is working.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I05d226fb5f05463341358cd20655f06376778bac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
This change is to skip sending the MBP HOB since coreboot doesn't
use it and also helps to reduce the boot time by ~40msec on ADL-N
variants.
Boot time data:
Before:
* 955:returning from FspSiliconInit 1,231,364 (117,051)
After:
* 955:returning from FspSiliconInit 1,198,221 (79,497)
BUG=b:241850107
TEST=Verified that boot time is reduced by ~40msec and also S0i3
is working.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: Iaeaa8bcdf8467fdd467a10a98dd7582e8e0b067c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch adds the support to enable/disable skipping MBP HOB
from the devicetree based on mainboard requirement.
Only ADL-N FSP has the required support to skip the MBP HOB and
enabling it is saving the Boot time.
BUG=b:241850107
TEST=Build and boot to verify that the right value has been passed to
the FSP.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: Iddeb2c652fac9513b14139d6f732d333bbb989d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66441
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The infrastructure for selecting an appropriate firmware image to use
the right descriptor is now ready so runtime descriptor updates are no
longer necessary. Since the different descriptor builds split along
HDMI/USB-C lines for nereid, a single VBT file can be used for each,
removing the need for runtime VBT selection as well.
BUG=b:229022567
TEST=Nereid type-C and HDMI outputs work as expected
Signed-off-by: Sam McNally <sammc@chromium.org>
Change-Id: Idf1fbd6c26203adbda002dec3f11e54a7b9f9b82
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Debian 11 reports ´0:6:0 can´t derive routing for PCI INT D´.
Use FIXED_INT_PIRQ for INT D to PIRQ routing table.
BUG=NA
TEST=Boot Debian 11 on Siemens AS_TGL1 and verify no PIRQ error message
in ´dmesg´
Change-Id: If38c7b6f664e0f6533e583ce62504281a4092720
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
spm_set_power_control() is already called in spm_init(). It is not
necessary to call spm_set_power_control() again in the mtk_mcu reset
callback.
TEST=check SPM PC value (0x250) after SPM is loaded.
[INFO ] SPM: spm_init done in 54 msecs, spm pc = 0x250
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Change-Id: I7ee517e1eb6485c52155a69d05781a61ddfe4cad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66785
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is sort-of reverts commit cbf290c692 ("soc/amd/sabrina: drop
CPPC code"), since it turned out that the CPPC feature is supported
on Sabrina (now Mendocino) despite this being missing from the
documentation I looked at when writing the patch referenced above.
Since the CPPC ACPI code generation functionality has been moved to
common code, this isn't a direct revert.
BUG=b:237336330
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1c059653eeae207d723c77e8a78b19c86e362296
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This patch provides a mitigation path for having different size SPINOR
parts across Rex board revisions. Rex Proto 0 only has 64MB SPINOR
mounted on the board, and the plan is to use 32MB later with Proto 1
onwards.
Hence, the idea here is to maintain a 32MB SPI Flash layout across all
Rex board revisions, but the Proto 0 build only selects
BOARD_ROMSIZE_KB_65536 config for adding padding at the end of the
32MB range.
BUG=b:242825380
TEST=Able to create 64MB AP Firmware for Rex with below layout:
SI_ALL: 0-9MB
SI_BIOS: 9MB-32MB
Padding/Unused: 32MB-64MB
Additionally, able to hit CPU reset on MTLRVP (has 64MB SPINOR) with
Rex AP Firmware binary.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibcc2206456639ef4ff22e0c4069521e583be58cd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66828
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Currently, to enable/disable LTE based on fw_config on nissa, we have
two sets of GPIOs: lte_enable_pads and lte_disable_pads. This was to
prevent the SAR interrupt pin GPP_H19 from floating for the short period
of time between enabling it in gpio.c and disabling it in fw_config.c
(see CB:64270 for more details).
With the new pad-based GPIO overrides (CB:64712), this is no longer an
issue since the gpio.c and fw_config.c overrides are applied at the same
time. So simplify the LTE GPIO configuration by enabling all the LTE
pins in the variant gpio.c, then disabling them in fw_config.c if
needed.
BUG=b:231690996
TEST=LTE still works on nivviks
Change-Id: I5bf20a027414ea5e7c1f198d69e355c76f467244
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66776
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The flag EC_BATT_FLAG_CUT_OFF was added with the CL:
3704470: battery: Set battery cutoff flag
https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3704470
This flag is set in the ACPI memory mapped area when the command
`ectool batterycutoff` is issued so ACPI code can respond
appriopriately. This CL adds the flags to coreboot ACPI.
BRANCH=none
BUG=b:217911928
TEST=Boot nipperkin with low & no battery
TEST=Boot skyrim with low & no battery
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: I4e63ff4fc2d6b0ecf767a6bffd81f823c74c15bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66803
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the Shadow Registers from 2 through 5 and print information
from them accordingly. All values were taken from Intel document
number 571993.
Tested on the StarLite Mk III and the correct values are
shown:
[DEBUG] CSE: IBB Verification Result: PASS
[DEBUG] CSE: IBB Verification Done : YES
[DEBUG] CSE: Actual IBB Size : 88
[DEBUG] CSE: Verified Boot Valid : FAIL
[DEBUG] CSE: Verified Boot Test : NO
[DEBUG] CSE: FPF status : FUSED
Please note, the values shown are in an error state.
This replaces the Fuse check that is done via Heci, as this will only
work whilst the CSE is in a normal state.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I8a9e7b329010fae1a2ed9c3fefc9765e617cdfe4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add supported memory parts in mem_parts_used list, and generate SPD ID
for these parts.
DRAM Part Name ID to assign
MT62F512M32D2DR-031 WT:B 0 (0000)
MT62F1G32D4DR-031 WT:B 1 (0001)
H9JCNNNBK3MLYR-N6E 0 (0000)
H58G56AK6BX069 2 (0010)
K3LKBKB0BM-MGCP 2 (0010)
BUG=b:242277219
BRANCH=None
TEST=run part_id_gen to generate SPD id
Change-Id: I46c168482113beb7cd28f387ed495847aba8602f
Signed-off-by: Wisley Chen <wisley.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Create the yaviks variant of the nissa reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:242277219
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_YAVIKS
Change-Id: Id60fe0e54a8e0196a302141f58c6695779ac251a
Signed-off-by: Wisley Chen <wisley.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66681
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Build error for platforms using Intel FSP for TGL_IOT (FSP_TYPE_IOT). File FirmwareVersionInfoHob.h does not exist in Intel FSP TGL IOT package.
File FirmwareVersionInfoHob.h is included when DISPLAY_FSP_VERSION_INFO is enabled. Enable this config for non TGL_IOT only.
BUG = NA
TEST = Verify that DISPLAY_FSP_VERSION_INFO is disabled by default for TGL_IOT
configuration (Build Siemens AS_TGL1).
Change-Id: Ief5a7222daf6f1658e8dc04f97b4ddc2bcb74905
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66636
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mendocino has more eSPI decode ranges than Picasso or Cezanne. To
support these additional ranges, introduce a new Kconfig option
SOC_AMD_COMMON_BLOCK_ESPI_EXTENDED_DECODE_RANGES that can be selected by
the SoCs that support the additional eSPI IO/MMIO decode ranges.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib761cdf201c35805d68cf5e8e462607ffd9fa017
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add GPIO configuration and device tree to enable the chip.
BUG=b:240607130
BRANCH=firmware-brya-14505.B
TEST=Patch linux with NXP's pending drivers
UWB device is probed and can respond to a simple hello packet
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I83be712d243c365a5cbfe6f69a6bd85440c5bec7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Starting vboot earlier in bootblock instead of romstage is usually
preferred (smaller root of trust, among other things). Therefore
unselect VBOOT_STARTS_IN_ROMSTAGE for broadwell. Also remove the unused
BROADWELL_VBOOT_IN_BOOTBLOCK option.
Change-Id: If8feea403ee4cd3a16ed8cb0faf9f4ccb34feaaf
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The I2C config was unnecessarily placed in the overridetree. As we
prepare for fanout, this is going to cause unnecessary noisy changes.
Move the I2C config to the devicetree to avoid this.
BUG=None
TEST=Build
Change-Id: I09ad5c911a0fd00274761cb71e9b659b47cd6da1
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66802
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCIe spec explicitly states that the bottom-two bits of the next
offset are reserved for future use and should be masked. We can also
change the loop condition to avoid wrong offsets below 0x100 (exten-
ded capabilities always reside in the extended config space).
The whole patch series was tested on Google Samus and keeps the L1ss
configuration of the WiFi device in tact.
Change-Id: I0b622a0ce0a4a1127d266226ade0ec1e66e9fb79
Signed-off-by: Nico Huber <nico.h@gmx.de>
Tested-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66459
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Keeping these checks in generic code seems rather dangerous.
In theory, it could lead to endless loops even for compliant
devices, if we accidentally detect arbitrary register contents
as capability and use them as a pointer to another one. Not
to forget that the register reads can have side effects.
All users of this `cafe` have been converted to use
pciexp_find_ext_vendor_cap().
Change-Id: I70d21534e04282a4156572a290b83c46be085e0c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66456
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We have this quirk in our tree since the introduction of L1-substate
support[1]. The way we searched for this capability was rather crude:
We simply assumed that it would show up in the first data word of
another capability.
As it turned out that it is actually a proper vendor-specific capa-
bility that we are looking for, we can drop some of the mystic code.
This was confirmed to work on the device that was originally used
during development, Google/Samus.
[1] commit 31c6e632cf (PCIe: Add L1 Sub-State support.)
Change-Id: I886fb96e9a92387bc0e2a7feb746f7842cee5476
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Vendors can choose to add non-standard capabilities inside a
Vendor-Specific Extended Capability. These are identified by
the Extended Capability ID 0x0b.
Change-Id: Idd6dd0e98bd53b19077afdd4c402114578bec966
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Move the `offset` parameter into pciexp_find_extended_cap(). If it's
called with `0`, we start a new search. If it's an existing offset,
we continue the search.
This makes it easier to search for multiple occurences of a capa-
bility in a single loop.
Change-Id: I80115372a82523b90460d97f0fd0fa565c3f56cb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Now that we have functionality to get the minimal and nominal
frequencies, the corresponding fields in the CPPC config can now be
populated. If the HOB isn't present and/or the frequency values
could not be obtained, CPPC_UNSUPPORTED is still used; otherwise the
HOB-provided frequency in MHz is used for those two fields.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Change-Id: Id3257690a3388d44ceceb7ac4f1db3d49e195caa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66551
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
xhci.asl places the SS ports at 11-14, following HS ports 1-10. However,
for Nissa, the kernel detects 12 HS ports 1-12 and 4 SS ports at 13-16,
resulting in the PLD intended for SS ports 1 and 2 being associated with
HS ports 11 and 12.
Changing the asl for SS to 13-16 makes locations associate correctly and
peering work.
BUG=b:234544025
BRANCH=firmware-brya-14505.B
TEST=manually verified on Nissa and Brya devices
Change-Id: I57aef771a7ff086b71a9e90b81e1a3635f832b2f
Signed-off-by: Adam Mills <adamjmills@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66590
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SMI sleep entry handler will access the SMN space via the index/data
register at PCI config space offsets 0xb8 and 0xbc of the device at bus
0, device 0, function 0. This register pair is also used by other
software components running on the x86 cores after boot, so it should be
saved and restored at the beginning/end of the SMI handler if it
accesses SMN. The sleep entry SMI handler is a special case, since the
OS is already done at the moment we enter the sleep SMI handler which is
the last code that gets run on the x86 cores before entering S3/4/5.
BUG=b:237004699
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0980562ef8a61489082a81c71d6d00d0786d68cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65529
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
EN_PP3300_EMMC will change to GPP_A21 to meet DP++ function and it based on Moli GPIO Table_20220803.xlsx. But it will let current eMMC skus can't boot into OS, so use the board_ver to decide which gpio table return and set override_gpio_table_id2 and early_gpio_table_id2 based on Moli GPIO Table_20220803.xlsx
1. set GPP_A21 to EN_PP3300_EMMC
2. set GPP_A22 to NC
3. set GPP_E20 to DDIC_DP_CTRCLK
4. set GPP_E21 to DDIC_DP_CTRLDATA
BUG=b:241370405
TEST=emerge-brask coreboot
Signed-off-by: Raihow Shi <raihow_shi@wistron.corp-partner.google.com>
Change-Id: I0a2c8684d140738f43658cd6075ed083eee44e65
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66371
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Create the winterhold variant of the skyrim reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:240970782
BRANCH=None
TEST=util/abuild/abuild -p none -t google/skyrim -x -a
make sure the build includes GOOGLE_WINTERHOLD
Signed-off-by: Isaac Lee <isaaclee@google.com>
Change-Id: I0e16f0a674aa3f4687cd82d5840a3c2087148a51
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66620
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit I73b7ddec50936f7836f915f459ca0bdc0777cb22.
Revert change to disable post codes. Post codes were initially disabled
because of an issue with initialization within the SMU.
BUG=b:227201571
TEST=Build and boot to OS in Skyrim.
Change-Id: I2a2bd2252a103c682b5d4ad5ecd1da42b3744083
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66092
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the VW GPIOs are not in the baseboard GPIO table, they do
not actually override anything, and hence do not actually get
programmed. This patch moves the programming from the ramstage
table to the bootblock table so they get programmed.
BUG=b:214581763
BRANCH=firmware-brya-14505.B
Signed-off-by: Cliff Huang <cliff.huang@intel.corp-partner.google.com>
Change-Id: I42db44d38df20dd2695921e2f252be163f6b17f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
It is highly unlikely that the "OEM revision" of the DSDT is 0x20110725
on mainboards with a chipset not yet released on 2011-07-25. Since this
comment is most likely to have been copy-pasted from other boards, drop
it from boards which use a chipset newer than Sandy/Ivy Bridge.
Change-Id: If2f61d09082806b461878a76b286204ae56bf0eb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
This patch drops explicit usage of the address-of operator ('&') while
passing the function pointer (argument 0) to the
`mp_run_on_all_cpus` API.
Note: It's just cosmetic change without any real difference in the operation.
TEST=Able to build and boot Google/Kano where CPU feature programming
is successful on all logical processors.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2c77959a76d2240ad1bfb7a9d7b9db7e8aee42f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66685
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
If we already encountered the last extended capability in the
list, we'd call pciexp_get_ext_cap_offset() with `offset == 0`.
So it also needs to check if the passed offset is valid.
As there were no callers of pciexp_find_next_extended_cap()
yet, pciexp_get_ext_cap_offset() was only ever called with
`PCIE_EXT_CAP_OFFSET`.
Change-Id: I155c4691a34ff16661919913a3446fa915ac535e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The PSP currently uses a hard coded GPIO for the TPM IRQ. Not all board
versions use the same GPIO. This method allows the mainboard to pass
in the correct GPIO.
BUG=b:241824257
TEST=Boot guybrush and verify PSP message prints
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ie05d095d7f141d6a526d08fbf25eb2652e96aa49
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Since bootblock_soc_early_init gets called before
bootblock_mainboard_early_init which does the early GPIO setup, external
I2C level shifters that are controlled by GPIOs might not be enabled yet.
Moving the reset_i2c_peripherals call to bootblock_soc_init makes sure
that the early GPIO setup is already done when reset_i2c_peripherals is
called.
Haven't probed any SCL signal on the non-SoC side of the I2C level
shifters yet, but the waveform on the SCL pin of I2C3 on the SoC of a
barla/careena Chromebook doesn't have the longer than expected SCL
pulses any more.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If02140aef56ed6db7ecee24811724b5b24e54a91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Logo.bmp is overwritten with a custom one from coreboot. This needs to
be restored before the branch is updated otherwise git will report that
the repository is dirty.
Move this to the update recipe so that will always be done for any
recipe that needs to update the branch.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I85bf753a47d9e70d6555dec9a539e8ed7395bead
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66355
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for SocInfo in coreboot. The API socinfo_modem_supported is
added to help to differentiate between LTE and WiFi SKUs.
BUG=b:232302324
TEST=Validate boards are detected correctly on LTE and Wifi SKUs
Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
Change-Id: I61047ad49772c3796ba403cafde311ad184a4093
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Add a new driver for NXP UWB SR1xx (e.g., SR150) device.
The driver was originally written by Tim Wawrzynczak as a WIP in
CL:3503703, and was based on drivers/spi/acpi.
BUG=b:240607130
BRANCH=firmware-brya-14505.B
TEST=On ghost (with follow-up CL), patch linux with NXP's pending
drivers
-> UWB device is probed and can respond to a simple hello
packet
Co-authored-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I5b1b0a5c1b48d0b09e7ab5f2ea6b6bc2fba2a7d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66466
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce the `BROADWELL_LPDDR3` Kconfig option along with some wrapper
code to allow mainboards using LPDDR3 DRAM to supply the DQ/DQS maps to
chipset code without having to use `pei_data`. The only mainboard using
LPDDR3 is Google Samus.
Change-Id: I0aaf0ace243c03600430c2a7ab6389a7b20cb432
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55812
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboards do not need to know about `pei_data` to tell northbridge code
where to find the SPD data. As done on Haswell, add the `mb_get_spd_map`
function and the `struct spd_info` type to retrieve SPD information from
mainboard code without having to use `pei_data` in said mainboard code.
Unlike Haswell MRC, Broadwell MRC uses all positions of the `spd_data`
array, not just the first. The placeholder SPD address for memory-down
seems to be different as well. Adapt the existing code to handle these
variations. Once complete, the abstraction layer for both MRC binaries
will have the same API.
Change-Id: I92a05003a319c354675368cae8e34980bd2f9e10
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
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: I8d3b352333bea7ea6f7b0f96d73e6c2d7d1a2cfb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55809
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Introduce the `SPD_MEMORY_DOWN` macro to indicate that a slot is used
with memory-down. This enables computing the channel disable masks as
the bits for slots where the SPD address is zero. To preserve current
behavior, zero the SPD addresses for memory-down slots afterwards.
Change-Id: I75b7be7c72062d1a26cfc7b09b79de62de0a9cea
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55807
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is the version of genrelnotes that was used to help with the
4.16 release.
- Fix shellcheck issues.
- Send messages for the user to STDERR.
- Add recent platforms
- Handle symbolic links to the git repo.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2204793a5d1cc5792d0720d2bbfb172bb6020dd4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
To generate a complete _CPC ACPI object, coreboot needs the minimal and
nominal core speed values which are specific to the CPU and not only the
CPU family. Since this is done by an undocumented mechanism, FSP has to
do this and puts the information we need into a HOB. This adds the HOB
GUID and the structure of the HOB data.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Change-Id: Ibf338c32de367a3fd57695873da1625338fa196d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66549
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These files contain no creative content, and therefore have no
copyright. This effectively means that they are in the public
domain.
This commit updates the unlicensable empty (and effectively empty)
files with the CC-PDDX identifier for license compliance scanning.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I0b76921a32e482b6aed154dddaba368f29ac2207
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66497
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A 32-bit long storing microseconds will rollover every ~1.19 hours.
This can cause stopwatch to misbehave, causing unexpected failures.
If the current field in stopwatch is near 2^31, the expires field may
rollover when initialized. If this occurs, stopwatch_expired() will
instantly return true.
If current and expires fields are near 2^31, the current field could
rollover before being checked. In this case, stopwatch_expired() will
not return true for over an hour. Also stopwatch_duration_usecs() will
return a large negative duration.
This issue has only been observed in SMM since it never takes more
than 35 minutes to boot.
Switching to uint64_t mitigates this issue since it will not rollover
for over 500K+ years. The raw TSC would rollover sooner than this,
~200 years, depending on the tick frequency.
BUG=b:237082996
BRANCH=All
TEST=Boot Nipperkin
Change-Id: I4c24894718f093ac7cd1e434410bc64e6436869a
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65403
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Move the code that prints the edk2 build options to it's own recipe
so that it can be called for different targets.
This change also fixes the print, as it accounts for recent switches
such as `--pcd` and `-s`.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ie797ca26cd28eab0f633bd8dee5ec19634fcea99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
DFD (Design for Debug) is a debugging tool, which scans flip-flops
and dumps to internal RAM on the WDT reset. After system reboots,
those values can be shown for debugging using MTK internal parsing
tools.
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I6d19dc6f4e47ed69ba2ea87c79984020a413aee9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66586
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tracker is a debugging tool. When bus timeout occurs, the system will
reboot and latch some values of tracker registers which could be used
for debugging.
This function will be triggered only when it encounters the bus
hanging issue.
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I78f676c08ea44e9bb10bd99bbfed70e3e8ece993
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66584
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 replaces 'SPDX-License-Identifier' tags in all the files under
soc/mediatek/mt8188 for better code re-use in other open source
software stack.
These files were originally from MediaTek and follow coreboot's main
license: "GPL-2.0-only". Now MediaTek replaces these files to
"GPL-2.0-only OR MIT" license.
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Change-Id: If61e8b252400e8e5ecd185b6806b1ca279065f15
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66628
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
A power and performance analysis performed on Alder Lake demonstrated
that with an EPP (Energy Performance Preference) at 50% along with
EET (Energy Efficient Turbo) disabled, the overall SoC performance are
similar or better and the SoC uses less power.
For instance some browser benchmark results improved by 2% and some
multi-core tests by 4% while at the same time power consumption
lowered by approximately 7.6%.
Similar results are observed on Raptor Lake.
BRANCH=firmware-brya-14505.B
BUG=b:240669428
TEST=verify that EPP is back to the by default 50% setting
`iotools rdmsr 0 0x774'
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I735ad9d88c7bf54def7a23b75abc4e89a213fb61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This reverts commit 938f33e9f7.
A power and performance analysis performed on Alder Lake demonstrated
that with an EPP (Energy Performance Preference) at 50% along with
EET (Energy Efficient Turbo) disabled, the overall SoC performance are
similar or better and the SoC uses less power.
For instance some browser benchmark results improved by 2% and some
multi-core tests by 4% while at the same time power consumption
lowered by approximately 7.6%.
BRANCH=firmware-brya-14505.B
BUG=b:240669428
TEST=verify that EPP is back to the by default 50% setting
`iotools rdmsr 0 0x774'
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Icacc555e62533ced30db83e0a036db1c85c0bfa6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66283
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This reverts commit 844dcb3725.
A power and performance analysis performed on Alder Lake demonstrated
that with an EPP (Energy Performance Preference) at 50% along with
EET (Energy Efficient Turbo) disabled, the overall SoC performance are
similar or better and the SoC uses less power.
For instance some browser benchmark results improved by 2% and some
multi-core tests by 4% while at the same time power consumption
lowered by approximately 7.6%.
BRANCH=firmware-brya-14505.B
BUG=b:240669428
TEST=verify that ETT is disabled
`iotools rdmsr 0 0x1fc'
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I96a72009aaf96d4237d57f4d5c8b1f41f87174d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66281
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Unassigned tag is defined to emulate an unmapped PCI BAR resource.
This resource is not mapped into host physical address and hence
should not be picked up by memranges_add_resources().
Change-Id: If7a5c437d486b80d798496b985efd80526f13c63
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66451
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
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>
IORESOURCE_ASSIGNED is used to indicate the resource is actually mapped
host physical address space. E.g. PCI BAR resources not mapped are
not regarded as assigned.
In src/include/device/device.h, standard macros, e.g. ram_resource,
mmio_resource, io_resource, et al, are all following the usage above.
This patch updates the bootmem-test and memrange-test to follow the
usage as well.
Change-Id: Ifc19302482038267cef01321a46a72d90ca76d35
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66450
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 removing SD card from USB card reader, the USB MSC stack does
not detach the device immediately. Instead, the USB MSC stack calls
usbdisk_remove() and calls usb_msc_destroy() after several pollings.
It results in usbdisk_remove() being called twice.
Since the usbmsc_inst_t instance is freed after first usbdisk_remove()
call, the second call invokes an invalid usbmsc_inst_t instance and
causes exception in CPU.
This patch prevents usbdisk_remove() from being called twice by setting
usbdisk_created to zero.
BUG=b:239492347
TEST=insert an empty SD card into the USB card reader then remove
the SD card. AP firmware does not crash.
Change-Id: I0675e9fde3e770d63dd0047928356a204245ef18
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66449
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
'Mendocino' was an embargoed name and could previously not be used.
Update amdfwtool for consistency with the correct naming convention.
BUG=b:239072117
TEST=Builds
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Change-Id: I404fcf59e89b75cd2488bcb51981aee2eb4ff0df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66468
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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 Creative Commons Public Domain Dedication and Certification is not
a license in the common sense in that it's stating that the associated
file is already in the public domain (having no copyright), and is not
actually putting it in the public domain like the CC-C0 license does.
The use for this in coreboot is for unlicensable files - either blank
files or files with no creative content. This allows these files to
have the SPDX identifier to identify them as having no known copyright
for open source license compliance.
If CC-PDM-1.0 is ever included in the list of SPDX licenses, that would
probably fit better, but because the public domain mark isn't actually
a license, and because "public domain" isn't well defined, CC-PDM was
rejected as a SPDX identifier.
For further information:
https://web.archive.org/web/20201018194411/https://github.com/spdx/license-list-XML/issues/988
Change-Id: Ibb300ecd066cde2a016195c2beca76a460c588e3
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66496
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
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>
This script creates a patch to remove all of the coreboot code that a
platform doesn't use. This is useful for auditing the codebase for an
individual platform or releasing a platform's code.
Unlike the script that Sage used that did something similar, this keeps
the entire Kconfig tree (Though in a single file), all makefiles that
are required to build, and the standard build tools can still be used.
This will allow for much easier re-integration back into the coreboot
codebase if code is released after running this.
This is just the initial version and more features needed to be added to
make it fully functional.
- It should be able to build multiple configurations to retain the code
for all of those configurations.
- Flag to remove submodules files as well
- Additional variable flags to replace hardcoded values.
- The list of makefiles that need to be kept is pretty long, and could
be updated so that they aren't needed by the top level makefiles.
- Add flag to show changed files
- Show number of files before and after script is run
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iec69db2ad1358846d649db627b6d60ac8c2204e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
On boards which use both PSP recovery A/B layout as well as VBOOT A/B
layout, ISH_B directory entry is pointing directly to PSP Level2
directory. This is not correct and either ISH_B should be marked as not
present or it should point to the ISH_A directory itself which in turn
point to PSP L2 directory. Fix it by choosing the latter option.
BUG=None
TEST=Build and boot to OS in Skyrim with PSP verstage.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I0a7a56e98de3f85669ff8ec2fcd1687aa33576a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
Currently bootblock does not initialize eSPI if it is already done in
PSP verstage. But some other component is clobbering the eSPI
configuration causing timeouts in EC communication after the boot flow
hits x86. To workaround this issue, re-initialize eSPI in bootblock.
BUG=b:217414563
TEST=Build and boot to OS in Skyrim with PSP verstage.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I41c0b2816a106a6a547f3cb372693e1bb7f23734
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This adds a default early GPIO table in the case of us not being
able to identify a valid board ID.
Primarily, this is useful in the case of EC issues to ensure
that debug interfaces (e.g. UART) are always up and available.
BUG=b:238165977
TEST=Boots and no errors on simics
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: I135dc6c29bc23195afe5c78eb79992691652d9e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66394
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The lid sensor is on a daughterboard which can cause unintended
shutdowns when not connected. Disable lid sensor based shutdown behavior
in depthcharge until we have a better solution.
BUG=b:240005819
BRANCH=firmware-brya-14505.B
TEST=booted ghost, no longer shuts down due to missing lid sensor
Change-Id: I69f70255dee1b69e05b112c0174f5f52d1368837
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Support for feature "In-Band ECC" not available for Tiger Lake
Similar to Elkhart Lake, Tiger Lake also provides this feature.
Ported from Elkhart Lake (CB:55668)
Bug = N/A
TEST = Build and boot Siemens AS-TGL1
Change-Id: Ie54d5f6a9747fad0105d0f8bf725be611bb8cf60
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event
logging types as below:
* ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason
while booting into recovery mode
* ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into
developer mode.
* ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into
diagnostic mode.
Drop static structure `cros_deprecated_recovery_reasons` as it has been
replaced by vb2_get_recovery_reason_string() function.
ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those
related fw boot info along with ChromeOS boot mode/reason etc.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I932952ce32337e2d54473667ce17582a90882da8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Building firmware for Brya is currently broken due to the RO_FWID region
for adlrvp_m_ext_ec bloating past 64 characters.
The CONFIG_MAINBOARD_PART_NUMBER is catenated onto the
CONFIG_MAINBOARD_VENDOR string, which for Intel, makes for a very long
trunk string that the kernel version will then be added to form the
RO_FWID string. For Intel, that trunk string is already pretty long at :
"Intel Corporation_Alder Lake Client Platform".
Shortening the CONFIG_MAINBOARD_PART_NUMBER should address this issue
for now.
BUG=b:241273391
TEST="emerge-brya coreboot chromeos-bootimage" and verify it builds
successfully
Change-Id: Ie862c87dd9a24743f249f1b10862ca6f3295db23
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Check return value of cbfs_truncate_space() in cbfs_truncate().
Remove return from cbfs_image_from_buffer() to inform about invalid
image region when incorrect offset header was provided.
Also change header offset provided to mentioned function in
cbfs_expand_to_region() and cbfs_truncate_space() from zero
to HEADER_OFFSET_UNKNOWN, as they do not support images with cbfs master
header.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ib009212692fb3594a826436df765860f54837154
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The check was recently removed to allow callers to pass `count == 0`.
Dereferencing the `msg` array is invalid in that case, though. Linux,
where we borrowed the i2c interface from, also treats this with -EINVAL.
Change-Id: I1eec02dd3a3fcf2d477a62cc65292fca40e469d3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
- Retrieve the SKU ID for Geralt via CBI interface. If that failed
(or no data found), fall back to ADC channels for SKU ID.
- The RAM code is implemented by the resistor straps that we can read
and decode from ADC.
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I31626e44bd873a3866c9bd1d511b476737f15a20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66275
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
UFS storage devices require the bRefClkFreq attribute to be set to
operate correctly in high speed mode. The correct value is determined by
what the SoC / board supports. For the ADL UFS controller, it is
19.2 MHz.
a) Introduce a new ACPI property "ref-clk-freq".
b) Add support to configure this property using an SoC Kconfig.
Kernel patch:
https://web.archive.org/web/20220801060732/https://lore.kernel.org/all/
20220715210230.1.I365d113d275117dee8fd055ce4fc7e6aebd0bce9@changeid/
BUG=b:238262674
TEST=Build,boot Nirwen and dump SSDT entries and check that the kernel
correctly parses ref-clk-freq as 19.2 MHz.
Scope (\_SB.PCI0)
{
Device (UFS)
{
Name (_ADR, 0x0000000000120007) // _ADR: Address
Name (_DDN, "UFS Controller") // _DDN: DOS Device Name
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
/* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"ref-clk-freq",
0x0124F800
}
}
})
}
}
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: I80c338a8a61f161b0feb6c5a3ca00cf5e0cfb36c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
- Add support for edp aux read and write.
- Update edp panel properties based on edid read.
- Configure edp controller and edp phy.
Panel details:
Manufacturer: SHP Model 1523 Serial Number 0
Made week 53 of 2020
EDID version: 1.4
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 31 cm x 17 cm
Gamma: 220%
Check DPMS levels
Supported color formats: RGB 4:4:4
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Supports GTF timings within operating range
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: 5a8780a070384d403020350035ae10000018
Detailed mode (IN HEX): Clock 346500 KHz, 135 mm x ae mm
0780 07b0 07d0 0820 hborder 0
0438 043b 0440 0485 vborder 0
-hsync -vsync
Did detailed timing
Hex of detail: 653880a070384d403020350035ae10000018
Detailed mode (IN HEX): Clock 144370 KHz, 135 mm x ae mm
0780 07b0 07d0 0820 hborder 0
0438 043b 0440 0485 vborder 0
-hsync -vsync
Hex of detail: 000000fd003090a7a7230100000000000000
Monitor ranges (bare limits): 48-144Hz V, 167-167kHz H, max dotclock
350MHz
Hex of detail: 000000fc004c513134304d314a5734390a20
Monitor name: LQ140M1JW49
Changes in V2:
- Remove Misc delays in edp code.
- Move mdss soc code to disp.c
- Update EDID read using I2C write & read.
Changes in V3:
- Remove unrelated delays.
- Misc changes.
BUG=b:182963902,b:216687885
TEST=Validated on qualcomm sc7280 development board.
Monitor name: LQ140M1JW49
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Change-Id: If89abb76028766b19450e756889a5d7776106f95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
gcc 12 fails the build with the warning below:
CC romstage/lib/cbfs.o
src/lib/cbfs.c: In function 'switch_to_postram_cache':
src/lib/cbfs.c:31:32: error: comparison between two arrays [-Werror=array-compare]
31 | if (_preram_cbfs_cache != _postram_cbfs_cache)
| ^~
src/lib/cbfs.c:31:32: note: use '&_preram_cbfs_cache[0] != &_postram_cbfs_cache[0]' to compare the addresses
Instead of following gcc’s suggestion, disable the warning for gcc as
requested by Julius [1]:
> Can we just set -Wno-array-compare instead? There's nothing illegal
> about that expression and as we can see in this case, there are
> perfectly reasonable cases where you might want to do something like
> that. On the other hand, I don't really see a realistic scenario where
> this warning could prevent a real problem (anyone who doesn't know
> that array1 == array2 doesn't compare the array elements in C
> shouldn't have any business submitting code to coreboot).
[1]: https://review.coreboot.org/c/coreboot/+/62827/1
Found-by: gcc-12 (Debian 12-20220313-1) 12.0.1 20220314 (experimental) [master r12-7638-g823b3b79cd2]
Found-by: gcc (Debian 12.1.0-7) 12.1.0
Change-Id: I322f7cc57dcca713141bddaaaed9ec034898754d
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use the new "detect" method instead of "probed". Fixes an uncommon issue
where i2c-hid fails to initialize the device on Linux.
Tested on: gaze15, gaze16-3060, lemp10, oryp8
Tested:
- Linux: Touchpad works across 50 reboots
- Windows: Touchpad is still detected as an I2C HID device
- Windows: Extra I2C HID devices are not shown in Device Manager
Change-Id: I6a899c64a6d77b65a2ae57ab8df81cd84b568184
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
the missing `; \` at the end of the line meant subsequent lines
were no longer run from $project_dir, so Logo.bmp was silently
failing to restore. This led to the working dir being dirty,
and on subsequent runs, any change to a different branch in the
same repo would fail.
Change-Id: I17a323bc2dda19b69d809e398b273f24e14b43af
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66321
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Copy the constraint from ADL-S to ADL-P.
Fixes the following warning in Linux on System76 oryp9, which has an
NVIDIA GPU on the bridge.
pcieport 0000:00:01.0: can't derive routing for PCI INT A
This, in turn, resolves an IRQ conflict with the PCH HDA device that
would cause a stack track on every boot.
irq 10: nobody cared (try booting with the "irqpoll" option)
<snip>
[<00000000bf549647>] azx_interrupt [snd_hda_codec]
Disabling IRQ #10
Change-Id: I550c80105ff861d051170ed748149aeb25a545db
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66285
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch calls into vboot API (vb2api_get_fw_boot_info) to retrieve
FW slot boot information like (tries count, current boot slot, previous
boot slot, previous boot status and boot mode).
Upon retrieval of the vboot information, elog callback from ramstage
records the info into the eventlog.
Additionally, this patch refactors the existing event logging mechanism
to add newer APIs to record vboot firmware boot related information.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS and run below command to
check the cbmem log:
Scenario 1:
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2_check_recovery() Recovery reason from previous boot:
0x0 / 0x0
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Developer boot`
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Success`.
....
Scenario 2:
localhost ~ # crossystem recovery_request=1
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Manual recovery boot`
VB2:vb2api_fill_boot_config() recovery_reason=0x13 / 0x00
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Unknown`.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6882cd1c4dbe5e24f6460388cd1af4e4a05fc4da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65561
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add static check to ensure the reserved APOB DRAM space is the same size
as the MRC_CACHE region specified in the fmap.
Update sabrina APOB DRAM size to match the fmap.
TEST: Timeless builds identical. Test build with a larger MRC_CACHE than
APOB DRAM failed the assert as expected.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ia14f6ef94b9062df0612fe96098b1012085ccf9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65878
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Firmware component that does memory training already limits the memory
controller to train at 5500 Mbps for all memory parts in Sabrina. Hence
removing this interim SPD change to limit the speed.
BUG=b:238074863
TEST=Build and boot to OS in Skyrim.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I2bc82c7407a97aac282708c3e0bd56ae99a8fc31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66290
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to pass PCIe base address to payloads, implement pcie_fill_lb()
to fill coreboot table with PCIe info.
BUG=b:182963902,b:216686574,b:181098581
TEST=Verified on Qualcomm sc7280 development board with NVMe endpoint
(Koixa NVMe, Model-KBG40ZPZ256G with FW AEGA0102). Confirmed NVMe is
getting detected in response to 'storage init' command in depthcharge
CLI prompt.
Output logs:
->dpch: storage init
Initializing NVMe controller 1e0f:0001
Identified NVMe model KBG40ZPZ256G TOSHIBA MEMORY
Added NVMe drive "NVMe Namespace 1" lbasize:512, count:0x1dcf32b0
* 0: NVMe Namespace 1
1 devices total
Also verified NVMe boot path that is depthcharge is able to load the
kernel image from NVMe storage.
Change-Id: I1ca2be55b98c8d1b86576072078cdda02ac55940
Signed-off-by: Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57614
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add 'pci_map_bus' function and PCIE_QCOM config for Qualcomm platform.
BUG=b:182963902,b:216686574,b:181098581
TEST=Verified on Qualcomm sc7280 development board with NVMe endpoint
(Koixa NVMe, Model-KBG40ZPZ256G with FW AEGA0102). Confirmed NVMe is
getting detected in response to 'storage init' command in depthcharge
CLI prompt.
Output logs:
->dpch: storage init
Initializing NVMe controller 1e0f:0001
Identified NVMe model KBG40ZPZ256G TOSHIBA MEMORY
Added NVMe drive "NVMe Namespace 1" lbasize:512, count:0x1dcf32b0
* 0: NVMe Namespace 1
1 devices total
Also verified NVMe boot path that is depthcharge is able to load the
kernel image from NVMe storage.
Change-Id: I7d1217502cbd7d4d0cdd298919ae82435630d61c
Signed-off-by: Prasad Malisetty <quic_pmaliset@quicinc.com>
Signed-off-by: Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57615
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add PCIe domain support for herobrine by enabling it in the devicetree.
BUG=b:182963902,b:216686574,b:181098581
TEST=Verified on Qualcomm sc7280 development board with NVMe card
(Koixa NVMe, Model-KBG40ZPZ256G with FW AEGA0102). Confirmed NVMe is
getting detected in response to 'storage init' command in depthcharge
CLI prompt.
Output logs:
->dpch: storage init
Initializing NVMe controller 1e0f:0001
Identified NVMe model KBG40ZPZ256G TOSHIBA MEMORY
Added NVMe drive "NVMe Namespace 1" lbasize:512, count:0x1dcf32b0
* 0: NVMe Namespace 1
1 devices total
Also verified NVMe boot path, that is depthcharge is able to load the
kernel image from NVMe storage.
Change-Id: Ied8fbbc8d20698ee081d93ba184b7d0291bb6a76
Signed-off-by: Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65137
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Disabling the Package C-state demotion feature for brya baseboard
as a work around to the S0ix issue and also this doesn't have any
impact on the power and performance measured and verified by the
PNP team.
This feature will be enabled after its functionality is verified with no
issues and also based on its impact on PNP.
BUG=none
BRANCH=firmware-brya-14505.B
TEST=Boot and verified that S0ix issue is resolved.
Signed-off-by: Zhixing Ma <zhixing.ma@intel.com>
Change-Id: Id3941c8870d41b25488c8ac5d38534fa94664d4a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65805
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This adds SPDX-License-Identifiers to all of the files in src/include
that are missing them or have unrecognized identifiers.
Files that were written specifically for coreboot and don't have license
information are licensed GPL-2.0-only, which is the license for the
overall coreboot project.
Files that were sourced from Linux are similarly GPL-2.0-only.
The cpu/power files were committed with source that was licensed as
GPL-2.0-or-later, so presumably that's the license for that entire
commit.
The final file, vbe.h gives a pointer to the BSD-2-Clause license
at opensource.org.
Change-Id: I3f8fd7848ce11c1a0060e05903fb17a7583b4725
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This reverts commit 78261e308de5361b2ff045091e8fb18cad2a5035.
Reason for revert: Now that PSP supports a soft fuse flag to toggle the
verstage serial logs, prevent PSP verstage from writing to the UART.
BUG=None
TEST=Build and boot to OS in Skyrim with PSP verstage. Ensure that PSP
verstage logs are not seen twice in the console.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I7ef2d585c320ea5903197939136dd2049a71af95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66248
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
HW Modexp engine is verified to be working fine. Any verification
failures during PSP verstage are because the firmware body is not read
correctly. This might be because of the incorrect SPI ROM mapping. Hence
enable the HW modexp engine for keyblock, preamble and firmware body
verification.
BUG=b:240175446
TEST=Build and boot to OS in Skyrim with PSP verstage using one of the
FW slots.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I8f6742630a7049354a24053fce28c477e53259e6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This is required to enable PSP verstage on SoCs with recovery A/B
layout.
BUG=b:217414563
TEST=Ensure that the concerned type 0x3a PSP entry is present in PSP L2
directory. Build and boot to OS in Skyrim with both PSP and x86
verstage.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I5fae2b5dbcc95a99af3df9f59bb8516280ec1281
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66246
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
SMMSTORE support in edk2 was not allowed in upstream edk2
as it was bootloader specific.
Shortly, it will be built from edk2-platforms and then,
it will be retired.
For now, the patches exist in the MrChromeBox fork (TIANOCORE_UEFIPAYLOAD), so enable
these by default when SMMSTORE_v2 is enabled.
Change-Id: I1861bf739c2e25f661b4f06a303348f0537dc8b3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65867
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Move configs for PCIe ports not present on z220_sff_workstation
from the devicetree.cb of base board to the overridetree.cb of
z220_cmt_workstation.
- Add a note for ME/AMT Flash Override jumper, for it is hard to
flash from OEM firmware either internally or externally without
closing this jumper.
- Add a side note for similar HP Compaq Elite 8300 SFF.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I35d8b97f52a83910a61c12b1f7367ee7a19a9ad7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65703
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
futility now supports image truncation and signing of whole images with
a single command invocation. Use it for vboot-enabled coreboot images.
TEST=Build and run coreboot on google/volteer
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I49eb7e977b635ccb9f6c1b76e53c36e82be1d795
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
MT8188 SPI tick delay setting is moved to `spi_cmd_reg` register which
is different from previous SoCs, so we define a macro to get the
designated register.
TEST=build pass.
BUG=b:233720142
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: Ia30e94a8688c0e1c1d4b3d15206f28e5bd8c9bd4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66184
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the gaelin variant of the brask reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:239514438
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_GAELIN
Signed-off-by: Raymond Chung <raymondchung@ami.corp-partner.google.com>
Change-Id: I7f1ff8690c7c57f8960e004d0490d5cede8667f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Add TDP and Power Limit settings for ADL-S 8+8 150W, 4+0 and 2+0.
The System Agent PCI IDs were not present in older 2.1 revision of
DOC #619501. Now that the mapping of these IDs to SKUs is known, fill
the missing TDPs and Power Limit settings based on DOC #626343.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I23dd8478e60bcc81a1048f2f6e6717dd281d1a69
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66053
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
The patch updates platform_is_resuming() API such that platform resume
state is determined from the saved state (CBMEM) instead of checking PMC
registers (PM1_STS & PM1_CNT) as they are getting cleared (before/early)
ramstage.
coreboot sends DISCONNECT IPC command which times out during resume (S3)
if system has servoV4 connected on port0. The issue occurs only during
the first cycle of resume (S3) test cycle after cold boot due to side
effect of platform_is_resuming() API that is not determining the resume
(S3) state correctly in ramstage.
PM1_STS and PM1_CNT register gets cleared at the start of ramstage.
platform_is_resuming() function was checks the cleared register value
and fails the condition of resume (S3) resulting in sending DISCONNECT
IPC command. Checking the platform resume state from the CBMEM saved
state using acpe_get_sleep_type() function helps cross verify the
system previous state at the later part of ramstage.
localhost ~ # cbmem -c | grep ERROR
[ERROR] EC returned error result code 3
[ERROR] PMC IPC timeout after 1000 ms
[ERROR] PMC IPC command 0x200a7 failed
[ERROR] pmc_send_ipc_cmd failed
[ERROR] Failed to setup port:0 to initial state
[ERROR] PMC IPC timeout after 1000 ms
[ERROR] PMC IPC command 0x200a7 failed
[ERROR] pmc_send_ipc_cmd failed
[ERROR] Failed to setup port:1 to initial state
[ERROR] GENERIC: 0.0 missing read_resources
[ERROR] PMC IPC timeout after 1000 ms
[ERROR] PMC IPC command 0xd0 failed
[ERROR] PMC: Failed sending PCI Enumeration Done Command
BUG=b:227289581
TEST=Verified system boots to OS and verified below tests on
Redrix (ADL-P) and Nivviks (ADL-N)
1. coreboot doesn't send the DISCONNECT during S3 resume
2. suspend S3 passes with both suzyq and servoV4 connected
3. After S3 resume, system detects the pen drive with Superspeed
4. After system resumes from S3, hot-plug the pen drive, system detects
the pen drive
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I353ab49073bc4b5288943e19a75efa04bd809227
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66126
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For some yet unknown reason, when this GPIO is locked, there is an
interrupt storm for IRQ #9 apparently caused by GPE 0x66. GPP_F14 is set
to GPE 0x64 on the ADL platform, so this doesn't quite make sense. This
patch removes the lock and fixes this IRQ storm, but the root cause is
not identified yet.
BUG=b:236997604
TEST=`grep ' 9:' /proc/interrupts` shows a reasonable value now
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I3d1c66fac80a173798ae33e48b1776d9f4fb5eaa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
There are 3 more CPU PCIe RP UPDs that are the current code is not setting,
and some boards may want to set these, so this patch adds support to set
these UPDs. The default values for any existing boards using these UPDs
should not change with this patch.
The UPDs are:
- CpuPcieRpDetectTimeoutMs
- CpuPcieRpAspm
- CpuPcieRpSlotImplemented
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Id48019f984e8e53ff3ce0c3c23e02dab65112c99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66197
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current "normal" EPB (six) setting resulted in the desired out of
box power and performance for several CPU generations.
However, a power and performance analysis on Alder Lake and Raptor
Lake CPUs demonstrates that this value results in undesirable higher
uncore power and that seven is a more appropriate value.
Note: the Linux kernel "4ecc933b x86: intel_epb: Allow model specific
normal EPB value" patch sets the EPB to 7 for Alder Lake.
BRANCH=firmware-brya-14505.B
BUG=b:239853069
TEST=verify that EPB is set by coreboot
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I5784656903d4c58bedc5063ee3ef310a99711050
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66059
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to document 619503 ADL EDS Vol2, bit 18 of MSR_POWER_CTL
must be set to be able to set the Energy/Performance Bias using MSR
IA32_ENERGY_PERF_BIAS.
Note that since this bit was not set until this patch, the
`set_energy_perf_bias(ENERGY_POLICY_NORMAL);' call in
`soc_core_init()` was systematically failing.
BRANCH=firmware-brya-14505.B
BUG=b:239853069
TEST=verify that EPB is set by coreboot
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Ic24abdd7f63f4707b8996da4755a26be148efe4a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch fixes the documentation discrepancy of GPIO reset type
between PCH EDS and GPIO BWG.
As per GPIO BWG, there are four GPIO reset types in Meteor Lake as
below:
- Power Good - (Value 00)
- Deep - (Value 01)
- Host Reset/PLTRST - (Value 10)
- Global Reset for GPP - (Value 11)
Also, dropped the need for having dedicated reset type for GPIO
community 3. As per the MTL EDS, all GPIO communities have the same
reset type.
BUG=b:213293047
TEST=Able to build and boot Google/Rex without below error msg.
[ERROR] gpio_pad_reset_config_override: Logical to Chipset mapping
not found
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Id7ea16d89b6f01b00a7b7c52945f6e01e8db6cbd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66155
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Will Kim <norwayforest92@gmail.com>
Enabling them causes firmware keyblock/preamble and/or body verification
failure. Hence disabling them to use software based verification.
Re-enable them once the issue is root-caused.
BUG=b:217414563
TEST=Build and boot to OS in Skyrim with PSP and x86 verstage.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I7e259ae5d790977d08afcb0a77f8d4f38c85f39e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66134
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently only SHA_GENERIC is used and does not need to be passed.
BUG=b:217414563
TEST=Build and boot to OS in Skyrim with PSP and x86 verstage.
Change-Id: Id705b1361fffaf940c51515e7f77d7fb0677fc4a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
wifi
This reverts commit 5e6fd360de.
On nereid, the SSDT entry for the PCIe wifi device is missing, causing
wake-on-WLAN not to work since the _PRW is missing.
It seems like when commit 5e6fd360de changed the SSDT generation logic
for CNVi and PCIe wifi, it broke the PCIe case. `wifi_pcie_ops` are
never assigned to any device, so
`parent && parent->ops == &wifi_pcie_ops` always returns false, and the
`wifi_cnvi_ops` are used even for PCIe devices.
Undo the changes in that CL. This allows both the CNVi and PCIe cases to
work. That CL was meant to fix an issue with the CNVi _PRW containing
garbage, but I can't reproduce this when the change is undone.
It was also meant to fix the following error on CNVi devices, but I
don't see any errors with this change:
[ERROR] NONE missing set_resources
BUB=b:233325709
TEST=On both nivviks (CNVi) and nereid (PCIe), check that the SSDT
contains the correct wifi device entries (below), including a _PRW
containing the correct GPE, and check that wake-on-WLAN works.
nivviks:
```
Scope (\_SB.PCI0.CNVW)
{
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x6D,
0x03
})
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
<snip>
}
}
```
nereid:
```
Device (\_SB.PCI0.RP01.WF00)
{
Name (_UID, 0x923ACF1C) // _UID: Unique ID
Name (_DDN, "WIFI Device") // _DDN: DOS Device Name
Name (_ADR, 0x0000000000000000) // _ADR: Address
}
Scope (\_SB.PCI0.RP01.WF00)
{
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x23,
0x03
})
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
<snip>
}
}
```
Fixes: 5e6fd360de ("drivers/wifi/generic: Fix properties in generic-under-PCI device case")
Change-Id: I100c5ee3842997c50444e5ce68d583834ed3a8ad
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66063
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit 108e537928
("payloads/tianocore: Add a proper target for the Boot Splash")
introduced 2 bugs in bootsplash handling:
- the "logo" make target added a spurious "/edk2" to the project dir
- the "logo" make target failed to account for the case where no user-
defined logo file is used (the upstream Tianocore one will be used
in this case)
Fix both these issues.
Test: build/boot qemu w/Tianocore w/o user-defined bootsplash file.
Change-Id: Ieebc547670213459823f58956ae87c6bf94b74ef
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66142
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Implement mainboard_needs_pcie_init() for cherry as a callback for
mt8195 SoC to determine whether to initialize PCIe. When the SKU id is
unknown or unprovisioned (for example at the beginning of the factory
flow), we should still initialize PCIe. Otherwise the devices with NVMe
will fail to boot.
BUG=b:238850212
TEST=emerge-cherry coreboot
BRANCH=cherry
Change-Id: I2ed0ceeb37d2924ca16485fb2d130959a7eff102
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65992
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
On SoCs which use A/B recovery layout, PSP verstage and signing keys are
expected to be present only in PSP L2 directory. Update amdfwtool to
include the PSP verstage and signing key only in PSP L2 directory.
BUG=b:239519603, b:238938623
TEST=Build and boot to OS in Skyrim with PSP verstage.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: Ieeb415be800b7ccf10d6983eb0b567e0a5eaa955
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Joxer will have both eMMC and UFS SKUs, which require different
settings in the descriptor. So update the descriptor at run-time based
on fw_config.
By default, the descriptor is configured for UFS. This configuration
still boots fine on eMMC SKUs, it just might cause problems with S0ix.
This is a temporary workaround. It will be removed once we've
implemented a proper solution for configuring the descriptor differently
for different SKUs.
BUG=b:238234376
TEST=Make an identical change for nivviks. On both nivviks (eMMC) and
nirwen (UFS), check that it boots and that the logs show the descriptor
being configured as expected.
Change-Id: I14232eb773936f2ecd183687208d332136935601
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
SSPM is "Secure System Power Manager" that provides power control in
secure domain. The initialization flow is to load SSPM firmware to
its SRAM space and then enable.
It takes 21 ms to load sspm.bin.
coreboot logs:
CBFS: Found 'sspm.bin' @0x21680 size 0xa815 in mcache @0xffffeac4
mtk_init_mcu: Loaded (and reset) sspm.bin in 21 msecs (137348 bytes)
TEST=we can see the sspm logs.
BUG=b:233720142
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: Ib6443b64734048c1d71eeac650f36d7c4ac709cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Load MCUPM firmware and boot up MCUPM in ramstage.
It takes 41 ms to load mcupm.bin.
coreboot logs:
CBFS: Found 'mcupm.bin' @0x12580 size 0xf0c6 in mcache @0xffffead0
mtk_init_mcu: Loaded (and reset) mcupm.bin in 41 msecs (122184 bytes)
TEST=we can see the mcupm logs after reset releases.
BUG=b:233720142
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: Id1e62d9d6ede1c453e03eeda0d9b16fafa9e2372
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The X2APIC_LATE_WORKAROUND kconfig allows bringing APs in XAPIC mode initially hence, it won't work if LAPIC ID is > 0xff.
This patch ensures the MAX_CPUS logic is appropriate while selecting X2APIC_LATE_WORKAROUND kconfig from SoC.
BUG=b:219061518, b:219053812
TEST=Able to build Google/Rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I466e6cc568024a9dea80af21e0ebf3572e74a1f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66110
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 patch updates the GPIO lock configuration recommendation
kconfig string to ensure the SoC user can select the correct
config as applicable for the SoC.
Note: From MTL onwards GPIO lock config can be performed using
PCR write (MMIO write) and the GPIO team has confirmed this.
BUG=b:213596994
TEST=Able to fix below GPIO lock config error msg on MTL with
`SOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCR` kconfig enabled.
[INFO ] Locking pad configuration using SBI
[INFO ] gpio_pad_config_lock_using_sbi: Locking pad 73
configuration
[ERROR] SBI Failure: Transaction Status = 1
[ERROR] Failed to lock GPIO PAD, response = 1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Icab1e4849b8e08ee1c695c924599f1513774178f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
An open standard to connect and manage functional blocks in an SoC
(System on a Chip)
* AMD64 - Another name for [**x86-64**](https://en.wikipedia.org/wiki/X86-64)
* AMD64 - Another name for [**x86-64**](https://en.wikipedia.org/wiki/X86-64)
* AMD-Vi AMD: The AMD name for their IOMMU implementation
* AMPL - AMD: [**Advanced Platform Management Link**](https://web.archive.org/web/20220509053546/https://developer.amd.com/wordpress/media/2012/10/419181.pdf) - Also referred to as
* AMPL - AMD: [**Advanced Platform Management Link**](https://web.archive.org/web/20220509053546/https://developer.amd.com/wordpress/media/2012/10/419181.pdf) - Also referred to as
SBI: Sideband Interface
SBI: Sideband Interface
* AMT - Intel: [**Active Management Technology**](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology)
* AMT - Intel: [**Active Management Technology**](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology)
* ANSI - [**American National Standards Institute**](American_National_Standards_Institute)
* ANSI - [**American National Standards Institute**](https://en.wikipedia.org/wiki/American_National_Standards_Institute)
* AOAC - AMD: Always On, Always Connected
* AOAC - AMD: Always On, Always Connected
* AP - Application processor - The main processor on the board (as
* AP - Application processor - The main processor on the board (as
opposed to the embedded controller or other processors that may be on
opposed to the embedded controller or other processors that may be on
the system), any cores in processor chip that isn’t the BSP - Boot
the system), any cores in the processor chip that aren't the BSP (Boot
Strap Processor.
Strap Processor).
* APCB - AMD: AMD PSP Customization Block
* APCB - AMD: AMD PSP Customization Block
* API - [**Application Programming Interface**](https://en.wikipedia.org/wiki/API)
* API - [**Application Programming Interface**](https://en.wikipedia.org/wiki/API)
* HBP - Graphics: [**Horizontal Back Porch**](https://en.wikipedia.org/wiki/Horizontal_blanking_interval) In the Horizontal blanking interval, this is the blank area past the end of the scanline
* HFP - Graphics: [**Horizontal Front Porch**](https://en.wikipedia.org/wiki/Horizontal_blanking_interval) In the Horizontal blanking interval, this is the blank before the start of the next scanline.
@ -416,6 +467,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
- Also known as SenseWire
- Also known as SenseWire
* IA - Intel Architecture
* IA - Intel Architecture
* IA-64 - Intel Itanium 64-bit architecture
* IA-64 - Intel Itanium 64-bit architecture
* IAFC - RISC-V: [**RISC-V Base Integer instruction set**](https://en.wikipedia.org/wiki/RISC-V), plus atomic instructions, single precision floating point instructions, and compressed instructions
* IBB – Initial Boot Block
* IBB – Initial Boot Block
* IBV - Independent BIOS Vendor
* IBV - Independent BIOS Vendor
* IC - Integrated Circuit
* IC - Integrated Circuit
@ -428,9 +480,12 @@ Spec](https://uefi.org/specifications) for details, or run the tool
* IDSEL/AD - Initialization Device SELect/Address and Data. Each PCI
* IDSEL/AD - Initialization Device SELect/Address and Data. Each PCI
slot has a signal called IDSEL. It is used to differentiate between
slot has a signal called IDSEL. It is used to differentiate between
is a superset of AMD's earlier Hypertransport interconnect.
is a superset of AMD's earlier Hypertransport interconnect.
* IFD - Intel: Intel Flash Descriptor
* IMAFC - RISC-V: [**RISC-V Base Integer instruction set**](https://en.wikipedia.org/wiki/RISC-V), plus integer multiply & divide, atomic instructions, single precision floating point instructions, and compressed instructions
* IMC - AMD: Integrated micro-controller - An 8051 microcontroller built
* IMC - AMD: Integrated micro-controller - An 8051 microcontroller built
into some AMD FCHs (Fusion Controller Hubs) and Southbridge chips.
into some AMD FCHs (Fusion Controller Hubs) and Southbridge chips.
This never worked well for anything beyond fan control and caused
This never worked well for anything beyond fan control and caused
@ -442,6 +497,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
* MCUPM - Mediatek: MCUPM is a hardware module which is used for MCUSYS Power Management. MCUPM firmware (mcupm.bin) is loaded into MCUPM SRAM at system initialization.
* MDFIO - Intel: Multi-Die Fabric IO
* MDFIO - Intel: Multi-Die Fabric IO
* MDN - AMD: Mendocino
* mDP - Mini DisplayPort connector
* ME - Intel: Management Engine
* ME - Intel: Management Engine
* MEI - Intel: ME Interface (Previously known as HECI)
* MEI - Intel: ME Interface (Previously known as HECI)
* Memory training - the process of finding the best speeds, voltages,
* Memory training - the process of finding the best speeds, voltages,
@ -556,7 +622,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
* VDDQ Memory/Power: The supply voltage to the output buffers of a memory chip.
* VESA - Video Electronics Standards Association
* VESA - Video Electronics Standards Association
* VGA: Video Graphics Array
* VGA: Video Graphics Array
* VID: Vendor Identifier
* VID: Vendor Identifier
@ -969,12 +1081,17 @@ Spec](https://uefi.org/specifications) for details, or run the tool
* VLB - VESA Local Bus
* VLB - VESA Local Bus
* VOIP - Voice over IP
* VOIP - Voice over IP
* Voodoo mode - a silly name for Big Real mode.
* Voodoo mode - a silly name for Big Real mode.
* VMX - Intel: CPU flag for Hardware Virtualization
* VPD - Vital Product Data
* VPD - Vital Product Data
* VPN - Virtual Private Network
* VPN - Virtual Private Network
* VPU - Intel: Versatile Processor Unit
* VR - Voltage Regulator
* VR - Voltage Regulator
* VRAM - Video Random Access Memory
* VRAM - Video Random Access Memory
* VREF Memory/Power: Reference voltage for the input lines of a chip that determines the voltage level at which the threshold between a logical 1 and a logical 0 occurs. Usually 1/2 VDDQ.
* VRM - Voltage Regulator Module
* VRM - Voltage Regulator Module
* VT-d - Intel: Virtualization Technology for Directed I/O
* VT-d - Intel: Virtualization Technology for Directed I/O
* VTT Memory/Power: Tracking Termination Voltage
* vUART - Virtual UART
## W
## W
@ -988,8 +1105,11 @@ Spec](https://uefi.org/specifications) for details, or run the tool
devices that open 360 degrees, or on the outside of the cover. For
devices that open 360 degrees, or on the outside of the cover. For
tablets, it's on the the side away from the screen.
tablets, it's on the the side away from the screen.
Prior to building coreboot the following files are required:
#### StarBook series:
* Intel Flash Descriptor file (descriptor.bin)
* Intel Management Engine firmware (me.bin)
* ITE Embedded Controller firmware (ec.bin)
#### StarLite series:
* Intel Flash Descriptor file (descriptor.bin)
* IFWI Image (ifwi.rom)
The files listed below are optional:
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
These files exist in the correct location in the [StarLabsLtd/blobs](https://github.com/StarLabsLtd/blobs) repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
### Build
The following commands will build a working image, where the last two words represent the
series and processor i.e. `lite_glkr`:
```bash
make distclean
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_starbook_adl
Please follow the [Star Labs build instructions](common/building.md) to build coreboot, using `config.starlabs_lite_glk` as config file.
Prior to building coreboot the following files are required:
* Intel Flash Descriptor file (descriptor.bin)
* Intel Management Engine firmware (me.bin)
* ITE Embedded Controller firmware (ec.bin)
The files listed below are optional:
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
### Build
The following commands will build a working image:
```bash
make distclean
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_lite_glk
make
```
## Flashing coreboot
## Flashing coreboot
@ -79,5 +59,6 @@ make
+---------------------+------------+
+---------------------+------------+
| External flashing | yes |
| External flashing | yes |
+---------------------+------------+
+---------------------+------------+
```
Please see [here](../common/flashing.md) for instructions on how to flash with fwupd.
Please see [here](common/flashing.md) for instructions on how to flash with fwupd.
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.
