coreboot July 2022

coreboot@coreboot.org

33 participants
36 discussions

ASUS P8ZZ7-V i7-3770 >16GB RAM: SPD CRC failed
by Nico Rikken 09 Aug '22

09 Aug '22

I'm in the process of building a new computer based on the P8ZZ7-V board with a i7-3770 CPU. I am running into a odd behavior the CPU_LED is blinking when using more than 2 8GB RAM modules. This occurs with both the vendor BIOS and the Coreboot build. A friend has the same configuration (mainboard, cpu, 4x8GB memory) which is working just fine. Which make me wonder why my setup is failing. We have gathered serial output (below) to diagnose the issue. Most notable is that for the failing memory configurations the '[DEBUG] Stored timings CRC16 mismatch.' message is returned, after which `[DEBUG] SPD probe channel0, slot1` is triggered, which seems to fail: `ERROR: SPD CRC failed!!!` The resulting looping sequence in the logs: <start of loop> [NOTE ] coreboot-4.17 Fri Jun 3 03:10:05 UTC 2022 bootblock starting (log level: 7)... [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x710000. [DEBUG] FMAP: base = 0xff800000 size = 0x800000 #areas = 4 [DEBUG] FMAP: area COREBOOT found @ 710200 (982528 bytes) [INFO ] CBFS: mcache @0xfeff0e00 built for 13 files, used 0x2dc of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x80 size 0x14c38 in mcache @0xfeff0e2c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 43 ms [NOTE ] coreboot-4.17 Fri Jun 3 03:10:05 UTC 2022 romstage starting (log level: 7)... [DEBUG] SMBus controller enabled [DEBUG] Setting up static northbridge registers... done [DEBUG] Initializing Graphics... [DEBUG] Back from systemagent_early_init() [INFO ] Intel ME early init [INFO ] Intel ME firmware is ready [DEBUG] ME: Requested 0MB UMA [DEBUG] Starting native Platform init [DEBUG] DMI: Running at X4 @ 5000MT/s [DEBUG] FMAP: area RW_MRC_CACHE found @ 700000 (65536 bytes) [DEBUG] Stored timings CRC16 mismatch. [DEBUG] ECC supported: no ECC forced: no [INFO ] ECC RAM unsupported. [DEBUG] SPD probe channel0, slot0 [DEBUG] Revision : 11 [DEBUG] Type : b [DEBUG] Key : 2 [DEBUG] Banks : 8 [DEBUG] Capacity : 4 Gb [DEBUG] Supported voltages : 1.5V [DEBUG] SDRAM width : 8 [DEBUG] Bus extension : 0 bits [DEBUG] Bus width : 64 [DEBUG] FTB timings : yes [DEBUG] Optional features : DLL-Off_mode RZQ/7 RZQ/6 [DEBUG] Thermal features : PASR ext_temp_range [DEBUG] Thermal sensor : no [DEBUG] Standard SDRAM : yes [DEBUG] Rank1 Address bits : mirrored [DEBUG] DIMM Reference card: B [DEBUG] Manufacturer ID : 9e02 [DEBUG] Part number : CML16GX3M2A1600C [DEBUG] XMP Profile : 1 [DEBUG] Max DIMMs/channel : 1 [DEBUG] XMP Revision : 1.3 [DEBUG] Requested voltage : 1500 mV [DEBUG] XMP profile supports 1 DIMMs, but 2 DIMMs are installed. [WARN ] XMP maximum DIMMs will be ignored. [INFO ] Row addr bits : 16 [INFO ] Column addr bits : 10 [INFO ] Number of ranks : 2 [INFO ] DIMM Capacity : 8192 MB [INFO ] CAS latencies : 6 9 [INFO ] tCKmin : 1.250 ns [INFO ] tAAmin : 11.250 ns [INFO ] tWRmin : 15.000 ns [INFO ] tRCDmin : 11.250 ns [INFO ] tRRDmin : 7.500 ns [INFO ] tRPmin : 11.250 ns [INFO ] tRASmin : 30.000 ns [INFO ] tRCmin : 50.625 ns [INFO ] tRFCmin : 260.000 ns [INFO ] tWTRmin : 7.500 ns [INFO ] tRTPmin : 7.500 ns [INFO ] tFAWmin : 37.500 ns [INFO ] tCWLmin : 10.000 ns [INFO ] tCMDmin : 2 [DEBUG] channel[0] rankmap = 0x3 [DEBUG] SPD probe channel0, slot1 [DEBUG] ERROR: SPD CRC failed!!! [DEBUG] Revision : 11 [DEBUG] Type : b [DEBUG] Key : 2 [DEBUG] Banks : 8 [DEBUG] Capacity : 4 Gb [DEBUG] Supported voltages : 1.5V [DEBUG] SDRAM width : 8 [DEBUG] Bus extension : 0 bits [DEBUG] Bus width : 64 <end of loop, restarting Coreboot> Mainboard: ASUS P8ZZ7-V CPU: i7-3770 RAM 4x8GB DDR3 Corsair CML16GX3M2A1600C9 Does anybody have advise what could be causing the `SPD CRC failed!!!` error? The next idea is to replace the CPU as the memory seems fine to swap around in most configurations. Other ideas are the motherboard, or something interfering with the readout. Is there an easy way to perhaps hardcode my way out of it for now, knowing the RAM will remain there once configured so I could even doe a custom Coreboot build? Best, Nico

