coreboot

coreboot@coreboot.org

6 participants
39686 discussions

Re: ASUS P8ZZ7-V i7-3770 >16GB RAM: SPD CRC failed
by Kevin Keijzer 27 Jul '22

27 Jul '22

I have this exact same board (P8Z77-V) with the exact same CPU (i7-3770), the exact same DIMM's (4x 8GB CMZ16GX3M2A1600C9), and the same coreboot version (4.17), and it's working fine for me for months now. When I leave CONFIG_NATIVE_RAMINIT_IGNORE_XMP_MAX_DIMMS to its default of n, the memory is clocked at 1333MHz (as the XMP profile says you may only use one DIMM per channel), but when I set CONFIG_NATIVE_RAMINIT_IGNORE_XMP_MAX_DIMMS=y, it's clocked at 1600MHz. In both cases the system works perfectly well with 32GB RAM. (I tested 1333MHz in the beginning, and later switched to 1600MHz.) So I don't understand why it wouldn't work with another identical setup. The logs show that the system reboots shortly after "SPD probe channel0, slot1". It seems to fail halfway during the probe, likely resulting in "Stored timings CRC16 mismatch." during the next try. I've never tested the vendor BIOS on my board, so I have no idea if it should work there or not. So why does the board reset halfway during an SPD probe? Could this be a faulty memory controller or something we're overlooking? -- With kind regards, Kevin Keijzer

1 0

[coreboot - Bug #332] (Resolved) I selected payload Tianocore Upstream (not UEFIPayload) but its still using MrChromebox UEFIPayload files?
by Sean Rhodes 26 Jul '22

26 Jul '22

Issue #332 has been updated by Sean Rhodes. Status changed from Response Needed to Resolved The old makefile used to add upstream as a remote, which is why it looks like it's using MrChromebox. It does, and always has, built from the correct repo. ---------------------------------------- Bug #332: I selected payload Tianocore Upstream (not UEFIPayload) but its still using MrChromebox UEFIPayload files? https://ticket.coreboot.org/issues/332#change-1052 * Author: xinhua wang * Status: Resolved * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- make V=1 -d Cloning Tianocore from Git Reaping winning child 0x559abd8daf20 PID 142498 git clone --branch uefipayload_202107 https://github.com/mrchromebox/edk2 /mnt/cb-trying-upstream/coreboot/payloads/external/tianocore/tianocore; \ cd /mnt/cb-trying-upstream/coreboot/payloads/external/tianocore/tianocore; \ git remote add upstream https://github.com/tianocore/edk2 Live child 0x559abd8daf20 (/mnt/cb-trying-upstream/coreboot/payloads/external/tianocore/tianocore) PID 142499 Cloning into '/mnt/cb-trying-upstream/coreboot/payloads/external any ideas, thx -- 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 #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

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