It should be PSP_RIB_FILE which is already there.
Change-Id: Ie7471489bd34554e357510b04473102d002f9988
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72506
Reviewed-by: ritul guru <ritul.bits@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently there is a problem, where two Displayports are not working. To
be precise: TCP0 and TCP1 (Type-C Port 0/1) are not working.
Setting the lane count of the TCP0 and TCP1 to x1 works fine.
Setting the lane count of the TCP0 and TCP1 to x2 does not work.
Setting the lane count of the TCP0 and TCP1 to x4 does not work.
The reason for that is currently unknown.
This change sets the lane count of the TCP0 and TCP1 Port to x1 length
in the VBT binary.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I182b528275152bf5adcb01a56816afd65674aed3
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72610
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch updates the print message to start with uppercase, 'board'
to 'Board'.
BUG=b:224325352
BRANCH=None
TEST=Able to observe proper print message when invalid board id is
configured.
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Ie82df940cbd1eba9c5d485b48648c2bc8f234aae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72638
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Markdown does not render newlines unless there is an empty line in
between the lines of text. Several command examples and a list were
missing these empty lines, causing their content to be rendered inline
with the preceding text.
Fix this by adding triple backticks around code blocks and bullet points
to rows of text in a list.
Change-Id: I9c1d2b81acdeb378346c68bced0cdbfeeb81bf26
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72625
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In CB:71614 Kyösti pointed out that ACPI_GPE0_BLK is the wrong address
to assign to proc_blk_addr; the correct one would be ACPI_CPU_CONTROL.
When looking a bit closer into this, it turned out that
acpigen_write_processor is generating deprecated AML opcodes, so replace
the acpigen_write_processor call with a call to the newly added
acpigen_write_processor_device function that also doesn't have the
proc_blk_addr and proc_blk_len parameters. The information about the IO
port for entering C-states is already written into an SSDT by
acpigen_write_CST_package which is likely also the reason why the wrong
proc_blk_addr value wasn't noticed for a very long time.
TEST=Mandolin still boots Ubuntu 22.04 LTS and Windows 10 and no
possibly related errors show up. Linux gets the expected C-state
information from the _CST package inside the processor device scope.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie67416e19e431029dd12da66ad44ddfa8586df03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The ACPI PROCESSOR_OP has been deprecated in ACPI 6.0 and dropped in
ACPI 6.4 and is now permanently reserved. As a replacement, DEVICE_OP
with the special HID ACPI0007 should be used instead. This special HID
was introduced in version 3 of the ACPI spec. To have a function to
generate this, acpigen_write_processor_device is introduced. The CPU
index is used as UID which can be assumed to be unique.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifb0da903a972be134bb3b9071f81b441f60917d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72469
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Follow thermal team's request on b/248086651 comment#27. Update the
thermal table setting for each mode and the conditions of temperature
switching.
BUG=b:248086651
TEST=emerge-skyrim coreboot
Change-Id: Ida10d9b10c33dea11440879afda07c04c1eccb9f
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
This register isn't used in coreboot and isn't defined in the Picasso
PPR #55570 Rev 3.18.
To enter a lower C-state, a read request to a special IO port is done.
The base address of this group of IO ports is configured in
set_cstate_io_addr via the MSR_CSTATE_ADDRESS and that read won't leave
the CPU. IIRC trying to put the MMIO mapping for entering the lower
C-states into the _CST package didn't work as expected when it was tried
on I think Cezanne.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib189993879feaa0a22f6810c4bd5c1a0bc8c5a27
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This patch moves ME host firmware status register structures to ME
header file. It also marks unused structure fields to reserved.
The idea here is to decouple ME specification defined structures from
the source file `.c` and keep those into header files so that in future
those spec defined header can move into common code.
The current and future SoC platform will be able to select the correct
ME spec header based on the applicable config. It might be also
beneficial if two different SoC platforms would like to use the same
ME specification and not necessarily share the same SoC directory.
BUG=b:260309647
Test=Able to build and boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I7dfd331e70f6d03c88248ca5147dbe6785a8e69d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
It turns out that the [0xfa000000-0xfaffffff] range conflicts with
some North TraceHub address space ranges ([0xfad00000-0xfadfffff] and
[0xfacfc000-0xfacfffff]).
Experiments have established that this conflicting range results in an
unpected PIPE A underrun issue reported by i915 and some visible
flickers on the display during boot.
The [0xf0000000-0xffffffff] range is a crowded memory space with
resources statically assigned to some devices but also some ranges
used at various point in the boot flow by the FSP.
To not run into any other potential conflicts, we want to pick a
unused memory space. But at this early stage of the boot, we do not
have full knowledge of what memory space is going to be used by the
FSP. As a result, we decided to pick the [0xaf000000-0xafffffff] range
as:
1. It does not conflicting with any coreboot memory space usage
2. It is the address the FSP uses by default for GFX MMIO BAR0 and as
such should not conflict with any FSP memory space usage.
BUG=b:264648959
BRANCH=firmware-brya-14505.B
TEST=No flickers observed on boot
Change-Id: I6a00350ff4007bb7692d2ff6598b946cc6123302
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72605
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Useful to see which architecture x86_32 or x86_64 coreboot was built for.
Change-Id: I34eec64ac32254c270dcbb97e20a7e6be0f478fc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
This fixes a NULL pointer deref introduced by 69cd729 (mb/*: Remove
lapic from devicetree).
Change-Id: I816fddfe3efe3c3aefe1b2ee28426dc1e1f3c962
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72599
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This is all handled at runtime now, so there is no need to have the
ability to statically add lapics to the devicetree.
Change-Id: I0746eb808a2956ac75f76c8189a9ecf190e33ce9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69378
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Functionality wise nothing changed, except that the first misspellings
caused SBOM_BIOS_ACM_PATH and SBOM_SINIT_ACM_PATH to not work before.
- Fix misspelling of CONFIG_BIOS_ACM_PATH -> CONFIG_SBOM_BIOS_ACM_PATH
- Fix misspelling of CONFIG_SINIT_ACM_PATH -> CONFIG_SBOM_SINIT_ACM_PATH
- Put SBOM_COMPILER_ handling into Kconfig instead of Makefile
- Reorder CONFIG_ paths (for readablity)
- Add in code comments (for readablity)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If67bc3bd0d330b9b5f083edc4d1697e92ace1ea0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The LPC BIOS decode lock bit is defined in EBG EDS documentation.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I60df7e6da2b22b8eeb2094aeb5ee9667043bb30b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71954
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
"\" is missing at the end of CC line for build_NASM.
Change-Id: Ic29ee731def31f958f939efe19bdb55b503eb6ba
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This uses a simpler form of #if to check if CONFIG_SAVE_MRC_AFTER_FSPS
is enabled, referencing the Kconfig variable only once and defaulting
to the original behavior if not.
Change-Id: I4711c1474d9a3a5c685dd31561619c568fab075c
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72587
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The variables defined in this defconfig are incorrectly named, therefore
fix them.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I9299be96f8c44d6a87d380f4f942c4d26af7050d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Since the PSE GBE0 MAC has been disabled on this board in
commit 343644006f ("mb/siemens/mc_ehl3/devicetree.cb:
Remove TSN GbE 0"), therefore disable the corresponding
GPIOs as well.
BUG=none
TEST=Test link detection and IP assignment on the remaining
ports (PSE GBE1 and PCH GBE0) of mc_ehl3.
Change-Id: Ifa055f58894688471d68b9b93fcb994fdcb2a568
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72449
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The parallel mp code picks up lapics at runtime, so remove it from all
devicetrees that use this codebase.
Change-Id: I5258a769c0f0ee4bbc4facc19737eed187b68c73
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69303
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch adds initial romstage code and spd data for LP5 memory
parts for MTL-RVP. This also configures memory based on the board id.
Memory - x32 LPDDR5
Vendor/Model - Micron/MT62F2G32D8DR-031 WT:B
Board ID -
0b0000 - Empty spd hex file
0b0001 - DDR5 (Empty spd hex file)
0b0010 - LPDDR5 (MT62F2G32D8DR-031 WT:B)
BUG=b:224325352
TEST=Able to boot intel/mtlrvp (LP5 SKU) to ChromeOS
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Change-Id: I15b352eb246aed23da273e56490c7094eae9d176
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch selects USE_UNIFIED_AP_FIRMWARE_FOR_UFS_AND_NON_UFS for
Google/Marasov variant which intends to achieve a unified AP firmware
image across UFS and non-UFS skus.
Note: Enabling this config would introduce an additional warm reset
during the cold-reset scenarios due to the function disabling of the
UFS controller as results we are expecting ~300ms higher boot time
(which might not be user visible because `cbmem -t` can't include
impacted boot time due to in-between resets).
BUG=b:264838335
TEST=Able to enter S0ix on Marasov NVMe sku after disabling UFS
during boot path.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie8b8814cdb5e0d97a382cebfe82868ada5762341
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Intel SPR-SP processor has socket type as
PROCESSOR_UPGRADE_SOCKET_LGA4677 which is different
from the socket type of CPX-SP and SKX-SP.
Change-Id: Id2279cc0c1fa3f007d7c081af6f78e5aa98d2f3d
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Signed-off-by: David Hendricks <ddaveh@amazon.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71947
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that we support >1 Xeon-SP, XEON_SP_COMMON_BASE no longer
reflects the socket type. This uses SOC_INTEL_* Kconfig variables and
returns the correct socket type for Cooper Lake-SP.
Signed-off-by: David Hendricks <ddaveh@amazon.com>
Change-Id: I142de5f040f3b76e352f27c00fe9e50787df5712
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When Kconfig SAVE_MRC_AFTER_FSPS is selected, save MRC training
data after FSP-S instead of FSP-M. For now only SPR-SP server
FSP supports this.
This issue surfaces with SPR-SP, because of the memory type
(DDR5 support) and memory capacity (more memory controllers, bigger
DRAM capacity). Therefore Intel decided to save MRC training data after
FSP-S with SPR-SP FSP.
Change-Id: I3bab0c5004e717e842b484c89187e8c0b9c2b3eb
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71950
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PMC registers are quite different between LBG and EBG. Move pmc.h
to lbg directory to differentiate.
Change-Id: I6f14059942210c222631e11cced0b5c05d3c1dc6
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: David Hendricks <ddaveh@amazon.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72399
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This functionality is used in multiple places, so factor it out into a
function. Compared to acpigen_write_processor_cnot, the buffer size is
decreased from 40 to 16 bytes, but the format string specified by
CONFIG_ACPI_CPU_STRING results in 9 chars and a NULL byte which will fit
into the buffer without any issue. I've seen the CPU devices being put
into another scope within \_SB, but even in that case that would be 14
chars and a NULL byte whist still fits into the 16 byte buffer. For
acpigen_write_processor and acpigen_write_processor_package this doesn't
change any edge case behavior. In the unrealistic case of the format
string resulting in a longer CPU device string, this would have been a
problem before this patch too.
Also drop the curly braces of the for loop in
acpigen_write_processor_package. This makes the code a bit harder to
read and isn't a very good idea, but with the curly braces in place, the
linter breaks the build :(
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5d8291a2aaae2011cb185d72c7f7864b6e2220ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72452
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
ACPI_CPU_STRING specifies the format string for the scope of the
processor devices in the generated ACPI code. Also point out that the
resulting string will be truncated to at most 15 chars to fit into the
16 byte buffer used in two functions in acpigen.c.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1fb1db8adeecd783c835a500d28a13b823cda155
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72451
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Not all Chrome-EC devices have a keyboard or use Vivaldi for key
remapping, so demote the printk output when the EC doesn't support
it from ERROR to INFO. Adjust the printk text for clarity.
Change-Id: I14059f4e3e56ff891f302601d5acc1bb842cffc1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72474
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The comment in the header amdfwtool.c was written long time ago and is
needed to get updated.
Change-Id: I6f64c9a240503f9d0bf240916c1066944fa39d27
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55602
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The current CMOS option causes Linux to not boot, as the GRUB EFI
loader will report an incorrect parameter.
Update the CMOS option so that the corresponding UPD is changed when
the wireless is set to disable, so that the root port for the wireless
is also disabled.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I607d700319d6a58618ec95b3440e695c82dff196
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71896
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change the Type-C USB 2.0 interface to a standard port, as the
Type-C macro will not work in Linux (dmesg says the cable is
faulty),
This makes the port work reliably in Linux, tested with:
* Manjaro 21
* Ubuntu 22.04
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I6dbf31b6e4603685297e9e5203b0db6ac1b9e24a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72387
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Zheng Bao