coreboot

coreboot@coreboot.org

6 participants
39687 discussions

coreboot release 4.15 reminder
by Jason Glenesk 01 Nov '21

01 Nov '21

Hi All, We are still going to do a release this week (Friday 11/5). If you have hardware and the ability to test, please test with the current code and report back any issues that come up. Also if you want a feature or change to be called out in the release notes that was checked in since 4.14, please add the change to Documentation/releases/ coreboot-4.15-relnotes.md. Side Note: I forgot to introduce myself when sending the last notice. I am relatively new to the coreboot community. AMD has been building up a coreboot team, and I started working with them a little over a year ago. I've worked in and around the firmware realm for almost 10 years. I'm excited about the chance to contribute to the project. Thanks everyone for being so welcoming. -Jason

1 0

Re: Installing OpenBIOS/coreboot
by bernd1-1＠web.de 01 Nov '21

01 Nov '21

2 1

Rust Hypervisor Firmware for coreboot
by Moroo Akira 29 Oct '21

29 Oct '21

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 29 Oct '21

29 Oct '21

1 0

[SPECIFICATION RFC v3] The firmware and bootloader log specification
by Alec Brown 29 Oct '21

29 Oct '21

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 27 Oct '21

27 Oct '21

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

7010 Motherboard Variants
by Matt B 25 Oct '21

25 Oct '21

A question about Optiplex 7010 motherboards: It appears (at least to me) that the DT and MT variants of the 7010 use the same motherboard, different from the SFF. The docs specify the SFF version. Has any testing been done on the DT/MT motherboard? The only mention in the documentation: > There are no schematics for SFF, but if one looks for MT/DT schematics, > they can be found publicly. Most of the schematics should match the SFF (although MT/DT has additional > PCIe and PCI slot). -M

2 2

GPU clock throttling on Intel Atom family
by Rao G 22 Oct '21

22 Oct '21

Hi All, Trying to enable GPU clock throttling on Intel Gen 7 UHD The SoC is E3815 Atom BayTrail On Ubuntu *command* *i*ntel_gpu_frequency *output* cur:200MHz min:200MHz RP1:400MHz max:400 MHz Can GPU Frequency be throttled? Any specific registers to enable throttling for GPU/GFX Thanks Ranga

1 1

[arm64] queries on current support and future direction
by Sukanto Ghosh 20 Oct '21

20 Oct '21

Hi Everyone, We have couple of queries regarding the current support and future direction of arm64 port of coreboot: 1. Does the current coreboot/arm64 execute post BL31 stage (assuming a separate BL2 stage loads BL31 and coreboot) ? * If no, would coreboot community be willing to support such a flow (via a build-time flag) ? * Beyond the direct access of EL3 registers, what are the other assumptions that the current coreboot/arm64 port has that need to be addressed to allow such a NS-EL2 port ? 2. Does the current coreboot/arm64 port allow executing only the ramstage of coreboot (say as a means of reducing the coreboot binary footprint) ? Best Regards, Sukanto

4 4

20 October 2021 coreboot Leadership meeting minutes
by Martin Roth 20 Oct '21

20 Oct '21

