coreboot

coreboot@coreboot.org

3 participants
39681 discussions

ACPI_S3 resume mechanism in coreboot
by Yoshinoya 07 May '24

07 May '24

Hi, Kyosti: I ask for help. Is there any document introducing acpi s3 resume mechanism in coreboot ? I am familiar with uefi bios, and there is boot script concept in uefi code. Buf I could not find any boot script code implemented in coreboot. For some early coreboot code(such as 2022 ver), there is an amd porting boot script infrastructure code in coreboot. Buf now, I could not find them in 2024 ver code package. Thanks

1 0

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

03 May '24

Issue #121 has been updated by Anastasios Koutian. The freezes have been quite random for me, sometimes happening within minutes of booting, sometimes hours, and sometimes days. It is possible that there are two separate issues that have the same symptom. You mentioned that using mrc.bin seems to also fix the freezes. Could you provide instructions on how to do that so I can confirm? ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1824 * 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 Patrick Rudolph 03 May '24

03 May '24

Issue #121 has been updated by Patrick Rudolph. My X220 is stable for more than 48h, which wasn't possible before as it would crash within a couple of hours. Since the issue doesn't appear any more I must assume it's fixed on my device. There might be other settings causing a similar problem, however they won't show on my test system (until now). ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1823 * 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

2024-05-01 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 02 May '24

02 May '24

# 2024-05-01 - coreboot Leadership Meeting Minutes ## Attendees: Martin Roth, Mina Asante, Arnaldo Pirrone, Jay Talbott, Matt DeVillier, David Hendricks, Jonathan Hall, Nicholas Chin, Nick Van Der Harst, Felix Singer, Julius Werner, Leandro Friedrich, Kunstardilla, Echo,Jon Murphy,Dragos Bogdan, Jegadeesh Vontlin, Werner Zeh, Nico Huber, Gogo Gogo, Jack, Christian Walter. ## 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 * Call for participation is open until May 31st, 2024 * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-03-20 * Martin: Martin: 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. * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) ## Minutes ### [Werner] native 64 bit support for payloads * Subrata is trying to get native 64 bit support for payloads merged but faces some (valid) discussions on the CL [CB:81960](https://review.coreboot.org/c/coreboot/+/81960). Can we help him to get it in? Seems to have some time constraints on Subrata’s side. * Martin: Push initial patch, have a document discussing a way forward? * Proof-of-concept was a compile-time decision whether to support 64-bit payload. * Schedule a call to resolve the issue. It's too slow to go back-and-forth on Gerrit / ML. Martin will set up the meeting when Werner is ready * Do we plan to support both 32 and 64-bit in the same build? * Please still discuss on the CL. ### [Felix,Matt, Martin] coreboot 24.05 release in two weeks * Currently scheduled for May 13,2024. * coreboot_release_2405 - Add this tag to patches on gerrit if you want them to be included. ### [Felix] How can we make todos more visible? * People from my local meetup group feel it’s quite hard to get into the project. Mostly because they don’t know what they could contribute other than a mainboard. Though, there are always some refactorings or cleanups which could be done. Any ideas on how to make such todos more visible? * Roadmap? * Tag bugs as a "get started" item * Get volunteers from experienced users to start a mentorship program. * Martin - Happy to help mentor on AMD ### [Martin] External module expectations * coreboot probably needs to make a list of expectations of external silicon initialization modules like FSP and openSIL. Maybe jointly with other open firmware projects like U-Boot * There seems to be confusion about what should be owned by which piece. * My opinion is that the host firmware should be responsible for all allocation at runtime. If there are specified hardcoded needs from the silicon init module, it can be stated and incorporated. This includes MMIO/IO/Memory/GPIO Config/CMOS, etc. * Resets should not be done independently by the module. At the very least, the module should return to the host firmware saying that it intends to reset the platform. * Because of the restriction on callbacks in non-open-source firmware, Debug output there needs to be handled strictly by the module. On open source firmware, the debug output should be done by the host firmware. * Look at adding calls that save register lists and compare them. THis would allow us to see what’s being changed in between various calls. This functionality would need to be enabled/disabled by Kconfig because we don’t want it in release firmware. * This could be a good starter task. * Have the save register call create a region in cbmem and dump all the listed registers (passed in) into the region. * A compare register call allows the differences to be calculated. ### [Jay] FYI, The current meeting invite lacks a link to these minutes. Had to open an old one to find the link. * Martin: I’ll get that fixed today.[Done] # Next Leadership Meeting * May 15, 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-05-01](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?pl=1).

1 0

Tagging coreboot 24.05 in less than 2 weeks!
by mina＠coreboot.org 02 May '24

02 May '24

