April 2024 - coreboot - mail.coreboot.org

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski Sept. 7, 2025

Sept. 7, 2025

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

5 7

[coreboot - Bug #535] (New) T420: Power light stays off after reboot
by frantic from xboot Sept. 7, 2025

Sept. 7, 2025

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

3 4

[coreboot - Bug #415] (New) RESOURCE_ALLOCATION_TOP_DOWN breaks edk2
by Sean Rhodes May 2, 2025

May 2, 2025

Issue #415 has been reported by Sean Rhodes. ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 https://ticket.coreboot.org/issues/415 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 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 - Bug #536] (New) Cannot build coreboot-sdk
by Michał Żygowski Aug. 22, 2024

Aug. 22, 2024

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 8

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel Aug. 7, 2024

Aug. 7, 2024

Issue #420 has been reported by Krystian Hebel. ---------------------------------------- Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… ---------------------------------------- Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- 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 12

question about nodefaultlibs gcc option
by Yoshinoya April 30, 2024

April 30, 2024

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 April 30, 2024

April 30, 2024

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 April 29, 2024

April 29, 2024

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 April 28, 2024

April 28, 2024

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 April 28, 2024

April 28, 2024

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