coreboot July 2022

coreboot@coreboot.org

33 participants
36 discussions

Intel Quark - a quick update
by Andy Pont 20 Jul '22

20 Jul '22

Thanks to the generosity of members of the list there are two Intel Galileo boards, a Gen 1 and Gen 2, on their way to me which should arrive towards the end of the month. As soon as they get here I will start testing the various configs to see what works and what is broken. -Andy.

7 10

[UPDATE] GSoC 2022 - Console via SMBus
by Ahamed Husni 20 Jul '22

20 Jul '22

Hi all, I am Husni. I am a coreboot GSoC contributor this year.We are in the sixth week of the coding period. I am working under the mentorship of Tim Wawrzynczak and Raul Rangel. My project is to log the coreboot console messages via SMBus. I am using a Gigabyte H61M-S2PV mainboard for development. I have written a blog about my progress. Please read it and let me know your feedback. https://medium.com/@husnifaiz/coreboot-console-via-smbus-introduction-38273… Regards, Husni Faiz.

1 0

AMD Lenovo G505S : default screen when using a MiniPCIe-to-PCIe discrete GPU ?
by Ivan Ivanov 20 Jul '22

20 Jul '22

Good day! My friend - also a G505S coreboot'er! - is using the "G505S discrete GPU" not-merged-yet patch series from https://review.coreboot.org/c/coreboot/+/58745 , which successfully get a G505S discrete GPU working (). However, trying to get a better GPU performance, he's connected an external discrete AMD RX470 GPU to this laptop's MiniPCIe port (originally meant for WiFi module) using a MiniPCIe-to-PCIe adapter. So his G505S has three GPUs: internal integrated HD-8650G, internal discrete (HD-8570M or R5-M230) and external discrete. For unknown reasons, G505S coreboot choses this external discrete GPU as a primary video output, ignoring the laptop's screen. Please, could you advise where in coreboot we could set up the default video output priority for this AMD AGESA board? Any idea where to dig? Best regards, Ivan

1 0

Re: Coreboot and open firmware RX590 efforts?
by Mike Banon 19 Jul '22

19 Jul '22

Hi there Nico, Thank you for your great summary of research, I'm going to CC it to a coreboot mailing list just in case someone wants to add more findings... I'm not aware of any people currently working on the OpenAtom project, or of any advances since the last activity long ago. Perhaps it's because 1) AtomDis utility output already gives quite a good idea of what functions/data are inside the AtomBIOS blob to get enough confidence there are no backdoors, and 2) if I remember correctly OpenAtom didn't promise any improvements of user experience (extra features etc.), + the overclocking/underclocking is already achievable by modding the AtomBIOS binary (just need to be careful around the voltages). So, the people would be interested in OpenAtom mostly for software freedom reasons (aka "FSF guys"), but probably it's not enough as we see. > Would you still recommend RX590 as being the best graphics card suitable for open firmware development? It'd be wonderful from the tech specs point of view - but the development won't be easiest, seeing that AtomDis utility gives a larger % of meaningful output for i.e. HD-8650G / HD-8570M / R5-M230 AtomBIOS blobs of coreboot-supported Lenovo G505S. Last commit to AtomDis was in 2011, it hasn't been updated since that and therefore starts having some trouble deciphering the newer AtomBIOSes (such as RX590). Although having an open firmware for a prominent RX590 would be a nice end goal, it would be wiser to start with the G505S blobs, especially since it seems the OpenAtom project has already been digging for the HD-8650G of G505S. What is also good: while developing for G505S it would be easier to try the custom ROMs: using a cbfstool utility from a coreboot repository, simply remove the old AtomBIOS blob from your coreboot.rom and add a new one (may even make a custom script, looking at csb_patcher.sh - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Introduction ), then flash the updated coreboot.rom into your G505S using a flashrom's internal mode. If you don't see any image on a screen (in case of a bad AtomBIOS), somehow boot to Linux (need to remember a SeaBIOS drive letter) and connect to G505S from another PC using SSH to try a coreboot.rom with another AtomBIOS blob. > One option I was considering is to extract the ROM and add it to cbfs so I wouldn't need SeaBIOS. Without the AtomBIOS blob I think your GPU won't work at all, no matter what your payload selection is. If you have any other questions, we will be happy to help you. On Sun, Jul 17, 2022 at 4:25 PM Nico Rikken <nico(a)nicorikken.eu> wrote: > > Hi Mike, > > Sorry for circumventing the Coreboot mailinglist, but it seems you have posted most recently on this subject. Happy to go via the mailinglist, but I didn't know what to write in a general way. > > I'm building a new computer based on the P8Z77-V. I'm considering adding a dedicated graphics card to drive larger display resolutions and have more GPU power for photo editing. I investgated what the current state of openness is. I also posted on Reddit: https://www.reddit.com/r/coreboot/comments/w080ng/requirements_for_adding_r… > > I read the history on this subject including your comments over the years: > - RX590 being the best before AMD PSP introduction > https://www.mail-archive.com/coreboot@coreboot.org/msg54703.html > - Lack of PSP is required to enable open source firmware like openAtom https://www.reddit.com/r/Amd/comments/ex04ld/do_the_latest_amd_cards_includ… > - There is/was some effort to open up Radeon cards with OpenAtom, also mentioned in https://www.reddit.com/r/Amd/comments/ex04ld/do_the_latest_amd_cards_includ… > - There was an interest to work on it for the GSoC 2015 https://www.mail-archive.com/coreboot@coreboot.org/msg44492.html > > It seems all current efforts to further open AMD GPU firmware have stalled. > > One option I was considering is to extract the ROM and add it to cbfs so I wouldn't need SeaBIOS. The again I saw your post about the trouble of dealing with extracting certain ROMs: https://www.mail-archive.com/coreboot@coreboot.org/msg49637.html But I think that won't be so much of an issue in this case. > > So to summize my question: where do we stand with open GPU firmware on X86? Would you still recommend RX590 as being the best graphics card suitable for open firmware development? Are there still people working on this? > > Best, > Nico -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 1

