coreboot August 2022

coreboot@coreboot.org

32 participants
30 discussions

Compatibility with legacy boards
by Benoît Dufour 13 Aug '22

13 Aug '22

Hello, I saw one of my old board is listed compatible on the CoreBoot wiki : https://www.coreboot.org/Board:asus/p5gc-mx but knowing the wiki is "being retired". I don't know if it is still supported by the latest version of CoreBoot. Then the Status (as of commit 5bb27b7815) chart has broken colors. So it is hard to me to tell if everything is working fine or not. Then my board is the P5GC-MX/1333 and not the P5GC-MX. I could attempt to flash the Coreboot BIOS to it, but I would want to know if it could bring me some advantages other than "it is free software". For example, the original manufacturer BIOS doesn't supports booting from USB, does CoreBoot supports it?

3 2

Heads up: Allocator changes
by Nico Huber 10 Aug '22

10 Aug '22

Hi coreboot fellows, after two years with the new resource allocator it's time again for some changes[1]. Much less invasive than last time, but again there will be changes in the pattern where resources are placed. So once more this may uncover bugs in case fixed resources are not reserved properly. Reasons for the changes are somewhat the same as always: we haven't finished the support for 64-bit resources. Currently one has to opt in for a placement above 4G with a resource flag, and even this has its limitations. For instance, reserved space for hot-pluggable de- vices can be placed above 4G with a Kconfig setting, but there's no rule what should happen with the resources of cold-plugged devices. In the worst case, allocation for those can fail. Another reason are approaching changes to support multiple PCI host bridges and multiple resource windows per domain. I digress... So everybody is invited to test the patch train. There is a new Kconfig option RESOURCE_ALLOCATION_TOP_DOWN. The default y should work fine, though in case of regressions it would be nice to have it tested with both settings. Cheers, Nico [1] https://review.coreboot.org/q/topic:allocator+status:open

1 1

APOLLOLAKE FSP can find FIT signature
by roman perepelitsin 10 Aug '22

10 Aug '22

Trying to run coreboot on apollo lake atom CPU. I'm stopped at romstage - on call FspMemoryInit I get this message (from debug FSP): FitHeader signature was invalid. As I understood - this mean that FSP can't validate FIT header in memory: "_FIT_ ". I have no ideas what going wrong. I'm doing all by guidlines and recomendations - but have this problem. Also, what mean this coreboot out: CBFS: Unmatched 'filename' at 'offset' ? Thanks! -- regards, Perepelitsin Roman

1 0

ASUS P8ZZ7-V i7-3770 >16GB RAM: SPD CRC failed
by Nico Rikken 09 Aug '22

09 Aug '22

