coreboot October 2021

coreboot@coreboot.org

40 participants
27 discussions

coreboot EFI working group meeting minutes - 12 October 2021
by Martin Roth 13 Oct '21

13 Oct '21

# 12 October 2021 - coreboot EFI working group ## Objective: Linux is expecting more and more to use EFI supplied interfaces (UEFI Boot Services in particular, even if many are stubbed out) so like it or not, we’re going to need to support these interfaces. How do we approach this without turning coreboot into UEFI. ## Decisions: * The coreboot repo will host an EDK2 fork for use as a coreboot payload. Commits to this repo will go through gerrit for review. * Any code needed to support booting should go into a payload instead of coreboot itself. * We will look at adding chain-loading payload support to coreboot. Among other things, this will allow a payload to support turning cbmem tables into UEFI HOBs as needed before calling into a UEFI support payload. ## Minutes: * Can you access the VC ? [Chris] * 9 people in. Apparently Chrome + Web or using the apps work for some people, but not for others. * Native [Bluejeans] apps * We’ll try a different method for our next meeting - The method will be announced after we decide when to hold our next meeting. * FelixH: this isn’t a job for coreboot. * This should definitely be in a payload. * If FSP settings need to be configured, this would be a problem. * How would we support boot variables? Or would we? * Werner: Agree with keeping this in a payload. * [pgeorgi] What’s the scope of this project? * Just booting? * Jay: Syspro is typically asked to create solutions that are NOT UEFI. They want simplicity and boot code to do the minimal amount. * 9elements: customers are mostly desiring UEFI boot solutions * coreboot need additional tables in cbmem to support a better UEFI implementation. * What’s the timeline? * When will we NEED to support the EFI interfaces? * Do we know what these interfaces will be? * Initially just boot services. * Is there any advantage to pulling EFI into coreboot. * No? Having chainloading payloads could handle any translation necessary without tying that to a specific payload. (ie. coreboot loads the cbmem2hob payload, which does its thing, then cbmem2hob loads the actual payload) * Look into chain-loading payloads: pgeorgi will look into this. Proof of concept: move splashscreen support out of ramstage. * Add an edk2 fork to the coreboot git server * Where do we start from? * Current EDK2 stable from August 2021. * https://review.coreboot.org/edk2.git is now mirrored from https://github.com/tianocore/edk2 * Updated hourly * Our own stable tag is default: coreboot-stable202108, based off edk2-stable202108 * How do we pull changes from EDK2 * Create upstream branch to pull in changes? The vast majority of changes will come into this branch, and someone would need to sort them out at some point. * What’s the volume of patches that come into the EDK2? That has a big impact to how we address this: * About 5 patches a day. * checked again: there are ~6000 commits between 2020-09-20 and 2021-09-20 on edk2/master, so more like 20 commits a day * Can we just create a fork and add things on top, or is there a better way to start? * Matt currently just creates his fork for the chromebook firmwares that he maintains. * How do we push changes back to EDK2? * This is a big issue - this is why many of the forks were created. * What’s the volume of our changes that would go into this tree? * How do we want to handle commits? * Are there enough people to do real code reviews? * Let’s just start by pushing through gerrit. * What other more minimal projects are we interested in pulling in as payloads? * Yabits, Voodoo, U-Boot’s codebase? * Yabits did not work the last time it was (minimally tested) * Tianocore is currently not very well featured. * There are definitely situations currently where a uefi-payload is needed, so if there were something that provided a UEFI interface without all of the associated overhead, that would be very useful. * Everyone has different ideas about what’s needed as a minimal solution. * Voodoo is trying to get away from running all of this code in ring0. * No serious discussion about building anything new from scratch at this point, but that’s obviously not out of the question if someone wanted to start a new project. * Definitely no one-size fits all solution here * AI: Need to find out what linux is going to need. * Is this just what’s required for grub, or by linux itself - those are different things. * May be useful to have multiple implementations to find where the gaps are. * Any maintained implementations are welcome on review.coreboot.org! (no graveyard for yabits unless you start working on it) * Figure out boot services profile for linux as a payload * AI: look at what grub needs * Note that there is "grub as a payload" * UEFI spec is closed source * This would need to be addressed by the UEFI Forum board of directors. * Nate will pass along the request to make this open source. * What counts as working? * Will definitely set up build testing * Can 9elements help any with testing for their purposes at least. * 9elements will definitely test, but can’t say at this point how it will look. * Created edk2 repo: * Matt to start pushing patches. * Martin to set up build testers. * Discuss whether we need another meeting on the 26th at next week’s leadership meeting. ## Agenda & random notes below. * How do we approach this without turning coreboot into UEFI. Linux is expecting more and more to use EFI supplied interfaces (UEFI Boot Services in particular, even if many are stubbed out) so like it or not, we’re going to need to support these interfaces. * Extend [Yabits]? This hasn’t had any new commits in over 3 years. It also leverages libpayload which is not so much alive either these days. * Through depthcharge, libpayload is probably the most exercised payload code you'll find these days that isn't a Linux kernel. * Fork EDK2 * There are already many private forks. It would be useful to have a central location to merge these. There is a worry about who will review the patches. I don’t think we want everyone on the internet to be able to submit and merge patches, so we probably want to create a group who can merge them. * Set up a jenkins builder * What codebase do we start with? * Extend Ron’s [Voodoo] project * This is now passing one of the tests from u-boot efi_selftest * Port to arm in progress * Write something from scratch * Add code to coreboot to create HOB structures and other requirements. * This was the initial suggestion that was proposed in the coreboot meeting last week. * Pull in u-boot’s UEFI implementation * How much of the [UEFI spec] is needed? * ARM has a [trimmed down UEFI spec]. Can a similar one be made for x86? * Boot services * Runtime services * Secure boot * Boot Variables * User identification? * Apparently EBBR requires mass storage as part of the spec, so more a payload matter [Bluejeans]: https://www.bluejeans.com/downloads [UEFI spec]: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf [Yabits]: https://github.com/yabits/uefi [Voodoo]: https://github.com/linuxboot/voodoo [trimmed down UEFI spec]: https://arm-software.github.io/ebbr/

