This reverts commit 79503ef515.
The Intel FSP repository at https://github.com/intel/FSP.git currently
lacks the Client ADL-N headers. The existing coreboot code references
the "IoT/AlderLakeN/" directory for these headers, but it is missing the
crucial FspProducerDataHeader.h file. Without this header, the ADL-N
platform is unable to utilize the appropriate MRC version needed for
updating MRC caches. This patch aims to restore the necessary FSP
headers for the ADL-N platform within the vendorcode directory.
Change-Id: I99e9d5a07b4ca8d1666e3fd50d3d363ed5d4618e
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This adds another external payload to coreboot. The payload has been
heavily based on u-boots UEFI implementation.
The leanefi payload is basically a translator from coreboot to UEFI. It
takes the coreboot tables and transforms them into UEFI interfaces.
Although it can potentially load any efi application that can
handle the minimized interface that leanefi provides, it has only
been tested with LinuxBoot (v6.3.5) as a payload. It has been optimized
to support only those interfaces that Linux requires to start.
Among other leanefi does not support:
- efi capsule update (also efi system resource table)
- efi variables
- efi text input protocol (it can only output)
- most boot services. mostly memory services are left (e.g. alloc/free)
- all runtime services (although there is still a very small runtime
footprint that is planned to be removed in the near future)
- TCG2/TPM (although that is mostly because of laziness)
The README.md currently provides more details on why.
The payload currently only supports arm64 and has only been tested
on emulation/simulator targets. The original motivation was to get ACPI
on arm64 published to the OS without using EDK2. It is however also
possible to supply the leanefi with a FDT that is published to the OS.
At that point one would however probably use coreboot only instead of
this shim layer on top. It would be way nicer to have Linux support
something else than UEFI to propagate the ACPI tables, but it requires
to get the Linux maintainer/community on board. So for now this shim
layer ciruimvents that.
LBBR Test:
// 1. dump FDT from QEMU like mentioned in aarch64 coreboot doc
// 2. compile u-root however you like (aarch64)
// 3. compile Linux (embed u-root initramfs via Kconfig)
// 4. copy Linux kernel to payloads/leanefi/Image
// 5. copy following coreboot defconfig to configs/defconfig:
CONFIG_BOARD_EMULATION_QEMU_AARCH64=y
CONFIG_PAYLOAD_NONE=n
CONFIG_PAYLOAD_LEANEFI=y
CONFIG_LEANEFI_PAYLOAD=y
CONFIG_LEANEFI_PAYLOAD_PATH="[path-to-linux]/arch/arm64/boot/Image"
CONFIG_LEANEFI_FDT=y
CONFIG_LEANEFI_FDT_PATH="[path-to-dumped-DTB]"
// 6. compile coreboot
make defconfig
make -j$(nproc)
// 7. run qemu like mentioned in coreboot doc (no FIT)
// 8. say hello to u-root and optionally kexec into the next kernel
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I4093378e89c3cb43fb0846666de80a7da36b03f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ron Minnich <rminnich@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The Razer Blade Stealth Kaby Lake has 2 variants. One is the H2U
variant, as originally committed, with the SKU number RZ09-01962, also
known as the 2016 model, and the H3Q model with SKU numbers RZ09-01963
and RZ09-01964, known as the Mid 2017 model. This commit adds support
for the H3Q model. With respect to coreboot, there are few known
differences:
1. Only the H2U has TPM.
2. The USB ports are different.
3. The screen size (and therefore VBIOS Table) is different.
4. The hda_verb is very slightly different.
5. The gpio is different.
Change-Id: I493a651e52c2eb938daa67a05e9caaa784020fa4
Signed-off-by: Reagan Bohan <xbjfk.github@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Apply commit c6b65c1a81 ("soc/intel/alderlake: Enable USB2 port reset
message on Type-C ports") to Meteor Lake.
This change is added to address the issue of USB3 ports downgrading to
high speed during low power modes and not returning back to super speed.
The patch enables port reset event on USB2 ports. This event is
is passed to USB3 upstream ports to upgrade back to super speed (USB3)
after a downgrade during low power state.
Change-Id: Iac702a8d8edd2b3b7e03abcac020be7e45335821
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82730
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
linux_trampoline.c generation is broken with latest crossgcc-i386
toolchain. Fix the issue to enable the building.
../cbfstool/linux_trampoline.S: Assembler messages:
../cbfstool/linux_trampoline.S💯 Error: no instruction mnemonic
suffix given and no register operands; can't size
instruction
<builtin>: recipe for target '../cbfstool/linux_trampoline.o'
failed
TEST=Build and boot on intel/archercity CRB
cd util/cbfstool/
rm linux_trampoline.c
make linux_trampoline.c
Change-Id: I7faca296f946bb4e9fd510661357925e5dcf9a6b
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82704
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The comment that the PchHdaAudioLink UPDs only configure GPIOs is
incorrect. Setting this to 1 is needed to enable HDA audio link.
Same exact situation as with Alder Lake in CL 71715.
Change-Id: Iecbe106ae18b5a8b53c04a5335a4e4c4ae27c7a0
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Initial commit is a copy of ec/system76/ec from tag v24.02.1 (commit
0a280ff7) with string changes. Dasharo-specific features will be added
in subsequent commits, similar to how Librem EC support was added in
changes 52390 and 52391.
Change-Id: Ic7c3d9413488026548514963eb78accc28e41e06
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
coreboot needs to figure out top of memory to place CBMEM data. On some
non-x86 QEMU virtual machines, this is achieved by probing the RAM space
to find where the VM starts discarding data since it's not backed by
actual RAM. This behaviour seems to have changed on the QEMU side since
then, VMs using the "virt" model have started raising exceptions/errors
instead of silently discarding data (likely [1] for example) which has
previously broken coreboot on these emulation boards.
The qemu-aarch64 and qemu-riscv mainboards are intended for the "virt"
models and had this issue, which were mostly fixed by using exception
handlers in the RAM detection process [2][3]. But on 32-bit RISC-V we
fail to initialize CBMEM if we have 2048 MiB or more of RAM, and on
64-bit RISC-V we had to limit probing to 16383 MiB because it can run
into MMIO regions otherwise.
The qemu-armv7 mainboard code is intended for the "vexpress-a9" model VM
which doesn't appear to suffer from this issue. Still, the issue can be
observed on the ARMv7 "virt" model via a port based on qemu-aarch64.
QEMU docs for ARM and RISC-V "virt" models [4][5] recommend reading the
device tree blob it provides for device information (incl. RAM size).
Implement functions that parse the device tree blob to find described
memory regions and calculate the top of memory in order to use it in
mainboard code as an alternative to probing RAM space. ARM64 code
initializes CBMEM in romstage where malloc isn't available, so take care
to do parsing without unflattening the blob and make the code available
in romstage as well.
[1] https://lore.kernel.org/qemu-devel/1504626814-23124-1-git-send-email-peter.maydell@linaro.org/T/#u
[2] https://review.coreboot.org/c/coreboot/+/34774
[3] https://review.coreboot.org/c/coreboot/+/36486
[4] https://qemu-project.gitlab.io/qemu/system/arm/virt.html
[5] https://qemu-project.gitlab.io/qemu/system/riscv/virt.html
Change-Id: I8bef09bc1bc4e324ebeaa37f78d67d3aa315f52c
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80322
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The crashlog code in intel/common/block and meteorlake soc
was casting integer addresses directly to pointer types,
which caused compilation errors in x86_64 bit builds.
This commit fixes the issue by using uintptr_t for casting
integer addresses to pointer types before dereferencing.
BUG=b:329034258
TEST=Successfully build Meteor Lake (rex) in both x86_32 and
x86_64 modes.
Change-Id: I2d0814a8b767270ec140341bfb51d0782469545d
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82481
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
For multi-SKU/SoC supports, IIO domain layouts are returned from FSP
HOBs. Add _OSC ASL generation utils so that static IIO domain layout
definition file per SKU/SoC are not needed any more.
The _OSC generation codes is a thin AML generation layer which
further invokes \_SB.POSC which is defined in ASL. The ASL handler
is able to handle boot-time generated info as parameters while keeps
good readability for the ease of maintenance. In this case, firmware
granted capabilities are calculated in boot time and passed to ASL
handler as parameters.
TEST=Build and boot on intel/archercity CRB
Change-Id: Ibd3bfa2428725fe593754436d5ed75a3a11b4cdc
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
This commit removes config guard around FSPM_ARCH_UPD from the
FspApi.h header file. This change is done to ensure
that this header file can be used with both x86_32 and x86_64
architectures and also with different FSP specification versions.
The following modifications are made:
- Removes PLATFORM_USES_FSP2_X86_32 config guard around
FSPM_ARCH_UPD, this was added to isolate the structure from
x64 build. This is not really required since the x64 build uses
FSP2.4 structures.
BUG=b:343428206
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Idc849de73723036323f81dfd055730f6669cd52e
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82425
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
* Conditionally select FSP 2.4 when x86_64 support is available
(HAVE_X86_64_SUPPORT).
* Default to FSP 2.3 otherwise.
* Adjust default FSP header path to align with architecture.
BUG=b:242829490
TEST=Able to build google/rex in both 32-bit and 64-bit mode.
Change-Id: Ib77a34c6bf7bca3485a197f109d1550ac3d51cc0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82624
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This change allows eSOL to be enabled on production Meteor Lake silicon
even when 64-bit support is not present. eSOL support is still TBD for
64-bit FSP hence, skip adding this support for 64-bit build.
TEST=Able to build and boot google/rex64 w/o eSOL.
Change-Id: I16762e5b74ae0aaa3c28730479a1fd9defc4d93c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82716
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit introduces new header files of V3471.91 for the x86_64
architecture in the fsp2_0/meteorlake directory. FSP2.4 brings FSP
64-bits support and the soc Kconfig file has been updated to select
this new header path when FSP2.4 is in use.
BUG=b:329034258
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Ib41b57e794311db729ac65a968f562aa127e86c3
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82473
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
This commit moves FSP V3471.91 header files for Meteor Lake
into a new x86_32 directory to better organize the files based
on the architecture. The Kconfig file has been modified accordingly
to reflect the new paths of the relocated headers.
BUG=b:329034258
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Id30186a8b1b5a9082f498e18a3378f5e9907b668
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82424
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit updates the type definitions for FSP parameters in the
Meteor Lake platform to ensure compatibility with the FSP2.4
specification, that supports 64-bit builds for the first time and
this also ensures that parameter types works for both 32-bit
and 64-bit builds.
- In fsp_params.c, FSPS_ARCH_UPD macro is changed to
FSPS_ARCHx_UPD which supports FSP2.4 and older specifications.
Special handling is added for FspEventHandler assignment to handle
as the variable type is different in both cases.
- In meminit.c, the type for SPD pointers is changed from uint32_t
to efi_uintn_t to support both 32-bit and 64-bit builds.
BUG=b:329034258
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Ide220f60184135a6488f4472f69a471e2b383e2a
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82177
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since this mainboard no longer uses the FSP GOP driver, the DDI port
settings are no longer necessary. The GOP driver was used in the initial
phase of development where we used Tianocore as payload for some test
cases. Finally, this mainboard uses a self-made Linux payload, which
does the graphic initialization.
BUG=none
TEST=Boot into Linux and check if graphic works correctly
Change-Id: Ie9e135fbc2627546d6ef95d7d5ff3e9a9222b5d2
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82663
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Some drives block the CPU from reaching C10 during S0ix suspend without
the RTD3 configs.
Fixes suspend with the following drives:
- Kingston KC3000 (SKC3000D/4096G)
- Kingston HyperX (SHPM2280P2H/240G)
- Solidigm P44 Pro (SSDPFKKW010X7)
The following drives continue to work:
- Samsung 970 Evo (MZVLB250HAHQ)
- WD Black SN770 (WDS250G3X0E)
- WD Green SN350 (WDS240G2G0C-00AJM0)
- WD Blue SN570 (WDS100T3B0C)
Change-Id: Ia369727d0f1aa5ff546cfb5700a63063730e8248
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Tested-by: Levi Portenier <levi@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Code dealing with PAE can be used outside of memset_pae(). This change
extracts creation of identity mapped pagetables to init_pae_pagetables()
and mapping of single 2 MiB map to pae_map_2M_page(). Both functions are
exported in include/cpu/x86/pae.h to allow use outside of pgtbl.c.
MEMSET_PAE_* macros were renamed to PAE_* since they no longer apply
only to memset_pae().
Change-Id: I8aa80eb246ff0e77e1f51d71933d3d00ab75aaeb
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82249
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<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>
