coreboot

coreboot@coreboot.org

6 participants
39687 discussions

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

05 Feb '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 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 3 of 3 defect(s) ** CID 1445995: Code maintainability issues (UNUSED_VALUE) /src/arch/x86/acpi_bert_storage.c: 534 in bert_new_event() ________________________________________________________________________________________________________ *** CID 1445995: Code maintainability issues (UNUSED_VALUE) /src/arch/x86/acpi_bert_storage.c: 534 in bert_new_event() 528 if (!status) 529 return NULL; 530 531 status->raw_data_length = sizeof(*status); 532 533 if (!guidcmp(guid, &CPER_SEC_PROC_GENERIC_GUID)) >>> CID 1445995: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "bert_append_genproc(status)" to "r" here, but that stored value is overwritten before it can be used. 534 r = bert_append_genproc(status); 535 else if (!guidcmp(guid, &CPER_SEC_PROC_GENERIC_GUID)) 536 r = bert_append_ia32x64(status); 537 if (!guidcmp(guid, &CPER_SEC_FW_ERR_REC_REF_GUID)) 538 r = bert_append_fw_err(status); 539 /* else if other types not implemented */ ** CID 1445994: Integer handling issues (BAD_SHIFT) /src/soc/amd/common/block/acpi/pm_state.c: 21 in get_index_bit() ________________________________________________________________________________________________________ *** CID 1445994: Integer handling issues (BAD_SHIFT) /src/soc/amd/common/block/acpi/pm_state.c: 21 in get_index_bit() 15 uint32_t t; 16 17 if (limit > TOTAL_BITS(uint32_t)) 18 return -1; 19 20 /* get a mask of valid bits. Ex limit = 3, set bits 0-2 */ >>> CID 1445994: Integer handling issues (BAD_SHIFT) >>> In expression "1 << limit", left shifting by more than 31 bits has undefined behavior. The shift amount, "limit", is as much as 32. 21 t = (1 << limit) - 1; 22 if ((value & t) == 0) 23 return -1; 24 t = 1; 25 for (i = 0; i < limit; i++) { 26 if (value & t) ** CID 1445993: Code maintainability issues (UNUSED_VALUE) /src/arch/x86/acpi_bert_storage.c: 536 in bert_new_event() ________________________________________________________________________________________________________ *** CID 1445993: Code maintainability issues (UNUSED_VALUE) /src/arch/x86/acpi_bert_storage.c: 536 in bert_new_event() 530 531 status->raw_data_length = sizeof(*status); 532 533 if (!guidcmp(guid, &CPER_SEC_PROC_GENERIC_GUID)) 534 r = bert_append_genproc(status); 535 else if (!guidcmp(guid, &CPER_SEC_PROC_GENERIC_GUID)) >>> CID 1445993: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "bert_append_ia32x64(status)" to "r" here, but that stored value is overwritten before it can be used. 536 r = bert_append_ia32x64(status); 537 if (!guidcmp(guid, &CPER_SEC_FW_ERR_REC_REF_GUID)) 538 r = bert_append_fw_err(status); 539 /* else if other types not implemented */ 540 else 541 r = NULL; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[Events] Talk about coreboot on POWER + vBeer online party!
by Mike Banon 04 Feb '21

04 Feb '21

Dear friends, Next Thursday __4th Feb at 3PM GMT__ , 3mdeb invites you to talk about the POWER9 support in coreboot opensource BIOS - https://meet.google.com/xsy-ocfw-exm . You are going to learn: 1) great benefits a coreboot will deliver to POWER-based PCs; 2) our progress and interesting challenges we are facing; 3) unique features of Dasharo coreboot-based firmware. Also, soon we are having a vBeer online party! Will be happy to discuss the open/libre firmwares (coreboot, Dasharo, etc.), related hardwares and other nice embedded things you have in mind. Please visit http://live.evenea.com/3mdeb-vbeer at 18th Feb 3PM GMT to have some fun with us. -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 1

DP (Display Port) not enumerating in OS
by Rao G 03 Feb '21

03 Feb '21

