Using enum cb_err as return type instead of int improves the readability
of the code. This commit only changes the return value of the static
functions in this file keeping the external interface identical.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I80300e0b24591fc660c3134139b9257e002cdbbb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Current max count for camera power ops is 5 which is not sufficient.
If we increase the ops by 1 in current variants the compiler
will not throw error for intel mipi camera driver.
Hence increase current max count for camera power ops to 6 from 5.
BUG=b:214665783
TEST=Build and boot to OS
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: I4f4c090f2275616816dfc697f27520cd1cbc1a80
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61146
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Without acpi name, acpi_device_path will return NULL.
<NULL>: Intel USB4 Retimer at GENERIC: 0.0
Replace with usb4_retimer_scope for the identify.
BUG=b:215742472
TEST=show below meaasge in coreboot log
\_SB.PCI0.TMD0.HR : Intel USB4 Retimer at GENERIC: 0.0
\_SB.PCI0.TMD1.HR : Intel USB4 Retimer at GENERIC: 0.0
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Idfa8b204894409b11936e5f221c218daa206cc02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61315
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The FSP API is used to notify the FSP about different phases in the
boot process. The current FSP specification supports three notify
phases:
- Post PCI enumeration
- Ready to Boot
- End of Firmware
This patch attempts to make calling into the FSP Notify Phase APIs
optional by using native coreboot implementations to perform the
required lock down and chipset register configuration prior boot to
payload.
BUG=b:211954778
TEST=Able to build brya without any compilation issue and coreboot
log with this code changes when SKIP_FSP_NOTIFY_PHASE_READY_TO_BOOT
and SKIP_FSP_NOTIFY_PHASE_END_OF_FIRMWARE config enabled.
coreboot skipped calling FSP notify phase: 00000040.
coreboot skipped calling FSP notify phase: 000000f0.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ia95e9ec25ae797f2ac8e1c74145cf21e59867d64
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Turns out 150ms isn't enough in the worst reset conditions. On guybrush
the TPM is reset in S0i3 and the CR50 is allowed to hibernate. The CR50
is woken up and initialized early during S0i3 resume. Occasionally the
CR50 isn't ready before the probe times out.
BUG=b:213828947
BRANCH=None
TEST=suspend_stress_test -c 1000
Change-Id: Ifda438080cf1ad2796c7061223a6a97b8e6e9987
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Keith Short <keithshort@chromium.org>
FSP 2.3 specification introduces following changes:
1. FSP_INFO_HEADER changes
Updated SpecVersion from 0x22 to 0x23
Updated HeaderRevision from 5 to 6
Added ExtendedImageRevision
FSP_INFO_HEADER length changed to 0x50
2. Added FSP_NON_VOLATILE_STORAGE_HOB2
Following changes are implemented in the patch to support FSP 2.3:
- Add Kconfig option
- Update FSP build binary version info based on ExtendedImageRevision
field in header
- New NV HOB related changes will be pushed as part of another patch
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ica1bd004286c785aa8a431f39d8efc69982874c1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Building an image for OCP DeltaLake with `x86_64-linux-gnu-gcc-11` fails
with the format warning below as the size of char * differs between
32-bit and 64-bit.
CC ramstage/drivers/ipmi/ipmi_fru.o
src/drivers/ipmi/ipmi_fru.c: In function 'read_fru_chassis_info_area':
src/drivers/ipmi/ipmi_fru.c:192:57: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'unsigned int' [-Werror=format=]
192 | printk(BIOS_ERR, "%s failed to malloc %ld bytes for "
| ~~^
| |
| long int
| %d
193 | "chassis custom data array.\n", __func__,
194 | info->custom_count * sizeof(char *));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
src/drivers/ipmi/ipmi_fru.c: In function 'read_fru_board_info_area':
src/drivers/ipmi/ipmi_fru.c:291:57: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'unsigned int' [-Werror=format=]
291 | printk(BIOS_ERR, "%s failed to malloc %ld bytes for "
| ~~^
| |
| long int
| %d
292 | "board custom data array.\n", __func__,
293 | info->custom_count * sizeof(char *));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
src/drivers/ipmi/ipmi_fru.c: In function 'read_fru_product_info_area':
src/drivers/ipmi/ipmi_fru.c:398:57: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'unsigned int' [-Werror=format=]
398 | printk(BIOS_ERR, "%s failed to malloc %ld bytes for "
| ~~^
| |
| long int
| %d
399 | "product custom data array.\n", __func__,
400 | info->custom_count * sizeof(char *));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| unsigned int
Fix the mismatches in `read_fru_chassis_info_area()` by using the length
modifier `z` for size_t as that is what `size_of` yields to.
Change-Id: If0c4266b19d56fa88abc397f305154d473ae1a93
Found-by: gcc (Debian 11.2.0-10) 11.2.0
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The Realtek RTL8125 has four registers for four leds
and a feature config register.
We use led0 and led2 in brask, so modify ethernet driver.
Those registers' IO address are based on RTL8125 datasheet.
BUG=b:193750191
TEST=Modify overridetree.cb to verify LEDs' settings.
Signed-off-by: Rory Liu <rory.liu@quanta.corp-partner.google.com>
Change-Id: I4b05a859dc0a0d2b8d6b35d6491fc88f7077cb92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, the pmc_mux/conn driver uses integer fields to store the
USB-2 and USB-3 port numbers from the SoC's point of view. Specifying
these as integers in the devicetree is error-prone, and this
information can instead be represented using pointers to the USB-2 and
USB-3 devices. The port numbers can then be obtained from the paths of
the linked devices, i.e. dev->path.usb.port_id.
Modify the driver to store device pointers instead of integer port
numbers, and update all devicetrees using the driver. These are the
mainboards affected (all are Intel TGL or ADL based):
google/brya
google/volteer
intel/adlrvp
intel/shadowmountain
intel/tglrvp
system76/darp7
system76/galp5
system76/lemp10
Command used to update the devicetrees:
git grep -l "usb._port_number" src/mainboard/ | \
xargs sed -i \
-e 's/register "usb2_port_number" = "\(.*\)"/use usb2_port\1 as usb2_port/g' \
-e 's/register "usb3_port_number" = "\(.*\)"/use tcss_usb3_port\1 as usb3_port/g'
BUG=b:208502191
TEST=Build test all affected boards. On brya0, boot device and check
that the ACPI tables generated with and without the change are the same.
Change-Id: I5045b8ea57e8ca6f9ebd7d68a19486736b7e2809
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The Bayhub LV2 has a known errata wherein PCI config registers at
offsets 0x234, 0x238, and 0x24C will only correctly accept writes
when they are addressed via a DWORD (32-bit) wide write operation
on the PCIe bus. Offset 0x234 is the LTR max snoop and max no-snoop
latency register, therefore add a finalize callback to this driver
which will program the LTR max-snoop/no-snoop register with a 32-bit
write using the values from pciexp_get_ltr_max_latencies().
BUG=b:204343849
TEST=verified the PCI config space writes took effect on google/taeko
Change-Id: I1813f798faa534fb212cb1a074bc7bcadd17a517
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
In the case of deduct_cmd_len being set and the adjusted cmd_len >=
ctrlr_max, ctrlr_max wasn't being adjusted and still had the value of
ctrlr->max_xfer_size. Handle this edge case (which we should never run
into) by setting ctrlr_max to 0 and printing a warning to the console.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9941b2947bb0a44dfae8ee69f509795dfb0cb241
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Currently coreboot interprets TCSS port number as per physical port
number while EC abstracts port number and provides indices as port
number. For example, if TCSS port 1 and 3 are enabled on the board,
coreboot will interpret port numbers as 0 and 2, but since only 2 ports
are enabled in the system EC will assign port numbers as 0 and 1.
This creates a port number mismatch while communicating between EC and
coreboot. This patch addresses issue where SoC can implement function
to map correct EC port as per port enabled in mainboard.
BUG=b:207057940
BRANCH=None
TEST=Check if code compiles successfully. Functionality will work once
function is implemented in SoC code.
Change-Id: Ia7a5e63838e6529196bd211516e4d665b084f79e
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add entry in ACPI table under IPU device to provide silicon type
information to IPU driver. IPU kernel driver can decide the type of
firmware to load based on this information.
BUG=b:207721978
BRANCH=none
TEST=Check for the ACPI entry in the SSDT after booting to kernel
Change-Id: I4e0af1dd50b9c014cae5454fcd4f9f76d0e0a85f
Cq-Depend: chromium:3319905
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The Realtek RT8168 and RT8125 have a similar programming interface,
therefore add the PCI device ID for the RT8125 into driver for support.
BUG=b:193750191
TEST=emerge-brask coreboot chromeos-bootimage. Test on brask whose NIC
is RT8125. Check if the default MAC is written into the NIC.
Signed-off-by: Alan Huang <alan-huang@quanta.corp-partner.google.com>
Change-Id: Iaa4c41f94fd6e5fd6393abbb30bfc22a149f5d71
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The current implementations of edid_read() and segments_edid_read() have
a few problems:
1. The type of variable `c` is incorrect, not matching the return type
of sp_tx_aux_rd(). In addition, the meaning of `c` is unknown.
2. It is pointless to do `cnt++` when sp_tx_aux_rd() fails.
3. These two functions ignore the return value of
anx7625_reg_block_read().
4. In segments_edid_read(), anx7625_reg_write() might return a positive
value on failure.
Fix all of the 4 issues, and modify the code to be closer to kernel
5.10's implementation (drivers/gpu/drm/bridge/analogix/anx7625.c). Note
that, however, unlike in kernel, anx7625_reg_block_read() here doesn't
return the number of bytes. On success, 0 is returned instead.
In addition, following coreboot's convention, always return negative
error codes. In particular, change the return value to -1 for
edid_read() and segments_edid_read() on failure.
BUG=b:207055969
TEST=emerge-asurada coreboot
BRANCH=none
Change-Id: Ife9d7d97df2926b4581ba519a152c9efed8cd969
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Some boards may want to use a _HID instead of an _ADR to locate a
graphics device. This patch provides that option in the devicetree.
BUG=b:206850071
TEST=Add `hid` entry in devicetree, dump SSDT and see _HID instead of
_ADR
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I32be4abf5c60be1f94aabaa2e9c734215c4e291e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The SMMSTORE_IN_CBFS option was just meant as a workaround for an
attempt to backport SMMSTORE into older Chromebooks that never actually
happened. All current and future users of coreboot should be using
SMMSTORE in an FMAP region. The APIs needed for SMMSTORE_IN_CBFS clash
with the CBFS rdev isolation needed for CBFS_VERIFICATION, so let's just
get rid of it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia0604a4ffd20b46774631d585925311b65d5a0e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59680
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The device is a PCIe Gen1 to SD 3.0 card reader controller to be
used in the Chromebook. The datasheet name is GL9750S and the revision
is 01.
The patch disables ASPM L0s.
BUG=b:206014046
TEST=Verify GL9750 enters L1 by observing CLKREQ# de-asserts.
Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
Change-Id: I6d60cef41baade7457a159d3ce2f8d2e6b66e71c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Introduce firmware-power-managed DSD ACPI property for TPM devices.
This property can be checked by the kernel TPM driver to override how
the TPM power states are managed. This is a tri-state flag, true,
false, or unset. So an enum used to keep the flag is unset by default.
When firmware-power-managed is true, the kernel driver will not send a
shutdown during s2idle/s0i3 suspend.
BUG=b:200578885
BRANCH=None
TEST=TPM shutdown is triggered on s0ix suspend on guybrush with patched
kernel
Change-Id: Ia48ead856fc0c6e637a2e07a5ecc58423f599c5b
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The _DSC (Device State for Configuration) object evaluates to an integer
may be used to tell Linux the highest allowed D state for a device
during probe. The support for _DSC requires support from the kernel
bus type if the bus driver normally sets the device in D0 state for
probe.
The D states and thus also the allowed values for _DSC are listed below.
Number State Description
0 D0 Device fully powered on
1 D1
2 D2
3 D3hot
4 D3cold Off
More details can be found here https://lkml.org/lkml/2021/10/25/397
BUG=none
BRANCH=none
TEST=Add corresponding field in brya, boot and dump SSDT to check if
_DSC field is as per expectation.
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "OVTI8856") // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
Name (_DDN, "Ov 8856 Camera") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Method (_DSC, 0, NotSerialized)
{
Return (0x04)
}
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: I5471f144918413a2982f86beaf3dbf7e4e66cc9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
