coreboot January 2021

coreboot@coreboot.org

46 participants
35 discussions

One QCLK is half a full clock cycle (tCK)
by Angel Pons 12 Jan '21

12 Jan '21

Hi list, I'm writing this email because there's one thing I always forget about. Now that I am sure about it, I would like to write it down somewhere so that I can't forget about it anymore. Anyway, that one thing is: On Intel memory controllers, one QCLK (Quadrature Clock) equals one half of a full clock cycle, i.e. tCK / 2. Best regards, Angel, the tormentor of memory controllers

1 0

Help locating BIOS flash IC on a not yet supported mini PC board
by reddunur＠online.de 12 Jan '21

12 Jan '21

Hello coreboot community, as an open source fan I recently get to know coreboot and really like the idea behind. Sadly I bought my computer HW before learning more on libre friendly hardware that respects your freedom. Now I try to figure out if I could do one or both of a) installing coreboot , b) remove /disable ME from my zotac mini PC, or I had to look out for already supported HW to do so. I use a zotac CI 640 nano fanless mini PC with kaby lake Intel Core i5-8250U and intel UHD grafics. https://www.zotac.com/product/mini_pcs/ci640-nano#spec In the process of cleaning FW I got stuck while figuring out, what is the relevant flash IC storing the bios. Form running linux I could read an 8MB flashrom with flashrom tool and internal programmer. While reading, flashrom reported chipset "Intel Kaby Lake U w/ iHDCP2.2 Prem." and gave the warning "SPI configuration lockdown activated". The programmer flashchip was reported as "Opaque flash chip" 8192kB. At least ME Cleaner worked with not errors on the captured fw image. Problem: I want to flash the modified image back to the IC using a raspberry 4b with gpio spi setup using a SOIC8 clip. But I could not manage to find the correct IC on the mainboard. I kept looking for SOIC8 200mil with some "25" signature and found only a GD25Q20C(2M-bit)Serial flash chip, that I could successfully read with raspberry spi setup. However, it contains only 256k data. strings showed me lots of HDMI related stuff. I have created a list of chips I found while disassembling and some pics. I hope that someone more experienced could explain me how the 8MB fw is stored on this zotac and if it is "safely" possible to rewrite it. I it is to difficult or dangerous, as beginner I will stick with new hardware from already supported hw list. The "promising" IC chips I found were a - 1 piece of "G labeled" AH1815 25Q2 1BT EE455, I think it is related to the GigaDevice GD25Q20C(2M-bit)I found on web. this chip I managed to read out.. b - 12 pieces of SOIC8 150mil (or samller?) : M B07 N03 EKH 1409 (Macronix? could not find anything:/ ) c - 1 piece of Issi IS25LQ020: 256K x 8 (2 Mbit) (maybe related to USB-C extension module) d - 1 piece of RT9059 GSP6E TOC, which I think could be a RichTek ultra low power voltage regulator? e - 4 pieces of "P labeled" 6982 GA9C1E ICs, I do not know what they are, maybe some MOSFET? f - 1 piece of "P labeled" 4435 GL9B2E SOIC8 200mil which I know nothing about Pics of the mainboard front and back are here: https://pasteboard.co/JJjQqQO.jpg https://pasteboard.co/JJjRjLU.jpg https://pasteboard.co/JJjRCDt.jpg Any suggestion how to go on or stop it anyway would be appreciated. kind regards, Peter Mueller

5 9

Secure Boot
by techmindams04＠gmail.com 12 Jan '21

12 Jan '21

Hi, I need to enable secure boot to load esxi installer. But it is failing with message Uefi secure boot is not enabled. So i need to enable it in coreboot. I have a uefi payload binary from Intel. Payload binary one with normal and another with secure functions. With normal payload i am able to boot Ubuntu but not esxi installer. It fails with Uefi secure boot is not enabled. When trying with uefi secure payload binary, the payload itself fails to come up. Do i need to enable anything in coreboot to enable secure boot?. Is coreboot support secure boot using Verified Boot. If so I enabled VBoot also but still the esxi loader fails to load. Is boot guard to be enabled for secure boot? Regards, gsenk

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 12 Jan '21

