coreboot November 2021

coreboot@coreboot.org

44 participants
35 discussions

Status of native Haswell raminit
by Matt B 11 Nov '21

11 Nov '21

Greetings, What is the status of native raminit on haswell? It's the first generation that doesn't have a native implementation. I did find some seemingly successful past work [1] but what happened to it? Did it run into a blocker issue or was it just abandoned in favor of other priorities? [1] https://code.georgi.software/coreboot/coreboot/commit/bc0066825877ea4f6e03c… -Matthew

1 0

9 November 2021 - coreboot EFI working group meeting minutes
by Martin Roth 10 Nov '21

10 Nov '21

# 9 November 2021 - coreboot EFI working group Attendees: Martin Roth, Felix Held, Michael Niewöhner, Matt DeVillier, Nate DeSimone, Patrick Georgi, Tim Crawford, Werner Zeh ## Agenda: * [Edward] Supporting some UEFI interfaces continues to be a hot topic, one such area is ESRT table ASL generation within coreboot to better support platform firmware topology descriptions up the stack. quasisec@ is working on a proposal in the not so distant future. * [Patrick] It looks like the push to require linux to use EFI is coming from the “Universal” Scalable Firmware project. * [UniversalScalableFirmware/linuxpayload](https://github.com/UniversalScalabl… <https://github.com/UniversalScalableFirmware/linuxpayload](https://github.c…> * [David] I think this has more to do with distros and OEMs expecting them for their manufacturing and testing purposes, for example [ubuntu-bios-uefi-requirements](https://odm.ubuntu.com/docs/ubuntu-bios-uefi… <https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf](https://odm.…> * 9.1. Legacy BIOS compatibility Ubuntu has been tested with UEFI-only mode BIOS and is also known to work with legacy BIOS compatibility mode (known as a Compatibility Support Module, or “CSM”) enabled. However, enabling legacy support will affect secure boot functionality, because it needs native-UEFI drivers and to be signed for validation during booting up * This looks like Intel trying to shape the future of firmware to suit their needs instead of coreboot's needs. * Are there any distros other than Ubunty looking at requiring UEFI? * [Nate] I believe these requirements are straight from Linux kernel. * [Patrick] In that case, they're probably an addition, not replacing the existing boot procedures. * Chip-agnostic loading would require this. * Someone from ARM proposing it. * [Nate] Linux is using EFI boot services to provide a more architecture agnostic Linux kernel launch [arch-agnostic initrd loading method for EFI systems](https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.ri… <https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.l…> * What boot parameters are still actually used? Need to go through the kernel source to find out. (that’s what Patrick G did when building the linux trampoline in cbfstool) * Supports native X64 launch. * Matt could use additional reviewers on his patches. Initial patches were simple, but the later patches could definitely use more reviewers. The concern is that there are probably better ways to do these later patches. If they don’t get reviewed, they’ll be merged regardless so that we have a working branch, but it would be better if reviewed and reworked as needed. [edk2 project search](https://review.coreboot.org/q/project:edk2) <https://review.coreboot.org/q/project:edk2](https://review.coreboot.org/q/p…> * [Martin] Yabits tested, and as previously reported is not currently working. More testing and debug is needed. * Nate: It looks like there are a number of fundamental issues with yabits, so the U-Boot implementation might be a better choice as a 2nd implementation. There were rumors about that version being dead, or having been canceled, but it looks like patches are still being merged. * [Martin] Documentation about coreboot’s EFI plans is started and will be shared before the next meeting. * Jitsi performed very well compared to all of the other open source solutions that we’ve used. The only issue is a lack of call-in numbers. Patrick will look at setting up a server to test more.

1 0

Installing coreboot with SeaBIOS
by Branden Waldner 10 Nov '21

10 Nov '21

> /bin/sh: 1: python: not found > make[2]: *** [Makefile:168: out/romlayout16.lds] Error 127 I ran in to this error the other day in a clean build environment and was going to mention it in the thread about python in the build system, but Peter Surge already commented here on it. If you are on Ubuntu or Debian you likely need to install "python-is-python3", which symlinks python to python3, since Debian kept python as python2 and makes python3 programs require that they use run as python3 not just python. With the removal of python2, they remove the original python link that pointed to the python version. Branden

1 0

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 09 Nov '21

09 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2021