Conversation
This is a workaround for modules that don't correctly populate the serial number field in SPD. When such modules are swapped, they generate the same CRC, causing FSP to mistakenly consider them the same, and attempt to restore cached MRC settings. This won't work when the modules are different. As a workaround, force retrain the memory when RTC failure is detected. Users are expected to reset their CMOS upon changing memory modules. Upstream-Status: Pending Change-Id: Iebb2810914b728317ce5ebd84b61667d2ba10529 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Pending Change-Id: I4843ed215bff8a003799b399885950e69d1daf4d Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I3b95df4a9a4cadb4037e301e3e55d73b60888003 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
…le lines Change-Id: I58d4caf5c2a0c4031cf7d319f83587e50b34cc48 Upstream-Status: Pending Rationale: coreboot coding style guidelines Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: Ib34ffb1fb42452e35428aa4192bb0f09fbb37d48 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: Ie930895584574d8607a2dc9605f0f1c8f5da7e1f Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
DDR5 SPD page length is 1024 bytes. Change-Id: I40bf0e8ae842ddb70b18838f9a0830226ee82652 Upstream-Status: Pending Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I9b0f330866fab5fd91f3fdd2ee81f11a963c1ce0 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I88084315150141a81ab8122c0ebf4d6d9ea739c2 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Sebastian Czapla <sebastian.czapla@3mdeb.com>
Fixes the problem reported by Linux: [Firmware Bug]: ACPI MWAIT C-state 0x33 not supported by HW (0x1010) Change-Id: I5a9234876158f058927cc5ede172c8d271e37c46 Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I6ff875db7311e3417f7fdb119a11cd97a62589c8 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I1cbcaac1ee430c4f8900178be810063758fdb3f2 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Intel Bay Trail SoCs (confirmed on Atom E3845) have leading spaces in the CPU brand string returned by CPUID. Strip these spaces so that SMBIOS CPU string does not look weird in the EDK2 setup page and the dmidecode output. Change-Id: I6f70a0373cca4bbec87408d47f9ddd868a109a0e Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I502df506b49ba6b5f45e88be2b8cca3e638d1da6 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I304761946ee64f104658d93a37f3870e9a46a9c2 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I0289f4079a7b4ab92ad17e37f0cb6abe25ec918a Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I6d94ca463045af63e2f91e43cb390671103ccd4d Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The utility assumed that TCG TPM log area is zeroed and then filled with events but it does not have to be true. If there is garbage after the last valid event entry, the utility will most likely access data outside of the cbmem area containing the logs. Relevant issue: linuxboot/heads#1608 TEST=Dump TCG TPM1.2 event log on Dell OptiPlex 7010 and see "Invalid TPM1.2 log entry overflowing cbmem area" error is printed. Upstream-Status: Submitted [CB:84926] Change-Id: I7e057db3378b701d046d4e578272b10f294142a7 Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The log area was not entirely cleared on creation resulting in garbage after the last valid lgo entry. It caused the cbmem utility to parse invalid events and access data outside the log area. In the TPM2 log sources, the entire area is being cleared, thus the issue has not been observed. Upstream-Status: Submitted [CB:84927] Change-Id: I7c780b62b1c6507e1dd1806b20b0270e364cde3d Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3afbc8a1655c5488e67a1f91e6a17504d92f60df Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
According to shcematics only Ethernet controllers have CLKREQ signal routed. However, it is required for each Root Port to have a CLKREQ signal routed. Otherwise, we hit the issue with MCE caused by lack of clock, described in fill_fsps_pcie_params. Unfortunately no ADL-N FSP has PchPcieClockGating and PchPciePowerGating, so one has to fake the CLKREQ signals for each port. Fortunately the ports with missing CLKREQ can be assigned to unused CLKREQ signals which are tied to GND per schematics. This will cause the CLKREQ to be always active for those devices and not hit the issue with MCE. The issue has been observed by constant dropping of RDP connection to Windows less than a minute after logging in. TEST=RDP connection to Windows is not severed for over 10 minutes. Change-Id: Ie00ac2a678d642753aeb26a8e1779d8d74909a62 Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ie66e06ae08549c6df056bee8a6fec7ed9a79c177 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
… series Change-Id: Ifbc24c4a33ccf05505f0e363346918a1645144de Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ifa253724d553667aaaa0c9bbd30ee28a705c515b Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ia8171560fc8b6b89be2d293547a94cfc63e795af Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I6e6cd8226a8006250eb9f04e0d9b958f239d0d64 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5ae3e27826b07c093aaf1d63ee2cb743bc03ce1a Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I605df3d1ccc2b6ab52f0dbe1486b3dcecbf61da4 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I2ad93b4c35c9f2483275fe484fcd82c590feb13f Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com> Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I157b1649a2bfef9dc842a515b1ae758685fbfabd Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Starting with Lunar Lake, the scaling factor information is centralized in the power control unit (PCU) firmware. In order to keep all firmware in sync, it is recommended to read the scaling factors from the PCU firmware instead of using hard-coded values. This commit adds a new Kconfig option, CONFIG_SOC_INTEL_COMMON_BLOCK_RUNTIME_CORE_SCALING_FACTORS, to allow SoC specific code to specify its own function to read the core scaling factors. When this option is enabled, the soc_read_core_scaling_factors() function from the SoC specific code is used to read the core scaling factors instead of using the statically defined values CONFIG_SOC_INTEL_PERFORMANCE_CORE_SCALE_FACTOR and CONFIG_SOC_INTEL_EFFICIENT_CORE_SCALE_FACTOR. Upstream-Status: Backport [25.03] Change-Id: Icdf47e17cc5a6d042f3c5f90cf811fccd6c1ed9b Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/85553 Reviewed-by: Pranava Y N <pranavayn@google.com> Reviewed-by: Cliff Huang <cliff.huang@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds support for reading core scaling factors via the
PCODE mailbox interface.
Starting with Lunar Lake, the scaling factor information is
centralized in the power control unit (PCU) firmware. In order to keep
all firmware in sync, it is recommended to read the scaling factors
from the PCU firmware instead of using hard-coded values.
The following changes were made:
- Updated the Kconfig file to select
SOC_INTEL_COMMON_BLOCK_RUNTIME_CORE_SCALING_FACTORS option
- Modified the acpi.h header file to export the cpu_perf_eff_type
enumeration for CPU performance/efficiency types.
- Added a new function to the pantherlake systemagent.c file,
soc_read_core_scaling_factors(), which reads the core scaling
factors from the PCODE mailbox interface. The pcode
READ_CORE_SCALING_FACTOR is presented in document 829201 Panther
Lake Processor Mailbox Command.
The performance impact on boot time is minimal. It took 12 us to read
the scaling factors on a fatcat device.
TEST=Successfully read performance and efficient scaling factors on a
fatcat board.
Upstream-Status: Backport [25.03]
Change-Id: I7a8e1e66a02e4bf6b1a41277e83c6dec786fe169
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85554
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
This resolves a crash issue observed on Meteor Lake and introduced by commit 70bdd2e ("cpu/x86/topology: Simplify CPU topology initialization"). This commit simplifies the code and provides more detailed CPU topology information by generalizing the use of the Extended Topology Enumeration Leaves 0x1f. As a result, the coreboot APIC core_id field does not provide the fully detailed path information. It turns out that the topology core identifier is used by the coreboot MP service mp_get_processor_info() implementation. But the MP Service EFI_CPU_PHYSICAL_LOCATION data structure only captures information about the package, core, and thread. The core identifier returned to the MP service caller must incorporate the full hierarchical path (die group, die, module, tile, module and core). This commit adds a new field to the cpu topology structure to represent the core ID within the package. For reference, here is that signature of the crash: LAPIC 0x40 in X2APIC mode. CPU Index 2 - APIC 64 Unexpected Exception:13 @ 10:69f3d1e4 - Halting Code: 0 eflags: 00010046 cr2: 00000000 eax: 00000001 ebx: 69f313e8 ecx: 0000004e edx: 00000000 edi: 69f38018 esi: 00000029 ebp: 69aeee0c esp: 69aeedc0 [...] The crash occurred when FSP attempted to lock the Protected Processor Inventory Number Enable Control MSR (IA32_PPIN_CTL 0x4e). 69f3d1d3: 8b 43 f4 mov -0xc(%ebx),%eax 69f3d1d6: 89 4d c4 mov %ecx,-0x3c(%ebp) 69f3d1d9: 89 45 dc mov %eax,-0x24(%ebp) 69f3d1dc: 8b 55 c4 mov -0x3c(%ebp),%edx 69f3d1df: 8b 45 c0 mov -0x40(%ebp),%eax 69f3d1e2: 8b 4d dc mov -0x24(%ebp),%ecx 69f3d1e5: 0f 30 wrmsr 69f3d1e7: e9 ee fd ff ff jmp 0xfffffe39 FSP experiences issues due to attempting to lock the same register multiple times for a single core. This is caused by an inconsistency in the processor information data structure, where multiple cores share the same identifier. This is not permitted and triggers a General Protection Fault Exception. TEST=Executing CpuFeaturesPei.efi in FSP-S does not crash on a rex board. Upstream-Status: Backport [25.03] Change-Id: I06db580cddaeaf5c452fa72f131d37d10dbc5974 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/86004 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Cliff Huang <cliff.huang@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Change-Id: I9381be805b5345650848dfb8945c168d15a7c55b Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I866fbf9622341f711904fdeef5e21f24a8e8d2bf Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I7187b24adae3138488f9a50ed19a83898e6ca409 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The option logic has been changed to default false but the coreboot configs were not updated to enable the options for the platforms that should have the quiet and fast boot. Change-Id: I289b7bde108db19c50e4fa157381b143685c7d63 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I4eaf5cd08574ca5012f86a5d1d050af872036760 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I0a5650de8da73a9fe168457c0cfe817a6e6fd0be Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Change-Id: I09e700bacd0187ef1f6ebb286a3ad3367c4964dd Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
1. Don't try to power it on again if it was powered on already. 2. Kick the platform via global reset if the GPU fails to come up. This reliably fixes dGPU detection. Upstream-Status: Pending Change-Id: I76b80ec8c988d25adff23f02b697d98885848f35 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I74f38ddfec9a3665478875e4866731fef5587379 Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Change-Id: Ied54e079fe913e724e5da822d1051dc340b29884 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Jakub Redmerski <jakub.redmerski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I795041b444888fe6524640fdf3d042e8ed9fa6cd Signed-off-by: Jakub Redmerski <jakub.redmerski@3mdeb.com>
Fix some typos and also update the naming convention of `CFR_OPTFLAG_GRAYOUT` to `CFR_OPTFLAG_INACTIVE` as per reviews. Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com> Change-Id: Id66808382b93e32c58024462c18b20c2a89d6d23 Reviewed-on: https://review.coreboot.org/c/coreboot/+/85780 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Christian Walter <christian.walter@9elements.com>
Add a version field to the CFR root struct so parsers can check compatibility when parsing structs. Change-Id: Ifcb950f1bdedc0ab925f3841befb7e7001c0f7f4 Signed-off-by: Filip Brozovic <fbrozovic@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/86080 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Implements a way for CFR options to depend on another option being set to one or more specific values. This is achieved by writing a list of values as a varbinary struct. Change-Id: Iaf7965551490969052eb27c207fa524470d4dd6a Signed-off-by: Filip Brozovic <fbrozovic@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/85987 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Sean Rhodes <sean@starlabs.systems> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds support for minimum/maximum limit values as well as step sizes for CFR number options. Additionally, add a new flag that specifies the option should be displayed in hexadecimal notation instead of decimal. Change-Id: I2e70f1430fb1911f1ad974832f8abfe76f928ac3 Signed-off-by: Filip Brozovic <fbrozovic@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/86039 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I749ecf2eb041dfbe2f6f93b5e3a7b2af3c78bb1d Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I123561aa82ac87e105c1a9592e05e1787963e72d Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I3a12f8bcf7b5fd52c0153b29e88d5d3fc55312e3 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: Ib3d1df648e50dc85f432f8c9f14fb685edf6facd Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: Ide2a3a4b59be5b27bf7315690520c9392a98d044 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I486d9faae85f79edb2d025578951ef55817198be Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Change-Id: I957a0cbd0dbea20f4408775dde5115cbfa7892e7 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Member
|
I've been using a thinkcentre tiny as my test mule. The current status is:
That's basically it. The CFR form is displayed as a single scrollable page, which is nice on a big monitor, but will wreak havoc on our tests over serial console. I didn't bother to call the options identically to our edk2 versions but it should be possible. Overall it seems to work well, I haven't seen any major issues. Reset to default works fine even if you call it before entering the menu, which was a pain point with some previous dynamic form implementations. |
Contributor
Member
|
The benefit is that it will be easier to add options, especially board-specific options. Right now we have all options in the same place edk2 with PCDs to control their visibility, which adds a lot of code for each board specific option. CFR allows the mainboard to specify options for the payload. So options like these will be easier to add:
plus hopefully it makes us closer to upstream |
Contributor
|
@mkopec ok, make sense. I wonder how much time we spent on those operations in the past and how much we will have to spent now. This would prove if it improves situation. For now we just have hipothesis. Easier control of board specific options, as well as those who customer want/may have according to their plan, is important feature. Hopefully we can leverage that more efficiently when it would be merged. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.