October 2021 - coreboot - mail.coreboot.org

ThinkPad T420 and FireWire chip on Linux
by Alesandar Metodiev April 9, 2022

April 9, 2022

Hello, Recently I have decided to give a try to coreboot for first time and flashed my ThinkPad T420, but a few weeks ago I have swapped the USB controller on the back, next to the battery, with a FireWire/USB controller (40GAB5809-G200) from another T420. Nothing special, since some models have been shipped like this. The controller is no longer accessible on my laptop. It seems like it may have been detected as an "SD Host Controller" or not detected at all. I will probably have to remove the chip and compare the output of lspci and lshw. If nothing has changed, I will probably have to return the stock BIOS and compare the results again. I have also tried to load some of the firewire kernel modules manually with modprobe. The operating systems I have tested so far are Arch Linux and Xubuntu. I am willing to provide more useful information, boot into a fresh Windows install, flash the chip again or whatever else. Correct me if I am wrong, but if I go back to the stock BIOS, the next time I flash, I will have to disassemble the laptop again and otherwise I must be fine with flashing internally, right? Thanks

6 28

Git reports an interesting error message
by Gregg Levine Jan. 20, 2022

Jan. 20, 2022

Hello! I just tried to synch my local tree with what's stored back there, and instead of watching it update I saw this one: fatal: unable to access 'https://review.coreboot.org/coreboot.git/': SSL certificate problem: certificate has expired Huh? Is everyone else aware of this? ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

3 5

26 October 2021 - coreboot EFI working group meeting minutes
by coreboot org Nov. 9, 2021

Nov. 9, 2021

# 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

Providing an Interface to load PSE FW for Intel Elkhart Lake Platform
by Tan, Lean Sheng Nov. 8, 2021

Nov. 8, 2021

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 Nov. 8, 2021

Nov. 8, 2021

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

Installing OpenBIOS/coreboot
by bernd1-1＠web.de Nov. 7, 2021

Nov. 7, 2021

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

Build error/warning on 32bit host?
by Branden Waldner Nov. 1, 2021

Nov. 1, 2021

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

Rust Hypervisor Firmware for coreboot
by Moroo Akira Oct. 29, 2021

Oct. 29, 2021

