coreboot September 2021

coreboot@coreboot.org

42 participants
31 discussions

[SPECIFICATION RFC v3] The firmware and bootloader log specification

by Alec Brown

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

2 days, 4 hours

There is a python in our toolchain?!?

by Patrick Georgi

Hi everybody, Historically, coreboot avoided depending on python too much (we got rid of an entire python based configuration and build system, for example), with few minor exceptions. The main reason has been that while python code is quick to slap together, it has demonstrated a penchant for breaking in all kinds of mysterious ways (python 2->3 really was just a slightly bigger instance of what's going on in python all the time), and its users demonstrate a disregard for their fellow developers as demonstrated by endless stack traces on trivial errors (or is the language too complicated to properly catch them all?) While probably nice for one-off prototypes, long term maintenance is a concern: this project has over 20 years of history under its belt, with more to come. That said, python makes its way back into the tree every now and then (typically as small snippets to compute and add hashes to binaries as needed by ARM SoCs). Uncanny, but typically not a big deal. There are two bigger initiatives proposed that would significantly increase our python footprint: 1. Replacing Linux's kconfig with kconfiglib ( https://review.coreboot.org/c/coreboot/+/48679) 2. Using pytest for end-to-end testing utilities ( https://review.coreboot.org/c/coreboot/+/57869) Compared to the "inject a hash value at a fixed location" scripts, these would probably be here to stay, and sufficiently integrated that everybody will have to deal with them. People spending time working on python code when it has no chance to land isn't a good use of their time and we should avoid that in the project. People spending time arguing that python shouldn't be used (to avoid the other outcome) even though the project's culture shifted and is now accepting Python isn't creating a great community for anybody. To avoid these scenarios, could we possibly nail down the policy on python in coreboot? Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

5 days, 6 hours

Git reports an interesting error message

by Gregg Levine

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."

2 weeks, 6 days

How to enable DisplayPort audio for Windows in Baytrail?

by Rao

3 weeks

Probook hardware info

by Brian Milliron

Since it didn't look like I would be able to get coreboot working on this laptop, I returned it. I still have all the hardware info I collected. Is this useful to anyone?

3 weeks, 1 day

Build failure due to gcc update to 11.2

by Bensaid, Selma

Hi, We are facing build failure due to the https://review.coreboot.org/c/coreboot/+/54050 # util/crossgcc: Update gcc to 11.2 Does anyone else face the same issue? Thanks, Selma.

3 weeks, 3 days

Coreboot help/teaching

by Patrick Charon

Good morning from France! I've been tinkering with computers for years, and got some (basic, yet useful) skills. Recently, reading about the BIOS/EFI/UEFI standard, I discovered CoreBoot. I tried and succeeded in compiling and using CoreBoot on a QEmu virtual machine. But now, I want to go deeper again, and install it on a real machine. The computer I selected is an old laptop from 2005, a HP ze4111s (single-core 1.6Ghz 32-bit Intel Celeron, 512 Mb DDR RAM, ATI Radeon GPU, enough to run Raspbian OS Buster). The BIOS is password protected, but I am on my way to unlock it. I read the article "CoreBoot porting guide". I understood it. But I still need some help, and even if I do things right, I have no way to check it. And if I did wrong, I want to know it before making my computer irreversibly crashed. So where can I find help to go through the steps and check if everything is right? To teach me, in fact. Forums and tutorials are sometimes difficult to understand, unclear and/or unusable with other machines than te example one. The computer I talk about is not my only one, I'm not this much crazy. Friendly, Patrick Charon P.-S.: this address is my "professional" address; my personal address patc(a)galaxyhit.com often goes to spam. But if you answer, please use this personal address!

3 weeks, 6 days

Support for Clevo p950er

by Jacob Dybvald Ludvigsen

Hi coreboot I have a Clevo p950er laptop, and I'd love to run coreboot firmware. Is it supported? -Sal cpu: 6-Core Intel Core i7-8750H lspci -tvnn: -[0000:00]-+-00.0 Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers [8086:3ec4] +-01.0-[01]----00.0 NVIDIA Corporation GP104M [GeForce GTX 1070 Mobile] [10de:1ba1] +-02.0 Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b] +-08.0 Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911] +-12.0 Intel Corporation Cannon Lake PCH Thermal Controller [8086:a379] +-14.0 Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d] +-14.2 Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f] +-16.0 Intel Corporation Cannon Lake PCH HECI Controller [8086:a360] +-17.0 Intel Corporation Cannon Lake Mobile PCH SATA AHCI Controller [8086:a353] +-1d.0-[02]----00.0 Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961/SM963 [144d:a804] +-1d.5-[03]----00.0 Intel Corporation Wireless-AC 9260 [8086:2526] +-1d.6-[04]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] +-1d.7-[05]----00.0 Realtek Semiconductor Co., Ltd. RTS5250 PCI Express Card Reader [10ec:5250] +-1f.0 Intel Corporation HM470 Chipset LPC/eSPI Controller [8086:a30d] +-1f.3 Intel Corporation Cannon Lake PCH cAVS [8086:a348] +-1f.4 Intel Corporation Cannon Lake PCH SMBus Controller [8086:a323] \-1f.5 Intel Corporation Cannon Lake PCH SPI Controller [8086:a324] superiotool -dV: superiotool r4.14-1987-g90fcffb416 Probing for Aspeed Super I/O at 0x2e... Found Aspeed AST2400 (id=0x00) at 0x2e Register dump: idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f val 85 87 06 01 00 00 00 00 00 00 00 00 01 00 00 00 def 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 LDN 0x02 (SUART1) idx 30 60 61 70 71 f0 val 00 02 f8 03 02 00 def 00 03 f8 04 02 RR LDN 0x03 (SUART2) idx 30 60 61 70 71 f0 val 00 00 00 00 00 00 def 00 02 f8 03 02 00 LDN 0x04 (SWC) idx 30 60 61 62 63 64 65 66 67 70 71 val 00 00 00 00 00 00 00 00 00 00 01 def 00 08 e6 08 e0 08 e4 08 e8 09 01 LDN 0x05 (Keyboard config (KBC)) idx 30 60 61 62 63 70 71 72 73 f0 val 01 00 00 00 00 0c 01 00 00 00 def 00 00 60 00 64 01 02 0c 02 83 LDN 0x07 (GPIO) idx 30 38 70 71 val 00 00 00 00 def 00 00 0b 01 LDN 0x0b (SUART3) idx 30 60 61 70 71 f0 val 00 00 00 00 00 00 def 00 03 e8 06 02 00 LDN 0x0c (SUART4) idx 30 60 61 70 71 f0 val 00 00 00 00 00 00 def 00 02 e8 05 02 00 LDN 0x0d (iLPC2AHB) idx 30 70 71 f0 f1 f2 f3 f4 f5 f6 f7 f8 fe val 00 00 00 00 00 00 00 00 00 00 00 00 00 def 00 09 01 NA NA NA NA NA NA NA NA 00 00 LDN 0x0e (Mailbox) idx 30 60 61 70 71 val 00 00 00 00 00 def 00 08 c0 09 01 flashrom -p internal -V: flashrom v1.2 on Linux 5.14.2-1-MANJARO (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.6.4, GCC 9.3.0, little endian Command line (3 args): flashrom -p internal -V Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer get_mtd_info: device_name: "BIOS", is_writeable: 0, numeraseregions: 0, total_size: 16777216, erasesize: 4096 Cannot open file stream for /dev/mtd0 No coreboot table found. Using Internal DMI decoder. No DMI table found. W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect. Active config mode, unknown reg 0x20 ID: 85. Found ITE EC, ID 0x8587, Rev 0x06 on port 0x2e. Found chipset "Intel HM370" with PCI ID 8086:a30d. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... BIOS_SPI_BC = 0x88: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x0 (SPI) Top Swap: not enabled SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x89: BIOS Lock Enable: disabled, BIOS Write Enable: enabled Error accessing SPIBAR, 0x1000 bytes at 0x00000000fe010000 /dev/mem mmap failed: Operation not permitted FAILED! FATAL ERROR! Error: Programmer initialization failed. Restoring PCI config space for 00:1f:5 reg 0xdc

3 weeks, 6 days

Intel® FSP External Architecture Specification v2.3 Has Been Released

by Desimone, Nathaniel L

Hi Everyone, We are pleased to announce that the FSP External Architecture Specification v2.3 has been posted to https://www.intel.com/fsp! Highlights * FSP_NON_VOLATILE_STORAGE_HOB2 – A new architectural HOB has been added for storage of MRC training data. While this HOB serves the same purpose as the original FSP_NON_VOLATILE_STORAGE_HOB, it allows >64KB of MRC training data to be stored. Some of Intel’s upcoming designs will require the storage of >64KB of MRC training data, so this addition is being made in advance. Bootloaders should practice defensive programming and first search for FSP_NON_VOLATILE_STORAGE_HOB2, and only search for FSP_NON_VOLATILE_STORAGE_HOB if the former is not found in the HOB list. This algorithm will guarantee compatibility with all FSP 2.x specification versions. * FSP Version Numbers – A new ExtendedImageRevision field has been added to the FSP_INFO_HEADER. This expands the size of the Revision and Build Number fields of the FSP version number from 8 bits to 16 bits. This is done by adding a high-order byte to each of those fields. If the ExtendedImageRevision field is present, then the FSP version number is decoded as follows: Build Number = (ExtendedImageRevision[7:0] << 8) | ImageRevision[7:0] Revision = (ExtendedImageRevision[15:8] << 8) | ImageRevision[15:8] Minor Version = ImageRevision[23:16] Major Version = ImageRevision[31:24] Roadmap Both Meteor Lake and Sapphire Rapids will require storage of >64KB of MRC training data. Therefore, we recommend that bootloaders plan to have support for FSP 2.3 ready by early next year. Does Anything Need to Change in coreboot? Supporting future Intel SoCs will require some changes. At a minimum, coreboot will need to be modified to support the new FSP_NON_VOLATILE_STORAGE_HOB2. Additionally, it is recommended that coreboot be modified to include the ExtendedImageRevision field when printing the FSP version number. This is not strictly required from a functional standpoint, but without it the FSP version number in the boot log will not be accurate.

3 weeks, 6 days

coreboot for Intel Xeon server processor

by Jonathan Zhang (Infra)

Hi colleagues, I am glad to announce that coreboot for Intel Xeon server processor has reached a major milestone: it is ready for the general development communities to have fun with. The FSP/coreboot/LinuxBoot stack for OCP (Open Compute Project) DeltaLake server was accepted by OCP OSF (Open System Firmware) project, and is made public at https://github.com/opencomputeproject/OpenSystemFirmware. For details, please check out https://doc.coreboot.org/mainboard/ocp/deltalake.html. Also the MAINTAINERS file was updated. If you have any question/suggestion, please reach out to the DeltaLake server and/or xeon-sp soc maintainers. Some additional notes: * The build system to build coreboot, Linux kernel, u-root, and to stitch the final image, is an open source project: https://github.com/facebookincubator/osf-builder * All the necessary Intel binary blobs are available with Intel redistributable licenses. DeltaLake server will be a great vehicle for engineering projects such as: * Server host firmware feature development. * Development for processor features that show up in server first, such as split IIO. If you need access to DeltaLake server, please reach out to the maintainers. I am also excited that 9 Elements volunteered to maintain the OSF DeltaLake code base, including coreboot. Going forward 9 Elements will continue to improve the code base, rebase to coreboot upstream tip, run tests and make periodic releases. We look forward to commercial success as well. All of these would not happen without coreboot community’s help, you guys rock! PS. Facebook team is looking for help. If you are interested, please check out the coreboot job board https://www.coreboot.org/jobs.html Thank you, Jonathan

4 weeks

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2021