July 2024 - coreboot - mail.coreboot.org

[coreboot - Bug #548] (New) Computer Fails To Recognize Upgraded WiFi Card
by Jeremy Brown May 17, 2025

May 17, 2025

Issue #548 has been reported by Jeremy Brown. ---------------------------------------- Bug #548: Computer Fails To Recognize Upgraded WiFi Card https://ticket.coreboot.org/issues/548 * Author: Jeremy Brown * Status: New * Priority: Normal * Target version: none * Start date: 2024-07-15 ---------------------------------------- I am running coreboot 24.05 on my Lenovo X201. I decided to upgrade my WiFi card from an Intel Centrino Advanced-N 6205 to an Intel Wireless-AC 7260; since I selected the option to support Intel PCIe cards in my build config I expected everything to work but my computer fails to recognize the new card. The old card is still recognized if I reinstall it so I know I didn't mess up the socket somehow; I've read reports of the 7260 [working with a modded factory BIOS](https://richbits.rbarnes.org/installing-the-intel-7260-in-the-thinkpa… so I don't think there's an electrical issue. I've attached lspci data from both chips, lmk if additional information is needed. ---Files-------------------------------- 6205_lspci_tree.txt (1.63 KB) 7260_lspci_tree.txt (1.57 KB) 6205_lspci.txt (12.8 KB) 7260_lspci.txt (12.2 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 11

[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

Gerrit Gitiles is back - for now
by Felix Singer Sept. 20, 2024

Sept. 20, 2024

I've just enabled Gitiles again. We will observe which effect this has on Gerrit now. Fingers crossing that it won't cause a high load anymore :) Felix

3 4

Announcement: Introducing UEFI Capsule Update Integration for coreboot with EDK II
by Beata Skierka Sept. 18, 2024

Sept. 18, 2024

Hello, We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage. One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II). For a detailed project outline, please visit our Dasharo documentation [1]. We are looking for feedback through comments on this thread or via the built-in discussion module on the website. Although the project plan has been already accepted by the NLnet Foundation, there may be still some room for justified changes. You can track project's progress via the GitHub Project [2]. Your feedback and participation would be much appreciated. We welcome your involvement in discussions, reviewing, and testing. You might already have seen some first patches as a results of this project getting started, such us: - https://review.coreboot.org/c/coreboot/+/82247 - https://review.coreboot.org/c/coreboot/+/82248 - https://review.coreboot.org/c/coreboot/+/82249 - https://review.coreboot.org/c/coreboot/+/82610 We acknowledge and appreciate the funding support from the NLnet Foundation. [1] https://docs.dasharo.com/projects/capsule-updates/ [2] https://github.com/orgs/Dasharo/projects/7/views/1 Best regards, Beata Skierka Project Manager https://3mdeb.com | @3mdeb_com

8 18

