coreboot April 2024

coreboot@coreboot.org

26 participants
31 discussions

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

27 Apr '24

Issue #121 has been updated by Patrick Rudolph. I made good progress with https://review.coreboot.org/c/coreboot/+/81597 It allows to configure the VR12-compatible regulator adjusting the CPU core voltage. Especially the PSI state are from interest, since those are using in Package C3 or deeper. My X220 is stable for 9hours while residing in Package C7 without freezes or shutdowns. Since the VR12 configuration is mainboard specific the devicetree settings should not be copy pasted from existing board, but read from vendor firmware MSRs. The values can be obtained from MSR 0x601 and MSR 0x602 for example using the `$ rdmsr` tool. The devicetree values can be obtained using: ``` #!/bin/bash echo "register \"pp0_current_limit\" = \"$(($(rdmsr -d -f 12:0 0x601) / 8))\"" echo "register \"pp1_current_limit\" = \"$(($(rdmsr -d -f 12:0 0x602) / 8))\"" echo "register \"pp0_psi[VR12_PSI1]\" = \"{$(($(rdmsr -d -f 41:39 0x601) + 1)), $(rdmsr -d -f 38:32 0x601)}\"" echo "register \"pp0_psi[VR12_PSI2]\" = \"{$(($(rdmsr -d -f 51:49 0x601) + 1)), $(rdmsr -d -f 48:42 0x601)}\"" echo "register \"pp0_psi[VR12_PSI3]\" = \"{$(($(rdmsr -d -f 61:59 0x601) + 1)), $(rdmsr -d -f 58:52 0x601)}\"" echo "register \"pp1_psi[VR12_PSI1]\" = \"{$(($(rdmsr -d -f 41:39 0x602) + 1)), $(rdmsr -d -f 38:32 0x602)}\"" echo "register \"pp1_psi[VR12_PSI2]\" = \"{$(($(rdmsr -d -f 51:49 0x602) + 1)), $(rdmsr -d -f 48:42 0x602)}\"" echo "register \"pp1_psi[VR12_PSI3]\" = \"{$(($(rdmsr -d -f 61:59 0x602) + 1)), $(rdmsr -d -f 58:52 0x602)}\"" ``` ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1815 * 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 26 Apr '24

26 Apr '24

Dear coreboot community, We are happy to announce that our upcoming coreboot leadership meeting is scheduled for Wednesday, May 1, 2024. [1] Kindly take a moment to review and update the current agenda items with matters you wish to see addressed during the meeting. [2] Thank you for your continued commitment to the coreboot project. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[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

AMD64 & X86S payload handover
by Nico Huber 23 Apr '24

23 Apr '24

Hi coreboot fellows, yesterday some patches[1] surfaced on Gerrit about a handover for 64-bit x86 payloads. Strictly speaking, we don't have to do anything for this right now, as the original, protected-mode handover would work too. How- ever, there is X86S on the horizon. If you don't know about it, here is the short version: X86S was announced by Intel last year, it's supposed to be a simplified version of AMD64, without real nor protected mode, so 64-bit long mode only. So we have: +----------------+-------+------+ | | AMD64 | X86S | +----------------+-------+------+ | real mode | X | | +----------------+-------+------+ | protected mode | X | | +----------------+-------+------+ | long mode | X | X | +----------------+-------+------+ After a night's sleep, I'm convinced we should keep things as simple as possible on the coreboot side, and hence propose the following: 1. AMD64: Keep the current, 32-bit protected mode handover 2. X86S: Hand over in long mode with a) the pointer to cbtables in RDI (like the first parameter in the System V ABI), b) the guarantee that the payload and cbtables are identity mapped in the current page tables. Rationale: * 1. Allows us to keep compatibility where it's possible. X86S breaks compatibility on purpose but we don't have to break compatibility in the AMD64 case. There is one exception: A future X86S payload could potentially run on AMD64 and vice versa. Though, compatibility could be ensured on the payload end (e.g. having two entry points like the Linux kernel has(*)). * Keeping the current handover where possible would allow to use a new 64-bit payload with a coreboot build from one of the older branches, for instance, without having to modify them all. Existing coreboot binaries for AMD64 systems would stay compatible as well. * 1. requires a 64-bit payload to switch (back) to long mode by itself. This should be straight-forward, though, and can be done with rather few instructions. The necessary page-table setup could be kept small, as long mode supports 1GiB pages. Having to set up its own page ta- tables also avoids problems with assumptions about the prior setup. * Generally, we can't control what downstream does. However, by adding a long-mode handover as late as possible (i.e. the first X86S port), we would encourage everybody to stay compatible. Once the long-mode handover is implemented upstream, it will be easier to create a pay- load that works with some x86 coreboot builds, but not all. Making it X86S only, will limit the room for incompatibility. * 2. a) is probably what people would expect. * 2. b) allows for more flexibility in coreboot, without having to set up much (ideally nothing) special for the payload. If we'd make more guarantees, e.g. a whole 4GiB space identity mapped, it would become more likely that we have to change the mapping for the handover. For instance, if we'd ever decide to add a continuous mapping for a >16M flash chip. That would likely still be compatible with 2. b), though might not be with more elaborate guarantees. So, please share your thoughts :) Best regards, Nico [1] https://review.coreboot.org/c/coreboot/+/81960 https://review.coreboot.org/c/coreboot/+/81964 https://review.coreboot.org/c/coreboot/+/81968 (*) All payloads (builds) until now will be incompatible to X86S. But if we'd encourage to give all 64-bit payloads from now on two en- try points (32- and 64-bit), we could increase the number of pay- loads that are both compatible to X86S and all prior AMD64 core- coreboots.

