coreboot September 2023

coreboot@coreboot.org

26 participants
33 discussions

How to get reviews on gerrit? aka. patches ignored for three years.
by Daniel Gröber 05 Oct '23

05 Oct '23

Hi, could someone tell me how I'm supposed to deal with unresponsive reviewers on gerrit? Clearly I must be doing something wrong as the patches have been gathering dust for around three years now. https://review.coreboot.org/q/topic:%22macronix-spi-bp%22 --Daniel

6 11

Qemu with persistent CMOS RAM (save / restore)
by Simon Glass 30 Sep '23

30 Sep '23

Hi, Is it possible to save and restore CMOS RAM with qemu, or some other emulator? I'd like it to be kept in a file on my system, so I can run coreboot multiple times and the CMOS RAM is preserved across runs. For example, if I make a change to a CMOS location, then I'd like that change to still be visible on the next run. Regards, Simon

1 0

RFC: Post-build control of serial console
by Simon Glass 29 Sep '23

29 Sep '23

Hi, RFC: Post-build control of serial console It is annoying to have to create and maintain two completely different builds of coreboot just to enable or disable the console. It would be much more convenient to have a 'silent' flag in the image, which can be updated as needed, without needing to rebuild coreboot. For example, if something goes wrong and coreboot hangs, it would be nice to be able to enable serial on the same image, then boot it again to see how far it gets. I propose a 'Coreboot Control Block' (CCB) which can hold a small number of such settings. It is designed to be available very early in bootblock, before CBFS is ready. It is able to control the output of the very first bootblock banner. early silicon-init, etc. It is built as part of the bootblock image, so can be accessed simply as a static C struct within the bootblock code. That means that the code overhead is very low and we could perhaps enable it by default. The bootblock can have a CBFS file attribute that indicates that it contains a CCB and the offset where it is stored. Other coreboot stages can read this as well, or it could be duplicated in a separate file. We can provide options in cbfstool to get and set settings in the CCB. This makes it easy to use this feature, e.g. to enable silent: cbfstool coreboot.rom ccb-set -n serial -V silent Why not use a separate CBFS file? - Boards typically read the entire bootblock and start execution from it. The console is started early so the settings are needed before CBFS is available. By putting the CCB inside the bootblock, it can control things from an early stage. Why not CMOS RAM / VVRAM? - If we allocate some space in CMOS for console / logging settings, then it would allow a similar feature. But it involves changing settings on the device. Each board would need to provide some CMOS options for this feature as part of the layout file. It would not be possible to enable console output without running some code on the device to update the CMOS RAM. Why not use Firmware Handoff to pass the CCB to following stages? - We could do that, particularly if CCB attracts some additional features, such as logging. Regards, Simon

3 5

google/brya/var/crota: selfboot jump reached after 1.2 s
by Paul Menzel 28 Sep '23

28 Sep '23

