coreboot April 2022

coreboot@coreboot.org

51 participants
44 discussions

Memtest 86+ fork
by Sameeruddin Shaik 03 Apr '22

03 Apr '22

Hi all, I wanted to work on below ticket https://ticket.coreboot.org/issues/184 Is there anyone working on it. Any inputs/hints would be appreciated. --sameer.

3 2

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

01 Apr '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 6 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1487636: Resource leaks (RESOURCE_LEAK) /util/cbfstool/fmd_parser.y: 173 in parse_descriptor() ________________________________________________________________________________________________________ *** CID 1487636: Resource leaks (RESOURCE_LEAK) /util/cbfstool/fmd_parser.y: 173 in parse_descriptor() 167 struct descriptor_node *next_node = cur_node->next; 168 free(cur_node); 169 cur_node = next_node; 170 } 171 } else { 172 region->list = NULL; >>> CID 1487636: Resource leaks (RESOURCE_LEAK) >>> Variable "region" going out of scope leaks the storage it points to. 173 } 174 return region; 175 } 176 177 void yyerror(const char *s) 178 { 179 fprintf(stderr, "%s\n", s); ** CID 1487635: Incorrect expression (SIZEOF_MISMATCH) /src/soc/qualcomm/common/qclib.c: 172 in qclib_load_and_run() ________________________________________________________________________________________________________ *** CID 1487635: Incorrect expression (SIZEOF_MISMATCH) /src/soc/qualcomm/common/qclib.c: 172 in qclib_load_and_run() 166 memset(_ddr_training, 0, REGION_SIZE(ddr_training)); 167 } 168 qclib_add_if_table_entry(QCLIB_TE_DDR_TRAINING_DATA, 169 _ddr_training, REGION_SIZE(ddr_training), 0); 170 171 /* Attempt to read MEM CHIP information */ >>> CID 1487635: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "mem_chip_addr" of type "void *" and argument "8U /* sizeof (mem_chip_addr) */" to function "qclib_add_if_table_entry" is suspicious. 172 qclib_add_if_table_entry(QCLIB_TE_MEM_CHIP_INFO, 173 mem_chip_addr, sizeof(mem_chip_addr), 0); 174 175 /* Attempt to load PMICCFG Blob */ 176 data_size = cbfs_load(CONFIG_CBFS_PREFIX "/pmiccfg", 177 _pmic, REGION_SIZE(pmic)); ** CID 1487634: Integer handling issues (SIGN_EXTENSION) /src/cpu/intel/common/common_init.c: 226 in set_energy_perf_pref() ________________________________________________________________________________________________________ *** CID 1487634: Integer handling issues (SIGN_EXTENSION) /src/cpu/intel/common/common_init.c: 226 in set_energy_perf_pref() 220 * prefer energy efficiency. 221 * This function needs to be called when HWP_ENABLE is set. 222 */ 223 void set_energy_perf_pref(u8 pref) 224 { 225 msr_unset_and_set(IA32_HWP_REQUEST, IA32_HWP_REQUEST_EPP_MASK, >>> CID 1487634: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "pref" with type "u8" (8 bits, unsigned) is promoted in "pref << 24" to type "int" (32 bits, signed), then sign-extended to type "unsigned long long" (64 bits, unsigned). If "pref << 24" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 226 pref << IA32_HWP_REQUEST_EPP_SHIFT); ** CID 1487633: Error handling issues (CHECKED_RETURN) /src/drivers/i2c/tpm/cr50.c: 257 in cr50_i2c_tis_ready() ________________________________________________________________________________________________________ *** CID 1487633: Error handling issues (CHECKED_RETURN) /src/drivers/i2c/tpm/cr50.c: 257 in cr50_i2c_tis_ready() 251 } 252 253 /* cr50 requires all 4 bytes of status register to be written */ 254 static void cr50_i2c_tis_ready(struct tpm_chip *chip) 255 { 256 uint8_t buf[4] = { TPM_STS_COMMAND_READY }; >>> CID 1487633: Error handling issues (CHECKED_RETURN) >>> Calling "cr50_i2c_write" without checking return value (as is done elsewhere 4 out of 5 times). 257 cr50_i2c_write(TPM_STS(chip->vendor.locality), buf, sizeof(buf)); 258 mdelay(CR50_TIMEOUT_SHORT_MS); 259 } 260 261 /* cr50 uses bytes 3:2 of status register for burst count and 262 * all 4 bytes must be read */ ** CID 1487632: Null pointer dereferences (REVERSE_INULL) /src/drivers/wifi/generic/acpi.c: 539 in wifi_ssdt_write_properties() ________________________________________________________________________________________________________ *** CID 1487632: Null pointer dereferences (REVERSE_INULL) /src/drivers/wifi/generic/acpi.c: 539 in wifi_ssdt_write_properties() 533 534 static void wifi_ssdt_write_properties(const struct device *dev, const char *scope) 535 { 536 bool is_cnvi_ddr_rfim_enabled = false; 537 538 const struct drivers_wifi_generic_config *config = dev->chip_info; >>> CID 1487632: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "dev" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 539 if (dev && config) 540 is_cnvi_ddr_rfim_enabled = config->enable_cnvi_ddr_rfim; 541 542 /* Scope */ 543 acpigen_write_scope(scope); 544 ** CID 1487631: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1487631: Memory - corruptions (OVERRUN) /src/mainboard/google/herobrine/bootblock.c: 14 in bootblock_mainboard_init() 8 9 void bootblock_mainboard_init(void) 10 { 11 setup_chromeos_gpios(); 12 13 if (CONFIG(MAINBOARD_HAS_I2C_TPM_CR50)) >>> CID 1487631: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 12 by passing argument "14U" in call to "i2c_init". 14 i2c_init(CONFIG_DRIVER_TPM_I2C_BUS, I2C_SPEED_FAST); /* H1/TPM I2C */ 15 16 if (CONFIG(MAINBOARD_HAS_SPI_TPM_CR50)) 17 qup_spi_init(CONFIG_DRIVER_TPM_SPI_BUS, 1010 * KHz); /* H1/TPM SPI */ 18 19 if (CONFIG(EC_GOOGLE_CHROMEEC)) 20 qup_spi_init(CONFIG_EC_GOOGLE_CHROMEEC_SPI_BUS, 1010 * KHz); /* EC SPI */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Support to Openpower platforms
by ratatouille gamer 01 Apr '22

01 Apr '22

the openpower have created this new firmware for boot openpower platforms is possible to coreboot use this base to write a new code for best support in openpower socs? https://github.com/open-power/hostboot

4 3

Re: PSE devices enumeration in corevoot
by Rao G 01 Apr '22

01 Apr '22

Hi Sheng, In the coreboot log I see PCI: 00:1d.0 [8086/4bb3] disabled PCI: Static device PCI: 00:1d.1 not found, disabling it. PCI: Static device PCI: 00:1d.2 not found, disabling it. In the FSP debug log I see PSE TSN Device: Device Id: 0xFFFF, Vendor Id: 0xFFFF PSE TSN Device: Device Id: 0xFFFF, Vendor Id: 0xFFFF Thanks Ranga Thanks Ranga On Thu, Mar 31, 2022 at 3:04 PM Rao G <grao.v80(a)gmail.com> wrote: > Hi Sheng, > > Thanks for your email and response. > > 1. Yes I used unsigned binary - PSE_FW that came along with 638228_PSE > > 2. In Device Tree > device pci 1d.0 off end # Intel Programmable Services Engine IPC > (local host to PSE) > device pci 1d.1 on end # Intel Programmable Services Engine > Time-Sensitive Networking GbE 0 > device pci 1d.2 on end # Intel Programmable Services Engine > Time-Sensitive Networking GbE 1 > > 3. This is not an RVP but a platform with EHL SoC and I could boot to > OS/Ubuntu with coreboot BIOS > > Do these TSN GbE devices need MAC programming? I don't see them enumerated > from EFI Shell or in OS/spci > > Thanks > Ranga > > > On Thu, Mar 31, 2022 at 2:34 PM Lean Sheng Tan <sheng.tan(a)9elements.com> > wrote: > >> Hi Ranga, >> Are you using Intel RVP? Yes you should at least be able to see the PSE >> TSN working if the PSE binary is included correctly (remember to include >> the 'unsigned' PSE binary from Intel), by turning on PSE TSN devices in >> devicetree.cb: >> device pci 1d.1 on end # Intel PSE Time-Sensitive Networking GbE 0 >> device pci 1d.2 on end # Intel PSE Time-Sensitive Networking GbE 1 >> >> Thanks, >> Sheng >> >> On Tue, 29 Mar 2022 at 18:32, Rao G <grao.v80(a)gmail.com> wrote: >> >>> Hi All, >>> >>> Did anybody work on Elkhart Lake that comes with PSE Firmware? >>> I don't see any devices getting enumerated which are under PSE I2C,UART, >>> Gbe,TSN >>> >>> The logs shows >>> >>> PSE Firmware Status is A138 read from address FE400034 >>> BIOS: PSE FW is loaded and running >>> >>> Looks like FSP is disabling PSE devices to enumerate >>> >>> Is this binary enough for coreboot? PSE_FW.bin >>> [image: image.png] >>> >>> Appreciate any pointers that would help to enumerate PSE devices in EFI >>> Shell >>> >>> Thanks >>> Ranga >>> _______________________________________________ >>> coreboot mailing list -- coreboot(a)coreboot.org >>> To unsubscribe send an email to coreboot-leave(a)coreboot.org >>> >>

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2022