[coreboot - Bug #549] (New) coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" (Thinkpad W530)
by Simon Dominic Aug. 23, 2024

Aug. 23, 2024

Issue #549 has been reported by Simon Dominic. ---------------------------------------- Bug #549: coreboot 24.05: SeaBIOS Windows 10/11 BSOD "ACPI BIOS ERROR" (Thinkpad W530) https://ticket.coreboot.org/issues/549 * Author: Simon Dominic * Status: New * Priority: Normal * Category: board support * Target version: master * Start date: 2024-07-31 * Affected versions: master * Affected hardware: Lenovo ThinkPad W530 * Affected OS: Windows 10/11 ---------------------------------------- When using the latest coreboot (i.e. using command `git clone https://review.coreboot.org/coreboot`) which is currently 24.05, to build a rom for Thinkpad W530, I get BSOD with "ACPI BIOS ERROR" when trying to boot into Windows 10 or 11 from SeaBIOS. Even just booting from a Windows install usb will show this error. This is even with incorporating the vga bios files (so i can external displays to work) - see my defconfig. Did consider using EDK2 apparently Windows support is pretty solid, but could never make a successful build - not that `make` command had errors, but once flashing, would just having white underscore and have to recover with external flashing. A separate issue to write about in and of itself, but I prefer SeaBIOS so I'll be sticking with that. I am quite new to coreboot - using for only about 2-3 months now. Let me know if there is further information I should provide. ---Files-------------------------------- defconfig (590 Bytes) w530_bsod.jpg (1.98 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

2 17

[coreboot - Bug #536] (New) Cannot build coreboot-sdk
by Michał Żygowski Aug. 23, 2024

Aug. 23, 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

Re: RW_MRC_CACHE always displays needs update and boot time is more
by Moorthi M.s July 31, 2024

July 31, 2024

Hi Paul, > > Thanks for your reply. > > I figured out the issue. > > The ME CPU replayed option is printing as YES, and this forces the MRC > training on each reset. > > Updated the ME firmware, and the issue was solved. > > Regards, > Moorthi S > On Wed, Jul 31, 2024, 12:02 Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > >> Dear Moorthi, >> >> >> Welcome to coreboot. >> >> Am 31.07.24 um 07:45 schrieb Moorthi M.s: >> >> > I am developing coreboot (ver 4.17) along with UEFI payload for a custom >> > board derived from CFL H RVP11 CRB. >> > >> > I included the CACHE_MRC_SETTINGS to reduce the boot time on subsequent >> > power on. >> > >> > But the time was not reducing and on every power on, around 18 seconds >> are >> > taking between post code 0x92 (Ram Init) and 0x98 (Ram Init Exit). And >> > always prints as " MRC: cache data 'RW_MRC_CACHE' needs update". >> > >> > Because of this coreboot takes around 45 secs to boot. >> > >> > Why every time the MRC cache data is changing? Why the processor is not >> > using the MRC cached data? >> >> Without knowing the code you are using, nobody knows. Did you dump the >> cache data to compare? >> >> > Is there any other configurations needs to be done? >> Unfortunately, you did not provide enough information to answer your >> question. Please provide at least your configuration and the verbose >> logs. Best would be to upload your code (and the schematics). >> >> Also, why do you use coreboot 4.17? 24.05 is the latest release. >> >> >> Kind regards, >> >> Paul >> >> >> PS: Just to mention it, there are coreboot consultants [1], that might >> save you some time in the end. >> >> >> [1]: https://coreboot.org/consulting.html >> >

1 0

RW_MRC_CACHE always displays needs update and boot time is more
by Moorthi M.s July 31, 2024

July 31, 2024

Hi, I am developing coreboot (ver 4.17) along with UEFI payload for a custom board derived from CFL H RVP11 CRB. I included the CACHE_MRC_SETTINGS to reduce the boot time on subsequent power on. But the time was not reducing and on every power on, around 18 seconds are taking between post code 0x92 (Ram Init) and 0x98 (Ram Init Exit). And always prints as " MRC: cache data 'RW_MRC_CACHE' needs update". Because of this coreboot takes around 45 secs to boot. Why everytime the MRC cache data is changing? Why the processor is not using the MRC cached data? Is there any other configurations needs to be done? Regards, Moorthi S

2 1

New extra-selectors mechanism on superiotool
by Maxim Polyakov July 26, 2024

July 26, 2024

Hello community! I am adding support for f81866 and f81966 fintek chips in superiotool: https://review.coreboot.org/q/topic:%22fintek%22 However, there are some difficulties to make a dump of the registers of these chips. Their global LDN0 and HWM registers contain fields that switch the register banks of these devices. At the same time, these registers contain fields that should not change after they are configured. For example, <Port Select Register - Index 27h> register contains: BANK_PROG_SEL field[3-2] - Bank select for configuration registers (bank 0/1/2/3) and PORT_4E_EN[4] - 0: The configuration register port is 2E/2F. 1: The configuration register port is 4E/4F. I suggest introducing a new element in chip configuration for such registers - an extra selector: https://review.coreboot.org/c/coreboot/+/83196 It seems to me that this is the optimal solution. This allows superiotool to configure the register fields to select a bank before making a correct dump for the corresponding LDN in automatic mode. Please review. Thx // Regards, // Max

1 0