coreboot June 2024

coreboot@coreboot.org

10 participants
20 discussions

Gerrit Gitiles is back - for now
by Felix Singer 20 Sep '24

20 Sep '24

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

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

22 Aug '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 8

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel 07 Aug '24

07 Aug '24

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

2024-06-26 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 28 Jun '24

28 Jun '24

# 2024-06-26 - coreboot Leadership Meeting ## Attendees Felix Singer, Felix Held, Werner Zeh, Jonathan Hall, David Hendricks, Jay Talbott, Mina Asante, Martin Roth, Karthik Ramasubramanian, Marshall Dawson, Shelley Chen, Maximilian Brune, Lean Sheng Tan. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ## Improving coreboot processes ### [Martin] bi-weekly review meetings * In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour and we’ll see where things progress from there. Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in some other time zone that may switch based on daylight savings?) * 17:00 UTC on Wednesdays opposite the leadership meeting. * David: Start a new google doc to ask for reviews. * Werner: Dedicated email address * Felix: Would it be better to just generate a list? * David: Let’s do both requests and generate a list of patches to review. * Karthik: Should maintainers be involved? * Martin: Absolutely, if they come to the meeting. * David: The idea is to remove bureaucracy * Werner: Who should we invite? * Martin: core devs * Felix: We can change things that don’t work well. ### [Martin] Merge SLOs * Can we define objectives for timeframes to get patches merged to different areas in the codebase? An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform. * Mainboard: 1 week? * FelixH: So what do we do if we get past this timeframe? Just merging anything because it’s passed the SLO period seems like a bad idea. * David: This is designed to help people who are new to the project. We don’t just want to merge stuff, but for isolated code, maybe we can look the other way at imperfections. * FelixH: Frequently add comments and mark as resolved. * David: SoC code still needs to be held to higher standards. * David: We still expect authors to be responsive to feedback. * FelixH: We still need reasonable patches as well - one logical change per patch. * Martin: Do we want any areas besides Mainboards? What about SIOs? * Werner: Maybe drivers? * Max: Everything other than mainboards can be used by multiple vendors? * Martin: It doesn’t seem unreasonable to try to get things merged in a month. * FelixH: It would be good to have a list of things to look at. * Martin: Send out an email with a list of patches which will be looked at in the next meeting? (Yes) * Add a month SLO for drivers & SIOs initially. ### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU… * Werner: How do we make sure we don’t address the wrong drive? * Karthik: Define a rule in FMAP to describe the characteristic of the disk. * Werner: Wouldn’t coreboot need to search all of the disks? Finding it would be tricky. * Werner: Don’t like searching multiple partitions. * Martin: So would this just be in libpayload * Karthik: The initial code would be just for libpayload. * Martin: I can’t really think of any uses for this in coreboot other than a splash-screen, so I’d really prefer that it just stayed a part of libpayload. * Karthik: We can keep this just a part of libpayload. If we ever need to change that, we can address that again at that point. A notice will be added. * Werner: Last time I dealt with EMMC, there was a difference in speed - training slowed things down and it needed write support. * Martin: I feel like there’s a big difference between training and any writes needed for that, and actually accessing data on the drive. I’m not opposed to the idea of starting training earlier. * David: Are there any patches? * Karthik: I can upload patches in the next week or so - it’ll be a WIP patch. ### [Martin]: Setting aside the reformatting project with clang-format until it’s more stable and has fewer quirks. # Next Leadership Meeting * July 10,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes *[2024-06-26](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?p).

3 2

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 24 Jun '24

24 Jun '24

