Use CPUID_ALL_STEPPINGS_MASK to only need one CPU device ID table entry
per family & model combination and not one per stepping.
TEST=Mandolin with a Picasso APU with PICASSO_B1_CPUID (0x00810f81)
still finished mpinit and boots successfully even though now only
PICASSO_B0_CPUID (0x00810f80) with CPUID_ALL_STEPPINGS_MASK specified as
device match mask. When commenting out the line with PICASSO_B0_CPUID
as a negative test, mpinit fails as expected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00ba43834ad86ecffa09d60599b17d122acd0b99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72848
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of always doing exact matches between the CPUID read in
identify_cpu and the device entries of the CPU device ID table,
offer the possibility to use a bit mask in the CPUID matching. This
allows covering all steppings of a CPU family/model with one entry and
avoids that case of a missing new stepping causing the CPUs not being
properly initialized.
Some of the CPU device ID tables can now be deduplicated using the
CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this
patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0540b514ca42591c0d3468307a82b5612585f614
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since all SoCs define the df_mmio_control union for the bits used in the
code, data_fabric_print_mmio_conf can take advantage of that and also
print a decoded version of those bits.
Output on Mandolin before the patch:
=== Data Fabric MMIO configuration registers ===
idx control base limit
0 93 fc000000 febfffff
1 93 10000000000 ffffffffffff
2 93 d0000000 f7ffffff
3 1093 fed00000 fedfffff
4 90 0 ffff
5 90 0 ffff
6 90 0 ffff
7 90 0 ffff
Output on Mandolin with the patch:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06e1d3a3e9abd664f59f2bb852394e7f723f2b30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
In contrast to Mendocino and all other AMD SoCs in the coreboot tree,
Rembrandt, on which Mendocino is based on, has a DF_MMIO_REG_SET_SIZE of
3 instead of 4, so the next data fabric MMIO register is 3 DWORDs after
the last one instead of the 4 DWORDs on the other SoCs. This was checked
against PPR #56558 Rev 3.04.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I454ad5d182f0040db93c9b3a83941333392c6061
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
To be able to handle a special case, add a per-SoC define for
DF_MMIO_REG_SET_SIZE instead of having this hard-coded as 4 in the
DF_MMIO_* macros. To avoid some duplication, also introduce the
DF_MMIO_REG_OFFSET macro.
TEST=Output from data_fabric_print_mmio_conf doesn't change on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67420a2973c8ef9a7f0ce19ddc0013de69731689
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The address mode is an internal mode which AMD FWs use. Regular
developers don't have to know that. Just report the relative address
every time. For the cases head and body are split, the address of body
is also reported.
Change-Id: I77d9aac0b3d996363341c1d2dae049ec344b39aa
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This patch adds ACPI configuration for USB2/3 ports for mtlrvp as per
schematics. This helps in generating corresponding ACPI code at runtime
that includes port information.
BUG=b:224325352
BRANCH=None
TEST=Able to build and boot MTLRVP. Connect USB device and check if
corresponding enumeration of USB device (14.0) is observed on executing
lspci.
00:14.0 USB controller: Intel Corporation Device 7e7d (rev 01)
00:14.1 USB controller: Intel Corporation Device 7e7e (rev 01)
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Ie150247661322e3944be15dc70f66033266d8aac
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72787
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch describes the TCSS USB ports for mtlrvp as per schematics.
This patch describes TCSS ports for UPC_TYPE_C_USB2_SS_SWITCH as below,
tcss_usb3_port1: USB3 Type-C Port C0
tcss_usb3_port2: USB3 Type-C Port C1
tcss_usb3_port3: USB3 Type-C Port C2
tcss_usb3_port4: USB3 Type-C Port C3
BUG=b:224325352
BRANCH=None
TEST=Able to build and boot MTLRVP to ChromeOS. Verify the enumeration
of xhci (0d.0) as part of lspci. Also verify the enumeration of Type-C
ports as part of cbmem -c.
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I0054ac4e3d1d9b97cfea615831ec8f3d3e00c9e0
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72785
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables FM350GL 5G WWAN support for mtlrvp.
BUG=b:224325352
BRANCH=None
TEST=Build and boot mtlrvp to ChromeOS. Ensure that WWAN module 00:1c.6
is enumerated as part of lspci and cbmem -c in AP console. Also verify
generation of PXSX Device as part of SSDT. Able to connect WiFi and
access internet.
cbmem -c:
\_SB.PCI0.RP07: Enable RTD3 for PCI: 00:1c.6 (Intel PCIe Runtime D3)
\_SB.PCI0.RP07: Enable WWAN for PCI: 00:1c.6 (Fibocom FM-350-GL)
SSDT:
Scope (\_SB.PCI0.RP07)
{
Device (PXSX)
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: I870cc0782fb989f1bdbe369a4a12630a62729d8e
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72779
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for samsung boards lumpy and stumpy. 0x8000 unused
flash space is allocated for RW_NVRAM.
Previously BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES was selected for
CPU_INTEL_HASWELL, CPU_INTEL_MODEL_{2065X,206AX} and others (see [2]).
However, there seems to be no particular reason on those platforms.
We've dropped the config for haswell. Now drop it for
CPU_INTEL_MODEL_{2065X,206AX}, so that VBOOT_VBNV_FLASH can be enabled.
[1] https://web.archive.org/web/20230115020833/https://issuetracker.google.com/issues/235293589?pli=1
[2] commit 6c2568f4f5
("drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config")
BUG=b:235293589
TEST=./util/abuild/abuild -a -t SAMSUNG_LUMPY -x
Change-Id: I833edd4f7a328b21e81c971ba8a9aec0aad7d3d3
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70296
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
This change adds 2 command line parameters, --skip_set and --skip_unset
that allows abuild to skip boards with particular Kconfig values either
set or not set.
Note that it only works on BOOL type variables.
This can be set on the abuild command line, or the JENKINS_ABUILD_OPT=
variable on the make command line.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I43336484cf25f83065ec7facf45c123d831024b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Since things are done a bit differently on Stoneyridge, it's probably
safer to run a test instead of assuming that the test on Picasso was
sufficient to be reasonably sure that this will also work as expected on
Stoneyridge.
TEST=No change of ACPI-related messages in dmesg with this patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I432752fae8be08d3cbd7d30215b350c4528c7206
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Create the constitution variant of the brask reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:267539938
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_CONSTITUTION
Change-Id: Idb6089561d3aa5aac4448f9d46347c731f027e9c
Signed-off-by: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72730
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of just printing the register contents, normalize the contents
of the base and limit registers to actual MMIO addresses and then print
those. This will hopefully avoid some confusion caused by the shifted
addresses.
Output on Mandolin before the patch:
=== Data Fabric MMIO configuration registers ===
Addresses are shifted to the right by 16 bits.
idx control base limit
0 93 fc00 febf
1 93 1000000 ffffffff
2 93 d000 f7ff
3 1093 fed0 fedf
4 90 0 0
5 90 0 0
6 90 0 0
7 90 0 0
Output on Mandolin after the patch:
=== Data Fabric MMIO configuration registers ===
idx control base limit
0 93 fc000000 febfffff
1 93 10000000000 ffffffffffff
2 93 d0000000 f7ffffff
3 1093 fed00000 fedfffff
4 90 0 ffff
5 90 0 ffff
6 90 0 ffff
7 90 0 ffff
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I62eeb88ddac6a7a421fccc8e433523459117976a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This moves the definition for POST_BOOTBLOCK_CAR from the intel-specific
postcodes into the common postcode list, and uses it for the
cache-as-RAM init as needed.
Because POST_BOOTBLOCK_CAR was set to 0x20 in some spots and 0x21 in
most of the others, the values were consolidated into 0x21. This will
change the value on some platforms.
Any conflicts should get sorted out later in the conversion process.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8527334e679a23006b77a5645f919aea76dd4926
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch enables PCIe port for WWAN as per mtlrvp schematics
BUG=b:224325352
BRANCH=None
TEST=Build and boot mtlrvp to ChromeOS. Ensure that WWAN module
gets enumerated with cbmem -c.
\_SB.PCI0.RP07: Enable RTD3 for PCI: 00:1c.6 (Intel PCIe Runtime D3)
\_SB.PCI0.RP07: Enable WWAN for PCI: 00:1c.6 (Fibocom FM-350-GL)
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: Ib372db9642a3c7b3a21a112fa0e6e0b4bc88a9ea
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72777
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Mendocino SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1ed0407826f579eb14169246b7b14ba677c20e8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Cezanne SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6953da5e0f1966aa3022364d9a9c72ebafc698cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Picasso SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia265f3eebf5e48c185d2e4bf4ef74f8eab7c9606
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
