Before this patch, gpio_configure_pads_with_override called
program_gpios once for each GPIO that needed to be configured which
resulted in base_num_pads - 1 unneeded master_switch_set/
master_switch_clr sequences for the gpio_configure_pads_with_override
call. Instead implement gpio_configure_pads_with_override as the more
generic function and program_gpios as a special case of that which
passes an empty override configuration and override pad number to
gpio_configure_pads_with_override.
TEST=GPIO configuration and multiplexer register values are the same for
all GPIOs on google/guybrush right before jumping to the payload before
and after the patch.
Change-Id: Ia8e47b2a278a1887db5406c1f863ddafa6a68675
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Earlier generation platform used `HeciEnabled` chip config (set to 0)
and HECI_DISABLE_USING_SMM Kconfig to make the CSE function disable at
the end of the post. `HeciEnabled` chip config remains enabled in all
latest generation platforms hence drop HECI_DISABLE_USING_SMM Kconfig
selection from SoC Kconfig as CSE remains default enabled.
BUG=b:200644229
TEST=No functional impact during boot as CSE (B:0, D:0x16, F:0) device
is listed with `lspci`.
Change-Id: I5278e5c2e015b91bb3df3a3c73a6c659a56794b5
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
The current power sequencing for the SSD does not work in a non-serial
enabled BIOS image. It appears that the FSP scans the PCIe RPs before
the SSD has time to prepare itself for PCIe, so the FSP disables the RP
and so depthcharge cannot find a boot disk.
Changing the power sequence timing to enable power in bootblock and
deassert reset in ramstage follows the SSD's power sequence and
allows it to be discovered by the FSP so the RP does not get disabled.
BUG=b:199714453
TEST=build, boot into SSD, and run reboot stress test.
Change-Id: I5e7943a6cc88bc02bcbd97a1086b2d8044d7b1c3
Signed-off-by: Wisley Chen <wisley.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
In this file bool, uint8_t and uint32_t are used, so include types.h
directly to have those types defined instead of relying to have those
included indirectly via amdblocks/gpio_banks.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6f4626a50219fab818e8bc5087961a731b44e71b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Loading QUP FW as per herobrine and piglin configuration
for I2C, SPI and UART.
As part of the code clean up, update the header files of the
QUP drivers with the correct path.
BUG=b:182963902
TEST=Validated on qualcomm sc7280 development board.
Signed-off-by: Rajesh Patil <rajpat@codeaurora.org>
Change-Id: Ic218c6a91ffc4484830446d707d1f3403e2dc46b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Currently, if LIB_SPD_DEPS contains an SPD file which doesn't exist, the
file is silently skipped when creating spd.bin. Instead, fail the build.
BUG=b:191776301
TEST=Build test on brya. Build fails if a non-existent file is included
in LIB_SPD_DEPS.
Change-Id: I1bdadb72e087c2ee7a88fbab2f3607bd400fa2e4
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Remove the override in guybrush devicetree that configured in-band eSPI
alerts. This will result in guybrush using dedicated open-drain eSPI
alerts. Guybrush boards must be reworked to connect the eSPI alert line,
otherwise they will not boot with this change
BUG=b:198596430
TEST=Boot on reworked guybrush
BRANCH=None
Change-Id: I185eec773336fb662d9fe7f4c11991813e4d7cd6
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57778
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change replaces the device tree walks with device pointers by
adding alias for following devices:
1. FPMCU
2. WWAN
Additionally, this change drops the __weak attribute for variant_has_*
functions as there is no need for different implementations for the
variants.
Change-Id: I8af5e27f226270e6b40a50640c87de99a5a703f7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
On some dedede variants, USB port 2.3/3.3 might be connected to either
LTE device or Type-A external port depending upon FW_CONFIG. Commit
856b579 ("mb/google/dedede/var/kracko: Update LTE USB port
configuration") enabled Type-A external port by default in override
tree and updated the config dynamically for LTE USB device if
FW_CONFIG indicated support for it. This was required because sconfig
lacked the support for multiple override devices. Commit
b9c22e0 ("util/sconfig: Compare probe conditions for override device
match") fixed this behavior in sconfig and now we can add multiple
override devices using different FW_CONFIG probe statements in
override tree. Hence, this change moves the LTE USB device to override
tree for metaknight, kracko and drawcia variants.
In addition to that, drawcia needs to be update reset_gpio depending
upon board_id. Thus, alias `lte_usb2` is used in drawcia override tree
to fix the reset_gpio for older boards i.e. board_id <= 9.
Change-Id: Ie5b205594680d9c2b8543c5c99325d95620cafd2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
On sasukette, codec device might be either 10EC5682 or RTL5682
depending upon the provisioned FW_CONFIG value for
AUDIO_CODEC_SOURCE. The HID for the device was updated in ramstage.c
because sconfig lacked the support for multiple override
devices. Commit b9c22e0 ("util/sconfig: Compare probe conditions for
override device match") fixed this behavior in sconfig and now we can
add multiple override devices using different FW_CONFIG probe
statements in override tree. Hence, this change moves the codec device
to override tree and drops the special handling in ramstage.c
This change also probes for UNPROVISIONED value of FW_CONFIG for
"10EC5682" device since some devices might have shipped with
UNPROVISIONED value and using "10EC5682" device.
Change-Id: I909a29c3df0cbb7ac3c07ca7663a49ad47007232
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: I95753fa536fae8ca4bb95007419875815c1bcb06
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: I1a55df754c711b2afb8939b442019831c25cce29
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: Idfaa9a24f7b7fefa4f63ab8e3bc4ee6a0f1faedf
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: Ie86822f22aa5899a7e446398370424ca5a4ca43d
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Fix the two issues below.
SB800: sb_Before_Pci_Init
shift out of bounds src/vendorcode/amd/cimx/sb800/PCILIB.c:49:18
ubsan: unrecoverable error.
SB800: sb_Before_Pci_Init
shift out of bounds src/vendorcode/amd/cimx/sb800/PCILIB.c:66:18
ubsan: unrecoverable error.
Found by: UBSAN
Change-Id: Id42e62d35f59793bad10998f14422ab7fb4fc029
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51283
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
This change provides helper macros for generating pointer name and
weak pointer definition for devices using alias names. This will be
helpful for developers to reference the device pointer with alias
names used in the device tree.
Change-Id: I3a5a3c7fdc2c521bac9ab3336f5a6ebecd621e04
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57738
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