Dear coreboot community, Please be reminded that our upcoming leadership meeting is on Wednesday, June 26.[1] You are welcome to review and update the current agenda items with any matters you wish to see discussed during the meeting.[2] Below are the items currently on the agenda. ## Current Agenda Items ## Improving coreboot processes ### [Martin] bi-weekly review meetings * In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour and we’ll see where things progress from there. Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in some other time zone that may switch based on daylight savings?) ### [Martin] Merge SLOs * Can we define objectives for timeframes to get patches merged to different areas in the codebase? An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform. ### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU…. ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[coreboot - Support #534] Enable Ethernet (LAN) on ADL-P Custom Board
by Mahesh Kilumu 24 Jun '24

24 Jun '24

Issue #534 has been updated by Mahesh Kilumu. % Done changed from 0 to 100 ---------------------------------------- Support #534: Enable Ethernet (LAN) on ADL-P Custom Board https://ticket.coreboot.org/issues/534#change-1865 * Author: Mahesh Kilumu * Status: New * Priority: Normal * Target version: 4.21 * Start date: 2024-03-21 ---------------------------------------- Hi, With respect to the Alderlake-P RVP platform designed Custom Board. i have been trying to implement the Ethernet(LAN) on my Custom Board. on RVP intel team used GBE PHY but on my custom board we have used the External Realtek RTL8111H controller over PCIe Root port7 for Ethernet. Below are the configuration details: 1) Devicetree.cb: device ref pcie_rp7 on end # Enable PCH PCIE RP 7 using CLK 6 register "pch_pcie_rp[PCH_RP(7)]" = "{ .clk_src = 6, .clk_req = 6, .flags = PCIE_CLK_LAN }" 2) gpio.c: /* 19: PCIE SRCCLKREQ6- same as RVP */ PAD_CFG_NF(GPP_F19, NONE, DEEP, NF1), /* 2: GPD_2_LAN_WAKE_N- same as RVP*/ PAD_CFG_NF(GPD2, NONE, DEEP, NF1), /* 21 : LAN_ISOLATE# -New Implementation */ PAD_CFG_GPO(GPP_A21, 1, DEEP), from the logs observed that, Root port got enabled ->> [SPEW ] PCI: 00:00:1c.6: enabled 1 But observed the few Error & warnings in the log with respect to the above configuration [WARN ] Missing root port clock structure definition [ERROR] PCI: 00:00:1c.6 missing read_resources full log details : https://pastebin.com/zWcsEZvL -- 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 21 Jun '24

21 Jun '24