Hello Coreboot Developers, Display port which comes along with Integrated LVDS, does not show up any OS graphics display text or screen after booting to OS, the DP port looks good during BIOS, at some point of time during OS booting display port turns off and no video on DP. Using ubuntu 18.04 Some ASL code for graphics is missing? HDMI, DVI & LVDS works well, no issue there Thanks for your time and any clues that would help to resolve this issue? Kind Regards Rao

2 1

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

02 Feb '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. 1 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 1445928: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/picasso/data_fabric.c: 178 in data_fabric_set_indirect_address() ________________________________________________________________________________________________________ *** CID 1445928: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/picasso/data_fabric.c: 178 in data_fabric_set_indirect_address() 172 { 173 uint32_t fabric_indirect_access_reg = DF_IND_CFG_INST_ACC_EN; 174 /* Register offset field [10:2] in this register corresponds to [10:2] of the 175 requested offset. */ 176 fabric_indirect_access_reg |= reg & DF_IND_CFG_ACC_REG_MASK; 177 fabric_indirect_access_reg |= >>> CID 1445928: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(func << 11) & (28 /* 7 << 2 */)" is always 0 regardless of the values of its operands. This occurs as the bitwise operand of "|". 178 (func << DF_IND_CFG_ACC_FUN_SHIFT) & DF_IND_CFG_ACC_FUN_MASK; 179 fabric_indirect_access_reg |= instance_id << DF_IND_CFG_INST_ID_SHIFT; 180 pci_write_config32(SOC_DF_F4_DEV, DF_FICAA_BIOS, fabric_indirect_access_reg); 181 } 182 183 uint32_t data_fabric_read32(uint8_t function, uint16_t reg, uint8_t instance_id) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Coreboot BIOS question
by SuperNova 30 Jan '21

30 Jan '21

Hello, I am a new user of Coreboot who recently purchased a Protectli firewall with Coreboot pre-installed. The firewall is running PfSense that I installed on it. Everything was going ok for a few days until I started having issues with PfSense and now I am having problems getting PfSense to launch at all. I believe this is related to a hardware issue with the firewall. During the coreboot launch I am getting an infinite loop which is triggered at the following line: cpu reset proxy stopped cpu 1 Sounds like an issue with the hardware to me. I believe I saw this same issue referencing cpu 2 as well. I have tried over a period of several weeks to boot up and I always get this message and then a loop back to the the coreboot initialization. At this point I cannot tell if this is a coreboot, pfsense, or hardware issue, and I am getting ready to just buy another firewall with pfsense already installed and I am hoping someone has the time to give me a brief idea of what might be going on here. I am fairly PC savy but am having difficulty drilling down to what might be driving this specific issue on the web. I do like your product and plan to purchase a PC with coreboot in the near future. Thanks a lot for your time. -Aaron Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 3

Problems with CAR setup on Tiger Lake
by Michał Żygowski 29 Jan '21

29 Jan '21

Dear coreboot community, I have a Tiger Lake UP3 RVP and I try to build a working coreboot on it, however facing an early stuck during CAR setup. Tried different approaches: - native coreboot's CAR setup - the last seen post code is 0x26 - FSP-T CAR setup - the last seen post code is 0x7F (which is TempRamInit Exit event according to FSP integration guide), FSP from public repo, Client variant Used microcode from original RVP firmware. Are there any patches that I have to apply to make it working? Best regards, -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

4 7

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

26 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. 1 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 1445764: Incorrect expression (CONSTANT_EXPRESSION_RESULT) /src/soc/intel/broadwell/raminit.c: 155 in setup_sdram_meminfo() ________________________________________________________________________________________________________ *** CID 1445764: Incorrect expression (CONSTANT_EXPRESSION_RESULT) /src/soc/intel/broadwell/raminit.c: 155 in setup_sdram_meminfo() 149 return; 150 } 151 152 memset(mem_info, 0, sizeof(*mem_info)); 153 /* Translate pei_memory_info struct data into memory_info struct */ 154 mem_info->dimm_cnt = pei_data->meminfo.dimm_cnt; >>> CID 1445764: Incorrect expression (CONSTANT_EXPRESSION_RESULT) >>> "8 < 8" is always false regardless of the values of its operands because those operands are identical. This occurs as the logical first operand of "?:". 155 for (int i = 0; i < MIN(DIMM_INFO_TOTAL, PEI_DIMM_INFO_TOTAL); i++) { 156 struct dimm_info *dimm = &mem_info->dimm[i]; 157 const struct pei_dimm_info *pei_dimm = 158 &pei_data->meminfo.dimm[i]; 159 dimm->dimm_size = pei_dimm->dimm_size; 160 dimm->ddr_type = pei_dimm->ddr_type; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Debugging Windows 10 BSOD
by Raul Rangel 25 Jan '21

25 Jan '21

I'm trying to boot the Windows 10 Installer on a picasso based device using coreboot + tianocore. I keep getting a BSOD after the windows logo shows with the very descriptive stop code `ACPI BIOS ERROR`. I've enabled bootdebug on the USB stick using the following: bcdedit /store H:\boot\bcd /bootdebug {bootmgr} on bcdedit /store H:\boot\bcd /bootdebug {default} on bcdedit /store H:\boot\bcd /debug {debug} on Here is the BCD: C:\Windows\system32>bcdedit /store h:\boot\bcd Windows Boot Manager -------------------- identifier {bootmgr} description Windows Boot Manager locale en-US inherit {globalsettings} bootdebug Yes default {default} displayorder {default} toolsdisplayorder {memdiag} timeout 30 Windows Boot Loader ------------------- identifier {default} device ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f} path \windows\system32\boot\winload.exe description Windows Setup locale en-US inherit {bootloadersettings} bootdebug Yes osdevice ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f} systemroot \windows bootmenupolicy Standard detecthal Yes winpe Yes debug Yes ems No C:\Windows\system32>bcdedit /store h:\boot\bcd /dbgsettings debugtype Serial debugport 1 baudrate 115200 I have also added the SPCR table: [000h 0000 4] Signature : "SPCR" [Serial Port Console Redirection table] [004h 0004 4] Table Length : 00000050 [008h 0008 1] Revision : 02 [009h 0009 1] Checksum : F1 [00Ah 0010 6] Oem ID : "COREv4" [010h 0016 8] Oem Table ID : "COREBOOT" [018h 0024 4] Oem Revision : 0000002A [01Ch 0028 4] Asl Compiler ID : "CORE" [020h 0032 4] Asl Compiler Revision : 20200925 [024h 0036 1] Interface Type : 00 [025h 0037 3] Reserved : 000000 [028h 0040 12] Serial Port Register : [Generic Address Structure] [028h 0040 1] Space ID : 00 [SystemMemory] [029h 0041 1] Bit Width : 20 [02Ah 0042 1] Bit Offset : 00 [02Bh 0043 1] Encoded Access Width : 03 [DWord Access:32] [02Ch 0044 8] Address : 00000000FEDC9000 [034h 0052 1] Interrupt Type : 03 [035h 0053 1] PCAT-compatible IRQ : 04 [036h 0054 4] Interrupt : 00000004 [03Ah 0058 1] Baud Rate : 00 [03Bh 0059 1] Parity : 00 [03Ch 0060 1] Stop Bits : 00 [03Dh 0061 1] Flow Control : 00 [03Eh 0062 1] Terminal Type : 00 [04Ch 0076 1] Reserved : 00 [040h 0064 2] PCI Device ID : FFFF [042h 0066 2] PCI Vendor ID : FFFF [044h 0068 1] PCI Bus : 00 [045h 0069 1] PCI Device : 00 [046h 0070 1] PCI Function : 00 [047h 0071 4] PCI Flags : 00000000 [04Bh 0075 1] PCI Segment : 00 [04Ch 0076 4] Reserved : 00000000 And the DBG2 table: [000h 0000 4] Signature : "DBG2" [Debug Port table type 2] [004h 0004 4] Table Length : 0000005C [008h 0008 1] Revision : 00 [009h 0009 1] Checksum : 78 [00Ah 0010 6] Oem ID : "COREv4" [010h 0016 8] Oem Table ID : "COREBOOT" [018h 0024 4] Oem Revision : 00000000 [01Ch 0028 4] Asl Compiler ID : "CORE" [020h 0032 4] Asl Compiler Revision : 20200925 [024h 0036 4] Info Offset : 0000002C [028h 0040 4] Info Count : 00000001 [02Ch 0044 1] Revision : 00 [02Dh 0045 2] Length : 0030 [02Fh 0047 1] Register Count : 01 [030h 0048 2] Namepath Length : 000A [032h 0050 2] Namepath Offset : 0026 [034h 0052 2] OEM Data Length : 0000 [Optional field not present] [036h 0054 2] OEM Data Offset : 0000 [Optional field not present] [038h 0056 2] Port Type : 8000 [03Ah 0058 2] Port Subtype : 0000 [03Ch 0060 2] Reserved : 0000 [03Eh 0062 2] Base Address Offset : 0016 [040h 0064 2] Address Size Offset : 0022 [042h 0066 12] Base Address Register : [Generic Address Structure] [042h 0066 1] Space ID : 00 [SystemMemory] [043h 0067 1] Bit Width : 20 [044h 0068 1] Bit Offset : 00 [045h 0069 1] Encoded Access Width : 03 [DWord Access:32] [046h 0070 8] Address : 00000000FEDC9000 [04Eh 0078 4] Address Size : 000000F8 [052h 0082 10] Namepath : "\_SB.FUR0" Given all this I have yet to see windows dump anything to the serial console. The device just reboots after the BSOD message. Does anyone have any experience debugging Windows boot errors? Can you share any tips? :) Thanks, Raul

5 9

Re: Testing code present in SMM
by Mick 24 Jan '21

24 Jan '21

Hello Peter, Thank you for your response! Cool! And ambitious. :) > Yeah, the project is pretty hacky, to be frank, and will be limited to the setup where SMRAM is from a0000h to bffffh. In general coreboot makes an attempt to not go overboard with SMM code, in > particular the QEMU board code may have almost none, to the point where > it's far from representative for modern platforms. > Yes, I'm aware of coreboot's stance on SMM. If I recall correctly, QEMU seemed to have trouble clearing the SMI_STS register. We will likely use hardware to test the setup. You're confirming my fear related to testing SMM in QEMU. I hope we will be able to see more SMM activity on a real board, but I don't know what to expect, as I have trouble finding sources that discuss how SMM is used in the "wild" (besides articles on reversing and exploiting SMM). Are you aware whether SMM is tested (for new functionality, for instance), and if so, how that is being done? Or is this done by using existing hardware setups? I do not have a lot of experience with low-level hardware. Thanks for your input :). Kind regards, Mick

2 1

Questions about Asus A88XM-E
by magiccat1＠protonmail.com 24 Jan '21

24 Jan '21

All, I have an Asus A88XM-E, and I am trying to install Coreboot on it. 1 ) The chip that came with the board says "GD25Q64(B)" (8192 kB, SPI). I think the chip definitely broken somehow. Everytime I tried to flashrom, it says Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00000fff: 0xd0c ERASE FAILED! when I tried sudo flashrom -w build/coreboot.rom --programmer ch341a_spi, it says Verifying flash... FAILED at 0x00000000! Expected=0x5f, Found=0xff, failed byte count from 0x00000000-0x007fffff: 0xb5 Your flash chip is in an unknown state. I am having a hard time flashing back to original bios as well. Can I buy W25Q64FVAIG to replace? The chip says GD25B64BP1G . Is that caused by using 5 V to be broken? I only performed flashrom -w and flashrom -r . 2) For configuration, I copied this configuration: https://review.coreboot.org/cgit/board-status.git/tree/asus/a88xm-e/4.12-32… to .config and added the board. I have exported the vga bios from Linux using: cp /sys/devices/pci0000:00/0000:00:01.0/rom vgabios.bin . The above config does not work with make, it tries to go to a webpage for secondary payload, and that webpage is changed. Removing those two lines CONFIG_COREINFO_SECONDARY_PAYLOAD=y && CONFIG_TINT_SECONDARY_PAYLOAD=y will let me build the rom. When I do sudo flashrom -w build/coreboot.rom --programmer ch341a_spi, it sometimes says write done: Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x00000000! Expected=0x5f, Found=0xff, failed byte count from 0x00000000-0x007fffff: 0xb5 Your flash chip is in an unknown state. When I boot with Coreboot, I see a black screen. I renamed vgabios.bin to pci1002,990c.rom, and I put that file in the ~/Coreboot/ folder. Thanks for helping out,

2 3

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