coreboot

coreboot@coreboot.org

8 participants
39598 discussions

2024-01-24 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 25 Jan '24

25 Jan '24

# 2024-01-24 - coreboot Leadership Meeting ## Attendees Martin Roth, Felix Singer, Julius Werner, Arthur Heymans, David Hendricks, Jonathan Hall, Matt DeVillier, Felix Held, Patrick Georgi, Werner Zeh, Mina Asante, Nicholas Chin, Subrata Banik, Nico Huber, Marshall Dawson, Maximilian Brune. ## Open Action Items * 2024-01-10 * [Open] Werner: Push patch based on https://ticket.coreboot.org/issues/522 * Nico: https://review.coreboot.org/q/topic:enforce_region_api * [Open] Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. * 2023-11-01 * [Started] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * We can save over 900MB by using shallow submodules. * [Projects & RFCs](https://docs.google.com/document/d/15H2m4swdESSgGaIuINOePkyst8b39Y7Lu…. * Making progress - see email thread. * 2023-10-4 * Martin: Write a tutorial for gerrit - Feel free to help.[Started](https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKa…. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. ## Minutes ### [Martin] [Review corebootprojects](https://docs.google.com/document/d/15H2m4swdESSgGaIuINOeP…. * See coreboot projects document ### [Martin] Review coreboot RFCs in gerrit * https://review.coreboot.org/c/coreboot/+/57861 * Abandon * https://review.coreboot.org/c/coreboot/+/62015 * Please review. ### [Martin & Felix]: coreboot infra discussion: - Is there any reason to consider moving to external services like gerrithub & github? - No? - coreboot.org hosts some private repos. Some cloud services claim ownership over everything. - Hidden costs? - Move Jenkins to a separate server - Can we use a build server, or is that too much of a security risk? - Some maintenance tasks are co-hosted. - What’s the problem if jenkins gets hacked? - Patches get marked as verified. - Can we reduce the saved logs that are no longer needed and only keep the ones that are important? - Unfortunately, there doesn’t seem to be a way to do that. Jenkins doesn’t have separate controls for even passed & failed builds, let alone builds that have been superseded by newer builds. * Decision: Rent a dedicated server with ECC memory and hard drives for storage. Start looking at moving jenkins over. We can look at moving the other services in the future. ## Hetzner servers “Ideal” machine for coreboot services * 8 cores with SMT * 64 GiB ECC Memory * 2x 512 GB NVMe drives RAID 1 * 2x 12 TB HDDs RAID1 * 12TB because 6TB drives are €17/month, 12 TB drives are €23. This can be used for backups & Jenkins logs/artifacts. * We could probably get away without a 2nd drive & RAID, but it seems more professional to have the redundancy. ### Hetzner AMD servers |[SX134] Mid-range Client CPU|[AX52] Mid-range Client CPU|[AX102] High-End Client CPU|[AX161] Server CPU| |:-------------------------- |:--------------------------|:--------------------------|:---------------- | | € 260.37 Germany | € 128.04 Germany | € 176.83 Germany | €240 Germany | | € 247.28 Finland | € 122.09 Finland | € 170.88 Finland | €227 Finland | | | | | | | AMD Ryzen 7 3700X | AMD Ryzen 7 7700 | AMD Ryzen 9 7950X3D | AMD EPYC7502P | | 8 Cores | 8 Cores | 16 Cores | 32 Cores | | | | | | | 128 GiB DDR4 ECC | 64 GiB DDR5 ECC | 128 GiB DDR5 ECC | 128 GiB DDR4 ECC | | | | | | | 2x 960 GB NVMe | 2x 1 TB NVMe | 2x 1.9 TB NVMe | 2x 1 TB NVMe | | | | | | | 10x 16 TB SATA HDD | 2x 12 TB SATA HDD | 2x 12 TB SATA HDD | 2x 12 TB SATAHDD | | | | | | * Here are relevant links to Hetzner AMD servers: - [SX134](https://www.hetzner.com/dedicated-rootserver/sx134/configurator#) - [AX52](https://www.hetzner.com/dedicated-rootserver/ax52/configurator#) - [AX102](https://www.hetzner.com/dedicated-rootserver/ax102/configurator#) - [AX161](https://www.hetzner.com/dedicated-rootserver/ax161/configurator#) ### Hetzner Intel Servers | [EX44] Mid-range Client CPU | [EX101] High-end Client CPU | [EX130-R] Server CPU | |:----------------------------|:----------------------------|:---------------------| | € 99.48 Germany | € 153.03 Germany | € 212.53 Germany | | € 93.53 Finland | € 147.08 Finland | € 206.58 Finland | | | | | | Intel® Core™ i5-13500 | Intel® Core™ i9-13900 | Intel Xeon Gold 5412U| | 6 P-cores 8 E-cores | 8 P-cores 16 E-cores | 24-cores | | | | | | 64 GiB DDR4 non-ECC | 64 GiB DDR5 ECC | 256 GiB DDR5 ECC | | | | | | 2 x 512 GB (Gen4) | 2 x 1.92 TB (Gen4) | 2 x 1.9 TB (Gen4) | | | | | | 2x 12 TB SATA HDD | 2x 12 TB SATA HDD | 2x 12 TB SATA HDD | | | | | * Here are relevant links to Hetzner Intel Servers: - [EX44](https://www.hetzner.com/dedicated-rootserver/ex44/configurator#) - [EX101](https://www.hetzner.com/dedicated-rootserver/ex101/configurator#) - [EX130-R](https://www.hetzner.com/dedicated-rootserver/ex130-r/configurator#) ### [SimonG] (cannot attend this week, so will skip Coreboot Control Block) # Next meeting * February 7, 2024. * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [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-01-24](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1….

1 0

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

22 Jan '24

Dear community, Please note that the upcoming coreboot leadership meeting is scheduled for Wednesday, January 24, 2024. [1] You are welcome to update the agenda items with matters you wish to see addressed during the meeting. [2] ## Current Agenda Items ### Felix and Martin want to talk servers again [1] (https://www.coreboot.org/calendar.html) [2] (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… .4ddv57gdsocp)

1 0

Shallow submodules
by Martin Roth 21 Jan '24

21 Jan '24

One of the tasks I've had in my queue for a bit is to look into shallow submodules for coreboot. TLDR, we can decrease the submodule data size by over 900GB by using shallow submodules. The idea behind shallow submodules is that by default, we don't pull down as much data. For most submodules, most people typically only use the single commit pointed to by the submodule pointer. This means that people are spending time pulling down commits and then storing data that they don't typically need. The downside of shallow submodules (and shallow git repos in general) is that they don't contain the full data for the repository, so you can't immediately look at the full history or check out other versions. There are a couple of ways to limit the amount of data being fetched by a git repository. - You can fetch a single branch - You can fetch a limited amount of the git repo's history, either by date or by number of commits. This explores those possibilities. Currently if you download everything in the coreboot tree, along with the full submodules you get 1.4GB of data: 226MB of data after downloading the just coreboot repo, but before downloading submodules. Then another 1.2GB of data for all of the submodules. Changing the submodules to pull down a depth of 1 commit, we fetch just 208MB of data, a much more reasonable size than 1.2GB Pulling down the full branch used for each submodule increases the submodule size to 769MB. Here's a spreadsheet with the submodule size data, along for recommendations for each. https://docs.google.com/spreadsheets/d/1DAnFFnoLxdLE15CsUTE_AuCZeKG-UdrBndi… <https://docs.google.com/spreadsheets/d/1DAnFFnoLxdLE15CsUTE_AuCZeKG-UdrBndi…> Submodules recommended to use --depth=1 are: arm-trusted-firmware, intel-sec-tools, stm, chromeec, blobs, fsp, vboot All other submodules would fetch the current branch. My thought is that we set the default for each submodule to the recommended value in the sheet, then we can add a Make target or Kconfig option that pulls down the rest, for anyone who wants the full data. Once you've pulled down the entire history of a repo, it won't get removed, so the update (mostly) only needs to be done once for historic data. You'd need to do it again after any submodule update to get the full recent commit history though. Unrelated to the submodules or any proposed changes, to thin the coreboot repo out a bit, you can limit how far back the coreboot history goes, and ignore branches other than main by running a command like this: `git clone https://review.coreboot.org/coreboot.git coreboot-https --shallow-since=2020-01-01 --branch=main --single-branch` This pulls down 127MB of data instead of the full 226MB. Obviously you can change the date as desired to get more or less history. If at some point, you decide you want the rest of the data for that repo, you can run `git fetch --unshallow`. One note on pulling less history for the coreboot repo - Make sure you get the latest tag, or your coreboot version id will be wrong and confusing. Let me know what you think about updating the submodules as recommended. Martin

5 7

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

19 Jan '24

Dear community, We are pleased to announce that the upcoming cooreboot leadership meeting is scheduled for next Wednesday, January 24, 2024. [1] Please take a moment to update the agenda items with matters you wish to see addressed during the meeting. [2] [1](https://www.coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 17 Jan '24

17 Jan '24

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1533252: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1533252: Memory - corruptions (OVERRUN) /src/soc/intel/xeon_sp/chip_common.c: 124 in attach_iio_stacks() 118 continue; 119 } 120 121 struct device_path path; 122 path.type = DEVICE_PATH_DOMAIN; 123 path.domain.domain = s * MAX_LOGIC_IIO_STACK + x; >>> CID 1533252: Memory - corruptions (OVERRUN) >>> Overrunning struct type device_path of 32 bytes by passing it to a function which accesses it at byte offset 39. 124 struct device *iio_domain = alloc_dev(dev->bus, &path); 125 if (iio_domain == NULL) 126 die("%s: out of memory.\n", __func__); 127 iio_domain->ops = &iio_pcie_domain_ops; 128 } 129 } ** CID 1533251: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1533251: Memory - corruptions (OVERRUN) /src/soc/intel/xeon_sp/spr/ioat.c: 37 in create_ioat_domain() 31 struct device_path path = { 32 .type = DEVICE_PATH_DOMAIN, 33 .domain = { 34 .domain = domain_base + bus_base, 35 }, 36 }; >>> CID 1533251: Memory - corruptions (OVERRUN) >>> Overrunning struct type device_path of 32 bytes by passing it to a function which accesses it at byte offset 39. 37 struct device *const domain = alloc_dev(upstream, &path); 38 if (!domain) 39 die("%s: out of memory.\n", __func__); 40 41 domain->ops = &ioat_domain_ops; 42 ** CID 1533250: Insecure data handling (TAINTED_SCALAR) /src/soc/intel/xeon_sp/chip_common.c: 106 in attach_iio_stacks() ________________________________________________________________________________________________________ *** CID 1533250: Insecure data handling (TAINTED_SCALAR) /src/soc/intel/xeon_sp/chip_common.c: 106 in attach_iio_stacks() 100 void attach_iio_stacks(struct device *dev) 101 { 102 const IIO_UDS *hob = get_iio_uds(); 103 if (!hob) 104 return; 105 >>> CID 1533250: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "hob->PlatformData.numofIIO" as a loop boundary. 106 for (int s = 0; s < hob->PlatformData.numofIIO; ++s) { 107 for (int x = 0; x < MAX_LOGIC_IIO_STACK; ++x) { 108 if (s == 0 && x == 0) 109 continue; 110 111 const STACK_RES *ri = &hob->PlatformData.IIO_resource[s].StackRes[x]; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Cannot verify review.coreboot.org's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’
by Mike Banon 16 Jan '24

16 Jan '24

Good day! I just found out that my wgets at http://dangerousprototypes.com/docs/Lenovo_G505S_hacking scripts (for restoring & configuring the AMD opensource AGESA boards at modern coreboot) - are failing because of this certificate error. To reproduce this easily you do not have to run the whole csb_patcher.sh or restore_agesa.sh - doing just a simple wget is more than enough, i.e.: wget "https://review.coreboot.org/changes/79838/revisions/2/patch?zip" --2024-01-16 **:**:**-- https://review.coreboot.org/changes/79838/revisions/2/patch?zip Resolving review.coreboot.org (review.coreboot.org)... **.**.***.*** Connecting to review.coreboot.org (review.coreboot.org)|**.**.***.***|:443... connected. ERROR: cannot verify review.coreboot.org's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’: Issued certificate has expired. To connect to review.coreboot.org insecurely, use `--no-check-certificate'. Please resolve this error -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

3 3

[coreboot - Bug #121] T520: Hangs in OS
by Alex Gravitos 16 Jan '24

16 Jan '24

Issue #121 has been updated by Alex Gravitos. seems my assumptions about it being the first return were not entirely correct, the laptop just froze on me during a system update (its arch, so no harm was actually done), i would like to see more details on the `PDM_APD_PPD` stuff ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1741 * 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

Added "checks" integration to Gerrit
by Felix Singer 16 Jan '24

16 Jan '24

Hi coreboot fellows, You will find some new things in the Gerrit UI when you have a patch open. I've just added checks integration, which shows the executed CI jobs and tests in a much more convenient way rather than in the comment section. Ideally, it also gives a bit information on which tests failed, how many or why they failed. So more or less a summary about the build results you also get when you open the overview of a CI job. And also.. failed jobs shouldn't be listed as "warning". An example how it could look like: https://gerrit-review.googlesource.com/Documentation/pg-plugin-checks-api.h… However, it's still work in progress and I'm trying to figure out how to make it showing more information. Just wanted to make a little announcement in case of you are wondering or seeing some errors :) Felix

2 1

Support for ASUS F15
by �� 15 Jan '24

15 Jan '24

Dear Coreboot project team, I am a user of the Asus F15 TUF Gaming laptop. I have a laptop with an Intel 11th gen i5-11400H CPU (Broadwell) on a motherboard specific to the laptop (FX506HC). Could you please help me create a way to install Coreboot on my computer or consider supporting it in the future? Best Wishes, Audial Moon

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Alex Gravitos 15 Jan '24

15 Jan '24

Issue #121 has been updated by Alex Gravitos. Patrick Rudolph wrote in #note-82: > It looks like returning `PDM_APD_PPD` in get_power_down_mode() also fixes the issue. took me a while to figure out which return was supposed to be changed (its the first one). **however**, for some reason doing that also kills ethernet - both on-board and in the dock. like, to the point of them not being seen by the system. an android phone connected as usb modem is detected fine, so i'd say changing these returns somehow impacts the gigabit ethernet blob. sorry if i give not enough info, i am using coreboot for less than a week on my T520i, tell me if you need anything like logs or whatever ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1740 * 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot