coreboot

coreboot@coreboot.org

37 participants
38719 discussions

Providing an Interface to load PSE FW for Intel Elkhart Lake Platform

by Tan, Lean Sheng

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

16 hours, 12 minutes

TigerLake RVP TCSS init failure

by Michal Zygowski

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

20 hours, 47 minutes

7010 Motherboard Variants

by Matt B

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

3 days, 3 hours

Installing OpenBIOS/coreboot

by bernd1-1＠web.de

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,

3 days, 23 hours

Build error/warning on 32bit host?

by Branden Waldner

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

4 days, 7 hours

GPU clock throttling on Intel Atom family

by Rao G

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

6 days, 3 hours

[arm64] queries on current support and future direction

by Sukanto Ghosh

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

1 week

20 October 2021 coreboot Leadership meeting minutes

by Martin Roth

# 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 week

Another year, another blob?

by Nico Huber

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

1 week

[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

1 week, 1 day

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot