coreboot April 2024

coreboot@coreboot.org

26 participants
31 discussions

[coreboot - Bug #536] (New) Cannot build coreboot-sdk
by Michał Żygowski 14 May '24

14 May '24

Issue #536 has been reported by Michał Żygowski. ---------------------------------------- Bug #536: Cannot build coreboot-sdk https://ticket.coreboot.org/issues/536 * Author: Michał Żygowski * Status: New * Priority: Normal * Assignee: Martin Roth * Target version: none * Start date: 2024-04-24 ---------------------------------------- I have just tried building coreboot-sdk from scratch and could not get past the step of installing the required packages. Found out that diffutils dependency on libcurl4t64 break libcurl4 (change apt-get to apt to see verbose information message like below): ``` shell > [coreboot-sdk 2/4] RUN useradd -p locked -m coreboot && apt-get -qq update && apt -qqy install --no-install-recommends bash-completion bc bison bsdextrautils bzip2 ca-certificates ccache cmake cscope curl device-tree-compiler dh-autoreconf diffutils exuberant-ctags flex g++ gawk gcc git gnat-13 golang graphicsmagick-imagemagick-compat graphviz lcov less libcapture-tiny-perl libcrypto++-dev libcurl4 libcurl4-openssl-dev libdatetime-perl libelf-dev libfreetype-dev libftdi1-dev libglib2.0-dev libgmp-dev libgpiod-dev libjaylink-dev liblzma-dev libnss3-dev libncurses-dev libpci-dev libreadline-dev libssl-dev libtimedate-perl libusb-1.0-0-dev libxml2-dev libyaml-dev m4 make meson msitools neovim ninja-build openssh-client openssl parted patch pbzip2 pkg-config python3 python-is-python3 qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86 rsync sharutils shellcheck unifont unzip uuid-dev vim-common wget xz-utils zlib1g-dev && apt-get clean: 2.106 2.106 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. 2.106 2.841 diffutils is already the newest version (1:3.10-1). 2.841 diffutils set to manually installed. 2.841 Some packages could not be installed. This may mean that you have 2.841 requested an impossible situation or if you are using the unstable 2.841 distribution that some required packages have not yet been created 2.841 or been moved out of Incoming. 2.841 The following information may help to resolve the situation: 2.841 2.841 Unsatisfied dependencies: 3.001 libcurl4t64 : Breaks: libcurl4 (< 8.7.1-3) 3.004 Error: Unable to correct problems, you have held broken packages. ``` Changing libcurl4 to libcurl4t64 allows the docker to continue the build process of coreboot-sdk. But is this the right thing to do? -- 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 7

[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

question about CFLAGS custom
by Yoshinoya 29 Apr '24

29 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

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