- coreboot - mail.coreboot.org

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

30 Apr '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

2 4

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

29 Apr '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

2 6

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 - Support #588] (New) Deguard AssertionError using ./generatedelta.py on Dell Optiplex 5040 SFF (0T7D40) full rom dump
by Walter Sonius 28 Apr '25

28 Apr '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

1 2

[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

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

25 Apr '25

Dear coreboot Community, Kindly note that we have an upcoming leadership meeting scheduled for Wednesday, April 30, 2025. [1] Please take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Memory map and type 13 (Fwd: Re: e820: Undefined type not treated as AddressRangeReserved)
by Paul Menzel 23 Apr '25

23 Apr '25

Dear coreboot folks, Some payloads, like GRUB [1] and formerly FILO [2], convert coreboot’s memory map(?) to E820 table, and copy the type 13. Currently, the Linux kernel does not follow the ACPI specification to treat the undefined types as AddressRangeReserved, so `cbmem` does not work, which can be worked around with `iomem=relaxed`. I brought this up to the Linux x86 maintainers, and Ingo Molnar kindly responded [attached, 3], and asked: > Just curious: why do they mark it type 13? What semantics do they > expect? It's not just some random value I suspect. Could somebody of the experts here shed some light on this? Thank you and kind regards, Paul PS: Ingo also prepared some patches to make Linux follow the ACPI specification [4]. [1]: https://ticket.coreboot.org/issues/590 [2]: https://review.coreboot.org/c/filo/+/51120 [3]: https://lore.kernel.org/all/aADkQoJE62OdWMhu@gmail.com/ [4]: https://lore.kernel.org/all/20250421185210.3372306-1-mingo@kernel.org/

1 0

[coreboot - Support #581] (New) success new variant "compaq_pro_6300_sff" for hp/snb_ivb_desktops compatible with "compaq_8300_elite_sff" template
by Walter Sonius 23 Apr '25

23 Apr '25

Issue #581 has been reported by Walter Sonius. ---------------------------------------- Support #581: success new variant "compaq_pro_6300_sff" for hp/snb_ivb_desktops compatible with "compaq_8300_elite_sff" template https://ticket.coreboot.org/issues/581 * Author: Walter Sonius * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2025-03-15 ---------------------------------------- Successful flash and coreboot SeaBIOS functioning of a HP "compaq_pro_6300_sff" with a unchanged "compaq_8300_elite_sff" template using coreboot (24.12-758-g1e7ba810c6bb) and SeaBIOS (version rel-1.16.3-0-ga6ed6b70). These two HP Compaq devices are extremely similar, they use the same OEM proprietary BIOS upgrade files. Hardware wise the only 3 noticeable differences are that the "compaq_8300_elite_sff" comes with a Q77 chipset, SuperIO NPCD378 and J32 labeled 16x length "white" PCI-E slot versus a Q75 chipset, SuperIO NPCD379HAKFX with the J32 labeled slot populated with a limited physical 1x length "black" PCI-E slot on the "compaq_pro_6300_sff". Flashing from OEM proprietary BIOS 3.08revA enabling the FDO jumper on the motherboard as described for the compaq_8300_elite_sff works by booting with "iomem=relaxed" kernel parameter and specifying the specific 16MB chip 25Q128A: flashrom -p internal -w cbtest.rom -c "MT25QL128" Tested and Working: Poweron/Poweroff/Reboot CPU i3-3220 / e3-1225v2 RAM 1x 2x 4x populated slots total of 4GB/8GB/16GB/24GB (both 1.35v and 1.5v modules mixed with ECC) Serial port (including coreboot) PS2 keyboard (including SeaBIOS) PS2 mouse SATA 3 ports (blue/white/white) USB 2.0 4x front & 2x back ports USB 3.0 4x back ports Ethernet 1Gbit/100Mbit Display port works in SeaBIOS and OS VGA port only works in OS! PCI using realtek RTL8169 1Gb PCIE 3.0 16x using 2.0 8x 10Gb intel X540-AT2 / using 1.0 16x Nvidia Geforce 6200 LE (also works in SeaBIOS) PCIE 2.0 1x using 2.0 1x 2.5Gb realtek RTL8125 PCIE 2.0 1x using 1.0 1x 1Gb intel 82574L (SeaBIOS loads option rom) Audio built-in speaker (plays music in OS compared to legacy bleep pc-speaker) Audio front panel 3.5 mm headphone jack (auto disables built-in Speakers and selects Headphones) Audio front panel 3.5 mm headphone&mic jack (only microphone works with 4 pin 3.5mm combi mic/headphone) Audio back panel 3.5mm green jack (manually select Line Out and it works) Sensors CPU and 2 motherboard sensors SuperIO Booting USB / SATA(HDD/DVD) OS: Fedora-mate Linux kernel 6.11.4 / 6.13.6, KDE neon Linux kernel 6.8.0-52 Flashrom: needs additional parameters compared to OEM BIOS both for read/write depending on flashrom version? flashrom -p internal:boardmismatch=force,ich_spi_mode=hwseq -w test.rom -c "Opague flash chip" Tested not Working: RAM ECC functioning (see coreboot log) SATA port black Wakeonlan, it just auto wakes from itself so cannot verify... iGPU multigpu with PCIE nvidia geforce 6200 le, only PCIE nvidia geforce works and iGPU gets disabled. What to do next to get this "compaq_pro_6300_sff" variant officially supported? *Supply more logs/info? *Fill a bug for the ECC not working or first get this variant supported as is? *Fill a bug that VGA doesn't work in SeaBIOS? *Fill a bug/ticket on the flashrom support list for the difference in parameters needed pre/post flash? https://support.hp.com/us-en/drivers/hp-compaq-pro-6300-small-form-factor-p… https://support.hp.com/in-en/drivers/hp-compaq-elite-8300-small-form-factor… Walter Sonius ---Files-------------------------------- cb-log-hp-compaq_pro_6300_sff.txt (51.8 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

4 34

[coreboot - Feature #583] (New) Allow reconfiguring PCIe slots on Asus P8Z77-V
by Keith Hui 22 Apr '25

22 Apr '25

Issue #583 has been reported by Keith Hui. ---------------------------------------- Feature #583: Allow reconfiguring PCIe slots on Asus P8Z77-V https://ticket.coreboot.org/issues/583 * Author: Keith Hui * Status: New * Priority: Normal * Assignee: Keith Hui * Category: board support * Target version: none * Start date: 2024-11-30 * Related links: https://review.coreboot.org/c/coreboot/+/85413 * Affected hardware: mb/asus/p8z77-v ---------------------------------------- Vendor firmware allows configuring the PCIe slots in three different ways, by reallocating 4 of the PCIe lanes between PCIEX16_3, PCIEX1_1, PCIEX1_2, and the onboard ASM1061 serial ATA controller providing 2 additional SATA ports. The options are (devices not shown are disabled): * X4: PCIEX16_3 as x4 * X1: PCIEX16_3 as x1, PCIEX1_1, PCIEX1_2 * Auto: PCIEX16_3 as x1, PCIEX1_1, ASM1061 The technical details have been worked out and implemented as patch CB:85413. However, two issues remain: 1. Despite our best efforts, PCIEX1_2 still doesn't work. 2. Configuring PCIEX16_3 for 4x requires changing a PCH soft strap from firmware, and coreboot lacks infrastructure for doing so. It has been established that the descriptor itself, which contains the soft straps, needs to be reflashed to make this change. This issue tracks our progress implementing this feature. -- 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 15

Toolchain tarballs missing
by Tim Crawford 22 Apr '25

22 Apr '25

It is currently not possible to build the coreboot toolchain due to NASM. The project website (https://nasm.us), which is used to download the source tarball, has been offline for days. While being hosted on GitHub for years now, the project does not use it for creating and distributing releases. coreboot does have mirrors of tarballs (https://www.coreboot.org/releases/crossgcc-sources/), but the version of NASM used is not present. - How are the tarballs uploaded to the coreboot mirror in the first place? - Can someone upload the missing tarball(s) to the mirror? -- Tim Crawford System76 Kernel Engineer tcrawford(a)system76.com

2 1

2025_04_23 coreboot Review Session
by mina＠coreboot.org 21 Apr '25

21 Apr '25

Hello coreboot, Pleased to announce that our upcoming group review session is scheduled for Wednesday, April 23. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Kindly add any specific patches you'd like the group to review to the top of the sheet. As an hour is not sufficient to address all patches on the list, reviewing patches in advance is greatly appreciated. Thank you. Best regards, Mina.

1 0

potential targets,
by zap 20 Apr '25

20 Apr '25

would it be possible to pay for a service to port x1 carbon gen 6 to coreboot? or thinkpad x280 or both? I am aware deguard can be used for this purpose, because of an intel me vulnerability. Is there a price someone would be willing to do this for? Would want boot guard disabled, plus intel me disabled + coreboot. Name the price if you anyone has interest

1 0

2025-04-16 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 17 Apr '25

17 Apr '25

# 2025-04-16 - coreboot Leadership Meeting ## Attendees Felix Singer, Werner Zeh, Julius Werner, Maximilian Brune, Jay Talbott, Alicja Michalska, Matt DeVellier, Mina Asante, Martin Roth, Felix Held, Jon Murphy, Marshall Dawson, Jeremy Compostella, Paul Menzel. ## Open Action Items * 2024-11-27 * [Open] Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * [Open] Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches.” * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian(?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long term project. ## Minutes ### [Martin] Here is a blog post of things we are putting in place to have better engagement with companies: (https://docs.google.com/document/d/1lFUm4A-8F6J0acVbFkE_N_OY6PQcEup0lLPXAe3…) * This collaboration gives room for companies or entities to enjoy the following benefits: * Private development repos * Public branches in the coreboot repo * ongoing or one-off meetings with companies * official company reps for the leadership meetings * blog posts from companies * FelixS: Why would someone need a private repo? * [Alicja] The current coreboot leadership meeting schedule is not favorable for participants in the Asian time zones, and there are companies here that are interested in coreboot. Is it possible to schedule the meeting in a way that makes it possible for everyone to attend? * [Martin] If there's interest in scheduling another meeting, I’m personally fine with it. However, I can’t guarantee that the leadership team will be able to attend. * [Werner] People are always welcome to update the agenda with their issues even if they cant make it to the meeting or reach out directly to any member of the leadership team at any time, and we will be happy to help. * [Felix H] We should put this on the mailing list to see if there’s a demand for a second leadership meeting. ### [Martin] This is a task from a while back to create a questionnaire poll about the concerns surrounding the use of AI tools in open source development [Possible AI poll questions](https://docs.google.com/document/d/1s__V82xvvojpSuI9fEVD3YwND5_H… * Could I get some review? # Next Leadership Meeting * April 30, 2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course, items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Leadership Meeting: Call for Interest from the Asian Region
by coreboot org 17 Apr '25

17 Apr '25

Hello all, We’d like to gauge interest in establishing a second coreboot leadership meeting scheduled at a time more accessible for contributors across Asia. As our community has grown globally, we recognize that our current meeting time may present challenges for many of our contributors in Asian time zones. While we've tried to be inclusive by encouraging people to submit agenda items via the mailing list or directly to the agenda regardless of attendance ability, we understand this is not the same as active participation in discussions. This topic was raised during the most recent leadership meeting, so we'd like to determine if there's sufficient interest to warrant a second regularly scheduled meeting. While all three members of the coreboot leadership team probably will not be able to attend this additional meeting, we see value in creating a dedicated forum to: - Hear perspectives from our Asian contributors - Discuss region-specific challenges and opportunities - Ensure diverse viewpoints are incorporated into project decisions - Build stronger connections with contributors across all regions If you're based in Asia or would benefit from an alternative meeting time, please respond to this post indicating: - Your interest in attending - Preferred time window - Early, overlapping more with the Americas - Late, overlapping more with Europe and Africa Feel free to respond on the mailing list or directly to the coreboot.org(a)gmail.com email if you don't feel comfortable posting to the mailing list. We'll assess the responses to determine if there's enough interest to move forward with this initiative. Thanks! Martin

1 0

Qotom Q20331G9-S10 (Intel Denverton C3758R) — Two Issues Remaining (VGA + Console Drop)
by Enzo Potenza 16 Apr '25

16 Apr '25

Dear all, I’ve been working on porting coreboot to the Qotom Q20331G9-S10, which uses the Intel Atom C3758R (Denverton). So far: System boots All onboard devices are detected properly Payload (EDK II) loads fine Issues: 1. VGA Not Working Pre-OS The board uses an AST2400 BMC for VGA output. I’ve added the VGA ROM (pulled from the official site) into the coreboot image, but no output is visible during pre-OS phase. (without the ROM, no VGA at all) 2. Console Stops After Payload The serial console works fine during the bootblock and into romstage/post. However, once coreboot hands off to the payload, the console garbles and stops showing valid output. Here’s the last clean output before it breaks: FSP End of Firmware ... Install PPI: BD44F629-EAE7-4198-87F1-39FAB0FD717E NotifyPhaseApi() - End [Status: 0x00000000] ▒`▒f▒▒▒f▒▒▒▒`▒f▒▒▒f▒▒▒▒`▒f▒▒▒f▒▒ If anyone has any ideas, I’d love to hear your inputs. Happy to share build configs or logs if that helps. Thanks! enzo

1 0

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

16 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

2 2

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

16 Apr '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

2 1

[coreboot - Bug #591] (New) Build error on lenovo/m920q due to removal of ##ROM_BASE##
by Oberon 4071 14 Apr '25

14 Apr '25

Issue #591 has been reported by Oberon 4071. ---------------------------------------- Bug #591: Build error on lenovo/m920q due to removal of ##ROM_BASE## https://ticket.coreboot.org/issues/591 * Author: Oberon 4071 * Status: New * Priority: Normal * Category: userspace utilities * Start date: 2025-04-11 * Affected hardware: lenovo/m920q ---------------------------------------- The current coreboot sources (25.03-161-gf6d40a9564) will not build when specifying lenovo/m920q as the mainboard, regardless of which payload is used. The following error occurs during build: ``` IFDTOOL IFDTOOL -p cnl -F build/fmap-template.fmd 3rdparty/blobs/mainboard/lenovo/m920q/descriptor.bin File 3rdparty/blobs/mainboard/lenovo/m920q/descriptor.bin is 4096 bytes Wrote layout to build/fmap-template.fmd HOSTCC cbfstool/fmaptool.o HOSTCC cbfstool/cbfs_sections.o HOSTCC cbfstool/fmap_from_fmd.o HOSTCC cbfstool/fmd.o HOSTCC cbfstool/fmd_parser.o HOSTCC cbfstool/fmd_scanner.o HOSTCC cbfstool/fmap.o HOSTCC cbfstool/kv_pair.o HOSTCC cbfstool/valstr.o HOSTCC cbfstool/fmaptool (link) FMAP build/util/cbfstool/fmaptool -h build/fmap_config.h build/fmap.fmd build/fmap.fmap syntax error FATAL: Failed while processing provided descriptor make: *** [Makefile.mk:1263: build/fmap.fmap] Error 4 ``` It appears that this error is the result of the commit a7eb390796ef4ba7baaffca741664b816de12256 (mb/*/*/*.fmd: Start flash at 0). This commit appears to remove all references to the token ##ROM_BASE##, but ifdtool has not been updated to reflect this change. The following patch appears to fix the issue on my end and allow coreboot to build for lenovo/m920q: ``` diff diff --git a/util/ifdtool/ifdtool.c b/util/ifdtool/ifdtool.c index 94105efe52..b21a89c0e1 100644 --- a/util/ifdtool/ifdtool.c +++ b/util/ifdtool/ifdtool.c @@ -1094,7 +1094,7 @@ static void create_fmap_template(char *image, int size, const char *layout_fname exit(EXIT_FAILURE); } - char *bbuf = "FLASH@##ROM_BASE## ##ROM_SIZE## {\n"; + char *bbuf = "FLASH ##ROM_SIZE## {\n"; if (write(layout_fd, bbuf, strlen(bbuf)) < 0) { perror("Could not write to file"); exit(EXIT_FAILURE); ``` In case it is needed, I have attached my .config settings. ---Files-------------------------------- config_lenovo_m920q_20250411.txt (26.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 3

[coreboot - Bug #590] (New) emulation/qemu-i440fx with GRUB payload: cbmem fails with `Table not found.`
by Paul Menzel 14 Apr '25

14 Apr '25

Issue #590 has been reported by Paul Menzel. ---------------------------------------- Bug #590: emulation/qemu-i440fx with GRUB payload: cbmem fails with `Table not found.` https://ticket.coreboot.org/issues/590 * Author: Paul Menzel * Status: New * Priority: Normal * Target version: none * Start date: 2025-04-10 * Affected versions: 25.03 ---------------------------------------- See `emulation/qemu-i440fx/25.03-154-g9e757b3396/2025-04-10T04_35_41Z` in the board status repository for the configuration. Building coreboot (25.03-154-g9e757b3396) for emulation/qemu-i440fx with GRUB (master) as payload, `cbmem` does not find the CBMEM tables and aborts with `Table not found.`. qemu-system-x86_64 -bios /dev/shm/coreboot/build/coreboot.rom -L /dev/shm -enable-kvm -smp cpus=2 -m 1G -hda /dev/shm/debian-32.img -serial stdio -net nic -net user,hostfwd=tcp::22222-:22 Using SeaBIOS, it works. -- 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 3

Bachelor thesis *Whole Process Persistence with coreboot* by Max Streicher, KIT
by Paul Menzel 14 Apr '25

14 Apr '25

Dear coreboot folks, I just found a the bachelor thesis *Whole Process Persistence with coreboot* by Max Streicher [1], from February 2024 (last year). It’s great to see, that coreboot allowed them to do research. Kind regards, Paul [1]: https://os.itec.kit.edu/downloads/2024_BA_Streicher_Whole_Process_Persisten…

1 0

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

14 Apr '25

Dear coreboot Community, Kindly note that we have an upcoming leadership meeting scheduled for Wednesday, April 16, 2025. [1] Please take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #589] (New) X230 eDP panel not detected by libgfxinit but works in Linux
by Jens Moelzer 09 Apr '25

09 Apr '25

Issue #589 has been reported by Jens Moelzer. ---------------------------------------- Bug #589: X230 eDP panel not detected by libgfxinit but works in Linux https://ticket.coreboot.org/issues/589 * Author: Jens Moelzer * Status: New * Priority: Normal * Target version: none * Start date: 2025-04-09 * Affected versions: 25.03 * Affected hardware: X230 eDP ---------------------------------------- I have a X230 with a eDP panel (LP125WF4-SPB1). My FHD mod board is self designed but somewhat similar to the nitrocaster mod (just much simpler). It takes DP_D from the docking port (2 lanes plus AUX plus HDP) and BACKLIGHT_ON + PANEL_BKLT_CTRL from the LVDS connector and connects everything directly to the eDP panel. It is totally passive and has no MCU and no EEPROM. I also attached the schematic (dasher-fhd.pdf). The panel stays blank until Linux boots and from the debug output it seems libgfxinit does not detect it at all. Once drm/i915 in Linux takes over the panel starts up and works perfectly fine including backlight control. From the log it seems that coreboot/libgfxinit for some reason can't read the EDID but Linux has no problem reading the EDID. An external display attached to the mini-DP port is detected by libgfxinit and does work with coreboot. I'm using coreboot 25.03 with "ThinkPad X230 eDP Mod (2K/FHD)" as mainboard and libgfxinit with linear framebuffer and edk2 payload. Though I also tried other payloads, gfx initialization settings, various changes to `gma-mainboard.ads`, `devicetree.cb` and other hacks I though worth a try. I also played around a lot with modifications to the VBT (explicitly configuring my panel including DTD, enabling edidless, ...). But nothing made any difference. Attached you find a coreboot log with Ada debug enabled (cbmem.log) and a full Linux boot log with `drm.debug=0x1ff` (linux.log) from the same boot since I though it might help to see what i915 is doing to get the panel working. ---Files-------------------------------- cbmem.log (58.3 KB) linux.log (301 KB) dasher-fhd.pdf (74.4 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

1 0

2025_04_09 coreboot Group Review Session
by mina＠coreboot.org 07 Apr '25

07 Apr '25

Hello coreboot! Our upcoming group review session is scheduled for Wednesday, April 9. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… 937#gid=1695410937) Kindly add any specific patches you'd like the group to review to the top of the sheet. As an hour is not sufficient to address all patches on the list, reviewing patches in advance would be greatly appreciated. Thank you. Best regards, Mina.

1 0

git tag 24.12 (would clobber existing tag)
by Paul Menzel 05 Apr '25

05 Apr '25

Dear coreboot folks, Just a quick question, if there the 24.12 tag was renewed back in December(?). $ LANG= git fetch --tags From ssh://review.coreboot.org:29418/coreboot ! [rejected] 24.12 -> 24.12 (would clobber existing tag) I don’t think, I manually added a tag, but I can’t say for certain, what I did several months ago. Kind regards, Paul [1]: https://doc.coreboot.org/releases/coreboot-24.12-relnotes.html

3 4

HP t740
by rherr 04 Apr '25

04 Apr '25

Attn: coreboot Is coreboot compatible with the HP t740 Thin Client? Thanks, Rodger Herrington Blanco, TX, USA

1 0

2025-04-02 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 03 Apr '25

03 Apr '25

# 2025-04-02 - coreboot Leadership Meeting ## Attendees Felix Singer, Jay Talbott, Felix Held, Jon Murphy, Karthik R, Maximilian Brune, Werner Zeh, Matt DeVillier, Martin Roth, Julius Werner, Andre, Mina Asante. ## Open Action Items * 2024-11-27 * [Open] Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * [Open] Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches.” * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian(?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long term project. ## Minutes ### [Martin] What’s going on with the GPL & Cisco * DavidH has been working on this. Still waiting for Cisco - They did a drop a couple years ago, but there are still additional products they haven’t released source code for. * Martin will reach out to David and update the meeting minutes with the current status. * [DavidH] Last I heard, SFC was going to set up a meeting in San Jose between their contact and those of us who are in the area (myself, Stefan, Ron, etc.) and possibly fly one of their attorneys over to attend (depending if lawyers are invited or not). This seems to have stalled again, likely due to the Vizio case consuming a lot of their bandwidth. ### [Martin] Discussion about having meetings between companies and coreboot. * We would like to have some regular meetings with companies or other groups where upcoming plans can be discussed. * [Matt] Put this out on the mailing list * [Max] How often would this be? How will people be made aware? * Monthly at most * At least two of the coreboot leadership would be present or it would have to be rescheduled * The meeting would be put on the coreboot mailing list and calendar. * The meeting could be scheduled by asking on the mailing list or reaching out to the coreboot leadership. # Next Leadership Meeting * April 16, 2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course, items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 31 Mar '25

31 Mar '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, April 2, 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 ### [Martin] What’s going on with the GPL & Cisco? ### [Martin] Discussion about having meetings between companies and coreboot. * We would like to have some regular meetings with companies or other groups where upcoming plans can be discussed. ## Notifications * coreboot 25.03 release is complete. We will do a blog post for it tomorrow. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Q on flashing IFD from within coreboot (IVB boards)
by Keith Hui 31 Mar '25

31 Mar '25

I have narrowed the IFD update logic to one UEFI module within vendor BIOS: PcieLaneDxe, and after running Ghidra on it, I have learned enough to start implementing it on coreboot. All is in pursuit of this: https://review.coreboot.org/c/coreboot/+/85413 It will also help with the recently upstream p8z77-v_le_plus, and Sabertooth Z77. Turns out vendor is also just reflashing the IFD after configuring some GPIOs on the board. They don't seem concerned about SPI controller freezing. My code is going to look like this: 8<------ static enum cb_err reprogram_ifd(u8 new_pciepcs1) { const unsigned int PCHSTRP9 = 0x124; u16 lvscc = RCBA16(0x38c4); const unsigned int lbes_map[] = { 256, 4 * KiB, 8 * KiB, 64 * KiB }; u8 * ifdbuf; u8 erase_opcode = (lvscc >> 8) & 0xff; unsigned int erase_size = lbes_map[lvscc & 0b11]; unsigned int i; ifdbuf = malloc(erase_size); /* Read */ memcpy(ifdbuf, (void *) 0xff800000, erase_size); /* Patch */ ifdbuf[PCHSTRP9] &= 0b11111100; ifdbuf[PCHSTRP9] |= (pciepcs1 & 0b11); /* Erase */ /* Write */ for (i = 0; i < erase_size; i+=64) { if (is_write_needed (ifdbuf+i, 64) { /* Write all 64 bytes if anything within isn't 0xff */ } } free(ifdbuf); return CB_SUCCESS; } 8<------ Q1: So far all boards in the Asus p8x7x-series family that need this use 8MiB SPI flash, so they're mapped to 0xff800000 when run as 32-bit. What is the right address to use when coreboot is compiled as 64-bit? Would I have to do "max int - 8 MiB"? Q2: I may have asked this before. Can I use SPI_FLASH Kconfig and the SPI flash driver? Can I use this without a FMD file? Or am I better off rolling my own again? Thanks Keith

1 0

[coreboot - Support #585] (New) acpi MSDM / SLIC table usage?
by Walter Sonius 29 Mar '25

29 Mar '25

Issue #585 has been reported by Walter Sonius. ---------------------------------------- Support #585: acpi MSDM / SLIC table usage? https://ticket.coreboot.org/issues/585 * Author: Walter Sonius * Status: New * Priority: Normal * Category: Documentation * Target version: none * Start date: 2025-03-20 * Affected OS: Windows 8 Pro / Windows 10 Pro ---------------------------------------- What option(s) does one need to compile this feature into a coreboot & edk2 build and where does one put the `slic_file` and in what format? Couldn't find anything in the documentation nor the commits that introduce MSDM/SLIC support: https://review.coreboot.org/c/coreboot/+/44995 https://review.coreboot.org/c/coreboot/+/7202 -- 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 8

[coreboot - Bug #569] (New) coreinfo: i386-elf-gcc-ar: Cannot find binary 'i386-elf-ar'
by Matthias Brugger 28 Mar '25

28 Mar '25

Issue #569 has been reported by Matthias Brugger. ---------------------------------------- Bug #569: coreinfo: i386-elf-gcc-ar: Cannot find binary 'i386-elf-ar' https://ticket.coreboot.org/issues/569 * Author: Matthias Brugger * Status: New * Priority: Normal * Target version: none * Start date: 2024-11-14 * Affected versions: master * Related links: https://doc.coreboot.org/tutorial/part1.html ---------------------------------------- Hi, when trying to compile the qemu example with latest branch, I get the following error: ``` ~/src/coreboot/$ make -C payloads/coreinfo/ Makefile:358: warning: overriding recipe for target '/home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/arch/x86/exec.libc.o' Makefile:358: warning: ignoring old recipe for target '/home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/arch/x86/exec.libc.o' AR /home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/libpci.a /home/mbrugger/src/coreboot/payloads/libpayload/../../util/crossgcc/xgcc/bin/i386-elf-gcc-ar: Cannot find binary 'i386-elf-ar' make[1]: *** [Makefile.mk:116: /home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/libpci.a] Error 1 make: *** [../libpayload/Makefile.payload:153: /home/mbrugger/src/coreboot/payloads/coreinfo/libpayload/libpayload.a] Error 2 ``` I double checked and ./util/crossgcc/xgcc/bin/i386-elf-ar exists. I suppose it's a problem in the cross compilation of i386-elf-gcc-ar -- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 28 Mar '25

28 Mar '25

Dear coreboot Community, Kindly note that we have an upcoming leadership meeting scheduled for Wednesday, April 2, 2025. [1] Please take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #507] (Closed) Windows GPU driver fails to load on AMD based google/guybrush, google/skyrim boards
by Matt DeVillier 27 Mar '25

27 Mar '25

Issue #507 has been updated by Matt DeVillier. Status changed from New to Closed This isn't an issue when not using vboot/PSP verstage, so closing for now. ---------------------------------------- Bug #507: Windows GPU driver fails to load on AMD based google/guybrush, google/skyrim boards https://ticket.coreboot.org/issues/507#change-2049 * Author: Matt DeVillier * Status: Closed * Priority: Normal * Target version: none * Start date: 2023-08-30 * Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, 4.21, main * Affected hardware: google/guybrush, google/skyrim ---------------------------------------- The Windows GPU drivers on AMD Cezanne and Mendocino platform ChromeOS devices (google guybrush and skyrim boards respectively) fail to load due to the PSP boot mode being `Development` vs `Production.` On these platforms, the PSP only boots in `Production` mode when ChromeOS verified boot mode is active. Possible solutions include having the PSP boot in `Production` mode when vboot is not used at all, when CONFIG_CHROMEOS is not set, or (always) when PSP signed verstage is used. Any of these require changes to the PSP firmware from AMD. -- 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

Re: [coreboot - Bug #582] (Closed) failure to boot after using haswell nri
by p db 26 Mar '25

26 Mar '25

> Problems are not ours, Problems are about corporations that in the year > 1991, decided do not give support to the operating system: "Gnu/linux"; > > When things were more easy to solve for Software and for Hardware, to the > same time, corporations REFUSED to develop "Free Hardware" and REFUSED to > put BLACK on WHITE and To SAY what type of COMPONENTS were used to develop > the motherboards. > > Informatics means: "Automatic Information"; it does not mean to give > support ONLY to the NON free software operating systems of corporations! > > Hardware MUST BE 100% Free! Why users must become crazy to have support > for Hardware and for Software? > > Awaiting a reply, > > Best Regards, > > Paolo Del Bene [PdB71] >

1 0

[coreboot - Bug #582] (New) failure to boot after using haswell nri
by Ron Dillenger 25 Mar '25

25 Mar '25

Issue #582 has been reported by Ron Dillenger. ---------------------------------------- Bug #582: failure to boot after using haswell nri https://ticket.coreboot.org/issues/582 * Author: Ron Dillenger * Status: New * Priority: Normal * Assignee: Angel Pons * Category: coreboot common code * Target version: master * Start date: 2025-03-15 * Affected hardware: Z97E-ITX a/c ---------------------------------------- Good day, I am experiencing a rather strange issue with my system after trying out the recently merged Haswell NRI. It was working great, booted fine and ran memtest86+ for the whole day, 10 passes with 0 errors. I then turned off the system for the night by just holding the power button down. The next morning, the system would not boot at all. No display output. Ever since then I haven't been able to get it to boot at all. One thing I have noticed is that the system will restart after about 15 seconds if there is an SPI flash chip present. If there is no present SPI chip this doesn't happen. So I assume the PCH is reading it or at least trying to. Worth noting is it only restarts one time, then it will just remain powered on forever until I turn it off. The restarting also doesn't seem to be consistent, it seems to only happen if I flip the switch on the power supply on and off. If I don't do this it will just remain powered on forever. My hardware: Z97E-ITX a/c 16GB TridentX 2400mhz DDR3 i7 4790S Things I have done: - Reflashed the original stock firmware - Tried a different known working kit of RAM - Removed everything from the system that is nonessential to boot (disk, keyboard, USB drives, etc.) - Removed the CMOS battery - Tried a different known working PSU - Tried different SPI flash chips with coreboot on them - Tried the original SPI flash chip with coreboot on it - Tried coreboot with flashconsole enabled, nothing is written to it At this point I suspect the problem is either with the motherboard, CPU or SPI flash chip. They are the only things I haven't swapped out. One reason I suspect the SPI flash chip is because I wrote to it a lot of times in my initial attempts to get coreboot working on this board. So, maybe that caused excessive wear, I'm not sure. The other reason is because one of the last flashes I did was with the internal motherboard programmer, which worked fine. At the time of the flash I was running the board with all the flash descriptor binaries and an external microcode binary included for my CPU since building it from tree was failing. The image that I flashed with the internal programmer was the same image with me_cleaner run on it. The system booted fine, I confirmed me_cleaner worked but then I tried to do another flash to include memtest86+ as a second payload and flashrom gave some errors about not being able to erase, telling me the flash chip ended up being unchanged. I then flashed the image using an external programmer (raspberry PI with a breadboard) and that worked fine. This makes me somewhat doubt it's the SPI flash chip, flashrom successfully verifies the flash with no errors, and I can read it back fine too and it's the same as what I flashed. I tried other flash chips but my understanding is they aren't all command-compatible so that could be why they didn't work. Unfortunately I haven't been able to try the stock bios on another flash chip because I don't have any motherboards that have chips of the same size. I know this could maybe be a hardware failure unrelated to coreboot or haswell NRI but I figured I would submit this with the hope that the developer or someone else here might have some better ideas about what is going on. -- 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 - Bug #586] (Response Needed) autoport should sanitize at least its ACPI DSDT SLIC/MSDM key dumps?
by Walter Sonius 25 Mar '25

25 Mar '25

Issue #586 has been reported by Walter Sonius. ---------------------------------------- Bug #586: autoport should sanitize at least its ACPI DSDT SLIC/MSDM key dumps? https://ticket.coreboot.org/issues/586 * Author: Walter Sonius * Status: Response Needed * Priority: Urgent * Start date: 2025-03-23 ---------------------------------------- Some might even want other info like MAC addresses or serial numbers to be cleared from the autoport dumps, but could at least these SLIC/MSDM activation keys be wiped by default when doing a log dump? -- 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 4

2025_03_26 coreboot Group Review Session
by mina＠coreboot.org 24 Mar '25

24 Mar '25

Hello coreboot! This is a reminder that our upcoming group review session is scheduled for Wednesday, March 26. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Kindly add any specific patches you'd like the group to review to the top of the sheet. As one hour is not sufficient to address all patches on the list, reviewing patches in advance would be greatly appreciated. Thank you. Best regards, Mina.

1 0

Fwd: Linux: [GIT PULL] Please pull fwctl subsystem changes
by Paul Menzel 24 Mar '25

24 Mar '25

Dear coreboot folks, Is Nvidia’s Jason Gunthorpe pull request *Please pull fwctl subsystem changes* [1] interesting for the coreboot ecosystem (including payoads), and if so, does it meet the requirements? > To refresh what it is about please refer to the cover letter and LWN coverage: > > https://lore.kernel.org/all/0-v5-642aa0c94070+4447f-fwctl_jgg@nvidia.com/ > https://lwn.net/Articles/990802/ Kind regards, Paul [1]: https://lore.kernel.org/lkml/Z+F2tcBM1LJpTDF9@nvidia.com/

1 0

coreboot 25.03 Release Tag Scheduled For 27_03 _2025
by mina＠coreboot.org 24 Mar '25

24 Mar '25

Hello everyone, This is a reminder that the coreboot release version 25.03 is scheduled to be tagged on Thursday, March 27th. Please let us know if there are any patches that should be included in the release. You can do that by adding the hashtag "coreboot_release_25.03" to the related patch on Gerrit. The hashtag field is shown after clicking on the "show all" button from the top left information block of a patch. We are using the hashtag "post_coreboot_release_25.03" to track patches that are important or useful and possibly even ready to be submitted but might break something and cause issues, so we prefer to submit them after the release. This gives enough time for testing until the next release. As usual, we have a 1 week delay after the new version is tagged before the announcement to allow for testing of the release. This gives us a chance to fix any issues that are found before making the release public. The 25.03 public announcement is scheduled for April 3rd. If you have any questions or concerns, please let the coreboot release team know or reply to this email. Thank you. Best regards, Mina.

1 0

[coreboot - Support #584] (New) [x200] DDR3 SPD value are read but memtest doesn't display them
by David Duchesne 21 Mar '25

21 Mar '25

Issue #584 has been reported by David Duchesne. ---------------------------------------- Support #584: [x200] DDR3 SPD value are read but memtest doesn't display them https://ticket.coreboot.org/issues/584 * Author: David Duchesne * Status: New * Priority: Normal * Target version: none * Start date: 2025-03-19 ---------------------------------------- Hello, Before opening an issue on memtest issue tracker, I would like to know if the DDR3 SPD reading is correct because with memtest 7.20 (64bit build), the main screen is fully empty, instead of showing: ``` Memory SPD Information ---- - Slot 0 : RAM SIZE / SPEED / PART NUMBER - Slot 1 : RAM SIZE / SPEED / PART NUMBER ``` Also, no mention of the RAM CAS just above. It is empty. Otherwise the test is running correctly. I'm having the same issue with a t400, r400 & t500 and memtest 7.20 (and earlier) All my lenovo are running coreboot 24.12 and have **CONFIG_DUMP_SMBIOS_TYPE17=y** Otherwise dmidecode have no issue reporting those values, see below. Any advice appreciated. Thanks. ``` $ dmidecode -t 17 # dmidecode 3.6 Getting SMBIOS data from sysfs. SMBIOS 3.0 present. Handle 0x000A, DMI type 17, 40 bytes Memory Device Array Handle: 0x0009 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4 GB Form Factor: SODIMM Set: None Locator: Channel-0-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Unknown Synchronous Speed: 1067 MT/s Manufacturer: Samsung Serial Number: 4608a20b Asset Tag: Channel-0-DIMM-0-AssetTag Part Number: M471B5273CH0-CF8 Rank: 2 Configured Memory Speed: 1067 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown Handle 0x000B, DMI type 17, 40 bytes Memory Device Array Handle: 0x0009 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4 GB Form Factor: SODIMM Set: None Locator: Channel-1-DIMM-0 Bank Locator: BANK 1 Type: DDR3 Type Detail: Unknown Synchronous Speed: 1067 MT/s Manufacturer: Samsung Serial Number: 4608a20b Asset Tag: Channel-1-DIMM-0-AssetTag Part Number: M471B5273CH0-CF8 Rank: 2 Configured Memory Speed: 1067 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown ``` -- 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

2025-03-19 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 18 Mar '25

18 Mar '25

Dear coreboot Community, Please note that our leadership meeting scheduled for tomorrow, March 19 has been canceled, as the issue on the agenda has already been resolved. Thank you. Best regards, Mina.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 17 Mar '25

17 Mar '25

Dear coreboot Community, Our upcoming leadership meeting is scheduled for Wednesday, March 19, 2025. [1] Please take a moment to update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot 25.03 release schedule
by coreboot org 14 Mar '25

14 Mar '25

Hi everyone, This is the notification that we're two weeks away from the coreboot 25.03 release tag, scheduled for Thursday, March 27th. Please mark patches you want to be merged before the release with the hashtag “coreboot_release_25.03”. There's no promise that these will get merged, but we will try to get everything on the list in. Mark any patches that need to be merged *after* the release with the hashtag "post_coreboot_release_25.03" As usual, we have a 1 week delay after the new version is tagged before the announcement to allow for testing of the release. This gives us a chance to fix any issues that are found before making the release public. The 25.03 public announcement is scheduled for April 3rd. If you have any questions or concerns, please let the coreboot release team know or reply to this email. Thanks, Martin

1 0

[coreboot - Feature #461] Replacing Haswell mrc.bin blob with free software
by gaspar ilom 12 Mar '25

12 Mar '25

Issue #461 has been updated by gaspar ilom. The patch train got merged: https://review.coreboot.org/c/coreboot/+/81897/4 Anyway, in heads we have made an effort to use NRI on the W541 and T440p boards. However boot times are between 10 and 20s. So it seems like the mrc cache is not properly build and reused. Also, on the W541 S3 resume does not work (just reboots the machine). I can offer testing and helping debugging this feature: https://github.com/linuxboot/heads/pull/1923 ---------------------------------------- Feature #461: Replacing Haswell mrc.bin blob with free software https://ticket.coreboot.org/issues/461#change-1999 * Author: akjuxr3 akjuxr3 * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: chipset configuration * Target version: none * Start date: 2020-04-01 * Related links: https://review.coreboot.org/q/topic:haswell-nri * Affected hardware: All Haswell mainboards ---------------------------------------- Currently in case of the ability to run as less amount of closed source software as possible and still have Microcode updates the reduced Intel ME with disabled bit in IFD and the lga1155 or the mobile versions of those cpus are the only option for x86_64 out there. The next cpu generation (Haswell) inside for example T440p and W541 require the binary blob mrc.bin Are there any plans of replacing the Haswell mrc.bin with free software? Or have the x86_64 platform be given up when the goal is to run just free software and the people should move to aarch64 or risc-v? -- 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_03_12 coreboot Group Review Sesssion
by mina＠coreboot.org 10 Mar '25

10 Mar '25

Hello coreboot! Please note that we have an upcoming group review session scheduled for Wednesday, March 12. https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

[coreboot - Bug #580] (New) smbios table only recorded data for one slot
by Keith Hui 09 Mar '25

09 Mar '25

Issue #580 has been reported by Keith Hui. ---------------------------------------- Bug #580: smbios table only recorded data for one slot https://ticket.coreboot.org/issues/580 * Author: Keith Hui * Status: New * Priority: Normal * Category: coreboot common code * Start date: 2025-03-09 * Affected hardware: asus/p8z77-v_le_plus ---------------------------------------- I entered smbios slot description for 5 slots in devicetree (via an overridetree.cb), but after booting only the last slot is recorded in the data table. overridetree.cb ``` device domain 0 on subsystemid 0x1043 0x84ca inherit device ref peg11 on # PCIEX_16_2 smbios_slot_desc "SlotTypePciExpressGen3X8" "SlotLengthLong" "PCIEX16_2" "SlotDataBusWidth8X" end chip southbridge/intel/bd82x6x register "usb_port_config" = "{ /* not relevant */ }" register "gen1_dec" = "0x000c0291" # NCT6779 HWM register "gen4_dec" = "0x0000ff29" # Could be for KB3722 EC device ref pcie_rp1 on # PCIEX_16_3 (electrical x2 or x4) smbios_slot_desc "SlotTypePciExpressGen2X4" "SlotLengthLong" "PCIEX16_3" "SlotDataBusWidth4X" end device ref pcie_rp3 on smbios_slot_desc "SlotTypePciExpressGen2X1" "SlotLengthShort" "PCIEX1_1" "SlotDataBusWidth1X" end device ref pcie_rp4 on smbios_slot_desc "SlotTypePciExpressGen2X1" "SlotLengthShort" "PCIEX1_2" "SlotDataBusWidth1X" end device ref pcie_rp5 on # RTL8111F LAN chip drivers/net register "customized_leds" = "0x482" device pci 00.0 on subsystemid 0x1043 0x8505 end end end device ref pcie_rp6 on # ASM1083 PCI bridge subsystemid 0x1043 0x8489 smbios_slot_desc "SlotTypePci" "SlotLengthLong" "PCI1" "SlotDataBusWidth32Bit" end device ref pcie_rp7 on # Marvell 88SE9120 ESATA6G subsystemid 0x1043 0x83ba end device ref pcie_rp8 on # ASM1042 USB3 subsystemid 0x1043 0x8488 end device ref hda on subsystemid 0x1043 0x841a end device ref lpc on chip superio/nuvoton/nct6779d device pnp 2e.1 off end # Parallel device pnp 2e.2 on # UART A io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 2e.3 off end # UART B, IR device pnp 2e.5 on # PS2 KBC io 0x60 = 0x0060 # KBC1 base io 0x62 = 0x0064 # KBC2 base irq 0x70 = 1 # Keyboard IRQ irq 0x72 = 12 # Mouse IRQ # KBC 12Mhz/A20 speed/sw KBRST drq 0xf0 = 0x82 end device pnp 2e.6 off end # CIR device pnp 2e.7 off end # GPIOs 6-8 device pnp 2e.8 off end # WDT1 GPIO 0-1 device pnp 2e.108 on end # GPIO0 device pnp 2e.109 on end # GPIO1 device pnp 2e.509 on end # GPIO5 all in device pnp 2e.a on # ACPI drq 0xe7 = 0x11 drq 0xf2 = 0x5d # Enable PME end device pnp 2e.b on # H/W Monitor, FP LED io 0x60 = 0x290 io 0x62 = 0 irq 0x70 = 0 drq 0xe4 = 0xf9 # Use GP50/52/55 end device pnp 2e.d off end # WDT1 device pnp 2e.e off end # CIR wake-up device pnp 2e.f off end device pnp 2e.14 on end # Port 80 UART device pnp 2e.16 off end # Deep sleep end end end end ``` Output of dmidecode -t9 ``` # dmidecode 3.6 Getting SMBIOS data from sysfs. SMBIOS 3.0.0 present. Handle 0x0015, DMI type 9, 19 bytes System Slot Information Designation: PCI1 Type: PCI Data Bus Width: 32 bit Current Usage: In Use Length: Long ID: 0 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Bus Address: 0000:00:1c.4 Data Bus Width (Base): 1 Peer Devices: 0 ``` I expect to see all 5 slots returned. -- 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

[announce] flashprog v1.4 is out!
by Nico Huber 09 Mar '25

09 Mar '25

Hi, I'm glad to announce the release of flashprog v1.4. This time we've mostly updated the flash chip database, added 90 new entries and polished many existing ones. You can read more about it in the full release notes[1]. As usual, you can download the source via Git[2] (tag `v1.4`) or as tarball[3]. Cheers, Nico [1] https://flashprog.org/wiki/Flashprog/v1.4 [2] https://github.com/SourceArcade/flashprog [3] https://flashprog.org/releases/flashprog-v1.4.tar.bz2

1 0

2025-03-05 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 06 Mar '25

06 Mar '25

# 2025-03-05 - coreboot Leadership Meeting ## Attendees Mina Asante, Jon Murphy, Felix Singer, Benjamin Doron, Felix Held, Andre, Andy Ebrahiem, Jeremy Compostella, Martin Roth, Matt DeVillier, David Hendricks, Jay Talbott, Julius Werner, Karthik R. ## Open Action Items * 2024-11-27 * [Open] Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * [Open] Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long term project. ## Minutes ### [Benjamin] Add support for sharing SMM with the payload * To support UEFI secure boot effectively, we need to perform the verify and write steps of its variables together, in SMM. Consequently, we propose a solution where coreboot ‘owns’ SMM (initialises and installs all its regular SMI handlers), and the payload is permitted to install its own SMI handlers within a dedicated SMRAM region that coreboot will call into (and return from) for payload-specific use-cases. While this was developed for EDK2, to support secure boot, note that it’s not UEFI-specific, and contains nothing specific to secure boot. This is a superior solution to one we proposed in 2023, called “[Add support for calling SMM payloads.](https://docs.google.com/document/d/1S1hLGc7nhBIaD3wN3eylyjhMMqEo… * Earlier proposal handed SMM control to the payload, which caused issues since some things like suspend/resume and EC functionality needed to be provided in SMM controlled by coreboot. * This new approach allows EDK2 to read, verify, and potentially write secure boot related variables in an "atomic" manner (using coreboot's SPI driver on the backend?). This solves a problem from the earlier solution where secure boot variables could be changed by an attacker in between EDK2 and coreboot interactions. * [A.I] Benjamin to publish a[ blog post at the 9E blog](https://9elements.com/blog/) about this so that we can review the design in more detail. (DFAD/ETA: unknown, probably after university exams) ### [Martin] Updating website * Privacy Policy * Leadership page * Trademark & logo ### [Martin] Email server * As we agreed previously, the email service remained on Stefan’s server. This includes the mailing list * Stefan, Patrick and myself are admins there. ### [Jon] cbmem updates * Google is pursuing testing of coreboot with Android. As such, we do need to make some changes to coreboot mechanisms to facilitate a slightly different OS. Can we get review on some cbmem changes to add support in sysfs: (https://review.coreboot.org/q/topic:%22cb em-in-sysfs%22) ### [Martin] We can post blogs on the coreboot blog if people are interested in writing things. * Don’t want to make it an advertising area, but we’d like news about devices using coreboot. * Martin can write something about opensil with coreboot after the Phoenix & Turin Proof-of-Concept (Non-production) openSIL releases. # Next Leadership Meeting * March 19, 2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course, items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 03 Mar '25

03 Mar '25

Dear coreboot Community, Please note that we have an upcoming leadership meeting scheduled for Wednesday, March 5, 2025. [1] Kindly review the agenda and share your thoughts or suggest additional items you would like to discuss during the meeting. [2] Thank you. ## Current Agenda Items ### [Benjamin] Add support for sharing SMM with the payload * To support UEFI secure boot effectively, we need to perform the verify and write steps of its variables together, in SMM. Consequently, we propose a solution where coreboot ‘owns’ SMM (initialises and installs all its regular SMI handlers), and the payload is permitted to install its own SMI handlers within a dedicated SMRAM region that coreboot will call into (and return from) for payload-specific use-cases. While this was developed for EDK2, to support secure boot, note that it’s not UEFI-specific, and contains nothing specific to secure boot. This is a superior solution to one we proposed in 2023, called “Add support for calling SMM payloads.” [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

(preping to coreboot) laptop X230 stuck on 2.75 - I cannot downgrade to 2.60!
by bruno＠slingshotsecurity.pro 02 Mar '25

02 Mar '25

I think I got myself in trouble stuck on 2.75 - I cannot downgrade to 2.60 (X230) via IVprep or the lenovo tool (I get "This app can't run on your PC"). Is there a way forward, please? Here is what I did and was planning to do (1vyrain, skulls and clean/disable/break the Intel ME): ## 1. EC Patching (accept all batteries and keyboards) https://github.com/hamishcoleman/thinkpad-ec/ It recomends using on the last modifiable version: x230 -BIOS 2.75 (G2ETB5WW) EC 1.14 (G2HT35WW) Therefore I upgraded from my 2.55 to 2.75, by downloading g2uj31us.exe, saving on a usb stick and running on the target machine's windows (the bootable iso would not dd well to the usb stick). https://support.lenovo.com/ec/en/downloads/ds029187 ## 2. Downgrade from 2.75 to 2.60 (X230) (I cannot perform from here onwards): https://github.com/n4ru/IVprep/tree/master Downloaded both IVprep and g2uj17us.exe and saved on the usb stick to run on target machine's windows but then I get I get "This app can't run on your PC". I have tested with both: BIOS Setup -> Security -> UEFI BIOS Update Option. Set Flash BIOS Updating by End-Users to Enabled, and Secure RollBack Prevention to Disabled BIOS Setup -> Security -> UEFI BIOS Update Option. Set Flash BIOS Updating by End-Users to Enabled, and Secure RollBack Prevention to Enabled ## 3. Get rid of the ME https://github.com/corna/me_cleaner I gues for this one, I should boot the target machine with a Live Linux, clone the repo and execute ## 4. Install Skulls via 1vyrain https://github.com/n4ru/1vyrain This would be burn the usb stick to the 1vyrain, use the ethernet cable and the skulls release URL https://github.com/merge/skulls/releases ## This question has been also posted on: - https://github.com/n4ru/1vyrain/issues/144- https://forum.qubes-os.org/t/how-to-use-ivprep-and-1vyrain-and-disable-inte… https://github.com/merge/skulls/issues/302 - https://github.com/hamishcoleman/thinkpad-ec/issues/266

1 0

Re: PC with coreboot - boot menu locked
by Paul Menzel 28 Feb '25

28 Feb '25

Dear Andrea, Welcome to coreboot. Please do not send messages over 500 kB (definitely not more than 1 MB) to mailing lists. Am 16.02.25 um 18:30 schrieb Andrea Battelli: > I have an embedded system that I want to reuse but the bios is locked up > and when I press the f12 key, it shows only a boot option (payload). How > can I disassemble the bios or rebuild another one? > > Attached is the dump of the rom and the screenshot of the boot menu It’d be great if you just copied the text output from the payload. SeaBIOS (version SageBIOS-20161017_085144-ttyree-dev-gtk-gtech-com) Select boot device: 1. Payload [igt_secure] Sage Engineering [1] *was* a company offering coreboot development a long time ago. No idea, if they upstreamed this board, or how to get the source code. What board is it exactly? Anyway, your attached dump has a coreboot image (CBFS – coreboot file system), you can dump with `cbfstool`: ``` $ ~/src/coreboot/util/cbfstool/cbfstool bios_igt_orig.bin print FMAP REGION: COREBOOT bios_igt_orig.bin: 16384 kB, bootblocksize 1024, romsize 16777216, offset 0xc00000 alignment: 64 bytes, architecture: x86 Name Offset Type Size Comp roothashes 0xc00000 (unknown) 192 none fallback/romstage 0xc00100 stage 60241 none fallback/ramstage 0xc0ecc0 stage 94548 none fallback/payload 0xc25e80 simple elf 49158 none bootsplash.jpg 0xc31ec0 bootsplash 48411 none etc/boot-menu-wait 0xc3dc40 raw 8 none (empty) 0xc3dc80 null 4888 none keyupdate 0xc3efc0 mma 8192 none (empty) 0xc41000 null 3992 none keystore 0xc41fc0 mrc 131072 none img/igt_secure 0xc62000 simple elf 83362 none vgaroms/videobios.rom 0xc76600 optionrom 65536 none (empty) 0xc86640 null 51544 none bootorder 0xc92fc0 raw 4096 none (empty) 0xc94000 null 2604952 none cpu_microcode_blob.bin 0xf0ffc0 microcode 38912 none (empty) 0xf19800 null 157592 none mrc.cache 0xf3ffc0 mrc_cache 65536 none (empty) 0xf50000 null 65432 none fsp.bin 0xf5ffc0 spd 524288 none (empty) 0xfe0000 null 12248 none bootorder_sata 0xfe3000 raw 4096 none bootorder_usb 0xfe4040 raw 4096 none bootorder_sec 0xfe5080 raw 4096 none (empty) 0xfe60c0 null 24 none rootpub 0xfe6100 fsp 2064 none (empty) 0xfe6940 null 103000 none ``` It does not seem to contain the build configuration, but you might be able to boot from a USB device. From there you should be able to read the logs with `cbmem` and find out the coreboot version and board name. Maybe that brings you further. I have never heard of `igt_secure`. As you can access the dump, you can at least build the payload yourself, and replace `fallback/payload` or add it under `img/`. Maybe that works. No idea if the keys/hashes verify anything from this. Anyway, the above should get you going. Kind regards, Paul [1]: https://se-eng.com/ [2]:

3 2

[p8x7x port] Realtek loses its mind & Marvell not going with times.
by Keith Hui 28 Feb '25

28 Feb '25

(Catchy subject eh? There's some truth to both.) My coreboot port to Asus P8Z77-V LE PLUS is almost ready, but I still have two outstanding problems. The board is losing its MAC address, partly because it doesn't have an 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 time Linux kernel sees it. I would then have to reassign its proper MAC address using "ip link change eno0 address <mac>". I added a debug read back in the rtl81xx driver and the device appears to be taking the MAC I programmed. Board also has a Marvell 88SE9120 for two extra SATA ports. It came up in legacy mode and pata_marvell driver isn't able to operate it. I find no documentation on how to switch to AHCI mode like ASM1061. Needless to say those two ports are currently useless. Ideas? I'm hoping to get this and a few supporting patches in for next release. https://review.coreboot.org/c/coreboot/+/86172 Thanks Keith

1 0

Re: PC with coreboot - boot menu locked
by p db 27 Feb '25

27 Feb '25

This is NOT free hardware, that is, tying people to solutions: "Digital Restricted Management", when people will understand that they will have to start relying on free hardware solutions, as usual, it will always be too late. Best Regards, Paolo Del Bene Il Gio 27 Feb 2025, 19:57 Andrea Battelli <battelli2(a)gmail.com> ha scritto: > Hi, > > I have an embedded system that I want to reuse but the bios is locked up > and when I press the f12 key, it shows only a boot option (payload). How > can I disassemble the bios or rebuild another one? > > Attached is the dump of the rom and the screenshot of the boot menu > > Thanks > Andrea > > PS: I don't how if it helps but the cpu is a Intel Core i3 4010U > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

2025_02_26 coreboot Group Review Sesssion
by mina＠coreboot.org 24 Feb '25

24 Feb '25

Hello coreboot! Our upcoming biweekly group review meeting is scheduled for Wednesday, February 26. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

Change in coreboot leadership
by David Hendricks 22 Feb '25

22 Feb '25

Hi everyone, After six years on the coreboot leadership team I've decided it's time to pass the torch. I joined the leadership team in 2019 while on a mission to get coreboot back on servers and am pleased with the progress that's been made. Now it's time for me to focus on family and other things and make room for somebody more hands-on with the day-to-day activities of the entire community. I'm happy to announce that Martin Roth will be taking over my spot on the leadership team. Though there are several strong contributors in our community, the leadership team has unanimously selected Martin for this position based on his exceptional qualifications: * Over 26 years of combined firmware development experience, including 13 years in the coreboot community and 13 years of BIOS development prior, mostly at Cyrix/National Semiconductor and AMD. * Significant technical contributions through thousands of patches and thoughtful code reviews, along with mentoring several community members. * Martin has maintained coreboot infrastructure for many years, working behind the scenes to keep the whole project going on a shoestring budget. This included years of maintaining our build infrastructure on servers in his basement. * Extensive experience working with (or at) silicon vendors on the foundational components needed to enable coreboot on bleeding-edge x86 platforms (FSP, AGESA, OpenSIL). * Experience at a variety of companies serving various market segments, ranging from embedded systems at National Semiconductor and Sage, to laptops at AMD and Google, and servers at AMD. * Strong commitment to open-source principles combined with technical expertise to achieve the best possible outcomes in our challenging industry. I'll continue in an advisory role and am also ramping up on some administrative tasks to lighten Martin's load so that he has more time to focus on the codebase. Thanks everyone, and congratulations to Martin!

2 1

2025-02-19 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 20 Feb '25

20 Feb '25

# 2025-02-19 - coreboot Leadership Meeting ## Attendees Felix Singer, Andre, Martin Roth, David Hendricks, Alicja Michalska, Julius Werner, Werner Zeh, Matt DeVillier, Andy Ebrahiem, Mina Asante, Karthik Ramasubramanian, Jeremy Compostella. ## Open Action Items * 2024-11-27 * [Open] Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * [Open] Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long term project. ## Minutes ### [Werner] Update on Intel’s plans around signing their FSP binaries * Currently not POR for API-mode binary, only for dispatch mode * It should not impact the coreboot flow. However, NDA customers need to keep an eye on it since if it does impact coreboot then that will be a drastic change. * Doc #830299 and #827444 ### [David] Change in coreboot leadership * Martin Roth will take my spot ### [Martin] AMD releasing Phoenix and Turin OpenSIL * Hopefully in February or early March * Somewhat more detail: (https://github.com/openSIL/openSIL/issues/24) * It'll be a while before releasing another one as they switch from proof-of-concept (POC) to plan-of-record (POR), migrating from AGESA to OpenSIL on next-gen SOCs. * Limits of POC * No graphics init, but could use the GOP driver with some effort in creating a wrapper. * Graphics init will be done in GOP driver (UEFI-specific) moving forward * coreboot needs a way to deal with this * We have yabel, x86emu, etc. for legacy graphics init. * uGOP or previous efforts? * AMD doesn't do graphics init before memory is up. * uGOP replaced open-source graphics init, which is the cause of the earlier pushback. * [Alicja] u-boot might have a workable solution? * Need to see what the current status is and potentially borrow parts of it to deal with graphics init. * Linux might be able to init graphics, but AtomBIOS tables still need to be filled in for kernel drivers to read. * [Alicja] On Intel side, there are video BIOS tables as well that fills in things like ports present. Alicja has gotten this working with coreboot + EDK2 by using GOP driver. * [Martin] Another option is to run GOP driver once in the tianocore payload to generate AtomBIOS tables, store the info, and then skip GOP driver on subsequent boots. * It's just a 64KiB chunk of data. * People with AMD NDA support can get a customized AtomBIOS table for their platform. Workarounds to run the GOP driver are more for the community to use. # Next Leadership Meeting * March 5, 2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course, items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot on Intel Leafhill (APL)
by Corvin Köhne 17 Feb '25

17 Feb '25

Hi, I'd like to get used to coreboot. Therefore, I'd like to be able to boot Linux and Windows on any platform yet. I've checked the coreboot tree and an Intel Apollo Lake CRB, namely Leafhill, is currently the only platform I have access to and coreboot has a mainboard folder for. So far, I'm able to boot Linux. It has some issues, e.g. the external PCIe slot of the board is not working yet, but it boots. Windows 10 dies with a BSOD and complains about UNSUPPORTED_PROCESSOR. Has anyone seen this issue before or can help me debug this issue? I've attached a boot log when trying to boot a Windows 10 Installer. What I did so far: I'm using a BIOS published by Intel, LEAFHILD.X64.0071.R01.1809030849.bin [1], for IFWI stitching of coreboot. I've verified that the Intel BIOS itself is working on my board. I've extracted the VBT and flashdescriptor of the Intel BIOS and passed it to my coreboot config shown below [2]. I've also applied some patches [3][4] to the coreboot tree itself because the USB port was not working on Linux and the flash layout does not fit to the flashdescriptor extracted by the Intel BIOS. [1] https://www.intel.com/content/www/us/en/developer/articles/tool/uefi-firmwa… [2] CONFIG_CCACHE=y CONFIG_VENDOR_INTEL=y CONFIG_INTEL_GMA_VBT_FILE="i915_vbt" CONFIG_IFD_BIN_PATH="flashregion_0_flashdescriptor.bin" CONFIG_BOARD_INTEL_LEAFHILL=y CONFIG_NEED_IFWI=y CONFIG_IFWI_FILE_NAME="leafhill.rom" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_RUN_FSP_GOP=y CONFIG_BOOTSPLASH=y CONFIG_PAYLOAD_EDK2=y CONFIG_EDK2_USE_EDK2_PLATFORMS=y CONFIG_EDK2_SERIAL_SUPPORT=y CONFIG_DISPLAY_FSP_CALLS_AND_STATUS=y [3] https://review.coreboot.org/c/coreboot/+/28547/1/src/mainboard/intel/leafhi… [4] diff --git a/src/mainboard/intel/leafhill/brd_gpio.h b/src/mainboard/intel/leafhill/brd_gpio.h index 7c6298f266a..df85752c056 100644 --- a/src/mainboard/intel/leafhill/brd_gpio.h +++ b/src/mainboard/intel/leafhill/brd_gpio.h @@ -33,4 +33,9 @@ static const struct pad_config gpio_table[] = { PAD_CFG_NF(SMB_CLK, NATIVE, DEEP, NF1), PAD_CFG_NF(SMB_DATA, NATIVE, DEEP, NF1), + + /// Added feature to enable USB power for USB devices, specifically keyboard + /// and mouse. + PAD_CFG_GPO_IOSSTATE_IOSTERM(GPIO_23, 1, DEEP, DN_20K, TxLASTRxE, + SAME), /// Feature: LB USB Power in LFH }; diff --git a/src/mainboard/intel/leafhill/leafhill.16384.fmd b/src/mainboard/intel/leafhill/leafhill.16384.fmd index a91ba9a6d85..7feddef49e0 100644 --- a/src/mainboard/intel/leafhill/leafhill.16384.fmd +++ b/src/mainboard/intel/leafhill/leafhill.16384.fmd @@ -1,14 +1,10 @@ -FLASH 16M { +FLASH@0xff000000 0x1000000 { SI_DESC@0x0 0x1000 - IFWI@0x1000 0x2ff000 - FMAP@0x300000 0x800 - COREBOOT(CBFS)@0x300800 0xc1d800 - UNIFIED_MRC_CACHE@0xf1e000 0x21000 { - RECOVERY_MRC_CACHE@0x0 0x10000 - RW_MRC_CACHE@0x10000 0x10000 - RW_VAR_MRC_CACHE@0x20000 0x1000 + SI_BIOS@0x1000 0x6fe000 { + IFWI@0x0 0x2ff000 + RW_MRC_CACHE@0x2ff000 0x10000 + SMMSTORE@0x30f000 0x40000 + FMAP@0x34f000 0x800 + COREBOOT(CBFS)@0x34f800 0x36b800 } - BIOS_UNUSABLE@0xf3f000 0x40000 - DEVICE_EXTENSION@0xf7f000 0x7f000 - UNUSED_HOLE@0xfff000 0x1000 } -- Kind regards, Corvin

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 14 Feb '25

14 Feb '25

Dear coreboot Community, We are pleased to announce that our next leadership meeting is scheduled for February 19, 2025. [1] Please update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Should I keep File #4491 open?
by Rob Brown 13 Feb '25

13 Feb '25

I wanted to follow up on your Hybrid LOC soft-approval for $264,822, starting at 6.42%. If you’re still considering funding, I’d love to connect and go over the details before activation. If anything has changed on your end or if you’d like to adjust the terms, just let me know - I may be able to secure better options based on updated financials. Let me know if you have time today or tomorrow for a quick call, or you can book a time here: calendly.com/rbrown-quickloanpartners/30min http://go.pardot.com/e/1091063/rbrown-quickloanpartners-30min/95n3s3/153884… . Looking forward to your thoughts! Sincerely, Robert Brown Account Executive Phone: (714) 804-0441 tel:+17148040441 Email: rbrown(a)quickloanpartner.com mailto:rbrown@quickloanpartner.com http://go.pardot.com/e/1091063/2025-02-13/95n3s6/1538844875/h/4ZtBkpz7sXrJK… 2050 North Tustin Ave. #1104 Orange, CA 92865 Fund TODAY by completing our online app! This email and any attachments are intended solely for the named recipient(s) and may contain confidential or proprietary information. Any unauthorized use, disclosure, copying, or distribution is strictly prohibited. If you believe you have received this email in error, please notify the sender immediately by replying to this email and delete it permanently from your system. We respect your privacy and do not sell or share your personal data with third parties. If you wish to stop receiving any communications from us, please click here http://go.pardot.com/unsubscribe/u/1091063/a89266a5d0e84252d8ce1d180c65e002… .

1 0

2025_02_12 coreboot Group Review Sesssion
by mina＠coreboot.org 10 Feb '25

10 Feb '25

Hello coreboot! Our upcoming biweekly group review session is scheduled for Wednesday, February 12, 2025. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

Coreboot + Tianocore on ThinkPad T480
by Jyber 10 Feb '25

10 Feb '25

Hi everyone, I’m looking to install Coreboot with Tianocore as UEFI payload on my ThinkPad T480. Is there a detailed guide or installation instructions available? If anyone has experience with this, I’d appreciate any tips! Thanks in advance!

1 0

About: "Free hardware"; Servers
by p db 10 Feb '25

10 Feb '25

Dear Coreboot, I am searching from different time, information about "Free hardware"; Servers, hardware that can be considerated "Ethic"; which supports 'Coreboot"; that has respect for the surrounding environment, which consumes little electricity and at the same time produces little Co2 " Carbon Dioxide", on which it is possible to install a Gnu/linux distribution, of those recognized as 100% Free Software by the Free Software Foundation, https://www.gnu.org/distros/free-distros.en.html as is possible dedicate space of the hard disk to the Gnu/Hurd operating system! Actually i know the "Silicon Mechanics", but i don't know, which models can support "coreboot", if anyone knows such other name, and that is "Ethic" and has support for "coreboot", is free to suggest the name and the model. Awaiting your reply, Best Regards, Paolo Del Bene [PdB71]

1 0

looking for cheap fw box with coreboot support
by Eero Volotinen 09 Feb '25

09 Feb '25

Hi, Is there any cheap firewall box at aliexpress that can support coreboot? Eero

4 5

Re: coreboot Digest, Vol 239, Issue 8
by Keith Hui 06 Feb '25

06 Feb '25

(I strongly suggest community members from US not respond for sanction concerns.) I am not too deep into the coreboot build system either, but I can tell you that what you changed is part of SeaBIOS payload, which the coreboot build brings in fresh every time you compile. This is not part of coreboot per se, and because it is brought in fresh each time, no wonder your changes are getting lost. You'll want to get the SeaBIOS sources yourself, make changes, build a binary, and insert it as a binary payload, instead of selecting SeaBIOS as your payload. I am a student from tehran university in iran and I am interested to > booting system's and I research in this field > I compiled compiled and build your project in the qemu and run > successfully but i have problem if i want to changing message that show in > the qemu. > > for this I changing some printf() function in file > /coreboot/payloads/external/Seabios/seabios/src/boot.c > and then commit this changing and use make to recompiling project but > nothing changing and then use "make clean " for deleting all the compiled > file and recompile all of the project again by "make" and after this i see > all of the my changing in the > /coreboot/payloads/external/Seabios/seabios/src/boot.c is deleted and even > my git commited is deleted . > > how build system work this happens? > > how to solve this problem and changing the massage in the qemu terminal? > > and please explain to me source for this subject (i search in coreboot > documentation but i can't find proper source) > > With respect and apologies for any English grammatical errors in the text. > Regards Keith >

1 0

2025-02-05 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 06 Feb '25

06 Feb '25

# 2025-02-05 - coreboot Leadership Meeting ## Attendees Felix Held, Jay Talbott, Julius Werner, Andy Ebrahiem, Martin Roth, Maximilian Brune, Matt DeVillier, Christian Walter, Andre, Mina Asante, David Hendricks, Alicja Michalska, Jon Murphy, Jeremy Compostella, Elyes. ## Open Action Items * 2024-11-27 * Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches.” * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Elyes] coreboot toolchain and/or Jenkins malfunction * There is something wrong with the coreboot toolchain and/or Jenkins. Here, (https://review.coreboot.org/c/coreboot/+/86100), I'm expecting the build to fail, at least getting this error: "error: initializer-string for array of 'char' is too long"! And here, (https://review.coreboot.org/c/coreboot/+/86012), it looks like Jenkins is mixing GCC versions! So, what is the plan? * I can understand adding support for a library that can be used by coreboot, as seen here(https://review.coreboot.org/c/coreboot/+/80737), but I'm having trouble understanding the purpose of adding LIBSTDCXX. Unless I'm mistaken, this library is not used in coreboot. What is the strategy of coreboot after this add and that of 'go' here (https://review.coreboot.org/c/coreboot/+/63639)? * To give some more background: * During the creation of the patch there was talk about the US government making SBOMs mandatory at some point (not sure what the current status is). * The go dependency was already there although to be fair it was only present in tooling (intel-sec-tools) as far as I know. We had multiple long talks (also in the leadership meeting) about adding go as a dependency into the coreboot build system. As far as I know we agreed on letting it into the coreboot build system because it was an optional dependency. * We worked with [https://fwupd.org/](https://fwupd.org/) together to facilitate SBOM as part of Firmware updates. More specifically you can see SBOM information on their web interface when you look at the Firmware updates. I haven’t looked at it for a while now, so I am not sure about the current status. * Isn’t that only an ABI for aarch64? According to the content of the patch it is removing the riscv abi (although the title mentions aarch64). * Rv32 is used by one of our emulation targets (src/mainboard/emulation/qemu-riscv) ### [Martin] Someone mentioned that GitHub isn't being synced anymore. * Felix S. already handled this? Need to double-check. ### [Alicja] Release notes status? ### [Martin] Adding IT support (reducing the "bus" factor) * Need someone knowledgeable in NixOS and our infra (Jenkins, Gerrit, Docker, etc) * Max has a potential candidate who can help. * We're happy to use some coreboot funds to do admin duties and document everything. * [Max] Toolchain is a significant maintenance burden. There are other projects out there, maybe we can utilize another project's toolchain (or merge?) so we don't shoulder the entire burden. * [Martin] For now the plan is to just split it into a separate module. We only update the toolchain 4x per year, and probably don't need to do it that often. * Splitting would allow us to test it separately from coreboot. We do toolchain builds but don't stress test the toolchain itself beyond "does it build?" * Splitting would make it easier to update - if people want more frequent updates, then that would be fine. * [Jon] This is also what ChromeOS does, for the above reasons. * [Max] Do we want all of our payloads to compile using coreboot's toolchain? * [Martin] We can try this out to see what's needed to support different payloads. * [David] It's nice, but not required. When we started LinuxBoot, we were using the coreboot toolchain since ARM64 was one of the early targets and doing the usual cross-toolchain setup was a pain outside of coreboot. * [Martin] Will look at adding build tests in Jenkins; can't promise to fix anything. * Having the latest working toolchain version is valuable info, even if the more recent toolchains fail. # Next Leadership Meeting * February 19, 2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course, items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Help me understand more about coreboot
by sourabadi 05 Feb '25

05 Feb '25

Hello I am a student from tehran university in iran and I am interested to booting system's and I research in this field I compiled compiled and build your project in the qemu and run successfully but i have problem if i want to changing message that show in the qemu. for this I changing some printf() function in file /coreboot/payloads/external/Seabios/seabios/src/boot.c and then commit this changing and use make to recompiling project but nothing changing and then use "make clean " for deleting all the compiled file and recompile all of the project again by "make" and after this i see all of the my changing in the /coreboot/payloads/external/Seabios/seabios/src/boot.c is deleted and even my git commited is deleted . how build system work this happens? how to solve this problem and changing the massage in the qemu terminal? and please explain to me source for this subject (i search in coreboot documentation but i can't find proper source) With respect and apologies for any English grammatical errors in the text.

2 1

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 03 Feb '25

03 Feb '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, February 5, 2025. [1] Kindly review the agenda and share your thoughts or suggest additional items you would like to discuss during the meeting. [2] Thank you. ## Current Agenda Items ### [Elyes] coreboot toolchain and/or Jenkins malfunction * There is something wrong with the coreboot toolchain and/or Jenkins. Here, (https://review.coreboot.org/c/coreboot/+/86100), I'm expecting the build to fail, at least getting this error: "error: initializer-string for array of 'char' is too long"! And here, (https://review.coreboot.org/c/coreboot/+/86012), it looks like Jenkins is mixing GCC versions! So, what is the plan? * I can understand adding support for a library that can be used by coreboot, as seen here(https://review.coreboot.org/c/coreboot/+/80737), but I'm having trouble understanding the purpose of adding LIBSTDCXX. Unless I'm mistaken, this library is not used in coreboot. What is the strategy of coreboot after this add and that of 'go' here? (https://review.coreboot.org/c/coreboot/+/63639) ? * GCC-15 deprecates support for ILP32 (-mabi=ilp32). If I'm not mistaken, RV32 is not used in coreboot tree. Should we remove it? (see (https://review.coreboot.org/c/coreboot/+/86053) ) [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 31 Jan '25

31 Jan '25

Dear coreboot Community, We are pleased to announce that our next leadership meeting is scheduled for February 5, 2025. [1] Please update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #576] (New) GPIO locking is broken on Kaby Lake and possibly other platforms
by Mate Kukri 30 Jan '25

30 Jan '25

Issue #576 has been reported by Mate Kukri. ---------------------------------------- Bug #576: GPIO locking is broken on Kaby Lake and possibly other platforms https://ticket.coreboot.org/issues/576 * Author: Mate Kukri * Status: New * Priority: Normal * Target version: none * Start date: 2025-01-30 ---------------------------------------- Many supported Kaby Lake boards (and possibly newer platforms as well) are vulnerable to [TPM GPIO reset attacks](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html). Trying to fix this by marking the affected GPIOs as locked in gpio.h and even also selecting `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` does not work. This was discovered last year and briefly discussed on #coreboot, but it came up again on the Heads matrix group in relation to supporting the TPM on the in-progress ThinkPad T480 port. -- 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

Help me push coreboot's envelope on Asus P8Z77-V
by Keith Hui 29 Jan '25

29 Jan '25

Hello all, Doing some work with (Bill's) Asus P8Z77-V board and running into some issues and limits. See it unfold at https://review.coreboot.org/c/coreboot/+/85413 That said, I've run into a few issues and limits trying to bring feature parity to it. It will also help me with porting coreboot to two more boards in the family: P8Z77-V LE PLUS and Sabertooth Z77. A patch has been sent for Sabertooth and I have one on the way maybe early next month - it needs a cap replaced, maybe more. The other board is on hand and a patch is being prepared. I'll put in as much as I can get working before sending it in. #1. Bill has been testing this patch (thanks!) with PCH soft strap #9 configured to have all lanes as x1. Actual routing is controlled by 3 GPIO lines from the super I/O, and it has card presence lines wired to the PCH. I got both working, but Bill still couldn't get his card to work on one of the two x1 slots. I need more fresh eyes to help. #2. Changing flash descriptor from within coreboot. I've come to a point where I need to be able to change the PCH soft straps based on user selection. As you can see in 85413, and in consultation with Nicholas (that convo is also on this list), to make it fully work I need to be able to change the otherwise read-only soft strap #9 in the flash descriptor, and it appears Asus is doing it as well. I know about SPI console - I actually used it during early attempts of porting my P8Z77-M - but I have not dealt with writing to the SPI from within coreboot nor have I studied SPI console deep enough to be able to come up with code of my own. 7-series PCH supports hardware sequencing if the SPI flash chip meets certain requirements. Does it mean I can just write() to the memory area mapped for SPI flash, and it fires the SPI commands for me? Will it do sector erase on my behalf and preserve what's not being overwritten? Nicholas mentioned some Haswell boards also need this done. Would love to hear some progress there. #3. Dynamic device tree? There will be times when the devicetree needs to change based on user selection. Not necessarily nvram options, but also choices made in 'make menuconfig'. In my efforts they are respectively enabling/disabling PCIe root ports 2-4 (based on whether port 1 is set for x4) and enabling the SIO serial port on Sabertooth if the user enables the "hacked serial port" in Kconfig. Devicetrees are supposed to be static, I get this. Where are the runtime hooks where code can go in and say "nope, this device is off"? Many thanks Keith

2 1

2025_01_29 coreboot Group Review Sesssion
by mina＠coreboot.org 27 Jan '25

27 Jan '25

Hello coreboot! Our upcoming biweekly group review meeting is scheduled for Wednesday, January 29. https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

2025-01-22 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 23 Jan '25

23 Jan '25

# 2025-01-22 - coreboot Leadership Meeting ## Attendees Felix Singer, Andre, Mina Asante, Werner Zeh, Felix Held, Jay Talbott, Maximilian Brune, Matt DeVillier, David Hendricks, Julius Werner, Alicja Michalska, Karthik R, Jon Murphy, Jeremy Compostella. ## Open Action Items * 2024-11-27 * Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Werner] What is the guidance for the length of the first commit line? * We used to have a Wiki entry for that which I have ported over to our new documentation (see [CB:85915](https://review.coreboot.org/c/coreboot/+/85915)). Shall we still stick with 65 (max 75) characters, or shall we adjust? A quick [survey](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thr… on the mailing list did not reveal any path forward. * [FelixH] 72 chars is used to prevent line breaks when the commit is formatted for e-mail. * [David/Matt] Subject lines often have long paths (as mentioned by others). We should have some guidelines and examples on how to keep this small (what part of the path to mention, acceptable abbreviations for "mainboard", "common", etc) so as to avoid over-crowding the subject line. ### [Werner] Our documentation website (doc.coreboot.org) seems still not to be updated periodically. Is there something we need to do? * [FelixS] Documentation is currently built weekly by a cron job. It's a hacky solution intended to help with migration from old server to new one. Future plan is to have documentation built by CI. * [Matt] Can we increase frequency of cron job? * [FelixS] Yes, that should be possible. * We'll increase it to once per day ### [Werner] Intel has some plans around signing their FSP binaries and would like to present details to the community some day. * Can we offer a dedicated call for that with a broader representation of the community? Or shall we just do it in one of the regular Wednesday-Calls? * [Max/Felix] We probably don't need another meeting. Someone from Intel can just bring it to this one. * [FelixH] What validates signatures? Do we not own the reset vector on Intel platforms anymore? * [David] It seems like a good thing if signature validation is optional. If it's mandatory and enforced by ME or something then that will be terrible since it will cripple portability to other platforms. Can't use a validated Intel binary from a BKC in a new product, for example, and people with FSP source code won't be able to build and run it on a validated Intel platform (CRB). * [Alicja] What is the justification? This will negatively impact debuggability. * Alicja: The first answer was "security". The second answer is to reduce the number of issues due to customized FSP binaries out there. ### [Werner] Our last release 24.12 seems stuck (behind schedule). Anything we can do about it? * [FelixS] It's ready, we just need to update the blog. Tag was created. * But there is some issue - `git describe` shows 24.08. Maybe it's not annotated? # Next Leadership Meeting * February 5, 2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course, items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 21 Jan '25

21 Jan '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for tomorrow, January 22, 2025. [1] Kindly review the agenda and share your thoughts or suggest additional items you would like to discuss during the meeting. [2] Thank you. ## Current Agenda Items ### [Werner] What is the guidance for the length of the first commit line? * We used to have a Wiki entry for that, which I have ported over to our new documentation (see [CB:85915](https://review.coreboot.org/c/coreboot/+/85915)). Shall we still stick with 65 (max 75) characters or shall we adjust? ### [Werner] Our documentation website (doc.coreboot.org) seems still not to be updated periodically. Is there something we need to do? ### [Werner] Intel has some plans around signing their FSP binaries and would like to present details to the community some day. * Can we offer a dedicated call for that with a broader representation of the community? Or shall we just do it in one of the regular Wednesday-Calls? [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Farewell to coreboot community
by LEAN SHENG TAN 21 Jan '25

21 Jan '25

Hi all, Couldn’t leave without saying goodbye to the open source community which I spent the most time mingling besides my previous company work. As many of you already know, I left the firmware field and thus 9elements to pursue my own startup. What a bizarre community with many interesting and great people, who I have grown to know many of you personally throughout the journey. In the end, I wish for the best of coreboot from the bottom of my heart, and hopefully it will be the de-factor firmware standard for providing much better quality and services compared to the existing solutions… Firmware world is a mess, and the introduction of coreboot came in as a spring water flows in some of very best devices in the world, and it just boot without much complications! Firmware should be simple and free the users from proprietary control!!! Always believed in coreboot, and will always vouch for you all :) Thank you for creating a very welcoming open source community that I had a lot of fun (and also some hard) times with ;) Best Regards, Sheng P.S: Any coreboot forks (whatever you called it Masharo or Pipapo), please pay your due in upstreaming your changes back to the main coreboot branch - especially for those companies who are having good profits (you know who you are) but refuse to actively contributing back to the community: maybe I will still come after you if I have too much free time; unless be a good boy and stop leaching for greed and profits, after all you are taking big advantage of the hard work from all the community members. Have some dignity.

4 5

Re: Two devicetree questions and two use cases
by Keith Hui 18 Jan '25

18 Jan '25

Hi Nicholas, Thanks for the reply, and the scoop, and pardon my second email to the list that essentially asked the same question again. The hidden register would be a boon to my goals. I have an Asus P8Z77-V LE Plus board on order that I will soon be able to test the idea on, since it is one of those boards with more devices than PCIe lanes. It is part of my plan to bring coreboot to all the P8x7x boards. Towards that goal there are a few patches I'm looking to get in such as CB:82556,82557,85834, and am still looking for volunteers to boot test my as yet incomplete ports. Cheers Keith > > Hi Keith, > > I can't speak to the devicetree stuff, but I did find something > interesting regarding the PCH PCIe ports: > > > p8z77-v and sabertooth_z77 have a third PCIe x4 slot serviced by the > > PCH, but the 4 lanes are shared with some other x1 slots and devices. > > They can configure the PCIe x4 slot to really be x4, or the 4 lanes > > can be configured as 4 x1 ports for various x1 slots or onboard > > devices. This requires changing a soft strap as well as manipulating > > some GPIOs in the SIO chip, and the devicetree changed to match. I > > have the SIO GPIO part figured out, the soft strap I can only come to > > one possible explanation: reflash SPI descriptor with the changed soft > > strap and force a platform reset. To verify I'll need to get a board > > and actually check the flash chip for changes. > > Changing the IFD at runtime seems like an impractical way to achieve > this, especially since the IFD is normally supposed to be read only. I > suspect there's another, undocumented method to change the > configuration. On ICH/PCH datasheets, there is an RCBA register (Root > Port Configuration Register) that indicates the current port > configuration. On the 7 series PCH's, that is at RCBA32(0x400), bits 3:2 > for ports 5-8 and bits 1:0 for ports 1:4. However, these bitfields are > documented as read only in the public datasheets. However, in the public > ICH9 datasheet (and seemingly only the ICH9 datasheet; other datasheets > like ICH7, ICH8, ICH10, etc don't have this detail) the equivalent > register at RCBA32(0x224) lists the bitfields as R/W, with a note saying > that writing to them is for debug/testing and should be treated as read > only and modifiable only through hard straps (it seems like ICH9 didn't > use IFD soft straps for this). Based on that note, I assume this > mechanism is intended for testing different PCH PCIe configurations > without reflashing the IFD. I haven't tested this yet on any platform > but it does seem plausible that this mechanism exists on chipsets other > than ICH9. > > Cheers, > Nicholas > > >

2 4

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 17 Jan '25

17 Jan '25

Dear coreboot Community, We are pleased to announce that we have an upcoming leadership meeting scheduled for January 22, 2025. [1] Please update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Reviewers for src/soc/intel/
by Compostella, Jeremy 16 Jan '25

16 Jan '25

Hi, I do not know who I should talk to so I am going to leverage the mailing list. I have been wondering: why have I not been looped in the review [85827 soc/intel/pantherlake: Refactor FSP-M params for debug message control]. I looked at the `MAINTAINERS' file and I found the following related definitions. ,---- | INTEL SUPPORT | R: Intel_Coreboot_Reviewers <intel_coreboot_reviewers(a)intel.com> | S: Maintained | F: src/vendorcode/intel/ | F: src/cpu/intel/ | F: src/northbridge/intel/ | F: src/southbridge/intel/ | F: src/soc/intel/ | F: src/drivers/intel/ | F: src/include/cpu/intel/ | [...] | INTEL PANTHERLAKE SOC | M: Subrata Banik <subratabanik(a)google.com> | M: Kapil Porwal <kapilporwal(a)google.com> | M: Pranava Y N <pranavayn(a)google.com> | S: Maintained | F: src/soc/intel/pantherlake/ `---- I am part of the Intel_Coreboot_Reviewers <intel_coreboot_reviewers(a)intel.com> mailing list but I do not see *Intel_Coreboot_Reviewers* added to the CC section in gerrit which probably explain why I did not get any email. Our goal is to have Intel folks of this mailing list as reviewers of all the src/soc/intel/... changes. How can we achieve that ? Regards, -- *Jeremy* /One Emacs to rule them all/ [85827 soc/intel/pantherlake: Refactor FSP-M params for debug message control] <https://review.coreboot.org/c/coreboot/+/85827>

2 7

Review session
by Maximilian Brune 15 Jan '25

15 Jan '25

Hello fellow coreboot engineers, I feel like I need to point out that the attendance of the review session is becoming rather poorly. I think the idea of the review session meeting is very nice, but it doesn't work if no one attends. The current attendance is usually 3 people of which 2 are fairly new in the project (1 year max) and have no +2 rights. That makes the meeting essentially pointless. I myself also don't always join the meeting, but I try to join if I can. I know everyone is doing this on a voluntary basis and even if I want to force you to join I sadly can't, because free will seems to become popular these days. Nevertheless I hope some of you can free up some time (doesn't have to be for the whole meeting) in the future. love you all Max

1 0

2025_01_15 coreboot Group Review Sesssion
by mina＠coreboot.org 14 Jan '25

14 Jan '25

Hello coreboot! We are pleased to announce that our upcoming review session is scheduled for tomorrow, January 15, 2025, at 10:00 AM Pacific Time: https://meet.google.com/kpu-yozw-gtt As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

Looking for more pairs of eyes, reviewers, for a Rust port of bios_extract
by Idwer Vollering 13 Jan '25

13 Jan '25

Hi, I'm porting bios_extract to Rust. This is an equally serious endeavour as it is a learning project. The port is halfway finished when it would handle PhoenixBIOS binaries, this is the part where I am stuck and would like to receive review. Award, AMI, binaries should work or mostly work, I could not find enough binaries to test with. What needs to be done, can be fixed later. Running `cargo clippy` is on the (mental) todo list. https://review.coreboot.org/c/bios_extract/+/84226

1 0

2025-01-08 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 09 Jan '25

09 Jan '25

# 2025-01-08 - coreboot Leadership Meeting ## Attendees Mina Asante, Saulo Silva, Felix Singer, Christian Walter, Andre, Maximilian Brune, Jay Talbott, Julius Werner, Matt DeVillier, Werner Zeh, Andy Ebrahiem, David Hendricks, Martin Roth, Alicja Michalska, Jeremy Compostella. ## Open Action Items * 2024-11-27 * Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian(?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ## [Sheng/Chris] Promote Liu Shuo to be core developer * He has shown great progress in leading and helping coreboot Xeon patches together with the community * Stats for the past 2 years: Commits: 96 (10th most commits overall) Reviews: 139 Comments: 118 * Worked together with community to upstream GNR patches and cleaned up many Eagle Stream coreboot mess * Able to address most of reviewers feedback and make the code better, understand coreboot practices, and also produces patches with good code quality. * Author of (https://community.intel.com/t5/Blogs/Tech-Innovation/Data-Center/Advancing-…) * Will have bigger responsibility to maintain and drive the Xeon coreboot works. * There have been no objections. * Decision: Liu Shuo has been promoted as a core developer. ### [Martin] How do we want to handle platforms that don’t have a public FSP/openSIL or other binaries. * We definitely don’t want to make it mandatory to have the binaries available to have the code in the coreboot repo. * We could make a blog post listing platforms that don’t have a public FSP and request that something be released. ### [Alicja] Plans to have a new mainboard porting guide later this month ### [Alijca] Refactor fallback mechanism to use more modern parts of vboot. * [David] We've had a fallback mechanism since early on, however it may be stale by now e.g. due to usage of CMOS variables and whatnot. A more modern approach that removes any dependency on things like counters maintained in certain types of memory would be nice, similar to vboot itself which was designed to not rely on any specific implementation from silicon vendors. # Next Leadership Meeting * January 22,2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Sane length for the first commit message line in documentation
by Zeh, Werner 09 Jan '25

09 Jan '25

Hi all. Recently it was brought to my attention that there is a dead link [1] in our documentation (commit message guidelines [2]). After having a look and asking around it turned out that it currently points to the old wiki which is finally offline, hence the dead link. I have created a patch to re-write the old content from the wiki in [3]. So far this is more or less a rewrite of what has been there in the old wiki with some additions from me. One review comment is that the mentioned limits for the line length of the first commit message might not be sufficient anymore. There it stated that the first line should be less than 65 characters or absolute maximum 75. Shall we adjust this length now that we are having this commit message guideline available again in our docs? Limiting to a too low number might lead to struggles when writing a meaningful description with the prefixed file path. Having too big numbers here might make it hard to read on consoles and even in Gerrit. Any thoughts on the new limits? Or are the ones mentioned there still fine? Your input is valuable. Thanks Werner [1] https://www.coreboot.org/Git#Commit_messages [2] https://doc.coreboot.org/contributing/gerrit_guidelines.html#recommendations -for-gerrit-activity [3] https://review.coreboot.org/c/coreboot/+/85915

2 2

Q: Can I modify PCH soft straps from bootblock?
by Keith Hui 09 Jan '25

09 Jan '25

All, A use case for the title is beginning to emerge for a number of Asus P8x7x boards. For example: https://review.coreboot.org/c/coreboot/+/85413 and https://review.coreboot.org/c/coreboot/+/85768 Many standard ATX boards in the family have more peripherals than the 8 PCIe lanes available out of the PCH, so some are structured to share 3 of the 4 PCIe lanes originally earmarked for an x4 slot. They do this with a number of 2-way PCIe switches (specifically ASM1440 - no datasheet, but I figured out the pinout, only thing I don't know is the polarity of the control signal) controlled by GPIOs either on the super I/O or the PCH. With vendor firmware this is an option that can be configured from UEFI setup itself. I can handle GPIOs fine, but stealing lanes from an x4 slot requires changing a soft strap to reconfigure lanes 1-4 from one x4 port to four x1 ports. The only strategy I can see work is flash a modified soft strap to the descriptor, during bootblock before PCI bus scan happens and before SPI is locked down, trigger a full platform reset (eg. outb(0xe, 0xcf9)) , then program the GPIOs to match the updated soft strap. Has this been done before in coreboot so there is code I can lift? Thanks Keith

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 06 Jan '25

06 Jan '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, January 8, 2025. [1] Kindly update the agenda with matters you wish to see addressed during the meeting. [2] ## Current Agenda Items ### [Sheng/Chris] Promote Liu Shuo to be core developer * He has shown great progress in leading and helping coreboot Xeon patches together with the community * Stats for the past 2 years: Commits: 96 (10th most commits overall) Reviews: 139 Comments: 118 * Worked together with community to upstream GNR patches and cleaned up many Eagle Stream coreboot mess * Able to address most of reviewers feedback and make the code better, understand coreboot practices, and also produces patches with good code quality. * Author of (https://community.intel.com/t5/Blogs/Tech-Innovation/Data-Center/Advancing-…) * Will have bigger responsibility to maintain and drive the Xeon coreboot works. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 03 Jan '25

03 Jan '25

Dear coreboot Community, We are pleased to announce that we have an upcoming leadership meeting scheduled for January 8, 2025. [1] Please update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Two devicetree questions and two use cases
by Keith Hui 27 Dec '24

27 Dec '24

My question is pretty much as title. I'll explain my use cases below. 1. https://review.coreboot.org/c/coreboot/+/82633 With this patch, I'm still getting leftover devices messages in the log for devices 0:1.1 and 0:1.2. This is with no card plugged into the PCIe x16 slot. As far as I can tell those devices are for when the Ivy Bridge CPU's PCIe lanes have to run in x8 or x4 mode. I don't know what device 0:4.0 is for. 0:6.0 is for the extra 4 PCIe lanes for Xeon CPUs. None of the Asus P8x7x series boards have them wired up. So is there a way for me to "remove" the latter two devices from chipset.cb with the mainboard devicetree.cb, or do I have to hide them like I did in the patch? How do I completely get rid of leftover devices? 2. https://review.coreboot.org/c/coreboot/+/85413 and https://review.coreboot.org/c/coreboot/+/85768 These boards, as well as p8z77-m_pro (likely any standard ATX board in this family), have one x16 slot and one x8 slot that are both serviced by the 16 PCIe lanes out of the CPU. The card presence pin on the x8 slot activates a CPU hard strap and enables bifurcation, as well as configures a bunch of PCIe mux/switches to send the bifurcated lanes to the x8 slot. Together they reconfigure the CPU's PCIe lanes into two x8 slots. But wait, there's more. p8z77-v and sabertooth_z77 have a third PCIe x4 slot serviced by the PCH, but the 4 lanes are shared with some other x1 slots and devices. They can configure the PCIe x4 slot to really be x4, or the 4 lanes can be configured as 4 x1 ports for various x1 slots or onboard devices. This requires changing a soft strap as well as manipulating some GPIOs in the SIO chip, and the devicetree changed to match. I have the SIO GPIO part figured out, the soft strap I can only come to one possible explanation: reflash SPI descriptor with the changed soft strap and force a platform reset. To verify I'll need to get a board and actually check the flash chip for changes. But how do I manage the devicetree dynamically? Say for sabertooth I'll want to turn on PCH PCIe root port 1 only if it is set for x4, otherwise I'll need all ports 1-4 on so its three PCIe x1 slots can work along with the x4 slot now being x1 only. Thanks Keith

2 1

Calling all Asus P8x7x board owners, and Q about NCT5535D
by Keith Hui 24 Dec '24

24 Dec '24

Hello, I recently got my hands on boardviews of many Asus P8x7x series mainboards, and some offshoots such as Z77-A and Sabertooth Z77, and have also found a way to extract VBT data and the USB port config out of the vendor firmware image (which isn't really a straight image, but what looks like an update capsule), allowing me to attempt something quite ambitious given I only have the P8Z77-M on hand: Bring coreboot to the entire family. Again because I only have the vendor firmware image and boardview to go by, I will only be able to put out an untested new board patch, hence I am calling for anyone with these boards, that aren't already in the tree, to help me test them, and to get things I can't get out of firmware image, such as HDA verbs and GPIO setup, by running autoport on your board. Additionally, if you have a P8Z77-V (Hello Bill!), please test this patch: https://review.coreboot.org/c/coreboot/+/85413 And if you have a P8Z77-M PRO, please test your serial port, and if changing it to use serial port A like P8Z77-M does, make the serial port work. Now, during my survey of the board family, I found that: 1. They link their power LEDs to only one of two GPIOs on the PCH: 8 or 27. That's easily determined from the boardview. 2. Except for P8C WS which I can't get a boardview for, this family only uses one of two Nuvoton super I/Os: NCT5535D or NCT6779D. 6779 is well known, but I cannot find the datasheet for 5535, and the pinout for the closest thing I can find, NCT5532D, have the pins shifted by approximately 3 pins, and there may be more differences. Does anyone know anything about NCT5535D or can hook me up with a datasheet? Thanks Keith

2 2

2024-12-25 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 23 Dec '24

23 Dec '24

Hello coreboot, Please note that the leadership meeting scheduled for Wednesday, December 25, 2024, has been canceled as it falls on Christmas Day. Thank you for your understanding, and I wish you a joyous and merry Christmas. Best regards, Mina.

1 0

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

18 Dec '24

Issue #121 has been updated by Anastasios Koutian. Anastasios Koutian wrote in #note-100: > Have been using this change: https://review.coreboot.org/c/coreboot/+/78609 since it was merged (May 23) and haven't seen any freezes. > It's possible that this solves the issue. Can others confirm? Still no freezes since. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1995 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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 #574] (New) Stack corruption in romstage on Intel platform (ADL-N) with recent builds
by Alicja Michalska 17 Dec '24

17 Dec '24

Issue #574 has been reported by Alicja Michalska. ---------------------------------------- Bug #574: Stack corruption in romstage on Intel platform (ADL-N) with recent builds https://ticket.coreboot.org/issues/574 * Author: Alicja Michalska * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2024-12-17 * Affected versions: master ---------------------------------------- While building from master (testing CB:85609), I've noticed CBMEM complaining about stack corruption. Older build made a ~month ago did not experience the same issue. Maybe caused by Xeon-SP refactoring? `[INFO ] CBFS: Found 'fallback/romstage' @0x21d40 size 0x11c28 in mcache @0xfef8c28c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 465 ms [NOTE ] coreboot-24.08-922-gf9b4c5a996dc-dirty Mon Dec 16 23:28:48 UTC 2024 x86_32 romstage starting (log level: 8)... [ERROR] Stack corruption detected at eip: 0xffc74870 [DEBUG] pm1_sts: 0000 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 0000 [DEBUG] GEN_PMCON: d8a01a78 00002200 [DEBUG] GBLRST_CAUSE: 00000002 00000000 [DEBUG] HPR_CAUSE0: 00000002 [DEBUG] prev_sleep_state 0 (S0) [INFO ] OC Watchdog: disabling watchdog timer [DEBUG] Abort disabling TXT, as CPU is not TXT capable. [SPEW ] CBFS DEBUG: _cbfs_alloc(name='fspm.bin', alloc=0x00000000(0xfef87e98), force_ro=false, type=-1) [DEBUG] FMAP: area COREBOOT found @ c50200 (3866112 bytes) [INFO ] Fixed Decode Window: SPI flash base=0x600000, Host base=0xff600000, Size=0xa00000 [INFO ] CBFS: Found 'fspm.bin' @0x58dc0 size 0xc0000 in mcache @0xfef8c414 [DEBUG] FMAP: area RW_MRC_CACHE found @ c00000 (65536 bytes) [SPEW ] MRC cache found, size 63176 bytes [SPEW ] bootmode is set to: 2 (boot assuming no config change)` -- 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

2024_12_18 coreboot Group Review Sesssion
by mina＠coreboot.org 16 Dec '24

16 Dec '24

Hello coreboot! We are pleased to announce that our upcoming review session is scheduled for Wednesday, December 18, 2024: https://meet.google.com/kpu-yozw-gtt As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

[coreboot - Support #571] (New) Keyboard scan codes of HP Elitebook 2170p under coreboot are different with those under oem firmware.
by Wreg Yek 16 Dec '24

16 Dec '24

Issue #571 has been reported by Wreg Yek. ---------------------------------------- Support #571: Keyboard scan codes of HP Elitebook 2170p under coreboot are different with those under oem firmware. https://ticket.coreboot.org/issues/571 * Author: Wreg Yek * Status: New * Priority: Normal * Target version: none * Start date: 2024-11-23 * Affected hardware: HP Elitebook 2170p * Affected OS: GNU/Linux with systemd v257-rc1 or later ---------------------------------------- HP Elitebook 2170p is weird compared with many other Elitebooks supported by coreboot, for its keyboard scan codes under coreboot is different with those under oem firmware, regardless of the same set of EC firmware blobs are used. The scan codes under oem firmware conform to the upstream [60-keyboard.hwdb](https://github.com/systemd/systemd/blob/main/hwdb.d/60-ke…, while after systemd v257-rc1, the `KEYBOARD_KEY_66=pickup_phone` within [upstream](https://github.com/systemd/systemd/commit/93b078c3dd40b10eed34a77… 60-keyboard.hwdb starts to conflict with the scan codes of backspace key under coreboot, where it is 0x66. Besides backspace, I have collected the scan codes of all Fn-keys under coreboot into the attached 61-2170p-kb.hwdb, which is adjusted to the default SMBIOS tables of coreboot for Elitebook 2170p, and could be used to walk around the scan code conflict. ---Files-------------------------------- 61-2170p-kb.hwdb (508 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

2 7

2024-12-11- coreboot Leadership Meeting Minutes
by mina＠coreboot.org 12 Dec '24

12 Dec '24

# 2024-12-11- coreboot Leadership Meeting ## Attendees Felix Singer, Jon Murphy, David Hendricks, Mina Asante, Werner Zeh, Matt DeVillier, Jay Talbott, Julius Werner, Maximilian Brune, Andre, Alicja Michalska, Karthik, Felix Held, Jeremy Compostella, Christian Walter. ## Announcements & Events * coreboot 24.12 release tag scheduled for December 18. * Please mark patches you want merged before the release with the hashtag “coreboot_release_2412”. * Patches which need to be merged afterwards (e.g. toolchain related) are marked with the hashtag “coreboot_post_release_2412”. ## Open Action Items * 2024-11-27 * Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### Chaos Computer Congress 38 * Felix Singer, Alicja Michalska, and others will be there * (https://events.ccc.de/congress/2024/hub/en/assembly/osfw/) * (https://events.ccc.de/congress/2024/hub/en/event/corebooting-intel-based-sy…) ### [David] Preemptively cancel the next leadership meeting, currently scheduled for Christmas day? * Yes, cancelled. ### [jpmurphy] When is the next release? The release page says upcoming Nov 24 (https://doc.coreboot.org/releases/index.html) * Pushed to late December due to holiday scheduling. * Just need to make review + merge patches tagged for the release. ### [alicja] Customers are asking about dynamically configuring FSP parameters * Need to revive some runtime configuration mechanisms (e.g. CFR: (https://review.coreboot.org/c/coreboot/+/74121)) * Try using the newfangled process so it doesn't get hamstrung like previous attempts: (https://docs.google.com/document/d/1gTWR4bnaapzhgDfoEDf_izNj9F3O8BqNpyTfpgn…) ### [alicja] ARM64 and potentially RISC-V - Standardize SoC tree and provide minimal flattened device tree. * Make it easy to use the coreboot framebuffer and such. * ARM64 is a bit of a mess, the more alicja works on standards compliance the more issues she runs into. * Example: u-boot has a generic device tree that provides generic interrupts, FB, etc. and then Linux adds things like audio. * Reduce reliance on the payload to modify the devicetree, since right now Depthcharge does a lot of work and we'd like to improve support for u-boot SPL, EDK2, etc. * Look at Universal Payload (UPL)? # Next Leadership Meeting * January 8,2025. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot 24.12 release tag planned for 18.12!
by Felix Singer 12 Dec '24

12 Dec '24

We are a quite late with the upcoming release this time, but we didn't forget it. The tag is planned for December 18th. Patches which should make it into the release are marked with the hashtag coreboot_release_2412 Patches which need to be merged afterwards (e.g. toolchain related) are marked with the hashtag coreboot_post_release_2412 As always, the final announcement will be done around one week later, and this time during the 38th Chaos Communication Congress in Hamburg! Hope to see you there :) Felix

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 10 Dec '24

10 Dec '24

Hello coreboot community, Please note that we have an upcoming leadership meeting scheduled for tomorrow, December 11, 2024. [1] Kindly update the current agenda with matters you wish to discuss during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Join our opensource firmware/hardware "DUG & vPub" online event - next Thursday! (12th Dec)
by Mike Banon 08 Dec '24

08 Dec '24

Dear Friends, I invite you to a joint ''DUG#8 & vPub 0xD'' event next Thursday: 1. on DUG (5 PM UTC) we will discuss the Dasharo distribution of coreboot opensource PC firmware and explore its new feature: a built-in tiny OS called DTS (Dasharo Tools Suite) 2. on vPub (7 PM UTC) we will be having an Opensource Online Party : with a cozy free-for-all chat about everything opensource firmware/hardware-related, as well as a few planned talks by our peers who would like to share their hard-won in-depth knowledge: * how to analyze the proprietary firmware images of AMD boards * how to check if your AMD board is not blocked by Platform Secure Boot from running the opensource firmware * how to improve the security of your homelab & intranet networks from the low-level angle * how to ensure that your opensource firmware builds are reproducible. Also, you may learn about rare devices that support the opensource firmwares and are hard to stumble upon elsewhere Join links & full events schedule are available here (both video streams and text chats will be available) : https://vpub.dasharo.com/e/15/dasharo-user-group-8 You are highly welcome and we will be waiting for you! -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

[coreboot - Support #567] (New) How init git repository for avoiding date error?
by nymous ano 08 Dec '24

08 Dec '24

Issue #567 has been reported by nymous ano. ---------------------------------------- Support #567: How init git repository for avoiding date error? https://ticket.coreboot.org/issues/567 * Author: nymous ano * Status: New * Priority: Normal * Category: build system * Target version: none * Start date: 2024-11-05 * Affected versions: master * Affected hardware: config.emulation_qemu_aarch64_fit_support_timestamps * Affected OS: Ubuntu Noble Numbat, 24.04, LTS ---------------------------------------- With compiling for 'config.emulation_qemu_aarch64_fit_support_timestamps' following this tutorial 'https://doc.coreboot.org/tutorial/part1.html' for origin/main branch on Linux Ubuntu Noble Numbat, 24.04, LTS, for a aarch64 emulation target, there's this error: > fatal: bad object HEAD > fatal: bad object HEAD > fatal: HEAD is neither a commit nor blob > date: invalid date '@' > date: invalid date '@' > date: invalid date '@' > date: invalid date '@' > date: invalid date '@' > date: invalid date '@' > date: invalid date '@' > date: invalid date '@' > fatal: bad object HEAD > fatal: HEAD is neither a commit nor blob > Updating git submodules. > CC romstage/lib/version.o > CC romstage/southbridge/intel/common/rtc.o > CC romstage/southbridge/intel/common/smbus.o > CC romstage/southbridge/intel/i82371eb/early_pm.o > src/lib/version.c:24:75: error: expected expression before ';' token > 24 | const unsigned int coreboot_version_timestamp = COREBOOT_VERSION_TIMESTAMP; > | ^ > In file included from src/lib/version.c:4: > build/build.h:13:33: error: invalid suffix "x" on integer constant > 13 | #define COREBOOT_BUILD_YEAR_BCD 0x > | ^~ > src/lib/version.c:33:17: note: in expansion of macro 'COREBOOT_BUILD_YEAR_BCD' > 33 | .year = COREBOOT_BUILD_YEAR_BCD, > | ^~~~~~~~~~~~~~~~~~~~~~~ > build/build.h:14:34: error: invalid suffix "x" on integer constant > 14 | #define COREBOOT_BUILD_MONTH_BCD 0x > | ^~ > src/lib/version.c:34:18: note: in expansion of macro 'COREBOOT_BUILD_MONTH_BCD' > 34 | .month = COREBOOT_BUILD_MONTH_BCD, > | ^~~~~~~~~~~~~~~~~~~~~~~~ > build/build.h:15:32: error: invalid suffix "x" on integer constant > 15 | #define COREBOOT_BUILD_DAY_BCD 0x > | ^~ > src/lib/version.c:35:16: note: in expansion of macro 'COREBOOT_BUILD_DAY_BCD' > 35 | .day = COREBOOT_BUILD_DAY_BCD, > | ^~~~~~~~~~~~~~~~~~~~~~ > build/build.h:16:36: error: invalid suffix "x" on integer constant > 16 | #define COREBOOT_BUILD_WEEKDAY_BCD 0x > | ^~ > src/lib/version.c:36:20: note: in expansion of macro 'COREBOOT_BUILD_WEEKDAY_BCD' > 36 | .weekday = COREBOOT_BUILD_WEEKDAY_BCD, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > make: *** [Makefile:430: build/romstage/lib/version.o] Error 1 > make: *** Waiting for unfinished jobs.... There seems to be no hint within tutorial documentation for to avoid this missing date and version from/for the repository? ( Thanks for Your time and engagement. ) -- 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 13

2024_12_04 coreboot Group Review Session Canceled.
by mina＠coreboot.org 04 Dec '24

04 Dec '24

Hello coreboot, Please be informed that the group review session scheduled for today has been canceled due to missing meeting details on the coreboot calendar. We sincerely apologize for the short notice and any inconvenience caused. Thank you. Best regards, Mina.

1 0

2024_12_04 coreboot Group Review Sesssion
by mina＠coreboot.org 02 Dec '24

02 Dec '24

Hello coreboot! Please note that we have an upcoming review session scheduled for Wednesday, December 4, 2024: https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… 18#gid=591540418). Kindly add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

1 0

2024-11-27 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 28 Nov '24

28 Nov '24

# 2024-11-27 - coreboot Leadership Meeting ## Attendees Julius Werner, Matt DeVillier, Jay Talbott, David Hendricks, Felix Held, Alicja Michalska, Mina Asante, Werner Zeh, Andre. ## Open Action Items * 2024-11-27 * Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Julius] Add [Yidi Lin](mailto:yidilin@google.com) (https://review.coreboot.org/q/owner:yidilin@google.com) to Submitters (“Core Developers”) group (100+ merged patches, 400+ reviews, been contributing for 4 years, has been bring-up lead for several SoCs, also contributed to vboot, Arm architecture, etc.) * Done ### [Alicja] Revisiting extending CBFS to storage media * (see: 2024-06-26 notes) to deal with large payloads. # Next Leadership Meeting December 11, 2024. [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 25 Nov '24

25 Nov '24

Dear coreboot community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, November 27, 2024. [1] Kindly take a moment to review the current agenda and share your thoughts, or suggest any additional items you would like to discuss during the meeting. [2] ## Current Agenda Items ### [Julius] Add Yidi Lin (https://review.coreboot.org/q/owner:yidilin@google.com) to Submitters (“Core Developers”) group (100+ merged patches, 400+ reviews, been contributing for 4 years, has been bring-up lead for several SoCs, also contributed to vboot, Arm architecture, etc.) [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

regarding coreboot source level debugging
by ritul guru 23 Nov '24

23 Nov '24

Hi All, Recently had a need to debug the coreboot at source level. Is it that we can only debug coreboot from romstage and not in bootblock or verstage via gdb or any other source level debugger? any pointers will be helpful here. I see a few pointers below to use gdb for coreboot source level debugging, any other guidelines or help available for the same? https://www.coreboot.org/Debugging *Thanks & RegardsRitul Guru+91-9916513186*

2 1

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 22 Nov '24

22 Nov '24

Dear coreboot community, Kindly note that we have an upcoming leadership meeting scheduled for Wednesday, November 27, 2024.[1] Please update the current agenda with matters you wish to discuss during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

2024_11_20 coreboot Group Review Sesssion
by mina＠coreboot.org 19 Nov '24

19 Nov '24

Hello coreboot! Please note that we have an upcoming review session scheduled for Wednesday, November 20, 2024: https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here’s the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… 80#gid=594572880) Kindly add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Nemanja Z 16 Nov '24

16 Nov '24

Issue #121 has been updated by Nemanja Z. I also finally updated my T520 i7-3740QM to 24.08-631-gf8d4283e78d2. (from 4.14-2082-gee760b4be8) No kernel options, C7 working now, no crashes in Debian 12, Windows 10 also seems fine. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1974 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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

Understanding cache-as-ram code
by Dorjoy Chowdhury 15 Nov '24

15 Nov '24

Hi, I am trying to understand how cache as ram works and how coreboot implements it. I am looking into this piece of code: https://github.com/coreboot/coreboot/blob/main/src/soc/intel/common/block/c… and if I try to summarize the whole process of setting up cache as ram is that after setting up MTRR for the region as write-back, we need to enable cache, invalidate the cache, call "clear_car" so that the cachelines are marked for these memory addresses. I understand that this is necessary so that later when CR0.CD = 1, CR0.NW = 1 is done, the memory accesses to these locations will cause cache hits and if written to these memory locations, the write-back policy will cause only the cache to be updated. My question is when "clear_car" is executed, wouldn't it cause the cache lines to be filled first (as it's a cache miss), by the cpu doing memory accesses by trying to "read" those locations? But DRAM isn't initialized still, so does that mean that the cache lines will be filled with garbage and this is okay, right? And then the cache is updated with some value with the stosl instruction. I am just not sure about if the cache lines will be filled with garbage when the cpu will first fill up the cache lines by trying to read those memory locations as there is no DRAM initialized. It would be great if someone could help me to understand this process. Thanks! Regards, Dorjoy

1 0

2024-11-13 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 14 Nov '24

14 Nov '24

# 2024-11-13 - coreboot Leadership Meeting ## Attendees Andre, Felix Held, Jay Talbott, Felix Singer, Julius Werner, Werner Zeh, Alicja Michalska, Mina Asante, Jon Murphy, Matt DeVillier, Maximilian Brune, Ron Minnich, Karthik R. ## Open Action Items * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot:https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Elyes] Any update on OpenSBI case …. ? (See 2024-07-24 - coreboot Leadership Meeting and (https://review.coreboot.org/c/coreboot/+/84979) ). * [Mat]: It was planned to replace the submodule by a binary blob (see patch from Max: https://review.coreboot.org/c/coreboot/+/83284). This patch is ready to be merged, we do not need the 3rdparty git repo anymore for OpenSBI. * Matt will rebase Max’ patch and merge it in. * [Julius]: Shall we keep the old 3rdparty openSBI submodule in the tree or shall we get rid of it after Max’s patch was merged? * [Max]: A lot of users have their own OpenSBI port, so having this submodule in the tree does not bring us that much benefits. It is hard to update OpenSBI submodule currently (can’t build it with our toolchain, there might be a missing linker (PIE: *Makefile:193: *** Your linker does not support creating PIEs, opensbi requires this.. Stop.*) feature). Not clear currently why our linker is missing. * [Julius]: Looks like it's not actually querying the linker for that, you just need to set an option?(https://github.com/riscv-software-src/opensbi/blob/master/Makefile#… * FelixS will give it a try! * If we are going to remove it from 3rdparty, we need to document the dependency to the users to make them aware of the change. * Conclusion: Keep it as long in the tree as somebody is going to fix the issue. ### [Karthik] Is it ok to enable FW_CONFIG in SMM stage (https://review.coreboot.org/c/coreboot/+/85107/11/src/lib/Makefile.mk) * Are there any security concerns? * FW_CONFIG can use either EC or CBFS * [Julius]: Is the EC communication driver linked to SMM? –> Yes * [Karthik]: Since EC code is linked to SMM there is no issue to add fw_config to SMM from Google’s point of view. * [Matt]:Isn’t fw_config cached on the first read? → Yes, but per stage only. * [Mat, FelixH]: Why not toggle the GPIOs even if the WWAN module is not equipped on the board? The pins should be configured as GPIOs anyway, switching them unconditionally should not harm and will enable us to not link fw_config into SMM. → Karthik will propose that to the ODMs, looks doable. # Next Leadership Meeting November 27, 2024. [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 11 Nov '24

11 Nov '24

Dear coreboot community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, November 13, 2024.[1] Kindly take a moment to review the current agenda and share your thoughts, or suggest any additional items you would like to discuss during the meeting.[2] Thank you. ## Current Agenda Items ### [Elyes] Any update on OpenSBI case …. ? (See 2024-07-24 - coreboot Leadership Meeting and https://review.coreboot.org/c/coreboot/+/84979. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 08 Nov '24

08 Nov '24

Dear coreboot community, Kindly note that our next leadership meeting is scheduled for Wednesday, November 13, 2024.[1] Please update the current agenda with matters you wish to discuss during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

H610DA V41 supporting
by Valeriy Simakov 05 Nov '24

05 Nov '24

Hello! I’m an embedded developer, and I’m interested in your ‘coreboot’ project. I want to run it on my motherboard(H610DA ). Could you please help me with that, is there any document that describes porting to a new motherboard? As I understand, I should know how the bios binary file organize on my motherboard and other specific information that I could get only from manufacture. -- Best regards, Valeriy Simakov

1 0

2024_11_06 coreboot Group Review Sesssion
by mina＠coreboot.org 04 Nov '24

04 Nov '24

Hello coreboot! Please note that our next review session is scheduled for Wednesday, November 6, 2024: https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here’s the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… 055#gid=1519768055). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

2024-10-30 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 31 Oct '24

31 Oct '24

# 2024-10-30 - coreboot Leadership Meeting ## Attendees Felix Held, Felix Singer, Marshall Dawson, Matt DeVillier, Jeremy Compostella, Alicja Michalska, Maximilian Brune, Pono, Mina Asante, David Hendricks, Jay Talbott, Julius Werner, Ron Minnich. ## Open Action Items * 2024-10-30 * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches”. * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot:https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: (https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Elyes] How to know when we should follow Linux rules and when those of coreboot ? Please make it clear. * I’m asking because of Felix’s comment here : https://review.coreboot.org/c/coreboot/+/84074 about “`Commit <first 12 chars of commit> ("<commit title>")"` * [Matt] coreboot’s checkpatch should detect and enforce this: ![alt_text](images/image1.png "image_tooltip") * [Matt] looks like we don’t explicitly state this in the coding style or documentation, and probably should just for clarity * AI: add clarification to docs, do not use gerrit change-id or CB: format in reference to already-merged patches. ### [David] Follow-up on discussion with SFC regarding use of LLM-generated code * It's a new thing that doesn't have a good policy yet. SFC is getting a lot of questions regarding this, and there seems to be widespread adoption in various companies but with various restrictions surrounding how they are used. It's unclear how this applies to the world of free software. * We need to gather data at this time to figure out how many people are using LLMs and how. This will help SFC craft appropriate policy. * How do we do this? Ask people to annotate commit messages if they used an LLM? This would be voluntary (we have no good way to enforce it). * We don't necessarily know who is using it now, and we don't have a good way of tracking it. So we treat patches the way we currently do, regardless of whether an LLM was involved in their creation or not. ### [David] Is anything needed with regard to Russian maintainers/contributors? * We asked the SFC back in April '23, but did not get a response. Given the recent drama in Linux it seems we need to revisit this topic and avoid running amok of sanctions. * [Pono] This is a confusing issue.Continuing as normal for now is OK, but SFC will let us know if this changes. * How could this be enforced? IP address scanning? Is there some retention period for logs? * Pono will follow-up with Karen about this. * Does this only apply to people working at sanctioned companies, or everyone living in the country? * [Alicja & others] - It may only apply to sanctioned companies. * How does this apply to certain community members? We believe there is at least one who may be impacted. # Next Leadership Meeting * November 13, 2024. [coreboot Calendar](https://coreboot.org/calendar.html). # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Nonfree software in vboot, what to do about it?
by Denis 'GNUtoo' Carikli 29 Oct '24

29 Oct '24

Hi, As part of my work on GNU Boot, I found nonfree software in vboot[1] in tests/futility/data. The same binaries also probably have free software with missing corresponding source code but I didn't take the time to confirm that yet. We'll take bios_link_mp.bin as an example. As many people know, is used in the first Chromebook pixel, and it's easy to extract things like the Management Engine firmware (with ifdtool -x) and to verify it with me_cleaner (though I'm unsure how to print which partitions it has and print that they are verified). It's also possible to extract things like the MRC binary as well with cbfstool (with cbfstool layout and then using the BOOT_STUB region of fmap). Several distributions ended up using vboot source code to make some vboot-utils packages. It includes distributions like Debian, Fedora, Guix, Trisquel, etc. So these distributions ended up redistributing the mrc.bin for instance when they published the source version of the vboot-utils package. Since all these distributions have repositories where redistributing nonfree software is forbidden, they automatically have a bug to solve here so I started bug reporting to them. The distributions could also workaround and somehow remove the binaries from the source they publish but this then brings a question of maintenance over time, so this is what bring me here. Questions on vboot: ------------------- Who is the vboot upstream, is it Coreboot or is it Google? Who should we discuss with when trying to understand if it's possible to find a solution. Does anyone redistributing the vboot source code also has the right to distribute the binaries as-is (including things like Intel Microcode)? Since they come with no licenses there is also nothing that forbids reverse engineering, right? Would it be possible to somehow remove or move the binaries somewhere else like in a separate git repository and make them optional in the tests? Or should we create free binaries somehow? Though I fear that the later somehow defeat the intent of the tests. References: ----------- [1]https://review.coreboot.org/vboot.git Denis.

2 3

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 29 Oct '24

29 Oct '24

Dear coreboot community, Please be reminded that we have an upcoming leadership meeting scheduled for tomorrow, October 30, 2024.[1] Kindly take a moment to review the current agenda and share your thoughts, or suggest any additional items you would like to discuss during the meeting.[2] Thank you. ## Current Agenda Items ### [Elyes] How to know when we should follow Linux rules and when those of coreboot? Please make it clear. * I’m asking because of Felix’s comment here : https://review.coreboot.org/c/coreboot/+/84074 about “`Commit <first 10 chars of commit> ("<commit title>")" ` [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Will core boot work with my system?
by Arif Tohid 27 Oct '24

27 Oct '24

Hi i just wanted to know if coreboot will work on my system can please confirm. My system: Clevo model: P375SM-A. Appreciate your kind help and advices many thanks. Thank you Kind Regards.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 25 Oct '24

25 Oct '24

Dear coreboot community, We are pleased to announce that our next leadership meeting is scheduled for Wednesday, October 30, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante.

1 0

Seeking your thoughts on LLM-generated contributions
by Karen M. Sandler 23 Oct '24

23 Oct '24

Hi coreboot contributors! We at Software Freedom Conservancy (coreboot's nonprofit home) have been hearing from member projects like coreboot that people are asking whether they can submit code to these projects that was generated by large language models (LLMs), sometimes called AI coding assistants. We'd like to better understand the nature of these requests, how much LLM-generated code has been offered to these projects, and generally how you're feeling about the situation. To do this, we will be holding three different sessions for all of our member projects, where you are welcome to join and share your thoughts and any details so far on these types of contributions. The sessions will all be run in the same way with the same topic - we are running three in order to hopefully allow as many people from around the world to attend as possible. Here are the times that the sessions will be held at: date -d "2024-10-29 20:00 UTC" date -d "2024-11-01 14:00 UTC" date -d "2024-11-06 04:00 UTC" We'll be meeting in this room for the sessions: https://bbb.sfconservancy.org/b/oss-nnj-obi-jea We are excited to see some of you there and are looking forward to drafting appropriate recommendations based on what we hear! Karen M. Sandler Executive Director, Software Freedom Conservancy she/hers __________ Become a Sustainer today! http://sfconservancy.org/sustainer/

1 0

2024_10_23 coreboot Group Review Session
by mina＠coreboot.org 21 Oct '24

21 Oct '24

Hello coreboot! We have an upcoming group review session scheduled for Wednesday, October 23, 2024: https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here’s the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… 18#gid=591540418) Kindly add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

1 0

[coreboot - Bug #565] (New) Wifi card not recognized (not enumerated) at all, Lenovo M700 tiny
by Vittorio Mori 20 Oct '24

20 Oct '24

Issue #565 has been reported by Vittorio Mori. ---------------------------------------- Bug #565: Wifi card not recognized (not enumerated) at all, Lenovo M700 tiny https://ticket.coreboot.org/issues/565 * Author: Vittorio Mori * Status: New * Priority: Normal * Target version: none * Start date: 2024-10-03 * Related links: https://drive.google.com/file/d/1o3ah4UMuQdK5z-D24uLYSXD3if47N5hs/view * Affected hardware: Lenovo M700 tiny ---------------------------------------- Hello, I've compiled coreboot for my Lenovo M700 Tiny, to have other processor support (Kaby Lake/Coffee Lake). The ed2k payload works correctly, I can successfully boot a Kaby Lake and Coffee lake CPU with Coreboot (original Lenovo BIOS is Skylake-only). I report two annoying issues: - wif card pci-e slot is not working, the card is not enumerated at all. ASPM on or off, no difference (with ASPM ON I get continous AER errors in dmesg on Linux). With original OEM BIOS the wifi (Intel 8260 wifi5 chipset) 100% works. On coreboot I get only the bluetooth part working (I know it's on the USB bus, so I think it's normal). - I use libgfxinit for graphics part: works correctly at boot, Linux booting always OK, but Windows 11 fails to initialize the displayport output i.e. it gets TURNED OFF for some reason when windows starts. I have to unplug and plug the cable back to have display back ON. This also does not happen with original OEM firmware. Maybe I must use a GOP ? I could not find a clear guide on how to compile/initialize coreboot w GOP into coreboot. Maybe I can run it into an .efi binary (I have all .efi GOPs somewhere..) ? Here is the cbmem log: `[NOTE ] coreboot-24.08-272-g735ca7f24ad4 Tue Sep 24 05:19:22 UTC 2024 x86_32 bootblock starting (log level: 7)... [DEBUG] CPU: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz [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 a148 (rev 31) is B150 [DEBUG] IGD: device id 5912 (rev 04) is Kaby Lake DT GT2 [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x850000. [DEBUG] FMAP: base = 0xff000000 size = 0x1000000 #areas = 8 [DEBUG] FMAP: area COREBOOT found @ 850200 (8060416 bytes) [INFO ] CBFS: mcache @0xfef04f00 built for 16 files, used 0x364 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x9d1c0 size 0xb9a0 in mcache @0xfef04f8c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 78 ms [NOTE ] coreboot-24.08-272-g735ca7f24ad4 Tue Sep 24 05:19:22 UTC 2024 x86_32 romstage starting (log level: 7)... [DEBUG] pm1_sts: 0000 pm1_en: 0000 pm1_cnt: 00000000 [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]: 00000002 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0001 [DEBUG] GEN_PMCON: e0850200 00001808 [DEBUG] GBLRST_CAUSE: 00000400 00010001 [DEBUG] prev_sleep_state 0 (S0) [DEBUG] FMAP: area COREBOOT found @ 850200 (8060416 bytes) [INFO ] CBFS: Found 'fspm.bin' @0xcadc0 size 0x63000 in mcache @0xfef0513c [DEBUG] FMAP: area RW_MRC_CACHE found @ 800000 (65536 bytes) [DEBUG] SPD @ 0x50 [INFO ] SPD: module type is DDR4 [INFO ] SPD: module part number is 4ATF51264HZ-2G3E2 [INFO ] SPD: banks 8, ranks 1, rows 16, columns 10, density 8192 Mb [INFO ] SPD: device width 16 bits, bus width 64 bits [INFO ] SPD: module size is 4096 MB (per channel) [DEBUG] SPD @ 0x52 [INFO ] SPD: module type is DDR4 [INFO ] SPD: module part number is 4ATF51264HZ-2G3E2 [INFO ] SPD: banks 8, ranks 1, rows 16, columns 10, density 8192 Mb [INFO ] SPD: device width 16 bits, bus width 64 bits [INFO ] SPD: module size is 4096 MB (per channel) [DEBUG] CBMEM: [DEBUG] IMD: root @ 0x7afff000 254 entries. [DEBUG] IMD: root @ 0x7affec00 62 entries. [DEBUG] External stage cache: [DEBUG] IMD: root @ 0x7b3ff000 254 entries. [DEBUG] IMD: root @ 0x7b3fec00 62 entries. [DEBUG] FMAP: area RW_MRC_CACHE found @ 800000 (65536 bytes) [DEBUG] MRC: Checking cached data update for 'RW_MRC_CACHE'. [DEBUG] MRC: 'RW_MRC_CACHE' does not need update. [DEBUG] 2 DIMMs found [DEBUG] SMM Memory Map [DEBUG] SMRAM : 0x7b000000 0x800000 [DEBUG] Subregion 0: 0x7b000000 0x200000 [DEBUG] Subregion 1: 0x7b200000 0x200000 [DEBUG] Subregion 2: 0x7b400000 0x400000 [DEBUG] top_of_ram = 0x7b000000 [DEBUG] Normal boot [INFO ] CBFS: Found 'fallback/postcar' @0x151e40 size 0x6808 in mcache @0xfef051b0 [DEBUG] Loading module at 0x7abce000 with entry 0x7abce031. filesize: 0x6208 memsize: 0xc5a0 [DEBUG] Processing 368 relocs. Offset value of 0x78bce000 [DEBUG] BS: romstage times (exec / console): total (unknown) / 226 ms [NOTE ] coreboot-24.08-272-g735ca7f24ad4 Tue Sep 24 05:19:22 UTC 2024 x86_32 postcar starting (log level: 7)... [DEBUG] Normal boot [DEBUG] FMAP: area COREBOOT found @ 850200 (8060416 bytes) [INFO ] CBFS: Found 'fallback/ramstage' @0xa8bc0 size 0x1d278 in mcache @0x7abdc0ec [DEBUG] Loading module at 0x7aa7f000 with entry 0x7aa7f000. filesize: 0x3a428 memsize: 0x14d908 [DEBUG] Processing 4860 relocs. Offset value of 0x76a7f000 [DEBUG] BS: postcar times (exec / console): total (unknown) / 43 ms [NOTE ] coreboot-24.08-272-g735ca7f24ad4 Tue Sep 24 05:19:22 UTC 2024 x86_32 ramstage starting (log level: 7)... [DEBUG] Normal boot [DEBUG] microcode: sig=0x906e9 pf=0x2 revision=0xf7 [DEBUG] FMAP: area COREBOOT found @ 850200 (8060416 bytes) [INFO ] CBFS: Found 'cpu_microcode_blob.bin' @0x80 size 0x9d000 in mcache @0x7abdc02c [DEBUG] Skip microcode update [INFO ] CBFS: Found 'fsps.bin' @0x12de00 size 0x23ff2 in mcache @0x7abdc27c [DEBUG] Detected 2 core, 4 thread CPU. [DEBUG] Setting up SMI for CPU [DEBUG] IED base = 0x7b400000 [DEBUG] IED size = 0x00400000 [INFO ] Will perform SMM setup. [INFO ] CPU: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz. [INFO ] LAPIC 0x0 in XAPIC mode. [DEBUG] CPU: APIC: 00 enabled [DEBUG] CPU: APIC: 01 enabled [DEBUG] CPU: APIC: 02 enabled [DEBUG] CPU: APIC: 03 enabled [DEBUG] Loading module at 0x00030000 with entry 0x00030000. filesize: 0x178 memsize: 0x178 [DEBUG] Processing 16 relocs. Offset value of 0x00030000 [DEBUG] Attempting to start 3 APs [DEBUG] Waiting for 10ms after sending INIT. [DEBUG] Waiting for SIPI to complete... [INFO ] LAPIC 0x1 in XAPIC mode. [DEBUG] done. [INFO ] AP: slot 3 apic_id 1, MCU rev: 0x000000f7 [DEBUG] Waiting for SIPI to complete... [DEBUG] done. [INFO ] LAPIC 0x3 in XAPIC mode. [INFO ] LAPIC 0x2 in XAPIC mode. [INFO ] AP: slot 1 apic_id 3, MCU rev: 0x000000f7 [INFO ] AP: slot 2 apic_id 2, MCU rev: 0x000000f7 [DEBUG] Loading module at 0x00038000 with entry 0x00038000. filesize: 0x1b0 memsize: 0x1b0 [DEBUG] Processing 9 relocs. Offset value of 0x00038000 [DEBUG] smm_module_setup_stub: stack_top = 0x7b002000 [DEBUG] smm_module_setup_stub: per cpu stack_size = 0x800 [DEBUG] smm_module_setup_stub: runtime.smm_size = 0x10000 [DEBUG] SMM Module: stub loaded at 38000. Will call 0x7aa98de3 [DEBUG] Installing permanent SMM handler to 0x7b000000 [DEBUG] HANDLER [0x7b1fe000-0x7b1ffe8f] [DEBUG] CPU 0 [DEBUG] ss0 [0x7b1fdc00-0x7b1fdfff] [DEBUG] stub0 [0x7b1f6000-0x7b1f61af] [DEBUG] CPU 1 [DEBUG] ss1 [0x7b1fd800-0x7b1fdbff] [DEBUG] stub1 [0x7b1f5c00-0x7b1f5daf] [DEBUG] CPU 2 [DEBUG] ss2 [0x7b1fd400-0x7b1fd7ff] [DEBUG] stub2 [0x7b1f5800-0x7b1f59af] [DEBUG] CPU 3 [DEBUG] ss3 [0x7b1fd000-0x7b1fd3ff] [DEBUG] stub3 [0x7b1f5400-0x7b1f55af] [DEBUG] stacks [0x7b000000-0x7b001fff] [DEBUG] Loading module at 0x7b1fe000 with entry 0x7b1ff81b. filesize: 0x1db0 memsize: 0x1e90 [DEBUG] Processing 149 relocs. Offset value of 0x7b1fe000 [DEBUG] FMAP: area SMMSTORE found @ 810000 (262144 bytes) [DEBUG] smm store: 4 # blocks with size 0x10000 [DEBUG] Loading module at 0x7b1f6000 with entry 0x7b1f6000. filesize: 0x1b0 memsize: 0x1b0 [DEBUG] Processing 9 relocs. Offset value of 0x7b1f6000 [DEBUG] smm_module_setup_stub: stack_top = 0x7b002000 [DEBUG] smm_module_setup_stub: per cpu stack_size = 0x800 [DEBUG] smm_module_setup_stub: runtime.smm_size = 0x200000 [DEBUG] SMM Module: placing smm entry code at 7b1f5c00, cpu # 0x1 [DEBUG] SMM Module: placing smm entry code at 7b1f5800, cpu # 0x2 [DEBUG] SMM Module: placing smm entry code at 7b1f5400, cpu # 0x3 [DEBUG] SMM Module: stub loaded at 7b1f6000. Will call 0x7b1ff81b [DEBUG] Clearing SMI status registers [DEBUG] TCO_STS: INTRD_DET [DEBUG] GPE0 STD STS: HOTPLUG [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7b1ee000, cpu = 0 [DEBUG] In relocation handler: CPU 0 [DEBUG] New SMBASE=0x7b1ee000 IEDBASE=0x7b400000 [DEBUG] Writing SMRR. base = 0x7b000006, mask=0xff800800 [DEBUG] Relocation complete. [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7b1ed800, cpu = 2 [DEBUG] In relocation handler: CPU 2 [DEBUG] New SMBASE=0x7b1ed800 IEDBASE=0x7b400000 [DEBUG] Writing SMRR. base = 0x7b000006, mask=0xff800800 [DEBUG] Relocation complete. [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7b1edc00, cpu = 1 [DEBUG] In relocation handler: CPU 1 [DEBUG] New SMBASE=0x7b1edc00 IEDBASE=0x7b400000 [DEBUG] Relocation complete. [INFO ] smm_do_relocation : curr_smbase 0x30000 perm_smbase 0x7b1ed400, cpu = 3 [DEBUG] In relocation handler: CPU 3 [DEBUG] New SMBASE=0x7b1ed400 IEDBASE=0x7b400000 [DEBUG] Relocation complete. [INFO ] Initializing CPU #0 [DEBUG] CPU: vendor Intel device 906e9 [DEBUG] CPU: family 06, model 9e, stepping 09 [DEBUG] Clearing out pending MCEs [DEBUG] cpu: energy policy set to 6 [INFO ] Turbo is unavailable [DEBUG] Skip microcode update [INFO ] CPU #0 initialized [INFO ] Initializing CPU #3 [INFO ] Initializing CPU #1 [INFO ] Initializing CPU #2 [DEBUG] CPU: vendor Intel device 906e9 [DEBUG] CPU: family 06, model 9e, stepping 09 [DEBUG] CPU: vendor Intel device 906e9 [DEBUG] CPU: family 06, model 9e, stepping 09 [DEBUG] Clearing out pending MCEs [DEBUG] Clearing out pending MCEs [DEBUG] cpu: energy policy set to 6 [DEBUG] CPU: vendor Intel device 906e9 [DEBUG] CPU: family 06, model 9e, stepping 09 [DEBUG] cpu: energy policy set to 6 [DEBUG] Skip microcode update [INFO ] CPU #1 initialized [DEBUG] Skip microcode update [INFO ] CPU #2 initialized [DEBUG] Clearing out pending MCEs [DEBUG] cpu: energy policy set to 6 [DEBUG] Skip microcode update [INFO ] CPU #3 initialized [INFO ] bsp_do_flight_plan done after 420 msecs. [DEBUG] Enabling SMIs. [DEBUG] Locking SMM. [DEBUG] VMX status: enabled [DEBUG] VMX status: enabled [DEBUG] IA32_FEATURE_CONTROL status: locked [DEBUG] VMX status: enabled [DEBUG] VMX status: enabled [DEBUG] IA32_FEATURE_CONTROL status: locked [DEBUG] IA32_FEATURE_CONTROL status: locked [DEBUG] BS: BS_DEV_INIT_CHIPS entry times (exec / console): 204 / 381 ms [DEBUG] IA32_FEATURE_CONTROL status: locked [DEBUG] WEAK: src/soc/intel/skylake/chip.c/mainboard_silicon_init_params called [INFO ] FSPS, status=0x00000000 [INFO ] ITSS IRQ Polarities Before: [INFO ] IPC0: 0x00ff4000 [INFO ] IPC1: 0x00000007 [INFO ] IPC2: 0x00000000 [INFO ] IPC3: 0x00000000 [INFO ] ITSS IRQ Polarities After: [INFO ] IPC0: 0x00ff4000 [INFO ] IPC1: 0x00000007 [INFO ] IPC2: 0x00000000 [INFO ] IPC3: 0x00000000 [INFO ] Found PCIe Root Port #7 at PCI: 00:1c.0. [NOTE ] pcie_rp_update_dev: Couldn't find PCIe Root Port #17 (originally PCI: 00:00:1b.0) which was enabled in devicetree, removing and disabling. [INFO ] Remapping PCIe Root Port #7 from PCI: 00:00:1c.6 to new function number 0. [DEBUG] BS: BS_DEV_INIT_CHIPS run times (exec / console): 56 / 73 ms [INFO ] Enumerating buses... [INFO ] Board ID: ThinkCentre M700 Tiny [INFO ] Serial header unpopulated [INFO ] PS/2 header unpopulated [INFO ] USB header unpopulated [INFO ] DisplayPort header populated [INFO ] PCIe / SATA header unpopulated [DEBUG] Root Device scanning... [DEBUG] CPU_CLUSTER: 0 enabled [DEBUG] DOMAIN: 00000000 enabled [DEBUG] DOMAIN: 00000000 scanning... [DEBUG] PCI: pci_scan_bus for segment group 00 bus 00 [DEBUG] PCI: 00:00:00.0 [8086/590f] enabled [DEBUG] PCI: 00:00:02.0 [8086/5912] enabled [DEBUG] PCI: 00:00:04.0 [8086/1903] enabled [DEBUG] PCI: 00:00:08.0 [8086/1911] enabled [DEBUG] PCI: 00:00:14.0 [8086/a12f] enabled [DEBUG] PCI: 00:00:14.2 [8086/a131] enabled [DEBUG] PCI: 00:00:16.0 [8086/a13a] enabled [DEBUG] PCI: 00:00:17.0 [8086/a102] enabled [DEBUG] PCI: 00:00:19.0 [8086/a166] disabled [DEBUG] PCI: 00:00:1c.0 [8086/a116] enabled [DEBUG] PCI: 00:00:1f.0 [8086/a148] enabled [DEBUG] PCI: 00:00:1f.1 [8086/a120] enabled [DEBUG] PCI: 00:00:1f.2 [8086/a121] enabled [DEBUG] PCI: 00:00:1f.3 [8086/a170] enabled [DEBUG] PCI: 00:00:1f.4 [8086/a123] enabled [DEBUG] PCI: 00:00:1f.6 [8086/15b8] enabled [DEBUG] GPIO: 0 enabled [WARN ] PCI: Leftover static devices: [WARN ] PCI: 00:00:01.0 [WARN ] PCI: 00:00:01.1 [WARN ] PCI: 00:00:01.2 [WARN ] PCI: 00:00:05.0 [WARN ] PCI: 00:00:07.0 [WARN ] PCI: 00:00:13.0 [WARN ] PCI: 00:00:14.1 [WARN ] PCI: 00:00:14.3 [WARN ] PCI: 00:00:15.0 [WARN ] PCI: 00:00:15.1 [WARN ] PCI: 00:00:15.2 [WARN ] PCI: 00:00:15.3 [WARN ] PCI: 00:00:16.1 [WARN ] PCI: 00:00:16.2 [WARN ] PCI: 00:00:16.3 [WARN ] PCI: 00:00:16.4 [WARN ] PCI: 00:00:19.1 [WARN ] PCI: 00:00:19.2 [WARN ] PCI: 00:00:1e.0 [WARN ] PCI: 00:00:1e.1 [WARN ] PCI: 00:00:1e.2 [WARN ] PCI: 00:00:1e.3 [WARN ] PCI: 00:00:1e.4 [WARN ] PCI: 00:00:1e.5 [WARN ] PCI: 00:00:1e.6 [WARN ] PCI: 00:00:1f.5 [WARN ] PCI: 00:00:1f.7 [WARN ] PCI: Check your devicetree.cb. [DEBUG] PCI: 00:00:02.0 scanning... [DEBUG] scan_bus: bus PCI: 00:00:02.0 finished in 0 msecs [DEBUG] PCI: 00:00:14.0 scanning... [DEBUG] scan_bus: bus PCI: 00:00:14.0 finished in 0 msecs [DEBUG] PCI: 00:00:1c.0 scanning... [DEBUG] PCI: pci_scan_bus for segment group 00 bus 01 [DEBUG] GENERIC: 0.0 enabled [INFO ] PCI: 00:00:1c.0: Setting Max_Payload_Size to 128 for devices under this root port [DEBUG] scan_bus: bus PCI: 00:00:1c.0 finished in 18 msecs [DEBUG] PCI: 00:00:1f.0 scanning... [DEBUG] PNP: 002e.1 disabled [DEBUG] PNP: 002e.2 enabled [DEBUG] PNP: 002e.3 disabled [DEBUG] PNP: 002e.5 disabled [DEBUG] PNP: 002e.6 disabled [DEBUG] PNP: 002e.7 disabled [DEBUG] PNP: 002e.8 disabled [DEBUG] PNP: 002e.9 disabled [DEBUG] PNP: 002e.a enabled [DEBUG] PNP: 002e.b enabled [DEBUG] PNP: 002e.c disabled [DEBUG] PNP: 002e.d disabled [DEBUG] PNP: 002e.e enabled [DEBUG] PNP: 002e.f disabled [INFO ] Found TPM 1.2 NPCT420AA V2 (0x00fe) by Nuvoton (0x1050) [DEBUG] PNP: 0c31.0 enabled [DEBUG] scan_bus: bus PCI: 00:00:1f.0 finished in 59 msecs [DEBUG] PCI: 00:00:1f.2 scanning... [DEBUG] scan_bus: bus PCI: 00:00:1f.2 finished in 0 msecs [DEBUG] PCI: 00:00:1f.3 scanning... [DEBUG] scan_bus: bus PCI: 00:00:1f.3 finished in 0 msecs [DEBUG] PCI: 00:00:1f.4 scanning... [DEBUG] scan_bus: bus PCI: 00:00:1f.4 finished in 0 msecs [DEBUG] scan_bus: bus DOMAIN: 00000000 finished in 336 msecs [DEBUG] scan_bus: bus Root Device finished in 354 msecs [INFO ] done [DEBUG] BS: BS_DEV_ENUMERATE run times (exec / console): 10 / 391 ms [INFO ] MRC: Could not find region 'UNIFIED_MRC_CACHE' [DEBUG] FMAP: area RW_MRC_CACHE found @ 800000 (65536 bytes) [INFO ] MRC: NOT enabling PRR for 'RW_MRC_CACHE'. [DEBUG] BS: BS_DEV_ENUMERATE exit times (exec / console): 0 / 18 ms [DEBUG] found VGA at PCI: 00:00:02.0 [DEBUG] Setting up VGA for PCI: 00:00:02.0 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 00000000 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge Root Device [INFO ] Allocating resources... [INFO ] Reading resources... [DEBUG] SA MMIO resource: PCIEXBAR -> base = 0xe0000000, size = 0x10000000 [DEBUG] SA MMIO resource: MCHBAR -> base = 0xfed10000, size = 0x00008000 [DEBUG] SA MMIO resource: DMIBAR -> base = 0xfed18000, size = 0x00001000 [DEBUG] SA MMIO resource: EPBAR -> base = 0xfed19000, size = 0x00001000 [DEBUG] SA MMIO resource: GDXCBAR -> base = 0xfed84000, size = 0x00001000 [DEBUG] SA MMIO resource: EDRAMBAR -> base = 0xfed80000, size = 0x00004000 [DEBUG] SA MMIO resource: GFXVTBAR -> base = 0xfed90000, size = 0x00001000 [DEBUG] SA MMIO resource: VTVC0BAR -> base = 0xfed91000, size = 0x00001000 [INFO ] Available memory above 4GB: 6112M [INFO ] Done reading resources. [INFO ] === Resource allocator: DOMAIN: 00000000 - Pass 1 (relative placement) === [DEBUG] PCI: 00:00:1c.0 io: size: 0 align: 12 gran: 12 limit: ffff [DEBUG] PCI: 00:00:1c.0 io: size: 0 align: 12 gran: 12 limit: ffff done [DEBUG] PCI: 00:00:1c.0 mem: size: 0 align: 20 gran: 20 limit: ffffffff [DEBUG] PCI: 00:00:1c.0 mem: size: 0 align: 20 gran: 20 limit: ffffffff done [DEBUG] PCI: 00:00:1c.0 prefmem: size: 0 align: 20 gran: 20 limit: ffffffffffffffff [DEBUG] PCI: 00:00:1c.0 prefmem: size: 0 align: 20 gran: 20 limit: ffffffffffffffff done [INFO ] === Resource allocator: DOMAIN: 00000000 - Pass 2 (allocating resources) === [DEBUG] DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff [DEBUG] avoid_fixed_resources: PCI: 00:00:1f.0 00 base 00000000 limit 00000fff io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:1f.0 84 base 00000080 limit 0000008f io (fixed) [DEBUG] avoid_fixed_resources: PNP: 002e.2 60 base 000003f8 limit 000003ff io (fixed) [DEBUG] avoid_fixed_resources: PNP: 002e.a 60 base 00000a10 limit 00000a17 io (fixed) [DEBUG] avoid_fixed_resources: PNP: 002e.b 60 base 00000a20 limit 00000a27 io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:1f.2 40 base 00001800 limit 000018ff io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:1f.4 20 base 0000efa0 limit 0000efbf io (fixed) [INFO ] DOMAIN: 00000000: Resource ranges: [INFO ] * Base: 1000, Size: 800, Tag: 100 [INFO ] * Base: 1900, Size: d6a0, Tag: 100 [INFO ] * Base: efc0, Size: 1040, Tag: 100 [DEBUG] PCI: 00:00:02.0 20 * [0x1000 - 0x103f] limit: 103f io [DEBUG] PCI: 00:00:17.0 20 * [0x1040 - 0x105f] limit: 105f io [DEBUG] PCI: 00:00:17.0 18 * [0x1060 - 0x1067] limit: 1067 io [DEBUG] PCI: 00:00:17.0 1c * [0x1068 - 0x106b] limit: 106b io [DEBUG] DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done [DEBUG] DOMAIN: 00000000 mem: base: 7b000000 size: 0 align: 0 gran: 0 limit: dfffffff [DEBUG] DOMAIN: 00000000 mem: base: 100000000 size: 0 align: 0 gran: 0 limit: 7fffffffff [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 00 base e0000000 limit efffffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 01 base fed10000 limit fed17fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 02 base fed18000 limit fed18fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 03 base fed19000 limit fed19fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 04 base fed84000 limit fed84fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 05 base fed80000 limit fed83fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 06 base fed90000 limit fed90fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 07 base fed91000 limit fed91fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 08 base 00000000 limit 0009ffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 09 base 000c0000 limit 7affffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 0a base 7b000000 limit 7fffffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 0b base 100000000 limit 27dffffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 0c base 000a0000 limit 000bffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 0d base 000c0000 limit 000fffff mem (fixed) [DEBUG] avoid_fixed_resources: PNP: 0c31.0 00 base fed40000 limit fed44fff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:1f.1 10 base fd000000 limit fdffffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:1f.2 48 base fe000000 limit fe00ffff mem (fixed) [INFO ] DOMAIN: 00000000: Resource ranges: [INFO ] * Base: 80000000, Size: 60000000, Tag: 200 [INFO ] * Base: 27e000000, Size: 7d82000000, Tag: 200 [DEBUG] PCI: 00:00:02.0 18 * [0x80000000 - 0x8fffffff] limit: 8fffffff prefmem [DEBUG] PCI: 00:00:02.0 10 * [0x90000000 - 0x90ffffff] limit: 90ffffff mem [DEBUG] PCI: 00:00:1f.6 10 * [0x91000000 - 0x9101ffff] limit: 9101ffff mem [DEBUG] PCI: 00:00:14.0 10 * [0x91020000 - 0x9102ffff] limit: 9102ffff mem [DEBUG] PCI: 00:00:1f.3 20 * [0x91030000 - 0x9103ffff] limit: 9103ffff mem [DEBUG] PCI: 00:00:04.0 10 * [0x91040000 - 0x91047fff] limit: 91047fff mem [DEBUG] PCI: 00:00:1f.2 10 * [0x91048000 - 0x9104bfff] limit: 9104bfff mem [DEBUG] PCI: 00:00:1f.3 10 * [0x9104c000 - 0x9104ffff] limit: 9104ffff mem [DEBUG] PCI: 00:00:17.0 10 * [0x91050000 - 0x91051fff] limit: 91051fff mem [DEBUG] PCI: 00:00:08.0 10 * [0x91052000 - 0x91052fff] limit: 91052fff mem [DEBUG] PCI: 00:00:14.2 10 * [0x91053000 - 0x91053fff] limit: 91053fff mem [DEBUG] PCI: 00:00:16.0 10 * [0x91054000 - 0x91054fff] limit: 91054fff mem [DEBUG] PCI: 00:00:17.0 24 * [0x91055000 - 0x910557ff] limit: 910557ff mem [DEBUG] PCI: 00:00:17.0 14 * [0x91056000 - 0x910560ff] limit: 910560ff mem [DEBUG] PCI: 00:00:1f.4 10 * [0x91057000 - 0x910570ff] limit: 910570ff mem [DEBUG] DOMAIN: 00000000 mem: base: 7b000000 size: 0 align: 0 gran: 0 limit: dfffffff done [DEBUG] DOMAIN: 00000000 mem: base: 100000000 size: 0 align: 0 gran: 0 limit: 7fffffffff done [INFO ] === Resource allocator: DOMAIN: 00000000 - resource allocation complete === [DEBUG] PCI: 00:00:02.0 10 <- [0x0000000090000000 - 0x0000000090ffffff] size 0x01000000 gran 0x18 mem64 [DEBUG] PCI: 00:00:02.0 18 <- [0x0000000080000000 - 0x000000008fffffff] size 0x10000000 gran 0x1c prefmem64 [DEBUG] PCI: 00:00:02.0 20 <- [0x0000000000001000 - 0x000000000000103f] size 0x00000040 gran 0x06 io [DEBUG] PCI: 00:00:04.0 10 <- [0x0000000091040000 - 0x0000000091047fff] size 0x00008000 gran 0x0f mem64 [DEBUG] PCI: 00:00:08.0 10 <- [0x0000000091052000 - 0x0000000091052fff] size 0x00001000 gran 0x0c mem64 [DEBUG] PCI: 00:00:14.0 10 <- [0x0000000091020000 - 0x000000009102ffff] size 0x00010000 gran 0x10 mem64 [DEBUG] PCI: 00:00:14.2 10 <- [0x0000000091053000 - 0x0000000091053fff] size 0x00001000 gran 0x0c mem64 [DEBUG] PCI: 00:00:16.0 10 <- [0x0000000091054000 - 0x0000000091054fff] size 0x00001000 gran 0x0c mem64 [DEBUG] PCI: 00:00:17.0 10 <- [0x0000000091050000 - 0x0000000091051fff] size 0x00002000 gran 0x0d mem [DEBUG] PCI: 00:00:17.0 14 <- [0x0000000091056000 - 0x00000000910560ff] size 0x00000100 gran 0x08 mem [DEBUG] PCI: 00:00:17.0 18 <- [0x0000000000001060 - 0x0000000000001067] size 0x00000008 gran 0x03 io [DEBUG] PCI: 00:00:17.0 1c <- [0x0000000000001068 - 0x000000000000106b] size 0x00000004 gran 0x02 io [DEBUG] PCI: 00:00:17.0 20 <- [0x0000000000001040 - 0x000000000000105f] size 0x00000020 gran 0x05 io [DEBUG] PCI: 00:00:17.0 24 <- [0x0000000091055000 - 0x00000000910557ff] size 0x00000800 gran 0x0b mem [DEBUG] PCI: 00:00:1c.0 1c <- [0x000000000000ffff - 0x000000000000fffe] size 0x00000000 gran 0x0c seg 00 buio [DEBUG] PCI: 00:00:1c.0 24 <- [0xffffffffffffffff - 0xfffffffffffffffe] size 0x00000000 gran 0x14 seg 00 buprefmem [DEBUG] PCI: 00:00:1c.0 20 <- [0x00000000ffffffff - 0x00000000fffffffe] size 0x00000000 gran 0x14 seg 00 bumem [DEBUG] PNP: 002e.2 60 <- [0x00000000000003f8 - 0x00000000000003ff] size 0x00000008 gran 0x03 io [DEBUG] PNP: 002e.2 70 <- [0x0000000000000003 - 0x0000000000000003] size 0x00000001 gran 0x00 irq [NOTE ] PNP: 002e.2 f0 irq size: 0x0000000001 not assigned in devicetree [DEBUG] PNP: 002e.a 60 <- [0x0000000000000a10 - 0x0000000000000a17] size 0x00000008 gran 0x03 io [NOTE ] PNP: 002e.a 70 irq size: 0x0000000001 not assigned in devicetree [DEBUG] PNP: 002e.b 60 <- [0x0000000000000a20 - 0x0000000000000a27] size 0x00000008 gran 0x03 io [NOTE ] PNP: 002e.b 70 irq size: 0x0000000001 not assigned in devicetree [DEBUG] PNP: 002e.e e4 <- [0x0000000000000010 - 0x000000000000000f] size 0x00000000 gran 0x00 irq [DEBUG] PNP: 002e.e e5 <- [0x0000000000000009 - 0x0000000000000008] size 0x00000000 gran 0x00 irq [DEBUG] LPC: enabling default decode range LPC_IOE_COMA_EN [DEBUG] LPC: Opened IO window LGIR1: base a10 size 8 [DEBUG] LPC: Opened IO window LGIR2: base a20 size 8 [DEBUG] PCI: 00:00:1f.2 10 <- [0x0000000091048000 - 0x000000009104bfff] size 0x00004000 gran 0x0e mem [DEBUG] PCI: 00:00:1f.3 10 <- [0x000000009104c000 - 0x000000009104ffff] size 0x00004000 gran 0x0e mem64 [DEBUG] PCI: 00:00:1f.3 20 <- [0x0000000091030000 - 0x000000009103ffff] size 0x00010000 gran 0x10 mem64 [DEBUG] PCI: 00:00:1f.4 10 <- [0x0000000091057000 - 0x00000000910570ff] size 0x00000100 gran 0x08 mem64 [DEBUG] PCI: 00:00:1f.6 10 <- [0x0000000091000000 - 0x000000009101ffff] size 0x00020000 gran 0x11 mem [INFO ] Done setting resources. [INFO ] Done allocating resources. [DEBUG] BS: BS_DEV_RESOURCES run times (exec / console): 3 / 961 ms [INFO ] Enabling resources... [DEBUG] PCI: 00:00:00.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:00.0 cmd <- 06 [DEBUG] PCI: 00:00:02.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:02.0 cmd <- 03 [DEBUG] PCI: 00:00:04.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:04.0 cmd <- 02 [DEBUG] PCI: 00:00:08.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:08.0 cmd <- 06 [DEBUG] PCI: 00:00:14.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:14.0 cmd <- 02 [DEBUG] PCI: 00:00:14.2 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:14.2 cmd <- 02 [DEBUG] PCI: 00:00:16.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:16.0 cmd <- 02 [DEBUG] PCI: 00:00:17.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:17.0 cmd <- 03 [DEBUG] PCI: 00:00:1c.0 bridge ctrl <- 0013 [DEBUG] PCI: 00:00:1c.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:1c.0 cmd <- 00 [DEBUG] PCI: 00:00:1f.0 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:1f.0 cmd <- 07 [DEBUG] PCI: 00:00:1f.2 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:1f.2 cmd <- 06 [DEBUG] PCI: 00:00:1f.3 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:1f.3 cmd <- 02 [DEBUG] PCI: 00:00:1f.4 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:1f.4 cmd <- 03 [DEBUG] PCI: 00:00:1f.6 subsystem <- 17aa/30d0 [DEBUG] PCI: 00:00:1f.6 cmd <- 02 [INFO ] done. [DEBUG] BS: BS_DEV_ENABLE run times (exec / console): 0 / 139 ms [DEBUG] ME: Version: 11.0.2.1003 [DEBUG] BS: BS_DEV_ENABLE exit times (exec / console): 37 / 4 ms [INFO ] Initializing devices... [DEBUG] PCI: 00:00:00.0 init [INFO ] CPU TDP = 51 Watts [INFO ] CPU PL1 = 51 Watts [INFO ] CPU PL2 = 65 Watts [DEBUG] PCI: 00:00:00.0 init finished in 10 msecs [DEBUG] PCI: 00:00:02.0 init [INFO ] CBFS: Found 'vbt.bin' @0xca340 size 0x47e in mcache @0x7abdc1e4 [INFO ] Found a VBT of 4608 bytes [INFO ] GMA: Found VBT in CBFS [INFO ] GMA: Found valid VBT in CBFS [INFO ] framebuffer_info: bytes_per_line: 7680, bits_per_pixel: 32 [INFO ] x_res x y_res: 1920 x 1200, size: 9216000 at 0x80000000 [DEBUG] PCI: 00:00:02.0 init finished in 178 msecs [DEBUG] PCI: 00:00:04.0 init [DEBUG] PCI: 00:00:04.0 init finished in 0 msecs [DEBUG] PCI: 00:00:08.0 init [DEBUG] PCI: 00:00:08.0 init finished in 0 msecs [DEBUG] PCI: 00:00:14.0 init [DEBUG] PCI: 00:00:14.0 init finished in 0 msecs [DEBUG] PCI: 00:00:14.2 init [DEBUG] PCI: 00:00:14.2 init finished in 0 msecs [DEBUG] PCI: 00:00:16.0 init [DEBUG] PCI: 00:00:16.0 init finished in 0 msecs [DEBUG] PCI: 00:00:1c.0 init [DEBUG] Initializing PCH PCIe bridge. [DEBUG] PCI: 00:00:1c.0 init finished in 4 msecs [DEBUG] PCI: 00:00:1f.0 init [DEBUG] IOAPIC: Initializing IOAPIC at fec00000 [DEBUG] IOAPIC: ID = 0x00 [DEBUG] IOAPIC: 120 interrupts [DEBUG] IOAPIC: Clearing IOAPIC at fec00000 [DEBUG] IOAPIC: Bootstrap Processor Local APIC = 0x00 [DEBUG] PCI: 00:00:1f.0 init finished in 23 msecs [DEBUG] PCI: 00:00:1f.2 init [DEBUG] RTC Init [INFO ] Set power on after power failure. [DEBUG] apm_control: Disabling ACPI. [DEBUG] APMC done. [DEBUG] Disabling Deep S3 [DEBUG] Disabling Deep S3 [DEBUG] Enabling Deep S4 [DEBUG] Enabling Deep S4 [DEBUG] Enabling Deep S5 [DEBUG] Enabling Deep S5 [DEBUG] PCI: 00:00:1f.2 init finished in 35 msecs [DEBUG] PCI: 00:00:1f.3 init [DEBUG] azalia_audio: base = 0x9104c000 [DEBUG] azalia_audio: codec_mask = 0x06 [DEBUG] azalia_audio: initializing codec #2... [DEBUG] azalia_audio: - vendor/device id: 0x8086280b [DEBUG] azalia_audio: - no verb! [DEBUG] azalia_audio: initializing codec #1... [DEBUG] azalia_audio: - vendor/device id: 0x10ec0233 [DEBUG] azalia_audio: - verb size: 44 [DEBUG] azalia_audio: - verb loaded [DEBUG] PCI: 00:00:1f.3 init finished in 48 msecs [DEBUG] PCI: 00:00:1f.4 init [DEBUG] PCI: 00:00:1f.4 init finished in 0 msecs [DEBUG] PCI: 00:00:1f.6 init [DEBUG] PCI: 00:00:1f.6 init finished in 0 msecs [DEBUG] PNP: 002e.2 init [DEBUG] PNP: 002e.2 init finished in 0 msecs [DEBUG] PNP: 002e.a init [INFO ] set power on after power fail [DEBUG] PNP: 002e.a init finished in 5 msecs [DEBUG] PNP: 002e.b init [DEBUG] PNP: 002e.b init finished in 0 msecs [DEBUG] PNP: 002e.e init [DEBUG] PNP: 002e.e init finished in 0 msecs [INFO ] Devices initialized [DEBUG] BS: BS_DEV_INIT run times (exec / console): 155 / 307 ms [DEBUG] TPM: Startup [DEBUG] TPM: command 0x99 returned 0x0 [DEBUG] TPM: Asserting physical presence [DEBUG] TPM: command 0x4000000a returned 0x0 [DEBUG] TPM: command 0x65 returned 0x0 [DEBUG] TPM: flags disable=0, deactivated=0, nvlocked=1 [INFO ] TPM: setup succeeded [DEBUG] BS: BS_DEV_INIT exit times (exec / console): 3 / 31 ms [INFO ] Finalize devices... [DEBUG] PCI: 00:00:02.0 final [DEBUG] PCI: 00:00:16.0 final [DEBUG] PCI: 00:00:17.0 final [DEBUG] PCI: 00:00:1f.2 final [DEBUG] PCI: 00:00:1f.4 final [INFO ] Devices finalized [DEBUG] BS: BS_POST_DEVICE run times (exec / console): 0 / 25 ms [INFO ] CBFS: Found 'fallback/dsdt.aml' @0xc73c0 size 0x2f48 in mcache @0x7abdc1b8 [WARN ] CBFS: 'fallback/slic' not found. [INFO ] ACPI: Writing ACPI tables at 7aa00000. [DEBUG] ACPI: * FACS [DEBUG] SCI is IRQ 9, GSI 9 [DEBUG] ACPI: * FACP [DEBUG] ACPI: added table 1/32, length now 44 [DEBUG] Found 1 CPU(s) with 2/4 physical/logical core(s) each. [DEBUG] PSS: 3900MHz power 51000 control 0x2700 status 0x2700 [DEBUG] PSS: 3800MHz power 49077 control 0x2600 status 0x2600 [DEBUG] PSS: 3300MHz power 40212 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 32105 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2300MHz power 24812 control 0x1700 status 0x1700 [DEBUG] PSS: 1800MHz power 18221 control 0x1200 status 0x1200 [DEBUG] PSS: 1300MHz power 12329 control 0xd00 status 0xd00 [DEBUG] PSS: 800MHz power 7088 control 0x800 status 0x800 [DEBUG] PSS: 3900MHz power 51000 control 0x2700 status 0x2700 [DEBUG] PSS: 3800MHz power 49077 control 0x2600 status 0x2600 [DEBUG] PSS: 3300MHz power 40212 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 32105 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2300MHz power 24812 control 0x1700 status 0x1700 [DEBUG] PSS: 1800MHz power 18221 control 0x1200 status 0x1200 [DEBUG] PSS: 1300MHz power 12329 control 0xd00 status 0xd00 [DEBUG] PSS: 800MHz power 7088 control 0x800 status 0x800 [DEBUG] PSS: 3900MHz power 51000 control 0x2700 status 0x2700 [DEBUG] PSS: 3800MHz power 49077 control 0x2600 status 0x2600 [DEBUG] PSS: 3300MHz power 40212 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 32105 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2300MHz power 24812 control 0x1700 status 0x1700 [DEBUG] PSS: 1800MHz power 18221 control 0x1200 status 0x1200 [DEBUG] PSS: 1300MHz power 12329 control 0xd00 status 0xd00 [DEBUG] PSS: 800MHz power 7088 control 0x800 status 0x800 [DEBUG] PSS: 3900MHz power 51000 control 0x2700 status 0x2700 [DEBUG] PSS: 3800MHz power 49077 control 0x2600 status 0x2600 [DEBUG] PSS: 3300MHz power 40212 control 0x2100 status 0x2100 [DEBUG] PSS: 2800MHz power 32105 control 0x1c00 status 0x1c00 [DEBUG] PSS: 2300MHz power 24812 control 0x1700 status 0x1700 [DEBUG] PSS: 1800MHz power 18221 control 0x1200 status 0x1200 [DEBUG] PSS: 1300MHz power 12329 control 0xd00 status 0xd00 [DEBUG] PSS: 800MHz power 7088 control 0x800 status 0x800 [DEBUG] PCI space above 4GB MMIO is at 0x27e000000, len = 0x7d82000000 [DEBUG] Empty min sleep state array returned [INFO ] Returning default LPI constraint package [INFO ] \_SB.PCI0.PEPD: Intel Power Engine Plug-in [INFO ] \_SB.PCI0.RP01: WIFI Device GENERIC: 0.0 [DEBUG] PPI: Pending OS request: 0x78c18f7c (0x68f0031f) [DEBUG] PPI: OS response: CMD 0x7081873c = 0x60f0021f [INFO ] \_SB_.PCI0.TPM: LPC TPM PNP: 0c31.0 [DEBUG] ACPI: * SSDT [DEBUG] ACPI: added table 2/32, length now 52 [DEBUG] ACPI: * MCFG [DEBUG] ACPI: added table 3/32, length now 60 [DEBUG] TCPA log created at 0x7a9f0000 [DEBUG] ACPI: * TCPA [DEBUG] ACPI: added table 4/32, length now 68 [DEBUG] ACPI: * LPIT [DEBUG] ACPI: added table 5/32, length now 76 [DEBUG] IOAPIC: 120 interrupts [DEBUG] SCI is IRQ 9, GSI 9 [DEBUG] ACPI: * APIC [DEBUG] ACPI: added table 6/32, length now 84 [DEBUG] ACPI: * SPCR [DEBUG] ACPI: added table 7/32, length now 92 [DEBUG] current = 7aa047b0 [DEBUG] ACPI: * DMAR [DEBUG] ACPI: added table 8/32, length now 100 [DEBUG] acpi_write_dbg2_pci_uart: Device not found [DEBUG] ACPI: * HPET [DEBUG] ACPI: added table 9/32, length now 108 [INFO ] ACPI: done. [DEBUG] ACPI tables: 18560 bytes. [DEBUG] smbios_write_tables: 7a9e8000 [DEBUG] SMBIOS firmware version is set to coreboot_version: '24.08-272-g735ca7f24ad4' [INFO ] Create SMBIOS type 16 [INFO ] Create SMBIOS type 17 [INFO ] Create SMBIOS type 20 [INFO ] GENERIC: 0.0 (WIFI Device) [DEBUG] SMBIOS tables: 1075 bytes. [DEBUG] Writing table forward entry at 0x00000500 [DEBUG] Wrote coreboot table at: 0x00000500, 0x10 bytes, checksum 453c [DEBUG] Writing coreboot table at 0x7aa24000 [DEBUG] 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES [DEBUG] 1. 0000000000001000-000000000009ffff: RAM [DEBUG] 2. 00000000000a0000-00000000000fffff: RESERVED [DEBUG] 3. 0000000000100000-000000007a9e7fff: RAM [DEBUG] 4. 000000007a9e8000-000000007aa7efff: CONFIGURATION TABLES [DEBUG] 5. 000000007aa7f000-000000007abccfff: RAMSTAGE [DEBUG] 6. 000000007abcd000-000000007affffff: CONFIGURATION TABLES [DEBUG] 7. 000000007b000000-000000007fffffff: RESERVED [DEBUG] 8. 00000000e0000000-00000000efffffff: RESERVED [DEBUG] 9. 00000000fd000000-00000000fe00ffff: RESERVED [DEBUG] 10. 00000000fed10000-00000000fed19fff: RESERVED [DEBUG] 11. 00000000fed40000-00000000fed44fff: RESERVED [DEBUG] 12. 00000000fed80000-00000000fed84fff: RESERVED [DEBUG] 13. 00000000fed90000-00000000fed91fff: RESERVED [DEBUG] 14. 0000000100000000-000000027dffffff: RAM [DEBUG] FMAP: area SMMSTORE found @ 810000 (262144 bytes) [DEBUG] smm store: 4 # blocks with size 0x10000 [DEBUG] Wrote coreboot table at: 0x7aa24000, 0x534 bytes, checksum 3a46 [DEBUG] coreboot table: 1356 bytes. [DEBUG] IMD ROOT 0. 0x7afff000 0x00001000 [DEBUG] IMD SMALL 1. 0x7affe000 0x00001000 [DEBUG] FSP MEMORY 2. 0x7abfe000 0x00400000 [DEBUG] CONSOLE 3. 0x7abde000 0x00020000 [DEBUG] TIME STAMP 4. 0x7abdd000 0x00000910 [DEBUG] RO MCACHE 5. 0x7abdc000 0x00000364 [DEBUG] MEM INFO 6. 0x7abdb000 0x00000f48 [DEBUG] AFTER CAR 7. 0x7abcd000 0x0000e000 [DEBUG] RAMSTAGE 8. 0x7aa7e000 0x0014f000 [DEBUG] REFCODE 9. 0x7aa50000 0x0002e000 [DEBUG] SMM BACKUP 10. 0x7aa40000 0x00010000 [DEBUG] SMM COMBUFFER11. 0x7aa30000 0x00010000 [DEBUG] IGD OPREGION12. 0x7aa2c000 0x000030c8 [DEBUG] COREBOOT 13. 0x7aa24000 0x00008000 [DEBUG] ACPI 14. 0x7aa00000 0x00024000 [DEBUG] TCPA TCGLOG15. 0x7a9f0000 0x00010000 [DEBUG] SMBIOS 16. 0x7a9e8000 0x00008000 [DEBUG] IMD small region: [DEBUG] IMD ROOT 0. 0x7affec00 0x00000400 [DEBUG] POWER STATE 1. 0x7affebc0 0x00000040 [DEBUG] FMAP 2. 0x7affea20 0x00000188 [DEBUG] FSP RUNTIME 3. 0x7affea00 0x00000004 [DEBUG] FSPM VERSION 4. 0x7affe9e0 0x00000004 [DEBUG] ROMSTAGE 5. 0x7affe9c0 0x00000004 [DEBUG] ROMSTG STCK 6. 0x7affe900 0x000000a8 [DEBUG] ACPI GNVS 7. 0x7affe8c0 0x00000038 [DEBUG] TPM PPI 8. 0x7affe760 0x0000015a [DEBUG] BS: BS_WRITE_TABLES run times (exec / console): 3 / 682 ms [INFO ] LAPIC 0x0 in XAPIC mode. [DEBUG] MTRR: Physical address space: [DEBUG] 0x0000000000000000 - 0x000000000009ffff size 0x000a0000 type 6 [DEBUG] 0x00000000000a0000 - 0x00000000000bffff size 0x00020000 type 0 [DEBUG] 0x00000000000c0000 - 0x000000007affffff size 0x7af40000 type 6 [DEBUG] 0x000000007b000000 - 0x000000007fffffff size 0x05000000 type 0 [DEBUG] 0x0000000080000000 - 0x000000008fffffff size 0x10000000 type 1 [DEBUG] 0x0000000090000000 - 0x00000000ffffffff size 0x70000000 type 0 [DEBUG] 0x0000000100000000 - 0x000000027dffffff size 0x17e000000 type 6 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x250 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x258 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x259 0x0000000000000000 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x268 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x269 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26a 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26b 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26c 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26d 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26e 0x0606060606060606 [DEBUG] apic_id 0x0: MTRR: Fixed MSR 0x26f 0x0606060606060606 [DEBUG] apic_id 0x0 setup mtrr for CPU physical address size: 39 bits [DEBUG] MTRR: default type WB/UC MTRR counts: 6/6. [DEBUG] MTRR: UC selected as default type. [DEBUG] MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 [DEBUG] MTRR: 1 base 0x000000007b000000 mask 0x0000007fff000000 type 0 [DEBUG] MTRR: 2 base 0x000000007c000000 mask 0x0000007ffc000000 type 0 [DEBUG] MTRR: 3 base 0x0000000080000000 mask 0x0000007ff0000000 type 1 [DEBUG] MTRR: 4 base 0x0000000100000000 mask 0x0000007f00000000 type 6 [DEBUG] MTRR: 5 base 0x0000000200000000 mask 0x0000007f80000000 type 6 [INFO ] LAPIC 0x1 in XAPIC mode. [INFO ] LAPIC 0x2 in XAPIC mode. [INFO ] LAPIC 0x3 in XAPIC mode. [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x250 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x258 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x259 0x0000000000000000 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x268 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x269 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x26a 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x26b 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x26c 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x26d 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x26e 0x0606060606060606 [DEBUG] apic_id 0x2: MTRR: Fixed MSR 0x26f 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x250 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x258 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x259 0x0000000000000000 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x268 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x269 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x26a 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x26b 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x26c 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x26d 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x26e 0x0606060606060606 [DEBUG] apic_id 0x1: MTRR: Fixed MSR 0x26f 0x0606060606060606 [DEBUG] apic_id 0x2 setup mtrr for CPU physical address size: 39 bits [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x250 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x258 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x259 0x0000000000000000 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x268 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x269 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x26a 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x26b 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x26c 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x26d 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x26e 0x0606060606060606 [DEBUG] apic_id 0x3: MTRR: Fixed MSR 0x26f 0x0606060606060606 [DEBUG] apic_id 0x1 setup mtrr for CPU physical address size: 39 bits [DEBUG] apic_id 0x3 setup mtrr for CPU physical address size: 39 bits [DEBUG] MTRR: TEMPORARY Physical address space: [DEBUG] 0x0000000000000000 - 0x000000000009ffff size 0x000a0000 type 6 [DEBUG] 0x00000000000a0000 - 0x00000000000bffff size 0x00020000 type 0 [DEBUG] 0x00000000000c0000 - 0x000000007affffff size 0x7af40000 type 6 [DEBUG] 0x000000007b000000 - 0x00000000ff7fffff size 0x84800000 type 0 [DEBUG] 0x00000000ff800000 - 0x00000000ffffffff size 0x00800000 type 5 [DEBUG] 0x0000000100000000 - 0x000000027dffffff size 0x17e000000 type 6 [DEBUG] MTRR: default type WB/UC MTRR counts: 11/6. [DEBUG] MTRR: UC selected as default type. [DEBUG] MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 [DEBUG] MTRR: 1 base 0x000000007b000000 mask 0x0000007fff000000 type 0 [DEBUG] MTRR: 2 base 0x000000007c000000 mask 0x0000007ffc000000 type 0 [DEBUG] MTRR: 3 base 0x00000000ff800000 mask 0x0000007fff800000 type 5 [DEBUG] MTRR: 4 base 0x0000000100000000 mask 0x0000007f00000000 type 6 [DEBUG] MTRR: 5 base 0x0000000200000000 mask 0x0000007f80000000 type 6 [DEBUG] MTRR check [DEBUG] Fixed MTRRs : Enabled [DEBUG] Variable MTRRs: Enabled [DEBUG] BS: BS_WRITE_TABLES exit times (exec / console): 205 / 308 ms [INFO ] CBFS: Found 'fallback/payload' @0x1586c0 size 0x151e6b in mcache @0x7abdc2f4 [DEBUG] Checking segment from ROM address 0xff9a88ec [DEBUG] Checking segment from ROM address 0xff9a8908 [DEBUG] Loading segment from ROM address 0xff9a88ec [DEBUG] code (compression=1) [DEBUG] New segment dstaddr 0x00800000 memsize 0x1000000 srcaddr 0xff9a8924 filesize 0x151e33 [DEBUG] Loading Segment: addr: 0x00800000 memsz: 0x0000000001000000 filesz: 0x0000000000151e33 [DEBUG] using LZMA [DEBUG] Loading segment from ROM address 0xff9a8908 [DEBUG] Entry Point 0x008016da [DEBUG] BS: BS_PAYLOAD_LOAD run times (exec / console): 135 / 60 ms [DEBUG] Finalizing chipset. [DEBUG] ME: Host Firmware Status Register 1 : 0x90000245 [DEBUG] ME: Host Firmware Status Register 2 : 0x83108106 [DEBUG] ME: Host Firmware Status Register 3 : 0x00000300 [DEBUG] ME: Host Firmware Status Register 4 : 0x00084000 [DEBUG] ME: Host Firmware Status Register 5 : 0x00000000 [DEBUG] ME: Host Firmware Status Register 6 : 0x40000000 [DEBUG] ME: FW Partition Table : OK [DEBUG] ME: Bringup Loader Failure : NO [DEBUG] ME: Firmware Init Complete : YES [DEBUG] ME: Manufacturing Mode : NO [DEBUG] ME: Boot Options Present : NO [DEBUG] ME: Update In Progress : NO [DEBUG] ME: D3 Support : NO [DEBUG] ME: D0i3 Support : YES [DEBUG] ME: Low Power State Enabled : NO [DEBUG] ME: CPU Replaced : NO [DEBUG] ME: CPU Replacement Valid : YES [DEBUG] ME: Current Working State : Normal [DEBUG] ME: Current Operation State : M0 with UMA [DEBUG] ME: Current Operation Mode : Normal [DEBUG] ME: Error Code : No Error [DEBUG] ME: Progress Phase : Unknown (8) [DEBUG] ME: Power Management Event : Global reset after an error [DEBUG] ME: Progress Phase State : Unknown phase: 0x08 state: 0x10 [DEBUG] ME: Power Down Mitigation : NO [DEBUG] ME: Firmware SKU : Unknown (0x0) [DEBUG] ME: FPF status : fused [DEBUG] apm_control: Finalizing SMM. [DEBUG] APMC done. [DEBUG] BS: BS_PAYLOAD_LOAD exit times (exec / console): 10 / 153 ms [DEBUG] mp_park_aps done after 0 msecs. [DEBUG] Jumping to boot code at 0x008016da(0x7aa24000)` I tried many many parameters, but results are always the same. -- 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 9

[coreboot - Bug #548] (New) Computer Fails To Recognize Upgraded WiFi Card
by Jeremy Brown 19 Oct '24

19 Oct '24

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 10

2024-10-16 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 17 Oct '24

17 Oct '24

# 2024-10-16 - coreboot Leadership Meeting ## Attendees Werner Zeh, Matt DeVillier, Felix Held, Ron Minnich, Mina Asante, Maximilian Brune, Felix Singer, Alicja Michalska, Jason Glenesk, Marshall Dawson, David Hendricks. ## Open Action Items * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. * Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api](https://review.core… * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [dhendrix] Should we add something in the code of conduct about autism or other conditions that may warrant limited exceptions? * This is something Angel brought up in the e-mail thread regarding a recent disciplinary action. A reasonable accommodation may be good to carve out. That leaves some open questions, however, like how do we know that somebody is really having this condition (e.g. doctor's note?) and not using it as an excuse? Also, what would such accommodations look like? SFC has offered to get us in touch with their director of DEI who can help craft policy for this sort of thing * [Alicja & others] Not a good idea to ask for documentation of a condition due to privacy, people gaming it, discrimination concerns, etc. * Code of conduct came as part of joining SFC. That was quite some time ago, maybe they have some updated language we can use. ### [Sheng] coreboot documentation automation build has been broken for ages. What has to be done to fix it? * FelixS.: Documentation system was converted a while ago (still Sphinx but uses a different parser now because the former was deprecated), noted too late to apply reverts. Now there seems to be a lot of errors which need fixing. * Matt: Has the conversion tool from markdown to html changed? * FelixS.: No, the parser changed. It runs locally but has issues to run on the server * Matt: Currently our repo is out of sync with the doc page. * FelixS. Needs to fix it on the coreboot server (understand why the docker-image isn’t working in our environment) * Werner: Isn’t there a builder for the documentation repo? * FelixS.: There is a dummy-builder around which does not really do anything. It Was planned to integrate it in the future but never happened. * Matt: Any plans to improve this to enable us to catch issues upfront? * FelixS.: Yes, planned but not yet started. ### [WernerZ] Shall we add a policy which will encourage fixing automated code scanner findings (like coverity or scan-build) even if the findings are not very likely to happen in the real world? * Max: Difficult, changing something just because a test found it might not be the right thing to do. It could be a false-positive. We should not just patch in order to make coverity happy. * Matt: Second Max, currently going through a nightmare at AMD fixing coevrity issues. It often makes code harder to read while does not solve any real problem. * David: Maybe we can constrain where coverity scans in the tree? EDK -code can be a source of coverity-findings because coverity does not understand the code flow properly. * FelixH.: Looked at AMD code in coreboot a few years ago, did not have the impression that many coverity issues are found there (mostly 32 to 64 bit issues) * Matt: Let’s exclude submodules and vendorcode from coverity and see how it flies. * Max: Good idea to limit the tree that is scanned by coverity * David: BTW, we had a GSoC project about coverity a few years ago. Jacob did some good write-ups and found 172 real issues, ignored 91. There may be some ideas for how to filter out false positives: (https://blogs.coreboot.org/blog/2019/08/22/gsoc-coreboot-coverity-final-upd…) * FelixH.: Used his github account to log in into coverity and then was asked by coverity to grant wider github account access rights. Why is that needed? Looks fishy. * What's up with coverity scan e-mails? Need to check with Martin about this… ### [Alicja] Do we have something in place that requires maintainers to build and run testing boards to make sure that the images are still able to boot with TOT? * Max: Hard to get some older boards sometimes, how to enforce a run test? And there is not always a maintainer for every board. * David: We decided a few years ago to drop boards that seem to not be maintained anymore (after >2 releases?) * FelixH. Tried to use board-status and it was a pain. Please do not drop boards on this basis because bringing a dropped board back in is much harder. → Matt and Max do agree here! * Matt: Need a better way to communicate a board's current status. board-status repo is too cumbersome. * Matt: Shall we set up a separate meeting to discuss board-status alternatives? * Alicja: Good idea, let’s do that * Matt will send out an invite. # Next Leadership Meeting * October 30, 2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 14 Oct '24

14 Oct '24

Dear coreboot community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, October 16, 2024.[1] Kindly take a moment to review the current agenda and share your thoughts or suggest any additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda Items ### [dhendrix] Should we add something in the code of conduct about autism or other conditions that may warrant limited exceptions? * This is something Angel brought up in the e-mail thread regarding a recent disciplinary action. A reasonable accommodation may be good to carve out. That leaves some open questions, however, like how do we know that somebody is really having this condition (e.g. doctor's note?) and not using it as an excuse? Also, what would such accommodations look like? SFC has offered to get us in touch with their director of DEI who can help craft policy for this sort of thing ### [Sheng] Coreboot documentation automation build has been broken for ages. What has to be done to fix it? ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #455] superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D
by Walter Sonius 13 Oct '24

13 Oct '24

Issue #455 has been updated by Walter Sonius. Quick and dirty fix! The same issue on MSI H87-G43 (ms7816 rev1.2) appears, although NCT6779D is supported however not the specific model with ID`0xc563`. In the "nuvoton.c" source file from the "superiotool" alter the ID on line number 551 from `0xc562` to `0xc563`. Since I don't know how to add an extra ID/condition to the source file, this will break detection for someone with the `0xc562` chip. Can someone please do pull request for superiotool? https://github.com/coreboot/coreboot/blob/main/util/superiotool/nuvoton.c ` {0xc562, "NCT6779D", {` replace with ` {0xc563, "NCT6779D", {` The first time using `superiotool` without this fix, it will detect wrongly the Aspeed chipset just like the Original Poster reports but returns `chip_id=0xc563` hinted multiple times. Subsequent runs of the `superiotool` won't find any chipset anymore but will end with `No Super I/O found`... ``` uname -a Linux ubuntu-mate 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 2 20:41:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux sudo dmesg | grep H87 [ 0.000000] DMI: MSI MS-7816/H87-G43 (MS-7816), BIOS V2.9 07/16/2014 sudo superiotool -l | grep 6779 Nuvoton NCT6775F (A) (dump available) Nuvoton NCT6775F (B) / NCT5572D (B) (not all LDNs supported) (dump available) Nuvoton NCT6776F (B) (dump available) Nuvoton NCT6776F/D (C) (dump available) Nuvoton NCT6779D (dump available) <---------------Partly supported sudo superiotool -aV superiotool r Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Aspeed Super I/O at 0x2e... Failed. Returned data: scratch registers all read as 0xff Probing for Aspeed Super I/O at 0x4e... Found Aspeed AST2400 (id=0x00) at 0x4e <----------------Wrong Probing for Exar Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Exar Super I/O at 0x4e... ... truncated output... Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0xc563 <------------------------Hint Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... ...truncated... ``` Fixed superiotool output, replaced line 551 ID c562 > c563 and it will dump/report registers: ``` sudo ./superiotool -dV superiotool r Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Aspeed Super I/O at 0x2e... Failed. Returned data: scratch registers all read as 0xff Probing for Aspeed Super I/O at 0x4e... Failed. Returned data: scratch registers all read as 0xff ...truncated... Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Found Nuvoton NCT6779D (id=0xc563) at 0x4e Register dump: idx 10 11 13 14 1a 1b 1c 1d 20 21 22 24 25 26 27 28 2a 2b 2c 2f val ff ff ff ff 30 70 08 00 c5 63 ff 04 00 40 00 00 40 00 00 0b def ff ff 00 00 30 70 10 00 c5 62 ff 04 00 MM 00 00 c0 00 01 MM LDN 0x01 (Parallel Port) idx 30 60 61 70 74 f0 val 01 03 78 05 04 3c def 01 03 78 07 04 3f LDN 0x02 (UART A) idx 30 60 61 70 f0 f2 val 01 03 f8 04 00 00 def 01 03 f8 04 00 00 LDN 0x03 (UART B, IR) idx 30 60 61 70 f0 f1 f2 val 00 02 f8 03 00 00 00 def 01 02 f8 03 00 00 00 LDN 0x05 (Keyboard Controller) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 83 def 00 00 00 00 00 00 00 83 LDN 0x06 (CIR) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 08 09 32 00 def 00 00 00 00 08 09 32 00 LDN 0x07 (GPIO6, GPIO7, GPIO8) idx e0 e1 e2 e3 e4 e5 e6 e7 ec ed f4 f5 f6 f7 f8 val 73 0f 00 0f ff ff ff ff 00 ff ff ff ff ff ff def 0f 00 00 00 ff 00 00 00 00 00 ff 00 00 00 00 LDN 0x08 (WDT1, GPIO0, GPIO1) idx 30 60 61 e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 val 00 00 00 ff ff ff ff ff ff d8 00 00 00 ff 00 ff def 00 00 00 ff 00 00 00 00 ff 00 00 00 00 00 00 00 LDN 0x09 (GPIO1, GPIO2, GPIO3, GPIO4, GPIO5, GPIO6, GPIO7, GPIO8) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ee f0 f1 f2 f4 f5 f6 f7 fe val be df 60 00 60 7f 06 00 06 00 00 00 c0 00 ff 00 00 3f 00 00 c0 00 def 00 ff 00 00 00 7f 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 00 00 LDN 0x0a (ACPI) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 ee f0 f2 f3 f4 f6 f7 fe val 01 00 00 15 08 02 5c 00 00 00 10 5c 00 00 00 c0 00 def 01 00 00 00 00 02 1c 00 00 00 10 5c 00 00 00 c0 00 LDN 0x0b (Hardware Monitor, Front Panel LED) idx 30 60 61 62 63 70 e0 e1 e2 e4 f0 f1 f2 f5 f6 f7 f8 f9 fa val 01 0a 00 0a 10 00 7f 7f ff 7f 00 00 00 00 00 87 47 00 00 def 00 00 00 00 00 00 7f 7f ff ff 00 00 00 10 00 87 47 00 00 LDN 0x0d (WDT1) idx f0 val 00 def 00 LDN 0x0e (CIR WAKE-UP) idx 30 60 61 70 val 00 00 00 00 def 00 00 00 00 LDN 0x0f (GPIO Push-Pull or Open-drain) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 f0 f1 f2 val ff df 7f ff ff ff 7b ff ff 9d 00 00 def ff ff 7f ff ff ff 0f ff ff 9d 00 00 LDN 0x14 (Port 80 UART) idx e0 e1 e2 e3 e4 val 80 00 00 10 00 def 80 00 00 10 00 LDN 0x16 (Deep Sleep) idx 30 e0 e1 e2 val 20 20 04 05 def 20 20 04 05 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff ...truncated... ``` Other debug info related to lm_sensors and this specific chipset. ``` sudo sensors-detect #truncated output Found `Nuvoton NCT5532D/NCT6779D Super IO Sensors' Success! (address 0xa00, driver `nct6775') Driver `nct6775': * ISA bus, address 0xa00 Chip `Nuvoton NCT5532D/NCT6779D Super IO Sensors' (confidence: 9) sudo modprobe nct6775 sudo dmesg | tail -n 1 [ 506.259692] nct6775: Found NCT6779D or compatible chip at 0x4e:0xa00 sensors radeon-pci-0100 Adapter: PCI adapter temp1: +35.0 C (crit = +120.0 C, hyst = +90.0 C) acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8 C temp2: +29.8 C nct6779-isa-0a00 Adapter: ISA adapter Vcore: 872.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.04 V (min = +0.00 V, max = +0.00 V) ALARM AVCC: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM +3.3V: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1.10 V (min = +0.00 V, max = +0.00 V) ALARM in5: 848.00 mV (min = +0.00 V, max = +0.00 V) ALARM in6: 1.06 V (min = +0.00 V, max = +0.00 V) ALARM 3VSB: 3.44 V (min = +0.00 V, max = +0.00 V) ALARM Vbat: 3.31 V (min = +0.00 V, max = +0.00 V) ALARM in9: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in10: 24.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 0.00 V (min = +0.00 V, max = +0.00 V) in12: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in13: 752.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 784.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 1010 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +27.0 C (high = +0.0 C, hyst = +0.0 C) ALARM sensor = CPU diode CPUTIN: +127.5 C (high = +80.0 C, hyst = +75.0 C) ALARM sensor = CPU diode AUXTIN0: +22.0 C sensor = thermistor AUXTIN1: +127.0 C sensor = thermistor AUXTIN2: -128.0 C sensor = thermistor AUXTIN3: -52.0 C sensor = thermal diode PECI Agent 0: +31.0 C PCH_CHIP_CPU_MAX_TEMP: +0.0 C PCH_CHIP_TEMP: +0.0 C PCH_CPU_TEMP: +0.0 C PCH_MCH_TEMP: +0.0 C PCH_DIM0_TEMP: +0.0 C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled coretemp-isa-0000 Adapter: ISA adapter Package id 0: +32.0 C (high = +80.0 C, crit = +100.0 C) Core 0: +30.0 C (high = +80.0 C, crit = +100.0 C) Core 1: +32.0 C (high = +80.0 C, crit = +100.0 C) ``` ---------------------------------------- Bug #455: superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D https://ticket.coreboot.org/issues/455#change-1941 * Author: shen Liu * Status: New * Priority: Normal * Category: userspace utilities * Target version: master * Start date: 2023-02-07 * Affected versions: master * Needs backport to: none * Related links: More discussion： https://www.reddit.com/r/coreboot/comments/10ud7tk/is_b85me45_ms7817_suppor… https://wiki.archlinux.org/title/Debuginfod * Affected hardware: MSI B85M-E45 * Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.9-1) ---------------------------------------- ``` shell sudo ./superiotool Found Aspeed AST2400 (id=0x00) at 0x4e sudo ./superiotool superiotool r4.19-306-g12ec7901b7 No Super I/O found ``` Does superiotool provide debug symbols? Without debug symbols I can't use gdb to provide more useful information. -- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 11 Oct '24

11 Oct '24

Dear coreboot community, Please note that our upcoming leadership meeting is scheduled for Wednesday, October 16, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante.

1 0

2024_10_09 coreboot Group Review Session
by mina＠coreboot.org 07 Oct '24

07 Oct '24

Hello coreboot! Our next group review session is scheduled for Wednesday, October 9, 2024: https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here’s the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Kindly add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

1 0

Recent disciplinary action taken
by David Hendricks 05 Oct '24

05 Oct '24

Dear coreboot community members, Recently there was some unpleasant activity on Gerrit which violated our community’s guidelines regarding respectful conduct. In this case the coreboot leadership team determined that the behavior in question fit a long pattern about which the individual had been previously warned. As a result we have decided to remove Nico from our community for a period of 1 year. We hope this will be a sufficient cooling off period and that we will not need to take more drastic steps in the future. As we've said in the past, we trust that developers in our community are acting in good faith and can generally resolve issues on their own. In cases where two sides cannot reach an agreement, for example in a code review, we expect all engagement to be respectful and to help drive toward a solution. For technical matters this often means starting a mailing list discussion, bringing an issue up during the coreboot leadership meeting, starting a task force to tackle a large problem, or other means of gathering input and collaborating. Personal matters should be brought to the leadership team directly. We'll listen to any complaints or frustrations, but cannot tolerate personal attacks made on Gerrit, the mailing list, or other forums. It is always required that we treat others in a professional manner and communicate with respect, regardless of how strongly we may feel about a particular issue. If anybody feels that a discussion has become too heated, or that somebody is not being treated respectfully, or are simply unsure of how to proceed in a difficult situation, please reach out to the coreboot leadership and we will chart a path forward together.

11 16

Project departure announcement: Arthur Heymans
by Arthur Heymans 04 Oct '24

04 Oct '24

Hi In light of a recent decision by the coreboot leadership, I would like to announce my departure from the project. I believe the one-year ban of Nico Huber is unjust and a poor decision for the community. Unless professional reasons compel me otherwise, I will be leaving the project for at least the same amount of time. Most of what I did this year was done in my free time. Out of the 104 patches I submitted to main since January, Nico reviewed 49. From a practical standpoint, this is a disaster. I do want to end this chapter on a positive note. I learned so much from this community and have had an incredible experience to be part of it, so thank you a million times! Interacting with this community has been a blast! Learning from people and giving back to others is one of the most rewarding things one can do in life. That's why I believe the future of firmware must be open source. The communities that form around such software align so well with our deep human nature. I think open-source firmware has a really bright future ahead, and I hope to be part of it somehow. I have a cool firmware project in the pipeline that I look forward to sharing one day. Thanks a lot and good luck! Arthur

1 0

Re: Recent disciplinary action taken
by AreYouLoco? 03 Oct '24

03 Oct '24

Hi, I am following project since few years. Happy coreboot user here. And I was hesitating but finally I decided to post to the list. Banning core developer for 1 year because of some disagreements sounds a bit harsh to me. Especially that I used to post questions on the IRC channel and mailing list and Nico was the only that actually took my personal struggles building coreboot as well as helped fixing one issue. If not that I would probabbly pass and walk away from actually using coreboot. And now I recommend it to others. Its not defending. I just would like to express my personal experience here. That we are people. We make mistakes. If someone is not behaving maybe the person has some bad-bad day. Some kind of consecuence should be taken. Because without that we wont learn. Am I wrong? Bit still one year ban seems harsh to me. Thats it. Just my 2 cents. Orest, aka AreYouLoco? On October 3, 2024 2:05:12 PM UTC, coreboot-request(a)coreboot.org wrote: >Send coreboot mailing list submissions to > coreboot(a)coreboot.org > >To subscribe or unsubscribe via email, send a message with subject or >body 'help' to > coreboot-request(a)coreboot.org > >You can reach the person managing the list at > coreboot-owner(a)coreboot.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of coreboot digest..." > >Today's Topics: > > 1. Re: Recent disciplinary action taken (Sergii Dmytruk) > 2. Re: Recent disciplinary action taken (Angel Pons) > 3. 2024-10-02 - coreboot Leadership Meeting Minutes > (mina(a)coreboot.org) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 2 Oct 2024 15:03:42 +0300 >From: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> >Subject: [coreboot] Re: Recent disciplinary action taken >To: Arthur Heymans <arthur(a)aheymans.xyz> >Cc: coreboot(a)coreboot.org >Message-ID: <Zv02njwrZB-HiR0K@MjU3Nj> >Content-Type: text/plain; charset=utf-8 > >Hi > >I second that. First Nico was banned from flashrom, now from coreboot. >I saw no real basis for the previous decision and see none for this one. >I even thought of him being overly nice in our recent interactions. > >In general, he seems to care much more about the projects than many >others and actually put in the effort. This can result in having strong >opinions and disagreements, but that's not a bad thing. > >Regards, >Sergii > >On Wed, Oct 02, 2024 at 11:55:55AM +0200, Arthur Heymans wrote: >> Hi >> >> I am not happy with this decision. >> We are a community with a lot of passionate individuals that differ in >> their communication style. >> Differences in communication styles cause friction, there is no way around >> it. >> Commenting beyond the mere technical on how we treat each other in a >> community is appropriate and not a violation of respectful conduct. >> To the contrary, sometimes a more heated discussion is to be preferred to >> be being "nice" all the time. >> >> I remember on one of my first patches in 2016, that Nico commented that the >> code looked so bad he wanted to cry. >> It's not "nice" but it was really bad code and I learned a lot since then, >> thanks to the honest and truthful communication of the community. >> More direct communication is preferred by lot of people, including myself. >> >> I believe Nico is a good actor in our community and a 1 year ban does more >> harm than good. >> I personally thoroughly enjoy having him as a reviewer. >> >> I ask the leadership to revisit this decision. Coreboot is a hard project >> to get into and driving the most competent people away is not a smart move. >> >> Arthur >> >> On Wed, Oct 2, 2024 at 9:40 AM David Hendricks via coreboot < >> coreboot(a)coreboot.org> wrote: >> >> > Dear coreboot community members, >> > >> > Recently there was some unpleasant activity on Gerrit which violated our >> > community’s guidelines regarding respectful conduct. In this case the >> > coreboot leadership team determined that the behavior in question fit a >> > long pattern about which the individual had been previously warned. As a >> > result we have decided to remove Nico from our community for a period of 1 >> > year. We hope this will be a sufficient cooling off period and that we will >> > not need to take more drastic steps in the future. >> > >> > As we've said in the past, we trust that developers in our community are >> > acting in good faith and can generally resolve issues on their own. In >> > cases where two sides cannot reach an agreement, for example in a code >> > review, we expect all engagement to be respectful and to help drive toward >> > a solution. For technical matters this often means starting a mailing list >> > discussion, bringing an issue up during the coreboot leadership meeting, >> > starting a task force to tackle a large problem, or other means of >> > gathering input and collaborating. >> > >> > Personal matters should be brought to the leadership team directly. We'll >> > listen to any complaints or frustrations, but cannot tolerate personal >> > attacks made on Gerrit, the mailing list, or other forums. It is always >> > required that we treat others in a professional manner and communicate with >> > respect, regardless of how strongly we may feel about a particular issue. >> > >> > If anybody feels that a discussion has become too heated, or that somebody >> > is not being treated respectfully, or are simply unsure of how to proceed >> > in a difficult situation, please reach out to the coreboot leadership and >> > we will chart a path forward together. >> > _______________________________________________ >> > coreboot mailing list -- coreboot(a)coreboot.org >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >------------------------------ > >Message: 2 >Date: Wed, 2 Oct 2024 14:27:00 +0000 >From: Angel Pons <th3fanbus(a)gmail.com> >Subject: [coreboot] Re: Recent disciplinary action taken >To: David Hendricks <dhendrix(a)coreboot.org> >Cc: coreboot(a)coreboot.org >Message-ID: > <CABqd-o1X8o+V9WGvQ34SajWRkwS1ONQpRNhxkB06rA29v8rwVA(a)mail.gmail.com> >Content-Type: multipart/alternative; > boundary="0000000000001580ce06237f3ca0" > >Hello list, > >On Wed, Oct 2, 2024 at 7:40 AM David Hendricks via coreboot < >coreboot(a)coreboot.org> wrote: > >> Dear coreboot community members, >> >> Recently there was some unpleasant activity on Gerrit which violated our >> community’s guidelines regarding respectful conduct. In this case the >> coreboot leadership team determined that the behavior in question fit a >> long pattern about which the individual had been previously warned. As a >> result we have decided to remove Nico from our community for a period of 1 >> year. We hope this will be a sufficient cooling off period and that we will >> not need to take more drastic steps in the future. >> >David, I see you are one of the three members of the leadership team [1]. >Could you please provide the following, privately if necessary? > > - the minutes for the meeting in which the decision was made (which might >contain references to the documents below; if the meeting minutes are not >available, I would like to know why) > - links to the aforementioned "unpleasant activity on Gerrit" > - the guidelines from [2] or [3] (I could not find a document called >"community guidelines") that were violated > >Not knowing what happened nor why makes me afraid to contribute, lest the >same fate befall me as well. Especially considering that Nico has been a >role model for me as I was learning the ropes of firmware development, so >most of the things about coreboot as well as authoring and reviewing >changes I have learned from him. > >> As we've said in the past, we trust that developers in our community are >> acting in good faith and can generally resolve issues on their own. In >> cases where two sides cannot reach an agreement, for example in a code >> review, we expect all engagement to be respectful and to help drive toward >> a solution. For technical matters this often means starting a mailing list >> discussion, bringing an issue up during the coreboot leadership meeting, >> starting a task force to tackle a large problem, or other means of >> gathering input and collaborating. >> >> Personal matters should be brought to the leadership team directly. We'll >> listen to any complaints or frustrations, but cannot tolerate personal >> attacks made on Gerrit, the mailing list, or other forums. It is always >> required that we treat others in a professional manner and communicate with >> respect, regardless of how strongly we may feel about a particular issue. >> >A tiny remark about professional manner: when interacting with others I >know, I like sprinkling a bit of humour in my messages, but without being >disrespectful towards anyone (no dark humour and no making fun of others) >or compromising my knowledge/abilities (do not overdo it and consider that >not everyone might get it). I believe this does not make me unprofessional, >but I am happy to listen in case anyone disagrees. > >Other than that, I agree with the above, but I also believe it is important >to be aware that misunderstandings can and will happen, especially >considering that people from all over the world can contribute, each with >their own culture and tradition. Not everyone is a native English speaker >(even if it does not seem like it, I am not). Not everyone is capable of >noticing when a discussion is getting too heated/tense, let alone do >something to end it before it is too late (I am trying to get better at >this). Not everyone communicates the same way, e.g. autistic people tend to >communicate in direct and literal ways that can be misinterpreted by >non-autistic people [4] (I am autistic, I have had this happen before), >whereas other autistic people have no issues with this communication style. > >I believe that the information in [4] (especially the list of 12 rules) is >valuable and I would appreciate having them integrated into our own >guidelines, although I agree they should be guidelines rather than >strictly-enforced rules: misunderstandings are *still* inevitable and will >happen. In case of a misunderstanding, I think the most sensible way to >proceed is for someone (preferably one of the participants) to notice that >"something feels wrong" and remain calm, disengaging from the discussion if >needed (e.g. wait before replying to an email or review comment). If >possible, try to bring it up without pointing fingers, e.g. "I feel this >discussion is heating up: is there anything I can do to help, or am I >reading into things?" or (quoting a response) "This sounded quite rude to >me, was it intentional?". This requires being able to recognise that >tension is building up and restraining one's impulses; I understand this is >not trivial to accomplish, especially if one is susceptible to getting >angry (e.g. me). > >> If anybody feels that a discussion has become too heated, or that somebody >> is not being treated respectfully, or are simply unsure of how to proceed >> in a difficult situation, please reach out to the coreboot leadership and >> we will chart a path forward together. >> _______________________________________________ >> coreboot mailing list -- coreboot(a)coreboot.org >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > >Best regards, >Angel > >[1]: https://www.coreboot.org/leadership.html >[2]: https://doc.coreboot.org/community/code_of_conduct.html >[3]: https://doc.coreboot.org/contributing/gerrit_guidelines.html >[4]: >https://warwick.ac.uk/services/socialinclusion/projects/letstalkaboutdisabi… >

1 0

2024-10-02 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 03 Oct '24

03 Oct '24

# 2024-10-02 - coreboot Leadership Meeting ## Attendees Felix Held, Alicja Michalska, David Hendricks, Matt DeVillier, Maximilian Brune, Werner Zeh, Mina Asante, Martin Roth, Jonathon Murphy, Felix Singer, Julius Werner, Karthik Ramasubramanian, Jeremy Compostella. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out invitations for this meeting. * Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico:(https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? * David: Were we supposed to set up a meeting to discuss ideas? * Intel was pushing slimboot - BSD licensed. * Do we know how much slimboot is used? * Werner: 2 years ago it was being used because of the license reason. More than 90% of contributions were made by intel employees. The main intel contributor has left the project. It doesn’t look like there’s a community there at all. No guarantee that the project will persist if intel decides to drop it. Based on the BSD license there’s not much of a chance that a healthy community will evolve. With intel’s current financial issues, it’s even less likely. * Max: I’m not hearing anything about slimboot anymore. * Martin: Inertia * Martin: UEFI is more expected, has larger IBVs. * The silicon vendors push the IBVs - AMI, Insyde, Phoenix. * ODMs just go with their relationships with the IBVs. * Developing on your own is hard * Complexity/inflexibility of FSP. It's hard to justify coreboot + FSP when FSP requires its own set of custom patches and hacks to change its default behavior. * Alicja: I believe we need something that can configure the platform options at runtime (writing to CMOS/SMMSTORE) instead of setting options at build time, many people using Chromebooks with Matt's builds complain about "lack of features". * Can anyone look further into this? ### [Werner] Present the workflow for Feature Request and Implementation which is an outcome of one of the OSFF’s workstreams. * There are tasks around streamlining feature implementation requests to make it more plannable for business use cases. Werner took it as an AI. Website: (https://opensourcefirmware.foundation/workstreams/feature-request-flow/) Specification: (https://drive.google.com/file/d/1su3s93xNgqy9AixDfHEWGrB_1nxYbQoz/view) * This process has been reviewed by a number of coreboot and OSFF community members from a number of companies. * This would not be required to add a feature, but is intended simply to help the project and feature implementers work through the process. * The point of this is to provide a timeline and a better guarantee that the feature would be accepted by the community. * Felixh: Who is doing the work to implement the feature? * This is not restricted by the process. Most of the time it would be the requester. * Felixh: The “guarantee” of acceptance is very concerning. I’m worried that companies will demand that their patches get rubber stamped. * That’s absolutely not guaranteed by this process. The idea is that a specification would be agreed upon, to facilitate the merging of features. The time to reject a feature is early in this * Max: Who decides when to transition between phases? * Werner: It differs between phases. One way is when the community and requester are in sync. In the implementation phase if the feature complies with the design document (this is decided by the implementation team). There are also suggested timelines. * Max: There are a number of feature patches where the idea is good, but the implementation doesn’t fit coreboot well. How do we avoid merging poor patches? * Werner: That’s why the community needs to be involved in the implementation phase. Full features shouldn’t just be dropped into the tree. * David: Agreed, even if an implementation isn’t perfect, it may be better to get it in then fix it rather than just letting it bitrot. * FelixH: If things are being done behind closed doors, this process may not work. * Martin: Behind closed doors should be a big exception. Let’s see how this goes. * Werner: I can look at creating a feature design template from the OSFF. We can also have a dashboard of features that are ongoing and what phase they’re in. There are a lot of things to improve in the ecosystem. * Martin: How to give feedback: * Werner: Send an email or review on the google [doc](https://docs.google.com/document/d/1zZvnoJwAKX7bm80UxPwnHMfelvoqoYbxR1…. Feedback is welcome. ### [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach. * 2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. * Jon: We’re going to try to make the bugs public and update gerrit. Can we add a rule to link to the bug? * Martin will work with the other admins to make this work. * CrosBug? * BUG=b:? * CB-Bug - For coreboot bugs? * Werner: Please respond to the poll about how to respond to coverity issues. * (https://rallly.co/invite/1c8J3azXAcje) ### David: We had to take an action with a community member’s behavior. Details are on the mailing list. David will respond to various questions on the mailing list. * If anyone is feeling anxiety about dealing with other people in the community, *please* reach out. You can email anyone on the leadership team or the arbitration team. These issues will be kept confidential. (https://coreboot.org/leadership.html) ### Granite rapids patches are out! Great job getting these out before the chip is out. * FelixH: These are great and very appreciated. It’s obvious that a lot of work went into trying to improve things. # Next Leadership Meeting * October 16, 2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 30 Sep '24

30 Sep '24

Dear community, Please be reminded that our coreboot leadership meeting is scheduled for Wednesday, October 2, 2024.[1] Kindly review the current agenda and share your thoughts or suggest additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda Items ### [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? ### [Werner] Present the workflow for Feature Request and Implementation which is an outcome of one of the OSFF’s workstreams. ### [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach. * 2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 27 Sep '24

27 Sep '24

Dear community, Our upcoming coreboot leadership meeting is scheduled for Wednesday, October 02, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

2024_09_25 coreboot Group Review Session
by mina＠coreboot.org 27 Sep '24

27 Sep '24

Hello coreboot! Our next group review session is on Wednesday, September 25, 2024: https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here’s the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Kindly add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our review session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

2 1

links for "board-status" not found
by lödur 23 Sep '24

23 Sep '24

Hello, on page: https://coreboot.org/status/board-status.html the both links for "a tool in the coreboot repository" https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/util/board_stat… "board status repository" https://review.coreboot.org/plugins/gitiles/board-status/ point to "Not Found" Could you repair these links, please. Thanks, loedur

2 1

Re: Could not find a bounce buffer... Payload not loaded. Intel 440BX/LX Board
by Branden Waldner 22 Sep '24

22 Sep '24

Hi Christian, Both Keith Hei and I [Branden] have 440BX boards that still run up-to-date/recent coreboot (though they do need a bit of work). I also have an Intel 440LX board [Trigem Florida-TG (COGNAC)] that I was intending on trying to get coreboot to run on yet, but I wanted to get it reworked at the local maker/hackerspace to socket the flash chip which I haven't been able to get done. From old messages on the mailing list, it looked like the 440BX code did run on the 440LX and I have had it run at 66MHz fsb speed on the 440BX. Though maybe the memory settings could be an issue if the ram is rated for faster than the [older] chipset can handle (I'm not sure about the details of it)? I probably can't help much though and Keith has been working on a Haswell board recently, so I'm not sure how much time he has had to work on the older boards. I just figured I make sure to mention it at least. Branden PS Necroware on Youtube / scorp on Vogons forum has the same board as you [in the video: Too nice to be true? Intel i440LX was upset about my plans] and has expressed interest in open source works, so maybe he might be interested as well? I haven't tried messaging him about it.

2 1

Gerrit Gitiles is back - for now
by Felix Singer 20 Sep '24

20 Sep '24

I've just enabled Gitiles again. We will observe which effect this has on Gerrit now. Fingers crossing that it won't cause a high load anymore :) Felix

3 4

2024-09-18 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 19 Sep '24

19 Sep '24

# 2024-09-18 - coreboot Leadership Meeting ## Attendees Ron Minnich, Felix Singer, Julius Werner, Felix Held, Matt DeVillier, Nico Huber,Jon Murphy, Werner Zeh, David Hendricks, Mina Asante. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out invitations for this meeting. * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico:(https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Martin] How do we want to handle code written with copilot or other AI tools. * We don’t currently have a policy, and it seems like we should. * [Matt] Code generated by AI is not copyrightable. Submitters should stay responsible for their code, regardless how it was created. * [David] Would be polite if the author mentions in the commit message that AI was used to create (parts) of the code. Still DCO should cover the legal parts of this discussion. Therefore, we do not need a dedicated policy for that. * [David] We should try to leverage AI possibilities in our project. As Bryan @ Oxide observed, open source code are by nature documented better than proprietary firmware (as far as LLM training goes) and this can be an advantage of coreboot. * [Nico] Can this make it easier to violate the DCO using AI? Should we try to improve the awareness in the community? * [Matt] The AI can spit out license-incompatible code and this way could make it into coreboot’s code base. * [Matt] Update the DCO to include that the comitter has to ensure that the added code from AI is compliant to our license. * [David] Are there filters available at the AI side to ensure output is license compatible? * [Julius] We could ask the SFC for help from the legal standpoint →[David](mailto:david.hendricks@gmail.com) will ask ### [jpmurphy] What are the coreboot projects goals? * Individuals and companies have their own goals. Do we have wider goals from the project’s point of view? * [David] This is a huge topic. Should we start a doc and just collect things there? * [Ron] Initial goals of linuxbios were: maintainability, security reliability * Goal was to have computers shipped with coreboot, not to retrofit machines like buying a Wintel PC and installing Linux on it. * [Werner] Get adoption by big vendors earlier, the rest will fall into it. * [Nico] For an early vendor adoption, we need to be able to boot into Windows as a first class citizen * [FelixH] UEFI way of booting an OS is de facto standard in the client space. We could counter this with EDK 2 but somebody should take the time to work on this. * [David] There are a number of different solutions to boot Windows (Universal Payload, EDK 2, Yabits and Rust Hypervisor (Akira's projects)), has somebody had a closer look? If the goal is to boot into EDK2, why bother with coreboot at all? * [David] Multiple architectures and boards in a single codebase - LinuxBIOS started with PPC, Alpha, and x86. Support for ARM helped get Intel to support coreboot. EDK2 is a fork-per-product sort of deal. * [Werner] We should continue the task of re-building coreboot’s webpage. Gather all the requirements and reach out to some company that can do the work based on our requirements. Preserve a section in this webpage where real uses-cases can be added to to make coreboot’s use cases popular. * [FelixH] Simplified architecture, not bloated like EDK2 with its dispatcher, dynamic module loading, etc. ### [jpmurphy] How do we want to manage a roadmap? * Can we start a draft of a roadmap to at least start gathering a list of features/tech debt and their priorities? * [FelixH] Writing up a roadmap does not mean the features will be implemented. Who will make sure that we stick to the planned roadmap? * [Jon] We should have at least a list gathered so that we can plan * [FelixS] We have too many communication channels, keeping track can be quite challenging. * [Werner] Use a kanban board to publish and track progress of features? * Better look/feel than tickets. * [Werner] The coreboot project has a few different communication channels around (mailing list, Slack, Matrix, IRC, Google docs, Discord) All our discussions happen spreaded among those and there is no central place (accepted by all community members) where decisions are written down. * Mailing list seems suitable as it has an archive but some people opted out due to heated discussions and other issue we had in the past. * Google docs could be one place but unfortunately not every community member likes them. In addition, despite the meeting minutes, there is no “official” document where centric decisions are written down, one has to search in the archive to find things. * Slack/Matrix are not used by everyone. * IRC is not suitable for such things as well. * Would a kanban-style board be something we like to have a look into for such things? I know, ranting about too many communication channels and then adding another one isn’t the best move. But still, let us at least discuss. * Possible open source boards we can have a look at: (https://kanboard.org/) and (https://wekan.github.io/). It might be easier to maintain a feature roadmap this way, IMHO. And we can host it on coreboot.org to have full control over it. * [FelixS] I suggest using [forgejo for kanban boards](https://forgejo.org/docs/latest/user/project/) instead, since I’ve suggested it as an issue tracker before and it got positive feedback. Both, issues and kanban, are very well integrated. So we reduce the number of services. ### [jpmurphy] We get coverity results for free from synopsis. At the time of writing, there are 705 outstanding defects. Do we have a plan for burning these down? * (https://scan.coverity.com/projects/coreboot)? * Can we set a bar to burn these down by a certain date, and then moving forward we require that the defect count is 0 prior to releases? * [FelixH] Can we export the coverity results and show them in a coreboot-driven dashboard so that everybody can have access? * [Jon] Set up a dedicated meeting to discuss this? * [Werner] I can send out an invite to discuss this. ### [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach. * 2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. # Next Leadership Meeting * October 2,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

Announcement: Introducing UEFI Capsule Update Integration for coreboot with EDK II
by Beata Skierka 18 Sep '24

18 Sep '24

Hello, We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage. One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II). For a detailed project outline, please visit our Dasharo documentation [1]. We are looking for feedback through comments on this thread or via the built-in discussion module on the website. Although the project plan has been already accepted by the NLnet Foundation, there may be still some room for justified changes. You can track project's progress via the GitHub Project [2]. Your feedback and participation would be much appreciated. We welcome your involvement in discussions, reviewing, and testing. You might already have seen some first patches as a results of this project getting started, such us: - https://review.coreboot.org/c/coreboot/+/82247 - https://review.coreboot.org/c/coreboot/+/82248 - https://review.coreboot.org/c/coreboot/+/82249 - https://review.coreboot.org/c/coreboot/+/82610 We acknowledge and appreciate the funding support from the NLnet Foundation. [1] https://docs.dasharo.com/projects/capsule-updates/ [2] https://github.com/orgs/Dasharo/projects/7/views/1 Best regards, Beata Skierka Project Manager https://3mdeb.com | @3mdeb_com

8 18

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 16 Sep '24

16 Sep '24

Dear coreboot community, Please be reminded that our leadership meeting is scheduled for Wednesday, September 18, 2024.[1] Kindly review the current agenda and share your thoughts or suggest additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda ### [Martin] How do we want to handle code written with copilot or other AI tools. * We don’t currently have a policy, and it seems like we should. * [jpmurphy] What are the coreboot projects goals? * [jpmurphy] How do we want to manage a roadmap? * Can we start a draft of a roadmap to at least start gathering a list of features/tech debt and their priorities? * [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? * [jpmurphy] How do we utilize the OSFF to obtain NDA’s with SoC vendors and provide early silicon support? * [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * <code>Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach.</code> * <code>2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it's a Google bug. Felix S had suggested ChromeOS-Bug-Id</code> * <code>[jpmurphy] We get coverity results for free from synopsis. At the time of writing, there are 705 outstanding defects. Do we have a plan for burning these down?</code> * <code>(https://scan.coverity.com/projects/coreboot)?</code> * <code>Can we set a bar to burn these down by a certain date, and then moving forward we require that the defect count is 0 prior to releases?</code> ### [Werner] The coreboot project has a few different communication channels around (mailing list, Slack, Matrix, IRC, Google docs) All our discussions happen spreaded among those and there is no central place (accepted by all community members) where decisions are written down. * Mailing list seems suitable as it has an archive but some people opted out due to heated discussions and other issue we had in the past * Google docs could be one place but unfortunately not every community member likes them. In addition, despite the meeting minutes, there is no “official” document where centric decisions are written down, one has to search in the archive to find things * Slack/Matrix are not used by everyone * IRC is not suitable for such things as well In addition, I agree with jmurphy’s points above, we do not have a plan for a roadmap. Would a kanban-style board be something we like to have a look into for such things? I know, ranting about too many communication channels and then adding another one isn’t the best move. But still, let us at least discuss. Possible open source boards we can have a look at:(https://kanboard.org/) and (https://wekan.github.io/) It might be easier to maintain a feature roadmap this way, IMHO. And we can host it on coreboot.org to have full control over it. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit

1 0

[coreboot - Bug #563] (New) tty doesn't show on external display using edk2 on W530
by Simon Dominic 16 Sep '24

16 Sep '24

Issue #563 has been reported by Simon Dominic. ---------------------------------------- Bug #563: tty doesn't show on external display using edk2 on W530 https://ticket.coreboot.org/issues/563 * Author: Simon Dominic * Status: New * Priority: Normal * Target version: none * Start date: 2024-09-16 * Affected hardware: Lenovo ThinkPad W530 * Affected OS: Debian 12 ---------------------------------------- I use the w530 (with Debian 12 + edk2), but this may also be happening with other thinkpads. When I connect to external displays and turn on, while the graphical environment shows as normal, the tty or anything not graphical doesn't show. This includes anything prior to the graphical display manager (such as lightdm). For example, when LUKS asks for the password for my encrypted drive. (The GRUB screen also doesn't show, but I can't recall if this was already the case with the stock bios. It also never showed with SeaBIOS, so maybe so). With SeaBIOS, the tty etc. *does* show, but only with nouveau open-source graphics drivers. The nouveau driver suffers from screen tearing on this system, so I switched to proprietary nvidia drivers (Tesla 470 for w530) to resolve this. While it did cure screen tearing, I got the same problem as with edk2. -- 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 #562] (New) Issues regarding HP Elitebook 8470p
by Kristof Horvath 14 Sep '24

14 Sep '24

Issue #562 has been reported by Kristof Horvath. ---------------------------------------- Bug #562: Issues regarding HP Elitebook 8470p https://ticket.coreboot.org/issues/562 * Author: Kristof Horvath * Status: New * Priority: Normal * Target version: none * Start date: 2024-09-14 * Affected versions: 4.21 ---------------------------------------- Hi all! I have a HP Elitebook 8470p with Libreboot 20240612 installed, but I've also tried compiling from scratch using the git head of coreboot. I have been using it with Ubuntu 24.04, but there are some issues: 1.) Screen brightness can not be changed. 2.) After returning from sleep, the WWAN module (MC7710) is not accessible. 3.) Bluetooth is not recognized, as if the BT module was absent. It may not be related, but Windows 10 fails to boot with "ACPI BIOS error" BSOD message. I have actually found out the third problem: the device tree override (/src/mainboard/hp/snb_ivb_laptops/variants/8470p/overridetree.cb) contains incorrect values for usb_port_config. Enabling all USB ports fixes that issue, but I'm not sure if this is the correct fix. -- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 13 Sep '24

13 Sep '24

Dear coreboot community, Please note that our upcoming leadership meeting is scheduled for Wednesday,September 18, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

DUG #7 & vPub 0xC - an open-source online party! September 12th at 4 PM UTC
by Mike Banon 11 Sep '24

11 Sep '24

Dear friends, I invite you to a joint DUG #7 + vPub 0xC event that starts Tomorrow at 4 PM UTC ! ;-) Would you like to: * see an exciting demo of a new Dasharo firmware for ODROID H4+ single board computer? (could be installed in a mini-ITX case thanks to a kit) * get updates about the NovaCustom privacy-focused laptops (coreboot-supported & QubesOS-certified) ? * learn some cool tricks on how to successfully hunt for firmware vulnerabilities? and also * find out about new open hardware / opensource firmware-supporting devices that you haven't heard about before? Then this upcoming event - is an excellent opportunity for you to have a great time in the company of fellow firmware enthusiasts. The 1st part of our event - DUG #7 - is dedicated to Dasharo distribution of coreboot opensource firmware with advanced features like GUI & FLASHBIOS and the ecosystem around it. DUG will take place between 4-6 PM UTC - and then around 6 PM UTC will switch to vPub. The past events have been highly successful, and I'm sure you will find this time interesting as well ;-) Both sound/video and text chats will be available for your convenience More details and Join links are available here - https://vpub.dasharo.com/e/14/dasharo-user-group-7 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Could not find a bounce buffer... Payload not loaded. Intel 440BX/LX Board
by Christian Sühs 10 Sep '24

10 Sep '24

2 2

2024-09-11 coreboot Group Review Session
by mina＠coreboot.org 09 Sep '24

09 Sep '24

Hello coreboot! We have an upcoming group review session on Wednesday: https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we’ll begin by reviewing a few RFC patches together, then switch to review patches individually for a bit, but everyone will be available if you have questions about the patch you’re reviewing. Here’s the link to the list of patches to be reviewed: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Kindly add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our review session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

1 0

MrChromebox-2408 release is out
by Matt DeVillier 09 Sep '24

09 Sep '24

(2024.09.08) Now supporting nearly 300 x86_64 ChromeOS devices, this new release is based on the coreboot 24.08 tag (August 2024) and includes the following changes: * Rebased on coreboot tag 24.08 * New edk2 branch (uefipayload_2408), rebased on upstream edk2-stable202408 tag * Adjusted touchscreen init timing params for JINLON * Minor improvements to EC software sync code * Added automatic fan control for 7th/8th-gen Chromeboxes (FIZZ board) * Fixed fan control on 10th-gen Chromeboxes * Added ACPI driver attachment for SPI CR50 TPMs to use coolstar's Windows drivers * Added ability to configure (when compiling) UMA allocation for Intel Sandy/Ivybridge and AMD Stoneyridge and Picasso devices * Fixed display init on some boards (LASER14, MARASOV, OMNIGUL, KINOX) * AMD Picasso devices no longer use vboot https://mrchromebox.tech cheers, Matt

2 1

[coreboot - Bug #527] Can't compile coreboot on Arch Linux
by Peter Daru 07 Sep '24

07 Sep '24

Issue #527 has been updated by Peter Daru. Sorry if this doesn't fit here. I thought this is similar if not same issue as op's one. I was following [doc tutorial](https://doc.coreboot.org/tutorial/part1.html) for qemu x64 and also couldn't compile. I run fully up to date installation (apart from kernel itself). Turns out doing `$ make clang CPUS=$(nproc)` and then `$ make` I was able to compile. This is what I got following tutor: ``` # # No change to /home/daru/Git/coreboot/payloads/coreinfo/.config # Makefile:358: warning: overriding recipe for target '/home/daru/Git/coreboot/payloads/coreinfo/libpayload/arch/x86/exec.libc.o' Makefile:358: warning: ignoring old recipe for target '/home/daru/Git/coreboot/payloads/coreinfo/libpayload/arch/x86/exec.libc.o' LPGCC coreinfo.bin /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: warning: exception_asm.libc.o: missing .note.GNU-stack section implies executable stack /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: warning: build/coreinfo.bin has a LOAD segment with RWX permissions /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: build/cpuinfo_module.o: in function `cpuinfo_module_init': cpuinfo_module.c:(.text+0x474): undefined reference to `__udivdi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: build/timestamps_module.o: in function `timestamp_print_entry.constprop.0': timestamps_module.c:(.text+0x157): undefined reference to `__udivdi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: timestamps_module.c:(.text+0x194): undefined reference to `__udivdi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/coreinfo/libpayload/libpayload.a(time.libc.o): in function `update_clock': /home/daru/Git/coreboot/payloads/libpayload/libc/time.c:60:(.text.time+0xe8): undefined reference to `__udivdi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/libpayload/libc/time.c:65:(.text.time+0x11d): undefined reference to `__udivdi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/coreinfo/libpayload/libpayload.a(time.libc.o):/home/daru/Git/coreboot/payloads/libpayload/libc/time.c:68: more undefined references to `__udivdi3' follow /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/coreinfo/libpayload/libpayload.a(printf.libc.o): in function `print_number': /home/daru/Git/coreboot/payloads/libpayload/libc/printf.c:261:(.text.printf_core+0x5c0): undefined reference to `__udivmoddi4' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/coreinfo/libpayload/libpayload.a(gcd.libc.o): in function `gcd': /home/daru/Git/coreboot/src/commonlib/bsd/gcd.c:14:(.text.gcd+0x58): undefined reference to `__umoddi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/src/commonlib/bsd/gcd.c:19:(.text.gcd+0x76): undefined reference to `__umoddi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/coreinfo/libpayload/libpayload.a(timer.libc.o): in function `get_cpu_khz_xtal': /home/daru/Git/coreboot/payloads/libpayload/arch/x86/timer.c:121:(.text.get_cpu_speed+0x9f): undefined reference to `__udivdi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/libpayload/arch/x86/timer.c:121:(.text.get_cpu_speed+0xb0): undefined reference to `__udivdi3' /home/daru/Git/coreboot/util/crossgcc/xgcc/lib/gcc/x86_64-elf/14.2.0/../../../../x86_64-elf/bin/ld.bfd: /home/daru/Git/coreboot/payloads/coreinfo/libpayload/libpayload.a(timer.libc.o): in function `calibrate_pit': /home/daru/Git/coreboot/payloads/libpayload/arch/x86/timer.c:78:(.text.get_cpu_speed+0x17c): undefined reference to `__udivdi3' collect2: error: ld returned 1 exit status make[2]: *** [../libpayload/Makefile.payload:104: build/coreinfo.bin] Error 1 make[1]: *** [Makefile:64: defaultbuild] Error 2 make: *** [payloads/Makefile.mk:38: payloads/coreinfo/build/coreinfo.elf] Error 2 ``` ---------------------------------------- Bug #527: Can't compile coreboot on Arch Linux https://ticket.coreboot.org/issues/527#change-1918 * Author: naixin Lv * Status: New * Priority: Normal * Category: build system * Target version: master * Start date: 2024-02-23 * Affected versions: master * Needs backport to: none * Affected hardware: GIGABYTE GA-H61M-DS2 * Affected OS: none ---------------------------------------- I want to compile coreboot for my Gigabyte GA-H61M-DS2 mainboard, but I only found a short guide for this board at this site: https://www.iot-tech.dev/full.php?ar=166 After downloaded the coreboot git repository, It gave me this error: ``` shell /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/console/vtxprintf.o: in function `number': /home/zhongli/coreboot/src/console/vtxprintf.c:63:(.text.number+0x12b): undefined reference to `__udivmoddi4' /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___divdi3': /home/zhongli/coreboot/src/lib/gcc.c:19:(.text.__wrap___divdi3+0x1): undefined reference to `__divdi3' /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___udivdi3': /home/zhongli/coreboot/src/lib/gcc.c:20:(.text.__wrap___udivdi3+0x1): undefined reference to `__udivdi3' make: *** [src/arch/x86/Makefile.mk:191: build/cbfs/fallback/romstage.debug] Error 1 ``` And I'll put my config file on here. Any help ? ---Files-------------------------------- defconfig (726 Bytes) ifd_shrinked.bin (4 KB) me_shrinked.bin (96 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

1 0

2024-09-04 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 02 Sep '24

02 Sep '24

Hello coreboot, Kindly be informed that the leadership meeting scheduled for Wednesday, September 4, has been canceled due to a time conflict with OSFC. [1] Thank you. [1](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[coreboot - Bug #552] (New) X201 not booting with edk2 payload
by Maya Matuszczyk 01 Sep '24

01 Sep '24

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

1 1

[coreboot - Bug #121] T520: Hangs in OS
by Ján Mlynek 01 Sep '24

01 Sep '24

Issue #121 has been updated by Ján Mlynek. I updated to main a week ago and after more than 100 hours of uptime, I didn't experience any hangs so far. This amount of time wasn't possible to achieve before. I will report again in a few weeks if no hangs occur but it looks promising. T420, i7-3632QM ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1907 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 30 Aug '24

30 Aug '24

Dear community, Please note that we have an upcoming coreboot leadership meeting scheduled for Wednesday, September 4, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #553] (New) M95M02 write failure
by Miklos Marton 30 Aug '24

30 Aug '24

Issue #553 has been reported by Miklos Marton. ---------------------------------------- Bug #553: M95M02 write failure https://ticket.coreboot.org/issues/553 * Author: Miklos Marton * Status: New * Priority: Normal * Target version: none * Start date: 2024-08-21 * Affected hardware: STLinkV3 * Affected OS: Linux ---------------------------------------- While trying to add support for EEPROM devices (which lacks the erase capability) I came across some issues with implementing it. The only device so far which lacks erase capability is the M95M02. When trying to write it via force I receieve a SIGSEV and the following output: ``` shell 08:17:18: Debugging /home/mm/Projektek/flashrom/flashrom -p stlinkv3_spi -c M95M02 -f -w /tmp/myfile ... could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcap.so.2 flashrom 1.4.0-rc2 (git:v1.4.0-rc2-1-gbd3c5f31) on Linux 6.8.0-40-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Connected to STLink V3 with bridge FW version: 5 SCK frequency set to 750 kHz Assuming ST flash chip "M95M02" (256 kB, SPI) on stlinkv3_spi. === This flash part has status UNTESTED for operations: WP The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. You can also try to follow the instructions here: https://www.flashrom.org/contrib_howtos/how_to_mark_chip_tested.html Thanks for your help! spi_get_opcode_from_erasefn: unknown erase function (0x1). Please report this at flashrom(a)flashrom.org ``` Backtrace: ``` >~"#0 0x000055555558f047 in check_block_eraser (flash=flash@entry=0x7fffffffd9d0, k=k@entry=0, log=log@entry=0) at flashrom.c:489\n" >~"#1 0x000055555558f0c7 in count_usable_erasers (flash=flash@entry=0x7fffffffd9d0) at flashrom.c:508\n" >~"#2 0x000055555558f15f in chip_safety_check (flash=flash@entry=0x7fffffffd9d0, force=1, read_it=read_it@entry=0, write_it=write_it@entry=1, erase_it=erase_it@entry=0, verify_it=verify_it@entry=1) at flashrom.c:2019\n" >~"#3 0x0000555555591426 in prepare_flash_access (flash=flash@entry=0x7fffffffd9d0, read_it=read_it@entry=false, write_it=write_it@entry=true, erase_it=erase_it@entry=false, verify_it=verify_it@entry=true) at flashrom.c:2121\n" >~"#4 0x0000555555591821 in flashrom_image_write (flashrom_flashctx=flashrom_flashctx@entry=0x7fffffffd9d0, buffer=buffer@entry=0x7ffff7ea5010, buffer_len=buffer_len@entry=262144, refbuffer=refbuffer@entry=0x0) at flashrom.c:2287\n" >~"#5 0x00005555555795d6 in do_write (flash=flash@entry=0x7fffffffd9d0, filename=0x55555565c2c0 \"/tmp/myfile\", referencefile=0x0) at cli_classic.c:535\n" >~"#6 0x000055555557a455 in main (argc=<optimized out>, argv=<optimized out>) at cli_classic.c:1255\n" ``` -- 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

2024-08-28 coreboot Group Review Session
by mina＠coreboot.org 26 Aug '24

26 Aug '24

Hello coreboot! We have an upcoming group review session on Wednesday: https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we’ll begin by reviewing a few RFC patches together, then switch to review patches individually for a bit, but everyone will be available if you have questions about the patch you’re reviewing. Here’s the link to the list of patches to be reviewed: https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… 61#gid=1189723661 Please add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our review session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

1 0

[coreboot - Other #554] (New) Do not follow ch1p's guide on flashing Thinkpad W530 with only 8MB chip!!
by Simon Dominic 23 Aug '24

23 Aug '24

Issue #554 has been reported by Simon Dominic. ---------------------------------------- Other #554: Do not follow ch1p's guide on flashing Thinkpad W530 with only 8MB chip!! https://ticket.coreboot.org/issues/554 * Author: Simon Dominic * Status: New * Priority: Normal * Target version: none * Start date: 2024-08-23 ---------------------------------------- I had to learn this the hard way and (literally) pay the price (for it to be repaired) for following this guide (both on their own [website](https://ch1p.io/coreboot-t530-one-chip/) and a [reddit post](https://www.reddit.com/r/coreboot/comments/956ymu/howto_flash_coreboo…). I often make tweaks to my coreboot config which often breaks my system by not being able to boot, and thus requires a fully disassembly to access the 4MB chip to externally flash. As you can imagine, doing this every time I mess up is annoying, and so the idea that I could do it with just the 8MB chip, which is easily accessible, was very attractive. Right off the bat, I'll say this this method causes so many problems and going through the pain and frustration is not worth the convenience of not doing full disassembly. I was in contact with ch1p who was very helpful in trying to help me out. However, it must be said that this guide should **NOT** be followed! This completely messes up the bios chips' firmware tabling, making it impossible to internally or externally flash (while the chips were still on the motherboard). You cannot read or write from either of the chips, and the 8MB chip thinks it 4MB. I would get errors like this: ``` Reading old flash chip contents... done. Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x16, failed byte count from 0x00000000-0x00000fff: 0x1000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x16, failed byte count from 0x00000000-0x0000ffff: 0x10000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x16, failed byte count from 0x00000000-0x0000ffff: 0x10000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x16, failed byte count from 0x00000000-0x003fffff: 0x400000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x16, failed byte count from 0x00000000-0x003fffff: 0x400000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Looking for another erase function. Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Apparently at least some data has changed. Your flash chip is in an unknown state. Please report this to the mailing list at flashrom(a)flashrom.org or on IRC (see https://www.flashrom.org/Contact for details), thanks! ``` Thanks to [this](https://github.com/flashrom/flashrom/issues/190) github issue, I figured the only way to fix this was to have the chips physically removed and then flash them. Since I can't solder, I paid someone to do it (they charge for disassembly, so saved by dissembling myself and giving them just the motherboard). The bad news is the 8MB always thinks it's 4MB, so impossible to externally flash that chip. The good news is the 4MB chip is perfectly fine, which is great because that's the chip for the actually bios. From there, you can internally flash (both chips), so that problem sorts itself out. I had to pay someone to fix the mess that the guide caused. If someone with a Thinkpad W530 happens to stumble upon this post, you will save yourself time, pain and money by ignoring the guide and just dealing with full disassembly. It's not worth it. -- 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

4 5

[coreboot - Bug #549] (New) coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" (Thinkpad W530)
by Simon Dominic 23 Aug '24

23 Aug '24

Issue #549 has been reported by Simon Dominic. ---------------------------------------- Bug #549: coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" (Thinkpad W530) https://ticket.coreboot.org/issues/549 * Author: Simon Dominic * Status: New * Priority: Normal * Category: board support * Target version: master * Start date: 2024-07-31 * Affected versions: master * Affected hardware: Lenovo ThinkPad W530 * Affected OS: Windows 10/11 ---------------------------------------- When using the latest coreboot (i.e. using command `git clone https://review.coreboot.org/coreboot`), which is currently 24.05, to build a rom for Thinkpad W530, I get BSOD with "ACPI BIOS ERROR" when trying to boot into Windows 10 or 11 from SeaBIOS. Even just booting from a Windows install usb will show this error. This is even with incorporating the vga bios files (so i can external displays to work) - see my defconfig. Did consider using EDK2 apparently Windows support is pretty solid, but could never make a successful build - not that `make` command had errors, but once flashing, would just having white underscore and have to recover with external flashing. A separate issue to write about in and of itself, but I prefer SeaBIOS so I'll be sticking with that. I am quite new to coreboot - using for only about 2-3 months now. Let me know if there is further information I should provide. ---Files-------------------------------- defconfig (590 Bytes) w530_bsod.jpg (1.98 MB) -- 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 17

[coreboot - Bug #536] (New) Cannot build coreboot-sdk
by Michał Żygowski 23 Aug '24

23 Aug '24

Issue #536 has been reported by Michał Żygowski. ---------------------------------------- Bug #536: Cannot build coreboot-sdk https://ticket.coreboot.org/issues/536 * Author: Michał Żygowski * Status: New * Priority: Normal * Assignee: Martin Roth * Target version: none * Start date: 2024-04-24 ---------------------------------------- I have just tried building coreboot-sdk from scratch and could not get past the step of installing the required packages. Found out that diffutils dependency on libcurl4t64 break libcurl4 (change apt-get to apt to see verbose information message like below): ``` shell > [coreboot-sdk 2/4] RUN useradd -p locked -m coreboot && apt-get -qq update && apt -qqy install --no-install-recommends bash-completion bc bison bsdextrautils bzip2 ca-certificates ccache cmake cscope curl device-tree-compiler dh-autoreconf diffutils exuberant-ctags flex g++ gawk gcc git gnat-13 golang graphicsmagick-imagemagick-compat graphviz lcov less libcapture-tiny-perl libcrypto++-dev libcurl4 libcurl4-openssl-dev libdatetime-perl libelf-dev libfreetype-dev libftdi1-dev libglib2.0-dev libgmp-dev libgpiod-dev libjaylink-dev liblzma-dev libnss3-dev libncurses-dev libpci-dev libreadline-dev libssl-dev libtimedate-perl libusb-1.0-0-dev libxml2-dev libyaml-dev m4 make meson msitools neovim ninja-build openssh-client openssl parted patch pbzip2 pkg-config python3 python-is-python3 qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86 rsync sharutils shellcheck unifont unzip uuid-dev vim-common wget xz-utils zlib1g-dev && apt-get clean: 2.106 2.106 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. 2.106 2.841 diffutils is already the newest version (1:3.10-1). 2.841 diffutils set to manually installed. 2.841 Some packages could not be installed. This may mean that you have 2.841 requested an impossible situation or if you are using the unstable 2.841 distribution that some required packages have not yet been created 2.841 or been moved out of Incoming. 2.841 The following information may help to resolve the situation: 2.841 2.841 Unsatisfied dependencies: 3.001 libcurl4t64 : Breaks: libcurl4 (< 8.7.1-3) 3.004 Error: Unable to correct problems, you have held broken packages. ``` Changing libcurl4 to libcurl4t64 allows the docker to continue the build process of coreboot-sdk. But is this the right thing to do? -- 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

4 8

[coreboot - Bug #522] (Closed) `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function.
by Martin Roth 23 Aug '24

23 Aug '24

Issue #522 has been updated by Martin Roth. Status changed from New to Closed Fixed with https://review.coreboot.org/c/coreboot/+/79905/ ---------------------------------------- Bug #522: `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function. https://ticket.coreboot.org/issues/522#change-1895 * Author: Vadim Zaliva * Status: Closed * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2023-12-27 * Affected versions: master * Related links: https://review.coreboot.org/q/topic:enforce_region_api ---------------------------------------- `region_overlap()` function checks whether or not two memory regions overlap. Memory regions are represented as a region struct that contains the region's offset and size. This function then relies on `region_end()` function to compute the end of the region. `region_end()` function is susceptible to an integer overflow, which might result in the incorrect behaviour of `region_overlap()` function. An example of inputs that lead to wrong behaviour: ``` struct region r1 = {SIZE_MAX - 10, 20}; struct region r2 = {SIZE_MAX - 20, 15}; ``` It returns 0, but since the regions actually overlap, it should return 1. `region_overlap()` function is used in `smm_region_overlaps_handler()` function, which is itself used in SMI handlers to validate address values that come from an untrusted environment. This is necessary to prevent security vulnerabilities such as described in [BARing the System by Yuriy Bulygin, Oleksandr Bazhaniuk et al.](https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf) We do not have an example of an exploit based on this incorrect behaviour and are aware of the existence of one. However, theoretically, this could lead to security vulnerabilities. This bug was found during an ongoing [Coreboot Formal Verification Project](https://zaliva.org/UCSC-Twisted-Presentation-20231211.pdf), which aims to prove some important security properties of the coreboot’s SMI handler for the Gemini Lake/Octopus platform using Coq proof assistant and Verified Software Toolchain framework. ---Files-------------------------------- diff.txt (930 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-08-21 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 22 Aug '24

22 Aug '24

# 2024-08-21 - coreboot Leadership Meeting ## Attendees Martin Roth, Maximilian Brune, Werner Zeh, Nico Huber, Felix Held, Jon Murphy, Jonathan Hall, Karthik R, Matt DeVillier, Julius Werner, David Hendricks, Ron Minnich, Felix Singer, Mina Asante. ## Announcements & Events * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Martin] coreboot relies on VBOOT, but the API isn’t stable. Currently we can’t build coreboot without vboot at all. How do we want to handle this? * [Matt] For the majority of chromebooks, vboot is used in downstream builds, so has become a requirement. However one can’t update just the RW portion because the API has changed. You’re basically committing to a single version of coreboot & vboot when you create an RO. * Do we want to fork VBOOT? * This would create a number of issues * We can have multiple versioned VBOOT submodules. * Create a new VBOOT submodule version * Can we create submodules based on the final patch of vboot version * Julius: The real solution is to fix the board. * Can Google help us to specify and stabilize ABI versions? * Julius: coreboot has this own issue itself - When we update the car layout for example * Jon: Just because there are issues in one area doesn’t mean we shouldn’t try to fix it in other areas. We can look at fixing the different areas individually. * Julius: This would halt progress if we can’t change things. * Martin: we’re not saying that we can’t change things, just that we draw a line when we do change things. * Jon: Things should try to be backward compatible. * Julius: This isn’t a vboot problem - it’s a coreboot problem in general. * Jon: This is at least a starting point. * Martin: VBOOT is *AN* issue, let’s take issue one by one. * Julius: There are too many issues, and it may be a waste of time to try. * Jon: Let’s try to draw a line - we won’t fix everything, but let’s try to create mechanisms. We can at least try to separate coreboot & vboot. Let’s write a design doc to deal with this. * Julius: We’re already working to encapsulate vboot. It’s a more realistic goal to try to hold any breaking changes to a certain time. Keeping things stable for a year isn’t realistic. * Werner: Has google run into this? How does google handle it? * Julius: We cut a branch and ship any updates from the branch. * Jon: i’m not suggesting an annual roll. Just giving a year to come up with a plan. The current google method is problematic. This change would help both google and the community. * Martin: We can do quarterly releases of breaking changes like we do with toolchain updates. * David: Can we break the build when there’s a backward-compatible breaking changes? Google can create branches for porting features and test all their products, but upstream cannot. Our goal upstream is to avoid breaking boards in the upstream main branch, so it will help to signal to our builder that something is broken so incompatible boards can be removed. * Martin: It’s more of a boot test than a build test. The new RW wouldn’t be backward compatible with the old RO. * Werner: what breaks? * Matt: Basically the structures are no longer compatible. Changes to the major and minor versions will halt the boot. We want to avoid having downstream dependency break upstream coreboot. * Jon: Software versioning is an industry practice. Why can’t we update vboot for backward compatibility? Disable features that aren’t compatible. * Julius: The CAR stack size for intel was incompatible. To be compatible, you have to add asm and move things by the exact amount. This would be very early. For the AMD board, can we just update a new signed verstage? * Matt: Yes, we just got a new update. There was a 2 year period where things were broken. * Martin: we can add a check in the CI to make sure that an update to the vboot version number breaks the build. This would make sure that people are notified and new signed verstages are published. * Martin: Let’s work towards marking all backwards breaking changes. ### [Martin] We had a meeting with the SFC last week. * We currently have over $70K in the bank and our current expenses are around $20K per year for the server infrastructure. * We should again look at how we want to spend this, and who is going to manage the projects spending the money. SFC will help in this process. We’ve agreed that we (the coreboot project) do _not_ want to pay anyone for writing patches. * Some thoughts we’ve had for our needs in the past: * someone to do documentation * someone to help with reviews * a community manager (Mina is doing parts of this job now, but the job could be expanded significantly.) * Update the website SFC will help with a fund-raiser. * Currently, our main supporter is Google, who has donated $50,000 over the past two years. * [Jon Murphy] Google is willing to contribute more, but requires written justification. I can request $25,000 this year, but need to write a one pager on what it’s used for. Can I get help? Can the community take this action and include me [Jon Murphy](jpmurphy(a)google.com) * Martin will write something up as to what we want to use this money for. * If we’re actively spending the money, especially on salaries, the money goes fast, so we should look at * What should our priorities be? * MattD: A website is probably the first item. * Werner: This doesn’t need coreboot expertise. * FelixS: Documentation and a website. * Max: For documentation, we’d really need someone who already knows coreboot * Martin: My thought was that we want a tech writer who can learn the coreboot project. * David: Agree with Max - documentation tasks would have to be scoped to be very high-level for this to work. * Matt: We can separate this into 2 parts: the project documentation and the implementation/developer documentation. * Ron: Documentation needs to be structured as something ongoing. It’s typically out of date as soon as it’s written. * Max: Agreed - we have breaking changes and updates. * Martin: Right - we want to have a writer who keeps updating things. * There’s a stringent process on how to hire people. There’s a bidding process and a lot of rules. * David: We may have legal expenses - there’s a company using the coreboot logo without supporting coreboot, and have a generally terrible reputation. Not sure if legal funds come from SFC's 10% or if that would come from our budget. ### [Werner] Intel asks for feedback from the open source community on how open source is received. * They currently have the opinion that open source isn’t worth it and base it on their experience with EDK II. * Werner: We have meeting with intel, where we ask for more open source. Recently we had meetings where there was friction. Intel tried with edk2 and don’t see that it works. Offered to ask the community about why edk2 isn’t a good example. Why did it fail, and how can things be done better? * Ron: Clearly open source works - they’re a big contributor, but you can’t just dump anything out there and expect it to work. Edk2 is viewed as being a dumpster fire. * Werner: This comes from the firmware group * Nico: Continue the comparison with the linux kernel. Edk2 is completely different. It tries to be internal binary compatible. * Werner: it’s not that the code is bad, but the way it’s run * Matt: Trying to upstream into edk2 is very difficult, moreso than linux. Patches stagnate, hard to get code reviews. Dev process is difficult. Sean has had similar issues. * Ron: There is an open source culture and EDK2 hasn’t adopted it. They don’t accept change well. * Max: posted link to blog post. EDK2 is more closely linked to closed source. coreboot is different because it’s based on open source. We don’t upstream to edk2 because it’s too difficult. * [https://blog.aheymans.xyz/post/uefi-coreboot-comparison/] * Werner: is there a community around the EDK2 project * Max: Yes * Werner: Can I set up a doc to further the discussion? [Feedback on EDK 2 as open source project](https://docs.google.com/document/d/1P3GLpCufykSID1MjhSU47wI7nM-Jgb… * Feel free to add your thoughts on this into this doc and share it with whomever is interested in being part of this discussion. * Max: May accept github PRs now. * FelixS: Did intel give any reasons why it failed from their perspective? * Werner: not yet. * FelixS: My thinking is that theirs is currently an empty statement to prevent any further discussion. * Ron: Big question is what’s in it for you? They failed at open source, it didn’t fail them. * Werner: I don’t want to pass up an opportunity and get blamed for it. ## INFO ### [Martin] Patches Review Meeting Feedback * The 2nd review meeting was Wednesday, August 15th. There was positive feedback again about the usefulness of the time spent. Reviewed ~15 patches. The feeling is that anything that we can review and get moving is to the project’s benefit. ### [Martin] Looking at uncrustify as an alternative to clang-format. * David: Search gerrit for uncrustify. We tried it on flashrom a while back and had some promising results, but it fell somewhat short. I'll be interested to see how you approach it. ### [Martin] Info:coreboot 24.08 Release * Release tag planned for Thursday. * Please mark anything you want to be merged with the hashtag “coreboot_release_2408”. * Mark anything that should be merged after the release with the hashtag “post_coreboot_release_2408”. **Completed Action Items** * [Done] Martin: Work on [clang-format config update](https://review.coreboot.org/c/coreboot/+/7883). * We can use the clang format version from the coreboot toolchain. * Some issues with clang format - martin will present. * See [CB:78833](https://review.coreboot.org/c/coreboot/+/78833) for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best “judgement" basis. * [Done] Martin to add [bitfield example](https://review.coreboot.org/c/coreboot/+/78833/4/src/drivers/intel… to 78833 * Let’s look at running this just for .c files to start with. * [Done] PatrickG, FelixS, MartinR: Look at improving the responsiveness of gerrit. * This had a number of causes, mostly related to running out of storage, as well as both of the NVMe drives going bad. We’ve reduced the amount of data being saved by jenkins and replaced the NVMe drives # Next Leadership Meeting * September 4, 2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

Re: Stable RO/RW ABI discussion
by Julius Werner 22 Aug '24

22 Aug '24

[resent with correct sender address] Hi, I wanted to pick up the discussion from the leadership meeting again here because I think it's easier to show my point with a few examples. If you want an old coreboot RO build to work together with a ToT RW build, then you don't just care about the vboot workbuffer matching... *everything* that is shared in any way between bootblock/verstage and romstage/ramstage/payload needs to be kept in sync or risks introducing dangerous and not necessarily immediately obvious errors. One major issue is the pre-RAM memory layout. Take for example this simple one-line CL: https://review.coreboot.org/83680 . Would most reviewers expect that it makes RW firmware built after that point incompatible with RO firmware built before? Well, it does, because it increases the size of a memory region here https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/src/… which then moves the offsets of all subsequent memory regions downwards accordingly. Some of these regions contain buffers that were passed by the bootblock to later stages (e.g. CBFS_MCACHE, FMAP_CACHE), and when the romstage tries to reuse those buffers it suddenly finds different data at the same offsets. We actually had to figure out how to support this for an RW update to one of our shipped Chromebooks, and it looks like this: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/… . It needs an ugly, complicated assembly hack to copy bytes around from the locations where RO firmware left them into the locations where RW firmware expects them. Since one of these regions is the stack, you can't even do that in C code because you might already be trampling over the data you're still trying to save once you enter a C function. And this patch is just tailored to this one particular case (and platform), it's not a universal solution — if we were resizing a different region, or swapping the order of two regions, that would require a completely different (maybe impossible) workaround. Now, we could try to replace our simple memory region management with something more complicated that comes with a built-in tagged directory (kinda like a second CBMEM in pre-RAM). Then, if every single access to one of those regions went through that directory, it would automatically find the right location. We would need to write the code to parse that directory in assembly for every architecture, since the stack setup is one of the things that uses them. But even then, that doesn't solve the resize problem: if we e.g. find a rare stack overflow in the FSP that requires us to have a bigger romstage stack, then we can't just reuse the directory the bootblock has written, we need to actually change it to fix that bug and move all those regions around to fit the new requirements. And what if migrating from the old to the new layout on the fly is not possible? If we flip the order of two sections, there might not be enough free scratch space to temporarily save the contents of one section while we move the contents of the other into its place. (Note that car.ld is only the shared pre-RAM layout for Intel platforms. Every Arm and (recent) AMD platform has their own separate layout like this, and some of them tend to be very tight. We regularly have to land patches like https://review.coreboot.org/78970 to make some sections larger or smaller so that things still fit on certain platforms. Each of those changes would lead to one of these situations where suddenly the romstage needs to move everything into a different place from where the bootblock left it because it needs space for new things that the older code didn't account for.) There are plenty of other dependencies between RO and RW stages, many of them very abstract and platform specific. For example, on Arm SoCs we often have a clock tree where a few shared top-level PLLs get multiplexed onto many peripheral devices that each have their own pre-divisors. The PLLs are usually set up by bootblock code (because some of them are needed very early), and the peripheral divisors are usually configured by the driver that initializes that peripheral. If you e.g. initialize an I2C controller in ramstage to 400KHz, the I2C driver can calculate what divider to set based on the target frequency and a #define constant of what the top-level PLL was set to. But what if for some reason the top-level PLL frequency needs to change? Today we'd submit a patch to change that #define and all the peripheral driver code will continue to calculate accurate divisor values. But if you then try to combine that RW ramstage with an RO bootblock built before that change, suddenly your divisor will be calculated with an incorrect value and your I2C clock will either be too fast or too slow, resulting in maybe the peripheral not working, or maybe your boot speed just regressing in a way nobody will ever track down, or maybe the bus running slightly too fast so that on 99.9% of devices it will still work but on 0.1% of devices you suddenly start having an awful heisenbug that will be a royal pain to track down. There can be a near-infinite number of scenarios like this on various platforms where code running in a later stage depends on some hardware initialization that code running in an earlier stage did, and I see no practical way to track them all even if we did try to implement explicit backwards-compatibility for all of them. vboot is an optional feature in coreboot and most people aren't even using it. How are we going to get every developer/reviewer to care about whether a change they're about to make could subtly break compatibility for a feature they've never used? And even if we did find a way to perfectly track every possible dependency and wanted to implement backwards-compatibility for all of them, what is the cost for doing so (both the effort of writing it, and the amount of extra romstage code we need to carry around in our binaries)? Not every incompatibility is easy to fix up once you detect it. Let's go back to the vboot workbuffer, for example: the workbuffer contains among other things a couple of data structures that have been read from the TPM and contain information relevant at various points in the boot flow. Right now, two of those (secdata_firmware and secdata_kernel) get loaded in verstage, while the third (secdata_fwmp) only gets loaded in our payload. But we have been discussing that we might want to (for various reasons) change this in the future so that secdata_fwmp is also loaded in verstage. Let's say we make that change, and we want to stay backwards compatible to RO firmware built before it. That means that early in romstage, before any new code that depends on secdata_fwmp runs, we'll need to run some code that checks the workbuffer version and fixes this incompatibility if it is too old. But in order to be able to load secdata_fwmp, we'll need to link the entire TPM driver stack into romstage which otherwise wouldn't be needed there on many platforms. So we are bloating our binary size in a potentially space-restricted pre-RAM stage just to be able to fix an issue that most people are never going to care about. Multiply that by the dozens of possible incompatibilities that will accumulate over the years. I totally understand that it would be great if we could just build a system where you can just run any RO and RW together and have them work it out, but I really don't think that's feasible in practice. vboot was not designed to support that, for good reason. And if we tried to just get started on adding compatibility code for specific issues that people have on a specific platform right now to "see how far we get", I don't think it's going to work out in the long term and it will just lead to disruption and extra code complexity right now that's eventually not going to pay off for anyone. It may work for the one platform you care about for a while but sooner or later there'll be another compatibility break that you can't easily mitigate. And if people start to rely on this working then they may get angry if someone else makes a change that is going to break compatibility on their platform in a way that can't be fixed, which I think would be a bad thing, because we do need to be able to develop new features and fix architectural issues (both in vboot and in other code that can cause RO->RW dependencies) unburdened by legacy code from years ago.

4 5

[announce] flashprog v1.2 is ready!
by Nico Huber 20 Aug '24

20 Aug '24

Hi all, I'm happy to announce the flashprog v1.2 release. This one should be particularly interesting for developers: We have finally added the first bits for multi-i/o fast reads and QPI support. QPI works well with a new driver for programmers based on the FT4222H. Dual- and quad-i/o reads are also implemented for the Dediprog SF600 and its successors. Of the latter, the SF600Plus-G2 is fully tested. Other versions, using the same protocol, should work as well. Dual-i/o is enabled by default for these. With all four i/o lines connected, quad-i/o reads can be enabled with $ flashprog -p dediprog:iomode=quad (don't forget to also set the `spispeed` to go even faster) SF600 models that use older protocol versions should work as well but are untested. For those, `iomode=dual` is necessary for dual- i/o. Test reports are most welcome! See also the full release notes at [1]. The code is available in Git[2] (tag `v1.2') and as tarball[3]. After the release is before the release, and we are currently loo- king for testers of new chipset support: On the Intel side we have patches prepared for Snow Ridge, Meteor Lake, and Emmitsburg (PCH) (newer Xeon-SP systems) [4]. For AMD, everything up to and including Zen 4 is supported as long as the chipset is not too locked down. More testing here would be welcome, though, so we know what configurations vendors ship. Happy flashing, Nico [1] https://flashprog.org/wiki/Flashprog/v1.2 [2] https://github.com/SourceArcade/flashprog [3] https://flashprog.org/releases/flashprog-v1.2.tar.bz2 [4] https://review.sourcearcade.org/q/status:open+topic:moar_ichspi

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 19 Aug '24

19 Aug '24

Dear coreboot community, Please be reminded that our upcoming leadership meeting is scheduled for Wednesday, August 21, 2024.[1] Kindly take a moment to review the current agenda and share your thoughts or suggest additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda ### [Martin] coreboot relies on VBOOT, but the ABI isn’t stable. Currently we can’t build coreboot without it at all. How do we want to handle this? * Do we want to fork VBOOT? * Can Google help us to specify and stabilize ABI versions? ### [Martin] Looking at uncrustify as an alternative to clang-format. ### [Martin] We had a meeting with the SFC last week. We currently have over $70K in the bank and our current expenses are around $20K per year for the server infrastructure. ### [Martin] Patch Review Meeting Feedback * The 2nd review meeting was Wednesday, August 15th. There was positive feedback again about the usefulness of the time spent. Reviewed ~15 patches. The feeling is that anything that we can review and get moving is to the project’s benefit. ### [Martin] Info:coreboot 24.08 Release * Release tag planned for Thursday. * Please mark anything you want to be merged with the hashtag “coreboot_release_24.08” * Mark anything that should be merged after the release with the hashtag “post_coreboot_release_24.08” ## Announcements & Events * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

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

17 Aug '24

Issue #121 has been updated by Anastasios Koutian. Have been using this change: https://review.coreboot.org/c/coreboot/+/78609 since it was merged (May 23) and haven't seen any freezes. It's possible that this solves the issue. Can others confirm? ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1893 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 16 Aug '24

16 Aug '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, August 21, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Assistance Required: MSI PRO Z790-P WiFi DDR4 - No Display Output After Coreboot ROM Update
by William Chen 15 Aug '24

15 Aug '24

*Dear Coreboot Support Team,* I hope this email finds you well. My name is [Your Name], and I am currently working as a BIOS developer. I am reaching out to seek assistance regarding an issue I have encountered while working with Coreboot on an MSI PRO Z790-P WiFi DDR4 motherboard. *Issue Description:* I successfully updated the ROM on the aforementioned motherboard using Coreboot. After flashing the ROM and powering on the system, the motherboard appears to be functioning—fans are spinning, and the board is receiving power—but there is no display output on the monitor. The motherboard has two display outputs: one DisplayPort and one HDMI. Since I do not have a suitable connector for the DisplayPort, I am using the HDMI output for display. Unfortunately, there is no signal on the monitor, and I am unsure whether this is related to the HDMI output, Coreboot configuration, or another issue. *Steps Taken:* - Confirmed the motherboard powers on correctly (fan is spinning). - Verified the HDMI cable and monitor are functional by testing with another system. - Double-checked the ROM update process to ensure there were no errors. *Request for Assistance:* Could you please provide guidance on how to resolve this issue or suggest any troubleshooting steps that I might have overlooked? Any advice or support would be greatly appreciated, as I aim to ensure proper functionality with Coreboot on this specific hardware. Thank you in advance for your time and assistance. I look forward to your response. *Best regards,William*

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 13 Aug '24

13 Aug '24

Hello coreboot, Please be reminded we are having a group review session tomorrow: https://meet.google.com/kpu-yozw-gtt. Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html. We’ll be reviewing a few RFC patches together, then switch to reviewing patches individually for a bit, but everyone will be available if you have questions about the patch you’re reviewing. Here’s the link to the list of patches to be reviewed: https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… If you have patches you’d specifically like the group to review, please add them to the top of the sheet. Given the limited time for the review session, any reviews that are done before the session are highly appreciated. Thank you. Best regards, Mina.

1 0

[coreboot - Support #550] (New) Help with dGPU integration with edk2 on W530
by Simon Dominic 10 Aug '24

10 Aug '24

Issue #550 has been reported by Simon Dominic. ---------------------------------------- Support #550: Help with dGPU integration with edk2 on W530 https://ticket.coreboot.org/issues/550 * Author: Simon Dominic * Status: New * Priority: Normal * Target version: none * Start date: 2024-08-09 * Affected versions: master * Affected hardware: Lenovo ThinkPad W530 ---------------------------------------- I run Debian and Windows 11 on my corebooted Thinkpad W530 with edk2 payload. Until recently I was using SeabBIOS, which in my experience has been a lot simpler to set up and integrate the dGPU via vga bios. The dGPU is necessary to use external displays for the W530. With a lot of [help from Matt DeVillier](https://ticket.coreboot.org/issues/549), I made the switch to edk2 with this defconfig: ``` CONFIG_USE_OPTION_TABLE=y CONFIG_VENDOR_LENOVO=y CONFIG_CBFS_SIZE=0x300000 CONFIG_VGA_BIOS_DGPU_ID="10de,0ffc" CONFIG_VGA_BIOS=y CONFIG_IFD_BIN_PATH="descriptor.bin" CONFIG_ME_BIN_PATH="me.bin" CONFIG_GBE_BIN_PATH="gbe.bin" CONFIG_VGA_BIOS_FILE="vgabios/8086,0166.rom" CONFIG_HAVE_IFD_BIN=y CONFIG_BOARD_LENOVO_W530=y CONFIG_HAVE_ME_BIN=y CONFIG_USE_ME_CLEANER=y CONFIG_HAVE_GBE_BIN=y CONFIG_MAINBOARD_USE_LIBGFXINIT=y CONFIG_VGA_BIOS_DGPU=y CONFIG_VGA_BIOS_DGPU_FILE="vgabios/10de,0ffc.rom" CONFIG_ELOG=y CONFIG_PAYLOAD_EDK2=y CONFIG_EDK2_BOOT_MANAGER_ESCAPE=y CONFIG_EDK2_FOLLOW_BGRT_SPEC=y ``` If I set graphics initialization to "Run VGA Option ROMs", the system completely hangs and I get a white underscore. libgfxinit works. With nvramtool. I can set hybrid_graphics_mode to "Dual Graphics". Interestingly, external displays is working on (Debian) **Linux**, but only detects the Intel iGPU. Specifically, even though I've chosen dual graphics, fastfetch only shows that one GPU, and not "GPU 1" and "GPU 2", and yet I get the functionality of the dGPU of external displays. On **Windows**, external display functionality doesn't work, and Windows Updates does not install Vulkan or Nvidia drivers like it did with the stock bios. When I change hybrid_graphics_mode to "Discrete Only", I get a black screen on boot. This can be reversed by resetting the CMOS settings by disconnecting the CMOS battery, removing the battery and powering on with just the charger plugged in. What can be done to have the dGPU actually properly detected (both Linux and Windows), and not cause black screen when selecting discrete graphics only? -- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 09 Aug '24

09 Aug '24

Hello coreboot community, We are doing a group review session next wednesday: https://meet.google.com/kpu-yozw-gtt. Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html We’ll be reviewing a few RFC patches together, then switch to reviewing patches individually for a bit, but everyone will be available if you have questions about the patch you’re reviewing. Here’s the link to the list of patches to be reviewed: https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… If you have patches that you’d specifically like to have reviewed by the group, please add them to the top of the sheet. We are obviously limited on time during the review session, so any reviews that are done before the session are appreciated. We definitely don’t expect to get everything reviewed. Thank you very much, we hope to have a good turnout. Best regards, Mina.

1 0

2024-08-07 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 08 Aug '24

08 Aug '24

# 2024-08-07 - coreboot Leadership Meeting ## Attendees Martin Roth, Matt DeVillier, Felix Held, Jay Talbott, Max Brune, Karthik Ramasubramanian, Mina Asante, David Hendricks, Julius Werner, Ron Minnich. ## Announcements & Events * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Max] RISC-V Architecture * Our RISC-V architecture is not really in a good shape. I have added a few patches over the last few months, but it is hard to find reviewers here, because there is not a single vendor that actually uses RISC-V on coreboot. So I would like to get temporary permission to merge my own patches. We don’t have any vendor depending on the architecture and the mainboards haven’t worked for months if not longer so I assume there are also not many other depending on it. Just to clarify I only ask permission to merge my own patches as long as they don’t influence code outside of RISC-V. My goal is to get the architecture properly running for actual hardware and QEMU. We can also add a restriction that I am only allowed to merge them if they haven’t been reviewed for ~1 month. I am not in a hurry anyway, but I would like to see them merged at some point. * [Martin] Ron might be able to help review the RISC-V portion. I still think we should have reviewers evaluate the patches. I’d be happy to help review patches for things other than evaluating correctness of the RISC-V architecture. * [Martin] Should we find a platform to port as our eval board for RISC-V? * Currently we have 2 platforms, and soon will have 4. * FelixH: would rather get at least one reviewer. * Add to the bi-weekly review list if needed. ### [Martin] coreboot Patches Review. * Last week’s review hour worked pretty well - there were about 6 of us on the call. We reviewed RFC patches together for about 40 minutes and then separated to review individual patches. The general feeling was that it was useful and that we should continue. * If there are any patches that people specifically want reviewed, add them to the list when it’s sent out. * The goal of that meeting is to help get patches merged. * Let us know if you want to be invited. * Or go to [https://coreboot.org/calendar.html] and add yourself * Martin: I don’t think this works - I believe only guests can modify the event to add other guests. * We’ll generate a list of patches we plan to review the week before the meeting - hopefully those can be looked at in the week before the meeting. * WIP patches will not be reviewed, with the exception of RFC patches. * The general search for patches we'll be reviewing: * repo:coreboot AND status:open AND age:1week AND -age:6months AND -is:wip AND -has:unresolved AND -label:Code-Review-1 AND -label:Verified-1 AND -is:wip ### coreboot 24.08 Release * Next release is planned to be tagged on 2024_08_22, the day after the next leadership meeting. This is 1 week later than initially planned to allow more time for testing. * Please mark anything you want to be merged with the hashtag “coreboot_release_24.08” * Mark anything that should be merged after the release with the hashtag "post_coreboot_release_24.08". ### [DavidH]: Looking at linkedin - Intel just cut a huge chunk of the workforce. Dell too. Please post any jobs you know of. * 9elements Open Positions: [https://9esec.io/team] # Next Leadership Meeting * August 21,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes [2024-08-07](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1….

1 0

Incorrect Intel GPU IDs for Comet Lake CPUs
by Maxim Polyakov 07 Aug '24

07 Aug '24

It seems that some of the graphics device IDs for intel Comet Lake CPUs are incorrect. According to the supported GPU list [1], fixed them in https://review.coreboot.org/c/coreboot/+/83708. If you support a motherboard with -S or -H processors, then please take a look at this patch. And it would be great if someone from Intel checked out these changes. Thx [1] https://web.archive.org/web/20240731152818/https://dgpu-docs.intel.com/devi… // Regards, // Max

1 0

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel 07 Aug '24

07 Aug '24

Issue #420 has been reported by Krystian Hebel. ---------------------------------------- Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… ---------------------------------------- Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- 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

4 12

24.08 release schedule
by coreboot org 07 Aug '24

07 Aug '24

Hello coreboot, This is the notification that we're two weeks away from doing the coreboot 24.08 release tag, which is scheduled for Thursday August 22nd. Please mark patches you want to be merged before the release with the hashtag “coreboot_release_24.08”. There's no promise that these will get merged, but we try to get everything on the list in. Mark any patches that should be merged *after* the release with the hashtag "post_coreboot_release_24.08" As usual, we will have a 1 week delay after the new version is tagged to allow for testing of the release. This will give us a chance to fix any issues that are found during the release process before making the release public. The 24.08 public announcement is scheduled for August 29th. If you have any questions or concerns, please let the coreboot release team know. Martin

1 0

FLOSS firmware status on new Qualcomm Snapdragon X Elite devices
by Paul Menzel 07 Aug '24

07 Aug '24

Dear coreboot folks, What parts of the firmware of the new Qualcomm Snapdragon X Elite devices, like Dell XPS 13 9345 [1], are FLOSS? Are these ARM devices good coreboot targets? Kind regards, Paul PS: With this new architecture, was coreboot/U-Boot ever considered, or is the x86 ecosystem of independent BIOS vendors (IBVs) so dominant, that no alternatives were considered? [1]: https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=h0v…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 05 Aug '24

05 Aug '24

Dear coreboot community, Please be reminded that our upcoming leadership meeting is scheduled for Wednesday, August 7, 2024.[1] Kindly take a moment to review the current agenda and share your thoughts or suggest issues you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda Items * [Max] RISC-V Architecture * Our RISC-V architecture is not really in a good shape. I have added a few patches over the last few months, but it is hard to find reviewers here, because there is not a single vendor that actually uses RISC-V on coreboot. So I would like to get temporary permission to merge my own patches. We don’t have any vendor depending on the architecture and the mainboards haven’t worked for months if not longer so I assume there are also not many other depending on it. Just to clarify I only ask permission to merge my own patches as long as they don’t influence code outside of RISC-V. My goal is to get the architecture properly running for actual hardware and QEMU. We can also add a restriction that I am only allowed to merge them if they haven’t been reviewed for ~1 month. I am not in a hurry anyway, but I would like to see them merged at some point. ## Announcements & Events * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…. [2](https://coreboot.org/calendar.html).

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 02 Aug '24

02 Aug '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, August 7,2024.[1] Kindly update the current agenda with matters you wish to see dicussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Re: RW_MRC_CACHE always displays needs update and boot time is more
by Moorthi M.s 31 Jul '24

31 Jul '24

Hi Paul, > > Thanks for your reply. > > I figured out the issue. > > The ME CPU replayed option is printing as YES, and this forces the MRC > training on each reset. > > Updated the ME firmware, and the issue was solved. > > Regards, > Moorthi S > On Wed, Jul 31, 2024, 12:02 Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > >> Dear Moorthi, >> >> >> Welcome to coreboot. >> >> Am 31.07.24 um 07:45 schrieb Moorthi M.s: >> >> > I am developing coreboot (ver 4.17) along with UEFI payload for a custom >> > board derived from CFL H RVP11 CRB. >> > >> > I included the CACHE_MRC_SETTINGS to reduce the boot time on subsequent >> > power on. >> > >> > But the time was not reducing and on every power on, around 18 seconds >> are >> > taking between post code 0x92 (Ram Init) and 0x98 (Ram Init Exit). And >> > always prints as " MRC: cache data 'RW_MRC_CACHE' needs update". >> > >> > Because of this coreboot takes around 45 secs to boot. >> > >> > Why every time the MRC cache data is changing? Why the processor is not >> > using the MRC cached data? >> >> Without knowing the code you are using, nobody knows. Did you dump the >> cache data to compare? >> >> > Is there any other configurations needs to be done? >> Unfortunately, you did not provide enough information to answer your >> question. Please provide at least your configuration and the verbose >> logs. Best would be to upload your code (and the schematics). >> >> Also, why do you use coreboot 4.17? 24.05 is the latest release. >> >> >> Kind regards, >> >> Paul >> >> >> PS: Just to mention it, there are coreboot consultants [1], that might >> save you some time in the end. >> >> >> [1]: https://coreboot.org/consulting.html >> >

1 0

RW_MRC_CACHE always displays needs update and boot time is more
by Moorthi M.s 31 Jul '24

31 Jul '24

Hi, I am developing coreboot (ver 4.17) along with UEFI payload for a custom board derived from CFL H RVP11 CRB. I included the CACHE_MRC_SETTINGS to reduce the boot time on subsequent power on. But the time was not reducing and on every power on, around 18 seconds are taking between post code 0x92 (Ram Init) and 0x98 (Ram Init Exit). And always prints as " MRC: cache data 'RW_MRC_CACHE' needs update". Because of this coreboot takes around 45 secs to boot. Why everytime the MRC cache data is changing? Why the processor is not using the MRC cached data? Is there any other configurations needs to be done? Regards, Moorthi S

2 1

New extra-selectors mechanism on superiotool
by Maxim Polyakov 26 Jul '24

26 Jul '24

Hello community! I am adding support for f81866 and f81966 fintek chips in superiotool: https://review.coreboot.org/q/topic:%22fintek%22 However, there are some difficulties to make a dump of the registers of these chips. Their global LDN0 and HWM registers contain fields that switch the register banks of these devices. At the same time, these registers contain fields that should not change after they are configured. For example, <Port Select Register - Index 27h> register contains: BANK_PROG_SEL field[3-2] - Bank select for configuration registers (bank 0/1/2/3) and PORT_4E_EN[4] - 0: The configuration register port is 2E/2F. 1: The configuration register port is 4E/4F. I suggest introducing a new element in chip configuration for such registers - an extra selector: https://review.coreboot.org/c/coreboot/+/83196 It seems to me that this is the optimal solution. This allows superiotool to configure the register fields to select a bank before making a correct dump for the corresponding LDN in automatic mode. Please review. Thx // Regards, // Max

1 0

2024-07-24 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 25 Jul '24

25 Jul '24

# 2024-07-24 - coreboot Leadership Meeting ## Attendees Martin Roth, Felix Singer, Felix Held, David Hendricks, Marshall Dawson, Maximilian Brune, Lean Sheng Tan, Nico Huber, Matt DeVillier, Werner Zeh, Paule Panter, Ron Minnich, Julius Werner, Jason Glenesk, Mina Asante. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Elyes] Submodules * chromeec and opensbi are a pain (#83466 and #83464 ) Not only they have not been updated for more than two years, they can block future improvements (as testing & prepare for C23 see (https://qa.coreboot.org/job/coreboot-toolchain/1646/testReport/junit/(root)… CV_RV64_/) ) * [Martin] I did a little work towards this a while back, looking at fixing chromeec by turning it from a submodule into something more like what we do for payloads. This would let different mainboards specify different versions. Unfortunately, this makes the CI very difficult, as one platform could check out a different version as another platform is building it. I’d suggest we just abandon chromeec from the build completely. Even Google never used it as a part of the coreboot build. * Julius mentioned that there was recently a discussion inside google about using the shared header. * Martin: The chromeEC submodule is huge and in my opinion we should just continue copying the single header file. * Decision: Drop ChromeEC submodule from coreboot. * [Max] regarding OpenSBI: The pain point is mostly src/arch/riscv/opensbi.c since it includes the sbi/fw-dynamic.h from the opensbi repo. I feel the pain since I have had trouble with it in the past too. There are 3 solutions I can think of. 1. We remove it and merge [https://review.coreboot.org/c/coreboot/+/83284] I will try to merge it anyway, since vendors tend to fork OpenSBI rather than upstreaming it. 2. We rewrite src/arch/riscv/opensbi.c to not include the opensbi header. Shouldn’t be too hard to add the structs and types that we need ourselfs. 3. We remove it and implement our own SBI implementation (very unlikely) * Ron (mostly) revived the SBI functionality from 10 years ago. The idea to remove the openSBI header is a good one. * Max - there are only a couple of structures we need. Will prepare a patch this week. ### [Elyes] prepare for experimental and incomplete C23 * If we opt to test and prepare for C23, and if we have to choose one functionality, would it be the use of nullptr constante and nullptr_t type ? (N3042) see [https://review.coreboot.org/c/coreboot/+/83459/8] Is that the right way? * One more question: If you have to choose only one “thing” that would improve the coreboot code (ISO C11 / 17) what would it be? * [Max] As a side note: If we use C23 I would like to make use of some of its features in coreboot code in general. For example using the “#embed” for our unit tests and using a separation to write long memory addresses (e.g. write 0xFFFF_FFFF instead of 0xFFFFFFFF) * Julius: I’d advocate we don’t do this - this is something brought in from c++ to address things that aren’t generally applicable to coreboot. It’d be very intrusive. * Ron: Unless there’s some benefit that we don’t currently see, what’s the point? * Julius: There’s no objection to using C23 in general, but the nullptr_t type doesn’t gain us anything. Max++ * Decision: Not looking to pursue this currently. ### [Sheng] RFC for UPL support patch by Max *[https://review.coreboot.org/c/coreboot/+/76591] * Please review. * Matt: Some of the names could be improved. * Martin: Let’s put this discussion off until next week - I’ll make sure that it’s in the list of patches to review. * UPL Spec is in github - please contribute. * [https://universalpayload.github.io/spec] * U-boot support: [https://patchwork.ozlabs.org/project/uboot/list/?series=416058] * Edk2 as well. Linuxboot will follow after ### [Nico] Flashprog releases and HW support * Flashprog does regular releases now. Is it ok to announce them on the coreboot ML (about every 3~4 months)? Just checking if anybody has feelings against it… * Probably a little more delicate: What to do about stale "Flashrom support" lines in docs and board_info.txt where it's known broken? remove? replace w/ Flashprog? do nothing? * Martin: Let’s add a line for flashprog support. If flashrom is broken on a platform mark it as no. * David: Do we want to create a CSV list for flash programs instead of separated lines? * Martin: this seems reasonable to me. * Nico: We’d need to update the various scripts to generate the website and lint the file. Nico can take a look at this. * Matt: Sure, we can even add non-open firmware flash packages. # Next Leadership Meeting * August 7,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes [2024-07-24](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 22 Jul '24

22 Jul '24

Dear coreboot community, Please be reminded that our upcoming leadership meeting is scheduled for Wednesday, July 24,2024.[1] You are encouraged to review the current agenda and share your thoughts or suggest issues you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda Items ### [Elyes] * [Submodules] chromeec and opensbi are a pain (#83466 and #83464 ) Not only they have not been updated for more than two years, they can block future improvements (as testing & prepare for C23 see [https://qa.coreboot.org/job/coreboot-toolchain/1646/testReport/junit/(root)… CV_RV64_/] * [prepare for experimental and incomplete C23] If we opt to test and prepare for C23, and if we have to choose one functionality, would it be the use of nullptr constante and nullptr_t type ? (N3042) see [https://review.coreboot.org/c/coreboot/+/83459/8] Is that the right way? * One more question: If you have to choose only one “thing” that would improve the coreboot code (ISO C11 / 17) what would it be? ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://www.coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 19 Jul '24

19 Jul '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, July 24,2024.[1] Kindly update the current agenda with matters you wish to see dicussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[ANNOUNCE] Go utility *hda-decoder*
by Paul Menzel 16 Jul '24

16 Jul '24

Dear coreboot and Linux folks, The utility *hda-decoder* written by Nicholas Sudsgaard was just submitted to the coreboot repository [1][2]. > util: Add hda-decoder > > This tool helps take off the burden of manually decoding default > configuration registers. Using decoded values can make code more > self-documenting compared to shrouding it with magic numbers. > > This is also written as a module which allows easy integration with > other tools written in Go (e.g. autoport). Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/80470 [2]: https://review.coreboot.org/plugins/gitiles/coreboot/+/b205f4e53ec30487ea1c…

1 0

Announcement: Official V0.9.1 Release for Universal Payload Sepcification
by Lean Sheng Tan 13 Jul '24

13 Jul '24

Hi everyone, After 2 years of endless discussions and relentless effort, we officially landed the V0.9 (and V0.9.1) of *Universal Payload Specification (UPL)* yesterday!!! V0.9 formally introduces using Device Trees as the standardized Payload Handoff Format to pass data from Platform Init (e.g. coreboot) to Payload (e.g. UEFI payload or LinuxBoot). This reduces the data handoff friction and proprietary handoff formats currently exist in each and every firmware project (e.g. HOB, coreboot table). A brief historical background: Universal Payload started as a sub-project under Intel's Universal Scalable Firmware Initiative. Since its introduction, Intel has been actively seeking for the firmware community's input to help make it a reality, to help standardise a common architecture and interfaces between Platform Init and Payload. Later on, 9elements actively collaborated with Intel to work with all major firmware projects (coreboot, U-Boot, edk2, Linuxboot) with the support of all architecture (x86, Arm, RISC-V). We have been actively promoting and collecting feedback in every means we could (mailing lists, OSFC, OCP Global Summit, COSCUP). I could not find words to summarize the 2 years tireless efforts made by all the UPL contributors: with about *2-4 meetings per month since May 2022*; countless back and forth discussion and some compromises made in between to find common ground that fits all Firmware solutions and projects; some technical setbacks with failed POCs and then persistent testings on coding sites; new expectations and issues pop up now and there that setback the initial timeline again and again... I owe all of them my greatest gratitude for their hard work. I would like to specially thanks *Vincent Zimmer* from Intel for making this happen in the first place - early commitment from *ARM*, Intel/ edk2 / Slimbootloaders maintainers, *Chasel Chiu* and *Dong Guo*, *Maximilian Brune* and *Arther Heymans* from coreboot, *Dhaval Sharma* and *Aaron Durbin* from Rivos, and *Simon Glass* & *Ron Minnich* who are both great visionaries in the Open Firmware world. In short, this is truly the first ever community effort that brings all firmware communities to collaborate together, in the very common goal to make Open Source Firmware a better place for everyone. For sure, this cannot and never will please everyone, and like all things there are always many issues in the first revision. Hence, I sincerely pledge to all of you, to help and contribute to this spec. This is an open invitation, as we follow the ethos of "*For Community, By Community*", the first open source spec that is owned by all the open firmware communities. Please refer here for the latest spec: *universalpayload.github.io/spec <http://universalpayload.github.io/spec>* Feel free to contribute here: *https://github.com/UniversalPayload/spec <https://github.com/UniversalPayload/spec>* WIP coreboot patch: *https://review.coreboot.org/c/coreboot/+/76591 <https://review.coreboot.org/c/coreboot/+/76591>* Last but not least, I also wanted to specially thank 9elements Cyber Security for all the support since the very beginning that helps me to navigate through all the hurdles and issues for the past 2 years. Let's continue to work together for a better Open Source Firmware for everyone. Thanks, Sheng

2 1

VxWorks 7 rebooting with UEFI payload
by Moorthi M.s 11 Jul '24

11 Jul '24

Hi, I am developing coreboot along with UEFI payload for a custom board derived from CFL H RVP11 CRB. Modifications are done as per the custom board and board was booted to CentOS and Windows. When we try to boot VxWorks 7 with native UEFI loader, the board was rebooting. But the same UEFI loader and VxWorks image is booting with BIOS version of the same custom board. Is there any modification need to be done to boot VxWorks 7? Thanks & best regards, Moorthi S

1 0

2024-07-10 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 09 Jul '24

09 Jul '24

Dear community, Please note that tomorrow's coreboot leadership meeting has been canceled because there are no items on the agenda to discuss. Thank you. Best regards, Mina.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 08 Jul '24

08 Jul '24

Dear coreboot community, At the moment, there are no topics listed on the agenda for the leadership meeting this Wednesday. If there are no additions by the end of the day tomorrow, the meeting would have to be cancelled. If you have any topics you would like to discuss, kindly add them to the agenda items.[1] Thank you. Best regards, Mina. [1](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Enforcing coreboot as lowercase
by Arthur Heymans 08 Jul '24

08 Jul '24

Hi The coreboot trademark is registered as lowercase. We enforce this in for instance commits, even when normal grammar would dictate uppercase at the start of a sentence. This makes sense for very well known brands, companies and products like "eBay", "iPhone", "AMD". They are all very well known trademarks and they have some uppercase letter in them in atypical places. For these words grammar exceptions seems reasonable. Coreboot is a reasonably well known as a project, but little people know about the specificity of the trademark. This often causes confusion on people either reading "coreboot" at the start of a sense, where it looks grammatically wrong, making it even look unprofessional in the eyes of some. This is because there is no other uppercase letter inside coreboot that would make it a typical exception to regular grammar rules. People getting into the project making the mistake at the start of a sentence, might get the wrong impression of too many idiosyncrasies. On top of that it takes a non zero amount of effort on people in the project to educate others on this trademark thing. Also trademark are typically a bit more broad than exactly how they are registered. I cannot start a company called iNTel or aMD that makes chips. I cannot put a product on the market called "IPHoNE". I think the same applies to "coreboot". So my question is: can we relax the trademark in lowercase enforcement? I would suggest to simply allow both ways. Arthur Heymans

7 8

Question about DISB handling in memory init
by Joursoir 06 Jul '24

06 Jul '24

Hello there, I have been studying the memory initialization process on the Alder Lake platform, like what's going on before and after utilizing FSP-M binary. And while I was studying sources I stumbled upon the following function (src/soc/intel/alderlake/pmutil.c): ``` /* Set the DISB after DRAM init */ void pmc_set_disb(void); ``` It's actually defined in every Intel SoC header and contains SoC-specific implementation. The comment and name function assert that func sets the DISB bit. And yes, it does it. However, I opened Intel 600 Series Chipset Family for IoT Edge Platform Controller Hub (PCH) Datasheet, Volume 2 (dated October 2022, Revision 001) and it asserts the opposite: ``` DRAM Initialization Scratchpad Bit (DISB): <skipped text>. BIOS is expected to set this bit prior to starting the DRAM initialization sequence and to clear this bit after completing the DRAM initialization sequence. BIOS can detect that a DRAM initialization sequence was interrupted by a reset by reading this bit during the boot sequence. If the bit is 1, then the DRAM initialization was interrupted. ``` So it suggests *clearing* the bit after DRAM init. Why does coreboot do the opposite? I was trying to study git history to find out, but it didn't give me any answer to my question as well. So maybe somebody on the mailing list knows more about it? Is it a typo in the Intel docs? -- Joursoir

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 05 Jul '24

05 Jul '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, July 10,2024.[1] Kindly update the current agenda with matters you wish to see dicussed during the meeting[2] Thank you. Best regards, Mina Asante. [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

2024-06-26 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 28 Jun '24

28 Jun '24

# 2024-06-26 - coreboot Leadership Meeting ## Attendees Felix Singer, Felix Held, Werner Zeh, Jonathan Hall, David Hendricks, Jay Talbott, Mina Asante, Martin Roth, Karthik Ramasubramanian, Marshall Dawson, Shelley Chen, Maximilian Brune, Lean Sheng Tan. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ## Improving coreboot processes ### [Martin] bi-weekly review meetings * In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour and we’ll see where things progress from there. Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in some other time zone that may switch based on daylight savings?) * 17:00 UTC on Wednesdays opposite the leadership meeting. * David: Start a new google doc to ask for reviews. * Werner: Dedicated email address * Felix: Would it be better to just generate a list? * David: Let’s do both requests and generate a list of patches to review. * Karthik: Should maintainers be involved? * Martin: Absolutely, if they come to the meeting. * David: The idea is to remove bureaucracy * Werner: Who should we invite? * Martin: core devs * Felix: We can change things that don’t work well. ### [Martin] Merge SLOs * Can we define objectives for timeframes to get patches merged to different areas in the codebase? An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform. * Mainboard: 1 week? * FelixH: So what do we do if we get past this timeframe? Just merging anything because it’s passed the SLO period seems like a bad idea. * David: This is designed to help people who are new to the project. We don’t just want to merge stuff, but for isolated code, maybe we can look the other way at imperfections. * FelixH: Frequently add comments and mark as resolved. * David: SoC code still needs to be held to higher standards. * David: We still expect authors to be responsive to feedback. * FelixH: We still need reasonable patches as well - one logical change per patch. * Martin: Do we want any areas besides Mainboards? What about SIOs? * Werner: Maybe drivers? * Max: Everything other than mainboards can be used by multiple vendors? * Martin: It doesn’t seem unreasonable to try to get things merged in a month. * FelixH: It would be good to have a list of things to look at. * Martin: Send out an email with a list of patches which will be looked at in the next meeting? (Yes) * Add a month SLO for drivers & SIOs initially. ### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU… * Werner: How do we make sure we don’t address the wrong drive? * Karthik: Define a rule in FMAP to describe the characteristic of the disk. * Werner: Wouldn’t coreboot need to search all of the disks? Finding it would be tricky. * Werner: Don’t like searching multiple partitions. * Martin: So would this just be in libpayload * Karthik: The initial code would be just for libpayload. * Martin: I can’t really think of any uses for this in coreboot other than a splash-screen, so I’d really prefer that it just stayed a part of libpayload. * Karthik: We can keep this just a part of libpayload. If we ever need to change that, we can address that again at that point. A notice will be added. * Werner: Last time I dealt with EMMC, there was a difference in speed - training slowed things down and it needed write support. * Martin: I feel like there’s a big difference between training and any writes needed for that, and actually accessing data on the drive. I’m not opposed to the idea of starting training earlier. * David: Are there any patches? * Karthik: I can upload patches in the next week or so - it’ll be a WIP patch. ### [Martin]: Setting aside the reformatting project with clang-format until it’s more stable and has fewer quirks. # Next Leadership Meeting * July 10,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes *[2024-06-26](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?p).

3 2

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 24 Jun '24

24 Jun '24

Dear coreboot community, Please be reminded that our upcoming leadership meeting is on Wednesday, June 26.[1] You are welcome to review and update the current agenda items with any matters you wish to see discussed during the meeting.[2] Below are the items currently on the agenda. ## Current Agenda Items ## Improving coreboot processes ### [Martin] bi-weekly review meetings * In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour and we’ll see where things progress from there. Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in some other time zone that may switch based on daylight savings?) ### [Martin] Merge SLOs * Can we define objectives for timeframes to get patches merged to different areas in the codebase? An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform. ### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU…. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[coreboot - Support #534] Enable Ethernet (LAN) on ADL-P Custom Board
by Mahesh Kilumu 24 Jun '24

24 Jun '24

Issue #534 has been updated by Mahesh Kilumu. % Done changed from 0 to 100 ---------------------------------------- Support #534: Enable Ethernet (LAN) on ADL-P Custom Board https://ticket.coreboot.org/issues/534#change-1865 * Author: Mahesh Kilumu * Status: New * Priority: Normal * Target version: 4.21 * Start date: 2024-03-21 ---------------------------------------- Hi, With respect to the Alderlake-P RVP platform designed Custom Board. i have been trying to implement the Ethernet(LAN) on my Custom Board. on RVP intel team used GBE PHY but on my custom board we have used the External Realtek RTL8111H controller over PCIe Root port7 for Ethernet. Below are the configuration details: 1) Devicetree.cb: device ref pcie_rp7 on end # Enable PCH PCIE RP 7 using CLK 6 register "pch_pcie_rp[PCH_RP(7)]" = "{ .clk_src = 6, .clk_req = 6, .flags = PCIE_CLK_LAN }" 2) gpio.c: /* 19: PCIE SRCCLKREQ6- same as RVP */ PAD_CFG_NF(GPP_F19, NONE, DEEP, NF1), /* 2: GPD_2_LAN_WAKE_N- same as RVP*/ PAD_CFG_NF(GPD2, NONE, DEEP, NF1), /* 21 : LAN_ISOLATE# -New Implementation */ PAD_CFG_GPO(GPP_A21, 1, DEEP), from the logs observed that, Root port got enabled ->> [SPEW ] PCI: 00:00:1c.6: enabled 1 But observed the few Error & warnings in the log with respect to the above configuration [WARN ] Missing root port clock structure definition [ERROR] PCI: 00:00:1c.6 missing read_resources full log details : https://pastebin.com/zWcsEZvL -- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 21 Jun '24

21 Jun '24

Dear community, Kindly note that we have an upcoming coreboot leadership meeting scheduled for Wednesday, June 26,2024.[1] We encourage you to take a moment to review the items on the current agenda and share your thoughts or suggest additional matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[coreboot - Bug #276] SPI flash console output causes `SMM Handler caused a stack overflow`
by Arthur Heymans 21 Jun '24

21 Jun '24

Issue #276 has been updated by Arthur Heymans. config SMM_MODULE_STACK_SIZE hex default 0x800 if ARCH_RAMSTAGE_X86_64 default 0x400 So just bumping this to always use 0x800 might be a solution ---------------------------------------- Bug #276: SPI flash console output causes `SMM Handler caused a stack overflow` https://ticket.coreboot.org/issues/276#change-1864 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2020-07-19 ---------------------------------------- On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: ``` FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/dsdt.aml' CBFS: Found @ offset 39300 size 3138 FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/slic' CBFS: 'fallback/slic' not found. ACPI: Writing ACPI tables at bfb51000. ACPI: * FACS ACPI: * DSDT FMAP: area CONSOLE found @ 0 (131072 bytes) coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... canary 0x0 != 0xbfeffc00 SMM Handler caused a stack overflow ``` -- 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 #276] SPI flash console output causes `SMM Handler caused a stack overflow`
by Filip Lewiński 21 Jun '24

21 Jun '24

Issue #276 has been updated by Filip Lewiński. Paul Menzel wrote: > On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: > > ``` > FMAP: area COREBOOT found @ 60200 (1703424 bytes) > CBFS: Locating 'fallback/dsdt.aml' > CBFS: Found @ offset 39300 size 3138 > FMAP: area COREBOOT found @ 60200 (1703424 bytes) > CBFS: Locating 'fallback/slic' > CBFS: 'fallback/slic' not found. > ACPI: Writing ACPI tables at bfb51000. > ACPI: * FACS > ACPI: * DSDT > FMAP: area CONSOLE found @ 0 (131072 bytes) > > > coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... > canary 0x0 != 0xbfeffc00 > SMM Handler caused a stack overflow > ``` I've experienced the same with coreboot+EDK2(MrChromeBox) on a Thinkpad T400. If you still have trouble booting the platform, I've somehow managed to bypass it by rebuilding with 64bit mode enabled. ---------------------------------------- Bug #276: SPI flash console output causes `SMM Handler caused a stack overflow` https://ticket.coreboot.org/issues/276#change-1863 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2020-07-19 ---------------------------------------- On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: ``` FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/dsdt.aml' CBFS: Found @ offset 39300 size 3138 FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/slic' CBFS: 'fallback/slic' not found. ACPI: Writing ACPI tables at bfb51000. ACPI: * FACS ACPI: * DSDT FMAP: area CONSOLE found @ 0 (131072 bytes) coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... canary 0x0 != 0xbfeffc00 SMM Handler caused a stack overflow ``` -- 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

VBT versions compatibility with different FSP/GOP versions
by Paul Menzel 18 Jun '24

18 Jun '24

Dear coreboot folks, I noticed commit 5d1494adda44 (mb/system76/tgl: Update VBTs to version 250) [1]: > mb/system76/tgl: Update VBTs to version 250 > > Commit 4c7e97b26a34 ("Update fsp submodule to upstream master branch") > included an update to the VBT from 240 to 250, breaking parsing of > existing VBTs. > > After that commit, the VBT was parsed as (from gaze16-3060-b): > > [DEBUG] PCI: 00:02.0 init > [INFO ] GMA: Found VBT in CBFS > [INFO ] GMA: Found valid VBT in CBFS > [INFO ] framebuffer_info: bytes_per_line: 4096, bits_per_pixel: 32 > [INFO ] x_res x y_res: 1024 x 768, size: 3145728 at 0xd0000000 > [DEBUG] PCI: 00:02.0 init finished in 6 msecs > > When the expected output is: > > [DEBUG] PCI: 00:00:02.0 init > [INFO ] GMA: Found VBT in CBFS > [INFO ] GMA: Found valid VBT in CBFS > [INFO ] framebuffer_info: bytes_per_line: 7680, bits_per_pixel: 32 > [INFO ] x_res x y_res: 1920 x 1080, size: 8294400 at 0xd0000000 > [DEBUG] PCI: 00:00:02.0 init finished in 6 msecs > > Generate blobs for the new version using Intel Display Configuration > Tool (DisCon) v3.3, based on the existing 237 and 240 VBTs. > > (For our edk2 payload, the UEFI GOP driver was updated to 17.0.1077.) Updating the submodule pointer of 3rdparty/fsp brings in commit 849ce8261bb0 (Tiger Lake FSP A.0.7E.70) with no commit message body. The diff contains: TigerLakeFspBinPkg/Client/SampleCode/Vbt/Vbt.json @@ -23891,7 +24584,7 @@ }, { "WidgetType": "Label", - "WidgetName": "VBT Version: 240", + "WidgetName": "VBT Version: 250",^M "Visibility": "", "Data": [], "HelpText": "", Vladimir (φ-coder) also published the tool intelvbtupgrader [2] to address this problem. I would have assumed that FSP versions would be backwards compatible. I attache the output of `intel_vbt_decode` of both VBT files. Does somebody have more insight? Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/82246 [2]: https://review.coreboot.org/c/coreboot/+/82722

1 0

MrChromebox-2405 Release Announcement
by Matt DeVillier 17 Jun '24

17 Jun '24

As coreboot changed its version numbering to a YYMM scheme earlier this year, MrChromebox releases will now do the same. This new release is based on the coreboot 24.05 tag (May 2024) and now supports well over 300 different devices. It includes the following notable changes: - Rebased on coreboot tag 24.05 - Added support for several new Intel Jasperlake boards (beadrix, boxy, dexi, peezer, taranza) - Added latest Google-built EC-RW updates for all Jasperlake boards - Updated the EC-RW firmware for Fizz boards (Intel 7th/8th-gen Chromeboxes) - Updated the EC-RW firmware for Zork boards (AMD Picasso) - Updated the signed PSP verstage binaries for Zork/Guybrush boards (AMD Picasso, Cezanne) - Updated EC-RW software update code for improved compatibility - Fixed SMBUS subsystem ID on several Sandy/Ivybridge Chromebooks - Increased the UMA VRAM to 128MB on Zork boards (AMD Picasso boards) - Filtered out some spurious error messages in the coreboot console log All source code (and blobs) for coreboot, edk2, and Chrome-EC can be found on my github repos: https://github.com/MrChromebox/coreboot/commits/MrChromebox-2405 https://github.com/MrChromebox/edk2/commits/uefipayload_2402 https://github.com/MrChromebox/chrome-ec/branches/all https://github.com/MrChromebox/blobs/ For device compatibility and installation, see https://mrchromebox.tech cheers, Matt

1 0

2024-06-12 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 13 Jun '24

13 Jun '24

# 2024-06-12 - coreboot Leadership Meeting ## Attendees Werner Zeh, Matt DeVillier, David Hendricks, Mina Asante, Jonathan Hall, Martin Roth, Felix Singer, Felix Held, Nico Huber, Jay Talbott, Rhys Perry, Karthik Ramasubramanian, Shelley Chen, Nicholas Chin, Ron Minnich, Mike Banon, Julius Werner, Marshall Dawson. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Felix S/Martin] We’ve got a OSFF booth accepted for [FOSSY conference](https://sfconservancy.org/fossy) * 1st - 4th August * Looking for volunteers to help with the booth. * Please reach out to FelixS or Martin if you’re interested. We might be able to help out some with travel or hotel costs. ### [Martin] Infrastructure * We need additional people to help with coreboot infra. * Using NixOS for the base OS * Docker images for gerrit, jenkins, other services. * Reach out to coreboot leadership if interested. * Felix will be the infra lead, but if we can’t find people in the community, we may need to hire someone (some company) to help with this. * Obviously this will cost the project cash * [MattD] We need a backstop, even if we have volunteers, so hiring a company would probably be good anyway. * If any or our contract companies have recommendations, please suggest good companies. ### [Elyes] Add lint rule to avoid duplicated includes. * I’ve added some lint rules to warn when a header is duplicated through another header which is supposed to provide it. (see [https://review.coreboot.org/c/coreboot/+/81907]) The rules I’ve used are those in: ``Documentation/contributing/coding_style.md`` As per Nico’s comments, we need some rules (if this is something we want to do.) * Headers can still be included in other header files. * [Martin]: This is (or should be) just enforcing what’s already documented in the coding style document. If this is a bad idea, let’s remove it from the coding style and not have a conflict between what we’re willing to enforce and the coding style guide. * [Nico]: This could make updating headers more difficult. * [Ron]: This seems like a slippery slope - do we want to alphabetize the header list? Christmas tree header list. * Those aren’t how we do things here. No required alphabetization or other styles for headers. * [David]: IWYU may make things fragile. Good in theory, if it's easy and reliable to use/enforce then we should do it. * [Julius]: The coding style wastes reviewers time. Do we really need to worry about this? * [Martin]: This patch would fix that. * [Nico]: Do we want to just prohibit bulk cleanups? * [Martin]: Does that mean we should get rid of the coding style? If we’re not going to enforce it, why have it? * [Nico]: it’s good for new users. * [FelixS]: could IWYU be used instead of self-written scripts to supply suggestions? * [David]: Maybe we should roll this out slowly before enforcing it. Hopefully this won’t introduce a bunch of Diffs. * The work is already done, so let’s prevent new style violations from going in. * [Martin]: Can we agree that we can submit this and if it causes issues we can roll it back? * [David]: We shouldn’t block it unless we can articulate exactly why it’s a problem. Let’s think about it for a week and if there aren’t any explicit issues, then let’s merge it. ### [Yidi Lin] [Do we consider GPIO ball names definitions in <soc/gpio.h> as part of <gpio.h>](https://review.coreboot.org/c/coreboot/+/82813/1/src/mainboard/google/kukui/gpio.h) ? * This is related to the above header issue. * Listed in the style guide as an example * [Nico]: These two gpio headers aren’t really the same thing. One is hardware, the other is the general function headers. * [Matt]: Does the main GPIO.h automatically include soc/gpio.h? * Felix: Yes, and includes the IWYU annotation that it should be supplied. * [Matt]: As long as we’re being consistent across the codebase, it should be fine. It looks like we’re normally including soc/gpio.h in mainboards. There are currently 364 instances of that - so let’s not change it to comply with the style guide. Let’s update the style guide and update the patch. * [Julius]: Let’s just leave things as they are and not do bulk updates. * [Jonathan]: This seems like a misinterpretation of the style guide - it’s saying that you don’t need to include both. It doesn’t seem to say that you should use gpio.h instead. Let’s edit the style guide to clarify this. * **Decision**: Let’s just edit the style guide for clarity and not force inclusion. That means that we’d drop these patches (unless the board owner prefers it.) ### [Felix H] Usage of LLM outputs making the commit messages bad * I’ve seen commit messages (patchset 2 of 82871, 82872) that look very much like output from some LLM that say little in much text and I’d very much prefer that we keep commit messages concise, so I’d like to discuss if we want to allow usage of LLM output and if so how we should make sure to mainly get possible advantages of that but keep the disadvantages to a minimum * [Martin] Yes, I think we want to allow the output from LLMs in patch descriptions, in fact I was just talking about creating some automation to generate a description of the patch that could be (optionally) used to update the commit message. People who are less fluent in English could really benefit from this. * [Martin]: Let’s just say that commit messages should be concise and related to the patch. ### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU… Look at the document for reasoning. Please review it and make comments. * [Martin]: I kind of hate the idea of loading firmware from the drive for stages before the payload - this feels like a slippery slope and that next we’re going to need network drivers in coreboot to support loading the firmware over the network. Payload can do what it wants. * [David]: This sort of thing is pretty normal in the non-x86 world. * [Werner]: The mass storage device is really owned by the OS. If the firmware is on the drive, we could break the boot when the drive is formatted or replaced. * [Karthik]: only boot critical components would be moved to the disk. * [Martin/Felix]: This seems like a large security hole - your system can be owned from the boot firmware instead of just the OS. * [Julius]: This is just extending cbfs to the disk and not a part of an OS file system. This is mainly intended for CSME update. This would be only Ramstage or later and would be optional. * [Werner]: Requires adding mass storage devices. Allows coreboot to read the entire disk. How does that affect security? * [David]: Let’s assume that Google didn't screw up their implementation, and focus on how this would fit into upstream or if it should be blocked. It seems like it could be an advantage for cost savings (as Julius points out) by making it so laptop vendors don't need a huge flash chip for things like CSME binaries. * [Martin]: This needs further discussion, so please review the document and make comments there. In general I feel like if something is needed by some coreboot users, we should try to be accepting of their needs (assuming that it’s not adding additional binary blobs. # Next Leadership Meeting * June 26,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes *[2024-06-12](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?p1).

1 0

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

12 Jun '24

Issue #121 has been updated by Patrick Rudolph. > I tried booting with kernel command line parameter idle=nomwait. That should make the OS use the `hlt` instruction instead of `mwait`, which is similar to package C1-state. When using `powertop` or similar tools it should show how much time it spends in specific C-states. I would expect it to draw a bit more power, but probably just ~1Watt. > not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷 I would also expect it to not freeze any more, since C1-states where reported to be working fine. Quote: > As an update to the above, intel_idle.max_cstate=3 was not stable but intel_idle.max_cstate=2 was and I haven't had any crashes in about a month. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1860 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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 12 Jun '24

12 Jun '24

Issue #121 has been updated by Anastasios Koutian. Alex Gravitos wrote in #note-97: > Anastasios Koutian wrote in #note-96: > > I tried booting with kernel command line parameter idle=nomwait. > > There were no freezes for 1 week, 5 days and 16 hours, which was not possible previously. > > After this, I powered down and removed the parameter to see what happens. The system froze after 15 hours and 7 minutes. > > Intel PCM is showing no negative impact on idle power consumption with idle=nomwait. > > I recommend to people following this bug to try this out and confirm if it works for them. > > not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷 That's interesting. I have not seen freezes since adding this option, but it's possible that it's just a coincidence, since this bug is quite random. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1859 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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 Alex Gravitos 12 Jun '24

12 Jun '24

Issue #121 has been updated by Alex Gravitos. Anastasios Koutian wrote in #note-96: > I tried booting with kernel command line parameter idle=nomwait. > There were no freezes for 1 week, 5 days and 16 hours, which was not possible previously. > After this, I powered down and removed the parameter to see what happens. The system froze after 15 hours and 7 minutes. > Intel PCM is showing no negative impact on idle power consumption with idle=nomwait. > I recommend to people following this bug to try this out and confirm if it works for them. not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷 ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1858 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- 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

[Invitation - Tomorrow 4PM UTC] Dasharo "User Group #6 & Developers vPub 0xB" event
by Mike Banon 12 Jun '24

12 Jun '24

Dear Friends, I invite you to Dasharo "User Group (DUG) #6 & Developers vPub 0xB" joint event that starts tomorrow at 4 PM UTC ! 1) on DUG we will discuss the Dasharo coreboot firmware distribution and explore the new supported platforms: in particular you will see a special demo of upcoming NovaCustom V54/V56 laptops with modern & powerful Intel 14th Gen Meteor Lake CPUs 2) vPub will feature our prominent guests from Intel and Karlsruhe Institute of Technology with a couple of interesting talks, and a cosy free-for-all chat about anything opensource firmware/hardware-related! ;-) Join links & full schedule are available here - https://vpub.dasharo.com/e/13/dasharo-user-group-6 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 11 Jun '24

11 Jun '24

Dear coreboot community, Please note that our upcoming coreboot leadership meeting is scheduled for Wednesday, June 12, 2024.[1] You are welcome to review and update the current agenda items with any matters you wish to see discussed during the meeting.[2] Below are the items currently on the agenda. ## Current Agenda Items ### [Elyes] Add lint rule to avoid duplicated includes. * I’ve added some lint rules to warn when a header is duplicated through another header which is supposed to provide it. (see https://review.coreboot.org/c/coreboot/+/81907 ). The rules I’ve used are those in: `Documentation/contributing/coding_style.md` As per Nico’s comments, we need some rules… ### [Yidi Lin] Do we consider GPIO ball names definitions in <soc/gpio.h> as part of <gpio.h> ? ## Improving coreboot processes ### [Martin] bi-weekly review meetings * In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour and we’ll see where things progress from there. Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in some other timezone that may switch based on daylight savings?) ### [Martin] Merge SLOsl * Can we define objectives for timeframes to get patches merged to different areas in the codebase? An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

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