This patch drops the SoC specific implementation as DPTF driver can
now fillin those platform specific data using SoC specific macros.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: If65976f15374ba2410b537b1646ce466ba02969b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch fills in a generic platform info structure based on the
inputs from the SoC dptf header file (soc/dptf.h).
It will help to make things common and drop unnecessary back and
forth call between common code and SoC code.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3521882495485cef686655abd65337515bae5faa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71111
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<commonlib/bsd/compiler.h> is automatically included in all
compilation units by the build system.
(see Documentation/contributing/coding_style.md)
Change-Id: I09ed0c5eb2054c3add026f200c0fd3f609f73197
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67905
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds config to let SoC users (config) to choose if EISA HID
is supported. All SoC config would like to support EISA HID need to
select `HAVE_DPTF_EISA_HID` config.
Prior to Tiger Lake, all DPTF devices used 7-character EISA
IDs. If selected, the 7-character _HIDs will be emitted,
otherwise, it will use the "new" style, which are regular
8-character _HIDs.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6bf64f74c447b28665d31a64181c33df882d5d06
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71108
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch makes the SoC specific callback code more readable by adding
`soc_` prefix into the `get_dptf_platform_info()`.
In nutshell this patch renames `get_dptf_platform_info()` to
`soc_get_dptf_platform_info()`.
TEST=Able to build Google/Rex without any compilation issue.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I27d6a146d5928e1742f82f85f51ad42656f46344
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
This patch implements mps2_noop_get_number_of_processors() API with
minimal information required for Intel MTL FSP to utilise the
`MP_SERVICES_PPI_V2_NOOP` config.
The major difference between Intel ADL and MTL FSP in terms of doing
CPU feature programming aka utilizing MP PPI wrapper code is that,
starting with MTL, FSP has dropped the `SkipMpInit` UPD.
It means now, coreboot doesn't have any way to skip FSP doing MP Init
operation. But during ADL, coreboot had introduced the
MP_SERVICES_PPI_V2_NOOP config that is used to skip FSP about
actually running any CPU feature programming on APs.
The idea is to use the same config even in MTL to provide only the
must have information (to bypass any assert in FSP during debug image)
to FSP.
Passing `FSP_UNSUPPORTED` from mps2_noop_get_number_of_processors()
results in `assert` while compiling FSP in debug mode hence,
implementing the function to pass only the information about BSP being
the active processor along with passing `FSP_SUCCESS` (eventually it
makes FSP happy and doesn't run into any issue in debug and/or release
mode).
TEST=Able to build and boot Google/Rex and Google/Kano while
coreboot skip calling into FSP for doing MP init.
Change-Id: I75d7e151699782210e86be564b0055d572cacc3f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70555
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>
On nissa, the ISH is running closed source firmware, so the ChromeOS
security requirements specify it must be behind an IOMMU. Allow adding
DmaProperty to the _DSD of the ISH device. This will result in the
kernel marking the device as untrusted.
BUG=b:249846505
TEST=Check SSDT is correct, and kernel detects the DmaProperty and
firmware-name properties.
SSDT entry on yaviks with both add_acpi_dma_property and firmware_name
set in devictree:
Scope (\_SB.PCI0.ISHB)
{
Name (_DSD, Package (0x04) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"firmware-name",
"adl_ish_lite.bin"
}
},
ToUUID ("70d24161-6dd5-4c9e-8070-705531292865"),
Package (0x01)
{
Package (0x02)
{
"DmaProperty",
One
}
}
})
}
Change-Id: Ie1539fc757e72e995e98c3ecf83e705e3bede8c0
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Currently the MRC cache is updated in romstage, immediately after
returning from FSP-M. Since cbmem is not cached in romstage, the update
is slow (~6 ms on nissa). Specifically, the new MRC data returned by the
FSP is stored in the FSP reserved memory in cbmem, so hashing the new
data is slow.
Move the MRC cache update to ramstage, where cbmem is cached. On nissa,
this saves ~5 ms of boot time.
Before:
552:finished loading ChromeOS VPD (RW) 631,667 (16)
3:after RAM initialization 637,703 (6,036)
4:end of romstage 650,307 (12,603)
After:
552:finished loading ChromeOS VPD (RW) 631,832 (15)
3:after RAM initialization 633,002 (1,169)
4:end of romstage 645,582 (12,580)
In ramstage, save_mrc_data() takes ~138 us.
BUG=b:242667207
TEST=MRC caching still works as expected on nivviks - after clearing the
MRC cache, memory is retrained on the next boot, but cached data is used
on subsequent boots.
Change-Id: Ie6aa2dee83a3ab8913830746593935d36a034b8d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This reverts commit 095c931cf1.
Previously cpu_info() was implemented with a struct on top of an
aligned stack. As FSP changed the stack value cpu_info() could not be
used in FSP context (which PPI is). Now cpu_info() uses GDT segments,
which FSP does not touch so it can be used.
This also exports cpu_infos from cpu.c as it's a convenient way to get
the struct device * for a certain index.
TESTED on aldrvp: FSP-S works and is able to run code on APs.
Change-Id: I3a40156ba275b572d7d1913d8c17c24b4c8f6d78
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69509
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current IPU ES entry value is always set to true for RPL and
kernel picks the ES version of the main IPU FW even for the production
bootloader but loading is not successful due to the authentication
failure.
On Raptor Lake silicon, the production binaries are backward
compatible with ES parts.
This change removes the IPU ES support ACPI entry since the
kernel needs to load the production IPU main firmware on both the
ES/QS parts.
BUG=b:258125833
TEST=Verify the Camera functionality by enabling the IPU secure mode
on RPL variants with both ES/QS silicon.
Signed-off-by: Jim Lai <jim.lai@intel.com>
Change-Id: I9fd8ea0dd6ffdb16961bb017ba4388bf99e4d5bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69929
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Get rid of a lot of casts.
Change-Id: I93645ef5dd270905ce421e68e342aff4c331eae6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Not all functions that call fsp_print_guid print their output with the
BIOS_SPEW log level, so introduce a new log level parameter so that the
caller of fsp_print_guid can specify which log level fsp_print_guid
should use for printing the GUID.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3b37afe703f506d4913f95a954368c0eec0f862d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69599
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the new fsp_hob_iterator_get_next_guid_extension function in
fsp_find_extension_hob_by_guid instead of iterating through the HOB list
in this function.
TEST=AMD_FSP_DMI_HOB is still found and the same type 17 DMI info is
printed on the console.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4d4ce14c8a5494763de3f65ed049f98a768c40a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Drop the find_resource_hob_by_guid implementation and use the new
fsp_hob_iterator_init and fsp_hob_iterator_get_next_guid_resource
functions in fsp_find_range_hob.
TEST=Mandolin still finds the TSEG range HOB and uses the correct TSEG
location.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00786cbeea203fba195ddc953c3242be544a7d70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Introduce iterator function to go through the HOBs that will be used in
follow-up commits both from the rest of the common FSP HOB access code
and from SoC-specific code that needs to access specific HOBs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If86dde2a9f41d0ca7941493a92f11b91a77e2ae0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since the characters per line limit was increased from 80 to 96, some
line breaks can be removed to improve code readability.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I92aa3fec8c8caba143e418efc999ec4a7c5d93c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69461
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
No need to call a function that just instantly returns.
It greatly enhances readability to just check before calling a funtion
and it also removes an extra argument.
Change-Id: I4d57c45ede520160ef615725c023b7e92289a995
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68592
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 reverts commit 672bd9bee5.
Reason for revert: Gmeet resolution dropped. When system starts
Gmeet video call, it uses the hardware accelerated encoder as per
the expectation. But, as soon as another system connects to the call,
the immediate fallback observed from hardware to software encoder.
Due to this, Gmeet resolution dropped from 720p to 180p.
Currently, this issue observed on AlderLake-N SoC based fanless
platforms. This issue is not seen on fan based systems.
BUG=b:246535768,b:235254828
BRANCH=None
TEST=Built and tested on Alderlake-N systems. With this revert
Gmeet resolution drop not observed.
Change-Id: Idaeaeaed47be44166a7cba9a0a1fac50d2688e50
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Baieswara Reddy Sagili <baieswara.reddy.sagili@intel.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
BRANCH=none
BUG=b:234776154
TEST=build and boot Nirwen UFS, copy ISH firmware to host
file system /lib/firmware/intel/adln_ish.bin
check "dmesg |grep ish", it should show:
ish-loader: ISH firmware intel/adlnrvp_ish.bin loaded
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: I89782b0b7dde1fca0130472a38628e72dfd5c26c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
The current IPU ES entry value is always set to true for ADL-N and
kernel picks the ES version of the main IPU FW even for the production
bootloader but loading is not successful due to the authentication
failure.
Alderlake-N silicon has the same CPU id for all the SKU's and
also the production binaries are backward compatible with ES parts.
This change removes the IPU ES support ACPI entry since the
kernel needs to load the production IPU main firmware on both the
ES/QS parts.
BUG=b:248249032
TEST=Verify the Camera functionality by enabling the IPU secure mode
on ADL-N variants with both ES/QS silicon.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I75b222e6f2b1ccdc5b6c448eb60afff3c1da3a8b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
On some platforms the HFSTS4 bit 19 does not indicate active PTT.
Instead of ME HFSTS4, use TXT FTIF register to check active TPM for
the current boot. Discrete TPM shall be deactivated when PTT is
enabled so this always should return true value of PTT state.
Leave the old method for backwards compatibility if TXT FTIF would not
be applicable for older microarchitectures.
Based on DOC #560297.
TEST=Check if PTT is detected as active on MSI PRO Z690-A DDR4 WIFI
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3a55c9f38f5bb94fb1186592446a28e675c1207c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Currently, the "loading FSP-S" timestamp is added in fsp_silicon_init().
However, most Intel platforms actually load FSP-S earlier than this, in
soc_fsp_load(). So the timestamp is added in the wrong place.
Add the timestamp in fsps_load() instead, after the load_done early
return so that it will only be added for the first call.
Before:
949:finished CSE firmware sync 961,833 (17,998)
17:starting LZ4 decompress (ignore for x86) 1,018,328 (56,495)
18:finished LZ4 decompress (ignore for x86) 1,018,797 (469)
30:device enumeration 1,035,096 (16,298)
971:loading FSP-S 1,048,082 (12,986)
954:calling FspSiliconInit 1,049,331 (1,249)
After:
949:finished CSE firmware sync 959,355 (16,370)
971:loading FSP-S 978,139 (18,784)
17:starting LZ4 decompress (ignore for x86) 1,015,796 (37,656)
18:finished LZ4 decompress (ignore for x86) 1,016,271 (475)
30:device enumeration 1,032,567 (16,295)
954:calling FspSiliconInit 1,046,867 (14,300)
BUG=b:239769975
TEST="loading FSP-S" is added in the right place on nivviks (see above).
Change-Id: Ib26cf96ae97766333fe75ae44381d4f7c6cc7b61
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add multiple fan support for dptf policies
BUG=b:235254828
BRANCH=None
TEST=Built and tested on Redrix system for two fans
Change-Id: I96ead90e3b805bd20de03e4bef4fa4b9fbaaaedd
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch implements EFI_PEI_MP_SERVICES_PPI structure definitions
with APIs that return mp_api_unsupported().
The reason behind this change is to fix an FSP issue where FSP assumes
ownership of the APs (Application Processors) upon passing a `NULL`
pointer to the CpuMpPpi FSP-S UPD.Hence, this patch implements
`MP_SERVICES_PPI_DEFAULT` config to fill EFI_PEI_MP_SERVICES_PPI with
`mp_api_unsupported` APIs.
Later this data structure can be passed to the CpuMpPpi UPD to avoid
APs from getting hijacked by FSP while coreboot decides to set
SkipMpInit UPD.
TEST=Able to build and boot Google/Taeko with this patch.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I31fcaa2aa633071b6d6bfa05dbe891ef87978d2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
coreboot uses TianoCore interchangeably with EDK II, and whilst the
meaning is generally clear, it's not the payload it uses. EDK II is
commonly written as edk2.
coreboot builds edk2 directly from the edk2 repository. Whilst it
can build some components from edk2-platforms, the target is still
edk2.
[1] tianocore.org - "Welcome to TianoCore, the community supporting"
[2] tianocore.org - "EDK II is a modern, feature-rich, cross-platform
firmware development environment for the UEFI and UEFI Platform
Initialization (PI) specifications."
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4de125d92ae38ff8dfd0c4c06806c2d2921945ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65820
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>
This adds SPDX identifiers to the remaining source files in the
drivers directory that don't already have them.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I97f96de857515214069c3b77f3c781f7f0555c6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66499
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As per Intel Dynamic Tuning Spec revision 1.3.13, section 14.1.2 TBAT
_UID should match the _UID implemented for battery device ACPI object
for OS
_UID for TBAT is currently set to "TBAT" but should be 1.
Battery device is define at src/ec/google/chromeec/acpi/battery.asl
Setting _UID to 1 because right now ChromeOS is the only user
of DPTF driver
TEST: Build and boot brya0
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: I1e4474e59cf01f937fbd51e5b674a609f0c47625
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Fixes: 5315e96abf ("arch/x86/postcar: Use a separate stack for C execution")
Resolves:
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/
thread/TGIWAKZKELJRAEMKJNYRJ55MX2CXYNCV/
Link: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/
thread/2JC3GNJSGXUD6DRVUY7O2O3W6OM3E2MY/
5315e96abf broke platforms using FSP-M to tear down CAR. It was pushing
the value at '_estack' into %esp rather than the address '_estack'.
Change-Id: Ie1fc70bd60fe3a2519ffb71625a35630fa732ff6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65716
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Branding changes to unify and update Chrome OS to ChromeOS (removing the
space).
This CL also includes changing Chromium OS to ChromiumOS as well.
BUG=None
TEST=N/A
Change-Id: I39af9f1069b62747dbfeebdd62d85fabfa655dcd
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65479
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
CPUID_RAPTORLAKE_P_Q0 is ES. Add it to generate is_es = 1 in ACPI
BUG=b:229134437
BRANCH=firmware-brya-14505.B
TEST=Booted to OS on adlrvp + rpl silicon
Signed-off-by: zhixingma <zhixing.ma@intel.com>
Change-Id: I67d70dc7e916a4818869aef86e7e642b66ea5dae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
There are efforts to have bootflows that do not follow a traditional
bootblock-romstage-postcar-ramstage model. As part of that CBMEM
initialisation hooks will need to move from romstage to bootblock.
The interface towards platforms and drivers will change to use one of
CBMEM_CREATION_HOOK() or CBMEM_READY_HOOK(). Former will only be called
in the first stage with CBMEM available.
Change-Id: Ie24bf4e818ca69f539196c3a814f3c52d4103d7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This patch fixes a potential corner case scenario where the value of
CONFIG_DEFAULT_CONSOLE_LOGLEVEL is less than `BIOS_SPEW` hence, coreboot
is unable to redirect FSP serial messages over UART.
Rather than passing hard coded `BIOS_SPEW` for the FSP debug handler,
this patch now calls get_log_level() function to pass the supported log
level while printing FSP serial msg.
BUG=b:225544587
TEST=Able to build and boot taeko. Also, able to see FSP debug log with
CONFIG_DEFAULT_CONSOLE_LOGLEVEL=7.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8a18101f5c3004252205387bde28590c72e05b9d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64460
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