I'm in the process of building a new computer based on the P8ZZ7-V board with a i7-3770 CPU. I am running into a odd behavior the CPU_LED is blinking when using more than 2 8GB RAM modules. This occurs with both the vendor BIOS and the Coreboot build. A friend has the same configuration (mainboard, cpu, 4x8GB memory) which is working just fine. Which make me wonder why my setup is failing. We have gathered serial output (below) to diagnose the issue. Most notable is that for the failing memory configurations the '[DEBUG] Stored timings CRC16 mismatch.' message is returned, after which `[DEBUG] SPD probe channel0, slot1` is triggered, which seems to fail: `ERROR: SPD CRC failed!!!` The resulting looping sequence in the logs: <start of loop> [NOTE ] coreboot-4.17 Fri Jun 3 03:10:05 UTC 2022 bootblock starting (log level: 7)... [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x710000. [DEBUG] FMAP: base = 0xff800000 size = 0x800000 #areas = 4 [DEBUG] FMAP: area COREBOOT found @ 710200 (982528 bytes) [INFO ] CBFS: mcache @0xfeff0e00 built for 13 files, used 0x2dc of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x80 size 0x14c38 in mcache @0xfeff0e2c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 43 ms [NOTE ] coreboot-4.17 Fri Jun 3 03:10:05 UTC 2022 romstage starting (log level: 7)... [DEBUG] SMBus controller enabled [DEBUG] Setting up static northbridge registers... done [DEBUG] Initializing Graphics... [DEBUG] Back from systemagent_early_init() [INFO ] Intel ME early init [INFO ] Intel ME firmware is ready [DEBUG] ME: Requested 0MB UMA [DEBUG] Starting native Platform init [DEBUG] DMI: Running at X4 @ 5000MT/s [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [DEBUG] Stored timings CRC16 mismatch. [DEBUG] ECC supported: no ECC forced: no [INFO ] ECC RAM unsupported. [DEBUG] SPD probe channel0, slot0 [DEBUG] Revision : 11 [DEBUG] Type : b [DEBUG] Key : 2 [DEBUG] Banks : 8 [DEBUG] Capacity : 4 Gb [DEBUG] Supported voltages : 1.5V [DEBUG] SDRAM width : 8 [DEBUG] Bus extension : 0 bits [DEBUG] Bus width : 64 [DEBUG] FTB timings : yes [DEBUG] Optional features : DLL-Off_mode RZQ/7 RZQ/6 [DEBUG] Thermal features : PASR ext_temp_range [DEBUG] Thermal sensor : no [DEBUG] Standard SDRAM : yes [DEBUG] Rank1 Address bits : mirrored [DEBUG] DIMM Reference card: B [DEBUG] Manufacturer ID : 9e02 [DEBUG] Part number : CML16GX3M2A1600C [DEBUG] XMP Profile : 1 [DEBUG] Max DIMMs/channel : 1 [DEBUG] XMP Revision : 1.3 [DEBUG] Requested voltage : 1500 mV [DEBUG] XMP profile supports 1 DIMMs, but 2 DIMMs are installed. [WARN ] XMP maximum DIMMs will be ignored. [INFO ] Row addr bits : 16 [INFO ] Column addr bits : 10 [INFO ] Number of ranks : 2 [INFO ] DIMM Capacity : 8192 MB [INFO ] CAS latencies : 6 9 [INFO ] tCKmin : 1.250 ns [INFO ] tAAmin : 11.250 ns [INFO ] tWRmin : 15.000 ns [INFO ] tRCDmin : 11.250 ns [INFO ] tRRDmin : 7.500 ns [INFO ] tRPmin : 11.250 ns [INFO ] tRASmin : 30.000 ns [INFO ] tRCmin : 50.625 ns [INFO ] tRFCmin : 260.000 ns [INFO ] tWTRmin : 7.500 ns [INFO ] tRTPmin : 7.500 ns [INFO ] tFAWmin : 37.500 ns [INFO ] tCWLmin : 10.000 ns [INFO ] tCMDmin : 2 [DEBUG] channel[0] rankmap = 0x3 [DEBUG] SPD probe channel0, slot1 [DEBUG] ERROR: SPD CRC failed!!! [DEBUG] Revision : 11 [DEBUG] Type : b [DEBUG] Key : 2 [DEBUG] Banks : 8 [DEBUG] Capacity : 4 Gb [DEBUG] Supported voltages : 1.5V [DEBUG] SDRAM width : 8 [DEBUG] Bus extension : 0 bits [DEBUG] Bus width : 64 <end of loop, restarting Coreboot> Mainboard: ASUS P8ZZ7-V CPU: i7-3770 RAM 4x8GB DDR3 Corsair CML16GX3M2A1600C9 Does anybody have advise what could be causing the `SPD CRC failed!!!` error? The next idea is to replace the CPU as the memory seems fine to swap around in most configurations. Other ideas are the motherboard, or something interfering with the readout. Is there an easy way to perhaps hardcode my way out of it for now, knowing the RAM will remain there once configured so I could even doe a custom Coreboot build? Best, Nico

4 7

Reconsidering the Gerrit submission strategy
by Patrick Georgi 08 Aug '22

08 Aug '22

