If the ChromiumOS EC indicates that the device has an assistant key,
we should also add it to the generated linux,keymap binding. This
commit simply does so by examining the keyboard capabilities reported by
the EC.
BUG=b:333088656
TEST=With a device that has an assistant key, flash AP FW and verify
that the key is mapped to `KEY_ASSISTANT` in the Linux kernel using
`evtest`.
Change-Id: I217220e89bce88e3045a4fc3b124954696276442
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81996
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Some devices may generate scancodes for the Fn key if they have one.
If they do, we should add them to the linux,keymap binding.
BUG=b:333096023
TEST=Flash DUT that emits a scancode for the Fn key, verify that it is
mapped to KEY_FN in the Linux kernel using `evtest` when pressing the Fn
key.
Change-Id: Ie4daa64bc6b619392276d0b5f16e2d195d5bd68c
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81895
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Some internal keyboards have a dictation key; this commit simply adds
support for this key by adding the mapping from the scancode to the
Linux keycode for use in the linux,physmap ACPI table.
BUG=b:333101631
TEST=Flash DUT that emits a scancode for a dictation key, verify that it
is mapped to KEY_DICTATE in the Linux kernel.
Change-Id: Iabc56662a9d6b29e84ab81ed93cb46d2e8372de9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Add dynamic PCI domain _OSC ASL generation codes, supporting both
PCIe and CXL domains.
Dynamic SSDT generation is used to generate a list of ASL device
objects based on FSP outputs (e.g. the SoC/SKU configurations)
and _OSC is a method inside these objects (hence it would be
straightforward to be generated altogether, plus some C codes
managed boot configs could be referenced as well).
This usage is optional. It is helpful for cases where the same
code set supports multiple SKUs/SoCs (difficult to be handled by
one set of static SSDT), and the CPU performance is good enough
to run SSDT generation logics with minimal costs.
TEST=intel/archercity CRB
Tested with https://review.coreboot.org/c/coreboot/+/81377.
Change-Id: I711ce5350d718e47feb2912555108801ad7f918d
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This prepares the code for enabling both CONFIG_TPM1 and CONFIG_TPM2
during compilation, in which case actual TPM family in use can be
determined at runtime.
In some places both compile-time and runtime checks are necessary.
Yet in places like probe functions runtime state checks don't make sense
as runtime state is defined by results of probing.
Change-Id: Id9cc25aad8d1d7bfad12b7a92059b1b3641bbfa9
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69161
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even though it has an 'amd_' prefix, the amd_pci_domain_fill_ssdt
implementation doesn't contain any AMD-specific code and can also be
used by other SoCs. So factor it out, move the implementation to
src/acpi/acpigen_pci_root_resource_producer.c, and rename it to
pci_domain_fill_ssdt. When a SoC now assigns pci_domain_fill_ssdt to its
domain operation's acpi_fill_ssdt function pointer, the PCI domain
resource producer information will be added to the SSDT.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7bd8568cf0b7051c74adbedfe0e416a0938ccb99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80464
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ice5dadd3eaadfa9962225520a3a75b05b44518ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80066
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add initial support for multiple PCI segment groups. Instead of
modifying secondary in the bus struct introduce a new segment_group
struct element and keep existing common code.
Since all platforms currently only use 1 segment this is not a
functional change. On platforms that support more than 1 segment the
segment has to be set when creating the PCI domain.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ied3313c41896362dd989ee2ab1b1bcdced840aa8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The physical address size of the System-on-Chip (SoC) can be different
from the CPU physical address size. These two different physical
address sizes should be used for settings of their respective field.
For instance, the physical address size related to the CPU should be
used for MTRR programming while the physical address size of the SoC
should be used for MMIO resource allocation.
Typically, on Meteor Lake, the CPUs physical address size is 46 if TME
is disabled and 42 if TME is enabled but Meteor Lake SoC physical
address size is always 42. As a result, MTRRs should reflect the TME
status while coreboot MMIO resource allocator should always use
42 bits.
This commit introduces `SOC_PHYSICAL_ADDRESS_WIDTH' Kconfig to set the
physical address size of the SoC for those SoCs.
BUG=b:314886709
TEST=MTRR are aligned between coreboot and FSP
Change-Id: Icb76242718581357e5c62c2465690cf489cb1375
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79665
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The optimization of sleep time in acpi code includes reducing the sleep
duration and increasing the polling frequency within the acpi _ON/_OFF
method. StorageD3Enable is activated in Google/Rex, and this
optimization results in a saving of approximately 25ms in D3cold resume
time, reducing it from around 160ms to 135ms.
BUG=b:296206467
BRANCH=firmware-rex-15709.B
TEST=boot test verified on google/rex
verified _ON/_OFF Method in SSDT.
verifid kernel log in s0ix test -
0000:00:06.0: PM: pci_pm_resume_noirq
Change-Id: I7ba960cb78b42ff0108a48f00206b6df0c78ce7a
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79414
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This commit lays the groundwork for implementing the ACPI WDAT (Watchdog
Action Table) table specification. The WDAT is a special ACPI table
introduced by Microsoft that describes the watchdog for the OS.
Platforms that need to implement the WDAT table must describe the
hardware watchdog management operations as described in the
specification. See “Links to ACPI-Related Documents”
(http://uefi.org/acpi) under the heading “Watchdog Action Table”.
BUG=b:314260167
TEST=Mock the acpi_soc_fill_wdat function for a specific platform/soc
and enable ACPI_WDAT_WDT in the kconfig. Check if the build passes
successfully.
Change-Id: Ieb82d1f69b2b7fffacfd2928bc71f8ff10498074
Signed-off-by: Marek Maslanka <mmaslanka@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
The device/device.h provides the definition for struct device used in
those files, so include this header file to make sure that it's not only
included indirectly via some other header file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6ff7cdbf0f53ada92adb53cf268e5feee9df4629
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
This patch adds code to generate Processor Properties
Topology Tables (PPTT) compliant to the ACPI 6.4 specification.
- The 'acpi_get_pptt_topology' hook is mandatory once ACPI_PPTT
is selected. Its purpose is to return a pointer to a topology tree,
which describes the relationship between CPUs and caches. The hook
can be provided by, for example, mainboard code.
Background: We are currently working on mainboard code for qemu-sbsa
and Neoverse N2. Both require a valid PPTT table. Patch was tested
against the qemu-sbsa board.
Change-Id: Ia119e1ba15756704668116bdbc655190ec94ff10
Signed-off-by: David Milosevic <David.Milosevic@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Returning a NULL device name can cause issues if something else does
handle it.
E.g. UART and GNA devices on Intel Alder Lake-N cause
INTERNAL_POWER_ERROR BSOD's in Windows when enabled due to invalid
packages being created from a NULL name
Test: build/boot google/nissa (craaskvin) to Win11
Change-Id: I0679147ad3e330d706bbf97c30bc11b2432e2e8a
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Previously acpigen_pop_len always wrote a 3 byte PkgLength to the 3
bytes reserved by acpigen_write_len_f. After this patch acpigen_pop_len
encodes PkgLength in 1-3 bytes depending on the PkgLength. When less
than the 3 bytes that were previously reserved in the corresponding
acpigen_write_len_f call are needed for PkgLength, the payload data will
be moved back by the number of reserved bytes that aren't needed for the
PkgLength.
This fixes the problem that the Windows AML parser doesn't like a 3 byte
PkgLength being used for the size of the buffer containing UTF-16
strings when the length could be encoded in a single PkgLength byte. In
that case, Windows previously ignored the whole SSDT containing this
larger than necessary PkgLength encoding. It should however be noted
that the ACPI 6.4 spec doesn't specify if it's required to always use
the most compact possible encoding of the PkgLength or not. Since iasl
generates the shortest possible PkgLength encoding, it's also a good
idea to make coreboot's acpigen do the same although it's not required
by the specification.
With this patch applied, Windows still boots on Mandolin and the time it
takes to write the tables doesn't change. To measure the times, the log
level in bs_sample_time was increased to BIOS_CRIT and the console log
level was increased to BIOS_CRIT too to only get those times as output.
BS: BS_WRITE_TABLES run times (exec / console): 8 / 0 ms
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib897b08a05a7cdc52902d51364246c260ea1f206
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
The buffer length is in bytes, and since we are converting from ASCII
to UTF-16, the value written needs to be 2x the string length + null
terminator.
TEST=build/boot google skyrim (frostflow), dump acpi and check bytecode
for correct buffer length preceding unicode strings.
Change-Id: Id322e3ff457ca1c92c55125224ca6cfab8762a84
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
For GICD and GICR a SOC needs to implement 2 callbacks to get the base
of those interrupt controllers.
For all the cpu GIC the code loops over all the DEVICE_PATH_GICC_V3
devices in a similar fashion to how x86 lapics are added. It's up to the
SOC to add those devices to the tree.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5074d0a76316e854b7801e14b3241f88e805b02f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76132
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since d8f2dce "acpi.c: Swap XSDT and RSDT for adding/finding tables"
XSDT is primarily used to add new tables or to find the S3 resume vector.
However with QEMU coreboot does not generate most ACPI tables but takes
them from whatever QEMU provides. Qemu only creates an RSDT and lacks an
XSDT.
To keep the codebase simple with the assumption that XSDT is always
present, create an XSDT based on the existing RSDT and update the
address in RSDP.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ia9b7f090f55e436de98afad6f23597c3d426bb88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77385
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In soundwire.h, SOUNDWIRE_DPN MIN & MAX are set to 1 and 14. When
creating the dpn array, the length was set to MAX - MIN or 13, numbered
0 to 12.
When accessing the array, the code was bailing out if a value greater
than MAX was trying to be accessed, so the array was able to be overrun
by two structure lengths.
Fix this problem by:
1) Not subtracting the MIN value when creating the array, which does
waste a little space. If anyone wants to refactor the code to fix that,
please feel free.
2) Breaking out of the loop when the port is equal to the MAX port
number instead of just when it's greater than the max port number.
Reported-by: Coverity (CID:1429766 & CID:1429771)
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0841bb8c9869fe9f53958f05614848785a98b766
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Allow the use of 64bit MMCONF base in MCFG table.
Previously only 32 bits were utilized for MMCONF base, while the
remaining 32bits were reserved & held value of zero as evident from MCFG
table disassembly. This commit entails updating the 'base_address' field
in the 'mmconfig' structure to 64 bits and removing the 'base_reserved'
field.
TEST=Confirmed the functionality of the 64bit MMCONF base in the MCFG
table disassembly below
Signature : "MCFG"
Table Length : 0000003C
Revision : 01
Checksum : BD
Oem ID : "COREv4"
Oem Table ID : "COREBOOT"
Oem Revision : 00000000
Asl Compiler ID : "CORE"
Asl Compiler Revision : 20230628
Reserved : 0000000000000000
Base Address : 0000001010000000
Segment Group Number : 0000
Start Bus Number : 00
End Bus Number : FF
Reserved : 00000000
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I2f4bc727c3239bf941e1a09bc277ed66ae6b0185
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77539
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
