coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Weird thoughts about blobs (was Re: Re: Another year, another blob?)
by Nico Huber 09 Nov '21

09 Nov '21

On 05.11.21 18:15, Martin Roth via coreboot wrote: > Nov 4, 2021, 05:24 by pmenzel(a)molgen.mpg.de: > >> On 20.10.21 14:24, Nico Huber wrote: >> >>> My proposal: >>> How about we set up some guidelines how to proceed when adding support >>> for a new platform that requires any blobs? My vague idea is as follows: >>> Before the very first commit for such a new platform can be merged, a >>> set of predefined, blob related questions (to be discussed) should be >>> answered. This should also apply if a new platform just brings the same >>> kind of blobs with it as its predecessor (e.g. next gen FSP). Situations >>> may change and blobs do too. Speaking of FSP, it's actually a set of >>> many blobs. I think questions should be answered for each part of it >>> individually. >>> ...>> What do you think? >>> >> >> Thank you for bringing this up, and I totally agree. Reaching out to the coreboot community and including it in the planing phase is currently lacking quite a lot. The coreboot mailing list is the perfect forum for that, but unfortunately not used a lot.>> >> Kind regards, >> Paul >> > The current reality is that binary blobs are needed for almost every platform in coreboot. I believe the coreboot leadership is united behind the unfortunate reality that allowing these blobs is a requirement for the platform. Not sure what you are trying to say. Do you mean we shouldn't talk about the way blobs are added because they are needed anyway? Blobs are needed anyway so we won't review code around them any more? > I don't think we're going to refuse a platform right now simply because it has blobs. Nobody brought that up. What are you referring to? > I'm not sure what coreboot would look like right now if we'd started refusing blobs when the required blobs started appearing, but it definitely wouldn't have many modern platforms. That's a very hypothetical, IMO wrong statement. "definitely" is a very strong word there. Also, what's a "required blob" anyway? Most of the blobs in coreboot are not required but politically desired. As an ex- perienced coreboot developer who has written fully open-source platform support in the past, I would expect this to have happened: We'd have less ARM platforms in the tree because those were added for Chromebooks with little interest from other folks. On the x86 end, we'd be behind about a year compared to the support we have today, as other companies who rely less on the silicon vendor's blessing might have done the job. The community would look much different. Instead of many developers struggling to bring blobs up, we'd have less but much better experienced developers who still understand the hardware. Of course we'll never know which scenario would have been more likely. But it's been almost ten years, a lot could have happened. Imagine coreboot would have been FSP free, maybe even AMD would have been more open to a free software solution. FWIW, FSP encourages a lot of people to put more and more code into blobs. IMO we are stuck in a corner, and you want us to stay there as calm as possible. > > We all agree that we don't like adding more proprietary binaries, but there are times when a binary needs to be closed for a time until the platform is released such as with the PSE. This should be acceptable, so long as the promise is actually followed through upon. If not, the company making that promise loses credibility. Unfortunately, that's not always a great motivator. Maybe the coreboot organization & SFC can enter into a contract that specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee. You know that the PSE is an Intel thing and still talk about credibility? Do you have any idea what is going on around their blobs? There are even claims in our documentation today that can't be explained and look like very weak excuses for the simple fact: The blob interface was done like this because Intel wanted it and all promises were only made to get the patch in. That Intel lost its credibility on the matter is one reason why it is hard to get things like the PSE support added. I think we need a better process so the developers tasked with such things don't suffer. And they should never be in a position that needs them to make promises. Individuals can't make promises on behalf of a huge company, that would be gambling, IMO, and we would never get an official, written promise anyway. So please forget about promises. > Simply refusing to accept the binaries *only hurts us*, most companies will be probably happy using Slimboot or TianoCore. Making things difficult to work with coreboot only makes it easier to show why something shouldn't be open and why the chip vendors shouldn't work with coreboot. I cant tell you how many times I've heard that the reason coreboot wasn't used or wasn't upstreamed was that it takes too long to get changes into coreboot. Again not sure why you bring that up? I started a thread to make things easier. Why do you want to make it harder? Nico

4 5

26 October 2021 - coreboot EFI working group meeting minutes
by coreboot org 09 Nov '21

09 Nov '21