Dear Community, We are happy to announce that the next coreboot release, version 24.05, is scheduled for May 13th. Please test any mainboards, give feedback, and, if possible, submit a patch for review in case you find any issue. We appreciate any help. Also, let us know if there are any patches that should be included in the release. You can do that by responding to this email or by adding the following hashtag 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. coreboot_release_2405 [1] We are using another hashtag to track patches which are important or useful in some way, maybe even ready to be submitted, but might break something and thus the risk is too high right before the release. So we prefer to submit them after the release which gives enough time for testing until the next release. Examples are version updates to the toolchain or updates to the FSP submodule pointer. The hashtag is as follows: coreboot_post_release_2405 [2] Please don't hesitate and reach out to us if you have any questions or feedback. Thank you for your support and dedication to the coreboot project. [1](https://review.coreboot.org/q/hashtag:coreboot_release_2405) [2](https://review.coreboot.org/q/hashtag:coreboot_post_release_2405)

1 0

Asus P5Q hints and tips
by Eduardo Batalha 01 May '24

01 May '24

Hi all, Here are a few hints and tips for the Asus P5Q 1) keyboard power on In order to activate the "any key" keyboard power on function, start by installing the ioport package, use the package manager from your linux distribution or install from here: https://people.redhat.com/rjones/ioport/ Then, as root, do: outb 0x2E 0x87; outb 0x2e 0x87; outb 0x2e 0x07; outb 0x2f 0x0a; outb 0x2e 0xe0; outb 0x2f 0x41 2) Blinking power light whilst sleeping If you want your computer to blink the power light when you put it to sleep, create a file named smihandler.c inside the src/mainboard/asus/p5qc/ folder with the following contents: #include <arch/io.h> #include <cpu/x86/smm.h> void mainboard_smi_sleep(u8 slp_typ) { outb(inb(0x59b) | 0x08,0x59b); } 3) Floppy configuration Byte 0x10 in the RTC NVRAM space is used by various operating systems (including linux) to determine what type of floppy drive you have connected to the motherboard If you replace cmos.default and cmos.layout with the attached files it will be possible for you select the floppy type with either the nvramui secondary payload or use the nvramtool . Hope this is useful to anybody. Regards, Ed

1 0

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

01 May '24

Issue #121 has been updated by Anastasios Koutian. Anastasios Koutian wrote in #note-90: > Patrick Rudolph wrote in #note-89: > > I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2 and PSI3 values to 0 in PowerManagment2.efi. > > The X230 vendor BIOS does not hard-code those values in PowerManagment2.efi. > > Thus this is likely a bug in the voltage regulator used on Sandy-Bridge platforms. > > > > I've created https://review.coreboot.org/c/coreboot/+/82070 based on this, please test. > > Hi Patrick, I have cherry-picked your commit on top of coreboot main and I am testing on my T420. I will inform you of the results. System froze again after a couple of days. Unfortunately, this does not seem to have fixed the bug, however being able to set VR config in device tree is a very useful feature. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1822 * 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 #533] T440p audio mute button and fan control not working
by frantic from xboot 01 May '24

01 May '24

Issue #533 has been updated by frantic from xboot. Evgeny Zinoviev wrote in #note-13: > For everyone who encounters this issue - I just found another workaround: > > just pass `force_load=1` to thinkpad_acpi module. PS. That only works once you've fixed the SMBIOS tables. ---------------------------------------- Bug #533: T440p audio mute button and fan control not working https://ticket.coreboot.org/issues/533#change-1821 * Author: frantic from xboot * Status: Resolved * Priority: Normal * Target version: master * Start date: 2024-03-07 * Affected versions: master * Affected hardware: Lenovo Thinkpad T440p * Affected OS: All Linux distributions ---------------------------------------- In recent coreboot versions, the audio mute button and fan control has stopped working. Whereas you use the same revision from Libreboot, it all works fine and smoothly. This leads me to suspect that someone changed someone without testing, which is real annoying. The audio mute button technically still functions, but the LED no longer turns on/off. Always just off. Fan control no longer works with Thinkfan. /proc/acpi/ibm/fan doesn't exist any more. I've tried "force loading" thinkpad_acpi, but it doesn't work. -- 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 #535] (New) T420: Power light stays off after reboot
by frantic from xboot 01 May '24

01 May '24

Issue #535 has been reported by frantic from xboot. ---------------------------------------- Bug #535: T420: Power light stays off after reboot https://ticket.coreboot.org/issues/535 * Author: frantic from xboot * Status: New * Priority: Low * Target version: master * Start date: 2024-04-24 * Affected hardware: Lenovo ThinkPad T420 ---------------------------------------- I have recently encountered a bug in coreboot where if you reboot the computer, the keyboard power light will stay turned off after it turns back on. Where if you do a clean boot, the light turns on. I am unsure whether this is a coreboot or payload issue. I am using GRUB as my payload. Just run the `reboot` command in Linux and it should be reproducible. Priority set to `Low` as it doesn't affect usability all too much. -- 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

question about nodefaultlibs gcc option
by Yoshinoya 30 Apr '24

30 Apr '24

Hi, Could Coreboot use gcclib functions directly? I find not declare nodefaultlibs option during compiling coreboot source code. Thanks

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot