September 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

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

Oct. 29, 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

TigerLake RVP TCSS init failure
by Michal Zygowski Oct. 27, 2021

Oct. 27, 2021

Dear coreboot community, I have encountered problem with silicon init on Tiger Lake RVP platform. I managed to resolve previous issues with memory initialization and now hitting an error with TCSS init. The FSP asserts on IOM ready check, which is 0. The configuration has selected CONFIG_USE_INTEL_FSP_MP_INIT (without MP PPI service). When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is selected, then the FSP-S returns smoothly (at least from one of the phases I guess) and resets after clearing MCEs in coreboot's CPU init: CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 Clearing out pending MCEs Setting up local APIC... apic_id: 0x00 done. Turbo is available but hidden Turbo is available and visible CPU #0 initialized Initializing CPU #2 Initializing CPU #6 Initializing CPU #7 CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 CPU: vendor Intel device 806c0 CPU: family 06, model 8c, stepping 00 Clearing out pending MCEs Cl (tutaj następuje reset) Any ideas what may cause these issues? When I clean this up, I will upstream the DDR4 variant of TGL UP3 RVP. -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

6 16

There is a python in our toolchain?!?
by Patrick Georgi Oct. 16, 2021

Oct. 16, 2021

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

11 28

How to enable DisplayPort audio for Windows in Baytrail?
by Rao Sept. 30, 2021

Sept. 30, 2021

2 1

Probook hardware info
by Brian Milliron Sept. 29, 2021

Sept. 29, 2021

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?

1 0

Build failure due to gcc update to 11.2
by Bensaid, Selma Sept. 27, 2021

Sept. 27, 2021

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 4

Coreboot help/teaching
by Patrick Charon Sept. 24, 2021

Sept. 24, 2021

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!

4 6

Support for Clevo p950er
by Jacob Dybvald Ludvigsen Sept. 24, 2021

Sept. 24, 2021

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

1 0