# 20 October 2021 - coreboot Leadership ##Attendees: Felix Singer, David Hendricks, Arthur, Werner, Piotr, Lean Sheng Tan, Marshall, Jason Glenesk, Jay Talbott, Matt DeVillier, Patrick Georgi, Tim Crawford, Martin, Stefan, Felix Held ## Agenda: * [patrick g] “Verified+1” permissions on gerrit repos that aren’t build tested (e.g. homepage.git): open up? For which groups? * For which repos? * Blobs - Only people appointed by Stefan for legal reasons. * Homepage: All submitters? Owner’s +2 or verified doesn’t count. * [martin] Clean up the coreboot root folder? * /spd, /gnat.adc, /Makefile.inc, /toolchain.inc -> src * Move spd directory to src/lib (or src/device?) * Look at moving gnat.adc to /src. Might be difficult to move * Move toolchain.inc to /src - only included by top level makefile * (keep Makefile.inc in place, otherwise it has to refer to ../util which is ugly) * /configs -> util/abuild * Having this here may help with visibility of platforms * Leave this here, remove subdirectory * /MAINTAINERS, /AUTHORS -> Documentation * Leave both of these at the top level * MAINTAINERS is machine readable and not really “Documentation”, AUTHORS is a “standard file” * Remove COPYING - it’s a copy of the GPL V2 license, which we have under /LICENSES * Leave this here: standard location so license checking and compliance tools are happier to find it there. * Update README.MD to point into /Documentation and each .md in other directories. * Marshall will do this. Thanks! * Add a .mailmap file [to correctly map authors to an email address](https://git-scm.com/docs/gitmailmap). * Yes * Should we lock it to the result after moving anything so that additional objects can’t be created without deliberation? * Add a lint test to keep other files from being added without discussion. * [Martin] When do we need another coreboot EFI working group meeting? * Next tuesday - send out invites after this meeting. * Lots of issues joining last time. * [Werner] Discuss patch [CB:55367](https://review.coreboot.org/c/coreboot/+/55367) regarding Intel PSE (Programmable Service Engine) * Must be loaded at boot time by a piece of firmware. * Discussed osfc2020 - zephyr based, but not open yet. * Patch just adds the loading from cbfs so that FSP can load it. * Yet another blob without notifications. * Blob is unfortunately mandatory for the platform. * Initializes the ARM processor then stops running? * It may be possible to write an open version? * The process of open sourcing the code for this takes a long time, so this is (in theory) a temporary solution. * The processor is EC-like, handles realtime interface, has I2C interface. * PCIe devices can be assigned to either the device or X86. * Sheng and Werner will verify that this is more similar to an EC than the ME. * If this is EC-like, this shouldn’t be an issue. * [Arthur] Logging: (optional) printing the error level in front of the message? * Would need to have a little logic to allow a line to continue without printing again. * Loglevel in brackets. * Sure, let's try this - so long as it's optional, there's not much of a downside. * [Martin] Adding requirements for blobs in coreboot’s repos * Nico [suggested requesting/requiring some additional items for blobs](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thre…. * We already have[ a list of requirements](https://review.coreboot.org/plugins/gitiles/blobs/+/refs/head…, so updating that doesn’t seem unreasonable. * How do we want to handle non-coreboot-owned blob repos - fsp/intel_microcode/amd_blobs/qc_blobs/ * Let’s review the blobs directory and see what’s still needed. * Revisit next meeting ## Mailing list discussions of interest: * Mailing list question about [arm64 ports of coreboot](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/t… * Mailing list: [firmware and bootloader log spec](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/threa… * (LPC 2021 System Boot and Security MC discussion about that)[https://youtu.be/JwU1_hyOzMI?t=4329] ## Ongoing items: * [New videoconferencing system?](#bookmark=id.ehzxgz9a1ta0) * Big Blue Button (maintained install: senfcall.de, [coreboot room](https://lecture.senfcall.de/pat-yut-ayj-bc6) set up by pgeorgi) * At the end of the meeting, please try to join the coreboot room here, so we can see if it’s working for people. * What happens if the host doesn’t join - seems fine. * This was tested by a number of people after the meeting, and it seems better than bluejeans. There weren't any reports of people not being able to get in, though some people had a little difficulty getting their audio set up. It seems like they were able to resolve this * Bluejeans. coreboot.org has an account here already, but lots of folks had issues joining the coreboot EFI working group meeting on Oct 12, so probably not? * Kind of weird - different versions per subscription level? * Definite NO. * Documentation updates * Hiring a tech writer? * Not right now. * coreboot 4.15 release ~Nov 1 * First notice went out to mailing list. * Contribute to the same patch or check it in and add to it? * Martin to review. * [Updating the builder](https://docs.google.com/document/d/10jQc1N67Pck2pE3pkyke7g-YFDIBqu… * Felix testing NixOS. * Need to determine builder differences - decide what builder can build what at runtime based on configuration. * Packaged coreboot toolchain for NixOS. * 4.14 package - making a stable release. * Set up build test with flashrom * Test both with linux & bsd

1 0

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