Dear Google Chromebook folks, I got a Dell Latitude 5340 Chromebook with coreboot-v1.9308_26_0.0.22-26491-g38c6637296 With hot MRC cache, ChromeOS login screen is reached after around six seconds, which is great. According to the firmware time stamps in `chrome://system`, coreboot takes 1.2 until starting depthcharge: 82 entries total: 990:CSME ROM started execution 0 944:CSE sent 'Boot Stall Done' to PMC 119,000 945:CSE started to handle ICC configuration 119,000 (0) 946:CSE sent 'Host BIOS Prep Done' to PMC 123,000 (4,000) 947:CSE received 'CPU Reset Done Ack sent' from PMC 307,000 (184,000) 0:1st timestamp 342,717 (35,717) So the Converged Security Engine alone takes 342 ms – as long as coreboot takes to execute on older systems. 11:start of bootblock 352,538 (9,821) 12:end of bootblock 358,690 (6,151) 501:starting to load verstage 358,693 (3) 502:finished loading verstage 359,785 (1,092) 5:start of verified boot 361,037 (1,252) 503:starting to initialize TPM 361,739 (701) 504:finished TPM initialization 450,095 (88,356) 88 ms is high, but I think common for TPM initialization. 505:starting to verify keyblock/preamble (RSA) 471,441 (21,345) 506:finished verifying keyblock/preamble (RSA) 476,234 (4,793) 507:starting to verify body (load+SHA2+RSA) 476,256 (22) 508:finished loading body 679,079 (202,822) Another 200 ms is spent here. 509:finished calculating body hash (SHA2) 686,553 (7,473) 510:finished verifying body signature (RSA) 688,054 (1,501) 511:starting TPM PCR extend 690,511 (2,456) 512:finished TPM PCR extend 719,107 (28,596) 513:starting locking TPM 719,107 (0) 514:finished locking TPM 733,290 (14,183) 6:end of verified boot 747,454 (14,163) 13:starting to load romstage 747,563 (108) 14:finished loading romstage 747,575 (12) 1:start of romstage 747,587 (12) 515:starting EC software sync 747,596 (8) 516:EC vboot hash ready 749,955 (2,359) 517:waiting for EC to allow higher power draw 753,883 (3,928) 518:finished EC software sync 755,385 (1,501) 948:starting CSE firmware sync 756,428 (1,043) 949:finished CSE firmware sync 759,141 (2,712) 970:loading FSP-M 760,597 (1,456) 2:before RAM initialization 760,603 (5) 950:calling FspMemoryInit 785,801 (25,198) 951:returning from FspMemoryInit 825,967 (40,165) 550:starting to load ChromeOS VPD 826,013 (45) 551:finished loading ChromeOS VPD (RO) 826,099 (86) 552:finished loading ChromeOS VPD (RW) 826,132 (32) 3:after RAM initialization 826,196 (64) 4:end of romstage 827,576 (1,379) 100:start of postcar 836,651 (9,074) 101:end of postcar 836,651 (0) 8:starting to load ramstage 836,655 (3) 15:starting LZMA decompress (ignore for x86) 836,701 (46) 16:finished LZMA decompress (ignore for x86) 866,740 (30,039) 9:finished loading ramstage 866,880 (139) 10:start of ramstage 866,929 (48) 17:starting LZ4 decompress (ignore for x86) 867,936 (1,006) 18:finished LZ4 decompress (ignore for x86) 907,401 (39,465) 30:device enumeration 913,217 (5,816) 971:loading FSP-S 923,807 (10,589) 954:calling FspSiliconInit 934,237 (10,430) 955:returning from FspSiliconInit 968,817 (34,579) 962:calling FspMultiPhaseSiInit 968,822 (5) 963:returning from FspMultiPhaseSiInit 1,146,574 (177,751) 177 ms are spent here in the FSP blob? 942:before sending EOP to ME 1,146,823 (248) 40:device configuration 1,149,840 (3,016) 50:device enable 1,162,440 (12,600) 60:device initialization 1,167,018 (4,578) 114:started elog init 1,168,482 (1,464) 115:finished elog init 1,170,862 (2,379) 15:starting LZMA decompress (ignore for x86) 1,174,928 (4,065) 16:finished LZMA decompress (ignore for x86) 1,175,208 (280) 70:device setup done 1,186,831 (11,622) 75:cbmem post 1,187,518 (686) 80:write tables 1,187,593 (75) 85:finalize chips 1,195,483 (7,889) 553:started TPM enable update 1,204,169 (8,685) 554:finished TPM enable update 1,223,291 (19,122) 90:starting to load payload 1,223,317 (26) 15:starting LZMA decompress (ignore for x86) 1,223,459 (141) 16:finished LZMA decompress (ignore for x86) 1,236,494 (13,035) 943:after sending EOP to ME 1,240,485 (3,990) 99:selfboot jump 1,240,607 (122) 1000:depthcharge start 1,248,752 (8,144) 1002:RO vboot init 1,249,204 (452) 1020:vboot select&load kernel 1,249,228 (23) 1040:finished storage device initialization 1,282,580 (33,352) 1050:finished reading kernel from disk 1,288,042 (5,461) 1100:finished vboot kernel verification 1,295,930 (7,887) 1101:jumping to kernel 1,314,111 (18,180) Total Time: 1,314,072 I thought ChromeOS requirement is to reach `selfboot jump` below (still quite high) one second. Or is the actually met by not counting from power-on but from 1st timestamp? Does somebody know, why the CSE takes so long? Is Intel aware of that and going to improve that? I think there was something similar in the past, where Duncan Laurie(?), experienced, that coreboot was faster than the ME initialization, and had to wait for the Intel ME to send the ready signal. I think Intel improved on that later on? Kind regards, Paul

2 1

CML v1 / v2 FSP
by Jonathon Hall 27 Sep '23

27 Sep '23

Hi all, As many of you probably know, Comet Lake v1/v2 have different FSP binaries, and hence separate Kconfigs `SOC_INTEL_COMETLAKE_1` and `..._2`. In short, the same SKU could be either depending on the stepping. We're getting new steppings in future batches of products, which will move them from CML v1 to CML v2. These aren't otherwise "new versions" of the product. It would simplify life for my customers if they had the same firmware image. From an initial look it seems reasonable to embed both FSPs and select at runtime using the CPUID as suggested by Intel: * The headers for both FSPs are equivalent (differ only in comments), so there should be no issue switching at runtime * The _1 / _2 Kconfigs are only used to select FSP headers/binary, nothing else * It'll cost some flash space, so separate _1 / _2 should continue to exist, but in my case that tradeoff is fine Has anyone looked into this in the past? Is there any other reason this is not a good idea? From my initial look, I would try: * Add another Comet Lake Kconfig, say `SOC_INTEL_COMETLAKE_1_2` (or `..._1_AND_2`, etc.) * Embed a second FSP - probably add an optional `FSP_FD_PATH_2` to the FSP 2.0 Kconfig, the `..._1_2` SoC Kconfig would then put its second FSP here * Add a second `FSP_M_CBFS`/`FSP_S_CBFS` (the names of the files in cbfs) * For `SOC_INTEL_COMETLAKE_1_2`, select the correct cbfs name based on CPUID. Those are only used in a few places, so the impact wouldn't be very large. Thanks, Jonathon

2 2

[coreboot - Bug #509] (New) SD Card hotplug not working on Apollo Lake
by CoolStar Organization 27 Sep '23

27 Sep '23

Issue #509 has been reported by CoolStar Organization. ---------------------------------------- Bug #509: SD Card hotplug not working on Apollo Lake https://ticket.coreboot.org/issues/509 * Author: CoolStar Organization * Status: New * Priority: Normal * Category: chipset configuration * Target version: master * Start date: 2023-09-27 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Needs backport to: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: Apollo Lake * Affected OS: Linux, Windows 10, Windows 11 ---------------------------------------- Something is broken with the SD Card enumeration on Apollo Lake where hotplug is broken in both Linux and Windows -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

2 1

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 27 Sep '23

27 Sep '23

Issue #121 has been updated by Anastasios Koutian. Patrick Rudolph wrote in #note-75: > I compared the vendor ACPI code for T520 and T530: > - The T520 is missing _CST entries, thus the C-states are reported in FADT. I couldn't find a firmware dump that has a FADT. > - The T530 has _CST, but the latencies are higher: For C3 148usec, vs 63 in coreboot. > It's possible that too short advertised exit latencies causes issues when meeting deadlines within the kernel. > The kernel will pick deeper C-states, while it shouldn't, as it assumes that those wake much faster. Hi Patrick, I have done some digging with MSRs but never looked into this particular one. I have a spare T420 motherboard now and I could flash the vendor firmware back in, to examine the value. If that would contribute to solving this issue, I'd be happy to do it. Thank you for looking into this. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1667 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 24 Sep '23

24 Sep '23

Issue #121 has been updated by Patrick Rudolph. I compared the vendor ACPI code for T520 and T530: - The T520 is missing _CST entries, thus the C-states are reported in FADT. I couldn't find a firmware dump that has a FADT. - The T530 has _CST, but the latencies are higher: For C3 148usec, vs 63 in coreboot. It's possible that too short advertised exit latencies causes issues when meeting deadlines within the kernel. The kernel will pick deeper C-states, while it shouldn't, as it assumes that those wake much faster. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1666 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 24 Sep '23

24 Sep '23

Issue #121 has been updated by Patrick Rudolph. Does limiting the max C-state in MSR MSR_PKG_CST_CONFIG_CONTROL also work around the issue? What setting is being used on vendor firmware for MSR MSR_PKG_CST_CONFIG_CONTROL? Currently the code doesn't check if the processor supports C6/C3 sleep states, it just assumes it does. According to the BWG, when bus masters, that cannot tolerate long bus master latency, are present, the BM_STS avoidance must be used for C3/C6 states. It sounds a bit like this could be the case here. The CPU is in C3/C6 and takes too long to wake in order to handle the bus master request. If enabled the acpi_idle_bm_check() would then prevent the CPU from entering a higher C-state (deeper sleep) when a bus master is active (similar to what intel_idle.max_cstate=2 does). ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1665 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 24 Sep '23

24 Sep '23

Issue #121 has been updated by Anastasios Koutian. File defconfig added The issue is resolved for me after doing the following: a) Change motherboards from FRU 04W2049 (dGPU + iGPU) to FRU 04W2045 (iGPU). b) Update coreboot to 4.21 with EDK II (defconfig is attached). System has been stable for 6+ hours with no c-state limit. Previously it would freeze after 1-3 hours. Everything else is the same as my previous post. I recommend anyone still facing this issue to try the above. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1664 * Author: Julz Buckton * Status: New * Priority: Normal * Start date: 2017-06-09 ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2023