2 1

Re: Porting Coreboot to a Mini PC
by Matt DeVillier 20 Apr '24

20 Apr '24

you are of course free to do exactly that, or my MrChromebox firmware if you prefer coreboot + UEFI. But ultimately, the only reason you have that option is because others felt it was worth the additional price to support the company paying for the coreboot development., so you might consider donating to the SFF, coreboot.org, or whosever work you decide to use "for free" On Sat, Apr 20, 2024 at 12:23 PM Mason Corkern <corkernm(a)berea.edu> wrote: > yeah no thanks. I'll just buy the $300 exact hardware and then flash the > firmware from Purism's website for free and save a bunch of money 😉 > > Thanks, > Mason Corkern > ------------------------------ > *From:* Matt DeVillier <matt.devillier(a)gmail.com> > *Sent:* Wednesday, April 3, 2024 8:36 PM > *To:* Mason Corkern <corkernm(a)berea.edu> > *Cc:* coreboot <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] Porting Coreboot to a Mini PC > > *[EXTERNAL SENDER]* > that's still going to cost more than $400. Add a zero and I'll think about > it ;-) > > On Wed, Apr 3, 2024, 7:30 PM Mason Corkern <corkernm(a)berea.edu> wrote: > > Yeah, I only want the port, not ongoing support. > > Thanks, > Mason Corkern > ------------------------------ > *From:* Matt DeVillier <matt.devillier(a)gmail.com> > *Sent:* Wednesday, April 3, 2024 8:25 PM > *To:* Mason Corkern <corkernm(a)berea.edu> > *Cc:* coreboot(a)coreboot.org <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] Porting Coreboot to a Mini PC > > *[EXTERNAL SENDER]* > The minisforum MiniPC you have linked is a completely different device > from the one offered by Purism/Nitrokey; the only thing similar is the form > factor. > > coreboot support has to be added on a per-mainboard basis, so the > Minisforum device you linked would need to be ported by someone who > understands coreboot and x86 firmware (or who has a lot of free time to > learn). And the mainboard on the device would need to be unencumbered by > things like Intel Bootguard (which fortunately IME most devices like that > are, but it's not a guarantee). > > If you want not just a coreboot port, but ongoing support, it's going to > cost you a heck of a lot more than the $400 you think Purism/Nitrokey are > "overcharging" by. And I say that as the developer who did the initial port > on the Purism Librem Mini/Mini v2 boards. > > -Matt > (speaking on behalf of myself, not any present or past employer) > > On Wed, Apr 3, 2024 at 5:43 PM Mason Corkern <corkernm(a)berea.edu> wrote: > > Greetings, > > I recently purchased a Mini PC from mini forums, a company based in Hong > Kong [1]. I want to replace their custom BIOS with Coreboot since it's > FOSS. Prisim and Nitro has been able to install Coreboot, but they said > they did a custom port for the motherboard/cpu and they overcharge by $400 > and justify it due to the R&D spent on porting Coreboot to the minipc [2]. > Has anyone tried porting Coreboot for similar boars and/or made a tutorial? > I couldn't find it when I googled around and looked in docs. > > > > 1. Minisforum NAB6/NPB7 Intel i7-12650H/Intel i7-13700H > <https://store.minisforum.com/products/minisforum-nab6?variant=44164535288053> > 2. Purism– Librem Mini <https://puri.sm/products/librem-mini/> and NitroPC > 1 | shop.nitrokey.com <https://shop.nitrokey.com/shop/nitropc-1-132>. > 3. > > Thanks, > Mason Corkern > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >

1 0

[coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
by Christian Walter 17 Apr '24

17 Apr '24

Issue #499 has been updated by Christian Walter. Oberon 4071 wrote: > coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce > coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 > Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 > > coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. > > I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. > > Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. > > I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). We fixed the issue in our edk2 here: https://github.com/9elements/edk2/commit/d965778103bfe2badd815c6fe35d278658… ---------------------------------------- Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1807 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Related links: https://review.coreboot.org/c/coreboot/+/76198 https://review.coreboot.org/c/coreboot/+/76199 * Affected hardware: lenovo/t440p ---------------------------------------- coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files-------------------------------- .config (20.7 KB) console.log (128 KB) cbmem.txt (151 KB) cbmem_seabios_with_resource_allocation_top_down.txt (41.1 KB) dmesg_change_76199.txt (56.7 KB) cbmem_change_76199.txt (120 KB) cbmem.txt (116 KB) cbmem_top_down_n.txt (163 KB) dmesg_top_down_n.txt (58.2 KB) dmesg.txt (58.3 KB) cbmem.txt (166 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-04-17 coreboot Leadership Meeting Canceled
by mina＠coreboot.org 15 Apr '24

15 Apr '24

Dear community, Kindly be informed that the coreboot leadership meeting scheduled for Wednesday, April 17, 2024, has been canceled. We apologize for any inconvenience this may cause and appreciate your understanding. Best Regards, Mina Asante

1 0

Found how to work some LEDs on P8Z77-M. Looking for implementation guidance.
by Keith Hui 15 Apr '24

15 Apr '24

What an eye opener. Yesterday I stumbled upon some boardviews for my board, and the pro variant. That could also let me sort out the pro's serial port without one actually on hand, but that's for another time. The power button have never blinked while in S3 like it's supposed to. I found that it is connected to GPIO27 on the PCH. I could adjust the PCH GPIO config to make it blink. What is the best approach if I want it to blink before entering S3, and stop it blinking after coming out of? Thanks Keith

2 1

Windows XP 0xA5 BSoD at IASL_VERSION Address
by Grayson Guarino 14 Apr '24

14 Apr '24

Greetings, I am not the most familiar with how Coreboot, SeaBIOS, BIOSes in general, and ACPI work, so forgive me if I am unclear. I am trying to install Windows XP SP3 on a Thinkpad T420 which has been upgraded with an Intel i7-3632QM. I am running Coreboot (commits c4e68f6080/09eb8d0c9b) and SeaBIOS (v1.16.3/commit d239552). I have listed two versions for both Coreboot and SeaBIOS because the former is a sensible recent build of both, while the latter is an attempt to build Coreboot with ACPI 1.0 support (and the latter SeaBIOS commit was chosen as it was made around the same time as the Coreboot commit). It seems like ACPI 1.0 backwards compatibility was dropped at commit be3979c, which could be incorrect. What I am noticing is that regardless of whether I use the newer or older Coreboot build, Windows XP's installer shows a blue screen of death with the following STOP code: [Newer build] STOP: 0x000000A5 (0x00000011, 0x00000008, 0xF794B280, 0x20230628) [Older build] STOP: 0x000000A5 (0x00000011, 0x00000008, 0xF794B280, 0x20200110) Parameter 4 for each of these STOP codes matches the date of the IASL version in both. Do you have any suggestions for how I can further attempt to debug this? I'm struggling to find the release where ACPI v1.0 compatibility was officially dropped, so if it is not 09eb8d0c9b, let me know and I will attempt to rebuild and flash again. Thank you, Grayson

4 5

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

12 Apr '24

Dear community, We are happy to announce that the next coreboot leadership meeting is scheduled for Wednesday, April 17, 2024. [1] Kindly take a moment to update the current agenda items with matters you wish to see addressed during the meeting. [2] Thank you for your continued commitment to the coreboot project. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2024