coreboot July 2023

coreboot@coreboot.org

19 participants
29 discussions

[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

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon 21 Feb '24

21 Feb '24

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

[coreboot - Bug #475] (New) mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c does not work as intended
by Bill XIE 17 Nov '23

17 Nov '23

Issue #475 has been reported by Bill XIE. ---------------------------------------- Bug #475: mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c does not work as intended https://ticket.coreboot.org/issues/475 * Author: Bill XIE * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2023-03-30 * Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: x200 ---------------------------------------- Date back to coreboot 4.9, mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c calls get_blc_pwm_freq_value(NULL), making the following if condition always falling to the first, not to mention null dereference on strcmp() in get_blc_pwm_freq_value(). In order to determine the correct vbt filename at runtime, edid ascii string should be obtained first. This issue may be distantly related to #474. -- 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 4

[coreboot - Support #485] (New) Request for Support for Intel Xeon 1700 D Processor Family in Coreboot(Ice Lake)
by Rajat Dongre 17 Nov '23

17 Nov '23

Issue #485 has been reported by Rajat Dongre. ---------------------------------------- Support #485: Request for Support for Intel Xeon 1700 D Processor Family in Coreboot(Ice Lake) https://ticket.coreboot.org/issues/485 * Author: Rajat Dongre * Status: New * Priority: Immediate * Assignee: Rajat Dongre * Target version: none * Start date: 2023-04-27 ---------------------------------------- Hi, I am writing this email to request support for the Intel Xeon 1700 D processor family (Ice Lake) in Coreboot. As you may be aware, the support for the IceLake SOC has been removed, and I am using a processor from the same family. I would appreciate any help or guidance on how to bring up my processor using Coreboot. I have been using Coreboot for some time and am familiar with its functionalities, but I am facing difficulties with the processor mentioned above. and Can I used to older version of coreboot where you give support for the Ice lake but the Intel Xeon 1700 D processor family launch in Dec 2022. so I have doubt I will work for this SOC as the Icelake is not updated from last 4 years in coreboot. I would be grateful if you could provide any relevant documentation, code, or instructions to help me with my request. I believe that my request will not only benefit me but also other members of the community who are facing similar challenges. Thank you for your time and consideration, and I look forward to hearing from you soon. -- 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 6

[coreboot - Other #479] (New) [legal] ISC License copyright violation in ubsan
by Jonas Termansen 17 Nov '23

17 Nov '23

Issue #479 has been reported by Jonas Termansen. ---------------------------------------- Other #479: [legal] ISC License copyright violation in ubsan https://ticket.coreboot.org/issues/479 * Author: Jonas Termansen * Status: New * Priority: Normal * Target version: none * Start date: 2023-04-09 ---------------------------------------- Hi :) coreboot has removed my copyright statement from the ubsan implementation, which violates my copyright as licensed to you under the terms of the ISC License: ``` * Copyright (c) 2014, 2015 Jonas 'Sortie' Termansen. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * ... ``` The file in question is: https://github.com/coreboot/coreboot/blob/master/src/lib/ubsan.c The file does clearly state it's forked from my original ubsan implementation: https://gitlab.com/sortix/sortix/-/blob/master/libc/ubsan/ubsan.c However, the coreboot copy has removed my copyright notice, which is one of only two terms of the license. It's fine that the permission notice has been changed to `SPDX-License-Identifier: ISC` which is unambiguously information preserving, but removing my copyright notice is a loss of information. The copyright notice was removed in https://github.com/coreboot/coreboot/commit/16849bbe0c8a79277e1a682dcb42eaf… which moved my name to AUTHORS. Although a mention in AUTHORS is appreciated, it removes the association between the file's contents and my identity and my moral rights to my work. Although the full information is available in the git history, that's not good enough. I'm concerned that further copies of the file in other projects may lose the authorship information entirely. Please restore my copyright notice at the top of the file :) Jonas 'Sortie' Termansen -- 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 4

[coreboot - Bug #500] (New) libgfxinit bootsplash only supports jpeg and does not support extended resolutions
by Thierry Laurion 17 Nov '23

17 Nov '23

Issue #500 has been reported by Thierry Laurion. ---------------------------------------- Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500 * Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c https://git.seabios.org/seabios.git/ https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad… WiP PoC: https://github.com/osresearch/heads/pull/1403 * Affected hardware: iGPU driven by libgfxinit * Affected OS: All ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAt… Short version: - libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768) - libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768) - libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 - Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used. - Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo. - Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree - By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that) Longer version: - OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd - To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378) - Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14) - To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach) - With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad…) - The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX. Actual state: - libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) - libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-…) - Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job. Desired state: - flat bmp support in native format just like seabios support, where coreboot compressed them prior of adding it into CBFS. - support for all crazy resolutions we currently have, not being stuck in 2000. - Be able to promote coreboot from raminit code. ---Files-------------------------------- signal-2023-07-13-164022.jpeg (269 KB) signal-2023-07-13-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) -- 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 10

[coreboot - Bug #499] (New) coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
by Oberon 4071 31 Aug '23

31 Aug '23

Issue #499 has been reported by Oberon 4071. ---------------------------------------- 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 * Author: Oberon 4071 * Status: New * Priority: Normal * Category: coreboot common code * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * 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) -- 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

6 25

Trouble booting with mt8183
by Jared Baur 15 Aug '23

15 Aug '23

I am looking for some advice for configuring coreboot with a uImage fit payload for an mt8183 chromebook (Kukui Fennel)? I have said fitimage, I've modified the memlayout for the mt8183 board similar to https://github.com/coreboot/coreboot/commit/22e605c2c06f553b98131a87b634709… so that the fitimage fits in the cbfs and has space to load, and coreboot successfully builds. I've also enabled a bunch of debug settings for coreboot printing to serial. When flashing the ROM and rebooting, the serial console doesn't show anything past bootrom messages like so: ``` [DL] 00000000 00000000 010701 F0: 102B 0000 F3: 1006 0033 [0200] F3: 4001 00E0 [0200] F3: 0000 0000 V0: 0000 0000 [0001] 00: 1027 0002 01: 0000 0000 BP: 0C00 0251 [0000] G0: 1182 0000 EC: 0004 0000 [0001] S7: 0000 0000 [0000] CC: 0000 0000 [0001] T0: 0000 00DB [000F] Jump to BL ``` I am happy to post any configuration that would be helpful. I am hoping to just get some serial output from coreboot at this point in time, regardless of the payload.

3 2

[coreboot - Bug #495] (Response Needed) Stoney not booting PSPSecureOS -- Graphics driver takes 30 minutes to start
by CoolStar Organization 14 Aug '23

14 Aug '23

Issue #495 has been reported by CoolStar Organization. ---------------------------------------- Bug #495: Stoney not booting PSPSecureOS -- Graphics driver takes 30 minutes to start https://ticket.coreboot.org/issues/495 * Author: CoolStar Organization * Status: Response Needed * Priority: High * Category: chipset configuration * Target version: none * Start date: 2023-06-14 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: stoney * Affected OS: Windows 10, Windows 11 ---------------------------------------- Windows 11 Graphics driver takes 30 minutes to start on Stoney due to missing PSPSecureOS. Windows 10 20H2 and newer hangs on boot (potentially from the same thing) -- 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 3

[coreboot - Bug #496] (New) Missing malloc check in libpayload
by Keith Makan 14 Aug '23

14 Aug '23

Issue #496 has been reported by Keith Makan. ---------------------------------------- Bug #496: Missing malloc check in libpayload https://ticket.coreboot.org/issues/496 * Author: Keith Makan * Status: New * Priority: Normal * Target version: none * Start date: 2023-06-27 * Affected versions: 4.21 * Affected hardware: ALL * Affected OS: ALL ---------------------------------------- libpayload in payload/libpayload/drivers/options.c::get_option_as_string does not issue a NULL check against malloc's return code. Should there be a NOMEM error this may result in a NULL pointer deref or crash. The following code extract illustrates the mentioned issue: ` int get_option_as_string(const struct nvram_accessor *nvram, struct cb_cmos_option_table *option_table, char **dest, const char *name) { ... /* extra byte to ensure 0-terminated strings */ raw = malloc(cmos_length+1); memset(raw, 0, cmos_length+1); <--- no check against malloc's return code ` -- 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 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2023