Uldrenite supports the WWAN 5G device and uses variant.c to handle the
power-on sequence according to the Rolling Wireless_RW350R-GL_Hardware
Guide_Generic_V1.1. Due to no hardware access, the boot time is
estimated to increase by 50 ms.
At this stage, we do not yet have the board or key parts for
verification. However, I still need to merge the CL to ensure that the
WWAN functionality works. Once the motherboard is available, I will make
adjustments to optimize and reduce the boot time.
BUG=b:381393809, b:383212261
BRANCH=None
TEST=emerge-nissa coreboot
Change-Id: If8695920c2b3d2a27da62afcbe75e70d1ea09792
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85537
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>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Per Fabian Groffen <grobian@gentoo.org> in CB:75145:
This particular setting results in
[ERROR] PNP: 002e.308 missing read_resources
The underlying root cause was fixed by commit f5b993de4f
(sio/nuvoton/nct6779d: Correct GPIOBASE virtual LDN). However, to make
GPIO by I/O work requires setting up an I/O port resource here and
a generic LPC I/O decode at southbridge/intel/bd82x6x, and both weren't
done. Even if done, this newfound capability still doesn't offer much.
Change-Id: I39739ab71bc644619667b3e123cc9ad85f9d109f
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: coreboot org <coreboot.org@gmail.com>
According to Intel mFIT tool, SATA Port 0 is mapped as RP11 (PCI-E).
Disable SATA mapping on that port.
Setting SATAXPCIE1 GPIO fixes broken SATA port.
Therefore, this port is now fully functional.
TEST: Plug in 2.5in SATA drive, check detection in EDK2/Linux.
Change-Id: I9556383952d163a145ac73cb846740a4ce67a1e1
Signed-off-by: Alicja Michalska <alicja.michalska@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85609
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Revert super I/O IRQ polarity settings replicated from OEM firmware
back to its power-on defaults.
With OEM settings COM 1/UART A/serial port 1 gets blocked right after
the kernel boots. It no longer works or responds, which actually means
the Linux boot process gets stuck forever when configured to write
to ttyS0.
Also revised the comment on another SIO setting to say it's being set
for PECI.
TEST=Not using these settings, I have not found any downside.
Serial keeps working, sensors still work, S3 suspend/resume works
correctly.
Reported by Fabian and confirmed by Keith.
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Keith Hui <buurin@gmail.com>
Change-Id: Iae526762e79e9e2d46d06e12c338f375e5555e8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: coreboot org <coreboot.org@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
If CSE is in RO, then a reset is expected for CSE to jump to RW. Include
that reset in mainboard_expects_another_reset() logic. This will avoid
unnecessary warm reset during regular boot flow in boards with non-UFS
storage.
BUG=None
TEST=Build Brox BIOS image and boot to OS. Ensure that redundant reset
to disable UFS controller is avoided.
Before this change:
[INFO ] Disabling UFS controllers
[INFO ] Warm Reset after disabling UFS controllers
[INFO ] system_reset() called!
<snip>
[DEBUG] HECI: Global Reset(Type:1) Command
<snip>
[INFO ] Disabling UFS controllers
[INFO ] Warm Reset after disabling UFS controllers
[INFO ] system_reset() called!
After this change:
[DEBUG] HECI: Global Reset(Type:1) Command
<snip>
[INFO ] Disabling UFS controllers
[INFO ] Warm Reset after disabling UFS controllers
[INFO ] system_reset() called!
Change-Id: I80a46b15813b6bdfa6c029c54590f4b7c2a6754b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85642
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CSE Sync Early Sign of Life (ESOL) event is logged as soon as the CSE FW
update is complete. This happens irrespective of whether Early Sign of
Life screen is enabled or not. Move CSE Sync ESOL event right before
displaying the ESOL screen.
BUG=b:378458829, b:379585294
TEST=Build Brox BIOS image and boot to OS. Ensure that the ESOL event
for CSE Sync is logged.
Change-Id: Iaa0dbb87ddde69dc3f4a9e058fc6bed8711b29e7
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85111
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
According to the discussion on the issue tracker, set
GPP_A14 as USB_OC1 for the A0 port
BUG=b:380789023
TEST=emerge-nissa coreboot
Change-Id: I2b782216c0392b1a98ea57300e683c32999d5a32
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
According to the discussion on the issue tracker, set GPP_B5
and GPP_B6 to the ISH function.
BUG=b:383696667
TEST=emerge-nissa coreboot
Change-Id: I0c98206edd89c90cb1c341a8f713f09f4b8bf0e7
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85601
Reviewed-by: Kapil Porwal <kapilporwal@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>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Add new folder and basic drivers for Mediatek SoC 'MT8189'.
Also enable UART and ARM arch timer.
This commit includes the necessary initialization files for MT8189,
which cannot be shared with other existing SoCs.
The modules included are:
- Memory layout: MT8189 has only 64KB of SRAM, differing in space
allocation compared to other SoCs.
- PLL: Different SoCs have different PLL designs. In this commit,
we provide the most basic settings, with more configurations to
be added in future commits.
- Timer: MT8189 uses timer v2, unlike other SoCs which use timer v1.
- SPI: The SPI driver for different SoCs varies depending on the GPIO/
PIN MUX used. In this commit, we provide the most basic settings,
with more configurations to be added in future commits.
- EMI: MT8189 uses common EMI code along with MT8189-specific
'dram_parameter.h'. This commit provides an EMI stub to ensure
coreboot builds successfully. Future DRAM-related commits will
utilize the common EMI code.
BUG=b:379008996
BRANCH=none
TEST=saw the coreboot uart log to bootblock
Change-Id: I5d83c4c7fba49e455fac0b58f019ad225f83c197
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85616
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MediaTek pwrsel (Power Select) is mainly used to reduce power
consumption, controlled by mcupm.
BUG=b:317009620
TEST=Build pass
Change-Id: Ib1b8588810fdad5c675dee865627337269b57d18
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This change allows the Chrome EC (CREC) ACPI device to publish the LPC
Generic Memory Range (GMR) address range using the _CRS method.
The Google CREC driver can now parse this information to determine the
MMIO address map, enabling access to the LPC GMR register space.
This addresses the issue where the CREC driver was unable to
automatically determine the LPC GMR base address.
TEST=Able to build and boot google/brox.
without this patch:
brox-rev0 ~ # cat /proc/iomem | grep fe0
fe000000-fe00ffff : INTC1026:00
fe000000-fe00ffff : intel_scu_ipc
fe03e000-fe03efff : 0000:00:1e.0
fe03e000-fe03e1ff : lpss_dev
fe03e000-fe03e1ff : serial
fe03e200-fe03e2ff : lpss_priv
fe03e800-fe03efff : idma64.4
fe03e800-fe03efff : idma64.4 idma64.4
with this patch:
brox-rev0 ~ # cat /proc/iomem | grep fe0
fe000000-fe00ffff : INTC1026:00
fe000000-fe00ffff : intel_scu_ipc
fe03e000-fe03efff : 0000:00:1e.0
fe03e000-fe03e1ff : lpss_dev
fe03e000-fe03e1ff : serial
fe03e200-fe03e2ff : lpss_priv
fe03e800-fe03efff : idma64.4
fe03e800-fe03efff : idma64.4 idma64.4
fe0b0000-fe0bffff : GOOG0004:00
Change-Id: Ib3ea3e2a482f9eceaa8c15e38b7e708b156bc978
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85603
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds an ACPI method to get the LPC Generic Memory Range
(LGMR) address. This is necessary for platforms that need to access
the LGMR from OS driver.
The new method, called GLGM, reads the LGMR address from the LPC PCI
configuration space (offset 0x98) and returns it as a 32-bit value.
BUG=b:354066052
TEST=Able to build and boot google/brox.
Change-Id: I4322cee2c608e550e233c45c68958e8a4046c361
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85602
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently u-root doesn't build for various reasons.
1. The boot cmds have changed. Some have been removed and the default
has changed to the 'boot' cmd for loading an OS.
2. The elvish shell has been removed as default shell. The gosh is now
the default.
3. For some reason the -uroot-source parameter doesn't exist anymore? So
instead we just cd into the u-root directory and build the initramfs
there.
Build tested:
| CONFIG_LINUXBOOT_COMPILE_KERNEL | CONFIG_LINUXBOOT_BUILD_INITRAMFS |
----------------------------------------------------------------------
| n | n |
| n | y |
| y | n |
| y | y |
----------------------------------------------------------------------
Change-Id: If66238cec248deb3594de82f3adbc608516a2fc5
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84119
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently our coreboot toolchain cannot build the Linux kernel in case
of x86_64. It spits out the following error during build:
```
make -C build/kernel-6_3 \
CROSS_COMPILE=/home/max/coreboot-amd/util/crossgcc/xgcc/bin/x86_64-elf- \
ARCH=x86_64 KBUILD_BUILD_USER=coreboot KBUILD_BUILD_HOST=reproducible \
KBUILD_BUILD_TIMESTAMP=Tue Aug 20 13:36:03 2024 KBUILD_BUILD_VERSION=0 bzImage
arch/x86/lib/clear_page_64.S: Assembler messages:
arch/x86/lib/clear_page_64.S:18: Error: number of operands mismatch for `mov'
arch/x86/lib/clear_page_64.S:27: Error: number of operands mismatch for `mov'
make[4]: *** [scripts/Makefile.build:374: arch/x86/lib/clear_page_64.o] Error 1
make[3]: *** [scripts/Makefile.build:494: arch/x86/lib] Error 2
make[3]: *** Waiting for unfinished jobs....
arch/x86/entry/entry_64.S: Assembler messages:
arch/x86/entry/entry_64.S:437: Error: unbalanced parenthesis in operand 1.
arch/x86/entry/entry_64.S:262: Info: macro invoked from here
arch/x86/entry/entry_64.S:265: Info: macro invoked from here
arch/x86/entry/entry_64.S:439: Error: unbalanced parenthesis in operand 1.
arch/x86/entry/entry_64.S:262: Info: macro invoked from here
arch/x86/entry/entry_64.S:265: Info: macro invoked from here
make[5]: *** [scripts/Makefile.build:374: arch/x86/entry/entry_64.o] Error 1
make[4]: *** [scripts/Makefile.build:494: arch/x86/entry] Error 2
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:494: arch/x86] Error 2
make[2]: *** [Makefile:2025: .] Error 2
make[1]: *** [targets/linux.mk:60: build/kernel-6_3/arch/x86/boot/bzImage] Error 2
make: *** [payloads/external/Makefile.mk:401: payloads/external/LinuxBoot/build/Image] Error 2
```
In order to fix it, we will default to the host toolchain in order to
build x86_64 Linux. For that we add another Kconfig that decides,
whether or not a cross toolchain is used to build Linux.
Change-Id: Icaf56d6991d79f629e9ba8c901b441d81921d594
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83990
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Add target for building libstdcxx for a cross compile target using the
GCC source downloaded for a cross compiler build and linking against a
specified libc implementation.
BUG=NONE
TEST=Build libstdc++ for cross compilers, link against generated library
./util/crossgcc/buildgcc -t -p arm-eabi -P libstdcxx -l c,c++ -j128 \
--libstdcxx_include /tmp/picolibc
Change-Id: Ie0c06ffaeab632c27a992dee8abcc403cceabeed
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
MT8196's SPM_SYSTEM_BASE_OFFSET has a different offset due to the
hardware design. To avoid adding a new kconfig for differentiation,
migrate this definition into SoC specific value.
BUG=none
TEST=emerge-geralt coreboot && emerge-corsola coreboot
Change-Id: I5df510d5d05a0594d87e7e96e1e03e20a018785f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85625
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The init flow in `spm_init_pcm_register` and `spm_kick_pcm_to_run` is
simplified on MT8196. And MT8196 does not have corresponded registers
used by these two functions. Therefore, move these two function to a
separated file and simply name it as spm_v1.c.
BUG=none
TEST=emerge-geralt coreboot && emerge-corsola coreboot
Change-Id: I028d8f8ca8c9988d26d400f25ca09a2615541364
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85623
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a mechanism so that coreboot can provide a list of options to
post-coreboot code. The options are grouped together into forms and
have a meaning name and optional help text. This can be used to let
payloads know which options should be displayed in a setup menu,
for instance. Although this system was written to be used with edk2,
it has been designed with flexibility in mind so that other payloads
can also make use of this mechanism. The system currently lacks a way
to describe where to find option values.
This information is stored in a set of data structures specifically
created for this purpose. This format is known as CFR, which means
"coreboot forms representation" or "cursed forms representation".
Although the "forms representation" is borrowed from UEFI, CFR can
be used in non-UEFI scenarios as well.
The data structures are implemented as an extension of cbtables records
to support nesting. It should not break backwards compatibility because
the CFR root record (LB_TAG_CFR_ROOT) size includes all of its children
records. The concept of record nesting is borrowed from the records for
CMOS options. It is not possible to reuse the CMOS records because they
are too closely coupled with CMOS options; using these structures would
needlessly restrict more capable backends to what can be done with CMOS
options, which is undesired.
Because CFR supports variable-length components, directly transforming
options into CFR structures is not a trivial process. Furthermore, CFR
structures need to be written in one go. Because of this, abstractions
exist to generate CFR structures from a set of "setup menu" structures
that are coreboot-specific and could be integrated with the devicetree
at some point. Note that `struct sm_object` is a tagged union. This is
used to have lists of options in an array, as building linked lists of
options at runtime is extremely impractical because options would have
to be added at the end of the linked list to maintain option order. To
avoid mistakes defining `struct sm_object` values, helper macros exist
for supported option types. The macros also provide some type checking
as they initialise specific union members.
It should be possible to extend CFR support for more sophisticated
options like fan curve points. Feedback about this is highly
appreciated.
Change-Id: I304de7d26d79245a2e31a6d01f6c5643b31cb772
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74121
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since QEMU commit 728b923f548d
("target/arm: Do memory type alignment check when translation enabled")
alignment is checked for device memory. That causes exceptions during
bootup of coreboot trying to load things (e.g. stages) from the memory
mapped flash.
To fix it the memory mapped flash region will be marked as MA_MEM
(normal memory) instead of MA_DEV (device memory). Technically that
isn't 100% correct, but avoids having to write a custom memory mapped
flash driver that checks for alignment on all accesses. Since it is
emulation and therefore always normal memory anyway, there shouldn't be
any side effects.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I98bd1a18495e3d153ce53abec8686c7871ee12c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85147
Reviewed-by: David Milosevic <David.Milosevic@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The MiTAC Computing Whitestone2 O-RAN CU/DU Edge Server is a compact
and highly efficient 1U rackmount solution designed for edge computing
in O-RAN (Open Radio Access Network) environments. Featuring support
for the 4th Gen Intel® Xeon® Scalable Processor Edge Enhanced Product
Family, it delivers robust performance with a single socket (LGA-4677)
that supports up to 205W TDP. The server provides excellent memory
capabilities with 8 DDR5 RDIMM slots supporting 4400 MHz speeds across
8 channels per CPU.
Working:
- All eight DIMM slots
- Serial port to emit spam
- POST code display
- Front USB 2.0 port
- Front Intel E810 CAM1 (25Gbps x 4)
- Front Intel E810 CAM2 (25Gbps x 4 / 10Gbps x 8)
- M.2 2280/22110 slot x 2 (Gen3 x4)
- Flashing internally with flashrom
Untested for now (i.e. should work, will eventually test):
- Riser PCIe Gen.4 x16 slots x 2 (FHHL)
Others:
- The board boots to Ubuntu 22.04.2 (5.15.0-1032-realtime) with all
40 cores (Intel 5433n) available.
- FlexRAN 23.11 + DPDK 22.11.1 + ACC200 O-RU + O-DU long-run test
pass.
Change-Id: Icf625cf8e9c76ef08411614c15ee43d0c459b905
Signed-off-by: Mark Chang <mark.chang@mitaccomputing.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85532
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the schematic_20241203, configure USB ports and their
mappings.
BUG=b:380789023
TEST=emerge-nissa coreboot
Change-Id: I8fa3bf958faaf17b35e33fe93e2a11e0d2eb48d6
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85582
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The nissa project fw branch is more suitable for compatibility with unknown, so the compatible methods of wifi and ssd are replaced.
BUG=b:383675207
BRANCH=None
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: Id2415d18c635dece94500f511bccdc9d2b69d1b4
Signed-off-by: Rui Zhou <zhourui@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Rauru reference design has SD card interfaces, so we have to configure
it in ramstage.
Implement msdc.c (memory and SD Card controller) to place the SD card
drivers.
This implementation is based on chapter 10.3 in MT8196 Functional
Specification.
TEST=Build pass
BUG=b:317009620
Change-Id: Ibb6a075d0f1b5a647e93a58b3ea1029b7676c765
Signed-off-by: Andy-ld Lu <andy-ld.lu@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85564
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tracker is a debugging tool, including AP/INFRA/PERI tracker. When bus
timeout occurs, the system reboots and latches some values which could
be used for debug.
Rename VLPCFG_BASE to VLP_CFG_BASE.
TEST=Build pass, When we encounter a bus hang and HW watchdog triggers
a reset to the platform, the tracker will print the
latched information:
[INFO ] **Dump %s aw debug register start**
[INFO ] xxxxxx, 0x1c600000, 0x0, 63
This means that the 63rd entry latch accessing 0x1c600000 has a bus
timeout.
BUG=b:317009620
Signed-off-by: Xiwen Shao <xiwen.shao@mediatek.corp-partner.google.com>
Change-Id: Ib9784a370acec45ce36a800f3955b9cf96651298
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84929
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
MMinfra is the Multimedia Infrastructure. All the Multimedia modules
depend on it. This file adds some initial settings for MMinfra.
Test=Build pass
BUG=b:317009620
Signed-off-by: Xueqi Zhang <xueqi.zhang@mediatek.corp-partner.google.com>
Change-Id: Ie86f141a0957fc60d4973875c0dbcbdb57be1f75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Enable IDT_IN_EVERY_STAGE in qemu to easily debug HW breakpoints.
TEST: Can use breakpoints in pre RAM stages to debug invalid
memory accesses on QEMU.
Change-Id: If4a386d1adc788ff717899027881590b7c8b3369
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85593
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Make use of exception handling in every stage. Additionally this
enables breakpoints in all stages, making NULL dereferences and
stack overflows easier to detect.
TEST: Stack canary exceptions are seen in romstage on ibm/sbp1.
Change-Id: I8a9f12b9ae041ce47c14f2ef7f09b029d408260e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85569
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix regression introduced in commit 0351872731
("arch/x86: Add breakpoint to stack canary").
romstage_main writes to the stack-canary, but since that's expected
temporarily disable the breakpoint. This only caused a warning on
platforms that do select IDT_IN_EVERY_STAGE, since those install the
stack canary breakpoint.
TEST: No more exceptions are printed in romstage when IDT_IN_EVERY_STAGE
is enabled.
Change-Id: I7ebf0a5e8eaad49af77ab4d5f6b58fc849013b14
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The mainboard code relies on IPMI communication with the BMC.
Since the x86 and BMC start booting at the same time on ACPI G3
exit and the x86 is a bit faster, wait for the BMC to signal it's
done booting by pulling GPP_F4 low.
Fixes lots of error messages in coreboot about not working IPMI:
[ERROR] wait_ibf timeout!
[ERROR] IPMI START WRITE failed
[ERROR] ipmi_kcs_send_message failed
TEST: Once GPP_F4 is low IPMI communication over the KCS is also
working on ocp/tiogapass.
The log contains the line:
[DEBUG] BMC ready after 125560 ms
Change-Id: I925aff1ff1ffd3d7388835e62aad2ba339e52472
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85492
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to document 559910 Intel Connectivity Platforms BIOS
Guideline revision 8.2 and 9.2 specifications, both revision 0 and 1
are supported and share the same structure.
BUG=b:346600091
Change-Id: Id0e05a9db48445b9254701d2a09c19bfbd477284
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85586
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This commit rewrites the CPU topology initialization code to simplify
it and make it more maintainable.
The previous code used a complex set of if-else statements to
initialize the CPU topology based on the CPUID leaves that were
supported. This has been replaced with a simpler and more readable
function that follows the Intel Software Developer Manual
recommendation by prioritizing CPUID EAX=0x1f over CPUID EAX=0xb if
available.
The new code removes the need for separate functions to handle the
topology initialization for different CPUID leaves. It uses a static
array of bitfield descriptors to store the APIC ID descriptor
information for each level of the CPU topology. This simplifies the
code and makes it easier to add new levels of topology in the future.
The code populates the node ID based on the package ID, eliminating
the need for an extra function call.
Change-Id: Ie9424559f895af69e79c36b919e80af803861148
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85576
Reviewed-by: Jincheng Li <jincheng.li@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Stop using platform_fsp_memory_init_params_cb() as SoC specific romstage
hook and introduce early_pch_init() to do PCH init in romstage before
FSP-M runs.
Move PCH specific code into early_pch_init and call it from common code.
Change-Id: Id31a2018f5820098e83782b19a1672d2e35bdb83
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85505
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The azalia audio device is usually unused on server platforms.
Add code to hide it since FSP lacks this option and there's no
official bit in the IFD to disable it. The device is disabled
early to:
1. Prevent FSP from seeing the device being present. It could keep
an internal state that the device is working.
2. Prevent FSP-M from trying to detect codecs. This would increase
boot time.
3. Prevent FSP from becoming confused or crash when the device is
suddently missing as disabled by a ramstage PCI driver.
TEST: No HDA PCI device visible on ocp/tiogapass.
Change-Id: I84ac53621b2dcf7baa68f2efb30d0b7e77595c8d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85496
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Disable the debug code as there were unexplainable stack corruptions
detected on some platforms.
No problems were observed on:
- QEMU
- Xeon-SP
Change-Id: I1f1b9f01af7fbb0c19becf6ea53d436898584c5e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85594
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Apply ISH_FW_VERSION in Kconfig to improve boot time.
It won't do some ISH init task without the config on UFS sku and
cause boot to kernel time over 1.55 sec from G3 boot.
BUG=b:364971947
BRANCH=firmware-brox-16080.B
TEST=cbmem -c | grep "ISH version" -> ISH version: 5.4.2.7780
Boot to OS on jubilant, run bootperf test of G3 boot.
Confirm the test result is pass.
Change-Id: I31db0925a81b6ec68ee6afcb262e540ba7db206a
Signed-off-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Update header files for FSP for Meteor Lake platform to version 4122_21,
previous version being 3471_91.
FSPS:
1. Added UPD's ThcMode, ThcWakeOnTouch
2. Reserved bit changes
FSPM:
1 Added PchHdaSubSystemIds
BUG=b:329548127
TEST=Able to build and boot google/rex to ChromeOS.
Change-Id: I4a1164060f7e91f8fa4ada60421bf87fb17ad541
Signed-off-by: alokagar <alok.agarwal@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84656
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
