coreboot October 2022

coreboot@coreboot.org

16 participants
36 discussions

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski 24 Apr '24

24 Apr '24

Issue #433 has been reported by Michał Żygowski. ---------------------------------------- Feature #433: Unify TPM drivers in coreboot https://ticket.coreboot.org/issues/433 * Author: Michał Żygowski * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-24 ---------------------------------------- Add an option to compile all drivers for TPM 1.2, 2.0 TIS and CRB. The motivation is to not build multiple coreboot ROMs for each possible TPM supported by the platform. The tasks would include: - runtime TPM detection (probing TPM_INTF_CAPABILITY and TPM_INTERFACE_ID) - rename the TPM driver functions, make them static and expose them as a driver structure, e.g. struct tpm_driver { void (*init)(void); int (*open)(void); int (*close)(void); int (*sendrecv)(const uint8_t *sendbuf, size_t send_size, uint8_t *recvbuf, size_t *recv_len); } - based on the detected TPM, hook the tpm_driver functions to provide the global TPM API: tis_open, tis_close, tis_init, tis_sendrecv. Some additional API to get vendor/device name could also be considered. -- 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 6

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon 21 Feb '24

21 Feb '24

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

[coreboot - Bug #392] (New) Coreboot 4.16 & 4.17 - SeaBios Windows 10 BSOD "ACPI Error"
by Pawel Radomychelski 15 Jan '23

15 Jan '23

Issue #392 has been reported by Pawel Radomychelski. ---------------------------------------- Bug #392: Coreboot 4.16 & 4.17 - SeaBios Windows 10 BSOD "ACPI Error" https://ticket.coreboot.org/issues/392 * Author: Pawel Radomychelski * Status: New * Priority: High * Category: board support * Target version: 4.17 * Start date: 2022-06-18 * Affected versions: 4.16, 4.17, master * Affected hardware: Lenovo ThinkPad X230 Tablet * Affected OS: Windows 10 ---------------------------------------- Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with "ACPI Error" very early. Don't know which commit exactly brakes ACPI, but i can say, that in my CoreBoot 4.15 Image from 11/09/2021 Windows 10 is booting just fine from SeaBIOS. Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried yesterday with CoreBoot 4.17 and its still broken. I think, since CB4.16 there is something broken in ACPI. As i read, the problem is, that ACPI reserves some memory area, which in Windows is reserved for the system. This [[https://ticket.coreboot.org/issues/327]] seems to be a similar problem, but the guy is using TianoCore instead of SeaBIOS. Changing the line OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) to OperationRegion (OPRG, SystemMemory, ASLS, 0x1000) doesnt fix it for SeaBios, but fix it for TianoCore. ---Files-------------------------------- dmesg_cb415.txt (78.9 KB) dmesg_cb417.txt (79.9 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

7 31

[coreboot - Bug #386] (New) ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop
by gzz5f gzz5f 15 Jan '23

15 Jan '23

Issue #386 has been reported by gzz5f gzz5f. ---------------------------------------- Bug #386: ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop https://ticket.coreboot.org/issues/386 * Author: gzz5f gzz5f * Status: New * Priority: High * Category: board support * Target version: master * Start date: 2022-06-05 * Affected versions: master * Needs backport to: none * Affected hardware: ASUS P8Z77-V LX2 * Affected OS: all ---------------------------------------- I build coreboot today for the ASUS P8Z77-V LX2 and used the latest coreboot master code. The 2 8GiB DIMMs are working fine at first boot. You can start computer, install from a live media the OS and so on. But at the second boot it failes boot forever and its bootooping. It does not make a change if i boot for a second until SeaBIOS output and then turn off the computer or use the computer for longer time. The second boot is always broken. Workaround 1: Remove one of the two 8GiB DIMMs. Then the computer also starts fine after a reboot. Workaround 2: Install two 4GiB DIMMs instead of two 8GiB DIMMs. Then the computer also starts fine after reboot. Workaround 3: At every boot boot for a second with one DIMM. Turn off the computer, insert the second DIMM and start it again. kmalkki told me to rebuid the image with DEBUG_RAM_SETUP=y I then build a second image, with DEBUG_RAM_SETUP=y. The logfile contains the first successfull boot (created with Workaround 3), the poweroff and the poweron with the bootloop. I have let it bootloop few times before turned off the PSU. ---Files-------------------------------- coreboot_logfie.txt (197 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 #432] (New) t440p reboots on suspend
by Josh R 15 Jan '23

15 Jan '23

Issue #432 has been reported by Josh R. ---------------------------------------- Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432 * Author: Josh R * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo t440p * Affected OS: Ubuntu 22.04 (Pop OS) ---------------------------------------- Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files-------------------------------- cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

3 6

[coreboot - Support #387] (New) Support Framework Laptop
by Jun Aruga 15 Jan '23

15 Jan '23

Issue #387 has been reported by Jun Aruga. ---------------------------------------- Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387 * Author: Jun Aruga * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop ---------------------------------------- Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the coreboot community. Our plan in the near term is to help them create a shim loader that can be signed to run on any Framework Laptop, which then enables anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 -- 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

7 15

[coreboot - Cleanup #421] (New) Change API of functions taking hash as an argument
by Krystian Hebel 13 Jan '23

13 Jan '23

Issue #421 has been reported by Krystian Hebel. ---------------------------------------- Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 ---------------------------------------- All existing functions that take a digest as an input assume that only one hashing algorithm is used at a time. Crypto agile format entry can (and should) log every used PCR bank in one entry for a given measurement. To make it work, some of the arguments must be changed, e.g.: - pass number of algorithms used; - instead of algorithm ID, pass a pointer to array of such IDs, with size equal to above; - instead of hash, pass a pointer to array of hashes, with size and order as above. -- 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 15

Cisco Meraki use coreboot in some MX products and will not provide the source code
by Hal Martin 22 Dec '22

22 Dec '22

Hello, Several Cisco Meraki products (MX84, MX250) are using the coreboot bootloader. Meraki are also distributing coreboot builds for these products via their update mechanism. In October 2021, I requested the corresponding coreboot source code for the MX84 from open-source(a)meraki.com. Another individual requested the coreboot source code for the MX250 around the same time. We own the devices in quesiton. To date, Meraki have not provided the source code or provided an explanation as to the delay in providing the source code. The last reply I received was in January, and they have not replied to any of my follow up requests. As coreboot is GPL licensed software, I wanted to inform the coreboot community that I believe Cisco Meraki are not acting in good faith and are, in my opinion, violating the GPL by not providing the coreboot source code upon request. Kind regards, Hal Martin

4 4

[coreboot - Feature #435] (New) Add the new memtest86+ v6.0 as secondary coreboot payload
by akjuxr3 akjuxr3 07 Nov '22

07 Nov '22

Issue #435 has been reported by akjuxr3 akjuxr3. ---------------------------------------- Feature #435: Add the new memtest86+ v6.0 as secondary coreboot payload https://ticket.coreboot.org/issues/435 * Author: akjuxr3 akjuxr3 * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-25 * Related links: https://github.com/memtest86plus/memtest86plus https://www.memtest.org/ https://www.phoronix.com/news/memtest86-6.0-Released ---------------------------------------- Memtest86+ have been rewritten. The release of the final version 6.0 was on 23.10.2022 . Here the changelog: Rewrite code for UEFI 32 & 64 bits Add support for x64 Long Mode Paging Add support for up to 256 cores Add detection for DDR4 & DDR5 Add support for XMP 3.0 Add detection for AMD Zen 1/2/3/4 Add detection for Intel up to 13th Gen Add better support for AMD pre-ZEN CPUs Add support for older nVidia and AMD chipsets Add support for SDRAM Many enhancements Numerous bug fixes & optimization Since it work now with uefi, it would be great if it could be used with tianocore payload. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

3 2

Please test coreboot using laptops with kernel 6.1-rc# for a possible backlight regression
by Hans de Goede 03 Nov '22

03 Nov '22

Hi All, I have landed a large(ish) refactor of the ACPI/x86 backlight detection code in the kernel for 6.1. It has come to my attention that this may cause backlight control to stop working on laptops where the original BIOS has been replaced with coreboot, see this patch, which is the root cause of the possible regression + its replies: https://lore.kernel.org/platform-driver-x86/20220825143726.269890-3-hdegoed… On ACPI/x86 laptops there may be multiple methods available to control the backlight (native GPU control, ACPI video bus, vendor specific) and even though a method is available it does not always work, basically the only method guaranteed to work is the one preferred by the Windows version with which the laptop shipped. The kernel so far has delegated part of this problem by registering multiple backlight devices under /sys/class/backlight and then letting userspace figure it out. One goal of the refactor is to only register 1 backlight device per panel. On many (somewhat older) laptops "ls /sys/class/backlight" would show 2 backlight devices: "acpi_video0" and "intel_backlight" and the various (per desktop) userspace backlight helpers would prefer the "acpi_video0". The goal of the linked kernel patch is to simply not register "intel_backlight" in this case, just like the kernel was already not registering "acpi_video0" on the models where "intel_backlight" should be used. But this may cause problems / a change in behavior if: 1. You have an unusual / or customized userspace which prefers intel_backlight over acpi_video0 when both are present 2. You always only had intel_backlight and that now no longer gets registered, leaving you completely without backlight support. I would like to try and find and resolve any such problems before 6.1 gets released. As such if you are using a laptop with coreboot please run the following tests: 1. Boot kernel 6.0 or older, and collect the output of: ls /sys/class/backlight 2. Boot kernel 6.1, note for ChromeBooks please used Torvalds latest master and not rc2 since a fix for ChromeBooks has just landed, and collect the output of: ls /sys/class/backlight 3. Check if everything still works as expected with kernel 6.1 Report the results of 1-3 either on the list or in a direct email to me (your choice). Please include the model of your laptop and please report this even if everything still works fine, I need to know how things work on coreboot laptops which have not regressed too, to avoid accidentally regressing those if I need to do fixes for some other coreboot capable models. 4. Run: sudo dmidecode > dmidecode.txt sudo acpidump -o acpidump.txt And then send me a *private* off-list email with the dmidecode.txt and acpidump.txt files attached. Please don't forget to mention the model of your laptop in this email. Sorry for any breakage my backlight refactor may have caused and thank you in advance for taking the time to test this. Regards, Hans

5 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2022