4 7

Reconsidering the Gerrit submission strategy
by Patrick Georgi 08 Aug '22

08 Aug '22

Hi everybody, I was recently made aware that Gerrit now supports adding metadata to commit messages in the "rebase" strategy. The "cherry-pick" strategy that we're using has been chosen over everything else primarily due to this capability. Some details: Gerrit supports different ways of committing changes into branches when developers submit them, with different effects on which changes are considered ready and how they show up in the commit history. The two main contenders are "cherry-pick" and "rebase always". Both create a linear history (unlike some "merge" strategies that can create merge commits. Both add metadata to the commits, all that "Reviewed-on", "Reviewed-by" etc in the commit message. Cherry-pick considers every change on Gerrit on its own. Even if you push a patch train of 50 commits, it allows submitting commit #49 individually. That gives some flexibility (if these commits are truly independent) but also creates risk: if changes are merged out of order, we might break the tree with otherwise perfectly good commits, for example when a new API is used that is only added by a previous commit. Rebase always considers patch trains: To submit commit #49, the commit itself and all its 48 ancestors need to be ready for submission. It becomes a one-click operation in the UI and ordering is honored. On the other hand, picking an individual commit is a manual operation now (cherry-pick to become its own patch train, push, re-review). Speaking of UI, depending on the strategy the "readiness" marker in the UI changes behavior, too: With "cherry-pick", each commit is compared against the branch individually, with a "merge conflict" notification if the commit on its own would fail to merge. With "rebase always" the entire patch train up to that point is considered. It's a matter of trade-offs, but given that "rebase always" can now add the metadata that was the deal breaker for anything but cherry-pick back in the day, I wanted to know how y'all feel about changing or keeping the submission strategy. David proposed that we could try out "rebase always" for a while (maybe a month) to see how it feels. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Liana Sebastian

6 19

Servers?
by Jeremy Hansen 03 Aug '22

03 Aug '22

I’ve looked at the list of hardware vendors. I see System76 listed but when I asked System76, they claim it’s not supported. “Support” I understand, but does it work? Maybe using their System76 firmware? Any other server vendors I should consider? I know Purism offers servers as well. Anyone else? Thank you -jeremy

4 6

Custom coreboot installer and license
by Felix Freeman 28 Jul '22

28 Jul '22

Hello people, This is a question and kind-of an announcement. I'm just a few days ahead of the official opening of an online store that will sell corebooted laptops in Chile. For this purpose I've created a custom coreboot installer, and, since it's useful to me, I thought it could be useful for other people and uploaded it to the tubes. Code is here: https://git.hacktivista.org/hackware-boot This software is not a fork of coreboot, but an automated compiler/installer of coreboot that of course uses its tools. These are not shipped with it, but downloaded from git or the Debian repos. In case you're wondering what's different from Skulls or osboot: It includes several security enhacements through the combination of a custom GRUB config and the usage of a custom tool called hwbtool. It also ships all available payloads that libgfxinit supports by default. I built it because I needed to automate the installation for my store's laptops. Here the difficult part: I want to publish it (it's currently published indeed) under license that's incompatible with the GPL. The question is, is this legal? Also distributing the result of such combination? Examples of such usage can be found here: https://git.sr.ht/~hacktivista/hackware-boot/tree/main/item/x230t/flash_spi… https://git.sr.ht/~hacktivista/hackware-boot/tree/main/item/hwbtool#L167 As far as I understand I'm just using a software in a separate program, not linking nor intending to distribute derivatives of coreboot project programs under other license. But I thought it's better to ask. Please refrain from asking out of topic questions regarding the software or the license on this thread. I know it might be a hot topic for some people and will happily answer via private email or even on a completely new thread here on this same list. Thanks a lot, Felix Freeman

3 6

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

28 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

camelback mountain CRB graphics support + UefiPayload
by Moorthi M.s 28 Jul '22

28 Jul '22

Hi, We are developing coreboot along with UefiPayload for camelback mountain crb. The processor doesn't have the inbuilt graphics support. Add-on graphics card is used in the CRB. Graphics is initialised and working with SeaBios as payload. But when we configured to use UefiPayload, shell and boot options are not visible in graphics display. A cursor is blinking in the display and the shell is visible in the UART console. Is there any configuration required for UefiPayload with respect to graphics? Thanks & regards, Moorthi

1 0

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

27 Jul '22

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

2025

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