Add watchdog support for MT8189.
BUG=b:379008996
BRANCH=none
TEST=build pass and WDT makes DUT reboot when MTK_WDT_MODE_ENABLE is
set.
Change-Id: I496fce91e52393db31fd1fb5a1c68d91b2ed073e
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85678
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Starting from MT8196, MediaTek platform introudces a new blob named
MediaTek firmware support package (mtk-fsp). The features of mtk-fsp
include but not limit to,
- Security settings, e.g: Device Access Proctection Control, Security
Memory Protection Unit.
- Initialization for advanced CPU frequency control.
This patch implements APIs for
1) Exchanging data between coreboot and mtk-fsp.
2) Loading and running the mtk-fsp blob at a specific bootstage.
BUG=b:373797027
TEST=emerge-rauru coreboot; Run mock blob and return from mock blob.
Change-Id: Idef3518f9763fe5f74adb459c137db164563e483
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85665
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update timer macro name for common.
The new ICs (e.g. mt8196, mt8189) will no longer use GPT. In order
to improve code readability, replace GPT_MHZ with TIMER_MHZ for
existing SoCs.
BUG=b:379008996
BRANCH=none
TEST=Build pass, Macro name is correct.
Change-Id: I02f18bfa5b5912f28e322d40cd46823a0095bbf4
Signed-off-by: Ke Zheng <ot_ke.zheng@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85681
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for loading SPM firmware from CBFS to SPM SRAM
and fix the SPM register definitions. SPM needs its own firmware to
enable SPM suspend/resume function which turns off several resources
such as DRAM/mainpll/26M clk when linux system suspends.
coreboot log:
CBFS: Found 'spm_firmware.pm' @0xadf00 size 0x5a60 in mcache @0xfffdd3c
mtk_init_mcu: Loaded (and reset) spm_firmware.pm in 3 msecs (30080 byt)
TEST=build pass
BUG=348147674
Change-Id: Ie09346f46cb734c74776b760485e7f35d4357e5e
Signed-off-by: Wenzhen Yu <wenzhen.yu@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85599
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename GSPI2 to GSPI0A to align with the latest Intel documentation
and platform specifications (doc: 815002)
BUG=b:377595986
TEST=Able to see 0x12.6 device is visible using `lspci`.
Change-Id: I9b87d38e44c07a053104b53df38ee1ce14a86c7f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: YH Lin <yueherngl@google.com>
This change adds the ACPI name "SPI2" for the GSPI2 device
in the Panther Lake SOC.
Replace space with tab for PCI_DEVFN_GSPI2 macro.
w/o this patch:
[ERROR] Missing ACPI Name for PCI: 00:12.6
[ERROR] Missing ACPI Name for PCI: 00:12.6
w/ this patch:
No error
Change-Id: I404ddb893b82836e06d0f52a6d6f2aff2273d8c6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85712
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure GPP_F15 to generate an IRQ, that is used by the Virtual
Button driver to report whether the tablet is docked or undocked to
the OS.
Change-Id: I0815da09bd7ffd3926622e10df6a06ab5593dc2d
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim <max.senia.poliak@gmail.com>
This patch adds support for the Intel Virtual Button driver, which
reports whether a tablet is docked or undocked. The GPIO used for
detection is hardcoded to GPP_F15 for now, specific to the
`mb/starlite_adl` board.
The GPIO value is returned to the HID driver via the `_STA` and
`VGBS` methods. These methods ensure proper notification to the OS,
allowing it to show or hide the virtual keyboard depending on the
docking status.
Tested on `starlite_adl` with Ubuntu 24.04, confirming the virtual
keyboard appears when the tablet is undocked and hides when docked.
This was verified with ACPI debug enabled, as dmesg does not
report the state of the GPIO.
Change-Id: I574a1b2d3907b2341a0dfdc412151d574ba4848e
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83879
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
touchpanel
1. Reuse DB_A (now DB_A_HDMI_LTE) as the HDMI switch.
2. Turn off the Type-C port C1 when using HDMI because both of them use
the same interface in hardware.
3. Use TOUCH_PANEL_I2C_GENERIC (formerly TOUCH_PANEL_DISABLE) to
support other screen models as we cannot have different fields to
support individual touch screen models.
BUG=b:365445053
TEST=emerge-nissa coreboot and run in DUT
Change-Id: I1900658f7c2e09180287a4e61f02e04be203b6e9
Signed-off-by: Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85512
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Kyle Lin <kylelinck@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
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>