# 26 October 2021 - coreboot EFI working group It looks like the push to require linux to use EFI is coming from the Universal Scalable Firmware project. [https://github.com/UniversalScalableFirmware/linuxpayload](https://github.c… It might be good if coreboot contributors helped drive those decisions. ## Objective: Linux is expecting more and more to use EFI supplied interfaces (UEFI Boot Services in particular, even if many are stubbed out) so like it or not, we’re going to need to support these interfaces. How do we approach this without turning coreboot into UEFI. ## AIs: * Matt to push his EDK2 patches * Matt look at re-implementing coreboot payload package * Martin to write some initial eocumentationDocumentation ## Agenda & Minutes * We have the coreboot EFI fork up: [https://review.coreboot.org/edk2.git](https://review.coreboot.org/edk2.git) * Jenkins builder is up: [https://qa.coreboot.org/job/edk2-gerrit/](https://qa.coreboot.org/job/edk2-… * Final patch for build was merged: [https://review.coreboot.org/c/edk2/+/58497](https://review.coreboot.org/c/e… * What next with EDK2? * Matt to push his patches from his current fork and clean them up. * Expect discussions on the patches about the best ways to do things. * Pulled patches from system76 & 9elements branches. * 9Elements - no definite timeline for pushing their patches. Currently having a logging issue. Mostly fixes. * Major feature implementation next year. Not sure yet how that will be handled. * Do we need to create branches? * 3mdeb, system76 & 9elements have other branches. * Documentation? * Any volunteers? Martin will write up some documentation to review. * What are we doing here? * How does this differ from the upstream EDK2? * Would like to avoid EFIisms in coreboot itself, so we are offloading it to the payload. * Is the EDK2 our preference for now? * Nobody stated a preference, but we'd like to make sure that any changes do not limit coreboot to only using the EDK2. * FSP has an issue with console output and timestamps - how to address this? * If we add an interface for the FSP, there are issues with linking. * AMD already handles this and passes coreboot compatible console and timestamps. * Payload chain loaders - turn cbmem into HOBs * Why not just put these into EDK2 * Let’s not limit ourselves to EDK2 * Sandy/ivy bridge platforms are having problems with the latest edk2 * Do we need to bring back the coreboot payload package as a separate implementation until this is fixed? * Separate payload or just update makefile? Matt will look into it initially. * Philipp is interested in working on a Rust-based payload for EFI compatibility. * Working on proof of concept payload * Look at adding Rust to coreboot toolchain at some point * System76 is also using Rust to build binaries that are getting added to the firmware separately. * Additional references for minimal EFI interfaces: * [https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf](https://odm.… (chapter 9) * [https://arm-software.github.io/ebbr/index.html#document-chapter2-uefi](http… * [https://developer.arm.com/documentation/den0044/latest](https://developer.a… (Appendix C) * [https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requ… \

2 1

First commercially available coreboot for Intel Xeon-SP
by Jonathan Zhang 09 Nov '21

09 Nov '21

Hi, We now have the first commercially available coreboot solution for servers based on Intel Xeon-SP processor (specifically CooperLake Scalable Processor). WW OCP DeltaLake server (with OSF being part of it) was OCP accepted; Also the server and its OSF solution are on market, backed by WW and 9E partnership. OCP blog: https://www.opencompute.org/blog/open-system-firmware-for-ocp-server-deltal… WW PR: https://www.prnewswire.com/news-releases/wiwynn-successfully-implemented-op… I look forward to a positive loop between coreboot engineering as open source firmware and its commercial success! Go coreboot for a fair server market share. Jonathan

3 2

Providing an Interface to load PSE FW for Intel Elkhart Lake Platform
by Tan, Lean Sheng 09 Nov '21

09 Nov '21

