Correct .UserBd field to BOARD_TYPE_ULT_ULX from BOARD_TYPE_MOBILE. This
is from Intel's guidance for MRC to map the memory speed to proper POR
number.
BUG=b:332980211
BRANCH=brya
TEST=Built and compare the results of command 'dmidecode -t 17'
[Before]
(Same values in all of memory device handle)
Speed: 6400 MT/s
Configured Memory Speed: 6400 MT/s
[After]
(Same values in all of memory device handle)
Speed: 5200 MT/s
Configured Memory Speed: 5200 MT/s
Change-Id: Id16bcbc2d0cb4c2cf3008cf2ef1027ed98e93afb
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Chen <jamie.chen@intel.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
bmp_load_logo() loads the custom logo.bmp file into CBMEM. This cbmem
buffer is released after FSP-S init is complete. In certain platforms,
the logo file is displayed during PCI enumeration. This means the logo
buffer is used after it is released. Fix this issue by releasing the
logo buffer when the coreboot has finished loading payload. During S3
scenario CBMEM is locked, bmp logo is not loaded and hence the release
is a no-op.
BUG=b:337144954
TEST=Build Skyrim BIOS Image and boot to OS. Ensure that the chromeOS
boot logo is seen without any corruption.
Change-Id: Id27cf02de04055075e7c1cb0ae531dee8524f828
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82121
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Integrated Boot Logic (IBL) codes doesn't support bootloader
controlled Primary-to-Sideband Bridge (P2SB) hidden and unhidden.
Hence, dynamically read IBL HPET/IOAPIC Bus:Device.Function (BDF)
by bootloader is not supported, because when P2SB is hidden the
register access is denied.
TEST=Build and boot on intel/archercity CRB
TEST=Build on intel/avenuecity CRB
TEST=Build on intel/beechnutcity CRB
Change-Id: I3975cb00e215c4984c63bb8510e8aef7d4cc85a4
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81321
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configuration variable implementation (VPD, et al) is regarded to
be mainboard specific and should not be bounded to SoC codes.
This patch moves the VPD based settings (FSP log level, et al)
from SoC codes to mainboard codes.
TEST=Build and boot on intel/archercity CRB with no significant log
differences
Change-Id: Iefea72eec6e52f8d1ae2d10e1edbabdebf4dff91
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82090
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Configuration variable implementation (VPD, et al) is regarded to
be mainboard specific and should not be bounded to SoC codes.
Add get_cxl_mode so that SoC codes do not need to get this
configuration from VPD any more.
TEST=Build and boot on intel/archercity CRB with no significant log
differences
Change-Id: I1e08e92ad769112d7e570ee12cf973451a3befc0
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch sets different names for different mtlrvp
variants so they can be matched properly at runtime against
unique frids (i.e. firmware read-only identifiers).
BRANCH=firmware-rex-15709.B
TEST=Verified boot functionality on intel/mtlrvp
Change-Id: I5292a0ffcd7524c55cd7aef37c2f59432b2af06a
Signed-off-by: YH Lin <yueherngl@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In NUMA architecture, all devices (cpu, memory and PCI device)
belong to specific proximity domain. Add utils to map device
instance to their proximity domain.
Proximity domain ID is the index assigned at the creation of
proximity domains. There is no hard relationship between proximity
domain ID and the device identities (e.g. socket ID). Hence we
need the map utils to explicitly link them.
For now the Sub-NUMA config isn't taken into account.
TEST=Build and boot on intel/archercity CRB
Change-Id: Icd14a98823491ccfc38473e44a26dddfbbcaa7c0
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Co-authored-by: Ziang Wang <ziang.wang@intel.com>
Co-authored-by: Gang Chen <gang.c.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81440
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add FSP 2 Multi Processor Platform Initialization module a function
indirection to ensure that efi_ap_procedure functions are called with
the appropriate C calling convention.
BUG=b:329034258
TEST=Verified both x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: I64e65b2941207375d5e27c84aa26061e7e72a7f6
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81663
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Stack alignment:
1. FSP functions must be called with the stack 16-bytes aligned
in x86_64 mode.This is already setup properly with the default
value of the `mpreferred-stack-boundary' compiler option (4).
2. The FSP heap buffer supplied by coreboot through the `StackBase'
UPD must be 16-bytes aligned. This alignment is consistent for
both x86_64 and x86_32 modes to simplify the implementation.
BUG=b:329034258
TEST=Verified on Meteor Lake board (Rex)
Change-Id: I86048c5d3623a29f17a5e492cd67568e4844589c
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81661
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Add GPP_F18 configuration in early_gpio_table.
Without this, DUT cannot get the proper state of this signal on early
phase. It allowed DUT to attempt to enter into dev mode when EC is in RW
currently, it causes the failure of autotest/firmware_DevMode.
BUG=b:337365524
TEST=built and run autotest firmware_DevMode
Change-Id: I2179bb10b431547bc35f332c74915a63495b779d
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82099
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: YH Lin <yueherngl@google.com>
GPP_D14 is floating when ISH is not being used and wasting power. Add
pulldown to prevent this from happening.
BUG=b:336654954
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
make sure OS boots up
HW team validated that power usage is 20 mW lower
Change-Id: I4e19e98fa31022ece66a47402a2a4461b430ef70
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
As described in Intel document 336464 (8th gen S series datasheet volume
1), the CPU's 4 eDP lanes can be bifurcated, so that DDI-A (eDP) ends up
with 2 lanes, and DDI-E (DP, typically used for VGA) has the remaining 2
lanes. This lets mainboards provide a VGA output without sacrificing one
of the main 4-lane DDIs. Newer platforms seem to be lacking this.
However, the way this is structured in coreboot does not allow boards to
choose whether bifurcation should be enabled. Most boards in the tree do
not use DDI-E (it doesn't exist on mobile platforms), but there are some
boards (e.g. hp/280_g2) that use DDI-E and a DP-to-VGA converter chip to
provide a VGA output.
Replace `SOC_INTEL_CONFIGURE_DDI_A_4_LANES` with two new Kconfig options
to allow boards to decide. Use `SOC_INTEL_GFX_HAVE_DDI_A_BIFURCATION` to
specify whether a platform supports DDI-A bifurcation at all (do nothing
otherwise, maintaining the original code's behaviour). If bifurcation is
supported, the `SOC_INTEL_GFX_ENABLE_DDI_E_BIFURCATION` is used to clear
or set the `DDI_A_4_LANES` bit in the `DDI_BUF_CTL_A` register.
Change-Id: I516538db77509209d371f3f49c920476e06b052f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82113
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the pad reset config for Touchpad Interrupt from PLTRST to DEEP
so that it can still act as a wake source during S3 suspend.
BUG=b:336398012
TEST=Build Brox BIOS image and boot to OS. Suspend to S3 and wakeup
using Trackpad.
246 | 2024-04-25 16:55:18-0700 | ACPI Enter | S3
247 | 2024-04-25 16:55:34-0700 | ACPI Wake | S3
248 | 2024-04-25 16:55:34-0700 | Wake Source | GPE # | 67
249 | 2024-04-25 17:00:38-0700 | ACPI Enter | S3
250 | 2024-04-25 17:00:47-0700 | ACPI Wake | S3
251 | 2024-04-25 17:00:47-0700 | Wake Source | GPE # | 67
Also suspend to S0ix and wakeup using Trackpad.
Change-Id: If1a275e42c6c7ad743eedc9cd3320776008bfd62
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
When installing the packages, apt-get returns an error about holding
broken packages. It occurs the diffutils depends on libcurl4t64
which breaks the libcurl4.
As a solution, remove the libcurl4 from the list, and let the package
manager resolve the dependencies.
TEST=Build coreboot-sdk
Change-Id: Iabc4f74619d4462317d8adb4068e50135d89d80e
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
If the TPM is not detected in the system it may mean it is inactive
due to enabled ME with active PTT. In such case, the chipset will route
the TPM traffic to PTT CRB TPM on Intel systems.
If TPM is not probed, disable the PC80 TPM device driver, so that
coreboot will not generate improper SSDT ACPI table.
Change-Id: I05972ad74a36abaafa2f17a16f09710550a3a3f3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
If CRB TPM is not detected in the system it may mean it is inactive
due to disabled or neutered ME. In such case, the chipset will route
the TPM traffic to LPC/SPI on Intel systems.
If CRB TPM is not probed, disable the CRB TPM device driver, so that
coreboot will not generate improper SMBIOS/SSDT ACPI tables.
Change-Id: Ie0928536d9042b1f680d585e1ca9ad2cadf0c8ef
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
RAMOOPS memory region was being overwritten by coreboot bmp_load_logo()
function. The CBMEM_ID_FSP_LOGO region created during bmp_load_logo()
was overlapping with RAMOOPS space created earlier. This resulted in
memory corruption of RAMOOPS buffer.
To prevent this, the RAMOOPS region allocation is moved to
BS_DEV_INIT_CHIPS phase from earlier BS_WRITE_TABLES phase of boot.
BUG=b:332910298
TEST=build and boot coreboot image on google/rex HW. Check RAMOOPS
CBMEM region creation using cbmem -l command
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ibae06362cd80eacb16f6cf0eed8c9aa1fbfb2535
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82042
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds support for the new command-line option `-c` to
the ifdtool, which is able to check GPR0 (Global Protected Range)
status.
This patch also add helper function get_enabled_gprd() to get enabled
GPR0 settings. It used in enable_gpr0() and is_gpr0_protected().
Developers can use ifdtool with '-c' option to check whether GPR0 is
set to enabled or disabled in the binary file.
BUG=none
TEST=(1) > ifdtool -p mtl -E image-unlocked.bin -O image-lock.bin
...
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
...
GPR0 protection is now enabled
(2) > ifdtool -p mtl -c image-unlocked.bin
GPR0 status: Disabled
Value at GPRD offset (64) is 0x00000000
--------- GPR0 Protected Range --------------
Start address = 0x00000000
End address = 0x00000fff
(3) > ifdtool -p mtl -c image-lock.bin
GPR0 status: Enabled
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
Change-Id: I6b3af973be784200b965a68e5f6b7737cba03ed7
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
