coreboot

coreboot@coreboot.org

17 participants
39654 discussions

[RFC] Pre-Memory Sign-of-Life using Intel uGOP
by Compostella, Jeremy 27 Aug '23

27 Aug '23

Dear coreboot developers, With Raptor Lake, we introduced the Pre-Memory Sign-of-Life feature which displays an on-screen message while firmware components such as coreboot, Firmware Support Package Memory (FSP-M) or, CSME perform long time operations during pre-memory stages. We propose to take advantage of a proprietary driver Intel already supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver. This driver is designed to run in post-memory initialization stages. Therefore, we derived a new version capable of running in pre-memory stages which we called microGOP. This version is specifically designed to perform graphics legacy VGA initialization. We intend to keep providing such a binary base solution on the long run as it addresses our software convergence goals and is compatible with early platform development stage constraints. [libgfxinit] supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published. Below, we present the work we performed to run this microGOP driver from coreboot romstage. It allows to initialize graphics with a very similar flow compared to [libgfxinit] use. Our goal is to start collecting feedback. We will release all the patches on coreboot.org under the [ugop] topic soon. [libgfxinit] <https://github.com/coreboot/libgfxinit> [ugop] <https://review.coreboot.org/q/topic:ugop> 1 microGOP driver interface =========================== The uGOP PEIM provides the following PEIM-to-PEIM protocol under the `31a4622d-0e21-40a2-80db-c44208fce1b5' GUID. ,---- | #define PEI_PREMEM_GRAPHICS_PPI_GUID \ | { \ | 0x31a4622d, 0x0e21, 0x40a2, 0x80, 0xdb, 0xc4, 0x42, 0x08, 0xfc, 0xe1, 0xb5 \ | }; `---- The protocol is composed of three fields. ,---- | struct { | UINT32 Version; | PREMEM_PEI_GRAPHICS_INIT PreMemGraphicsPpiInit; | PREMEM_PEI_GRAPHICS_EXIT PreMemGraphicsPpiExit; | } PEI_MICRO_GRAPHICS_PPI; `---- 1. The current `Version' is `0x00010000'. Where the upper 16 bits represent the major (1) and the lower 16 bits represent the minor number. 2. `PreMemGraphicsPpiInit()' ,---- | typedef | EFI_STATUS | (EFIAPI *PREMEM_PEI_GRAPHICS_INIT) ( | IN VOID *Vbt | ); `---- The `PreMemGraphicsPpiInit()' should be supplied with a pointer to the Video BIOS Table. 3. `PreMemGraphicsPpiExit()' does not take any parameters. This function must be called to disable VGA graphics configuration once not necessary anymore. Not performing this operation may lead to undesirable behaviour when other graphics stack starts (GOP in FSP-S or Operating System driver). 2 Integration ============= As we intend to run microGOP driver in romstage, we want to keep the required coreboot code as small and efficient as possible. For this reason, we discarded re-using the EDK2 code which would have a major impact on the romstage binary size in addition to adding complication to the build scripts. Instead, we implemented a limited set of Pre-EFI Initialization services. The code is small and designed to accommodate a simple PEIM driver such as microGOP. 2.1 PEI services ~~~~~~~~~~~~~~~~ microGOP depends on a limited of PEI services: 1. `InstallPpi()' to install the PEIM Graphics PPI 2. `LocatePpi()' to access PEIM-to-PEIM Interface (PPI) Dependencies 3. `AllocatePool()' to dynamically allocate memory to handle internal data structure such as display information ... 4. `GetHobList()' and `CreateHob()' to access Hand Off Blocks (HOB) holding runtime data 5. `ReportStatusCode()' to report debug information which coreboot prints using `printk'. Those services implemented in coreboot are pretty straightforward and fit in less than 300 lines of code. 2.2 PEI services pointer ~~~~~~~~~~~~~~~~~~~~~~~~ microGOP expects to find the PEI services pointer in the architecture size word immediately preceding the Interrupt Descriptor Table (IDT) (cf. [Platform Initialization (PI) Specification] *5.4 PEI Services Table Retrieval*). Since [coreboot x86/exception] module already sets up the IDT and as we do not want to disrupt this configuration we create a copy of the IDT. But we include an extra architecture size word preceding the table to store the PEI services pointer. Note that FSP memory installs its own IDT but it backups and restores the one we have set up. Therefore, there is no risk of having PEI services pointer conflicts. [Platform Initialization (PI) Specification] <https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf> [coreboot x86/exception] <https://github.com/coreboot/coreboot/blob/master/src/arch/x86/exception.c> 2.3 Portable Executable Relocation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As we need to execute the microGOP binary in place, we need to perform a relocation operation of the Portable Executable binary. Since memory space is limited in the pre-memory stages, it is preferable to perform a static relocation operation during the firmware stitching operation. Fortunately, most of the logic and code is already available as this operation is performed on the FSP-M binary. We only have to add explicit support for EFI binaries (cf. [76762 cbfstool: Add relocation support for EFI binaries]). [76762 cbfstool: Add relocation support for EFI binaries] <https://review.coreboot.org/c/coreboot/+/76762> 2.4 Uncompressed VBT ~~~~~~~~~~~~~~~~~~~~ As microGOP requires the Video BIOS Table (VBT) and since memory space is limited in the pre-memory stages, it is preferable to keep VBT in uncompressed form in CBFS. We introduced the `CONFIG_VBT_CBFS_COMPRESSION' configuration entry to allow this (cf. [76816 drivers/intel/gma/Kconfig: Add VBT compression configuration entry]). [76816 drivers/intel/gma/Kconfig: Add VBT compression configuration entry] <https://review.coreboot.org/c/coreboot/+/76816> 3 Code flow =========== <file:./code-flow.svg> 4 Performances analysis ======================= The analysis below is based on a microGOP binary with eDP and HDMI support. 4.1 Size impact ~~~~~~~~~~~~~~~ When `CONFIG_UGOP_EARLY_GRAPHICS' is set 1. `ugop.efi' is included as a CBFS file 2. `romstage' includes extra code: `pei.c', `ugop.c' and `ux.c' 3. `vbt.bin' is stored uncompressed instead of lzma compressed CBFS File UGOP_EARLY_GRAPHICS=n (bytes) UGOP_EARLY_GRAPHICS=y (bytes) Delta (bytes) ---------------------------------------------------------------------------------------- microGOP 0 68448 68448 romstage 126128 136256 10128 vbt.bin 1264 9216 7952 ---------------------------------------------------------------------------------------- *Total* 127392 213920 *86528* The use of microGOP in coreboot represents a size increase of around 84 KB per region (`COREBOOT', `FW_MAIN_A' and `FW_MAIN_B'). 4.2 Regular Boot time impact (no Sign-of-Life) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On a Meteor Lake Google Rex board, we performed 5 warm reset cycles (without and with `CONFIG_UGOP_EARLY_GRAPHICS' set) and we collected the `cbmem -t' outputs. We computed the median time of each duration (time between two timestamps) and then performed a comparison with a threshold of 0.5 ms. Start ID Start Description End ID End Description Delta (ms) ------------------------------------------------------------------------------------------------------------------------- 947 CSE received 'CPU Reset Done Ack sent' from PMC 991 Die Management Unit (DMU) load completed +1.0 507 starting to verify body (load+SHA2+RSA) 508 finished loading body +4.7 510 finished verifying body signature (RSA) 511 starting TPM PCR extend -0.8 1030 finished EC verification 1040 finished storage device initialization +1.4 The only relevant impact is the verification of the image (507 -> 508): +4.7 ms and it can be explained by the 84 KB size increase of the image. Overall the boot time impact is about 5 ms and concentrated on `verstage'. 4.3 Cache-As-Ram ~~~~~~~~~~~~~~~~ For microGOP to execute properly, we have to provide some memory allocation services (`allocate_pool' and `create_hob'). These services relies on cache-as-ram memory reservation (`.bss' section). We looked at the two new object files: Object file .bss section size (bytes) ---------------------------------------- pei.o 6730 ugop.o 9 ---------------------------------------- *6739* With microGOP sign-of-life, there is an extra 7 KB cache-as-ram use. 4.4 Conclusion ~~~~~~~~~~~~~~ The SPINOR and cache-as-RAM space use along with the boot performance penalty are limited and comparable to what it would be with libgfxinit. We also noticed that microGOP is faster to bring-up graphics than libgfxinit. Indeed, according to previously captured numbers on Raptor Lake compared to some number of microGOP on Meteor Lake, microGOP is three times faster to bring up graphics than libgfxinit on an eDP panel (119 ms vs 373 ms). 5 Summary ========= This Sign-of-Life microGOP driver based implementation presents the following advantages: - it needs a limited code addition - it has a limited impact on the performance - its flow and boot performance impact is comparable to libgfxinit solution - it is compatible with our software convergence goals - it can be available during new platform development early stages which help our partners to test the feature and stabilize the platform Regards, -- *Jeremy* /One Emacs to rule them all/

