This commit adds wake functionality to the CNVi Bluetooth device by
registering to "GPE0_PME_B0" using the common CNVi block.
BUG=454341255
TEST=Able to wake up the device from a low power state using a keyboard
Bluetooth device.
Change-Id: I4bcbb34e1d53b3438f9e9f2b39f09d91e8dc7110
Signed-off-by: Varun Upadhyay <varun.upadhyay@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89982
Reviewed-by: P, Usha <usha.p@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure and enable the PCIe root ports and associated clocks for the
mc_ehl6 mainboard. This is necessary because the PCIe configuration
differs from the mc_ehl2 baseboard.
TEST=Boot into the OS and verify that all expected PCIe devices are
correctly detected.
Change-Id: Ie5ac3d437088d1db08f869317ef3e5712c3baa3e
Signed-off-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This new mainboard variant for the Siemens mc_ehl6 is initially based on
a direct copy of the mc_ehl2 configuration. This commit contains the
basic board setup with only minimal changes to enable the new variant.
Further specific adaptations for the mc_ehl6 hardware will be handled
in subsequent commits.
Change-Id: Ifcc730da492edb084e67762ce643f27b1a2576b0
Signed-off-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Now that we use the WATCHDOG_TOMBSTONE section to store the watchdog
event magic, there is no need to ask EC for the last reset reason. In
fact, with MEDIATEK_WDT_RESET_BY_SW enabled, EC doesn't even record the
watchdog reset reason.
Enable CHROMEOS_USE_EC_WATCHDOG_FLAG only if MEDIATEK_WDT_RESET_BY_SW is
disabled.
BUG=b:433636690
TEST=emerge-skywalker coreboot
TEST="elogtool list" contained "Hardware watchdog reset"
BRANCH=skywalker
Change-Id: Iac6ec72d5c148244ccbd7d1b02af78c359897d7d
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90174
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the watchdog timeout triggers a reset, the CPU will return to the
default frequency. If there is a mismatch between voltage and frequency,
the device will fail to reboot. Therefore, the kernel configuration
"mediatek,disable-extrst" is removed for MT8189, meaning the watchdog
timeout will trigger external reset, by notifying PMIC and EC via
AP_PMIC_WDTRST_L.
As we want to keep the watchdog status registers until coreboot runs,
the MT8189's EC simply ignores the external reset signal
AP_PMIC_WDTRST_L. Because EC ignores it, coreboot has to trigger the
secondary reset by another method other than watchdog hardware.
Therefore, introduce a Kconfig option MEDIATEK_WDT_RESET_BY_SW to
trigger the secondary reset by board_reset(), which is often implemented
by asserting a GPIO (for example GPIO_AP_EC_WARM_RST_REQ for MT8189).
BUG=b:433636690
TEST=emerge-skywalker coreboot
BRANCH=skywalker
Change-Id: Ib4c698bfd1b85705be05f40f385f4e252975c319
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90172
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
The purpose of the WATCHDOG_TOMBSTONE section is to temporarily record
the watchdog timeout event, before triggering the reboot. Then, in the
next boot, if WATCHDOG_TOMBSTONE contains the watchdog event magic, then
a watchdog event will be added to the event log.
The flow relies on the fact that the WATCHDOG_TOMBSTONE section can be
preserved across AP resets. However, for MT8189, the whole SRAM region
will be powered down during AP reset via GPIO AP_SYSRST_ODL (SYSRSTB).
Fortunately, the Kconfig option CHROMEOS_USE_EC_WATCHDOG_FLAG is also
enabled. Therefore, even if WATCHDOG_TOMBSTONE data is cleared, the
elog_handle_watchdog_tombstone() function can still obtain the correct
watchdog reset reason from EC.
On MT8189, L3C (used as SRAM_L2C) is powered on by default. Also, per
MT8189 PMIC configuration, a SYSRSTB reset will retain the L3C power.
Therefore, region data in SRAM_L2C can be preserved across AP resets.
Fix the WATCHDOG_TOMBSTONE preservation by moving it to SRAM_L2C.
Reduce PRERAM_CBMEM_CONSOLE by 1K for WATCHDOG_TOMBSTONE.
BUG=b:433636690, b:456672760
TEST=emerge-skywalker coreboot
TEST=watchdog event added to eventlog on WDT timeout
TEST=cbmem logs preserved on WDT timeout
BRANCH=skywalker
Change-Id: Id1cfc2700301ebb0b6399356b884b2473c883445
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90171
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Update EN_SPK_PA pin configuration based on the schematic to enable speaker function.
schematics: RUBY_EVT_0902_2112.pdf
BUG=b:452216678
TEST=Build FW and boot to OS, verify that the speaker is functioning
by playing a YouTube video.
Change-Id: Iabb3e9d214841aaa155ce5b782740ad0722722fa
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90169
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Add support to configure DFSR table, introduce qupv3_clock_v2
structure to calculate register addresses for serial engines 2
and 3. Update CBCR registers to use the new structure for QUPv3
clock enablement.
BUG=b:444617760
TEST=Create an image.serial.bin and ensure it boots on X1P42100.
Dump DFSR registers for corresponding QUP and check if values are
updated properly into correct register address.
Change-Id: Ibd7e4bf121bd99130336047a50ed70d4cbec2234
Signed-off-by: Swathi Tamilselvan <tswathi@qualcomm.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90145
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Toggle the RTC BUC control bit for Top Swap bootblock selection based on
the "attempt_slot_b" flag CMOS option, allowing to select which of the
BOOTBLOCK or TOP_SWAP regions to boot from.
This means that after an update, the CMOS option can be set to boot from
the newer TOP_SWAP bootblock. In case of failure, CMOS can be cleared to
revert to the known-good base BOOTBLOCK.
This is part of ongoing implementation of a redundancy feature proposed
on the mailing list:
https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/C6JN2PB7K7D67EG7OIKB6BBERZU5YV35/
Switching between identical bootblocks doesn't impact further boot flow,
i.e. selecting which FMAP region to load consecutive stages from.
That is to be enabled in following patches.
So far tested and enabled for the Alder Lake SoC.
TEST=Boot VP6650, setting the attempt_slot_b flag to different values,
observing that it resets/continues booting correctly.
Change-Id: Ib183a1f72ee8585b2c4ad4376344de33ff54cbb9
Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
The recent increase of the RW size to 1756KB (CB:89545) has led to an
FMAP incompatibility. This issue arises during testing when both the ToT
firmware (which utilizes a new FMAP layout) and the firmware
branch-built firmware (which relies on an older FMAP layout) are used on
the same device.
To address this testing failure and streamline the testing process, the
updated FMAP will be exclusively implemented for the new variant. The
Navi and Hylia devices will continue to use the legacy FMAP.
BUG=b:461559917,b:463050048
TEST=emerge-{rauru,tanjiro} coreboot chromeos-bootimage
Change-Id: Icb4a12030f7a2e05757c903b70899c07b92c9875
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Chen-Tsung Hsieh <chentsung@google.com>
Add additional register configuration for the Realtek ALC257 audio
codec on the Lenovo ThinkPad T480. This includes:
- Hidden register SW reset sequence
- ClassD 2W amplifier configuration
- Jack detection (JD1) setup for headphone port
- Silence data mode threshold setting at -84dB
Shamelessly taken from google/brya/variants/pujjolo/hda_verb.c
Change-Id: Ib77138d782ceb9feeaef82935bc1c0d5c3066183
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90023
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Add driver to read 'hwid' file from CBFS and use it for SMBIOS product
name. Processes the ChromeOS-format HWID string by removing prefix
after colon, trimming whitespace, and extracting base name before
any hyphen/space. Returned string is normalized to have the first
character/letter capitalized, and the rest lower case. If no HWID file
is found in CBFS, the fallback is CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME.
This driver is intended to allow ChromeOS devices running upstream
coreboot to persist their board's unique HWID and use it as the SMBIOS
board name, but it is not limited to that function.
TEST=tested in MrChromebox downstream. Multiple devices which use the
same ChromeOS board but differ in HWID can use the same firmware image
and still be properly identified.
Change-Id: I1af1df4c79858d23ef71400abe72f41eec6c25c6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90063
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This is going to be used in some devices in place of KEY_ASSISTANT, map
it.
BUG=b:446676921
TEST=flashed and tested on a brox board, checked that the correct code
is generated with evtest
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Change-Id: I006c232c2924e8b6dc06338b0282c76f1f529a9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90026
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like some devices may be using the capslock key, this a standard
code, just map it.
BUG=b:446677367
TEST=flashed and tested on a brox board, checked that the correct code
is generated with evtest
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Change-Id: Ieb0f55e7f25a1b34d226efe12ad9dc481a53a082
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90025
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Chromium OS EC has some specialized handling of chromebook specific
function keys on the keyboard top row, these have a function specific
action key code that is exposed to the OS and used to map their
position, and also a specific scancode that has to be mapped to a Linux
event code.
This adds the necessary mapping for KEY_HOMEPAGE, which is going to be
used in new devices.
The scancode picked is 0xe012, which maps to e02a or 0xaa, the
corresponding EC CL is:
https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/7118961
BUG=b:446007724
TEST=flashed and tested on a brox board with chromiumos, checked the
code with evtest
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Change-Id: I395721a342f507453dae19373df2f189ac1b5dac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90024
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
memory_info with dimm_info entries is available as CBMEM_ID_MEMINFO.
Moving the structures definitions to the commonlib allows the payloads
to easily access the memory information.
BUG=b:450374306
TEST=Build and boot Google/Brya
Change-Id: I25e788d5afd668e93f8ea60adaefb7b8b5d5ec28
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
To support Memory Tagging Extension (MTE), configure booker
(custom CI-700) registers related to MTE to set up MTE tag address.
According to CI-700 documentation, the por_mtu_tag_addr_base register is
only accessible by Secure accesses. Therefore these registers are now
configured in coreboot ramstage before passing to payloads.
BRANCH=rauru
BUG=b:438666196
TEST=manual test
Change-Id: I0d98cfee3e208a559116f84362528f005ea6f2c8
Signed-off-by: Jeff Xu <jeffxu@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90141
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
This commit updates the linker script to properly define and name the
DMA coherent memory regions used before and after DRAM initialization.
1. Rename Pre-RAM DMA Region:
The existing `DMA_COHERENT` region allocated in BSRAM at `0x14857000` is
renamed to `PRERAM_DMA_COHERENT`. This aligns the linker script with the
code changes (in `mmu.c`) which use the more specific name for the early
boot DMA buffer.
2. Add Post-RAM DMA Region:
A new region, `POSTRAM_DMA_COHERENT`, is defined at the very start of
DRAM (`0x80000000`) with an 8KB size. This region is intended for
general-purpose DMA operations that occur after DRAM is active,
ensuring a reserved, known, and uncached region for peripherals.
The memory map diagram comments are also updated to reflect these new
region names.
BUG=b:456953373
TEST=Able to build and boot google/quenbi.
Change-Id: I6fb4b9bf3425b311169ac43e1997f6574b571e00
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90098
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This commit relocates the following two regions:
1. `ddr_information`
2. `WATCHDOG_TOMBSTONE`
Previously, these regions were allocated in a higher address range
(starting near 0x14800000).
The regions are now defined within SSRAM`:
- `ddr_information` is moved from `0x14860000` to `0x146ABFE8`.
- `WATCHDOG_TOMBSTONE` is moved from `0x14818FFC` to `0x146ABFFC`.
This memory map change updates the linker script's visual diagram and
section definitions to reflect the new memory layout.
BUG=b:456953373
TEST=Able to build google/quenbi.
Change-Id: I4545722a836ec472e8086d1a941515cb3956c763
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90052
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MMU configuration in qc_mmu_dram_config_post_dram_init() needs to
include the memory region allocated for DMA coherent buffers.
Map the `postram_dma_coherent` region as UNCACHED_RAM to ensure memory
writes bypass the CPU cache hierarchy.
The mapping is only configured if the `_postram_dma_coherent` address
is different from `_preram_dma_coherent` address aka migration of the
region.
This is necessary for DMA operations that occur after DRAM is
initialized.
BUG=b:456953373
TEST=Able to build google/quenbi.
Change-Id: If5f625ad74f4f6ea244c8b377543be3666122cea
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Refactor the DMA coherent memory region definition to support
stage-specific allocations.
In some boot flows, it is necessary to define separate DMA coherent
buffers for the early boot stage (e.g., romstage/bootblock) and the
later stage (ramstage). It allows the firmware to use only the memory
it needs, where it needs it, and prevents small-scale memory constraints
from crippling the overall boot flow.
The arch-specific, and now redundant, definitions of DMA_COHERENT are
removed from arm/memlayout.h and arm64/memlayout.h.
BUG=b:456953373
TEST=Able to build google/quenbi.
Change-Id: Ic32d14dda6cda0f731233dd3d86f3215c6af3637
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90049
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch relocates the coreboot stack from the BSRAM (Boot IMEM)
region to the SSRAM (Shared System RAM) region.
The 16K stack definition is moved from:
BSRAM region (0x14850000)
To:
SSRAM region (0x14680000)
This move is crucial because the BSRAM region is actively cleared during
the later stages of the IP loading process, which would wipe the stack
and lead to instability. Placing the stack in the persistent SSRAM
ensures it remains accessible throughout the early boot process.
BUG=BUG=b:456953373
TEST=Able to build google/quenbi w/ new stack region.
Change-Id: I59cd14fed2a5907bcbb8bed027dd5a55eb73e56d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90137
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add boot timestamps to measure the duration of loading the Secure OS
(BL32) payload in the `run_bl31()` function.
The Secure OS is loaded if the Kconfig option
`CONFIG_ARM64_USE_SECURE_OS` is enabled. The new timestamps are:
- "TS_TFA_LOAD_BL32_START": Placed immediately before the Secure OS
(BL32) loading process begins.
- "TS_TFA_LOAD_BL32_END": Placed after the BL32 entry point information
is set up and before the BL33 parameters are finalized.
This instrumentation helps profile the boot time cost of the Trusted
Firmware-A (TFA) BL32 component loading.
Change-Id: I6ca74b8d4b11dfab4829f8bc5fbaa39ee5212137
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Instrument the Qualcomm QCLib flow with timestamps to measure
execution time for both the initial loading/running phase and the
subsequent re-entry phase.
The timestamps are placed as follows:
- TS_QUALCOMM_QCLIB_INIT_START/END: Tracks the execution of
`qclib_load_and_run()`.
- TS_QUALCOMM_QCLIB_REINIT_START/END: Tracks the execution of
`qclib_rerun()`, which typically handles the AOP bring-up.
This instrumentation helps in profiling and optimizing the boot
performance on Qualcomm platforms.
Change-Id: I200ea5a78f4630000e80aed6dc38581af4d2e8aa
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90112
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch adds new timestamp IDs to track the execution flow within
the Qualcomm QCLib and the loading of the Secure OS (BL32) by the ARM
Trusted Firmware (TFA).
The following new IDs are introduced:
- TS_QUALCOMM_QCLIB_INIT_START (980)
- TS_QUALCOMM_QCLIB_INIT_END (981)
- TS_QUALCOMM_QCLIB_REINIT_START (982)
- TS_QUALCOMM_QCLIB_REINIT_END (983)
- TS_TFA_LOAD_BL32_START (998)
- TS_TFA_LOAD_BL32_END (999)
The reserved ID ranges are updated to accommodate these new vendor-
specific and architecture-specific timestamps:
- Intel/FSP range reduced from 950-989 to 950-980.
- A new range 980-990 is allocated for qualcomm/qclib.
- The Intel ME continued range is updated from 990-999 to 990-997.
- A new range 998-999 is allocated for ARM Trusted Firmware.
Change-Id: I904ac36862212a86961383dfe5e9b0f7ef0f02ea
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90111
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
We used to put SMBIOS header and other data before VPD. That is not the
case anymore. New device will write the VPD starting at 0 instead of
0x600. Search VPD at 0x0 to support this.
TEST=build and boot google/geralt. VPD is found both at 0 and at 0x600.
Change-Id: I7072f7c646b6b55d11bc06dba5674828246fa1d0
Signed-off-by: Jian-Jia Su <jjsu@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
S3 now works on Windows, so don't recommend switching to S0IX.
Change-Id: I5f5dac0f2bf5eddbfef041b12a134bb70fdd7577
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90125
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the datasheet and the LCD team’s response, increase Touch
IC enable delay time to resolve touch failure after resume.
BUG=b:458190286
TEST=1. Checked the touch screen power sequence waveform. The result is in b:458190286#comment4.
2. The touch feature works after resume.
Change-Id: Ia5a1d028721b1181d38730c23b27a80fa97e0dd7
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Due to project requirements, GPP_D16 and GPP_D17 are not used. This has been confirmed by both the schematic and the LCFC hardware engineers. Therefore, they should be removed from the fw_config.
schematics: RUBY_EVT_0902_2112.pdf
BUG=b:452216678
TEST=Build FW and boot to OS, check DMIC function works.
Change-Id: I195ad082836d3b8a4fa79cbbc9e4bffaec745011
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90071
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Update the silence detection threshold based on the new verb table
provided by Realtek team.
BUG=b:446120613
TEST=reboot, open camera app, press shutter. There should be sound.
Change-Id: I7d27a38e4068a72f4fb04321e46f0266161572e1
Signed-off-by: Terry Cheong <htcheong@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90118
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create a new header with CFR objects for keyboard backlight and
automatic fan control, which mainboards can include in their
setup menus in order to expose the options. The visibility of the
options are controlled by callbacks which test for device presence.
Change-Id: I2386b527f65b2e3b4ca43b9b65b69040abee00ad
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Allow enabling of automatic fan control via a setup option, while
preserving the functionality of the existing Kconfig symbol.
TEST=tested hooked up to a CFR option to toggle automatic fan control
at boot, with visibility controlled by fan presence, on a range of
ChromeOS devices with and without a PWM-controlled fan.
Change-Id: I0510c0d0bd79106036f77d59e04d455ee904ce6e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89830
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add google_chromeec_has_fan() to determine if a board has a fan or not.
The function first tries the EC feature flag (EC_FEATURE_PWM_FAN),
falling back to a RPM read test if the flag is unavailable.
TEST=tested hooked up to a CFR option to enable auto fan control at
boot, with option visibility controlled by fan presence, on a range
of Chromebooks with and without PWM-controlled fans.
Change-Id: I2a920709f0e6780c779a87568d6a8d18f817c76d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89829
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
The EC controls the power and reset to some of the PCIe devices.
Change-Id: Ic607978e32486ecd4563c32cd6a5ff1dfd125013
Signed-off-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87221
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Also adds some help messages to make it more clearly on what this
Kconfig achives.
Change-Id: Ic74ea602c038f029a5b7b1edb256c23c6ad1ba9f
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
AMD Renoir soc is very similar to Cezanne and has been used without
differentiation until now. Create the separation between SOCs using
Kconfig option to facilitate the customization of different features.
Also update SOC_AMD_RENOIR use on the crater mainboard.
Change-Id: I4783c4e3b17032b6d26ef67ddf954df3ce68fdf0
Signed-off-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87215
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For the t470s variant, this patch replaces the vendor SPD binaries for
soldered-on RAM with ones generated from spd_tools. This is in
preparation for adding variants with more complex onboard RAM
configurations.
This patch has been successfully validated on hardware (Thinkpad T470s
20JT-S16E00 with 4GB soldered-on RAM and unpopulated DIMM slot).
Change-Id: I9cde4f05472105c238b3a8ee94cdedb89db08198
Depends-On: Ied92619130feaa160d01f75bc38230ab6a024ace
Signed-off-by: Johann C. Rode <jcrode@gmx.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90027
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds parts used on Lenovo Thinkpads:
Micron MT40A512M16HA-083E:A
Micron MT40A1G16HBA-083E:A
Samsung K4A8G165WB-BCPB
Micron MT40A512M16JY-083E:B
Micron MT40A1G16WBU-083E:B
Samsung K4A8G165WC-BCRC
Samsung K4AAG165WB-MCRC
SKHynix H5AN8G6NAFR-UHC
SKHynix H5AN8G6NAMR-UHC
Micron MT40A512M6LY-075:E
Micron MT40A256M16GE-083E
Samsung K4A4G165WE-BCRC
The SPD data (timing, configuration, etc.) has been extracted from datasheets and laptop schematics. When there has been conflicting data between these data sources, slower (safer) values were picked.
Change-Id: Ied92619130feaa160d01f75bc38230ab6a024ace
Signed-off-by: Johann C. Rode <jcrode@gmx.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90032
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, pressing the power button results in the EC powering off the
system without letting the OS cleanly execute its shutdown procedures.
Sending command 0x3e with an argument of 1 to the EC tells it to route
power button events to the host so that the OS can determine what to do.
This command was found in the ec/google/wilco code in coreboot, which is
used on Dell's Latitude Chromebooks. Based on the CONFIG_EC_GOOGLE_WILCO
help text, the "Wilco" ECs run a modified version of Dell's typical
Latitude EC firmware, so it is likely that the two implementations share
commands. Examining LPC traffic on the Latitude E6400 did show that
vendor firmware was sending a 0x3e command to the EC, and reimplementing
it in coreboot allowed power button events to be handled by the OS.
Change-Id: I5ded315270c0e1efbbc90cfa9d9d894b872e99a2
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
As of commit 31fc5b06a6 ("device: Introduce reworked azalia verb
table"), all boards using the old azalia verb table format must select
CONFIG_AZALIA_USE_LEGACY_VERB_TABLE. The generated output of autoport
uses the old format, so select the config.
This is only meant to be a temporary measure as opposed to reworking
autoport to produce the new format, as I would rather incorporate
hda-decoder's functionality to generate hda-verb.c instead of
duplicating efforts. Support for the new format in hda-decoder is
currently WIP on CB:84357.
Change-Id: I54c6a92a69039eb747ee8cc6d5186dc3a3c6acc8
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90055
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new Kconfig option, FSP_VGA_MODE12_MONOCHROME, to allow the
system to use a 1-bit-per-pixel (1bpp) planar VGA buffer during FSP
initialization instead of the standard 4bpp buffer. This is useful
in romstage where every byte is critical.
When this option is enabled, the FSP is expected to handle the
internal replication of the 1bpp data across the other three
color planes to render the monochrome image.
Key changes:
- Introduce FSP_VGA_MODE12_MONOCHROME Kconfig option.
- Automatically select FSP_VGA_MODE12 when the monochrome option is
used.
- Set FSP_VGA_MODE12_BPP to 0x1 when FSP_VGA_MODE12_MONOCHROME is
selected.
BUG=b:406725440
TEST=Verify VGA text rotation on Google/Felino.
Change-Id: Ie77c40025c13e52188439fffedc834c26338bfe3
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
