coreboot March 2025

coreboot@coreboot.org

8 participants
25 discussions

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

31 Mar '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 4

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 #581] (New) success new variant "compaq_pro_6300_sff" for hp/snb_ivb_desktops compatible with "compaq_8300_elite_sff" template
by Walter Sonius 29 Mar '25

29 Mar '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 32

[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 24 Mar '25

24 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 24 Mar '25

24 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2025