Incorrect size of the einj structure was being used, which created an
invalid checksum message by the OS. This patch fixes the issue.
Test=Booted to Linux on Deltalake mainboard and verified invalid checksum
message is not logged in syslog. Exact message -> 'ACPI BIOS Warning
(bug): Incorrect checksum in table [EINJ] - 0xDA, should be 0xD9'
Change-Id: I2b1722d6960d4a62d14fb02ac5e8838397e12f92
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54787
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
scan-build found a dead assignment, that the value stored to `res` is
never read. Use `pci_dev_read_resources()` instead, as done in
`sb/intel/common/smbus_ops.c` since commit 5f734327
(sb/intel/common/smbus_ops.c: Clean up read resources) avoiding the
assignment.
Change-Id: Ic59063b05a45dca411bf5b56c1abf3dd66ff0437
Found-by: scan-build (coreboot toolchain v0ad5fbd48d 2020-12-24 - clang version 11.0.0)
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54904
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ESPI_SLAVE_CHANNEL_READY is a read-only bit from the host perspective.
It is set when the eSPI peripheral has configured the channel.
We actually want to set the ESPI_SLAVE_CHANNEL_ENABLE flag. This never
caused an issue before because the peripheral channel is enabled by
default after PLTRST# is deasserted. This does fix the case where
periph_ch_en == 0. It now properly clears the enable flag.
BUG=b:188188172, b:188935533
TEST=Boot guybrush to OS, perform warm reset
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I24e0734d5652601ae9c967da528fec5e3f780991
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The ChromeEC might take longer than 1ms for the peripheral channel to be
enabled. The PLTRST# interrupt handler takes about ~539us.
This doesn't account for the time it takes for the interrupt handler
to be scheduled. Increasing the timeout to 10ms gives ample time.
BUG=b:188188172, b:188935533
TEST=Boot guybrush and no longer see channel enable errors
Suggested-by: Rob Barnes <robbarnes@google.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib6db577bf06175ceb17b446af706ad8c9f891481
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54788
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the introduction of fw_config support in coreboot, it is possible
for mainboards to control the state of a device (on/off) in ramstage
using fw_config probe conditions. However, the device tree in
immutable in all other stages and hence `is_dev_enabled()` does not
really reflect the true state as in ramstage.
This change adds a call to `fw_config_probe_dev()` in
`is_dev_enabled()` when device tree is immutable (by checking
DEVTREE_EARLY) to first check if device is disabled because of device
probe conditions. If so, then it reports device as being
disabled. Else, dev->enabled is used to report the device state.
This allows early stages (bootblock, romstage) to use
`is_dev_enabled()` to get the true state of the device by taking probe
conditions into account and eliminates the need for each caller to
perform their own separate probing.
Change-Id: Ifede6775bda245cba199d3419aebd782dc690f2c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54752
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a helper function `fw_config_probe_dev()` that allows
the caller to check if any of the probe conditions are true for any
given device. If device has no probe conditions or a matching probe
condition, then it returns true and provides the matching probe
condition back to caller (if provided with a valid pointer). Else, it
returns false. When fw_config support is disabled, this function
always returns true.
Change-Id: Ic2dae338e6fbd7755feb23ca86c50c42103f349b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54751
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`probe_list` member in `struct device` is present in all stages,
however, util/sconfig emits the list only when !DEVTREE_EARLY. This
change ensures that `probe_list` is emitted in all stages. In follow
up changes, this is used to get the correct device state using probe
conditions.
Change-Id: I61f7e909d48b616ac2127a5a9f36bdf4817a5165
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
fw_config is unprovisioned in the factory for the first boot. This is
the only case where fw_config is left unprovisioned. On first boot in
factory, fw_config gets correctly provisioned by the factory
toolkit. When fw_config is unprovisioned, it is not always possible to
make a guess which device to enable/disable since there can be certain
conflicting devices which can never be enabled at the same time. That
is the reason the original implementation of fw_config library kept
fw_config as 0 when it was unprovisioned.
CB:47956 ("fw_config: Use UNDEFINED_FW_CONFIG to mean unprovisioned")
added support for a special unprovisioned value to allow any callers
to identify this factory boot condition and take any appropriate
action required for this boot (Ideally, this would just involve
configuring any boot devices essential to getting to OS. All other
non-essential devices can be kept disabled until fw_config is properly
provisioned). However, CB:47956 missed handling the
`fw_config_probe()` function and resulted in silent change in behavior.
This change fixes the regression introduced by CB:47956 and returns
`false` in `fw_config_probe()` if fw_config is not provisioned yet.
Change-Id: Ic22cd650d3eb3a6016fa2e2775ea8272405ee23b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54750
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit ce0e2a0140 (drivers/intel/fsp2_0:
use FSP to allocate APEI BERT memory region) adds a mechanism to reserve
the BERT region inside the coreboot code, so we can get rid of the
workaround to reserve it in the FSP and return the location in a HOB.
mcfg->bert_size defaults to 0 which makes the FSP not generate the
corresponding HOB, but that field is planned to be removed at least on
Cezanne, so don't explicitly set it to 0.
BUG=b:169934025
TEST=BERT table that gets generated in a follow-up patch for Picasso
points to expected BERT region and Linux is able to access, decode and
display it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaca89b47793bf9982181560f026459a18e7db134
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52584
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most of the time when INIT_BOOTBLOCK is selected, the cache should be
empty here anyway, so this is a no-op. But when it's not empty that
means the bootblock loaded some other file before it got to the TPM
init part (which is possible, for example, if hooks like
bootblock_soc_init() load something).
Change-Id: I4aea86c094abc951d7670838f12371fddaffaa90
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In order to fill out static entries for a _PRT table for
soc/intel/common, the PIRQ<->IRQ mapping is required. This patch adds
a function lpc_get_pch_pirq_routing() which returns this mapping.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib215fba54573c50a88aa4584442bd8d27ae017be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Enable ASPM, Common Clock and Clock Power Managment. Accomplish this
by adding the options in the platform Kconfig as well as dxio
descriptors.
BUG=b:187743927
TEST=Boot to ChromeOS and see ASPM, CC and Clock PM enabled with lspci
Change-Id: I9d6e606763798afc6b797d7d24ee7cae09f9e33f
Signed-off-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54681
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable ASPM, Common Clock and Clock Power Managment. Accomplish this
by adding the options in the platform Kconfig as well as dxio
descriptors.
BUG=b:187743927
TEST=Boot to ChromeOS and see ASPM, CC and Clock PM enabled with lspci
Change-Id: Iefc4b5b489cb8caf59f21dd4333d7af66ba47c32
Signed-off-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54282
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
UI monitors this input event and sends global mic mute command to CRAS
when the physical switch is toggled.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on DUT.
Apply crrev.com/c/2870806 with chrome cmdline flag and verify global
mute is triggered.
Verify sequences of switch toggle and suspend/resume.
Change-Id: Id89947885fdd96c5b5d598bda6db127daf298dc3
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Added SW_MUTE_DEVICE event type for mic mute switch.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on puff:
/dev/input/event3: mic_mute_switch
UI event_device_info receives the proper name.
Change-Id: I09c52dc3df63e266c73741b102a22f8a2b896791
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Added the label field to the gpio_keys _DSD so that the kernel driver
can use a meaningful name instead of the generic _HID PRP0001.
BUG=b:184593945
BRANCH=puff
TEST=build image and verify with evtest on puff:
/dev/input/event3: mic_mute_switch
UI event_device_info receives the proper name.
Change-Id: I0377851b9cf23bab31930aed6e7de91b4ac3505b
Signed-off-by: Ben Zhang <benzh@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
