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>
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.]
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things.
To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others.
Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.
When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.
We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances.
For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system.
Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.
In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.
If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.
11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).
To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the library's name and an idea of what it does.
Copyright (C) year name of author
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in
the library `Frob' (a library for tweaking knobs) written
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.