[coreboot - Feature #404] (New) Support board variants in board-status
by Patrick Georgi 17 Jul '22

17 Jul '22

Issue #404 has been reported by Patrick Georgi. ---------------------------------------- Feature #404: Support board variants in board-status https://ticket.coreboot.org/issues/404 * Author: Patrick Georgi * Status: New * Priority: Normal * Category: infrastructure * Target version: none * Start date: 2022-07-17 ---------------------------------------- The board-status tool predates our concept of board variants, which we now use extensively. This means that the board list on https://coreboot.org/status/board-status.html is always incomplete, so add support for parsing out board variants, showing them in the board list and properly attributing board-status data to variants. -- 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

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

15 Jul '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1490681: Memory - illegal accesses (OVERRUN) /src/soc/intel/meteorlake/fsp_params.c: 109 in fill_fsps_lpss_params() ________________________________________________________________________________________________________ *** CID 1490681: Memory - illegal accesses (OVERRUN) /src/soc/intel/meteorlake/fsp_params.c: 109 in fill_fsps_lpss_params() 103 } 104 105 max_port = get_max_gspi_port(); 106 for (i = 0; i < max_port; i++) { 107 s_cfg->SerialIoSpiCsMode[i] = config->serial_io_gspi_cs_mode[i]; 108 s_cfg->SerialIoSpiCsState[i] = config->serial_io_gspi_cs_state[i]; >>> CID 1490681: Memory - illegal accesses (OVERRUN) >>> Overrunning array "gspi_dev" of 2 4-byte elements at element index 2 (byte offset 11) using index "i" (which evaluates to 2). 109 s_cfg->SerialIoSpiMode[i] = is_devfn_enabled(gspi_dev[i]) ? 110 config->serial_io_gspi_mode[i] : 0; 111 } 112 113 max_port = get_max_uart_port(); 114 for (i = 0; i < max_port; i++) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

I may have misconfigured my Coreboot ROM, what did I do wrong?
by Tristan Young 15 Jul '22

15 Jul '22

Today, I internally flashed a Coreboot ROM that I partially built myself to the motherboard of my ThinkPad T440p. But when I restarted my computer, it started constantly beeping, and turning it off and on didn't change that result. Luckily, I fixed it by flashing my previous Coreboot BIOS (SeaBIOS) to the top 4 MiB chip externally using my Raspberry Pi. But there are some things that were different in the build configuration for the newer BIOS, such as trying to use a bootorder file to make SeaBIOS try to boot from my HDD first instead of my CD/DVD drive, as well as setting the options to clear the DRAM on each boot. I also didn't use the cleanbuild option after different build attempts for the newer BIOS. Should I send my .config file so that you can tell if any of the config settings or combinations of them that I chose wouldn't work on my specific model of ThinkPad? And should I also send over an actual 4MiB binary of the BIOS I flashed that didn't work?

3 2

Measured boot and TPM standards
by Krystian Hebel 13 Jul '22

13 Jul '22

TL;DR: why doesn't vboot follow existing standards and tries to create its own instead? [XKCD] During our adventures with enabling coreboot port for Talos 2 we got to the point of enabling TPM, and with it, measured boot. coreboot's part worked without too many issues other than those resulting from assumptions about endianness, Skiboot's (payload) - not so much, at least it seemed that way. Hardware access worked after adding a driver implementation for new module, but it failed to parse event log and in result disabled TPM. Skiboot (payload) expects Agile format [TPM20] of event log, while vboot provides its own format [VBOOT], compatible with neither Agile nor legacy format used by TPM 1.2 [TPM12]. Even worse, address of this log is written to TCPA ACPI table, from which it is read and parsed (or at least tried) by kernel as TPM 1.2 format [LINUX]. At first I thought custom format was developed to add support for SHA-256, but only TPM 2.0 uses it, and it already has new format, capable of storing bigger hashes. Which brings up the question: why use own format that nothing else knows how to parse? Are there any reasons against switching to Agile format? AFAICT only cbmem can parse the current form. Another problem is PCR assignments: on one hand, [VBOOT] says that "coreboot uses the SHA-1 or SHA-256 hash algorithm depending on the _TPM specification_ for measurements", and then doesn't follow any existing specification, even though both families have predefined and mostly compatible with each other uses for PCRs (section 3.3.3 in [TPM12] and 3.3.4 in [TPM20]). Measuring GBB flags to PCR0 is dubious since PCR0 is usually used for code at or near RTM. Speaking of RTM, what the heck with those SRTM/DRTM definitions? When reading it, I got the feeling that there was misunderstanding and someone thought that S stands for software, D - discrete, although expansions of those abbreviations in the vboot documentation are correct. [DRTM] definitely isn't able to start from IBB, as is suggested in that documentation. We would like to work on mentioned issues, both implementation and documentation. Before we invest time in it, we would like to know whether there are any reasons that would require keeping current form, any caveats or design decisions we've missed. [XKCD] https://xkcd.com/927/ [TPM20] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… [VBOOT] https://doc.coreboot.org/security/vboot/measured_boot.html#tcpa-eventlog [TPM12] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [LINUX] https://github.com/torvalds/linux/blob/master/drivers/char/tpm/eventlog/acp… [DRTM] https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture… -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com

2 1

[coreboot - Bug #388] (New) denverton_ns: crash when starting postcar
by King Sumo 13 Jul '22

13 Jul '22

Issue #388 has been reported by King Sumo. ---------------------------------------- Bug #388: denverton_ns: crash when starting postcar https://ticket.coreboot.org/issues/388 * Author: King Sumo * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2022-06-15 * Affected versions: 4.17, master * Affected hardware: intel harcuvar * Affected OS: all ---------------------------------------- Postcar is crashing when using configured to teardown the CAR using FSP. Therefore the bug may occur in other platforms than denverton as well. See also the discussion here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2JC3… The bug was instroduced by the following change: * 5315e96abf arch/x86/postcar: Use a separate stack for C execution Attached is a patch with the bug fix. ---Files-------------------------------- fix-postcar-crash.patch (822 Bytes) -- 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

2 2

POST codes and PCI Post card
by Pedro Erencia 11 Jul '22

11 Jul '22

I've noticed that POST codes are sent very early. In x86 the first code is sent just after storing the bist. Are codes sent so early useful? They are sent ages before any PCI configuration. Is there any guarantee of them reaching a PCI POST card?

5 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2022