Data on channel 0 & 1 are normal (from DMIC)
but there is noise on channel 2 & 3, so change to NF
PAD_CFG_NF(GPP_R6, NONE, DEEP, NF4) to PAD_NC(GPP_R6, NONE),
PAD_CFG_NF(GPP_R7, NONE, DEEP, NF4) to PAD_NC(GPP_R7, NONE),
BUG=b:210802722
TEST=FW_NAME=vell emerge-brya coreboot
Change-Id: I1b5ccd2c239e526e4f1ce2d5ed6c1386303590c8
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61033
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `reset` gpio is currently being consumed by the btusb kernel driver.
The functionality was added in https://crrev.com/c/3342774. The goal of
the patch was to reset the BT device when command timeouts occur. This
works, but it doesn't support the case where the BT device is having
problems with USB enumeration. In that case the device can't enumerate
so the driver can't help resetting the device.
If we instead switch to using an ACPI power resource, the kernel can
control the BT device's power. This is beneficial when the device is
having USB communication problems since the kernel will try and power
cycle the device.
We don't lose the ability to reset the device on command timeouts
either since `btusb_qca_cmd_timeout` will enqueue a USB port reset if
there is no `reset` GPIO. So win / win.
This results in the following power resource:
PowerResource (PR02, 0x00, 0x0000)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x01)
}
Method (_ON, 0, Serialized) // _ON_: Power On
{
\_SB.CTXS (0x84)
Sleep (0x01F4)
}
Method (_OFF, 0, Serialized) // _OFF: Power Off
{
\_SB.STXS (0x84)
Sleep (0x0A)
}
}
I switched the device tree entry from using reset_gpio to enable_gpio
because the acpi_device_add_power_res method asserts the reset in the
_ON method unconditionally. This results in a small glitch on the line.
By using the enable_gpio we get the correct behavior.
I don't have a datasheet right now, so I just picked some values for the
reset timing. The kernel driver was using 200ms. We can revisit the
numbers when we get a datasheet.
BUG=b:218295688
TEST=Suspend stress test on nipperkin with 600+ cycles. Verify power
resource is created on the kernel. This should allow the kernel to
power cycle the device via usb_acpi_set_power_state.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib1eff86db76929f76432cd6f765880c892e7a786
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
When brya boards that use ChromeOS autoupdate update their firmware,
devices with SOC_INTEL_CSE_SUB_PART_UPDATE will end up attempting to
replace IOM and NPHY BPDT firmware in the CSE region. However, because
of the way the autoupdate works, the CSE RO will not be updated during
autoupdate. This means that these boards now have different stitching
schemes between CSE RO and RW and this causes the sub-partition update
to fail and the boot hangs. To remedy the situation for these boards,
a separate FMD files is provided so they can continue to use the
cse_serger tool for stitching. The only boards affected were kano and
brask, so they are updated here.
BUG=b:218376385
TEST=use flashrom to downgrade to 14474 then use futility to update to
image with this patch and system boots.
Signed-off-by: Tracy Wu <tracy.wu@intel.corp-partner.google.com>
Change-Id: Ia8bdf6b28d952f6d983b84e39da96e159027a822
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61728
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This fixes building with -jx
Change-Id: I51efc03839c53b96fa248e6fe5dc0e00b773aa53
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
create SOC_INTEL_GFX_MEMBASE_OFFSET for platform to map graphic memory
base if required, because it may vary by platfrom.
BUG=b:216756721
TEST= Check default offset for existing platform and
update platform specific offset in Kconfig under SoC directory.
Change-Id: I6b1e34ada9b895dabcdc8116d2470e8831ed0a9e
Signed-off-by: Ethan Tsao <ethan.tsao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61389
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Brask cannot pass powerd_dbus_suspend test because the NIC does not
enter ASPM L1.2. Here we add "enable_aspm_l1_2" in devicetree for
RTL8125 to enable ASPM L1.2.
BUG=b:204309459
BRANCH=None
TEST=emerge and test with command powerd_dbus_suspend
Signed-off-by: Alan Huang <alan-huang@quanta.corp-partner.google.com>
Change-Id: I9a56df1d68696f409f9ee681d37de6759a588d80
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add a new configuration parameter "enable_aspm_l1_2".
Write value 0xe059000f to register offset 0xb0 to allow kernel driver to
enable ASPM L1.2.
Use Kconfig "PCIEXP_ASPM" and "enable_aspm_l1_2" to decide whether to
enable ASPM L1.2.
BUG=b:204309459
TEST=emerge and test if the driver can read the correct value
Change-Id: I944dbf04d3ca19df4de224540bee538bff4d1f12
Signed-off-by: Alan Huang <alan-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Since the APIC bus isn't used since a long time and the IOAPIC and LAPIC
talk to each other via the system bus, there is no longer the
requirement that the IOAPIC IDs mustn't overlap with the LAPIC IDs that
start at 0 and end at CONFIG_MAX_CPUS - 1. The current Intel code uses 2
as the IOAPIC ID while most of their CPUs have more than 2 logical cores
resulting in the IOAPIC having the same ID as one of the LAPICs.
All chipsets in soc/amd use the defines for FCH_IOAPIC_ID and
GNB_IOAPIC_ID for initializing the IOAPIC register, writing both MADT
and IVRS ACPI tables and there's no MPTable support for those SoCs that
might also rely on those IDs being consistent.
This patch changes the definitions for FCH_IOAPIC_ID and GNB_IOAPIC_ID
from CONFIG_MAX_CPUS and CONFIG_MAX_CPUS + 1 to 0 and 1. This also makes
sure that the IOAPIC IDs still fit in 4 bits despite Cezanne having a
CONFIG_MAX_CPUS of 16 resulting in the IOAPIC IDs being larger than 4
bits with the old code. While the Cezanne FCH IOAPIC supports 8 bits of
IOAPIC IDs, this is non-standard.
TEST=AMD Mandolin and Google Liara still work.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: Id3a356480bb8407e0347cb5cef691fde7edc8deb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The following error message is now gone:
CC bootblock/arch/x86/id.o
/tmp/id-35b17a.s:35:7: error: expected relocatable expression
.long - ver
^
/tmp/id-35b17a.s:36:7: error: expected relocatable expression
.long - vendor
^
/tmp/id-35b17a.s:37:7: error: expected relocatable expression
.long - part
^
Tested with BUILD_TIMELESS=1 on x86_32 with gcc. The binary stays the
same.
Change-Id: I930e7b96c4428bcb95ff1903e6a3e7679171ffee
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch makes SKIP_CSE_RBP=y default for Apollo Lake if Boot Device is
memory mapped and ensures SkipCseRbp UPD is guarded against this config.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ifd01a25443e2582a90529e55be8d34a88342a103
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
FCH_UART_ID_MAX == 2, and there are 2 UARTS, so we don't need the -1.
BUG=b:215599230
TEST=Build guybrush
Found-by: Coverity CID 1469611
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I5f0171ed2d3da7f86ba3cfd0457f60d2d5722625
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61869
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Agah port 0 does not have a retimer so the port needs
to be configured for the SOC to handle Aux orientation flipping.
Add the "TcssAuxOri" and "typec_aux_bias_pads" to lets the SoC IOM firmware control the Aux DC bias voltages.
BUG=b:210970640
BRANCH=NONE
TEST=emerge-draco coreboot chromeos-bootimage
Change-Id: I1fa5c4574b1a0e8dd2f66f3f6382436337c530fa
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Alder Lake N has single memory controller with 64-bit bus width. Alder
Lake common meminit block driver considers bus width to be 128-bit and
populates the meminit data accordingly. By setting half_populated to
true, only the bottom half is populated.
Ideally, half_populated is used in platforms with multiple channels to
enable only one half of the channel. Alder Lake N has single channel,
and it would require for new structures to be defined in meminit block
driver for LPx memory configurations. In order to avoid adding new
structures, set half_populated to true. This has the same effect as
having single channel with 64-bit width.
Change-Id: I414e5dc82caf47b6b96c474b3ef6e01c2ce0226e
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
The mainboards mc_apl{2,4,5,6} use VBOOT for verification and can be in
a recovery state for different reasons. In this case we still want the
MRC cache to be around to avoid the DRAM retraining on every boot.
This patch enables the Kconfig switch HAS_RECOVERY_MRC_CACHE which makes
the already available MRC recovery region in FMAP useable.
Test=Boot mc_apl2 in recovery mode and make sure the recovery MRC
cache is used.
Change-Id: I2ea4993f05dd87a0e637f55e84b4fc06f5e29ecc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This IRQ routing info is taken from mb/google/guybrush. The IRQ routing
on Chausie that was a 1:1 copy caused some issues with the I2C driver,
so port the Chausie IRQ mapping change back to Majolica.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ieb958639dd8aef7c60c050ad107dde7d1cd6a8bd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This IRQ routing info is taken from mb/google/guybrush. This should fix
these errors:
[ 0.655051] i2c_designware AMDI0010:00: IRQ index 0 not found
[ 0.659239] i2c_designware AMDI0010:01: IRQ index 0 not found
[ 0.663198] i2c_designware AMDI0010:02: IRQ index 0 not found
[ 0.667200] i2c_designware AMDI0010:03: IRQ index 0 not found
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8c85c8e4b1c860d6ca25060353355f703a49e1e6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
For the generic board which uses Cezanne, we use the generic SPL
table. For the Guybrush Chromebook, we need to use a customized SPL
file.
BUG=b:216096562
Change-Id: I385b0fe13cb78a053c07127ec3ea1c61dc42c7e4
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Fix issue where registers always seem to contain their own offset.
After writing the desired register into SIRI, the requested data is
returned in SIRD. This register is 4 bytes after SIRI, commonly 0xA4.
Tested on TGL-H (SATA SIR registers are common), genuine data is
returned.
Change-Id: I322b11d53178e5b64e353c1b4e576548592c16c3
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Currently the SPM version string is stored at the end of the blob,
possibly without a trailing '\0'. Therefore, we should be careful not to
print characters beyond the blob size.
BUG=b:211944565
TEST=emerge-corsola coreboot
TEST=SPM version looked good in AP console
BRANCH=asurada,cherry
Change-Id: Icfeb686539dc20cf5b78de77c27bdbb137b5d624
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61800
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Several recovery images for newer ChromeOS boards fail in
extract_partition() due to parted detecting that there are overlapping
partitions, and therefore failing to print the partition layout
(this is potentially a parted bug; requries further investigation).
To work around this, fall back to using fdisk, making the assumption
that ROOT-A is always partition #3, and calculate the partition
start and size using the sector size.
Test: successfully extract coreboot firmware images from recovery
images which previously failed to extract (fizz, octopus, volteer).
Change-Id: I03234170ba0544af9eb0879253f0a8e0e7bf33f5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Wile historically there was a unique recovery image for each Chrome OS
board/HWID (with matching names), this is no longer the case. Now,
multiple boards share a single recovery image, so adjust how the proper
recovery image is determined, and how the coreboot image is extracted from it.
Test: successfully extract coreboot images for older 1:1 boards (e.g. CAVE)
and newer 1:N boards (e.g. DROBIT)
Change-Id: If478aa6eadea3acf3ee9d4c5fa266acd72c99b7a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This patch adds a new --loglevel option to the CBMEM utility which can
be used either numerically (e.g. `cbmem -1 --loglevel 6`) or by name
(e.g. `cbmem -c --loglevel INFO`) to restrict the lines that will be
printed from the CBMEM console log to a maximum loglevel. By default,
using this option means that lines without a loglevel (which usually
happens when payloads or other non-coreboot components add their own
logs to the CBMEM console) will not be printed. Prefixing a `+`
character to the option value (e.g. `--loglevel +6` or
`--loglevel +INFO`) can be used to change that behavior.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8458027083246df5637dffd3ebfeb4d0a78deadf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Config USE_PM_ACPI_TIMER to y for primus4es only as
commit 1ce0f3aab7 (mb/google/brya: Fix S0i3 regression)
breaks suspend stress test on ES CPU SKU.
BUG=b:211377699
TEST=USE="project_primus emerge-brya coreboot" and verified
the suspend stress test works on primus4es.
Change-Id: I8d19c10e2029e233542a8ceec272f8ede2b4bfac
Signed-off-by: Casper Chang <casper_chang@wistron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Few of the Alder Lake-N Device IDs according to EDS, are named as ADL_M
IDs in the current code. Hence rename those device IDs as ADL_M_N and
use them for Alder Lake-N platform.
Document Number: 619501, 645548
Signed-off-by: Usha P <usha.p@intel.com>
Change-Id: I6042017c6189cbc3ca9dce0e50acfb68ea4003f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61162
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Refactor existing acp code into acp_gen1 variant as preparation for gen2
variant in sabrina.
Change-Id: Id9248584237196b5404b79d3a8552cb90fe4491e
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Check if FSP binary and coreboot FSP structures (fspmupd.h) match
sufficiently.
A change in minor number denotes less critical changes or additions
to the FSP API that still allow for the boot process to proceed.
A change of the AMD image revision major number will halt boot.
The Fspmupd.h header now defines IMAGE_REVISION_ macros for AMD
Picasso, Cezanne and Sabrina APUs.
BUG=b:184650244
TEST=build, boot and check fsp image revision info. Example:
FSP major = 1
FSP minor = 0
FSP revision = 5
FSP build = 0
Signed-off-by: Julian Schroeder <julianmarcusschroeder@gmail.com>
Change-Id: I0fbf9413b0cf3e6093ee9c61ff692ff78ebefebc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61281
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
It's available in %r3 in bootblock and needs to be passed to payload in
%r27. We use one of two hypervisor's special registers as a buffer,
which aren't used for anything by the code.
Change-Id: I0911f4b534c6f8cacfa057a5bad7576fec711637
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
"hb-mode" is a -machine flag for QEMU. "hb" stands for Hostboot, which
is OpenPower firmware created by IBM.
QEMU for PPC64 can run initial program in two different modes:
* hb-mode=off with load address 0x00000000
* hb-mode=on with load address 0x08000000
Real hardware always loads firmware at 0x08000000 and coreboot shouldn't
require a special build to be run on QEMU.
Memory layout is updated to reflect change of load address.
Change-Id: I1bdc97a095bd46fccc862985b3bd24f4fa5bc054
Signed-off-by: Yaroslav Kurlaev <yaroslav.kurlaev@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
This change adds mem_parts_uesd.txt that contains the new memory parts
used (H54G46CYRBX267,H54G56CYRBX247) by primus and Makefile.inc
generated by gen_part_id using mem_parts_used.txt.
BUG=b:218415732
Signed-off-by: Malik_Hsu <malik_hsu@wistron.corp-partner.google.com>
Change-Id: I0d236c51f0c996a22954046876f3494ba9e62693
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently apu/amdfw_a-position and apu/amdfw_b-position currently depend on CEZANNE_FW_A_POSITION and CEZANNE_FW_B_POSITION. This causes error messages from awk as these variables are sourced from fmap_config.h and these variables are expanded before fmap_config.h is built. However these variables should not be set to CEZANNE_FW_*_POSITION. These files end up in the FW_MAIN_* fmap regions. These regions are placed at the proper locations through the chromeos.fmd file. The apu/amdfw_*-position variables are the positions within these regions where the files end up. These variables should be set to 0x40 to coincide with the beginning of the FW_MAIN_* regions, accounting for the size of struct cbfs_file + filename + metadata, aligned to 64 bytes. Currently they end up in the correct locations only because fmap_config.h does not exist when the apu/amdfw_*-position variables are expanded.
This change explicity sets the value of these variables to 0x40, removing the errors from awk and ensuring that these files end up in the correct location in the resulting image. These changes are also applied to the Picasso and Sabrina makefiles as well.
BUG=b:198322933
TEST=Verified that the apu/amdfw_* files end up in the correct locations as reported by cbfstool during the build, did timeless builds and confirmed that coreboot.rom images were identical, tested AP firmware on guybrush and zork devices
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: If1c2b61c5be0bcab52e19349dacbcc391e8aa909
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Introduce and use functions to translate eSPI IO/MMIO decode range IDs
into the corresponding register bits and the IO/MMIO range and size
register IDs into register offsets. This is a preparation to support the
additional eSPI decode ranges on Sabrina where not all enable bits and
base/size registers for one type of decode ranges are consecutive.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id91fe32447a06b049e33dfdacc8edfa2ebb2df39
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This aligns the register names more with the PPR.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4e7dc8dfc0fa5e86b9d4425f2496be86e039b686
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Nissa is using the FM101, which has the following power sequencing
requirements:
Power on: assert WWAN_EN, delay 20 ms, deassert WWAN_RST_L
Power off: assert WWAN_RST_L, delay 20 ms, deassert WWAN_EN
Add a power resource to the USB device, and use wwan_power.asl to
handle the power off sequence.
BUG=b:217092522
TEST=abuild -a -x -c max -p none -t google/brya -b nivviks
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: Ibe1b863a550c6af1ac3eb98f2aaa3db15b149ada
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61694
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Nissa is using the FM101 which is USB only. To allow us to reuse the
existing wwan_power.asl for power sequencing, move the PCIe-specific
part behind a new Kconfig HAVE_PCIE_WWAN.
BUG=b:217092522
TEST=Build brya0 and check that generated dsdt.asl doesn't change.
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: Icb6db91ce00deb2b30379f5ff7a974d1feb62ea8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
If the LTE USB DB is not connected, disable the LTE-related GPIOs.
BUG=b:197479026
TEST=abuild -a -x -c max -p none -t google/brya -b nivviks
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: I86251d8ad58d82ff2112ac5f2dfafdabbff4c76f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Add an initial overridetree for nivviks based on the pre-proto schematic
and build matrix.
BUG=b:197479026
TEST=abuild -a -x -c max -p none -t google/brya -b nivviks
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: Id3ecd184415a20a3a52da8bb5e60fe2ce0495b44
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
There may be occasions where an I2C device was initialized during
"early initialization," but when used again in ENV_PAYLOAD_LOADER
before resource allocation happens, it would currently return that it
has not been assigned a BAR. However, because of the early BAR
assigned to it, it should still be valid to use that until proper
resources have been assigned, therefore return any BAR that may have
been assigned to the device during early initialization.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I8ab599199592a72ae96cd9f95accfaa0d84e66b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The `chip` argument passed around to many functions in this driver is
actualy unused, so remove it where it is unused.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib8d32fdf340c8ef49fefd11da433e3b6ee561f29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61718
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Shon Wang