coreboot April 2025

coreboot@coreboot.org

13 participants
29 discussions

[coreboot - Support #594] (New) "[EMERG] FspMemoryInit error, status=0x80000007" on Dell Optiplex 5040 SFF (0T7D40) using optiplex_3050 port code
by Walter Sonius 17 May '25

17 May '25

Issue #594 has been reported by Walter Sonius. ---------------------------------------- Support #594: "[EMERG] FspMemoryInit error, status=0x80000007" on Dell Optiplex 5040 SFF (0T7D40) using optiplex_3050 port code https://ticket.coreboot.org/issues/594 * Author: Walter Sonius * Status: New * Priority: Normal * Target version: none * Start date: 2025-04-28 * Affected versions: 25.03 * Affected hardware: Dell Optiplex 5040 SFF ---------------------------------------- To further test the "deguard", just tried to flash this unsupported `optiplex_3050` code on the Dell Optiplex 5040 SFF and results in this error. **[EMERG] FspMemoryInit error, status=0x80000007** The Dell Optiplex 3050 micro shares the same OEM BIOS file as the Optiplex 3050 SFF. Since the later board looks very similar tot the Optiplex 5040 SFF except for these obvious differences: 2 DDR4 (DDR4-sodimm on the micro) slots vs 4 DDR3L slots 1 PCIe 1x length (closed) vs 4x length (open) black slots 2 SATA (black missing) vs 3 SATA connectors 2 USB3 vs 4 USB3 back ports 1 DisplayPort vs 2 DisplayPorts 0 serial vs 1 serial port 0 VGA vs 1 VGA(using motherboard header) 0 PS2 vs 2 PS2 ports B250 chipset vs Q170 chipset I took the gamble and flashed the 3050 micro port, just by adding the "Flash descriptor", "ME" and "Igbe" regions of the working [Optiplex 5040 SFF deguarded ROM](https://ticket.coreboot.org/issues/588) and only inserting pci 1f6 and peg0 to the devicetree.cb all other code is untouched. ``` ... device domain 0 on + device ref peg0 on + register "Peg0MaxLinkWidth" = "Peg0_x16" + + # Configure PCIe clockgen in PCH + register "PcieRpClkReqSupport[0]" = "1" + register "PcieRpClkReqNumber[0]" = "0" + register "PcieRpClkSrcNumber[0]" = "0" + end device ref igpu on register "PrimaryDisplay" = "Display_iGFX" end ... ... device ref hda on end device ref smbus on end + device pci 1f.6 on end # GbE <--- Extra port which contains I219-V but disabled also works on Asrock H110 Pro BTC+ end ... ``` The boards serial output works and it detects RAM only in 2 of 4 slots that resemble the 3050 SFF. Also correct sizes 2GB, 4GB, 8GB and variants including DDR3 vs DDR3L gets correctly detected. Different CPU's will also run Skylake i3-6100T, Kabylake G3950 and Coffeelake G4900T. ``` [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32. [DEBUG] CPU: Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz [DEBUG] CPU: ID 506e3, Skylake H R0, ucode: 000000ef [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 190f (rev 07) is Skylake-S (2 Core) [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 1912 (rev 06) is Skylake DT GT2 [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route frr [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 87 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32. [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0900 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0050200 00003008 [DEBUG] GBLRST_CAUSE: 00000002 00000000 [DEBUG] prev_sleep_state 0 (S0) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [DEBUG] SPD @ 0x50 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [DEBUG] SPD @ 0x52 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [EMERG] FspMemoryInit error, status=0x80000007 ``` Kabylake just with one Dimm inserted: ``` [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 bootblock starting (log level: 7)... [DEBUG] CPU: Intel(R) Celeron(R) CPU G3950 @ 3.00GHz [DEBUG] CPU: ID 906e9, Kabylake H B0, ucode: 000000f7 [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 590f (rev 06) is Kabylake-S [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 5902 (rev 04) is Kaby Lake DT GT1F [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route from MISCCFG register [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 88 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 romstage starting (log level: 7)... [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0800 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0040200 0000700a [DEBUG] GBLRST_CAUSE: 00000000 00000000 [DEBUG] prev_sleep_state 5 (S5) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [INFO ] No memory dimm at address A4 [DEBUG] SPD @ 0x50 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [EMERG] FspMemoryInit error, status=0x80000007 ``` Coffeelake with just 1 Dimm inserted: ``` [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 bootblock starting (log level: 7)... [DEBUG] CPU: Intel(R) Celeron(R) G4900T CPU @ 2.90GHz [DEBUG] CPU: ID 906eb, Unknown, ucode: 000000f5 [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 3e0f (rev 08) is Unknown [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 3e93 (rev 00) is Unknown [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route from MISCCFG register [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 86 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 romstage starting (log level: 7)... [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0800 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0040200 0000700a [DEBUG] GBLRST_CAUSE: 00000000 00000000 [DEBUG] prev_sleep_state 5 (S5) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [INFO ] No memory dimm at address A4 [DEBUG] SPD @ 0x50 [INFO ] SPD: module type is DDR3 [INFO ] SPD: module part number is HMT41GU6MFR8C-PB [INFO ] SPD: banks 8, ranks 2, rows 16, columns 10, density 4096 Mb [INFO ] SPD: device width 8 bits, bus width 64 bits [INFO ] SPD: module size is 8192 MB (per channel) [EMERG] FspMemoryInit error, status=0x80000007 No Dimms at all inserted or other 2 unsupported banks used [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 bootblock starting (log level: 7)... [DEBUG] CPU: Intel(R) Celeron(R) G4900T CPU @ 2.90GHz [DEBUG] CPU: ID 906eb, Unknown, ucode: 000000f5 [DEBUG] CPU: AES supported, TXT NOT supported, VT supported [DEBUG] MCH: device id 3e0f (rev 08) is Unknown [DEBUG] PCH: device id a146 (rev 31) is Q170 [DEBUG] IGD: device id 3e93 (rev 00) is Unknown [WARN ] PMC: Duplicate GPE DW register values detected; using default GPE route from MISCCFG register [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x750000. [DEBUG] FMAP: base = 0x0 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: mcache @0xfef04e00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xd0f0 in mcache @0xfef04e8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 86 ms [NOTE ] coreboot-25.03-324-geffd1ffdad73-dirty Mon Apr 28 05:44:45 UTC 2025 x86_32 romstage starting (log level: 7)... [WARN ] HECI: CSE device 16.0 is disabled [DEBUG] pm1_sts: 0800 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: d0040200 0000700a [DEBUG] GBLRST_CAUSE: 00000000 00000000 [DEBUG] prev_sleep_state 5 (S5) [DEBUG] FMAP: area COREBOOT found @ 750200 (9108992 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcddc0 size 0x63000 in mcache @0xfef0503c [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [NOTE ] MRC: no data in 'RW_MRC_CACHE' [INFO ] No memory dimm at address A0 [INFO ] No memory dimm at address A4 [EMERG] FspMemoryInit error, status=0x80000007 ``` Will upload autoport logs soon, anyone already some obvious edits/hints to the existing [optiplex_3050 code](https://github.com/coreboot/coreboot/tree/main/src/mainboard/dell/opt… get me past this [EMERG] FspMemoryInit error, status=0x80000007 error? -- 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

3 11

[coreboot - Bug #548] (New) Computer Fails To Recognize Upgraded WiFi Card
by Jeremy Brown 17 May '25

17 May '25

Issue #548 has been reported by Jeremy Brown. ---------------------------------------- Bug #548: Computer Fails To Recognize Upgraded WiFi Card https://ticket.coreboot.org/issues/548 * Author: Jeremy Brown * Status: New * Priority: Normal * Target version: none * Start date: 2024-07-15 ---------------------------------------- I am running coreboot 24.05 on my Lenovo X201. I decided to upgrade my WiFi card from an Intel Centrino Advanced-N 6205 to an Intel Wireless-AC 7260; since I selected the option to support Intel PCIe cards in my build config I expected everything to work but my computer fails to recognize the new card. The old card is still recognized if I reinstall it so I know I didn't mess up the socket somehow; I've read reports of the 7260 [working with a modded factory BIOS](https://richbits.rbarnes.org/installing-the-intel-7260-in-the-thinkpa… so I don't think there's an electrical issue. I've attached lspci data from both chips, lmk if additional information is needed. ---Files-------------------------------- 6205_lspci_tree.txt (1.63 KB) 7260_lspci_tree.txt (1.57 KB) 6205_lspci.txt (12.8 KB) 7260_lspci.txt (12.2 KB) -- 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

6 11

[coreboot - Bug #552] (New) X201 not booting with edk2 payload
by Maya Matuszczyk 17 May '25

17 May '25

Issue #552 has been reported by Maya Matuszczyk. ---------------------------------------- Bug #552: X201 not booting with edk2 payload https://ticket.coreboot.org/issues/552 * Author: Maya Matuszczyk * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2024-08-18 * Affected hardware: x201 ---------------------------------------- Hello, I tried to update my x201 with a new version of coreboot(I lost the working one). After building(using default config + set to x201 + bigger cbfs + linear high-res framebuffer) with latest release I couldn't get anything with edk2 to boot on it. I've tried changing `RESOURCE_ALLOCATION_TOP_DOWN` and using newer/older tags of MrChromebox's edk2 fork. -- 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 2

[coreboot - Support #588] (New) Deguard AssertionError using ./generatedelta.py on Dell Optiplex 5040 SFF (0T7D40) full rom dump
by Walter Sonius 04 May '25

04 May '25

Issue #588 has been reported by Walter Sonius. ---------------------------------------- Support #588: Deguard AssertionError using ./generatedelta.py on Dell Optiplex 5040 SFF (0T7D40) full rom dump https://ticket.coreboot.org/issues/588 * Author: Walter Sonius * Status: New * Priority: Normal * Category: userspace utilities * Target version: none * Start date: 2025-03-31 ---------------------------------------- Running the deguard `./generatedelta.py` on the flashrom dumped rom from a Dell Optiplex 5040 SFF (0T7D40 A00, Q170 chipset, ME 11.8.92.4222) 1.22 BIOS results in the following AssertionError: ``` ./generatedelta.py --input dell_optiplex_5040_sff_bios122.rom --output data/delta/dell5040sff Traceback (most recent call last): File "/home/neon/deguard/./generatedelta.py", line 55, in <module> mfs = MFS(me.entry_data("MFS")) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/neon/deguard/lib/mfs.py", line 43, in __init__ page = MFSPage(self.data[page * self.PAGE_SIZE:(page + 1) * self.PAGE_SIZE], page) # Load page ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/neon/deguard/lib/mfs.py", line 164, in __init__ self.chunks[chunk] = MFSChunk(data, chunk_id) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/neon/deguard/lib/mfs.py", line 273, in __init__ assert self.crc == MFS.Crc16(self.data + struct.pack("<H", self.chunk_id)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError ``` This "AssertionError" can be skipped by using "Filip Lewiński" [filipleple patch](https://codeberg.org/libreboot/deguard/issues/1) on `lib/mfs.py`: ``` - assert self.crc == MFS.Crc16(self.data + struct.pack("<H", self.chunk_id)) + print(f"Chunk ID: {self.chunk_id}, Data: {self.data.hex()[:100]}, Expected CRC: {self.crc}, Calculated CRC: {MFS.Crc16(self.data + struct.pack('<H', self.chunk_id))}") + # assert self.crc == MFS.Crc16(self.data + struct.pack("<H", self.chunk_id)) + if (self.crc != MFS.Crc16(self.data + struct.pack("<H", self.chunk_id))): + print ("Invalid CRC!!!\n") ``` It now lists the following 52 CRC invalid errors, but will create a delta folder structure like the example optiplex 3050 although it misses the `ptt` folder and some other files differ: ``` ./generatedelta.py --input dell_optiplex_5040_sff_bios122.rom --output data/delta/dell5040sff | grep "CRC: 0," Chunk ID: 9662, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 40051 Chunk ID: 9668, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 31713 Chunk ID: 9669, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 18640 Chunk ID: 8173, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 20614 Chunk ID: 8174, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 1493 Chunk ID: 8175, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 14052 Chunk ID: 8176, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 9641 Chunk ID: 8177, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 5784 Chunk ID: 8178, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 17355 Chunk ID: 8179, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 28922 Chunk ID: 8180, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 59757 Chunk ID: 8181, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 55900 Chunk ID: 8182, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 36623 Chunk ID: 8183, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 48190 Chunk ID: 8184, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 44032 Chunk ID: 8185, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 40753 Chunk ID: 8186, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 51810 Chunk ID: 8187, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 63827 Chunk ID: 8188, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 24772 Chunk ID: 8189, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 21493 Chunk ID: 8190, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 1702 Chunk ID: 8191, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 13719 Chunk ID: 8192, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 61908 Chunk ID: 8193, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 49893 Chunk ID: 8194, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 38838 Chunk ID: 8195, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 42119 Chunk ID: 8196, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 15632 Chunk ID: 8197, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 3617 Chunk ID: 8198, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 23410 Chunk ID: 8199, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 26691 Chunk ID: 8200, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 30845 Chunk ID: 8201, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 19276 Chunk ID: 8202, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 7711 Chunk ID: 8203, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 11566 Chunk ID: 8204, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 46265 Chunk ID: 8205, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 34696 Chunk ID: 8206, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 53979 Chunk ID: 8207, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 57834 Chunk ID: 8208, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 62119 Chunk ID: 8209, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 49558 Chunk ID: 8210, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 38085 Chunk ID: 8211, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 42996 Chunk ID: 8212, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 15971 Chunk ID: 8213, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 3410 Chunk ID: 8214, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 22529 Chunk ID: 8215, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 27440 Chunk ID: 8216, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 31502 Chunk ID: 10199, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 3459 Chunk ID: 6000, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 48953 Chunk ID: 6001, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 35848 Chunk ID: 6002, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 55643 Chunk ID: 6003, Data: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, Expected CRC: 0, Calculated CRC: 60010 ``` A tree view of the new delta folder: ``` data/delta/dell5040sff/ └── home ├── amt │ ├── rtfd │ │ ├── acl │ │ │ ├── tnf0 │ │ │ ├── tnf1 │ │ │ └── tnf2 │ │ ├── amt.wol │ │ ├── hshStr.crt19 │ │ ├── hshStr.crt23 │ │ ├── hshStr.crt24 │ │ ├── hshStr.crt25 │ │ └── hshStr.crt26 │ └── skip_rtfd │ └── uim.policy ├── bup │ ├── bup_sku │ │ ├── emu_fuse_map │ │ ├── fuse_ip_base │ │ └── plat_n_sku │ ├── invokemebx │ └── mbp ├── fwupdate │ ├── fwuavgerase │ ├── fwuavgwrite │ └── fwuoemid ├── gpio │ └── csme_pins ├── icc │ ├── dynregs │ ├── header │ ├── namestr │ ├── prof0 │ ├── prof1 │ ├── prof2 │ ├── prof3 │ ├── prof4 │ ├── prof5 │ └── prof6 ├── mca │ ├── eom │ └── ish_policy ├── mctp │ └── device_ports ├── pavp │ ├── hdcp_ports │ └── lspcon_port ├── policy │ ├── Bist │ │ └── auto_config │ ├── cfgmgr │ │ └── cfg_rules │ ├── hci │ │ ├── sysintid1 │ │ ├── sysintid2 │ │ └── sysintid3 │ └── pwdmgr │ └── segreto └── secureboot ├── bootpolres ├── bootpoltype ├── enfpolicy ├── kmid └── pubkeyhash ``` Diffing this compared to the example delta 3050 folder: ``` diff -bur optiplex_3050 optiplex_5040_sff_strip Binary files optiplex_3050/home/bup/bup_sku/emu_fuse_map and optiplex_5040_sff_strip/home/bup/bup_sku/emu_fuse_map differ Binary files optiplex_3050/home/bup/bup_sku/plat_n_sku and optiplex_5040_sff_strip/home/bup/bup_sku/plat_n_sku differ Only in optiplex_5040_sff_strip/home/bup: invokemebx Binary files optiplex_3050/home/bup/mbp and optiplex_5040_sff_strip/home/bup/mbp differ Binary files optiplex_3050/home/icc/dynregs and optiplex_5040_sff_strip/home/icc/dynregs differ Binary files optiplex_3050/home/icc/prof0 and optiplex_5040_sff_strip/home/icc/prof0 differ Only in optiplex_3050/home/icc: prof10 Only in optiplex_3050/home/icc: prof7 Only in optiplex_3050/home/icc: prof8 Only in optiplex_3050/home/icc: prof9 Only in optiplex_5040_sff_strip/home/policy: Bist Binary files optiplex_3050/home/policy/cfgmgr/cfg_rules and optiplex_5040_sff_strip/home/policy/cfgmgr/cfg_rules differ diff -bur optiplex_3050/home/policy/hci/sysintid1 optiplex_5040_sff_strip/home/policy/hci/sysintid1 --- optiplex_3050/home/policy/hci/sysintid1 2025-03-31 15:36:47.220784635 +0200 +++ optiplex_5040_sff_strip/home/policy/hci/sysintid1 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -�n$� \ No newline at end of file +_�� \ No newline at end of file diff -bur optiplex_3050/home/policy/hci/sysintid2 optiplex_5040_sff_strip/home/policy/hci/sysintid2 --- optiplex_3050/home/policy/hci/sysintid2 2025-03-31 15:36:47.220784635 +0200 +++ optiplex_5040_sff_strip/home/policy/hci/sysintid2 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -��t` \ No newline at end of file +�� \ No newline at end of file diff -bur optiplex_3050/home/policy/hci/sysintid3 optiplex_5040_sff_strip/home/policy/hci/sysintid3 --- optiplex_3050/home/policy/hci/sysintid3 2025-03-31 15:36:47.220784635 +0200 +++ optiplex_5040_sff_strip/home/policy/hci/sysintid3 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -Ȯ� \ No newline at end of file +�a< \ No newline at end of file diff -bur optiplex_3050/home/policy/pwdmgr/segreto optiplex_5040_sff_strip/home/policy/pwdmgr/segreto --- optiplex_3050/home/policy/pwdmgr/segreto 2025-03-31 15:36:47.221784637 +0200 +++ optiplex_5040_sff_strip/home/policy/pwdmgr/segreto 2025-03-31 16:01:29.335254012 +0200 @@ -1 +1 @@ -��к \ No newline at end of file +�"�H \ No newline at end of file ``` After deleting (strip) the `secureboot` and `amt,fwupd,pavp` folders it will generate a 2M consumer ME image when using `finalimage.py`. `./finalimage.py --delta data/delta/dell5040sff --version 11.6.0.1126 -pch H --sku 2M --fake-fpfs data/fpfs/zero --input external/asrock_h110_me_11.6.0.1126.bin --output 5040sff_patched_me.bin` When enabling the HAP bit on the original IFD and replacing the ME with the downgraded and deguarded ME should complete the manual. Is it correct to replace the current corporate ME firmware around ~7MB from the original image with this 2MB donor consumer variant, will it be similar like the Optiplex 3050 from the example or should I find a older vulnerable corporate ME firmware? Which file(s) of this dump may I distribute / upload to this ticket license wise to improve debugging? Using the service mode jumper on this Dell Optiplex 5040 SFF I was able to fully read and write the whole firmware even the ME regions (checksum checked it). Anyone else experience or success using a 'ch341a_spi' or 'raspberry spi' doing in-situ flash recover on this particular Dell or similar in case I need it? https://www.dell.com/support/product-details/en-uk/product/optiplex-5040-sf… -- 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 3

[coreboot - Bug #592] (New) Lenovo M920q can't use DIMM2 RAM slot
by Coreboot Enjoyer 02 May '25

02 May '25

Issue #592 has been reported by Coreboot Enjoyer. ---------------------------------------- Bug #592: Lenovo M920q can't use DIMM2 RAM slot https://ticket.coreboot.org/issues/592 * Author: Coreboot Enjoyer * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2025-04-15 * Affected versions: main * Related links: https://github.com/Thrilleratplay/coreboot-builder-scripts/issues/33 Also, it looks like a similar issue to https://ticket.coreboot.org/issues/462 * Affected hardware: Lenovo M920q ---------------------------------------- Building the current coreboot source, as well as commits 497298708c330deb479fbf3ee6a3acc8bff2a102, 640a41f3ee938b794b140218921e0fd63b1d9235 and 7945a31e9172ec2939cc1abc6036962a6efb601b, produces the firmware, that allows to initialize the motherboard if only DIMM1 RAM slot is filled. It fails to initialize, if DIMM1 RAM slot is empty and DIMM2 is filled, as well as if both DIMM1 and DIMM2 are filled. The issue is reproducible with different RAM sticks. I tried every possible combination with Kingston 32GB (2666MHz, CL 19-19-19-43) and Samsung 8GB (2400MHz, CL 17-17-17-39) -- the motherboard recognizes RAM sticks correctly, but still fails when the DIMM2 is filled with any RAM stick. I have also attached the build config file, which uses most of the default options. ---Files-------------------------------- m920q-dimm2-config.txt (27.6 KB) -- 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

3 2

[coreboot - Bug #415] (New) RESOURCE_ALLOCATION_TOP_DOWN breaks edk2
by Sean Rhodes 02 May '25

02 May '25

Issue #415 has been reported by Sean Rhodes. ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 https://ticket.coreboot.org/issues/415 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 KB) -- 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

3 6

[coreboot - Bug #579] (New) MAC address programmed by coreboot to onboard RTL8111F does not persist
by Keith Hui 02 May '25

02 May '25

Issue #579 has been reported by Keith Hui. ---------------------------------------- Bug #579: MAC address programmed by coreboot to onboard RTL8111F does not persist https://ticket.coreboot.org/issues/579 * Author: Keith Hui * Status: New * Priority: Normal * Category: chipset configuration * Target version: none * Start date: 2025-03-01 * Related links: https://review.coreboot.org/c/coreboot/+/86172 * Affected hardware: Asus P8Z77-V LE PLUS w/ RTL8111F * Affected OS: Linux kernel 6.12.7 ---------------------------------------- I am producing a coreboot port on Asus P8Z77-V LE PLUS on which this issue is observed. It has a RTL8111F ethernet controller without EEPROM for vital product data. I enabled the rtl8168 driver in coreboot so I can configure the LEDs and MAC address. Lights work great, but the MAC address always revert to `00:00:00:00:00:05` by the Linux r8169 kernel module. I would then have to reassign its proper MAC address using `ip link change eno0 address <mac>`. The device appears to be taking the address I programmed, but r8169 reverts it both on init and teardown, insisting that `00:00:00:00:00:05` is its permanent MAC address. Survival of coreboot programmed MAC address before r8169 driver is confirmed by a debug read back I inserted in the coreboot rtl81xx driver, as well as by temporarily blacklisting r8169. Vendor firmware is unaffected. -- 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

3 5

[RFC] Towards a more complete redundancy of firmware with vboot
by Michał Żygowski 30 Apr '25

30 Apr '25

Hello coreboot community, Google's vboot has been with us (coreboot) for many years already, probably mainly on Chromebook devices. In 3mdeb we have been using it with coreboot for a couple years as well. From a user and developer point of view, vboot is a great library that hardens the firmware with cryptographic verification of the executable code and provides a redundant A/B + recovery layout scheme. However, it comes with a couple of limitations we have observed throughout the years: 1. Sometimes when the coreboot-based firmware is updated on a device after a longer period of time, the vboot submodule revisions get updated too. Occasionally it may lead to backwards incompatibility between recovery and A/B parts (assuming that only A/B is updated and recovery remain write protected) . 2. Sometimes when the coreboot-based firmware is updated on a device after a longer period of time, the car.ld (or any program layout shared across multiple stages in both recovery and A/B like bootblock and romstage/postcar) gets updated too. Almost every time it leads to backwards incompatibility and a brick. There may be other cases as well, which need special handling and testing, because it may not be safe to flash an update on a device. One solution may be to freeze the codebase on given revisions and avoid updating them, but that's not what we typically want. I came up with the following idea: Leverage the top-swap mechanism to provide two bootblocks with verstages (assuming verstage starts in bootblock and no separate verstage): - Top Swap RO - used for booting recovery only (built with vboot submodule from coreboot revision X) - Top Swap RW - used for booting RW A/B only (built with vboot submodule from coreboot revision Y) Example (simplified) flashmap layout could look like this: RW_B (optional RW_A WP_RO { FMAP GBB COREBOOT TOP_SWAP_RO } TOP_SWAP_RW - TOP_SWAP_RW would be the default one placed right under top of 4G. - Whenever vb2api_fail is called, coreboot would have to switch the top swap to TOP_SWAP_RO. - TOP_SWAP_RW is updatable so should be unlocked, like RW_A/B. But verstage should be protected coreboot has some code/logic for building an image with top swaps, so I think it is doable. Unsolved problems or questions: 1. Having two distinct vboot builds does not prevent from backwards incompatibility in vboot NV storage layout. Does the layout of vbnv even change? For the past 10 years the offsets have not changed (only one new flag and one flag name modification). So we can assume it is not a problem. 2. There might be other incompatibilities I am unaware of. Different recovery reasons codes shouldn't be a problem generally. 3. Chromebooks usually write-protect WP_RO region. In the scheme above, the TOP_SWAP_RW would be unprotected. Do Chromebooks still use WP screws and SPI chip provided protections? - In 3mdeb we use the chipset PRx registers to protect the recovery part of the firmware. It gives a possibility of 4K granular protection of the SPI firmware. Multiple PRx registers could be used here: 1 - protect WP_RO, 2 - protect TOP_SWAP_RW. On updates lift the protection on second PR only - Ideally the top swaps could be protected/verified by solutions like Boot Guard (AFAIK boot Guard can support top swap, haven't researched yet how it works in practice). Then write protection of TOP_SWAP_RW would not be a concern. 4. Changes in the flashmap layout. This is rather out of scope, as any change in flashmap layout would imply updating whole BIOS region typically. So I would exclude this for now. The solution is Intel-only, not aware of top-swaps on AMD, except PSP/ASP 16MB flash page limitations and top-swap like behavior. Also AMD is a whole different story, because bootblock is integrated into PSP/ASP directory, which has its own A/B (and two level) mechanism + psp_verstage... So leaving that aside for now. Looking for your insights, comments, suggestions, any problems you see with the approach (haven't started any development yet) etc. Appreciated in advance. Best regards, -- Michał Żygowski Firmware Engineer GPG: 6B5BA214D21FCEB2 https://3mdeb.com | @3mdeb_com

3 3

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 28 Apr '25

28 Apr '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, April 30, 2025. [1] Kindly take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. ## Current Agenda Items ### [MartinR/Nicholas Chin] Look at adding doxygen back to coreboot * (https://review.coreboot.org/c/coreboot/+/8722) [RFC][POC] Tree: Add doxygen config files and targets * coreboot used to have targets to build Doxygen documentation, but they were removed in (https://review.coreboot.org/q/commit:619086d1056c) ("Treewide: Remove doxygen config files and targets") after it was decided that the doxygen documentation was dead. Recent discussion on a patch for doc.coreboot.org brought up the issue of how to keep API documentation up to date with the code, and there was some interest in being able to use the docstrings in the code to generate such information. Doxygen is one of the go-to tools for this sort of thing, but the previous attempt at using this required users to run a separate make target to view documentation, which may have contributed to its lack of use. Instead of using Doxygen to generate its own separate HTML output directly, there are tools such as Breathe [1], which can take the output of Doxygen and bridge it into Sphinx, which would allow API documentation to be seamlessly integrated into doc.coreboot.org and built automatically. To support this, re-add Doxygen configs and targets, but configure it for XML output, which is the format Breathe is able to parse. * The Gerrit discussion that prompted this idea: (https://review.coreboot.org/c/coreboot/+/87186/4..5/Documentation/lib/times…) * A proof of concept for how the whole Doxygen + Breathe thing works to pull in docstrings into our docs can be found in these patches: (https://review.coreboot.org/q/topic:%22autogen_api_docs%22) * There are also some alternatives which are all based around the idea of “API docs in code, then generate documentation from that.” The Sphinx syntax for pulling in a particular API’s documentation is also fairly similar between them. * With all of these types of documentation generators, you only need to add Doxygen/kerneldoc/etc style docstring comments for the APIs you intend to include in the documentation, and in the Documentation/*.md files you need to explicitly add a directive to pull in the docstrings for those items. This is in comparison to pure Doxygen documentation which runs and generates docs for the entire tree (it is possible to exclude certain subdirectories but in general it is designed to run on the the entire project) * [NicholasC] kerneldoc from Linux (basically their own Doxygen-like tool) * I did some brief experimentation with this and it also seems to work fairly well. It does seem lighter than Doxygen + Breathe and is much faster than my current proof of concept. I think this would also be easier to integrate into the doc.coreboot.org container as it doesn’t require a separate step to run like Doxygen. That was causing me a lot of issues in the container due to the tree being read-only and the output paths being different compared to running in the host OS. There might be some Linux-isms that we’d need to deal with though, whereas Doxygen is a bit more generic. * Proof of concept here: (https://review.coreboot.org/q/topic:%22docs-kernel-doc%22) (this does currently work in Docker, unlike my current Doxygen + Breathe proof of concept.) * Sphinx C Autodoc (https://sphinx-c-autodoc.readthedocs.io/en/latest/) * Relies on clang, and I found it difficult to figure out all the proper compiler flags to pass it to get it to work * Hawkmoth (https://jnikula.github.io/hawkmoth/stable/) * Also relies on clang; had the same issues as the above ### [MartinR] Leadership meeting for Asia times * (https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/UMGF…) ### [Martinr/Michał Żygowski] redundancy of firmware with vboot * (https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/IY6B…) [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Website #593] (New) [low] bugs.coreboot.org SSL certificate issue
by Orest Worhacz 27 Apr '25

27 Apr '25

Issue #593 has been reported by Orest Worhacz. ---------------------------------------- Website #593: [low] bugs.coreboot.org SSL certificate issue https://ticket.coreboot.org/issues/593 * Author: Orest Worhacz * Status: New * Priority: Low * Category: infrastructure * Target version: none * Start date: 2025-04-27 ---------------------------------------- bugs.coreboot.org is CNAME to ticket.coreboot.org but SSL certificate is only valid for ticket.coreboot.org As a workaround instead of using CNAME in DNS make 304 permamently mover redirect to ticket.coreboot.org or issue a correct certificate wirh alt names. Its low priority and pure cosmetical but still an issue because certificate error in browser doesnt look professional and may scare away potential users. -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2025