4 4

The coreboot.org edk2 repo is live! (But don't get a heart attack)
by Patrick Georgi 12 Oct '21

12 Oct '21

Hi everybody, To facilitate cooperation on UEFI-as-a-payload work, we established a mirror of tianocore's edk2 repo at https://review.coreboot.org/edk2. Unlike other mirrors on review.coreboot.org, it's open for development. It's updated regularly, but the default branch that we set up, coreboot-stable202108, is based on edk2-stable202108, so there won't be changes flowing in automatically to the branch we will focus on. We will set up builders on qa.coreboot.org to cover that repo, so we get the same "at the very least, it builds" guarantees that we have for any coreboot contributions. Maybe we'll even get boot tests in the future, who knows? If you want to make coreboot+edk2 a viable option for starting hardware (with the bonus compared to "regular" edk2 flows that hardware init happens on the coreboot side, so if you want the same hardware to boot differently, it can easily be made to be coreboot+SomethingElse!), there's plenty of opportunities for developers. Matt DeVillier (Mr. Chromebox) offered to push his patch train there which (as I understand it) is an amalgamation of changes made in various edk2 forks in the coreboot ecosystem. Something people have talked about is adding Microsoft's Project Mu ( https://microsoft.github.io/mu/) UI improvements to tianocore-as-a-payload, which could find a good home there, as well. Finally, SMMSTORE: it exists, it helps where it is supported to persist UEFI variables, but as I understand it, actual support for devices is rather limited. Making coreboot+edk2 the premier option for booting UEFI platforms would give the rest of us something to work with that is more pleasant than trying to NERF vendor firmware until it stops doing all the things we don't need it to do. And if you don't care about UEFI (or if that's putting it mildly, even), don't worry: this is only a payload. Just like we have FILO on our server or SeaBIOS or depthcharge, this is just another option. But given the market penetration of UEFI interfaces, it's an important one to get right. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

3 2

Atomic Accesses to Local APIC
by Julian Stecklina 06 Oct '21

06 Oct '21