5 10

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 22 Aug '23

22 Aug '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1518657: (OVERRUN) ________________________________________________________________________________________________________ *** CID 1518657: (OVERRUN) /src/soc/mediatek/common/i2c.c: 514 in mtk_i2c_speed_init() 508 for (clk_div = 1; clk_div <= max_clk_div; clk_div++) { 509 clk_src = I2C_CLK_HZ / clk_div; 510 bus_ctrl->ac_timing.inter_clk_div = clk_div - 1; 511 512 if (speed > I2C_SPEED_FAST_PLUS) { 513 /* Set master code speed register */ >>> CID 1518657: (OVERRUN) >>> Overrunning callee's array of size 7 by passing argument "bus" (which evaluates to 7) in call to "mtk_i2c_calculate_speed". 514 if (mtk_i2c_calculate_speed(bus, clk_src, I2C_SPEED_FAST, 515 &l_step_cnt, &l_sample_cnt)) 516 continue; 517 518 /* Set the high speed mode register */ 519 if (mtk_i2c_calculate_speed(bus, clk_src, speed, /src/soc/mediatek/common/i2c.c: 525 in mtk_i2c_speed_init() 519 if (mtk_i2c_calculate_speed(bus, clk_src, speed, 520 &step_cnt, &sample_cnt)) 521 continue; 522 523 bus_ctrl->ac_timing.inter_clk_div = (clk_div - 1) << 8 | (clk_div - 1); 524 } else { >>> CID 1518657: (OVERRUN) >>> Overrunning callee's array of size 7 by passing argument "bus" (which evaluates to 7) in call to "mtk_i2c_calculate_speed". 525 if (mtk_i2c_calculate_speed(bus, clk_src, speed, 526 &l_step_cnt, &l_sample_cnt)) 527 continue; 528 529 /* Disable the high speed transaction */ 530 bus_ctrl->ac_timing.hs = I2C_TIME_CLR_VALUE; ** CID 1518656: Memory - corruptions (OVERRUN) /src/soc/mediatek/common/i2c.c: 510 in mtk_i2c_speed_init() ________________________________________________________________________________________________________ *** CID 1518656: Memory - corruptions (OVERRUN) /src/soc/mediatek/common/i2c.c: 510 in mtk_i2c_speed_init() 504 } 505 506 bus_ctrl = &mtk_i2c_bus_controller[bus]; 507 508 for (clk_div = 1; clk_div <= max_clk_div; clk_div++) { 509 clk_src = I2C_CLK_HZ / clk_div; >>> CID 1518656: Memory - corruptions (OVERRUN) >>> Overrunning array of 280 bytes at byte offset 280 by dereferencing pointer "bus_ctrl". 510 bus_ctrl->ac_timing.inter_clk_div = clk_div - 1; 511 512 if (speed > I2C_SPEED_FAST_PLUS) { 513 /* Set master code speed register */ 514 if (mtk_i2c_calculate_speed(bus, clk_src, I2C_SPEED_FAST, 515 &l_step_cnt, &l_sample_cnt)) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

linux boot failure on 440bx/i82371eb [asus/p2b & p2-99] after [acpi/acpi.c: Reduce boilerplate] change
by Branden Waldner 22 Aug '23

22 Aug '23

Hi Keith Hui & list I just recently tested the latest coreboot ahead of the upcoming release and found that there had been a regression that broke [linux] booting with the disk controller timing out on the asus p2b. It broke with change 76127 [1] and was improved, but not fixed by 76321 [2]. Initially after the change it would hang at: "Write protecting kernel text and read-only data Run /init as init process" With the DSDT fix it would make it past there, but be unable to access the ide drive with the root filesystem. I haven't been able to look in to it much and don't know anything about acpi anyways, but I figured I would at least make sure to post logs. I might still be able to get it booted through usb or a pci ide/sata controller, but I haven't tried it, though it would probably help to get more diagnostic info. Branden Waldner [1] acpi/acpi.c: Reduce boilerplate https://review.coreboot.org/c/coreboot/+/76127 [2] acpi/acpi.c: Fix regression with DSDT https://review.coreboot.org/c/coreboot/+/76321

2 1

[coreboot - Feature #213] Have the bug tracker report activity to the mailing list
by Patrick Georgi 21 Aug '23

21 Aug '23

Issue #213 has been updated by Patrick Georgi. Related links updated Removed IRC as a target given the chaos we have around chat channels right now with libera.chat and matrix decoupling. Meanwhile, mailing list receives ticket updates ---------------------------------------- Feature #213: Have the bug tracker report activity to the mailing list https://ticket.coreboot.org/issues/213#change-1639 * Author: Patrick Georgi * Status: Resolved * Priority: Normal * Assignee: Patrick Georgi * Category: infrastructure * Start date: 2019-06-05 ---------------------------------------- This helps make the tracker more visible and therefore useful -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Feature #213] (Resolved) Have the bug tracker report activity to the mailing list
by Patrick Georgi 21 Aug '23

21 Aug '23

Issue #213 has been updated by Patrick Georgi. Subject changed from Have the bug tracker report activity to IRC and the mailing list to Have the bug tracker report activity to the mailing list Status changed from New to Resolved Related links updated ---------------------------------------- Feature #213: Have the bug tracker report activity to the mailing list https://ticket.coreboot.org/issues/213#change-1638 * Author: Patrick Georgi * Status: Resolved * Priority: Normal * Assignee: Patrick Georgi * Category: infrastructure * Start date: 2019-06-05 * Related links: Removed IRC as a target given the chaos we have around chat channels right now with libera.chat and matrix decoupling. ---------------------------------------- This helps make the tracker more visible and therefore useful -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot - Bug #309] crossgcc: Handle missing tarballs in download step
by Patrick Georgi 18 Aug '23

18 Aug '23

Issue #309 has been updated by Patrick Georgi. Assignee set to Felix Singer ---------------------------------------- Bug #309: crossgcc: Handle missing tarballs in download step https://ticket.coreboot.org/issues/309#change-1634 * Author: Patrick Georgi * Status: New * Priority: Normal * Assignee: Felix Singer * Start date: 2021-05-29 ---------------------------------------- We keep a copy of the tarballs used by crossgcc in coreboot releases in https://coreboot.org/releases/crossgcc-sources/, so we should fall back if a download failed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[PATCH v2 00/20] x86: efi: Fixes and improvements for coreboot
by Simon Glass 18 Aug '23

18 Aug '23

This little series fixes various bugs and annoyances in coreboot and coreboot64. With this both coreboot and coreboot64 start up and work reasonably well on Brya (x86 Chromebook) and U-Boot can boot common Linux distros. - Make coreboot64 debug UART start reliably - Avoid the long USB-init delay on startup - Correct the timer speed on coreboo64 - Fix a bootstd cros bug (will likely be squashed into another patch) - Fix the terribly slow console scrolling With v2 I have also brought in some lost x86 patches so they are all in one series. Changes in v2: - Update the malloc size too - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch Simon Glass (20): x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot x86: coreboot: Rearrange arch_cpu_init() x86: Set the CPU vendor in SPL x86: Allow APCI in SPL x86: coreboot: Look for DBG2 UART in SPL too x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 x86: coreboot: Drop USB init on startup x86: coreboot: Align options between coreboot and coreboot64 x86: coreboot: Enable VIDEO_COPY efi: x86: Correct the condition for installing ACPI tables x86: smbios: Add a Kconfig indicating SMBIOS-table presence x86: Record the position of the SMBIOS tables efi: x86: Use the installed SMBIOS tables efi: x86: Install the SMBIOS tables if present x86: coreboot: Record the position of the SMBIOS tables x86: doc: Move into its own directory x86: doc: Update summaries and add links x86: doc: Split out manual booting into its own file x86: doc: coreboot: Mention 64-bit Linux distros arch/x86/cpu/coreboot/coreboot.c | 16 +- arch/x86/cpu/x86_64/cpu.c | 7 + arch/x86/dts/coreboot.dts | 1 + arch/x86/include/asm/global_data.h | 1 + arch/x86/lib/coreboot/cb_sysinfo.c | 1 + arch/x86/lib/tables.c | 3 + configs/coreboot64_defconfig | 25 +-- configs/coreboot_defconfig | 21 +- doc/arch/index.rst | 2 +- doc/arch/x86/index.rst | 12 ++ doc/arch/x86/manual_boot.rst | 276 +++++++++++++++++++++++++++ doc/arch/{ => x86}/x86.rst | 295 ++--------------------------- doc/board/coreboot/coreboot.rst | 38 +++- drivers/serial/Kconfig | 2 +- drivers/video/coreboot.c | 12 ++ include/asm-generic/global_data.h | 8 + lib/Kconfig | 20 +- lib/efi_loader/Makefile | 4 +- lib/efi_loader/efi_setup.c | 20 +- lib/efi_loader/efi_smbios.c | 37 +--- 20 files changed, 447 insertions(+), 354 deletions(-) create mode 100644 doc/arch/x86/index.rst create mode 100644 doc/arch/x86/manual_boot.rst rename doc/arch/{ => x86}/x86.rst (64%) -- 2.42.0.rc1.204.g551eb34607-goog

1 11

Add ACPI PLD to new GFX (igpu) devices for Brya models
by Won Chung 17 Aug '23

17 Aug '23

1 0

Trouble booting with mt8183
by Jared Baur 15 Aug '23

15 Aug '23

I am looking for some advice for configuring coreboot with a uImage fit payload for an mt8183 chromebook (Kukui Fennel)? I have said fitimage, I've modified the memlayout for the mt8183 board similar to https://github.com/coreboot/coreboot/commit/22e605c2c06f553b98131a87b634709… so that the fitimage fits in the cbfs and has space to load, and coreboot successfully builds. I've also enabled a bunch of debug settings for coreboot printing to serial. When flashing the ROM and rebooting, the serial console doesn't show anything past bootrom messages like so: ``` [DL] 00000000 00000000 010701 F0: 102B 0000 F3: 1006 0033 [0200] F3: 4001 00E0 [0200] F3: 0000 0000 V0: 0000 0000 [0001] 00: 1027 0002 01: 0000 0000 BP: 0C00 0251 [0000] G0: 1182 0000 EC: 0004 0000 [0001] S7: 0000 0000 [0000] CC: 0000 0000 [0001] T0: 0000 00DB [000F] Jump to BL ``` I am happy to post any configuration that would be helpful. I am hoping to just get some serial output from coreboot at this point in time, regardless of the payload.

3 2

Haswell-E 2011-3 support
by Sid_key 14 Aug '23

14 Aug '23

Can someone help to implement 2011-3 support in coreboot? There are quite many 2011-3 chinese boards with broken bios, would be good to run coreboot on them to fix most problems. For example: Huananzhi X99 QD4 (Haswell-E/Broadwell-E 2011-3 CPU, B85/Q87/Z87 chipset) Huananzhi X99 BD4 (Haswell-E/Broadwell-E 2011-3 CPU, B85/Q87/Z87 chipset) I tried to make coreboot dt and to try booting Haswell-E over Haswell drivers, but faced FF postcode: dt: https://github.com/MrArtemSid/coreboot_huananzhi_x99-series/tree/staging1 haswell-e changes: https://github.com/MrArtemSid/coreboot/tree/haswell-e

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