| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds new ISH PCI device IDs for Intel PTL-U and PTL-H.
Additionally, updates the ISH driver's `pci_device_ids` list to
include these new IDs.
Source: Intel PTL-EDS vol 1. Document Number 815002, Rev 0.51 Chapter 2
BUG=b:347669091
TEST=Able to build google/fatcat.
Change-Id: I280cfdb50e8d453e957cb4bccff3a7ee2fb3bd10
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83505
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
Change-Id: Ib757c0548f6f643747ba8d70228b3d6dfa5182cd
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82752
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch skips the ISH firmware version print when CSE sync is done
by payload. The payload is responsible to dump the ISH version as
ISH version resides into the CSE boot partition table.
BUG=b:305898363
TEST=Able to build google/rex.
Change-Id: I1895a4d3c44838a9cc6380912f09aa4f0e6687bd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
EnableMultiPhaseSiliconInit upd is deprecated and has been
removed starting with v2.4 of FSP specification. Multi-phase
silicon initialization is mandatory for all FSP implementations
compliant to v2.4.
The following modifications are made:
- In fsp_params.c and silicon_init.c EnableMultiPhaseSiliconInit
update is guarded so that it will get included only if FSP2.4
is not selected.
BUG=b:329034258
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Icdbf3bacc0a05975fc941b264fd400d74f506fce
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
|
|
Change-Id: I9ed1a82fcd3fc29124ddc406592bd45dc84d4628
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
|
|
<stdio.h> header is used for input/output operations (such as printf,
scanf, fopen, etc.). Although some input/output functions can manipulate
strings, they do not need to directly include <string.h> because they
are declared independently.
Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Reference:
Panther Lake External Design Specification Volume 0.51 (815002)
BUG=b:329787286
TEST=verified on Panther Lake Simics Platform.
Change-Id: I941d6e1c8a697234b8e64a2523e60587897d7f7a
Signed-off-by: Saurabh Mishra <mishra.saurabh@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81848
Reviewed-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Included <efi/efi_datatype.h> to address coreboot style header
definitions rather using EDK2 header <Base.h>.
TEST=Able to build google/rex0.
Change-Id: I66559872c8d137d1baef5860fb98cad2a5214368
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82265
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Copy ACPI _PLD values from USB ports to corresponding USB muxes so that
the kernel can create symlinks between Type C connectors and
corresponding USB muxes. This symlink will be used to let userspace be
able to modify the USB role without knowing ACPI topology for the
device.
BUG=b:121287022 b:329657774
TEST=emerge-${BOARD} coreboot then check ACPI table on DUT
Change-Id: If27042cc995ef188f8a3e31444e994318ff98803
Signed-off-by: Won Chung <wonchung@google.com>
Tested-by: Emilie Roberts <hadrosaur@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81089
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Emilie Roberts <hadrosaur@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Required in SSDB for Windows drivers. Tested on google/brya (kano)
and verified Intel Webcam shows up to Windows as a camera source
Change-Id: Id6089f6bd841333882e28de9307fe5e48e368d02
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82068
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Sets`PLATFORM_USES_FSP2_X86_32' to `n' by default if FSP 2.4 is
enabled as 64-bits FSP should be norm moving forward.
BUG=b:329034258
TEST=verified on Lunar Lake RVP board (lnlrvp)
Change-Id: If0397f5cc8d0f4f1872bd37a001fe42e0c37ec98
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80323
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
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>
|
|
Same fsp_header struture is being used for x64 and x32 modes
and hence dropping the x64 assertion.
BUG=b:329034258
TEST=Verified on Meteor Lake board (Rex)
Change-Id: I6013af342670e6377a3fe7641d7d9b52c9b6f57c
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81662
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Usha P <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
- 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>
|
|
FSP 2.4 brings FSP 64-bits support which requires some adjustments in
coreboot:
FSP/UEFI uses the Microsoft x64 calling convention. Appropriate
attribute has to be set to all functions calling or called by
the FSP.
BUG=b:329034258
TEST=verified on Lunar Lake RVP board (lnlrvp)
Change-Id: If0397f5cc8d0f4f1872bd37a001fe42e0c37ec99
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
|
|
This patch introduces fsp print helper macros to print
`efi_return_status_t' with the appropriate format. These macros
are now used for fsp debug prints with return status
efi_return_status_t is defined as UINT64 or UNIT32 based on the
selected architecture
BUG=b:329034258
TEST=Verified on Meteor Lake board (Rex)
Change-Id: If6342c4d40c76b702351070e424797c21138a4a9
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81630
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<device/device.h> is supposed to provide <device/{path,resource}.h>
Change-Id: I2ef82c8fe30b1c1399a9f85c1734ce8ba16a1f88
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
Change-Id: I46a362270f69d0a4a28e5bb9c954f34d632815ff
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Replace fixed-width integers for pointers and sizes with uintptr_t and
size_t, promoting portability across 32-bit and 64-bit architectures.
For FSP-API specific UPD assignments, rely on `efi_uintn_t` rather
fixed size datatype uint32_t/uint64_t.
BUG=b:242829490
TEST=Firmware splash screen visible on google/rex0 w/ both 32-bit and
64-bit compilation.
Change-Id: Iab5c612e0640441a2a10e77949416de2afdb8985
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81615
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
|
|
This refactoring ensures bmp_load_logo() takes logo_size as an
argument, returning a valid logo_ptr only if logo_size is non-zero.
This prevents potential errors from mismatched size assumption.
BUG=b:242829490
TEST=google/rex0 builds successfully.
Change-Id: I14bc54670a67980ec93bc366b274832d1f959e50
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81618
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Call into FSP-T using the protected mode wrapper
and enter long mode in FSP-T support assembly code.
TEST: Booted on ibm/sbp1 in long mode.
Change-Id: Id6b9780b06b4bfbb952e32091ffbf3d0014f2090
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81281
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Ensures the FSP debug handler adheres to the EFI calling convention,
enabling seamless integration with coreboot infrastructure.
This is critical for 64-bit coreboot and FSP communications.
BUG=b:242829490
TEST=FSP debug logs successfully captured via coreboot event handler.
Change-Id: I9085a6c7d50e58fb56cbbc61da3a0af094d0dc05
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
|
|
This patch replaces UINT8 with uint8_t to align with coreboot's
standard data type conventions.
This promotes consistency within the codebase.
BUG=b:242829490
TEST=Verified firmware splash screen functionality on google/rex0.
Change-Id: I524bf6dc83e4330f155e21691f6b161643f29bd8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81571
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
fsp_mrc_version() function does not need to perform a CBFS access to
to get an address to the FSP-M blob as the caller,
do_fsp_memory_init(), already has it loaded. In addition to make the
code simpler, it avoids an unnecessary decompression of the FSP blob
if `FSP_COMPRESS_FSP_M_LZ4' or `FSP_COMPRESS_FSP_M_LZMA' are set.
TEST=Verified on Meteor Lake rex
Change-Id: If355b5811a09a0b76acc8a297db719d54caedc54
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81256
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
|
|
When the concerned chip.h file is included in a source file, it causes
compilation error saying unknown type name bool. Fix it by including the
stdbool.h file in the chip.h file.
BUG=None
TEST=Build Brox by including the chip.h file in one of the source files.
Change-Id: I4159e2c281c3e89dc45555ce38ad8637a3bf8587
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
|
|
After final production, it's possible by setting particular
bit using DCFG the OEM/ODM locks down thermal tuning beyond
what is usually done on the given platform.
In that case user space calibration tools should not try
to adjust the thermal configuration of the system.
By adding new DCFG (Device Configuration) it allows the
OEM/ODM to control this thermal tuning mechanism. They can
configure it by adding dcfg config under overridetree.cb file.
The default value for all bits is 0 to ensure default behavior
and backwards compatibility.
For an example if Bit 0 being set represents Generic DTT UI
access control is disabled and Bit 2 being set represents DTT
shell access control is disabled.
Each bit represents different configuration access control
for DTT as per BIOS specification document #640237.
It also gives the provision for user space to check the current
mode. This mode value is based on BIOS specification document
number #640237.
BUG=b:272382080
TEST=Build, boot on rex board and dump SSDT to check DCFG value.
Also, verified the newly added sysfs attribute "production_mode"
present under /sys/bus/platform/devices/INTC1042:00 path.
Change-Id: I507c4d6eee565d39b2f42950d888d110ab94de64
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78386
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There are 2 ways of referring to linker symbols, as extern
u8[] or extern u8*. Only the former will be correctly
initiated into an immediate operand (a constant) to asm.
DECLARE_REGION defines reference in form of extern u8[].
Use DECLARE_REGION as a standard way for these references.
TEST=intel/archercity CRB
Change-Id: I5f7d7855592d99b074f7ef49c285a13f8105f089
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81097
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
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>
|
|
This patch moves commonlib/stdlib.h -> commonlib/bsd/stdlib.h, since
all code is BSD licensed anyway.
It also moves some code from libpayloads stdlib.h to
commonlib/bsd/stdlib.h so that it can be shared with coreboot. This is
useful for a subsequent commit that adds devicetree.c into commonlib.
Also we don't support DMA on arm platforms in coreboot (only libpayload)
therefore `dma_malloc()` has been removed and `dma_coherent()` has been
moved to architecture specific functions. Any architecture that tries to
use `dma_coherent()` now will get a compile time error. In order to not
break current platforms like mb/google/herobrine which make use of the
commonlib/storage/sdhci.c controller which in turn uses `dma_coherent` a
stub has been added to arch/arm64/dma.c.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I3a7ab0d1ddcc7ce9af121a61b4d4eafc9e563a8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77969
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
FSP can also make use of Multi-Processor services during its
multi-phase stages. If `USE_INTEL_FSP_MP_INIT' is set and
`USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI' unset coreboot cannot
take MP ownership as FSP-S may still use EDK2 MP services
concurrently.
TEST=verified on Lunar Lake RVP board (lnlrvp)
Change-Id: If0397f5cc8d0f4f1872bd37a001fe42e0c37ec92
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80691
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Intel Firmware Support Package 2.4 specification (document 736809)
brings some significant changes compared to version 2.3 (document
644852):
1. It supports FSP-M multi-phase init. Some fields have been added to
the FSP header data structure for this purpose.
2. The `FSPM_ARCH2_UPD' and `FSPS_ARCH2_UPD' data structures must be
used in place of `FSPM_ARCH_UPD' and `FSPS_ARCH_UPD' respectively.
3. It support 64-bits FSP but 64-bits support will be provided by
subsequent patch.
Note that similarly to what is done for silicon initialization,
timestamps and post-codes are used during the memory initialization
multi-phase.
[736809]
https://cdrdv2-public.intel.com/736809/736809_FSP_EAS_v2.4_Errata_A.pdf
[644852]
https://cdrdv2-public.intel.com/644852/644852_2.3_Firmware-Support-Package-External-Architecture-Specification.pdf
TEST=verified on Lunar Lake RVP board (lnlrvp)
Change-Id: I1c24d26e105c3dcbd9cca0e7197ab1362344aa97
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
|
|
The `platform_fsp_multi_phase_init_cb' callback is specific to FSP-S,
let's rename it 'platform_fsp_silicon_multi_phase_init_cb' to avoid
any confusion.
Change-Id: I86b69e2069f08023e6f48464f6df4593710aa9ee
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Starting with Intel CPX there is a bug in the reference code during
the Pipe init. This code synchronises the CAR between sockets in FSP-M.
This code implicitly assumes that the FSP heap is right above the
RC heap, where both of them are located at the bottom part of CAR.
Work around this issue by making that implicit assumption done in FSP
explicit in the coreboot linker script and allocation.
TEST=intel/archercity CRB
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Change-Id: I38a4f4b7470556e528a1672044c31f8bd92887d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80579
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
|
|
Explicitly specifying the aspect `Side_Effects' is necessary for GCC
toolchains from 14.0 on. As older toolchains don't know the aspect,
we have to silence a warning about it, though.
Change-Id: I1eb879f57437587dc11d879fcc4042a70d384786
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80616
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ib27894f0f1e03501583fffb2c759b493d6a7b945
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80588
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ifa5c89aad7d0538c556665f8b4372e44cf593822
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80433
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This is just a clean-up commit.
Change-Id: If0397f5cc8d0f4f1872bd37a001fe42e0c37ec97
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80302
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@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>
|
|
Commit d25277666829 ("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 renames bus to upstream and link_list to downstream.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
Added Lunar Lake device IDs the device specific functions
Reference:
Lunar Lake External Design Specification Volume 1 (734362)
Change-Id: Id31d567287b9921d60909b1eb617c7cfaf6672c9
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Saurabh Mishra <mishra.saurabh@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.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: 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>
|
|
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>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I3bb71da8ea47f7365ae3895f5477f2a765256e3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
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>
|
|
This patch implements debug logging to aid debugging and
analysis of Firmware Splash Screen feature behavior.
BUG=b:284799726
BRANCH=firmware-rex-15709.B
TEST=Able to build and boot google/screebo and check the
FW splash screen state.
[DEBUG] Firmware Splash Screen : Enabled
Change-Id: I1ec7badf620e8dbe3d48674d93d640161de6a830
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paz Zcharya <pazz@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
This updates all warnings currently being printed under the files_added
and build_complete targets to the show_notices target.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia14d790dd377f2892f047059b6d24e5b5c5ea823
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79423
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Thanks to x86 CBFS cache support, we can leverage cbfs_map() function
to load the VBT binary regardless of if it is compressed or not.
Change-Id: I1e37e718a71bd85b0d7dee1efc4c0391798f16f7
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Introduce Kconfig choice to pick between lzma, lz4 and no compression
at all of the VBT binary.
If VBT is needed in romstage, it can be used to set VBT lz4
compression as an alternative to enabling lzma compression support.
Indeed, the extra lzma code needed to de-compress VBT undermines the
compression size reduction between lzma and lz4.
BUG=b:279173035
TEST=Verified that vbt.bin is lz4 compressed with
VBT_CBFS_COMPRESSION_LZ4 and not compressed at all with
VBT_CBFS_COMPRESSION_NONE
Change-Id: I1df6a96c2ec122f0ef8ee6a1e96ffbd621b14941
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
Support embedding a second FSP-M/FSP-S binary for an SoC that can
select one at runtime.
Comet Lake v1 and v2 are different steppings of the same SKUs, but they
require different FSP binaries. Supporting both in a single build
requires embedding both FSPs and selecting one at runtime based on the
CPUID. This is desirable for a product that may have different CPU
steppings but is not otherwise differentiated enough for a separate
firmware build.
An SoC can select PLATFORM_USES_SECOND_FSP to indicate that two FSP-M/
FSP-S binaries are required. Implement soc_select_fsp_m_cbfs() and
soc_select_fsp_s_cbfs() to choose one based on platform-specific
criteria. For Comet Lake, the first FSP is CML v1 and the second is
CML v2, but in principle a platform could define any meaning for the
first and second FSP.
FSP-T is not affected, only one FSP-T can be embedded if FSP_CAR is
used.
Only one set of FSP headers is used, which is sufficient for Comet Lake
v1/v2; their headers are equivalent.
ADD_FSP_BINARIES, FSP_USE_REPO, and FSP_FULL_FD are supported for both
sets of FSP-S/FSP-M but cannot be configured separately, both use the
same configuration.
Change-Id: Ied4c6c49a6bdf278238272edd47a2006258be8e5
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78344
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
This patch introduces a new coreboot table entry named
"has_external_display" to understand if external display is attached.
This information is useful to prevent graceful shutdown by payload
when the LID is closed but an external display is present.
This piece of the information will be gathered by coreboot and passed
into the payload using this new entry aka external_display because
payload (i.e., deptcharge) doesn't have any other way to determine
if external display is available.
BUG=b:299137940
TEST=Able to build and boot google/rex.
w/o this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> System is powered off by depthcharge
w/ this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> Booted to OS and device is alive/usable
Change-Id: I0fa7eee4c5a50371a7a66c6ca1ac2c7d046d010b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77796
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This commit updates the port select bit definitions for the
TRANS_DDI_FUNC_CTL registers in the Intel GMA driver to accommodate
the changes introduced since TGL SoC.
Specifically, the following changes were made:
- Updated the DDI select bit definitions from 3-bits (bit 28-30) to
4-bits (bit 27-30).
- Introduces `INTEL_GMA_VERSION_2` config to accommodate the port and
pipe related differences between previous generation GMA register
(TRANS_DDI_FUNC_CTL) to the current generation GMA register.
This commit backports the change from the following upstream patch:
https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-3-
lucas.demarchi@intel.com
BUG=b:299137940
TEST=Able to build and boot google/rex.
Change-Id: I815ffa90c2e235afd70baa7e3837e1f9af89b1b0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
|
|
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
_STR should return Unicode string. From ACPI spec:
6.1.10 _STR (String)
The _STR object evaluates to an Unicode string that describes the
device or thermal zone.
BUG=NA
TEST=Check the changed _STR in SSDT to see if Unicode() macro is used
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I1f4b55a268c1dadbae456afe5821ae161b8e15a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77695
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
|
|
This adds DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC to provide
the option to load pre-production or production signed IPU FW from IPU
kernel driver.
BUG=None
TEST=Build rex and brya to check if the build passes without an
error.
Change-Id: Ib507bceb6fd85d8ed764df82db400526a10e4d6e
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77854
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I42e995952a72a23a5f3aeadf428ad13f25546854
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic52f01d1d5d86334e0fd639b968b5eed43a35f1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77633
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch refactors the existing MRC cache storing logic, which was
spread between the ROM and RAM stages, into a single early MRC cache
store stage. The only exception is when SoC user selects
FSP_NVS_DATA_POST_SILICON_INIT to store MRC cache from ramstage (after
FSP-S).
It reverts all the boot-state logic previously used to locate and store
MRC cache from NVS HOB into NVS because majority of the platform can
potentially use the early MRC cache store with improved memory caching
at the pre-RAM phase (with the ramtop implementation).
The only exception is the Xeon SP platform, which currently locates
the MRC cache post in FSP-S (at ramstage). Therefore, this patch
provides an API to the FSP 2.x silicon init code to perform late
storing of the MRC cache.
In majority cases the updated logic, the romstage (post FSP-M) will
attempt to save the MRC cache. Platform that selects
FSP_NVS_DATA_POST_SILICON_INIT config performs the same operation post
FSP-S. Depending on whether the MRC_STASH_TO_CBMEM config is
enabled, the MRC cache will either be written directly to NVRAM at the
romstage or stashed into CBMEM for a late NVRAM write at ramstage.
Below table captures the change in the boot state w/ and w/o this
patch for storing the MRC cache. Overall the goal is to ensure the
platform behavior is remain unchanged before and after this patch.
w/o this patch:
| | Save MRC | Finalize | Lock the |
| | Cache | MRC Cache | Boot Medium |
+-----------+----------------+----------------+----------------+
| MRC_WRITE | BS_OS_RESUME | BS_OS_RESUME | BS_ON_RESUME |
| NV_LATE | CHECK_ENTRY | CHECK_ENTRY | CHECK_EXIT |
+-----------+----------------+----------------+----------------+
| MRC_STASH | BS_DEV | BS_DEV | BS_DEV |
| TO_CBMEM | ENUMERATE_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
+-----------+----------------+----------------+----------------+
| FSP_NVS | BS_DEV_INIT | BS_DEV | BS_DEV |
| DATA_POST | CHIPS_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
| SILICON | | | |
| INIT | | | |
+-----------+----------------+----------------+----------------+
| Platform | BS_PRE | BS_DEV | BS_DEV |
| w/o above | DEVICE_ENTRY | ENUMERATE_EXIT | ENUMERATE_ENTRY|
| config | | | |
| (FSP 2.0 | | | |
| platforms | | | |
w/ this patch:
| | Save MRC | Finalize | Lock the |
| | Cache | MRC Cache | Boot Medium |
+-----------+----------------+----------------+----------------+
| MRC_WRITE | BS_OS_RESUME | BS_OS_RESUME | BS_ON_RESUME |
| NV_LATE | CHECK_ENTRY | CHECK_ENTRY | CHECK_EXIT |
+-----------+----------------+----------------+----------------+
| MRC_STASH | BS_DEV | BS_DEV | BS_DEV |
| TO_CBMEM | ENUMERATE_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
+-----------+----------------+----------------+----------------+
| FSP_NVS | Post FSP-S | BS_DEV | BS_DEV |
| DATA_POST | (ramstage) | ENUMERATE_EXIT | RESOURCES_ENTRY|
| SILICON | | | |
| INIT | | | |
+-----------+----------------+----------------+----------------+
| Platform | Post FSP-M | BS_DEV | BS_DEV |
| w/o above | (romstage) | ENUMERATE_EXIT | ENUMERATE_ENTRY|
| config | | | |
| (FSP 2.0 | | | |
| platforms | | | |
BUG=b:296704537
TEST=Able to build and boot google/rex without any boot time impact.
Change-Id: Id1e91d25916594f59d1e467a142f5042c6138b51
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77556
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This patch renames `SAVE_MRC_AFTER_FSPS` config to
`FSP_NVS_DATA_POST_SILICON_INIT` to highlight the violation in the Xeon
SP FSP implementation, where the FSP Silicon Init API produces
Non-Volatile Storage (NVS) instead of the FSP-Memory Init API.
According to the FSP 2.x specification (section 11.3), the FSP
populates the NVS data using the FSP_NON_VOLATILE_STORAGE_HOB and
expects the boot firmware to parse the FSP_NON_VOLATILE_STORAGE_HOB
after the FspMemoryInit() API in API mode.
However, not all Intel SoC platforms that support the FSP 2.x
specification adhere to this requirement. For example, the FSP binary
for XEON SP platform produces NVS data (aka
FSP_NON_VOLATILE_STORAGE_HOB) after the FspSiliconInit() API.
Therefore, attempting to locate NVS data after the FspMemoryInit() API
on these platforms would result in an error. The `save_mrc_data.c`
implementation provides the required hooks to locate the NVS post
FSP-Silicon Init and store into Non-Volatile Storage.
BUG=b:296704537
TEST=Able to build and boot Intel Xeon SP w/o any functional impact.
Change-Id: I815a64263fa1415bfe30bb3c1c35e4adee307e86
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
This patch adds logic for logging the FW splash screen event to
the event log.
There could be three possible scenarios as below:
1. Platform w/o FW splash screen (i.e., either HAVE_FSP_LOGO_SUPPORT
or BMP_LOGO configs not enabled)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) not
present in the event log.
39 | 2023-08-27 12:42:54-0700 | System boot | 12
40 | 2023-08-27 12:42:54-0700 | ACPI Wake | S5
41 | 2023-08-27 12:42:54-0700 | Wake Source | Power Button | 0
2. Platform w/ FW splash screen (i.e., both HAVE_FSP_LOGO_SUPPORT
and BMP_LOGO configs are enabled)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) is
enabled in the event log.
34 | 2023-08-27 12:07:29-0700 | System boot | 11
35 | 2023-08-27 12:07:29-0700 | Firmware Splash Screen | Enabled
36 | 2023-08-27 12:07:31-0700 | ACPI Wake | S5
37 | 2023-08-27 12:07:31-0700 | Wake Source | Power Button | 0
3. Failed to render FW splash screen (due to any reason if FSP failed
to render the splash screen)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) is
disabled in the event log.
43 | 2023-08-27 13:06:10-0700 | System boot | 13
44 | 2023-08-27 13:06:10-0700 | Firmware Splash Screen | Disabled
45 | 2023-08-27 13:06:11-0700 | ACPI Wake | S5
46 | 2023-08-27 13:06:11-0700 | Wake Source | Power Button | 0
BUG=b:284799726
TEST=Verify that the event shows up in the event log when the user
selects the HAVE_FSP_LOGO_SUPPORT and BMP_LOGO configs to display
the firmware splash screen.
Change-Id: Ie9e09acff5443c31b881c300134bc0bb06c490c6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Change-Id: Id7634099e40c0bf97944be124b494c41d6335ad7
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
These Kconfig options were being used basically as #define statements,
which is unnecessary. This isn't a good use of Kconfig options and would
be better just as #defines if actually needed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If987b50d8ec3bb2ab99096e5e3c325e4d90a67a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
When LZMA compression is selected, then it's not needed to check if LZ4
compression is selected in addition. So instead of handling both cases
separately, check for LZ4 only if LZMA is not selected.
This applies to the cases of both, FSP-M and FSP-S.
Change-Id: I4ea61a38baf4c29bf522a50a26c6b47292e67960
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77323
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Fix the issue by adding the "ifeq" keyword which makes the extraneous
text a correct conditional directive.
Change-Id: Id8a8aa7acfdaeb0549f417fb013b2535a7298045
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77286
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>
|
|
This patch uses the CSE firmware specific data to store Intel
ISH firmware related information. Sending an ISH partition version
information command on every boot cycle would impact the overall boot
performance.
This information is used by the auto-test framework to ensure the ISH
firmware update is proper for in-field devices.
BUG=b:285405031
TEST=Able to build and boot google/rex. Verified ISH FW version is
getting displayed across warm resets without impacting the boot time.
Change-Id: I0242c26dd90d834815799f54740d8147ff9d45b7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77176
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This patch adds a new configuration option to allow the compression
algorithm for the logo cbfs file to be specified. By default, the logo
cbfs file is compressed using LZMA. However, enabling LZ4 compression
can save ~2ms of boot time when the BMP_LOGO config is enabled.
This patch verified that the logo cbfs file can be booted using either
LZMA or LZ4 compression.
BUG=b:284799726
TEST=Able to boot google/rex and verified firmware splash screen using
either LZMA or LZ4 compression.
Change-Id: Ib0aa5320632ae3f734004d2b1d495af11c2e1928
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
This patch adds an API to convert BMP images into GOP BLT buffers for
Intel FSP-S. This is required to display the OEM splash screen at
pre-boot phase.
Previously, Intel FSP-S had provision to consume the *.BMP file as is.
However, starting with the Alder Lake platform, Intel FSP has dropped
this conversion logic and expects the boot firmware to pass the BLT
buffer directly.
This patch implements the conversion logic in coreboot.
BUG=b:284799726
TEST=Able to build and boot google/rex
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I992b45d65374f09498ff0cab497f7091e1e7a350
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
|
|
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the drivers directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8442bc18ce228eca88a084660be84bcd1c5de928
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68980
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Change-Id: I9241d713fb8cc26c768746c8e442b46292036d20
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76694
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I03c21e180e9e399e5cb451bf3b9cfb6484cab68b
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76778
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I80b4b2df4a38dcbb28d928018446e91acae90ee6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Remove BUILD_TIME_STAMP_SIZE macro from coreboot because FSP 3223
version have BUILD_TIME_STAMP_SIZE macro defined as part of
`FspProducerDataHeader.h`.
Ref change:
9c28ab1d1a vc/intel/fsp/mtl: Update header files from 3194_81 to 3223.80
BUG=b:285110116
TEST=Able to build google/rex.
Change-Id: I52707adf1aa6dadca8dcf82102f76916a0cfe346
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
|
|
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
This patch introduces CBMEM ID to store the MRC version (similar to
existing implementation that stores the FSP-M version inside CBMEM ID)
inside cbmem so the version information is available across the
different coreboot stages. For example:
* romstage: Use the CBMEM ID version information to check if the MRC
cache is valid and need to erase the MRC cache
* ramstage: Use the CBMEM ID to store the MRC cache into the
non-volatile space.
BUG=b:261689642
TEST=Able to build and boot google/rex and dump the MRC version as
below.
cbmem --list
CBMEM table of contents:
NAME ID START LENGTH
...
21. MRC VERSION 5f43524d 75ffeb60 00000004
...
localhost ~ # cbmem -r 5f43524d | hexdump
00000000 01 12 07 00
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I91f735239b33c6f8ba41c076048903e4b213c6a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75921
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch uses the "generic" variable name as "version" while storing
the MRC cache data instead referring to the FSP-M version or MRC
version. Hence, updated all the instances of `fsp_version/fspm_version`
with `version`.
Also introduces the new option to the MRC cache
version that allows SoC users to store the MRC cache version based on
the supported EDK2 version. Intel FSP built with EDK2 version 202302
onwards has support to retrieve the MRC version by directly parsing
the binary.
Additionally, added the helper function `fsp_mrc_version()` and
corresponding header file to read the MRC version from the FSP binary.
BUG=b:261689642
TEST=Able to build and boot google/rex and google/omnigul.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia8af53aed674ad4a3b426264706264df91d9c6b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75920
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
|
|
FSP performance timestamp is in nano second by default. This patch is to
correct unit in FSP performance timestamp data print and macro name to
avoid confusion.
Change-Id: I4aec4f63beddbd7ce6e8e3fc1b53a45da2ee0b00
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75816
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
This patch renames `SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION` config
to `SOC_INTEL_STORE_ISH_FW_VERSION` to ensure the usage of this config
is clear.
Any platform would like to fetch the currently running ISH firmware
version should select this configuration.
TEST=Able to build and boot google/marasov.
Change-Id: Ie503d6a5bf5bd0d3d561355b592e75b22c910bf5
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75767
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
|
|
This patch calls into fsp_get_pch_reset_status() to get the
MultiPhaseSiInit API return status if
FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN is enabled.
Ideally FSP API should be able to return the status (both success and
error code) upon exiting the FSP API but unfortunately there are some
scenarios in ADL/RPL FSP where MultiPhaseSiInit API is unable to return
any ERROR status. Hence, this function can be considered as an
additional hook to read the FSP reset status by reading the dedicated
HOB without relying on the FSP API exit status code.
Any SoC platform that selects the FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN
config will call into this newly added API to get the FSP return status
from MultiPhaseSiInit.
BUG=b:278665768
TEST=Able to select FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN for ADL/RPL SoC
code and call into this API to know the return status from
MultiPhaseSiInit FSP API.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I749c9986e17e4cbab333b29425c9a4a4ba4128fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74784
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
|
|
This patch creates a function to read the FSP API Reset Status. This
function relies on the FSP Scheduled Reset HOB which holds the reset
type (warm/cold/shutdown) information along with any platform specific
reset need (like global reset).
Ideally FSP API should be able to return the status (both success and
error code) upon exiting the FSP API but unfortunately there are some
scenarios in ADL/RPL FSP where MultiPhaseSiInit API is unable to return
any ERROR status. Hence, this function provides an additional hook to
read the FSP reset status by reading the dedicated HOB without relying
on the FSP API exit status code.
Additionally, create FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN config option
to handle broken FSP API return status issue.
Any SoC platform that selects the `FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN`
config will call into this newly added API to get the FSP return status
from MultiPhaseSiInit.
BUG=b:278665768
TEST=Able to select FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN for ADL/RPL SoC
code and call into this API to know the return status from
MultiPhaseSiInit FSP API.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ief5d79736cc11a0a31ca2889128285795f8b5aae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
|
|
Some of the chip.h files in the tree are missing the include guards.
This patch adds them in order to avoid potential redefinions of symbols
contained in these headers, when they are included multiple times in
static.c generated by sconfig.
Change-Id: I550a514e72a8dd4db602e7ceffccd81aa36446e3
Signed-off-by: Jan Samek <jan.samek@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
TEST=fsp_print_guid() output doesn't get cobbled with other serial
output and now separated by a newline character.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8d47dbc5d493f86f14a1bbcf9cb5c16c0e12b841
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74781
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
This patch creates .final hook to call into get ISH version function
if platform has required config
(`SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION`) support.
BUG=b:273661726
TEST=The ISHC version, 5.4.2.7779, was retrieved on the google/nivviks.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ib3f983d5de5b169474bcdb1e9e2934174a9dadf8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74209
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit 4dba71fd25c91a9e610287c61238a8fe24452e4e.
Add multiple fan support for dptf policies.
This also fixes the Google Meet resolution drop issue as per
b:246535768 comment#12. When system starts Google Meet video call,
it uses the hardware accelerated encoder as expected. But, as soon as
another system connects to the call, an immediate fallback is observed
from hardware to software encoder. Due to this, Google Meet resolution
dropped from 720p to 180p. This issue is observed on Alder Lake-N SoC
based fanless platforms. This same issue was not seen on fan based
systems. With the fix in dptf driver where fan configures appropriate
setting for only fan participant, not for other device participants,
able to see consistent 720p resolution.
BUG=b:246535768,b:235254828
BRANCH=None
TEST=Built and tested on Alder Lake-P Redrix system for two fans
support and on Alder Lake-N fanless systems. With this code change
Google Meet resolution drop not observed.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: Id07d279ff962253c22be9d395ed7be0d732aeaa7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73249
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now the CPU topology is filled in struct device during mp_init.
Change-Id: I7322b43f5b95dda5fbe81e7427f5269c9d6f8755
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
Use enum cb_err as return value of fsp_find_range_hob instead of using
the raw -1 and 0 values. Also update the call sites accordingly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6c9f69a886f53868f1ef543c8fa04be95381f53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The API finds the FSP resource HOB for the given GUID.
Returns the pointer to the HOB if found, otherwise NULL
Change-Id: I4ebc9b7d214e5fc731ae45f28e7f5732a7635cbc
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
|
|
This patch renames all references of `top_of_ram` (TOM) in IA common
`basecode` module (for example: functions, variables, Kconfig,
Makefile and comments) with `ramtop` aka top_of_ram to make it more
meaningful and to avoid conflicts with Intel SA chipset TOM registers.
BUG=Able to build and boot google/rex with the same ~49ms savings
in place.
Change-Id: Icfe6300a8e4c5761064537fb256cfecbe2afb2d8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73881
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a new Kconfig CONFIG_ENABLE_FSP_ERROR_INFO option to enable
retrieval of FSP_ERROR_INFO_HOB from HobList created by FSP.
Such a HOB could be generated by Intel SPR-SP FSP.
This HOB data is defined in Intel®Firmware Support Package
External Architecture Specification v2.1 Doc#611786-2.1.
Change-Id: I812d1c22c1bbe5146630948ca6ca12c46ffd5504
Signed-off-by: Ray Han Lim, Ng <ray.han.lim.ng@intel.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
This patch enables early caching of TOM region to optimize the boot
time if valid mrc cache is found (i.e. except the first boot after
flashing/updating few AP firmware image).
TEST=Able to build and boot google/rex to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia575ad0f99d5b0fd015e40b0862e8560700f6c83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
|
|
This patch updates the print msg of mrc_cache size from hex to
decimal for easier understanding while debugging the issue.
TEST=Able to build and boot google/rex.
Without this patch:
[SPEW ] MRC cache found, size ee75
With this patch:
[SPEW ] MRC cache found, size 61045 bytes
Change-Id: I69feeb36423e47a5992c9f27d9a7042803a492cd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
|
|
Using a &uint64_t as a string argument does not include the required
NULL character termination. Update the format string to only print the 8
desired characters and not continue printing stack memory until a NULL
is found.
Before:
[EMERG] Invalid UPD signature! FSP provided "AMD_01_M;....`", expected was "CEZANE_MAMD_01_M;....`".
After:
[EMERG] Invalid UPD signature! FSP provided "AMD_01_M", expected was "CEZANE_M".
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ib334daa8518a92e0cf3d22c4d95908f4c84afe04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72911
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
<device/pci.h> chain-includes <device/pci_def.h> & <device/pci_type.h>.
Change-Id: I4e5999443e81ee1c4b1fd69942050b47f21f42f8
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72626
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
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 Alder Lake PEIM graphics driver executed as part of the FSP does
not wait for the panel power cycle to complete before it initializes
communication with the display. It can result in AUX channel
communication time out and PEIM graphics driver failing to bring up
graphics.
If we have performed some graphics operation in romstage, it is
possible that a panel power cycle is still in progress. To prevent any
issue with the PEIM graphics driver it is preferable to ensure that
panel power cycle is complete.
This patch replaces commit ba2cef5b5493
("soc/intel/common/block/early_graphics: Introduce a 200 ms delay")
workaround patch.
BUG=b:264526798
BRANCH=firmware-brya-14505.B
TEST=Developer screen is visible in the recovery flow
Change-Id: Iadd6c9552b184f7d6ec8df9d0d392634864ba50b
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72419
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
|
|
We were using the libgfxinit `Initialize' function with the
`Clean_State' parameter because the more appropriate `Update_Output'
function was not performing all the necessary clean up operations for
the PEIM driver to be successful when libgfxinit was used in romstage.
Thanks to a lot of experiments and some log analysis efforts, we were
able to identify the missing operation and fix the `Update_Output'
function (cf. https://review.coreboot.org/c/libgfxinit/+/72123).
The `initialized' global variable is now unnecessary as we track the
initialization in the Ada code instead.
Since the `Update_Output' function does not return any value, this
patch modifies the `gma_gfxstop' prototype accordingly. This does not
have any impact as the return value was not used anyway.
BUG=b:264526798
BRANCH=firmware-brya-14505.B
TEST=Developer screen is visible
Change-Id: I53d6fadf65dc09bd984de96edb4c1f15b64aeed0
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72125
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
|
|
This patch restricts the dump of the vebose graphics output settings
to configuration with the `DEBUG_ADA_CODE' flag set.
BUG=b:264526798
BRANCH=firmware-brya-14505.B
TEST=Configuration dump is seen only if DEBUG_ADA_CODE is set
Change-Id: Iadd6c9552b184f7d6ec8df9d0d392634864ba50c
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72418
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
|
|
Change-Id: Ifab3fcd2de8f0c1672d1a9a21c8e0c5dba5b7443
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72077
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