12 Jan '21

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. 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1442304: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/braswell/ramstage.c: 128 in soc_fill_acpi_wake() ________________________________________________________________________________________________________ *** CID 1442304: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/braswell/ramstage.c: 128 in soc_fill_acpi_wake() 122 /* Save wake source information for calculating ACPI _SWS values */ 123 int soc_fill_acpi_wake(uint32_t *pm1, uint32_t **gpe0) 124 { 125 struct chipset_power_state *ps = cbmem_find(CBMEM_ID_POWER_STATE); 126 static uint32_t gpe0_sts; 127 >>> CID 1442304: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "ps", which is known to be "NULL". 128 *pm1 = ps->pm1_sts & ps->pm1_en; 129 130 gpe0_sts = ps->gpe0_sts & ps->gpe0_en; 131 *gpe0 = &gpe0_sts; 132 133 return 1; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Updated invitation: coreboot Leadership Meeting @ Every 2 weeks from 11am to 12pm on Wednesday from Wed Sep 9, 2020 to Tue Jan 12 (MDT) (coreboot@coreboot.org)
by marshalldawson3rd＠gmail.com 11 Jan '21

11 Jan '21

This event has been changed. Title: coreboot Leadership Meeting Meeting Minutes - If you don't have edit access and want it, please ask Patrick G. When: Every 2 weeks from 11am to 12pm on Wednesday from Wed Sep 9, 2020 to Tue Jan 12 Mountain Time - Denver (changed) Joining info: Join with Google Meet https://meet.google.com/syn-toap-agu?hs=224 Join by phone (US) +1 347-554-5113 (PIN: 858153) More phone numbers: https://tel.meet/syn-toap-agu?pin=5345676483196&hs=0 Calendar: coreboot(a)coreboot.org Who: * Patrick Georgi - organizer * Martin Roth - creator, optional * WIM * Dossym Nurmukhanov * christian.walter(a)9elements.com * marshalldawson3rd(a)gmail.com * Stefan Reinauer * jeremy(a)system76.com * Marc Jones * Werner Zeh * David Hendricks * zaolin.daisuki(a)googlemail.com * quasisec(a)google.com * epeers(a)google.com * felix.held(a)amd.corp-partner.google.com * tcrawford(a)system76.com * gduynisveld(a)eltan.com * Held, Felix * coreboot(a)coreboot.org * subrata.banik(a)intel.com - optional * patrick.rudolph(a)9elements.com - optional * matt.devillier(a)gmail.com - optional * Ron Minnich - optional * deb(a)sfconservancy.org - optional * jaytalbott(a)sysproconsulting.com - optional * jonzhang(a)fb.com - optional * Furquan Shaikh - optional * kerry.brown(a)silverbackltd.com - optional * Julius Werner - optional * felix-coreboot(a)felixheld.de - optional * nico.h(a)gmx.de - optional * felix(a)felixheld.de - optional * ed.benyukhis(a)amd.com - optional * arthur(a)aheymans.xyz - optional Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=Z2c0NmY0bjVwNmY5… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account coreboot(a)coreboot.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Updated invitation: coreboot Leadership Meeting @ Every 2 weeks from 11am to 12pm on Wednesday (MST) (coreboot@coreboot.org)
by marshalldawson3rd＠gmail.com 11 Jan '21

11 Jan '21

This event has been changed. Title: coreboot Leadership Meeting Meeting Minutes - If you don't have edit access and want it, please ask Patrick G. When: Every 2 weeks from 11am to 12pm on Wednesday Mountain Time - Denver Joining info: Join with Google Meet https://meet.google.com/syn-toap-agu?hs=224 Join by phone (US) +1 347-554-5113 (PIN: 858153) More phone numbers: https://tel.meet/syn-toap-agu?pin=5345676483196&hs=0 Calendar: coreboot(a)coreboot.org Who: * Patrick Georgi - organizer * Martin Roth - creator, optional * WIM * Dossym Nurmukhanov * christian.walter(a)9elements.com * marshalldawson3rd(a)gmail.com * Stefan Reinauer * jeremy(a)system76.com * Marc Jones * Werner Zeh * David Hendricks * zaolin.daisuki(a)googlemail.com * quasisec(a)google.com * epeers(a)google.com * felix.held(a)amd.corp-partner.google.com * tcrawford(a)system76.com * gduynisveld(a)eltan.com * Held, Felix * coreboot(a)coreboot.org * jason.glenesk(a)amd.com * subrata.banik(a)intel.com - optional * patrick.rudolph(a)9elements.com - optional * matt.devillier(a)gmail.com - optional * Ron Minnich - optional * deb(a)sfconservancy.org - optional * jaytalbott(a)sysproconsulting.com - optional * jonzhang(a)fb.com - optional * Furquan Shaikh - optional * kerry.brown(a)silverbackltd.com - optional * Julius Werner - optional * felix-coreboot(a)felixheld.de - optional * nico.h(a)gmx.de - optional * felix(a)felixheld.de - optional * ed.benyukhis(a)amd.com - optional * arthur(a)aheymans.xyz - optional Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=Z2c0NmY0bjVwNmY5… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account coreboot(a)coreboot.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

"Fixing" `1 << 31` (technically undefined behavior with known implementation-specific results)
by Nico Huber 09 Jan '21

09 Jan '21

Hi coreboot fellows, another patch that fixes a `1 << 31` to `1UL << 31` [1] reminded me that some people objected to such changes. I'm not sure if we ever draw a conclusion on the matter. `1 << 31` is undefined behavior because the `1` can (and thus will) be represented as a (signed) `int` which is limited by 2^31-1 for all our targets. But we know very well that GCC (and I assume Clang too) do the right thing: Produce a value that when casted to an `unsigned int` is converted to 2^31. So, it's wrong but not broken ;) and any suffix to the `1` makes it a bit harder to read. What do you think? Should we allow such changes? Should we normalize on any style? If we want to make it defined behavior, my personal preference would be `1u << 31`. Lower case because it's more distinct from the number part, and we actually don't need a long (that might even hide actual errors if we want a 32-bit limited value). Cheers, Nico PS. Happy new year btw. :D [1] https://review.coreboot.org/c/coreboot/+/49076

