Introduce a mechanism so that coreboot can provide a list of options to
post-coreboot code. The options are grouped together into forms and
have a meaning name and optional help text. This can be used to let
payloads know which options should be displayed in a setup menu,
for instance. Although this system was written to be used with edk2,
it has been designed with flexibility in mind so that other payloads
can also make use of this mechanism. The system currently lacks a way
to describe where to find option values.
This information is stored in a set of data structures specifically
created for this purpose. This format is known as CFR, which means
"coreboot forms representation" or "cursed forms representation".
Although the "forms representation" is borrowed from UEFI, CFR can
be used in non-UEFI scenarios as well.
The data structures are implemented as an extension of cbtables records
to support nesting. It should not break backwards compatibility because
the CFR root record (LB_TAG_CFR_ROOT) size includes all of its children
records. The concept of record nesting is borrowed from the records for
CMOS options. It is not possible to reuse the CMOS records because they
are too closely coupled with CMOS options; using these structures would
needlessly restrict more capable backends to what can be done with CMOS
options, which is undesired.
Because CFR supports variable-length components, directly transforming
options into CFR structures is not a trivial process. Furthermore, CFR
structures need to be written in one go. Because of this, abstractions
exist to generate CFR structures from a set of "setup menu" structures
that are coreboot-specific and could be integrated with the devicetree
at some point. Note that `struct sm_object` is a tagged union. This is
used to have lists of options in an array, as building linked lists of
options at runtime is extremely impractical because options would have
to be added at the end of the linked list to maintain option order. To
avoid mistakes defining `struct sm_object` values, helper macros exist
for supported option types. The macros also provide some type checking
as they initialise specific union members.
It should be possible to extend CFR support for more sophisticated
options like fan curve points. Feedback about this is highly
appreciated.
Change-Id: I304de7d26d79245a2e31a6d01f6c5643b31cb772
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74121
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to document 559910 Intel Connectivity Platforms BIOS
Guideline revision 8.2 and 9.2 specifications, both revision 0 and 1
are supported and share the same structure.
BUG=b:346600091
Change-Id: Id0e05a9db48445b9254701d2a09c19bfbd477284
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85586
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This commit rewrites the CPU topology initialization code to simplify
it and make it more maintainable.
The previous code used a complex set of if-else statements to
initialize the CPU topology based on the CPUID leaves that were
supported. This has been replaced with a simpler and more readable
function that follows the Intel Software Developer Manual
recommendation by prioritizing CPUID EAX=0x1f over CPUID EAX=0xb if
available.
The new code removes the need for separate functions to handle the
topology initialization for different CPUID leaves. It uses a static
array of bitfield descriptors to store the APIC ID descriptor
information for each level of the CPU topology. This simplifies the
code and makes it easier to add new levels of topology in the future.
The code populates the node ID based on the package ID, eliminating
the need for an extra function call.
Change-Id: Ie9424559f895af69e79c36b919e80af803861148
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85576
Reviewed-by: Jincheng Li <jincheng.li@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
In order to debug stack smashing add a write breakpoint to the
stack canary (at _stack or _car_stack) and print the IP when the
stack canary is written.
TEST: Wrote to address _stack in ramstage and got the EIP of the
code that smashed the stack canary.
Change-Id: I8adf07a8425856795a4a71da5c41bec2244b02a8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84833
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The following functions are added:
_create_buffer_field
acpigen_write_create_buffer_byte_field
acpigen_write_create_buffer_word_field
acpigen_write_create_buffer_dword_field
acpigen_write_create_buffer_qword_field
These functions are to generate:
CreateByteField (<namestring> , offset, <field name>)
CreateWordField (<namestring> , offset, <field name>)
CreateDWordField (<namestring> , offset, <field name>)
CreateQWordField (<namestring> , offset, <field name>)
NOTE:
There are set of acpigen_write_create_[byte/word/dword/qword]_field
functions already, but the field can only be created from Arg[n] or
Local[n] variable objects. A Name object must be first assigned to such
variable. The new functions here will allow us to create field directly
from Name object.
BUG=none
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I725f17329c501c80d42034e0f6a2fccb2cef5915
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85197
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On platforms with multiple IOAPICs the GSI base must not be
linear, which is currently assumed by acpi_create_madt_ioapic_from_hw().
Integrate the existing struct device DEVICE_PATH_IOAPIC type and allow
to assign custom GSI bases for each IOAPIC. Write out the IOAPIC devices
into the MADT table if any.
For now, since no platform adds IOAPIC devices, the existing behaviour
remains the same. Allows to get rid of soc_get_ioapic_info().
Change-Id: Ie13d4f5c4f0704f0935974f90e5b7cf24e94aab3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add functions to send the RPMC-related commands to a RPMC-capable SPI
flash to provision the root key, update the HMAC key, increment the
monotonic counter, and request the monotonic counter data. To talk to
the flash chip, the command bytes and polling mechanism described in the
SFDP data structure of the flash are used.
The JESD260 specification was used as a reference.
Some of inspiration was taken from
github.com/teslamotors/coreboot/tree/tesla-4.12-amd
TEST=When used with the later patch that calls some of the functions
added in this patch, sending the RPMC increment monotonic counter
command to the RPMC-capable SPI flash, in this case W74M12JW, is
successful.
Change-Id: Ia9bd69d0105c66bf5ecb6c90e8c782a81912bd40
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84837
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These header files do not seem to be used in coreboot. Presumably
they're left over after the code that used them was removed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ide70239c7c2e93fff548d989735450396308c62b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85370
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Drive Strength BRI Rsp Object provides information from the OEM
platforms if they have replaced the Bluetooth Radio Interface resistor
to overcome the potential STEP errors on their designs. Based on
configuration, CNV firmware shall adjust the BRI Rsp line drive
strength.
The bri_resistor_value is encoded as follow:
| Bit | Val | Description | Default |
|------+-----+---------------------------------------------+---------|
| 0 | 0 | Device FW default values | 1 |
| | 1 | Override device FW default values | |
| 3:1 | 0 | Reserved (shall be set to 0) | 0 |
| 7:4 | 0 | DSBR override values (only if bit 0 is set) | 0xf |
| 31:7 | 0 | Reserved (shall be set to 0) | 0 |
Possible values:
- 0xf1 (default): indicates that the resistor on board is 33 Ohm
- 0x0 or 0xb1: indicates that the resistor on board is 10 Ohm
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=DSBR methods are added to the wifi device and bluetooth companion
device and they return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e300
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85017
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This feature provides ability to provide Wi-Fi PHY filter
Configuration. A well-defined dedicated filter on particular platform
can be used to perform the maximum Wi-Fi performance.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=WPFC method is added to the wifi device and return the data
supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e270
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84948
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Extended Bluetooth Regulatory Descriptor (EBRD) SAR/RFE are safety
regulations for limiting antenna radiation near human contact. EBRD
provides option to provide up to three sets of TX power limits and
power restrictions.
As the EBRD table is related to the revision 2 of the BRDS, this
commit also adds support for this new revision.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=EBRD method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e250
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84947
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This feature provides ability to set the Bluetooth Dual Mac Mode
setting.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BDMM method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e240
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84946
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This feature provides ability to set the Bluetooth Ultra High
Band (UHB) settings per country. The bluetooth UHB country selection
is defined as follow (default is 0):
| Bit | Value | |
|-------+-------+---------------------------------------------------|
| 0 | 0 | No override; use BT device settings |
| | 1 | Force disable BT in all countries that are not |
| | | defined in the following bits |
| 1 | 0 | USA 6GHz BT disable |
| | 1 | 6GHz BT allowed in the USA (enabled only if the |
| | | device is certified to the USA) |
| 2 | 0 | Rest of the World 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Rest of the World (enabled |
| | | only if the device is certified to the rest |
| | | of the world) |
| 3 | 0 | EU countries 6GHz BT disable |
| | 1 | 6GHz BT allowed in the EU countries (enabled only |
| | | if the device is certified to the EU countries) |
| 4 | 0 | South Korea 6GHz BT disable |
| | 1 | 6GHz BT allowed in the South Korea (enabled only |
| | | if the device is certified to the South Korea) |
| 5 | 0 | Brazil 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Brazil (enabled only if |
| | | the device is certified to the Brazil) |
| 6 | 0 | Chile 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Chile (enabled only if the |
| | | device is certified to the Chile) |
| 7 | 0 | Japan 6GHz BT disable |
| | 1 | 6GHz BT allowed in Japan (enabled only if the |
| | | device is certified to Japan) |
| 8 | 0 | Canada 6GHz BT disable |
| | 1 | 6GHz BT allowed in Canada (enabled only if the |
| | | device is certified to Canada) |
| 9 | 0 | Morocco 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Morocco (enabled only if |
| | | the device is certified to the Morocco) |
| 10 | 0 | Mongolia 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Mongolia (enabled only if |
| | | the device is certified to the Mongolia) |
| 11 | 0 | Malaysia 6GHz BT disable |
| | 1 | 6GHz BT allowed in the Malaysia (enabled only if |
| | | the device is certified to the Malaysia) |
| 31:12 | 0 | Reserved Should set to zeros |
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BUCS method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e231
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This feature provides ability to provide dual chain setting.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BDCM method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e220
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84943
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This feature provides ability to identify non-LTE platform and disable
BiQuad Bypass filter logic in hardware for Bluetooth usecases reducing
device power consumption.
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BBFB method is added to the bluetooth companion device and
return the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e213
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The ACPI BPAG method provide information to controls the antenna gain
method to be used per country.
The antenna gain mode is a bit field (0 - disabled, 1 -enabled)
defined as follow:
- Bit 0 - Antenna gain in EU
- Bit 1 - Antenna gain in China Mainland
The implementation follows document 559910 Intel Connectivity
Platforms BIOS Guideline revision 9.2 specification.
BUG=b:346600091
TEST=BPAG method is added to the bluetooth companion device and return
the data supplied by the SAR binary blob
Change-Id: Iebe95815c944d045f4cf686abcd1874a8a45e210
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add const qualifier for input of dev_is_active_bridge so that
dev_is_active_bridge could be used for both struct device * input
and const struct device * input.
TESTED=Build and boot on intel/avenuecity CRB
Change-Id: Ia4231534c87cd13d4e6e4d606733f9eb11221ac1
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Add a helper function to identify PCI IOAPICs.
Will be used in the following commits.
Change-Id: Ibe50934260b025575440fd52eace73fe2327a193
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
PRMRR (Protected Region Memory Range Region) are not accessible as
normal DRAM regions and needs to be explicitly reserved in memory
map.
Change-Id: I81d17b1376459510f7c0d43ba4b519b1f2bd3e1f
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Definitions of __fls/__ffs from lib.h and fms/fls from
cpu/x86/mtrr.h are duplicated. Use definition from lib.h which is
more generic.
Change-Id: Ic9c6f1027447b04627d7f21d777cbea142588093
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85104
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fill 'rpmc_caps' struct inside the 'spi_flash' struct with the RPMC info
from the SFDP table.
TEST=On a board with a W74M12JW SPI flash chip, the 'rpmc_caps' struct
has the expected entries (RPMC available, OP2 extended status as polling
method, 4 RPMC counters, OP1 is 0x9b, and OP2 is 0x96).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3a8332bffe93e1691f6fc87c3936025f158f3ab9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Add basic support for the Serial Flash Discoverable Parameters (SFDP)
standard which can be used to discover the parameters to interact with
any SPI flash chip that supports this mechanism. This commit adds
functionality to find specific SFDP parameter headers and print all SFDP
parameter headers, but not to parse any SFDP parameter table. This is a
preparation for a follow-up patch that adds support to parse the RPMC
SFDP parameter table. Since 'find_sfdp_parameter_header' is only used in
the next patch, it's marked as static inline in this commit so that the
code still build; the 'inline' keyword will be removed again in that
follow-up patch.
For now, only the legacy access protocol using single bit SPI transfers
is supported, but this should cover most of the SPI NOR flash chips. In
any other case, the code will error out. It's also assumed that the SFDP
data blocks read from the SPI flash chip are small enough to fit into
the SPI host controller buffer and don't need to be broken up into
multiple transfers. This limitation will be addressed in a follow-up
patch.
JESD216F.02 was used as a reference.
TEST=On a board with a W74M12JW SPI flash chip, calling
'spi_flash_print_sfdp_headers' prints this on the console output:
Manufacturer: ef
SF: Detected ef 6018 with sector size 0x1000, total 0x1000000
SF: Exiting 4-byte addressing mode
SFDP header found in SPI flash.
major rev 0x1, minor rev 0x6, access protocol 0xff, number of headers 3
SFPD header with index 0:
table ID 0xff00, major rev 0x1, minor rev 0x6
table pointer 0x80, table length DWORDS 0x10
SFPD header with index 1:
table ID 0xff84, major rev 0x1, minor rev 0x0
table pointer 0xd0, table length DWORDS 0x2
SFPD header with index 2:
table ID 0xff03, major rev 0x1, minor rev 0x0
table pointer 0xf0, table length DWORDS 0x2
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5a1706acf7d60fd64292e8f0677992ab4aebf46a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84786
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
As per commit 8651731537 ("sconfig: Move config_of_soc from device.h
to static.h") and commit 05a13e7ed9 ("sconfig: Move (WEAK_)DEV_PTR
from device.h to static.h"), sources that require access to the
devicetree should directly include static.h. This allows static.h to be
removed from device.h, eliminating many unnecessary dependencies on the
devicetree for objects that only need the device types and function
declarations.
Now that static.h has been included throughout the tree where necessary,
it can be removed from device.h.
Change-Id: Ie72840c71ffca2ada82456dda6a2c813f6a6c3ad
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84590
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Similar to commit 8651731537 ("sconfig: Move config_of_soc from
device.h to static.h"), move these macros to static.h to separate
dependencies on device.h and static.h. These macros resolve to device
alises that are declared in the generated static_devices.h header, so
move them to static.h which includes static_devices.h.
Since static.h remains included in device.h, any source that uses these
macros should still compile correctly. Subsequent commits will add
static.h to files that need them, after which static.h can be dropped
from device.h.
Change-Id: I1c76ad749769591da9c102b11eb618e93b68bd7c
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84676
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
By default, PCH SMBus codes will be called to retrieve SPD data. This
patch adds a SPD IO layer so that SoC could implement its specific SPD
IO layer functions such as using Integrated Memory Controller to get
SPD data.
Change-Id: I656298aeda409fca3c85266b5b8727fac9bfc917
Signed-off-by: Yuchi Chen <yuchi.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84201
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds new DID0 PCI device IDs for Intel PTL-H.
Additionally, updates the System Agent driver's `systemagent_ids`
list and Panther Lake SoC bootblock to support these new IDs.
Source: Intel PTL-FAS. Document Number 812562
BUG=b:347669091
TEST=Build fatcat and boot with Panther Lake SoC with newly added
MCH ID.
With patch, coreboot log:
`[DEBUG] MCH: device id b004 (rev 00) is Pantherlake H`
`[DEBUG] MCH: device id b00a (rev 00) is Pantherlake H`
Change-Id: I56e795696f661d88828d7549f856eee19c46c942
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84916
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Add a helper method to read the PME capability.
Will be used in the following commit.
Change-Id: Id1fdc98c9ce86d3ddf8056bb609afc58008cf2e9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84793
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add and use a new helper function to determine if a device is
1) a PCIe device
2) it's mark hot-plug capable
Change-Id: I61cc013844024b43808cd2f054310cb6676ba69e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84792
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Fix the following error when including device/pciexp.h
src/include/device/pciexp.h: In function 'pciexp_is_downstream_port':
src/include/device/pciexp.h:42:24: error: 'PCI_EXP_TYPE_ROOT_PORT' undeclared (first use in this function)
42 | return type == PCI_EXP_TYPE_ROOT_PORT ||
by including pci_def.h.
Change-Id: Idfd36301a5e766bbe97c93afef88c97507a4c4dc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84791
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The first table from the chapter 4.1 'OP1/OP2 Command Definition: No
Address Phase' of the JEDEC standard JESD260 (Replay Protected Monotonic
Counter (RPMC) for Serial Flash Devices) in the version from April 2021
was used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0050aea6cdc537122bae63fddb417dd9f6b75a02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84703
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
STMicro first moved their SPI NOR flash business to Numonyx which was a
joint venture with Intel which later got sold to Micron, so add a
comment to the VENDOR_ID_STMICRO JEDEC manufacturer ID define and
mention all 3 companies that have sold SPI NOR flash chips using this
manufacturer ID to the Kconfig help text of SPI_FLASH_STMICRO.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7886396d8f0a9766f568a221c0b5ade02489060b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84018
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add helper function to allow platform to fill gicc parameters for use in
ACPI table.
Change-Id: Ibd4c52a5482707fae8aa1b8b21fdc6bb5f4b45c2
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79973
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates SoundWire driver to support ALC721 audio codec
based on config flag.
reference datasheet: Realtek ALC721-VA0-CG Rev. 0.34
BUG=b:368495490
TEST=This driver was tested on Intel RVP with Add-on ALC721 codec card
by testing soundcard binding/devices are detected and check for audio
playback.
Change-Id: I1022ee91b16374d0d4d07e5198226595d61403a6
Signed-off-by: Varun Upadhyay <varun.upadhyay@intel.com>
Signed-off-by: Naveen M <naveen.m@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
IORT table represents IO topology of an Arm based system for use
with the Advanced Configuration and Power Interface (ACPI)
Add helper functions for ACPI IORT table for:
1. ITS (Interrupt Translation Service)
2. SMMUV3
3. ID MAP
4. Named Component
5. Root Complex
Based on document: DEN0049E_IO_Remapping_Table_E.e
Change-Id: I7feaf306b5eea21bfc9a2e2a1a2c3ddc3c683c0b
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79404
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GCC-13 introduced the nullptr constant. Use it when compiling with the
C23 standard.
Change-Id: I07db866bebfd25f1a60d18a3228ada2957500234
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83459
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Many sources include device.h and thus static.h, but many only need the
function declarations and type definitions, not the compiled devicetree
from sconfig. This causes many unnecessary recompiles whenever the
devicetree is updated due to the dependency. Address this by moving the
config_of_soc macro directly into the generated static.h header, as it
seems to be the only line in device.h that actually requires static.h.
For now, static.h remains included in device.h so that the build is not
affected. Subsequent commits will include static.h directly into sources
that actually need it, after which it can be dropped from device.h.
Some statistics for C objects:
Dell Latitude E6400 (GM45/ICH9):
669 total objects
181 depend on static.h
2 require static.h
Dell Latitude E6430 (Ivy Bridge/Panther Point):
693 total objects
199 depend on static.h
3 require static.h
Lenovo ThinkCentre M700 / M900 Tiny (Kaby Lake):
794 total objects
298 depend on static.h
23 objects require static.h
MSI PRO Z690-A (WIFI) DDR4 (Alder Lake):
959 total objects
319 depend on static.h
25 require static.h
The number of objects was determined by grepping the build log for
calls to CC, the number of objects that depend on static.h was
determined by grepping for calls to CC after touching static.h, and the
number of objects that actually require the static.h related lines from
device.h was determined by grepping for objects that failed to build
after removing the static.h lines from device.h and running make with
the --keep-going flag.
Change-Id: I7c40135bf2815093b81e47201c38b7d0a6ac8fa8
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When compiling with the C23 standard, bool, true, and false are
pre-defined by the language, so defining them in stdbool.h isn't allowed.
This fixes the following error:
src/include/stdbool.h:6:17: error: two or more data types in declaration specifiers
6 | typedef _Bool bool;
| ^~~~
src/include/stdbool.h:6:1: error: useless type name in empty declaration [-Werror]
6 | typedef _Bool bool;
| ^~~~~~~
Change-Id: Iec9b4e3f308008ece773ce3460daff97370161ea
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
IBL eSPI should be correctly configured by LPC driver so that console
input is usable.
Change-Id: I77cc6dd67b36035974e7f268d32b8473e8d83483
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Because PLATFORM_USES_FSP2_X86_32 default to false when
PLATFORM_USES_FSP1_1, efi_datatype.h wrongly defines EFI as
__attribute__((__ms_abi__)).
TEST=When some code involved in the build of a platform using
FSP 1.1 such as Google/CYAN includes efi_datatype.h, it does
not hit the following error: '__ms_abi__' calling convention
is not supported for this target
Change-Id: I914f73ff06bfb801fc319b45b23d7ce4cb7a6d5d
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84402
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These identifiers are not included in the GPU list from Intel [1].
At the same time, 0x9B44 is not PCI DID of graphics device at all:
8086:9B44 - 10th Gen Core Processor Host Bridge/DRAM Registers [2].
[1] https://web.archive.org/web/20240731152818/https://
dgpu-docs.intel.com/devices/hardware-table.html
[2] https://web.archive.org/web/20231004011832/https://devicehunt.com/
view/type/pci/vendor/8086/device/9B44
Change-Id: I8ff7b062f930cb63ffd9caf240874742bd53fc23
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
According to the Intel GPU list[1], 0x3E9B is DID of "Intel UHD Graphics
630" for the Coffee Lake processor family and has already been added to
the pci_ids.h as PCI_IDE_INTEL_CFL_H_GT2.
At the same time, the real PCI DID for Comet Lake-H GT2 is 0x9BC2 [1],
which is missing in the file.
[1] https://web.archive.org/web/20240731152818/https://
dgpu-docs.intel.com/devices/hardware-table.html
Change-Id: Iacab0a03388af3f6fd5d78a597580037889e8ef2
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
