This patch selects the DRIVERS_MTK_WIFI and USE_MTCL configs for google/yaviks as
the first platform that provides a country list to the Linux kernel via an
ACPI function (MTCL) in SSDT for MediaTek WiFi chipsets that are capable of
operating on the 6GHz band.
BUG=b:295544553
TEST=Build on similar model (PUJJO) that I have access to and verify the
flag and feature work as intended.
TEST=Add wifi_mtcls.bin blob to cbfs
TEST=Build coreboot for pujjo `emerge-nissa coreboot chromeos-bootimage`
TEST=Verify that MTCL defined in the file is present:
TEST=`acpidump -b`
TEST=`iasl ssdt.dat`
TEST=`less ssdt.dsl`
TEST=Search for MTCL
Change-Id: Iec54fc582d68b443665fceda47187c28f1a9216c
Signed-off-by: David Ruth <druth@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80305
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subratabanik@google.com>
It seems that we have some applications where we need to calculate a GCD
in 64 bits. Now, we could instantiate the algorithm multiple times for
different bit width combinations to be able to use the most efficient
one for each problem... but considering that the function usually only
gets called once per callsite per stage, and that software emulation of
64-bit division on 32-bit systems doesn't take *that* long either, we
would probably usually be paying more time loading the second instance
of the function than we save with faster divisions. So let's just make
things easy and always do it in 64-bit and then nobody has to spend time
thinking on which version to call.
Change-Id: I028361444c4048a0d76ba4f80c7334a9d9983c87
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80319
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
This makes it easier to reuse, e.g. if you want to do it twice in one
assembly file.
Change-Id: Ida861338004187e4e714be41e17c8447fa4cf935
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Although entry64.inc does guard against ENV_X86_64, it's more aesthetic
to have it with the other 64bit code below a guard just like other
platforms.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: If3ef19dd6654cd2fa0be3c68dee4a472e7a7935d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Current pagetable implementation allows memory access up to 4GiB using
2MiB pages. If user wants to access more than 4GiB with a 2MiB page it
will require more pagetable entries. By using a 1GiB page table, users
can access more than 4GiB of memory while reducing the number of
pagetable entries. This patch enables memory access up to 512GiB through
1GiB pages by selecting USE_1G_PAGES_TLB in Kconfig.
TEST: Verified in 64bit mode boot and access above 4GiB
Change-Id: Id569ae5b50abf5b72e4db33b5e4cd802399e76ec
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80088
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In case where PAD_CFG_GPI_INT() is initialized with a pin value
lower to PAD_CFG_GPI_IRQ_WAKE() for same GPIO community
the set_ioapic_used() is only called for the PAD_CFG_GPI_IRQ_WAKE() pin.
Due to this the IRQ associated with PAD_CFG_GPI_INT() is found free by
find_free_unique_irq() during IRQ assignment and assigned to other pins
which causes IRQ conflicts
BUG=b:322984217
BRANCH=None
TEST=Boot test on brox, check if correct IRQ assigned to EC
Change-Id: I8c3d557e888b8d0ceac203f49b702910fba26d6d
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80334
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In case printk does not work the current exception handler will print a
simple "!" to notify the developer that coreboot is actually there but
something went wrong.
The "!" can be quite confusing when it actually happens that printk does
not work. Since "!" doesn't really say much (if you don't know the
exception arm64 code) the developer (like me) can easily assume that
something went wrong while configuring clocks or baud rate of UART,
since the output seemingly does not seem to make sense.
This adds a little bit more output to assure the developer that what was
printed was actually intended to be printed. Therefore it prints
"EXCEPT" which assures the developer that this was intended output.
It also adds a comment above so that developer can more easily grep
for this message.
It has intentionally not been written as:
```
const char *msg = "\r\n!EXCPT!";
while (*msg)
__uart_tx_byte(*msg++);
```
because in this case the compiler will generate code that will place
`msg` somewhere in bootblock and the code will try to access this using
a memory address. In rare cases (if you link bootblock at the wrong
address) this memory address can be wrong and coreboot will not print
the message. Using individual calls to `__uart_tx_byte` ensures that the
compiler will generate code which directly puts the character bytes into
the argument register without referencing a variable in bootblock.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2f858730469fff3cae120fd7c32fec53b3d309ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80184
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Printing the data fabric MMIO decode window configuration might be
useful and it also aligns this SoC more with the other AMD family 17h+
SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I52f6655a5c63e31165549dcb6f5f95d4e74bad3d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Drop the unneeded data_fabric_set_mmio_np function and the corresponding
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig symbol. In systems
with only one FCH, its MMIO region will be subtractively decoded and
there's no need to add a non-posted data fabric MMIO region after the
FSP/openSIL has already configured the data fabric decode windows. In
systems with more than one FCH, openSIL will already take care of
initializing everything for the additional FCH, so we also won't need to
do anything in that case. Since dropping this function also removes both
data_fabric_print_mmio_conf calls before and after adding the unneeded
non-posted MMIO region, replace the data_fabric_set_mmio_np call with a
data_fabric_print_mmio_conf call to still print the data fabric MMIO
decode regions set up by the FSP/openSIL.
TEST=Mandolin still boots successfully
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I474b6e066060abb3fe5b78505521c7782cc192ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
smp_write_ioapic is only called from smp_write_ioapic_from_hw within the
same compilation unit, so reduce its scope by making it a static
function.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6a1bbfd50ae9d6c8ab18f478ae9bae3f8bf5e10d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
At the moment this is to handle the situation when device ID is the
same for TPM1 and TPM2 versions of a device. Later this TPM family will
be returned to the caller.
Change-Id: I23b85e6da0e02999704f3ec30412db0bdce2dd8a
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This adds another option to tell OpenSBI which hart to use for booting.
Test: Start hifive-unmatched board and see that Hart 1 (instead of 0) is
used for running OpenSBI.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Id58bd6ae3b55a5ef3f1a5c97dfa07c79aa4c78d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79948
Reviewed-by: Philipp Hug <philipp@hug.cx>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Updating from commit id 23d6774ab:
2024-01-16 09:47:43 +0100 - (Merge "feat(qemu-sbsa): mpidr needs to be present" into integration)
to commit id 17bef2248:
2024-02-05 23:33:50 +0100 - (Merge "feat(fvp): delegate FFH RAS handling to SP" into integration)
This brings in 142 new commits.
Change-Id: If89a3f0d32180ff7ae0a6b447687b9749dfab2ea
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80352
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Upload initial GPIO configuration for xol based on proto schematics.
BUG=b:319506033
BRANCH=firmware-brya-14505.B
TEST=FW_NAME=xol emerge-brya coreboot chromeos-bootimage
xol proto board can boot to ChromeOS
Change-Id: I224e58628e44571c07ce034136d690587e62be08
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80325
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Upload the initial devicetree and update Kconfig for xol following
proto schematics.
BUG=b:319506033
BRANCH=firmware-brya-14505.B
TEST=FW_NAME=xol emerge-brya coreboot
Change-Id: I411932eb4872d77993394a290e8afdd1a0038faf
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80324
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Since the local IOAPIC ID variable is initialized as 2 and never changed
afterwards, so make it const to make this more obvious.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1f19cc43b44a938758a43346f4fa75f8ed39ddea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80349
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Back in the days of the APIC bus, the IOAPIC IDs mustn't overlap with
the LAPIC IDs (0 to CONFIG_MAX_CPUS - 1), but since the IOAPIC and LAPIC
nowadays talk to each other via the system bus, an IOAPIC ID of 0 is
valid. When set_ioapic_id gets called with an IOAPIC ID of 0, it skipped
writing the IOAPIC ID to the corresponding IOAPIC register, so the code
was relying of the register having the expected default value of the
IOAPIC IO 0 for things to work as expected. The case of the IOAPIC ID
being 0 is the most common case in coreboot, since that's what
register_new_ioapic_gsi0 will end up doing. Fix this issue by not making
the io_apic_write call conditional on ioapic_id being non-zero. The only
southbridge that doesn't call register_new_ioapic_gsi0, calls
set_ioapic_id with the IOAPIC ID 2 for which this won't cause any
changes in behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic8538f82a6b10f16eeb228669db197dc8e326ffd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Remove hardcoded B:D:F numbers for the first socket and pass the PCI
addresses to be locked within SMM by using the smm_pci_resource_store.
This allows to lock down SMM on all sockets without knowing the actual
bus topology or PCI segment group at compile time where the UBOX devices
reside on.
Tested: SMM is locked on all 4 sockets instead of just one.
Change-Id: Ica694911384005681662d3d7bed354a60bf08911
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80247
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Cleanup to make the file follow the same convention after USE_MTCL was
added and the depends structure was requested instead of the if guards.
Signed-off-by: David Ruth <druth@google.com>
Change-Id: I3604b394f999b28de4723337b3b6b4e21139c83b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80307
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The MTCL function provides a country list to the Linux kernel via an
ACPI function in SSDT for MediaTek WiFi chipsets that are capable of
operating on the 6GHz band. The country list is used to selectively
disable 6GHz and 5.9GHz operation based on the country the device is
operating in.
The function needs to read a binary file and send it as a package via
the MTCL method in SSDT for PCIe WiFi with MediaTek chipsets.
Change Summary:
* Add src/drivers/wifi/generic/mtcl.c to abstract functionaltity related
to MTCL
* Add write_mtcl_aml function to convert the byte data into the format
expected by the MTCL functionality in the Linux kernel.
* Add validate_mtcl function to validate that the byte data read in
from a file is in the expected format.
* Add write_mtcl_function function to read a binary file called
"wifi_mtcl".bin" from cbfs, then call validate_mtcl to verify that
it is in an expected format, and if so write the aml via acpigen
* Add config flag DRIVERS_MTK_WIFI to src/drivers/wifi/generic in order
to include MediaTek WiFi specific functionality
* Add config flag USE_MTCL which depends on DRIVERS_MTK_WIFI and
enables including the specific ACPI function defined in SSDT
* Add config flag CONFIG_MTCL_CBFS_FILEPATH which depends on
DRIVERS_MTK_WIFI which enables configuring the file to add as
"wifi_mtcl.bin"
* Add a call to write_mtcl_function to src/drivers/wifi/generic/acpi.c
to include the MTCL function in SSDT for MTK WiFi devices when
USE_MTCL is enabled.
* Add MediaTek VID to src/include/device/pci_ids.h.
BUG=b:295544553
TEST=Add Kconfig entry USE_MTCL for pujjo
TEST=Add wifi_mtcl_defaults.bin blob to cbfs
TEST=Build coreboot for pujjo `emerge-nissa coreboot chromeos-bootimage`
TEST=Verify that MTCL defined in the file is present:
TEST=`acpidump -b`
TEST=`iasl ssdt.dat`
TEST=`less ssdt.dsl`
TEST=Search for MTCL
Signed-off-by: David Ruth <druth@chromium.org>
Change-Id: I9b5e7312a44e114270e664b983626faa6cfee350
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80170
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Currently, SOC_INTEL_COMMON_BLOCK_TCSS will set MUX to disabled. The two
related options to re-configure it for either USB devices or displays,
are currently only supported by the ChromeEC. As such, any device
without the ChromeEC will boot with attached USB-C devices in a
non-functional state.
Add TCSS_HAS_USBC_OPS to make this feature configurable, and set the
default to enabled if the board features the ChromeEC.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ia848668ae9af4637fc7cffec9eb694f29d7deba9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79882
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This is just a clean-up commit.
Change-Id: If0397f5cc8d0f4f1872bd37a001fe42e0c37ec97
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80302
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Update the I2C configuration to match the usage such that only required
I2C controllers are enabled.
BUG=b:319390850
TEST=Build Brox BIOS image and boot to OS. Ensure that only the required
I2C controllers are enabled.
Change-Id: I9f24beb9ef587163362cc6ded88efb05be1329b9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80303
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Just a memory leak fix in Linux 6.7.
Change-Id: I1ff302dafa01e78429a30ff18e21ffe0b45ce46e
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80263
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Follow reference design rex0, keep the GPIO settings of CNVi/PCIe.
Only set GPP_F04,GPP_F05/GPP_S01,GPP_S02 to NC when
WIFI_PCIE/WIFI_CNVI is selected.
BUG=none
TEST=Build and test on karis
Change-Id: Id23a2cfe0639f2d423980db9badc16c1477434d1
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Update element "KB_TYPE_CA" for align fw_config.
Only EC will reference KB_TYPE field in fw_config. This
CL is just for align fw_config.
BUG=none
TEST=emerge coreboot pass
Change-Id: Ied54f78dddd9dddca1272fc31c9502fc11c61dde
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
This patch switches the cbmem utility from its own IP checksum
implementation to the commonlib version (which is good because the old
one had a couple of bugs: doesn't work on odd sizes and may overflow
its carry accumulator with input larger than 64K).
Change-Id: I0bef2c85c37ddd3438b7ac6389e9daa3e4955b31
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80256
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a bit of optimized assembly code to the ipchksum()
algorithm for x86 targets in order to take advantage of larger load
sizes and the add-with-carry instruction. The same assembly (with one
minor manual tweak) works for both 32 and 64 bit mode (with most of the
work being done by GCC which automatically inserts `rax` or `eax` in the
inline assembly depending on the build target).
Change-Id: I484620dc14679ff5ca02b2ced2f84650730a6efc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80255
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a bit of optimized assembly code to the ipchksum()
algorithm for arm64 targets in order to take advantage of larger load
sizes and the add-with-carry instruction. This improves execution speed
on a Cortex-A75 by more than 20x.
Change-Id: I9c7bbc9d7a1cd083ced62fe9222592243a796077
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80254
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Yidi Lin <yidilin@google.com>
This patch moves libpayload over to the commonlib implementation for
calculating the IP checksum.
Change-Id: Ie8d323ce9f8d946758619761b4b22d54bce222b6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80253
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Yidi Lin <yidilin@google.com>
This patch adds a few more test cases for the IP checksum algorithm to
catch more possible corner cases (large data with more than 64K carries,
unaligned data, checksum addition with offset, etc.).
Change-Id: I39b4d3f1bb833894985649872329eec88a02a22c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
This patch moves the IP checksum algorithm into commonlib to prepare for
it being shared with libpayload. The current implementation is ancient
and pretty hard to read (and does some unnecessary questionable things
like the type-punning stuff which leads to suboptimal code generation),
so this reimplements it from scratch (that also helps with the
licensing).
This algorithm is prepared to take in a pre-calculated "wide" checksum
in a machine-register-sized data type which is then narrowed down to 16
bits (see RFC 1071 for why that's valid). This isn't used yet (and the
code will get optimized out), but will be used later in this patch
series for architecture-specific optimization.
Change-Id: Ic04c714c00439a17fc04a8a6e730cc2aa19b8e68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80251
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Make the initialization of the IOAPIC(s) in the PCI root(s) common
across all AMD family 17h+ SoCs. For this the more general
implementation from the Genoa code that supports multiple PC roots is
moved to the common AMD code. All other family 17h+ SoCs are then
adapted to use the common code. For those non-Genoa SoCs, the
initialization of this second IOAPIC is moved from the northbridge
device to the domain device above to match Genoa.
Test=Both the FCH IOAPIC and the PCIe root IOAPIC are still initialized
on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7c0ec6ac2f11cb11e46248cceec96c1fd2a49c16
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80286
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce BOARD_AMD_BIRMAN_PHOENIX_OPENSIL which selects the openSIL
based Phoenix SoC code. Since the Phoenix chip.c is different due to
some FSP-specific data structures in there that are guarded in the
openSIL case, a separate devicetree for the openSIL case is added.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I248102e92818b2d395d561a4bf2627f80906b2f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Since the USB configuration data structure is FSP-specific, add guards
on this part of the soc_amd_phoenix_config struct and the corresponding
include.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6c324421fbc3dc7b9a7bf6f5868785e9718147a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80298
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since openSIL configures the APCI IO port addresses, coreboot should not
overwrite them.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If10e5a9f52ab313ad1afebd7f9e722994d48b0a7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80297
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the calls to the openSIL stubs to do the silicon initialization, to
get the APCI IO ports, and to get the memory map.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6f37bf211e130cb44927f8a0e7f9134d246dfc1c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80296
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The configuration of the PCIe clock generators in the FCH was moved from
the FSP to coreboot, since all registers are documented. This
initialization is however tightly integrated in the rest of the PCIe
init code inside the reference code. In the FSP case, this code was
manually removed. openSIL will do that part of the initialization so
that there's no coreboot-specific change needed in openSIL. This will
also avoid the problems caused by mismatching configurations done by the
coreboot code and the PCIe init part of the reference code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6d64285a301ade6860c07e62dcb1a718e7a96644
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
In the FSP case we get this info via a HOB. It's currently unclear if
we'll get a data structure for this from openSIL or if we'll end up
being able to just read the configuration fro the hardware, so add a
get_pci_routing_table stub for now to be able to build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5003e287d6a3a9320922beaffff8a3a846531e14
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add the SOC_AMD_PHOENIX_OPENSIL Kconfig option to be able to build the
Phoenix code using openSIL instead of FSP for initializing the hardware.
Since there's currently no publicly available openSIL code for Phoenix,
SOC_AMD_OPENSIL_STUB is selected to have the stubs added to the build
instead of the actual openSIL code. The code added by selecting
SOC_AMD_COMMON_BLOCK_ACPI_CPPC relies on getting the information it
needs via a HOB, so for only select that option in the FSP case for now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If597ff3dc824ce832399d3efde32352b36354b21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add a stub implementation of the openSIL interface between coreboot and
vendorcode. This can be used to add most of the coreboot-side support
for a SoC using openSIL without the actual opnSIL code already being
publicly available. Once the corresponding openSIL code is available,
the SoC can then switch over to using the actual openSIL implementation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9284b0cbacba6eae7e2e7e69bc687f015076c2b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80292
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Remove the unused soc/platform_descriptors.h include and add the missing
types.h include.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie0b066aa5dc657f7709f9cce734a025180bf5bfe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Rename the BOARD_AMD_BIRMAN_PHOENIX option to
BOARD_AMD_BIRMAN_PHOENIX_FSP to distinguish between the FSP-based SoC
initialization and the non-FSP based one. Also change the
MAINBOARD_PART_NUMBER string to 'Birman_Phoenix_FSP'.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id3293a07cd1b1833df15ee0a40cad3127e19b7df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The last 'endif' belongs to the 'if BOARD_AMD_BIRMAN_COMMON' in line 26,
so fix the comment. Commit 35a30de7af ("mb/amd/birman: Use common
option for variant configuration") changed that condition, but missed
updating this comment, so do this now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I986e5a456e8f9fd92aacd007479c861feea06199
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Only add the vendorcode/amd/fsp/phoenix and vendorcode/amd/fsp/common
folders to the include search path when the SOC_AMD_PHOENIX_FSP Kconfig
option is selected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I18668ab8578b297c328fdc647c8a95f540ac6272
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80288
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Provide 3 separate functions for each openSIL time point instead of one,
so that we don't need the xSIM-api header file to be included in
opensil.h to decouple the coreboot code more form the openSIL code. This
will allow to create an openSIL stub implementation to already get most
of the coreboot-side SoC code in place before the openSIL source code is
done and released.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I969bc0862560b7254c48f04e9a03387417f328bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
When a device with no resource is passed it will keep overwriting
the current slot. Remove the conditional and allow a PCI device
to not have any resources.
This is particular useful for the next commits that makes use
of the PCI resource store to pass UBOX devices to SMM that allow
to lock-down SMM from within an SMI handler. Those devices do
not have any resources and cannot be hardcoded in SMM as their
PCI segment group and bus number varies depending on socket
count, CPU discovery and configuration.
Change-Id: I1a1b5944c97da5be6b9794c653b5159683f492e5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80246
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Commit d252776668 ("tree: Replace And(a,b) with ASL 2.0 syntax")
replaced two instances of `And(var, mask) == 0` with `var & mask == 0`.
This expression needs parentheses - `(var & mask) == 0`.
Without parentheses, it is always false, since the masks are nonzero
(`var & (mask == 0)`; `var & 0`; `0`).
This caused brightness changes on Intel GMA to take longer than
normal since the status was never checked. The brightness would
change immediately, but another brightness change could not occur until
the first change timed out.
This was most noticeable in KDE, which waits for the brightness change
to complete before accepting another brightness up/down keypress.
Tapping brightness up/down repeatedly would take much longer to reach
max/min brightness due to many presses being ignored.
It is noticeable in GNOME as well but less obvious. Tapping brightness
up/down repeatedly would handle all keypresses, but the display's
actual brightness would lag behind and skip some intermediate steps.
I tested both Librem 13v2 and Librem 14, as far as I know this would
apply to all systems configuring brightness with Intel GMA.
Test: Verify brightness keys respond quickly again on Librem 13v2 / 14.
Change-Id: I57895e8c654c83368b452d7adfe1856c0a0341fb
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80260
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
David Ruth