Hi, I noticed that some of my contributions to Rust Hypervisor Firmware could be helpful for the coreboot EFI working group. So I would like to introduce it. Rust Hypervisor Firmware (https://github.com/cloud-hypervisor/rust-hypervisor-firmware) is firmware written in Rust with a minimal EFI compatible layer. It is a part of the Cloud Hypervisor project and was created for booting Linux on the VMMs. I added the coreboot feature to the firmware to use the binary as a coreboot payload. I think this firmware would be a good start point if re-implementing UEFI without EDK2 because it provides only required functions to boot OS, but it is compatible enough to boot Windows10 on specific environments. The coreboot specific code is here: https://github.com/cloud-hypervisor/rust-hypervisor-firmware/blob/main/src/… It just parses the coreboot information table to provide e820 compatible information. I hope this is helpful. Akira Moroo

1 0

Re: WG:Installing OpenBIOS/coreboot
by bernd1-1＠web.de Oct. 29, 2021

Oct. 29, 2021

1 0

[SPECIFICATION RFC v3] The firmware and bootloader log specification
by Alec Brown Oct. 28, 2021

Oct. 28, 2021

Hi everyone, I've been working on improving the specification for the firmware and bootloader log that Daniel Kiper has proposed and take into account most of the suggestions that were made in these threads [1], [2]. The goal is to allow various boot components to pass logs to the running OS and then to the user space for processing and analysis. These logs should be generic enough so that it can work in multiple environments and be human readable. It has yet to be decided where to put the final version of this specification. It should be merged into an existing specification, e.g. UEFI, ACPI, Multiboot2, or be standalone, such as a part of OASIS Standards. Below is how the layout of these logs would store their data. bf_log_header: +-------------------+ u32 | version | u32 | size | u8[64] | producer | u8[64] | log_format | u64 | flags | u64 | next_bflh_addr | u64 | log_addr | u32 | log_size | +-------------------+ bf_log_buffer: +-------------------+ u32 | version | u32 | size | u8[64] | producer | u32 | next_msg_off | bf_log_msg[l] | msgs | +-------------------+ bf_log_msg: +-------------------+ u32 | size | u64 | ts_nsec | u32 | level | u32 | facility | u32 | msg_off | u8[n] | type | u8[m] | msg | +-------------------+ Where l is the number of msgs, n is the size of type, and m is the size of the msg. The bf_log_header structure forms a linked list. Each bf_log_header element in the linked list points to the individual log buffer and the next bf_log_header element in the linked list. The first element in the linked list points to the last boot component in the boot chain. The last element points to the starting boot component in the boot chain. The log buffers which contain the log messages are produced by the various boot components, typically from the firmware to the bootloader. The log message is stored in a log format that is compatible with the boot component that produced it. The fields in bf_log_header structure: - version: the firmware and bootloader log header version number, 1 for now, - size: the size of the bf_log_header to allow for backward compatibility if other fields are added, - producer: the producer/firmware/bootloader/... entity, NUL terminated string, e.g. GRUB, Coreboot; the length allows for ASCII UUID storage, - log_format: the format used to record the log messages, NUL terminated string, e.g. bf_log_msg, cbmem_cons, etc.; various producers may generate logs in various formats if needed, - flags: bit field used to store information about the log state, if bit 0 has been set it means the log was truncated, - next_bflh_addr: the physical address of the next bf_log_header structure, none if zero, - log_addr: the physical address of where the log buffer is stored, - log_size: the total size of the log buffer. The bf_log_buffer is used to store log messages from the firmware and bootloader. This format for storing messages is called the bf log format. The bf_log_buffer contains the header information of the bf log format with the log messages being stored in an array of bf_log_msg messages. The fields in bf_log_buffer structure: - version: the firmware and bootloader log version number, 1 for now, - size: the total allocated space for the bf_log_buffer including the log messages stored in msgs, - producer: the producer/firmware/bootloader/... entity, NUL terminated string, e.g. GRUB, Coreboot; the length allows for ASCII UUID storage; same as the field in bf_log_header, - next_msg_off: the byte offset from the beginning of the allocated space for bf_log_buffer to the next byte after the last bf_log_msg in msgs, - msgs: the array of log messages stored in the bf_log_msg structures. The fields in bf_log_msg structure: - size: the total size of the bf_log_msg entry, - ts_nsec: the timestamp in nanoseconds starting from 0 (zero); the producer using this log format defines the meaning of 0, - level: similar to the syslog meaning; used to differentiate normal log messages from debug log messages, but the exact interpretation depends on the producer, - facility: similar to the syslog meaning; used to differentiate the sources of the log messages, but the exact interpretation depends on the producer, - msg_off: the byte offset which the msg field starts in bf_log_msg, - type: the log message type; similar to facility but NUL terminated string instead of integer, but the exact interpretation depends on the producer, - msg: the log message, NUL terminated string. In bf_log_msg, the producers are free to use or ignore any of the level, facility, and type fields. If level or facility are ignored, they should be set to 0. If type is ignored, it should be set to an empty NUL terminated string. Since it doesn't seem possible to have each boot component using the same log format, we added a log_format and log_phys_addr fields to give flexibility in how logs are stored. An example of a different log format that can be used is the cbmem_console log format used by coreboot: cbmem_console: +-------------------+ u32 | size | u32 | cursor | u8[m] | body | +-------------------+ There is still the outstanding issue of how the logs will be sent to the OS. If UEFI is used, we can use config tables. If ACPI or Device Tree is used, we can use bf_log_header.next_bflh_addr to present the logs. If none of these platforms are used, it becomes a lot trickier to solve this issue. Any suggestions are much appreciated and will be taken into consideration. I will be presenting this work at the LPC System Boot and Security Micro-conference on the 22nd of September at 7:50 AM PDT (14:50 UTC). Come and join if you want to discuss the design. The schedule for the System Boot and Security Micro-conference can be found here [3]. Thanks! Alec Brown [1] https://lists.gnu.org/archive/html/grub-devel/2020-11/msg00100.html [2] https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00021.html [3] https://linuxplumbersconf.org/event/11/sessions/116/#20210922

4 6