9 14

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 08 Jan '21

08 Jan '21

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 1441844: (NULL_RETURNS) /util/intelmetool/intelmetool.c: 55 in dumpmemfile() /util/intelmetool/intelmetool.c: 53 in dumpmemfile() ________________________________________________________________________________________________________ *** CID 1441844: (NULL_RETURNS) /util/intelmetool/intelmetool.c: 55 in dumpmemfile() 49 { 50 FILE *fp = fopen("medump.bin", "w"); 51 uint32_t i; 52 for (i = 0; i < size; i++) { 53 fprintf(fp, "%c", *((uint8_t *) (phys + i))); 54 } >>> CID 1441844: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "fp" when calling "fclose". 55 fclose(fp); 56 } 57 58 static int isCPUGenuineIntel(void) 59 { 60 regs_t regs; /util/intelmetool/intelmetool.c: 53 in dumpmemfile() 47 48 static void dumpmemfile(uint8_t *phys, uint32_t size) 49 { 50 FILE *fp = fopen("medump.bin", "w"); 51 uint32_t i; 52 for (i = 0; i < size; i++) { >>> CID 1441844: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "fp" when calling "fprintf". [Note: The source code implementation of the function has been overridden by a builtin model.] 53 fprintf(fp, "%c", *((uint8_t *) (phys + i))); 54 } 55 fclose(fp); 56 } 57 58 static int isCPUGenuineIntel(void) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

GCC warnings about brackets -Wparentheses (was Re: "Fixing" `1 << 31` (technically undefined behavior with known implementation-specific results))
by Nico Huber 08 Jan '21

08 Jan '21

Hi Angel, as you brought it up, I guess we may as well discuss this on the list, too. I assume because some developers often don't remember that `+` takes precedence before `<<`, GCC warns now that one should place brackets in such cases even if they aren't necessary. On 08.01.21 01:37, Angel Pons wrote: > Since register fields usually have more than one bit, I prefer to > always use explicit shifts for consistency. The one case where I > prefer the BIT() macro is to reduce the amount of nested braces when > testing for individual bits in a mask. GCC encourages adding > unnecessary braces for expressions such as `1 << x + 3`, so it's easy > to end up with five levels of brace nesting in a single expression. I've also seen some worrisome brackets inflation in other cases. IMO, with too many brackets, one has to trace a line back and forth too much to match opening and closing brackets, so it actually becomes much harder to read. So, my question is, do we actually want -Wparentheses? Or is it just enabled because it's the default (with -Wall that is). Alternatively, we could encourage other ways to handle such seemingly ambiguity. For instance, one can store an intermediate value in a (const) variable. That would spread a single calculation over multiple lines, but it might be much easier to read than a forest of brackets. Nico

1 0

Need advise updating Intel's microcode in MPInit
by Patrick Rudolph 07 Jan '21

07 Jan '21

Hi, I'm stuck at solving a problem on Intel platforms that might not be one after all. Tests showed that a HyperThreading enabled core must not update microcodes on both threads at the same time, as the UCODE silicon is shared between those threads and one update might fail. However, doing so might not cause problems on devices newer than the Pentium 4 (as stated in some SDMs). Intel's SDM requires the use of semaphores to only update one thread of a core at once. In order to follow the microcode update flow described in Intel SDM I've moved some essential parts of coreboot's MP init code (aka SIPI vector) to C code [1]. While it makes it easier to maintain and reuse existing code (especially semaphores), it doesn't follow SDM to update microcode first no matter what. I'm not sure if all the work/changes are really necessary. The questions here are: * Do we care about Intel platforms supporting FIT? Those do update the microcode on all cores before executing the reset vector anyway and thus MP init won't update microcode at all. Following Intel SDM here is pointless. * Do we care about Intel platforms not supporting FIT (aka pre Haswell)? Those could update one core at time using a spinlock whenever HyperThreading is enabled. Assuming the limited amount of logical cores on those old platforms the additional boot delay might be very low. Another option would be to update microcode in parallel without a spinlock assuming that no Pentium 4 will ever run this code. Following Intel SDM here, given the low number of cores, won't give any significant speed up while adding complex code. * Do we care about Intel platforms supporting FIT not using FIT? Following Intel SDM here, assuming a high number of cores, will give significant speed up while adding complex code. * Should the SIPI vector in general be partially moved from assembly to C? This makes it easier to add features and reuse code, but compilers might generate unsupported code. To summarize: Instead of adding a bunch of code I'd prefer to serialize MP init microcode updates on non FIT and Hyper-Threading enabled CPUs only. 1: https://review.coreboot.org/q/topic:%22mpinit_cleanup%22+(status:open%20OR%… Kind Regards, Patrick Rudolph B.Sc. Electrical Engineering System Firmware Developer 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudolph(a)9elements.com Phone: +49 234 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO

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 January 2021