Hello, I was looking at the Local APIC code in coreboot and was wondering about `lapic_write_atomic` in src/include/cpu/x86/lapic.h. This uses an atomic XCHG to write to Local APIC registers. I would like to understand why this would be necessary, because none of the OSes I've seen or worked on do anything similar. ALso the Intel SDM discourages acceses that are not plain loads/stores. In the coreboot code, this function seems to exist for a really long time. I've found this from 2004: #ifdef CONFIG_X86_GOOD_APIC # define FORCE_READ_AROUND_WRITE 0 # define lapic_read_around(x) lapic_read(x) # define lapic_write_around(x,y) lapic_write((x),(y)) #else # define FORCE_READ_AROUND_WRITE 1 # define lapic_read_around(x) lapic_read(x) # define lapic_write_around(x,y) lapic_write_atomic((x),(y)) #endif This seems to indicate that using atomic writes was a workaround of some kind. Does anyone know more? Thanks! Julian

6 17

how intel ME is connected to the internet ?
by Hendra 04 Oct '21

04 Oct '21

hi coreboot, I read in Wikipedia that Intel ME has an independent internet connection. But what does "independent" mean ? Is it an independent internet connection from the OS ? or is it an independent internet connection from the network related devices ? such as: wwan card, wlan card, bluetooth module, wimax card or maybe it has its own secret/hidden independent networking device, so it can connect to the internet, without depending on Laptop's networking device, such as: wwan card, wlan card, bluetooth module, wimax card ? regards,

9 16

Gigabyte D510UD MOBO
by Ilker C 04 Oct '21

04 Oct '21

Hello All, I have this computer since 11 years and working with triple boot from SSD and HDD. Also I have PCI graphics card Radeon 512 KB. I overclocked the CPU to 2Ghz to run Linux Mint and Win 10. I had a problem with windows 10 due to the PCI graphics card conflicting when installed ram is more than 2Gb. Linux does not have. It works with 4gb and PCI Graphics card. After checking all information I find out that PCI Hole is the main reason and legacy BIOS does not have memory remapping function. Maybe that was necessary for this board. While I was searching how to change the existing BIOS I ended up coreboot. I downloaded the latest release and compiled in linux mint. (There are some missing steps in the HOWTO page while compiling) Then I used flashrom internally. Seabios boot was successful. He are my findings : - Seabios boots only with the SSD. - Linux Mint in HDD did not boot. WIn10 in HDD did not boot. - 2nd RAM slot is not working. So max memory is 2gb only. - GRUB2 did not work. - PCI graphics card did not work. Only on Board. - Gigabyte SATA ports did not work. Only Sata ports of Intel chipset NM10. - There is no any improvement in Boot speed. Because of the above I revert and installed the stock BIOS from Gigabyte. I believe this project is great and I would like to thank for all contributers. Regards

2 1

PXE on Coreboot
by Rao G 04 Oct '21

04 Oct '21

Hi Coreboot Developers, Very warm greetings! Trying to enable PXE along with UEFI payload on Elkhart Lake CRB platform Enabling Network stack requires below DXE drivers to be enabled https://github.com/tianocore/edk2/blob/vUDK2018/MdeModulePkg/MdeModulePkg.d… MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf [Components.IA32, Components.X64, Components.IPF, Components.AARCH64] MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf Please send your comments/views on how to enable PXE with uEFI payload, It is also okay incase if there is an alternate approach to enable PXE without UEFI payload. Thanks Ranga

2 1

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

