coreboot

coreboot@coreboot.org

3 participants
39681 discussions

question about CFLAGS custom
by Yoshinoya 30 Apr '24

30 Apr '24

Hi, I am studying coreboot source code. I have a question about how to costom CFLGAS. There is a Makefile.inc in the root of source code. I found some CFLAGS_common definition. Could i change CFLAGS setting in this file? And this changes could take effects in the whole coreboot module compile time? Thanks

1 1

Technical details of VGA text mode in coreboot romstage
by Nicholas Chin 29 Apr '24

29 Apr '24

Hi Jérémy, In the original thread about romstage VGA text mode on the coreboot mailing list [1], some ideas were brought up about using this functionality for early debug messages and porting this to older platforms. I was interested in these possibilities and started exploring an implementation for Ivy Bridge, so I was wondering if you know and are able to share more information about how this works on Alder Lake and if this is even theoretically possible on older platforms. From what I understand, accesses to the legacy VGA range from 0xA0000 to 0xBFFFF are forwarded to integrated graphics, assuming various config registers are set up appropriately. The Programmer's Reference Manuals state that the iGPU uses the preallocated graphics stolen memory range under TOLUD to support VGA graphics: "VGA graphics memory starts from the base of graphics data stolen memory defined in the PCI configuration BDSM register. VGA display uses the first four 64KB pages of VGA graphics memory" [2, pp. 22]. In the case of romstage graphics, there isn't DRAM to back the stolen memory range, so where exactly is this data being stored? My best guesses are the shared last level cache, the internal iGPU caches, or perhaps some other internal buffer. From the initial implementation of romstage graphics [3], there doesn't seem to be any other initialization being done other than setting up the iGPU GTTMMADR BAR for MMIO access, turning on the panel backlight, running libgfxinit, and running VGA init. I had attempted to replicate these initialization steps on Ivy Bridge and found that the earliest point that I could run romstage graphics without the boot process freezing on clearing the VGA framebuffer was just after normal DRAM operation was enabled in raminit, which suggests to me that the accesses were going out to the main memory which was not yet functioning if graphics was enabled beforehand. Does Alder Lake behave differently such that this "just works" out of the box without any additional initialization steps, or is there some additional initialization happening elsewhere to set up some sort of backing store? Cheers, Nicholas [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2DYB… [2] https://cdrdv2-public.intel.com/705833/intel-gfx-prm-osrc-tgl-vol-12-displa… [3] https://review.coreboot.org/q/topic:%22romstage-early-graphics-for-memory-t…

1 0

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

28 Apr '24

Issue #121 has been updated by Patrick Rudolph. Jun Muta wrote in #note-91: > 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've recently started using Libreboot and I'm having this issue on my T430. Do you happen to know what the values are for the T430? I check PowerManagment2.efi in T430 vendor firmware and it does not hard-code PSI2 and PSI3 to 0. It's likely a different problem, not related to the VR12 configuration. It looks like this only applies to Sandy-Bridge series, as reported here it only affects X220, T420, T520, T420s. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1819 * 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

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 28 Apr '24

28 Apr '24

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1544382: Null pointer dereferences (REVERSE_INULL) /src/drivers/i2c/rt5645/rt5645.c: 30 in rt5645_fill_ssdt() ________________________________________________________________________________________________________ *** CID 1544382: Null pointer dereferences (REVERSE_INULL) /src/drivers/i2c/rt5645/rt5645.c: 30 in rt5645_fill_ssdt() 24 .speed = config->bus_speed ? : I2C_SPEED_FAST, 25 .resource = scope, 26 }; 27 struct acpi_dp *dp; 28 int curr_index = 0; 29 >>> CID 1544382: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "config" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 30 if (!config) 31 return; 32 33 const char *name = acpi_device_name(dev); 34 if (!scope || !name) 35 return; ** CID 1544381: Integer handling issues (DIVIDE_BY_ZERO) /src/mainboard/dell/optiplex_9020/mainboard.c: 310 in get_pkg_power() ________________________________________________________________________________________________________ *** CID 1544381: Integer handling issues (DIVIDE_BY_ZERO) /src/mainboard/dell/optiplex_9020/mainboard.c: 310 in get_pkg_power() 304 static uint16_t get_pkg_power(void) 305 { 306 uint8_t rapl_power_unit = rdmsr(0x606).lo & 0xf; 307 if (rapl_power_unit) 308 rapl_power_unit = 2 << (rapl_power_unit - 1); 309 uint16_t pkg_power_info = rdmsr(0x614).lo & 0x7fff; >>> CID 1544381: Integer handling issues (DIVIDE_BY_ZERO) >>> In expression "pkg_power_info / rapl_power_unit", division by expression "rapl_power_unit" which may be zero has undefined behavior. 310 if (pkg_power_info / rapl_power_unit > 0x41) 311 return 32; 312 else 313 return 16; 314 } 315 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Jun Muta 28 Apr '24

28 Apr '24

Issue #121 has been updated by Jun Muta. 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've recently started using Libreboot and I'm having this issue on my T430. Do you happen to know what the values are for the T430? ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1818 * 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 28 Apr '24

28 Apr '24

Issue #121 has been updated by Anastasios Koutian. 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. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1817 * 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 28 Apr '24

28 Apr '24

Issue #121 has been updated by Patrick Rudolph. 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. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1816 * 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 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

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