Hi everybody, I was recently made aware that Gerrit now supports adding metadata to commit messages in the "rebase" strategy. The "cherry-pick" strategy that we're using has been chosen over everything else primarily due to this capability. Some details: Gerrit supports different ways of committing changes into branches when developers submit them, with different effects on which changes are considered ready and how they show up in the commit history. The two main contenders are "cherry-pick" and "rebase always". Both create a linear history (unlike some "merge" strategies that can create merge commits. Both add metadata to the commits, all that "Reviewed-on", "Reviewed-by" etc in the commit message. Cherry-pick considers every change on Gerrit on its own. Even if you push a patch train of 50 commits, it allows submitting commit #49 individually. That gives some flexibility (if these commits are truly independent) but also creates risk: if changes are merged out of order, we might break the tree with otherwise perfectly good commits, for example when a new API is used that is only added by a previous commit. Rebase always considers patch trains: To submit commit #49, the commit itself and all its 48 ancestors need to be ready for submission. It becomes a one-click operation in the UI and ordering is honored. On the other hand, picking an individual commit is a manual operation now (cherry-pick to become its own patch train, push, re-review). Speaking of UI, depending on the strategy the "readiness" marker in the UI changes behavior, too: With "cherry-pick", each commit is compared against the branch individually, with a "merge conflict" notification if the commit on its own would fail to merge. With "rebase always" the entire patch train up to that point is considered. It's a matter of trade-offs, but given that "rebase always" can now add the metadata that was the deal breaker for anything but cherry-pick back in the day, I wanted to know how y'all feel about changing or keeping the submission strategy. David proposed that we could try out "rebase always" for a while (maybe a month) to see how it feels. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Liana Sebastian

6 19

search_isolinux usb
by Geert Stappers 08 Aug '22

08 Aug '22

Hello coreboot developers, Here a coreboot user who wishes to boot from an USB-memory-stick. That is in addition to regular boot from internal storage device. The computer I'm talking about is a Lenovo Thinkpad X230 which does have coreboot installed, it is what I have bought. Payload is grub. An .iso is fetched from Internet and `dd` to USB-memory-stick. The USB-thumbdrive is then inserted in the X230, on the left side, in the USB-slot closest to user[1]. Upon power-on is a grub menu shown[2]. Default menu entry has description "Load operating system", beneat is `search_grub ahci` and does indeed load and start Linux. (in ohter words: payload came alive) However the other boot menu entries[3] don't work. It is the reason why I'm seeking your advice. When I active menu entry 'Search ISOLINUX menu (USB)', which has grub command 'search_isolinux usb', screen goes shortly black and then the main grub menu re-appears. As if the coreboot payload grub wants to tell "nothing found". For the other boot menu entries I also get "nothing found". What to do to make coreboot grub accepting USB image? Groeten Geert Stappers [1] Other USB-slots have also been tried. Only with the "front-left-USB-slot" do I see a blinking activity LED of the USB-memory-stick. [2] Other power-up-messages might have been printed, but the quick appearance of the grub menu overwrites then. [3] "Poweroff" and "Reboot" are not **boot** menu entries. -- Silence is hard to parse

3 2

configure: error: qemu, coreboot and loongson ports need unifont
by Geert Stappers 07 Aug '22

07 Aug '22

Hello coreboot archive, After a succesfull build of the default payload, I tried to build the grub payload and got configure: error: qemu, coreboot and loongson ports need unifont make[1]: *** [Makefile:34: grub2/build/config.h] Error 1 make: *** [payloads/external/Makefile.inc:224: grub2] Error 2 In https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/IVK… is adviced to do sudo apt install -y autoconf automake gettext autopoint pkg-config grub-common libfreetype6-dev unifont but no report on how succesfull that was. Now I report: Yes, those extra packages on the host got me a succesfull of the grub payload. Groeten Geert Stappers -- Silence is hard to parse

1 0

Image size and cpu-flash addresses.
by Pedro Erencia 07 Aug '22

07 Aug '22

