This patch fixes the documentation discrepancy of GPIO reset type
between PCH EDS and GPIO BWG.
As per GPIO BWG, there are four GPIO reset types in Meteor Lake as
below:
- Power Good - (Value 00)
- Deep - (Value 01)
- Host Reset/PLTRST - (Value 10)
- Global Reset for GPP - (Value 11)
Also, dropped the need for having dedicated reset type for GPIO
community 3. As per the MTL EDS, all GPIO communities have the same
reset type.
BUG=b:213293047
TEST=Able to build and boot Google/Rex without below error msg.
[ERROR] gpio_pad_reset_config_override: Logical to Chipset mapping
not found
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Id7ea16d89b6f01b00a7b7c52945f6e01e8db6cbd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66155
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Will Kim <norwayforest92@gmail.com>
Enabling them causes firmware keyblock/preamble and/or body verification
failure. Hence disabling them to use software based verification.
Re-enable them once the issue is root-caused.
BUG=b:217414563
TEST=Build and boot to OS in Skyrim with PSP and x86 verstage.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I7e259ae5d790977d08afcb0a77f8d4f38c85f39e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66134
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently only SHA_GENERIC is used and does not need to be passed.
BUG=b:217414563
TEST=Build and boot to OS in Skyrim with PSP and x86 verstage.
Change-Id: Id705b1361fffaf940c51515e7f77d7fb0677fc4a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
wifi
This reverts commit 5e6fd360de.
On nereid, the SSDT entry for the PCIe wifi device is missing, causing
wake-on-WLAN not to work since the _PRW is missing.
It seems like when commit 5e6fd360de changed the SSDT generation logic
for CNVi and PCIe wifi, it broke the PCIe case. `wifi_pcie_ops` are
never assigned to any device, so
`parent && parent->ops == &wifi_pcie_ops` always returns false, and the
`wifi_cnvi_ops` are used even for PCIe devices.
Undo the changes in that CL. This allows both the CNVi and PCIe cases to
work. That CL was meant to fix an issue with the CNVi _PRW containing
garbage, but I can't reproduce this when the change is undone.
It was also meant to fix the following error on CNVi devices, but I
don't see any errors with this change:
[ERROR] NONE missing set_resources
BUB=b:233325709
TEST=On both nivviks (CNVi) and nereid (PCIe), check that the SSDT
contains the correct wifi device entries (below), including a _PRW
containing the correct GPE, and check that wake-on-WLAN works.
nivviks:
```
Scope (\_SB.PCI0.CNVW)
{
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x6D,
0x03
})
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
<snip>
}
}
```
nereid:
```
Device (\_SB.PCI0.RP01.WF00)
{
Name (_UID, 0x923ACF1C) // _UID: Unique ID
Name (_DDN, "WIFI Device") // _DDN: DOS Device Name
Name (_ADR, 0x0000000000000000) // _ADR: Address
}
Scope (\_SB.PCI0.RP01.WF00)
{
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x23,
0x03
})
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
<snip>
}
}
```
Fixes: 5e6fd360de ("drivers/wifi/generic: Fix properties in generic-under-PCI device case")
Change-Id: I100c5ee3842997c50444e5ce68d583834ed3a8ad
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66063
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement mainboard_needs_pcie_init() for cherry as a callback for
mt8195 SoC to determine whether to initialize PCIe. When the SKU id is
unknown or unprovisioned (for example at the beginning of the factory
flow), we should still initialize PCIe. Otherwise the devices with NVMe
will fail to boot.
BUG=b:238850212
TEST=emerge-cherry coreboot
BRANCH=cherry
Change-Id: I2ed0ceeb37d2924ca16485fb2d130959a7eff102
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65992
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Joxer will have both eMMC and UFS SKUs, which require different
settings in the descriptor. So update the descriptor at run-time based
on fw_config.
By default, the descriptor is configured for UFS. This configuration
still boots fine on eMMC SKUs, it just might cause problems with S0ix.
This is a temporary workaround. It will be removed once we've
implemented a proper solution for configuring the descriptor differently
for different SKUs.
BUG=b:238234376
TEST=Make an identical change for nivviks. On both nivviks (eMMC) and
nirwen (UFS), check that it boots and that the logs show the descriptor
being configured as expected.
Change-Id: I14232eb773936f2ecd183687208d332136935601
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
SSPM is "Secure System Power Manager" that provides power control in
secure domain. The initialization flow is to load SSPM firmware to
its SRAM space and then enable.
It takes 21 ms to load sspm.bin.
coreboot logs:
CBFS: Found 'sspm.bin' @0x21680 size 0xa815 in mcache @0xffffeac4
mtk_init_mcu: Loaded (and reset) sspm.bin in 21 msecs (137348 bytes)
TEST=we can see the sspm logs.
BUG=b:233720142
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: Ib6443b64734048c1d71eeac650f36d7c4ac709cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Load MCUPM firmware and boot up MCUPM in ramstage.
It takes 41 ms to load mcupm.bin.
coreboot logs:
CBFS: Found 'mcupm.bin' @0x12580 size 0xf0c6 in mcache @0xffffead0
mtk_init_mcu: Loaded (and reset) mcupm.bin in 41 msecs (122184 bytes)
TEST=we can see the mcupm logs after reset releases.
BUG=b:233720142
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: Id1e62d9d6ede1c453e03eeda0d9b16fafa9e2372
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The X2APIC_LATE_WORKAROUND kconfig allows bringing APs in XAPIC mode initially hence, it won't work if LAPIC ID is > 0xff.
This patch ensures the MAX_CPUS logic is appropriate while selecting X2APIC_LATE_WORKAROUND kconfig from SoC.
BUG=b:219061518, b:219053812
TEST=Able to build Google/Rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I466e6cc568024a9dea80af21e0ebf3572e74a1f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66110
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This patch updates the GPIO lock configuration recommendation
kconfig string to ensure the SoC user can select the correct
config as applicable for the SoC.
Note: From MTL onwards GPIO lock config can be performed using
PCR write (MMIO write) and the GPIO team has confirmed this.
BUG=b:213596994
TEST=Able to fix below GPIO lock config error msg on MTL with
`SOC_INTEL_COMMON_BLOCK_GPIO_LOCK_USING_PCR` kconfig enabled.
[INFO ] Locking pad configuration using SBI
[INFO ] gpio_pad_config_lock_using_sbi: Locking pad 73
configuration
[ERROR] SBI Failure: Transaction Status = 1
[ERROR] Failed to lock GPIO PAD, response = 1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Icab1e4849b8e08ee1c695c924599f1513774178f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reserve bits 15 and 16 in the fw_config to be used to specify WFC
population status.
Possible values for field WFC bits include:
option WFC_ABSENT 0
option_WFC_MIPI_OVTI5675 1
option WFC_MIPI_OVTI8856 2
BUG=b:239613517
BRANCH=firmware-brya-14505.B
TEST='emerge-brya coreboot' and make sure it compiles successfully.
Change-Id: If797b79f0d094816eeb3df7bfded06e92e4e6a32
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Geralt reference design has both eMMC and SD card interfaces, so we have
to configure both in ramstage.
Implement msdc.c (mass storage device class) to place the eMMC and SD
card drivers.
This implementation is based on chapter 5.9 in MT8188 Functional
Specification.
TEST=boot to kernel using emmc successfully.
BUG=b:236331724
Signed-off-by: Andy-ld Lu <andy-ld.lu@mediatek.corp-partner.google.com>
Change-Id: I6594c8466a133d3fdb0084716acca8dcf785f94f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65975
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We plan to make 3 firmwares which differ only by Kconfig options and
can share a common variant directory.
ghost4adl: Board with an ADL chip.
ghost4es: Board near identical but has RPL-ES chip.
ghost: Will have final RPL silicon.
Since they will only differ by Kconfig options and Intel binary blobs,
let's not duplicate the variant directory but instead share it in
common.
BUG=b:239456576
BRANCH=firmware-brya-14505.B
TEST="make menuconfig", verify layout of board selection
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I94f2048bbe6675a807f8eba986a1ded0a4167733
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Follow the LED modification request in ADL_Moli_SC_MB_2022_0601.pdf and
set the customized_leds to 0x0482 based on 7.4 Customizable LED Configuration in "REALTEK+RTL8111K-CG+SPEC+0116" for RTL8111K in moli.
BUG=b:218985167
TEST=emerge-brask coreboot and check RTL8111K LED behaviour
Signed-off-by: Raihow Shi <raihow_shi@wistron.corp-partner.google.com>
Change-Id: Ia154d15ecf14b32a4d589abf27b9573693339a8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65958
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
