coreboot September 2019

coreboot@coreboot.org

52 participants
37 discussions

Coreboot Payload.
by nisingh＠infinera.com 16 Sep '19

16 Sep '19

Hi, I am using "GRUB-2" as a direct payload for a Denverton based implementation. Is it possible to invoke a payload which is programmed as a separate Image (not as a part of cbfs coreboot image) within a BOOT flash ? If not, then what are the areas do we need to modify in a state-machine to implement the same ? Thanks in advance, Nitin.

1 1

TPM measurements with UefiPayloadPkg EDK2
by Michal Zygowski 16 Sep '19

16 Sep '19

Hello, Is anybody aware what would be the effort to include TPM measurements in UefiPayloadPkg? The drivers for TPM seem to be already present for DXE in SecurityPkg and a function to measure the data with TPM and logging. However it does not seem the payload package uses them. Also I assume that PEI and DXE cannot be measured before execution with current implementation, because drivers are available late in DXE. If my understanding is correct, if I would use vboot+measured boot in coreboot the whole payload is measured still, but the trust chain would be broken after SEC. Can anybody tell if I am wrong? Best regards, -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com

3 4

F2A85-M - amdgpu fails, integrated GPU works fine
by bogdal.grzegorz＠tutanota.com 14 Sep '19

14 Sep '19

Hello, is there a known solution to my problem? After flashing the coreboot and booting the computer, I can use the integrated GPU through VGA, but initialization of amdgpu fails and DisplayPort external GPU isn't recognized by the system. It appears in lspci, though. I can provide better logs tommorow, but that's part of what appeared in dmesg: amdgpu get bioss error acpi vcft image header truncated amdgpu kernel bo map failed [...] error -22 amdgpu_vram_scratch_init failed [...] error -22 fatal error in GPU initialization My specs: F2A85-M A10-6800k with integrated Radeon HD 8670D AMD RX 570 a external GPU I've used coreboot with Seabios If there are some known solutions to the problem, please let me know. Otherwise I could use a list of files and command outputs I should provide to give better information. Thank you for your help.

5 6

Web site revamp
by Timothy Pearson 13 Sep '19

13 Sep '19

I'd like to open discussion on a revamp of the text on the main coreboot.org Web site. I had a brief discussion on IRC recently with some basic agreement from a couple of people that the text on that page has likely bitrotted enough compared to the current status and goals of coreboot to no longer be useful. I bring this up due to confusion in less technical circles that I've been having to correct over the past week or so. Specifically, these statements taken in isolation: "Fast, secure and flexible OpenSource firmware" "coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology." present a very different picture than the reality of the project at the moment for modern platforms. If people are not aware of the ME, PSP, AGESA, FSP, BinaryPI, and a host of other proprietary components, they naturally take the statements above at face value and assume that installing coreboot on their machine (or paying for coreboot support for their system) allows them to replace the entire proprietary firmware with an auditable, fast, secure OpenSource firmware. As those of us dealing with the reality of modern x86 and ARM platforms understand more fully, this could not be farther from the truth. One of the problems as I see it is that coreboot is really two different projects with two different goals right now, under the same label. One is the native init project, which at the moment is only viable for RISC-V, POWER, and certain ARM SoCs. The other is the open glue project for vendor binaries, which is not well understood at this time among much of the open source community, but seems to have significant support from vendors like Google, Intel, and AMD. Complicating matters, the trademark "coreboot" is currently known to some members of the public as a trusted (albeit limited in compatibility) fully open source replacement for their exiting board level firmware. When the word "coreboot" is used, very few people think of the glue project. Do we want to dilute / shift the coreboot trademark / branding to the glue part of the project, or do we want to somehow reserve "coreboot" for the native init part of the project? I don't have an answer here, I'm just trying to state the facts as I currently see them for further discussion. I would propose the following changes, and welcome discussion on these topics: The heading could read something like "Flexible, open source frameworks for system firmware" and the detailed description could read "coreboot is an extensible firmware platform that aims to provide a minimal boot environment for modern computers and embedded systems. As an Open Source project it provides a flexible framework for insertion of vendor specific firmware modules, and on open ISA platforms aims to provide a fully open, auditable boot process with maximum control over the technology." Thoughts? -- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com

10 26

Managing device settings after flashing coreboot
by duc01k＠disroot.org 08 Sep '19

08 Sep '19

Hi, Does flashing coreboot/tianocore payload change the settings options available in the BIOS setup of a device? I'm talking about the device/hardware config options (e.g. enable/disable Secure Boot, enable/disable hardware devices etc.) that can be accessed pre-boot by pressing a dedicated key. If it does make changes to this, is it possible to know in advance which options will be available after flashing? I looked around and couldn't find anything relating to this topic. Perhaps flashing coreboot doesn't have any effect at all on BIOS setup options, I'm not sure. Thanks.

3 5

Commit message in Coreboot
by himanshu sahdev 07 Sep '19

07 Sep '19

Hi, I have seen some patches on gerrit, found "BUG=b:#bug_no." in the commit message. example: CB:35233 <https://review.coreboot.org/c/coreboot/+/35233> I am not able to find this bug id and its significance with the particular commit. Also, have been through the https://ticket.coreboot.org/issues, it also doesn't have those bug_no. I want to know if coreboot uses some other bug tracking system I am unaware of or is it just that the bug id depends on some external/confidential/vendor_specific tracking system? Next, what if I want to provide the bug=# in commit message which referred an issue on https://ticket.coreboot.org/issues? Should I write bug=T220 or bug=b:220 for bug no 220? *HIMANSHU SAHDEV* *bio: *https://in.linkedin.com/in/himanshu-sahdev *mobile: **9560957360*

2 2

Fwd: Re: Web site revamp
by Matt B 03 Sep '19

03 Sep '19

---------- Forwarded message --------- From: Matt B <matthewwbradley6(a)gmail.com> Date: Tue, Sep 3, 2019 at 1:05 AM Subject: Re: [coreboot] Re: Web site revamp To: David Hendricks <david.hendricks(a)gmail.com> Building on that, postmarketOS (which in some ways feels like a weird sister project to coreboot?) does this thing where they display 3 random supported phones on the homepage every time it loads. Doing that with supported boards, with some feature bullet-points underneath might look real spiffy. -Matt On Mon, Sep 2, 2019 at 9:13 PM David Hendricks <david.hendricks(a)gmail.com> wrote: > It would be nice if we can more prominently show libre-friendly systems > with coreboot. There have been some ideas proposed about how to do this, > for example this one by Carl-Daniel: > https://mail.coreboot.org/pipermail/coreboot/2010-October/060894.html > > Now that our infrastructure is much better than it was nearly a decade > ago, maybe we can reconsider some ideas that would have previously involved > a lot of tedious manual labor. For example, perhaps a matrix of boards and > blob dependencies can be auto-generated using `make what-jenkins-does` (or > something similar) and looking at the resulting .config file for each > board. From there, boards with no blob dependencies (at least no > 3rdparty/{blobs,fsp} dependencies) can be put on a list of "libre > platforms" linked from the homepage. > > Just thinking out loud... > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2019