coreboot

coreboot@coreboot.org

17 participants
39654 discussions

[coreboot - Bug #312] (Resolved) [Tianocore] gcc11: UefiPayloadPkg build fails
by Sean Rhodes 26 Jul '22

26 Jul '22

Issue #312 has been updated by Sean Rhodes. Status changed from In Progress to Resolved Fixed upstream and MrChromebox fork ---------------------------------------- Bug #312: [Tianocore] gcc11: UefiPayloadPkg build fails https://ticket.coreboot.org/issues/312#change-1051 * Author: Patrik Tesarik * Status: Resolved * Priority: Normal * Assignee: Matt DeVillier * Start date: 2021-06-23 ---------------------------------------- With gcc11 the build of UefiPayloadPkg fails because the brotli code fails. This bug is fixed 'already' today (after 3 Months) in upstream brotli: https://github.com/google/brotli/pull/893 And the issue was already discussed in upstream EDK2, but it seems to me that the submodule reference(?) not fixed yet. https://bugzilla.tianocore.org/show_bug.cgi?id=3417 However, this ticket should make the maintainer of https://github.com/MrChromebox/edk2 aware that a pull of that brotli fix is trickles down somehow. Not sure what's the right way to go here. -- 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

Re: [flashrom] Intel Kaby Lake Y w/ iHDCP2.2 Prem ERASE_FAILED
by Angel Pons 22 Jul '22

22 Jul '22

Hi Craft, Looks like you only replied to me, so the mailing list hasn't received your message. In the future, remember to use "Reply to all" so that the mailing list also gets a copy of your message. On Fri, Jul 22, 2022 at 12:10 AM J. Craft <djcraft(a)gmail.com> wrote: > > Appreciate you getting back to me, Angel. Write Protection had been disabled, but I hadn't rebooted for it to take effect. :) Yes, a reboot is needed for the write-protect settings to be updated. > However, after rebooting and flashing properly, it appears that there is a bug in the bios that causes an ACIP BIOS ERROR when trying to install Windows 10. Any suggestions on what to do in this situation? Hmmm, https://www.reddit.com/r/chrultrabook/comments/aufp1q/getting_started_read_… says that Nocturne should be able to boot Windows... I presume it's a regression of some sort. > Kind regards, > Craft > > On Thu, Jul 21, 2022 at 3:59 AM Angel Pons <th3fanbus(a)gmail.com> wrote: >> >> Hi, >> >> On Thu, Jul 21, 2022 at 2:23 AM J. Craft <djcraft(a)gmail.com> wrote: >> > >> > Let me know if there's anything else needed and what might be suggested in this situation. >> >> *snip* >> >> > 0x84: 0x89ef09d0 PR0: Warning: 0x009d0000-0x009effff is read-only. >> >> flashrom errors out because this region is read-only. I'm pretty sure >> that's the MRC cache region. You have to disable write-protect by >> either removing the "WP screw" or by disconnecting the internal >> battery, then you will be able to flash coreboot successfully. >> >> > Good, writing to the flash chip apparently didn't do anything. >> >> You can safely reboot. >> >> Best regards, >> Angel Best regards, Angel

1 0

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

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