Dear community, Kindly note that we have an upcoming coreboot leadership meeting scheduled for Wednesday, June 26,2024.[1] We encourage you to take a moment to review the items on the current agenda and share your thoughts or suggest additional matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[coreboot - Bug #276] SPI flash console output causes `SMM Handler caused a stack overflow`
by Arthur Heymans 21 Jun '24

21 Jun '24

Issue #276 has been updated by Arthur Heymans. config SMM_MODULE_STACK_SIZE hex default 0x800 if ARCH_RAMSTAGE_X86_64 default 0x400 So just bumping this to always use 0x800 might be a solution ---------------------------------------- Bug #276: SPI flash console output causes `SMM Handler caused a stack overflow` https://ticket.coreboot.org/issues/276#change-1864 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2020-07-19 ---------------------------------------- On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: ``` FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/dsdt.aml' CBFS: Found @ offset 39300 size 3138 FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/slic' CBFS: 'fallback/slic' not found. ACPI: Writing ACPI tables at bfb51000. ACPI: * FACS ACPI: * DSDT FMAP: area CONSOLE found @ 0 (131072 bytes) coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... canary 0x0 != 0xbfeffc00 SMM Handler caused a stack overflow ``` -- 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 #276] SPI flash console output causes `SMM Handler caused a stack overflow`
by Filip Lewiński 21 Jun '24

21 Jun '24

Issue #276 has been updated by Filip Lewiński. Paul Menzel wrote: > On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: > > ``` > FMAP: area COREBOOT found @ 60200 (1703424 bytes) > CBFS: Locating 'fallback/dsdt.aml' > CBFS: Found @ offset 39300 size 3138 > FMAP: area COREBOOT found @ 60200 (1703424 bytes) > CBFS: Locating 'fallback/slic' > CBFS: 'fallback/slic' not found. > ACPI: Writing ACPI tables at bfb51000. > ACPI: * FACS > ACPI: * DSDT > FMAP: area CONSOLE found @ 0 (131072 bytes) > > > coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... > canary 0x0 != 0xbfeffc00 > SMM Handler caused a stack overflow > ``` I've experienced the same with coreboot+EDK2(MrChromeBox) on a Thinkpad T400. If you still have trouble booting the platform, I've somehow managed to bypass it by rebuilding with 64bit mode enabled. ---------------------------------------- Bug #276: SPI flash console output causes `SMM Handler caused a stack overflow` https://ticket.coreboot.org/issues/276#change-1863 * Author: Paul Menzel * Status: New * Priority: Normal * Start date: 2020-07-19 ---------------------------------------- On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow: ``` FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/dsdt.aml' CBFS: Found @ offset 39300 size 3138 FMAP: area COREBOOT found @ 60200 (1703424 bytes) CBFS: Locating 'fallback/slic' CBFS: 'fallback/slic' not found. ACPI: Writing ACPI tables at bfb51000. ACPI: * FACS ACPI: * DSDT FMAP: area CONSOLE found @ 0 (131072 bytes) coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)... canary 0x0 != 0xbfeffc00 SMM Handler caused a stack overflow ``` -- 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

VBT versions compatibility with different FSP/GOP versions
by Paul Menzel 18 Jun '24

18 Jun '24

Dear coreboot folks, I noticed commit 5d1494adda44 (mb/system76/tgl: Update VBTs to version 250) [1]: > mb/system76/tgl: Update VBTs to version 250 > > Commit 4c7e97b26a34 ("Update fsp submodule to upstream master branch") > included an update to the VBT from 240 to 250, breaking parsing of > existing VBTs. > > After that commit, the VBT was parsed as (from gaze16-3060-b): > > [DEBUG] PCI: 00:02.0 init > [INFO ] GMA: Found VBT in CBFS > [INFO ] GMA: Found valid VBT in CBFS > [INFO ] framebuffer_info: bytes_per_line: 4096, bits_per_pixel: 32 > [INFO ] x_res x y_res: 1024 x 768, size: 3145728 at 0xd0000000 > [DEBUG] PCI: 00:02.0 init finished in 6 msecs > > When the expected output is: > > [DEBUG] PCI: 00:00:02.0 init > [INFO ] GMA: Found VBT in CBFS > [INFO ] GMA: Found valid VBT in CBFS > [INFO ] framebuffer_info: bytes_per_line: 7680, bits_per_pixel: 32 > [INFO ] x_res x y_res: 1920 x 1080, size: 8294400 at 0xd0000000 > [DEBUG] PCI: 00:00:02.0 init finished in 6 msecs > > Generate blobs for the new version using Intel Display Configuration > Tool (DisCon) v3.3, based on the existing 237 and 240 VBTs. > > (For our edk2 payload, the UEFI GOP driver was updated to 17.0.1077.) Updating the submodule pointer of 3rdparty/fsp brings in commit 849ce8261bb0 (Tiger Lake FSP A.0.7E.70) with no commit message body. The diff contains: TigerLakeFspBinPkg/Client/SampleCode/Vbt/Vbt.json @@ -23891,7 +24584,7 @@ }, { "WidgetType": "Label", - "WidgetName": "VBT Version: 240", + "WidgetName": "VBT Version: 250",^M "Visibility": "", "Data": [], "HelpText": "", Vladimir (φ-coder) also published the tool intelvbtupgrader [2] to address this problem. I would have assumed that FSP versions would be backwards compatible. I attache the output of `intel_vbt_decode` of both VBT files. Does somebody have more insight? Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/82246 [2]: https://review.coreboot.org/c/coreboot/+/82722

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 June 2024