Hi everyone, I was going to try coreboot on an ASROCK FM2A88X Extreme4+ ( https://www.asrock.com/mb/AMD/FM2A88X%20Extreme4+/) with the configuration of the supported ASUS A88XM-E ( https://doc.coreboot.org/mainboard/asus/a88xm-e.html) which has the same chipset (A88X Bolton). The fact is that, at this moment, I only have a 16 MiB flash, while the image is 8 MiB. As the chipset claims that it “Supports a maximum SPI ROM size of 16MB” I think there should be no problem, but I wonder how I have to burn the image. That led me to the question of how the translation between CPU and flash addresses are done. For supporting various ROM sizes, I guess the controller should somehow know the size of the ROM, but I don't see anywhere where that could be specified. The only thing I found is this stack overflow question ( https://stackoverflow.com/questions/60200796/how-does-processor-read-bios-f…). There, flash descriptors and some straps are mentioned to provide the ROM size, but none of those methods are mentioned on the Bolton Datasheet. So I have two questions here, 1. How should I burn the 8 MiB image on the 16 MiB flash? 2. Out of curiosity, how is the cpu-flash address translation done?

3 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 05 Aug '22

05 Aug '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1490983: Control flow issues (DEADCODE) /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1210 in edp_ctrl_calc_tu() ________________________________________________________________________________________________________ *** CID 1490983: Control flow issues (DEADCODE) /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1210 in edp_ctrl_calc_tu() 1204 temp_fp = LCLK_FAST_SKEW_fp * tu->lwidth; 1205 temp = DIV_ROUND_UP(temp_fp, f); 1206 temp_fp = ((tu->bpp * f / 8) / (tu->nlanes * tu->original_ratio_fp)) * f * temp; 1207 temp = temp_fp / f; 1208 1209 if (async_en) >>> CID 1490983: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "tu->delay_start_link += (in...". 1210 tu->delay_start_link += (int)temp; 1211 tu->delay_start_time_fp = (tu->delay_start_link * f) / tu->lclk; 1212 1213 /* OUTPUTS */ 1214 tu_table->valid_boundary_link = tu->valid_boundary_link; 1215 tu_table->delay_start_link = tu->delay_start_link; ** CID 1490982: (RESOURCE_LEAK) /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() ________________________________________________________________________________________________________ *** CID 1490982: (RESOURCE_LEAK) /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() 1229 tu_table->valid_lower_boundary_link); 1230 printk(BIOS_INFO, "TU: upper_boundary_count: %d\n", 1231 tu_table->upper_boundary_count); 1232 printk(BIOS_INFO, "TU: lower_boundary_count: %d\n", 1233 tu_table->lower_boundary_count); 1234 printk(BIOS_INFO, "TU: tu_size_minus1: %d\n", tu_table->tu_size_minus1); >>> CID 1490982: (RESOURCE_LEAK) >>> Variable "tu" going out of scope leaks the storage it points to. 1235 } 1236 1237 static void edp_ctrl_config_TU(struct edp_ctrl *ctrl, struct edid *edid) 1238 { 1239 struct edp_ctrl_tu tu_config; 1240 /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() 1229 tu_table->valid_lower_boundary_link); 1230 printk(BIOS_INFO, "TU: upper_boundary_count: %d\n", 1231 tu_table->upper_boundary_count); 1232 printk(BIOS_INFO, "TU: lower_boundary_count: %d\n", 1233 tu_table->lower_boundary_count); 1234 printk(BIOS_INFO, "TU: tu_size_minus1: %d\n", tu_table->tu_size_minus1); >>> CID 1490982: (RESOURCE_LEAK) >>> Variable "tu" going out of scope leaks the storage it points to. 1235 } 1236 1237 static void edp_ctrl_config_TU(struct edp_ctrl *ctrl, struct edid *edid) 1238 { 1239 struct edp_ctrl_tu tu_config; 1240 /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() 1229 tu_table->valid_lower_boundary_link); 1230 printk(BIOS_INFO, "TU: upper_boundary_count: %d\n", 1231 tu_table->upper_boundary_count); 1232 printk(BIOS_INFO, "TU: lower_boundary_count: %d\n", 1233 tu_table->lower_boundary_count); 1234 printk(BIOS_INFO, "TU: tu_size_minus1: %d\n", tu_table->tu_size_minus1); >>> CID 1490982: (RESOURCE_LEAK) >>> Variable "tu" going out of scope leaks the storage it points to. 1235 } 1236 1237 static void edp_ctrl_config_TU(struct edp_ctrl *ctrl, struct edid *edid) 1238 { 1239 struct edp_ctrl_tu tu_config; 1240 /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 1235 in edp_ctrl_calc_tu() 1229 tu_table->valid_lower_boundary_link); 1230 printk(BIOS_INFO, "TU: upper_boundary_count: %d\n", 1231 tu_table->upper_boundary_count); 1232 printk(BIOS_INFO, "TU: lower_boundary_count: %d\n", 1233 tu_table->lower_boundary_count); 1234 printk(BIOS_INFO, "TU: tu_size_minus1: %d\n", tu_table->tu_size_minus1); >>> CID 1490982: (RESOURCE_LEAK) >>> Variable "tu" going out of scope leaks the storage it points to. 1235 } 1236 1237 static void edp_ctrl_config_TU(struct edp_ctrl *ctrl, struct edid *edid) 1238 { 1239 struct edp_ctrl_tu tu_config; 1240 ** CID 1490981: Integer handling issues (DIVIDE_BY_ZERO) /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 936 in edp_ctrl_pixel_clock_dividers() ________________________________________________________________________________________________________ *** CID 1490981: Integer handling issues (DIVIDE_BY_ZERO) /src/soc/qualcomm/sc7280/display/edp_ctrl.c: 936 in edp_ctrl_pixel_clock_dividers() 930 pixel_div = 2; 931 else if (rate == DP_LINK_BW_5_4) 932 pixel_div = 4; 933 else 934 printk(BIOS_ERR, "Invalid pixel mux divider\n"); 935 >>> CID 1490981: Integer handling issues (DIVIDE_BY_ZERO) >>> In expression "ctrl->link_rate_khz * 10U / pixel_div", division by expression "pixel_div" which may be zero has undefined behavior. 936 dispcc_input_rate = (ctrl->link_rate_khz * 10) / pixel_div; 937 938 rational_best_approximation(dispcc_input_rate, stream_rate_khz, 939 (unsigned long)(1 << 16) - 1, 940 (unsigned long)(1 << 16) - 1, &den, &num); 941 *pixel_m = num; ** CID 1490980: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1490980: (TAINTED_SCALAR) /3rdparty/vboot/firmware/2lib/2load_kernel.c: 629 in vb2api_load_kernel() 623 if (AllocAndReadGptData(disk_info->handle, &gpt)) { 624 VB2_DEBUG("Unable to read GPT data\n"); 625 goto gpt_done; 626 } 627 628 /* Initialize GPT library */ >>> CID 1490980: (TAINTED_SCALAR) >>> Passing tainted expression "*gpt.primary_header" to "GptInit", which uses it as a loop boundary. 629 if (GptInit(&gpt)) { 630 VB2_DEBUG("Error parsing GPT\n"); 631 goto gpt_done; 632 } 633 634 /* Loop over candidate kernel partitions */ /3rdparty/vboot/firmware/2lib/2load_kernel.c: 629 in vb2api_load_kernel() 623 if (AllocAndReadGptData(disk_info->handle, &gpt)) { 624 VB2_DEBUG("Unable to read GPT data\n"); 625 goto gpt_done; 626 } 627 628 /* Initialize GPT library */ >>> CID 1490980: (TAINTED_SCALAR) >>> Passing tainted expression "*gpt.secondary_header" to "GptInit", which uses it as a loop boundary. 629 if (GptInit(&gpt)) { 630 VB2_DEBUG("Error parsing GPT\n"); 631 goto gpt_done; 632 } 633 634 /* Loop over candidate kernel partitions */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Servers?
by Jeremy Hansen 03 Aug '22

03 Aug '22

I’ve looked at the list of hardware vendors. I see System76 listed but when I asked System76, they claim it’s not supported. “Support” I understand, but does it work? Maybe using their System76 firmware? Any other server vendors I should consider? I know Purism offers servers as well. Anyone else? Thank you -jeremy

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2022