01 Oct '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 7 new defect(s) introduced to coreboot found with Coverity Scan. 3 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 7 of 7 defect(s) ** CID 1464057: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 370 in MemTDIMMPresence3() ________________________________________________________________________________________________________ *** CID 1464057: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 370 in MemTDIMMPresence3() 364 ChannelPtr->RefRawCard[i] = SpdBufferPtr[SPD_RAWCARD] & 0x1F; 365 // 366 // Get control word values for RC3, RC4 and RC5 367 // 368 ChannelPtr->CtrlWrd03[i] = SpdBufferPtr[SPD_CTLWRD03] >> 4; 369 ChannelPtr->CtrlWrd04[i] = SpdBufferPtr[SPD_CTLWRD04] & 0x0F; >>> CID 1464057: Memory - corruptions (OVERRUN) >>> Overrunning array "ChannelPtr->CtrlWrd05" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 370 ChannelPtr->CtrlWrd05[i] = SpdBufferPtr[SPD_CTLWRD05] >> 4; 371 // 372 // Temporarily store info. of SPD byte 63 into CtrlWrd02(s), 373 // and they will be used late to calculate real RC2 and RC8 value 374 // 375 ChannelPtr->CtrlWrd02[i] = SpdBufferPtr[SPD_ADDRMAP] & 0x03; ** CID 1464056: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 364 in MemTDIMMPresence3() ________________________________________________________________________________________________________ *** CID 1464056: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 364 in MemTDIMMPresence3() 358 ChannelPtr->DimmMirrorPresent |= DimmMask; 359 } 360 } 361 // 362 // Get byte62: Reference Raw Card information 363 // >>> CID 1464056: Memory - corruptions (OVERRUN) >>> Overrunning array "ChannelPtr->RefRawCard" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 364 ChannelPtr->RefRawCard[i] = SpdBufferPtr[SPD_RAWCARD] & 0x1F; 365 // 366 // Get control word values for RC3, RC4 and RC5 367 // 368 ChannelPtr->CtrlWrd03[i] = SpdBufferPtr[SPD_CTLWRD03] >> 4; 369 ChannelPtr->CtrlWrd04[i] = SpdBufferPtr[SPD_CTLWRD04] & 0x0F; ** CID 1464055: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 375 in MemTDIMMPresence3() ________________________________________________________________________________________________________ *** CID 1464055: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 375 in MemTDIMMPresence3() 369 ChannelPtr->CtrlWrd04[i] = SpdBufferPtr[SPD_CTLWRD04] & 0x0F; 370 ChannelPtr->CtrlWrd05[i] = SpdBufferPtr[SPD_CTLWRD05] >> 4; 371 // 372 // Temporarily store info. of SPD byte 63 into CtrlWrd02(s), 373 // and they will be used late to calculate real RC2 and RC8 value 374 // >>> CID 1464055: Memory - corruptions (OVERRUN) >>> Overrunning array "ChannelPtr->CtrlWrd02" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 375 ChannelPtr->CtrlWrd02[i] = SpdBufferPtr[SPD_ADDRMAP] & 0x03; 376 // 377 // Copy the number of registers to the Ps Block to persist across frequency changes 378 // 379 NBPtr->PsPtr->NumOfReg[i] = SpdBufferPtr[SPD_ADDRMAP] & 0x03; 380 // ** CID 1464054: (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 379 in MemTDIMMPresence3() /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 384 in MemTDIMMPresence3() /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 383 in MemTDIMMPresence3() ________________________________________________________________________________________________________ *** CID 1464054: (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 379 in MemTDIMMPresence3() 373 // and they will be used late to calculate real RC2 and RC8 value 374 // 375 ChannelPtr->CtrlWrd02[i] = SpdBufferPtr[SPD_ADDRMAP] & 0x03; 376 // 377 // Copy the number of registers to the Ps Block to persist across frequency changes 378 // >>> CID 1464054: (OVERRUN) >>> Overrunning array "NBPtr->PsPtr->NumOfReg" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 379 NBPtr->PsPtr->NumOfReg[i] = SpdBufferPtr[SPD_ADDRMAP] & 0x03; 380 // 381 // Workaround for early revisions of DIMMs which SPD byte 63 is 0 382 // 383 if (NBPtr->PsPtr->NumOfReg[i] == JED_UNDEFINED) { 384 NBPtr->PsPtr->NumOfReg[i] = 1; /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 384 in MemTDIMMPresence3() 378 // 379 NBPtr->PsPtr->NumOfReg[i] = SpdBufferPtr[SPD_ADDRMAP] & 0x03; 380 // 381 // Workaround for early revisions of DIMMs which SPD byte 63 is 0 382 // 383 if (NBPtr->PsPtr->NumOfReg[i] == JED_UNDEFINED) { >>> CID 1464054: (OVERRUN) >>> Overrunning array "NBPtr->PsPtr->NumOfReg" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 384 NBPtr->PsPtr->NumOfReg[i] = 1; 385 } 386 } // if DIMM present 387 } // Dimm loop 388 389 if (Channel == 0) { /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 383 in MemTDIMMPresence3() 377 // Copy the number of registers to the Ps Block to persist across frequency changes 378 // 379 NBPtr->PsPtr->NumOfReg[i] = SpdBufferPtr[SPD_ADDRMAP] & 0x03; 380 // 381 // Workaround for early revisions of DIMMs which SPD byte 63 is 0 382 // >>> CID 1464054: (OVERRUN) >>> Overrunning array "NBPtr->PsPtr->NumOfReg" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 383 if (NBPtr->PsPtr->NumOfReg[i] == JED_UNDEFINED) { 384 NBPtr->PsPtr->NumOfReg[i] = 1; 385 } 386 } // if DIMM present 387 } // Dimm loop 388 ** CID 1464053: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 368 in MemTDIMMPresence3() ________________________________________________________________________________________________________ *** CID 1464053: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 368 in MemTDIMMPresence3() 362 // Get byte62: Reference Raw Card information 363 // 364 ChannelPtr->RefRawCard[i] = SpdBufferPtr[SPD_RAWCARD] & 0x1F; 365 // 366 // Get control word values for RC3, RC4 and RC5 367 // >>> CID 1464053: Memory - corruptions (OVERRUN) >>> Overrunning array "ChannelPtr->CtrlWrd03" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 368 ChannelPtr->CtrlWrd03[i] = SpdBufferPtr[SPD_CTLWRD03] >> 4; 369 ChannelPtr->CtrlWrd04[i] = SpdBufferPtr[SPD_CTLWRD04] & 0x0F; 370 ChannelPtr->CtrlWrd05[i] = SpdBufferPtr[SPD_CTLWRD05] >> 4; 371 // 372 // Temporarily store info. of SPD byte 63 into CtrlWrd02(s), 373 // and they will be used late to calculate real RC2 and RC8 value ** CID 1464052: (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1464052: (FORWARD_NULL) /src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuApicUtilities.c: 438 in ApEntry() 432 break; 433 default: 434 ReturnCode = 0; 435 break; 436 } 437 if (((ApFlags & AP_RETURN_PARAMS) != 0)) { >>> CID 1464052: (FORWARD_NULL) >>> Passing "&DataTransferInfo" to "ApUtilTransmitBuffer", which dereferences null "DataTransferInfo.DataPtr". 438 ApUtilTransmitBuffer (SourceSocket, 0, &DataTransferInfo, StdHeader); 439 } 440 if ((ApFlags & AP_TASK_HAS_OUTPUT) != 0) { 441 ApUtilWriteDataDword (ReturnCode, StdHeader); 442 } 443 if ((ApFlags & AP_END_AT_HLT) != 0) { /src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuApicUtilities.c: 438 in ApEntry() 432 break; 433 default: 434 ReturnCode = 0; 435 break; 436 } 437 if (((ApFlags & AP_RETURN_PARAMS) != 0)) { >>> CID 1464052: (FORWARD_NULL) >>> Passing "&DataTransferInfo" to "ApUtilTransmitBuffer", which dereferences null "DataTransferInfo.DataPtr". 438 ApUtilTransmitBuffer (SourceSocket, 0, &DataTransferInfo, StdHeader); 439 } 440 if ((ApFlags & AP_TASK_HAS_OUTPUT) != 0) { 441 ApUtilWriteDataDword (ReturnCode, StdHeader); 442 } 443 if ((ApFlags & AP_END_AT_HLT) != 0) { ** CID 1464051: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 369 in MemTDIMMPresence3() ________________________________________________________________________________________________________ *** CID 1464051: Memory - corruptions (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/Mem/Tech/DDR3/mtspd3.c: 369 in MemTDIMMPresence3() 363 // 364 ChannelPtr->RefRawCard[i] = SpdBufferPtr[SPD_RAWCARD] & 0x1F; 365 // 366 // Get control word values for RC3, RC4 and RC5 367 // 368 ChannelPtr->CtrlWrd03[i] = SpdBufferPtr[SPD_CTLWRD03] >> 4; >>> CID 1464051: Memory - corruptions (OVERRUN) >>> Overrunning array "ChannelPtr->CtrlWrd04" of 4 bytes at byte offset 4 using index "i" (which evaluates to 4). 369 ChannelPtr->CtrlWrd04[i] = SpdBufferPtr[SPD_CTLWRD04] & 0x0F; 370 ChannelPtr->CtrlWrd05[i] = SpdBufferPtr[SPD_CTLWRD05] >> 4; 371 // 372 // Temporarily store info. of SPD byte 63 into CtrlWrd02(s), 373 // and they will be used late to calculate real RC2 and RC8 value 374 // ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

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