Hi all, This is an info mail for addressing this patch (soc/intel/elkhartlake: Introduce Intel PSE [1]): With the Elkhart Lake Platform Intel has introduced an additional subsystem controller inside the Chipset which can be used to offload different kind of tasks from the main CPU. This controller is called the Programmable Service Engine (PSE) and is an ARM Cortex M7 based CPU with 384 KB of Tightly Coupled Memory (TCM for data and code) and 1MB of L2 SRAM. The firmware this controller executes has to be loaded during boot-time of the main CPU and can be any custom designed piece of firmware that serves the needs of the application. In addition, the PSE can be a Zephyr OS based. In order to perform the task in a given application, which might be e.g., real-time communication over Time Sensitive Network (TSN), Intel(r) EC Lite Service, Out Of Band (OOB) Management or even a network proxy, there are several SoC internal peripherals that can be assigned to the PSE (.../pci_devs.h [2]). This assignment must be done at boot time of the main CPU and cannot be changed later. So once a peripheral is assigned to the PSE, it disappears from the host subsystem and is only useable with the PSE to perform the task in question. There is one communication channel between the host subsystem and the PSE subsystem so that the host CPU can communicate with the application running on the PSE. IPC HW with HECI protocol. There is further no way that the PSE application can access host dedicated peripherals. To achieve this the PSE is equipped with a dedicated MMU which isolates both subsystems. As mentioned earlier the Firmware of the PSE needs to be loaded at boot time of the host CPU, this is mandatory for Elkhart Lake. There is a patch on Gerrit provides an interface to load the PSE firmware (soc/intel/elkhartlake: Introduce Intel PSE [1]. This patch does not introduce the PSE-Firmware itself nor does it add a new blob to the coreboot repository. In fact, this patch acquires the PSE firmware to load located inside the CBFS and loads it into DRAM, adds some settings related to the PSE like peripheral ownership and passes this DRAM buffer to the FSP, which then performs the loading of the firmware among with the settings into the PSE controller itself. Please and thank you, Sheng [1]: https://review.coreboot.org/c/coreboot/+/55367 [2]: https://review.coreboot.org/c/coreboot/+/58466

5 8

Another year, another blob?
by Nico Huber 08 Nov '21

08 Nov '21

Hi coreboot community, a recent yet-another-blob occurrence reminded me that I wanted to write about the matter for a long time. Every few months, it seems (if not, more often), a new blob is introduced to coreboot. Alas, this is often hidden to the last minute, creating unnecessary friction and unfortunate, set-in- stone solutions that haunt us for the years to come. My proposal: How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs? My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered. This should also apply if a new platform just brings the same kind of blobs with it as its predecessor (e.g. next gen FSP). Situations may change and blobs do too. Speaking of FSP, it's actually a set of many blobs. I think questions should be answered for each part of it individually. IMO, just answering all questions shouldn't suffice to unlock the merge. If there's some downside that definitely outweighs the benefit of adding the new platform, it should be blocked until the blob situation can change. For instance, we had in the past blobs that needed to be cus- tomized under NDA per board. Something like that doesn't seem to be useful for a free-software project. What do you think? Nico

8 26

How to enable SERIRQ reliably?
by Zhiwen Zheng 08 Nov '21

08 Nov '21

I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly. u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10); /* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7));

3 6

Installing OpenBIOS/coreboot
by bernd1-1＠web.de 07 Nov '21

07 Nov '21

Hi. I've watched a television broadcast where a hacker or security expert suspected that the BIOS of ThinkPads has a backdoor. Therefore, he said he uses OpenBIOS or coreboot. I read on Wikipedia that OpenBIOS works in interaction with coreboot on Intel machines. I read https://www.openfirmware.info/OpenBIOS as well as https://www.coreboot.org/OpenBIOS. 1. Please tell me whether a user without knowledge in programming or Linux command lines in Terminal is able to install OpenBIOS and/or coreboot. 2. Would you provide step by step instructions (especially for my case) how to install OpenBIOS and/or coreboot on my system? Regards,

4 11

Does the mrc.bin extracted from BayTrail-M chromebox work with BayTrail-D celeron J1900
by Zhiwen Zheng 06 Nov '21

06 Nov '21

Hi, I am trying to add a mainboard using celeron J1900 to coreboot-4.14, the serial console output stops after entering the MRC. The mrc.bin I used is extracted from Mrchromebox's roms for baytrail based chromebooks.

3 4

03 November 2021 - coreboot Leadership meeting minutes
by Martin Roth 05 Nov '21

05 Nov '21

# 03 November 2021 - coreboot Leadership meeting minutes Edited for clarity and formatting. * Attendees: Christian Walter, David Hendricks, Felix Held, Felix Singer, Jason Glenesk, Jay Talbott, Martin Roth, Matt DeVillier, Patrick Georgi, Piotr Król, Ron Minnich, Sean Rhodes, Stefan Reinauer, Tim Crawford, Werner Zeh ## Ongoing Items * New videoconferencing system? The desire for a new way of having meeting is because the current Google Meet platform requires a Google Employee to allow access. It would also be nice to use an open platform instead of a proprietary one, but we need something stable that we can all access. * BigBlueButton was used for the last coreboot EFI working group meeting and worked relatively well for most people, though some still seemed to have issues. * Matt - BBB did a poor job of filtering background noise. Not as good from an audio perspective. * Felix - same. Audio is much better in meet. * We probably do not want to use BBB at this time. * Should we try Jitsi? Limits: 100 ppl is free limit * [https://meet.jit.si/](https://meet.jit.si/) * Does this work with firefox? It used to have issues with some browsers. * We'll test this for the next EFI working group meeting * So far Google Meet seems to offer the best quality. * Can we use the Public version of google Meet? * 1 hour limit? * Number of people? * Can coreboot make an Google workspace account and host the meetings with Google Meet? * Yes, it has a free tier for non-profits. We'd need to work this out with SFC as they're the actual non-profit. ## Agenda: ### [martin] Trademark issues with starlabs. * StarLabs used the coreboot name in a way that creates confusion. * What would a reasonable release name be? * Starboot * Add "Star Labs" prefix before "coreboot" to make clear that it's a distro * coreboot version 4.15-company-7 (recommended naming scheme when not doing their own distro like libreboot, pureboot, ...) * We should document acceptable use and naming of the coreboot trademark. * Should coreboot go back to quarterly releases? * [Sean (Star Labs)] Yes, this would help. ### [Martin] 2022 coreboot (only) conference/hackathon/summit It’s been several years since we had a coreboot summit, and the thought is that this would be mostly focused on hacking and discussing improvements to the project instead of having a significant number of talks. * [Chris] Do we need another in person event? OSFF is willing to plan/take over costs * [Martin]Yes, after looking at the agenda for the latest OSFC, it was felt that a coreboot-only conference might be useful. If OSFF wants to pay for it, that’d be great, but I don’t think that OSFF should replace coreboot. * [Werner] Sounds like a good plan * [David] Choose a place with fewer restrictions (needs to be predictable). * In April after OCP regional summit - OSFF Meetup with hackathon ~40 ppl * [Ron] 4-day thing in Prague already planned for the week after OCP. April 21-24. Do this in parallel with the OSFF meeting. * Martin, Ron, and Chris will meet soon to discuss expanding this meeting. * [Chris] OSFC 2022 will be (hopefully) in south korea ### [Martin] Use of pseudonyms at coreboot. We currently require the use of real names at coreboot for legal reasons. This bothers some people. Could we introduce a method to allow reasonable pseudonyms by having a verified name held privately to associate with the name used in gerrit? I’d rather not have everyone switch and end up with code checked in as booty-mcbootface, but it seems reasonable to protect people’s privacy if desired. * [Werner] Is there a trust for source code? Basically a broker who submits the patches for people. * This is suggesting “Code laundering”. * Things like this are just being established now, but maybe shouldn't be allowed. * The entity submitting code would be responsible for this (this is supported by the [Developer’s Certificate of Origin](https://coreboot.org/Development_Guidelines#Sign-off_Procedure), part (b) or (c)) * [Martin] Can we have a company audit the code? Then it wouldn't matter as much if someone anonymously submitted code because troublesome code could be caught. * The coreboot server is in Germany, so the codebase is following their laws. * It might be best not to have a policy because then if there are issues, lawyers could actually come after us for the policy not being sufficient. * What does Linux do? * They have the linux foundation and with ~70% (estimate drawn from thin air) of big IT corporations being members, they play by different rules. * What do other projects do? * Let’s ask the SFC. * The important thing is to make sure that we’re making an effort to keep questionable content out. ### U&EFI - Usable & Effective Firmware Initiative. Created to create standards that coreboot can use. This originated because of the rumor that linux will soon require EFI interfaces to boot, a few patches that tried to change core coreboot concepts into something different (e.g. [https://review.coreboot.org/c/coreboot/+/51770](https://review.coreboot.org…), and more pushes in a similar direction (such as the “universal” “scalable” firmware “standard” driven by Intel). This seems like it’s boxing coreboot into a corner. Additionally there have been efforts to push EFI blocks further into coreboot. * [David] I think this has more to do with distros and OEMs expecting them for their manufacturing and testing purposes, for example [https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf](https://odm.… * Recently there have been a number of initiatives defining “industry standards” that affect coreboot, we’re then told that we need to support these “standards” * This will allow coreboot to define our own de-facto standards of similar legitimacy. These will then allow coreboot to continue with what we’re doing. * UPF - [Usable-Payload-Format](https://github.com/Usable-Effective-Firmware-Initiat…: Recommendations for providing means to pass information on to the OS and payloads. * Join #uefi in libre.chat, also visit its home (for now) at GitHub: [https://github.com/Usable-Effective-Firmware-Initiative](https://github.com… * Note that this name is tongue-in-cheek though the project itself isn't.

1 0

Build error/warning on 32bit host?
by Branden Waldner 01 Nov '21

01 Nov '21

I've been working on testing current coreboot on my asus/p2b and asus/p2-99 for the upcoming release, but ran in to problems trying to build it on my p2b with Gentoo with gcc 11.2.0. It (ironically) did build and work on the p2-99 with Debian Buster (oldstable) with gcc 8.3.0. It also built on my main system with Debian sid 64bit and gcc 11.2.0. CC host/lib/extract_vmlinuz.o In file included from /usr/include/string.h:519, from host/lib/extract_vmlinuz.c:9: In function 'memcpy', inlined from 'ExtractVmlinuz' at host/lib/extract_vmlinuz.c:67:2: /usr/include/bits/string_fortified.h:29:10: error: '__builtin_memcpy' specified bound between 2147483648 and 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=] 29 | return __builtin___memcpy_chk (__dest, __src, __len, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30 | __glibc_objsize0 (__dest)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ host/lib/extract_vmlinuz.c: At top level: cc1: note: unrecognized command-line option '-Wno-unknown-warning' may have been intended to silence earlier diagnostics cc1: all warnings being treated as errors It looks like I might have to do a better job of regular testing of self hosting the build on these old 32-bit systems. Branden

1 1

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