coreboot March 2021

coreboot@coreboot.org

26 participants
27 discussions

by Julian Stecklina

Hello Coreboot Developers! First, I want to say that it is really a joy to work with Coreboot. The code is well-written and of high-quality. :) I'm currently trying to get Tianocore EDK2 running as a Coreboot payload in Qemu and meeting with limited success, though. I have a working configuration for the qemu q35 target. Building it for and running it with the 440fx/piix4 chipset results in the crash below. Is PIIX4 supported with Coreboot/EDK2 or should this configuration be avoided? I also appreciate any pointers in how to debug a situation like this. It looks like the crash happens in EDK2. Is there a way to get an ELF file that objdump understands, so I can see where in EDK2 code this issue originates from? BS: BS_PAYLOAD_LOAD run times (exec / console): 64 / 2 ms Jumping to boot code at 0x008008c0(0x7ff9b000) !!!! X64 Exception Type - 00(#DE - Divide Error) CPU Apic ID - 00000000 !!!! RIP - 000000007F92FAB0, CS - 0000000000000038, RFLAGS - 0000000000000202 RAX - 000000007F938C20, RCX - 000000007F938C20, RDX - 0000000000000008 RBX - 0000000000000008, RSP - 000000007FF4B278, RBP - 000000007FF666E0 RSI - 000000007FF65910, RDI - 0000000000000001 R8 - 000000007FF63480, R9 - 0000000000000038, R10 - 000000007F93CF08 R11 - 000000007FF64F08, R12 - 0000000000000000, R13 - 0000000000000080 R14 - 000000007FF66760, R15 - 000000007FAA9118 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010011, CR2 - 0000000000000000, CR3 - 000000007FC01000 CR4 - 0000000000000228, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007FBED718 0000000000000047, LDTR - 0000000000000000 IDTR - 000000007F93A018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000007FF4AED0 !!!! Can't find image information. !!!! Thanks! Julian

3 months, 1 week

New Defects reported by Coverity Scan for coreboot

by scan-admin＠coverity.com

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. 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 1 of 1 defect(s) ** CID 1451545: Parse warnings (PARSE_ERROR) /src/mainboard/ti/beaglebone/sd_media.c: 95 in () ________________________________________________________________________________________________________ *** CID 1451545: Parse warnings (PARSE_ERROR) /src/mainboard/ti/beaglebone/sd_media.c: 95 in () 89 .munmap = mmap_helper_rdev_munmap, 90 .readat = sd_readat, 91 }; 92 93 extern struct omap_image_headers headers; 94 >>> CID 1451545: Parse warnings (PARSE_ERROR) >>> function call is not allowed in a constant expression 95 static struct mmap_helper_region_device sd_mdev = MMAP_HELPER_REGION_INIT( 96 &am335x_sd_ops, COREBOOT_IMAGE_OFFSET + sizeof(headers), CONFIG_ROM_SIZE); 97 98 static bool init_done = false; 99 100 void boot_device_init(void) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 months

[coreboot - Bug #303] (New) qemu: Failure to build TianoCore UefiPayload

by coreboot＠fe80.eu

Issue #303 has been reported by Julian Stecklina. ---------------------------------------- Bug #303: qemu: Failure to build TianoCore UefiPayload https://ticket.coreboot.org/issues/303 * Author: Julian Stecklina * Status: New * Priority: Normal * Assignee: * Category: build system * Target version: ---------------------------------------- I'm trying to build Coreboot with the TianoCore payload (CONFIG_TIANOCORE_UEFIPAYLOAD=y). This fails early when building the bundled TianoCore: ~~~ Using EDK2 in-source Basetools WORKSPACE: /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore EDK_TOOLS_PATH: /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/BaseTools CONF_PATH: /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/Conf Copying $EDK_TOOLS_PATH/Conf/build_rule.template to /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/Conf/build_rule.txt Copying $EDK_TOOLS_PATH/Conf/tools_def.template to /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/Conf/tools_def.txt Copying $EDK_TOOLS_PATH/Conf/target.template to /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/Conf/target.txt Build environment: Linux-5.11.9-200.fc33.x86_64-x86_64-with-glibc2.32 Build start time: 15:10:51, Mar.29 2021 WORKSPACE = /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore EDK_TOOLS_PATH = /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/BaseTools CONF_PATH = /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/Conf PYTHON_COMMAND = /usr/bin/python3.9 build.py... : error 000E: File/directory not found in workspace /home/julian/src/own/coreboot/payloads/external/tianocore/tianocore/UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc - Failed - Build end time: 15:10:51, Mar.29 2021 Build total time: 00:00:00 ~~~ I've attached my config and the full build output. I'm building on Fedora 33 on x86_64. ---Files-------------------------------- coreboot-config (20.5 KB) build.log (90.8 KB) -- 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

4 months

Coreboot on new laptops

by Gert Vanhaerents

Hi Coreboot, We are from a computer store and we sell computers and laptops with Linux or Windows or dual boot. For Linux we are many asked for laptops with coreboot, probably due to the presence of intel ME spyware in the laptops. So, we are now investigating whether there is a possibility to offer the laptops with coreboot. Normally we buy our laptops at a distributor, we have also asked the distributor to have coreboot they don't know anything about bios/eufi or coreboot. They only deliver the laptops with the bios/eufi that the manufacturer made it, we can always ask for a bios update but not for other bios systems like coreboot. We don't have any contact with the manufacturer or have any contact data. I know there are laptops of this brand that have coreboot on it, but to buy directly ar the manufacturer we don't sell enough (i think we must sell 10.000 laptops in a quarter or more). My questions: - We i have installed coreboot, can i also boot Windows 10 or boot in dual-boot (Windows and Linux)? - The installation of coreboot is very unclair. I have looking to google but i don't realy know how can install it. - Can i install coreboot like we normally flash a bios? (startup with a efi boot stick and run a batch file, or startup in the bios and do a bios update directly from the bios with a usb stick with the flash file) - Or do i need a eeprom programmer or something like that? - Must itake out the motherboard completely of the laptop? To work with coreboot it's very important to have a very fast procedure to install it in mass production. We cannot spell a few hours on each laptop. It must be a flash file for a model laptop and a other flash file for a other model laptop. So we can install coreboot on the best selling models. Startup from a usb-stick, do a flash update wait 5 or 10 minutes and reboot, ... done. When it's possible in the procudure like above can i get some help to make the first coreboot flash. With Kind Regards, Gert

4 months

[coreboot - Bug #302] (New) You need to be root

by coreboot＠fe80.eu

Issue #302 has been reported by Tim L. ---------------------------------------- Bug #302: You need to be root https://ticket.coreboot.org/issues/302 * Author: Tim L * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- ~~~ # ./intelmetool -m iopl: Operation not permitted You need to be root. # id uid=0(root) gid=0(root) groups=0(root) ~~~ -- 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

4 months

[coreboot - Bug #301] (New) soc/amd: gpio_bank_lib.asl: IASL remarks on inefficient creation of named objects

by coreboot＠fe80.eu

Issue #301 has been reported by Paul Menzel. ---------------------------------------- Bug #301: soc/amd: gpio_bank_lib.asl: IASL remarks on inefficient creation of named objects https://ticket.coreboot.org/issues/301 * Author: Paul Menzel * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- Building amd/majolica, IASL 20200925 shows the remarks below. ``` dsdt.asl 98: Name(BUFF, Buffer(Local0) {}) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.S2BF) dsdt.asl 188: OperationRegion (GPDW, SystemMemory, Local0, 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GPRD) dsdt.asl 201: OperationRegion (GPDW, SystemMemory, Local0, 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GPWR) dsdt.asl 298: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.STXS) dsdt.asl 312: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.CTXS) dsdt.asl 326: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GRXS) dsdt.asl 342: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GTXS) ``` -- 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

4 months

coding style discussions, again.

by Patrick Georgi

Hello everybody, https://review.coreboot.org/c/coreboot/+/51825 proposes getting rid of the rule to make if-statement blocks (and the like) as short as possible. The rationale is to encourage a style that avoids subtle bugs which then need to be found by tooling such as Coverity Scan and fixed by commits like https://review.coreboot.org/51786. Julius disagrees and requests wider discussion, specifically on the mailing list. So here we are: Arguments? Opinions? Julius, maybe you want to make your case, I didn't want to risk representing a distorted position. Regards, 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

4 months

Re: [flashrom] Fail flashing

by Mike Banon

I think the only way to prevent the current leaking to the surrounding elements of a chip - is desoldering. So, if we are trying to avoid the desoldering - yes, you could try reducing the length of wires between a programmer and a test clip - i.e. to 10cm. That certainly wouldn't hurt, and sometimes it really helps to achieve the successful flashing by ISP (in-system programming) method. Please note: while there are some successful examples of using the external PSU for an ISP flashing (i.e. this [1] BBB example at libreboot wiki), depending on a motherboard design this could be dangerous according to Angel Pons comments under [2] - so using the external PSU should be avoided unless all the other options have been tried and you still don't want to solder/desolder. While looking for the examples of L530 flashing I found a thread with your comments [3]. To answer your question why the other people were also targeting a ps08a chip: this is CMOS, and clearing a CMOS memory sometimes is also important to ensure the successful boot of a proprietary BIOS - but we haven't reached this stage yet, since we're just trying to flash a BIOS into a SPI flash chip. Have you ever tested your CH341A before in other setups? If not, do you have a spare CH341A to try it with a different one? And could you try a higher powered USB port to ensure that your CH341A itself is sufficiently powered? (i.e. you may be using a USB extender for your convenience, which is fine - but that extender also shouldn't be too long) [1] https://libreboot.org/docs/install/bbb_setup.html [2] https://review.coreboot.org/c/flashrom/+/31830 (this was my patch for the older version of flashrom useful in a unreliable flashing setup, but I only successfully read with it and never successfully wrote). [3] https://www.badcaps.net/forum/showthread.php?t=61517 P.S. I'm not sure how you can measure the leakage with a multimeter, and in any case knowing the exact values isn't necessary - when we already know the cause of unsuccessful flashing and just need to find out how to resolve it. On Wed, Mar 24, 2021 at 8:46 PM G. Nalin <giammi56(a)hotmail.com> wrote: > > HI, > > I have been recommended to desolder the BIOS chip to use the CH341a reliably, but I would like to avoid it and use the clip instead! Should I simply cut shorter the clip wires? Is there something I can do to ground the motherboard or avoid the leaking? How can I measure it (I have just a multimeter here atm). > > I don´t know how to supply the power externally while the EEPROM is connected to the USB. Could you indicate me a reference? > > I tried to verify the dumo, but if fails because there is some writing involved. > $ sudo flashrom -V -p ch341a_spi -v bios1b.img > > I don´t have a reference so I can´t say if the HEX or BIN dump is actually at least partially valid. It is not all FF and 00. > > Cheers, > > Giammarco Nalin > > Handy: +4915252667614 > Adresse: Hausener Weg 96, 60489, Frankfurt am Main > > > ________________________________ > From: Mike Banon <mikebdp2(a)gmail.com> > Sent: 24 March 2021 13:40 > To: G. Nalin <giammi56(a)hotmail.com> > Cc: flashrom(a)flashrom.org <flashrom(a)flashrom.org> > Subject: Re: [flashrom] Fail flashing > > Could you please verify that at least a part of the binary file got > flashed correctly? If yes, these reliability problems could be caused > by your setup - i.e. too long wires or the surrounding elements of the > BIOS chip are drawing too much current - causing a voltage drop on the > chip itself and the remaining is insufficient for the reliable > flashing (in this case I could recommend using the external power > supply for 3.3V line) > > On Wed, Mar 24, 2021 at 9:50 AM G. Nalin <giammi56(a)hotmail.com> wrote: > > > > Hi all, > > I am trying to flash a WInbond w25q64bv BIOS chip of a Thinkpad L530. I am on Ubuntu 20.04. Using a EEPROM ch341a and I am not able to copy correctly the content of the chip: diff and md5sum return all the time some errors. Trying to erase the chip gives random errors like > > > > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > > Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi. > > Reading old flash chip contents... done. > > Erasing and writing flash chip... FAILED at 0x000b6000! Expected=0xff, Found=0xae, failed byte count from 0x000b6000-0x000b6fff: 0x382 > > ERASE FAILED! > > > > and so on. When I prompt the internal status I get: > > > > $sudo flashrom -V -p internal > > > > flashrom v1.2 on Linux 5.8.0-45-generic (x86_64) > > flashrom is free software, get the source code at https://flashrom.org > > > > flashrom was built with libpci 3.6.4, GCC 9.2.1 20200304, little endian > > Command line (3 args): flashrom -V -p internal > > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > > Initializing internal programmer > > /sys/class/mtd/mtd0 does not exist > > No coreboot table found. > > Using Internal DMI decoder. > > DMI string chassis-type: "Notebook" > > Laptop detected via DMI. > > DMI string system-manufacturer: "LENOVO" > > DMI string system-product-name: "20AWS01V01" > > DMI string system-version: "ThinkPad T440p" > > DMI string baseboard-manufacturer: "LENOVO" > > DMI string baseboard-product-name: "20AWS01V01" > > DMI string baseboard-version: "0B98401 PRO" > > W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect. > > Active config mode, unknown reg 0x20 ID: 00. > > Found chipset "Intel QM87" with PCI ID 8086:8c4f. > > This chipset is marked as untested. If you are using an up-to-date version > > of flashrom *and* were (not) able to successfully update your firmware with it, > > then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. > > Thank you! > > Enabling flash write... Root Complex Register Block address = 0xfed1c000 > > GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) > > Top Swap: not enabled > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x4 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x5 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x6 > > 0x7fffffff/0x7fffffff FWH IDSEL: 0x7 > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > 0x7fffffff/0x7fffffff FWH decode enabled > > Maximum FWH chip size: 0x100000 bytes > > SPI Read Configuration: prefetching enabled, caching enabled, > > BIOS_CNTL = 0x2b: BIOS Lock Enable: enabled, BIOS Write Enable: enabled > > Warning: BIOS region SMM protection is enabled! > > Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed. > > New value is 0x2b. > > SPIBAR = 0x00007f0d5db92000 + 0x3800 > > 0x04: 0xe008 (HSFS) > > HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 > > SPI Configuration is locked down. > > Reading OPCODES... done > > 0x06: 0x0000 (HSFC) > > HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 > > 0x50: 0x00004a4b (FRAP) > > BMWAG 0x00, BMRAG 0x00, BRWA 0x4a, BRRA 0x4b > > 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. > > 0x58: 0x0bff0500 FREG1: BIOS region (0x00500000-0x00bfffff) is read-write. > > 0x5C: 0x04ff0003 FREG2: Management Engine region (0x00003000-0x004fffff) is locked. > > 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write. > > Not all flash regions are freely accessible by flashrom. This is most likely > > due to an active ME. Please see https://flashrom.org/ME for details. > > 0x74: 0x8aaf0800 PR0: Warning: 0x00800000-0x00aaffff is read-only. > > 0x78: 0x8ab00ab0 PR1: Warning: 0x00ab0000-0x00ab0fff is read-only. > > 0x7C: 0x8adf0ab1 PR2: Warning: 0x00ab1000-0x00adffff is read-only. > > 0x80: 0x8bff0b40 PR3: Warning: 0x00b40000-0x00bfffff is read-only. > > At least some flash regions are read protected. You have to use a flash > > layout and include only accessible regions. For write operations, you'll > > additionally need the --noverify-all switch. See manpage for more details. > > 0x90: 0xc0 (SSFS) > > SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 > > 0x91: 0xf94000 (SSFC) > > SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1 > > 0x94: 0x0606 (PREOP) > > 0x96: 0x3f90 (OPTYPE) > > 0x98: 0x03003505 (OPMENU) > > 0x9c: 0x9f20d802 (OPMENU+4) > > 0xa0: 0x00000000 (BBAR) > > 0xc4: 0x80802025 (LVSCC) > > LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 > > 0xc8: 0x80000000 (UVSCC) > > UVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0 > > 0xd0: 0x50444653 (FPB) > > Enabling hardware sequencing due to multiple flash chips detected. > > OK. > > The following protocols are supported: Programmer-specific. > > Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 2 attached SPI flash chips with a combined density of 12288 kB. > > The first partition ranges from 0x000000 to 0x652fff. > > In that range are 1619 erase blocks with 4096 B each. > > The second partition ranges from 0x653000 to 0xbfffff. > > In that range are 1453 erase blocks with 4096 B each. > > Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) mapped at physical address 0x0000000000000000. > > Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific). > > No operations were specified. > > Restoring MMIO space at 0x7f0d5db958a0 > > Restoring PCI config space for 00:1f:0 reg 0xdc > > > > /////////////////////////// > > > > $ sudo flashrom -V -p ch341a_spi > > flashrom v1.2 on Linux 5.8.0-45-generic (x86_64) > > flashrom is free software, get the source code at https://flashrom.org > > > > flashrom was built with libpci 3.6.4, GCC 9.2.1 20200304, little endian > > Command line (3 args): flashrom -V -p ch341a_spi > > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > > Initializing ch341a_spi programmer > > Device revision is 3.0.4 > > The following protocols are supported: SPI. > > > > ...... > > > > Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi. > > Chip status register is 0x00. > > > > This chip may contain one-time programmable memory. flashrom cannot read > > and may never be able to write it, hence it may not be able to completely > > clone the contents of this chip (see man page for details). > > > > > > > > Cheers, > > > > GN > > > > _______________________________________________ > > flashrom mailing list -- flashrom(a)flashrom.org > > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

4 months, 1 week

Apollo Lake platform does not keep RTC time on reboot

by Wolfgang Kamp - datakamp

Hi, I found a problem with keeping RTC time on reboot or power off even if battery is connected. The soc_get_rtc_failed routine in pmutil.c of apollolake SOC does not read and reset after read the General PM Configuration 1 register. As a result RTC always failed. Is there any Konfig what I overlooked or have soc_get_rtc_failed to be expanded? Kind regards, Wolfgang Kamp

4 months, 1 week

New Defects reported by Coverity Scan for coreboot

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 14 new defect(s) introduced to coreboot found with Coverity Scan. 11 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 14 of 14 defect(s) ** CID 1451398: Control flow issues (DEADCODE) /3rdparty/chromeec/driver/usb_mux/usb_mux.c: 400 in hc_usb_pd_mux_ack() ________________________________________________________________________________________________________ *** CID 1451398: Control flow issues (DEADCODE) /3rdparty/chromeec/driver/usb_mux/usb_mux.c: 400 in hc_usb_pd_mux_ack() 394 { 395 __maybe_unused const struct ec_params_usb_pd_mux_ack *p = args->params; 396 397 if (!IS_ENABLED(CONFIG_USB_MUX_AP_ACK_REQUEST)) 398 return EC_RES_INVALID_COMMAND; 399 >>> CID 1451398: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "task_set_event(TASK_ID_PD_C...". 400 task_set_event(PD_PORT_TO_TASK_ID(p->port), PD_EVENT_AP_MUX_DONE); 401 402 return EC_RES_SUCCESS; 403 } 404 DECLARE_HOST_COMMAND(EC_CMD_USB_PD_MUX_ACK, 405 hc_usb_pd_mux_ack, ** CID 1451397: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1451397: Memory - corruptions (ARRAY_VS_SINGLETON) /src/lib/selfboot.c: 238 in selfload_mapped() 232 { 233 uintptr_t entry = 0; 234 struct cbfs_payload_segment *cbfssegs; 235 236 cbfssegs = &((struct cbfs_payload *)mapping)->segments; 237 >>> CID 1451397: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "cbfssegs" to function "check_payload_segments" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 238 if (check_payload_segments(cbfssegs, dest_type)) 239 return false; 240 241 if (load_payload_segments(cbfssegs, &entry)) 242 return false; 243 ** CID 1451396: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1451396: Memory - corruptions (OVERRUN) /src/lib/selfboot.c: 241 in selfload_mapped() 235 236 cbfssegs = &((struct cbfs_payload *)mapping)->segments; 237 238 if (check_payload_segments(cbfssegs, dest_type)) 239 return false; 240 >>> CID 1451396: Memory - corruptions (OVERRUN) >>> Overrunning struct type cbfs_payload_segment of 28 bytes by passing it to a function which accesses it at byte offset 55. 241 if (load_payload_segments(cbfssegs, &entry)) 242 return false; 243 244 printk(BIOS_SPEW, "Loaded segments\n"); 245 246 /* Pass cbtables to payload if architecture desires it. */ ** CID 1451395: Control flow issues (NESTING_INDENT_MISMATCH) /src/soc/amd/common/block/i2c/i2c.c: 105 in dw_i2c_soc_init() ________________________________________________________________________________________________________ *** CID 1451395: Control flow issues (NESTING_INDENT_MISMATCH) /src/soc/amd/common/block/i2c/i2c.c: 105 in dw_i2c_soc_init() 99 if (ctrlr->mode == I2C_PERIPHERAL_MODE || !ctrlr->bar || 100 cfg->early_init != is_early_init) 101 continue; 102 103 if (dw_i2c_init(bus, cfg)) 104 printk(BIOS_ERR, "Failed to init i2c bus %d\n", bus); >>> CID 1451395: Control flow issues (NESTING_INDENT_MISMATCH) >>> This statement is indented to column 25, as if it were nested within the preceding parent statement, but it is not. 105 continue; 106 107 soc_i2c_misc_init(bus, cfg); 108 } 109 } 110 ** CID 1451394: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) /src/vendorcode/mediatek/mt8192/dramc/dramc_pi_calibration_api.c: 3630 in () ________________________________________________________________________________________________________ *** CID 1451394: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) /src/vendorcode/mediatek/mt8192/dramc/dramc_pi_calibration_api.c: 3630 in () 3624 3625 msg("[WriteLevelingPosCal] DQS PI B0/B1 = %d/%d\n", wrlevel_dqs_delay[0], wrlevel_dqs_delay[1]); 3626 } 3627 #endif 3628 3629 #define SET_PATTERN_MANUALLY_FOR_DEBUG 1 >>> CID 1451394: Parse warnings (PW.PARAM_SET_BUT_NOT_USED) >>> parameter "isAutoK" was set but never used 3630 DRAM_STATUS_T DramcWriteLeveling(DRAMC_CTX_T *p, u8 isAutoK, WLEV_DELAY_BASED_T stDelayBase) 3631 { 3632 // Note that below procedure is based on "ODT off" 3633 DRAM_STATUS_T KResult = DRAM_FAIL; 3634 3635 U8 byte_i, rank_i, ucDoneFlg; ** CID 1451393: Control flow issues (DEADCODE) /3rdparty/chromeec/driver/charger/isl923x.c: 177 in get_amon_bmon() ________________________________________________________________________________________________________ *** CID 1451393: Control flow issues (DEADCODE) /3rdparty/chromeec/driver/charger/isl923x.c: 177 in get_amon_bmon() 171 static int get_amon_bmon(int chgnum, enum isl923x_amon_bmon amon, 172 enum isl923x_mon_dir direction, int *adc) 173 { 174 int reg, ret; 175 176 if (IS_ENABLED(CHARGER_ISL9238X)) { >>> CID 1451393: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "ret = raw_read16(chgnum, 76...". 177 ret = raw_read16(chgnum, ISL9238_REG_CONTROL3, &reg); 178 if (ret) 179 return ret; 180 181 /* Switch direction */ 182 if (direction) ** CID 1451392: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 699 in i2c_read_string() ________________________________________________________________________________________________________ *** CID 1451392: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 699 in i2c_read_string() 693 694 if (len && block_length > (len - 1)) 695 data_length = len - 1; 696 else 697 data_length = block_length; 698 >>> CID 1451392: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "({...; 0;}) && addr_flags & (8192U /* 1U << 13 */)" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 699 if (IS_ENABLED(CONFIG_SMBUS_PEC) && 700 I2C_USE_PEC(addr_flags)) { 701 uint8_t addr_8bit = 702 I2C_STRIP_FLAGS(addr_flags) << 1; 703 uint8_t out[3] = {addr_8bit, reg, addr_8bit | 1}; 704 uint8_t pec, pec_remote; ** CID 1451391: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 775 in i2c_write_block() ________________________________________________________________________________________________________ *** CID 1451391: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 775 in i2c_write_block() 769 int i, rv; 770 uint8_t reg_address = offset, pec = 0; 771 772 if (!IS_ENABLED(CONFIG_SMBUS_PEC) && I2C_USE_PEC(addr_flags)) 773 return EC_ERROR_UNIMPLEMENTED; 774 >>> CID 1451391: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "({...; 0;}) && addr_flags & (8192U /* 1U << 13 */)" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 775 if (IS_ENABLED(CONFIG_SMBUS_PEC) && I2C_USE_PEC(addr_flags)) { 776 uint8_t addr_8bit = I2C_STRIP_FLAGS(addr_flags) << 1; 777 778 pec = cros_crc8(&addr_8bit, sizeof(uint8_t)); 779 pec = cros_crc8_arg(data, len, pec); 780 } ** CID 1451390: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 331 in platform_ec_i2c_write() ________________________________________________________________________________________________________ *** CID 1451390: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 331 in platform_ec_i2c_write() 325 const uint16_t addr_flags, 326 const uint8_t *out, int out_size) 327 { 328 if (!IS_ENABLED(CONFIG_SMBUS_PEC) && I2C_USE_PEC(addr_flags)) 329 return EC_ERROR_UNIMPLEMENTED; 330 >>> CID 1451390: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "({...; 0;}) && addr_flags & (8192U /* 1U << 13 */)" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 331 if (IS_ENABLED(CONFIG_SMBUS_PEC) && I2C_USE_PEC(addr_flags)) { 332 int i, rv; 333 uint8_t addr_8bit = I2C_STRIP_FLAGS(addr_flags) << 1; 334 uint8_t pec; 335 336 pec = cros_crc8(&addr_8bit, 1); ** CID 1451389: Incorrect expression (MISSING_COMMA) /src/soc/amd/picasso/mca.c: 140 in () ________________________________________________________________________________________________________ *** CID 1451389: Incorrect expression (MISSING_COMMA) /src/soc/amd/picasso/mca.c: 140 in () 134 } 135 136 static const char *const mca_bank_name[] = { 137 "Load-store unit", 138 "Instruction fetch unit", 139 "L2 cache unit", >>> CID 1451389: Incorrect expression (MISSING_COMMA) >>> In the initialization of "mca_bank_name", a suspicious concatenated string ""Decode unit"" is produced due to a missing comma between lines. 140 "Decode unit" 141 "", 142 "Execution unit", 143 "Floating point unit", 144 "L3 cache unit" 145 }; ** CID 1451388: (BAD_SHIFT) /3rdparty/chromeec/core/cortex-m/mpu.c: 142 in mpu_config_region_greedy() /3rdparty/chromeec/core/cortex-m/mpu.c: 161 in mpu_config_region_greedy() /3rdparty/chromeec/core/cortex-m/mpu.c: 142 in mpu_config_region_greedy() /3rdparty/chromeec/core/cortex-m/mpu.c: 161 in mpu_config_region_greedy() ________________________________________________________________________________________________________ *** CID 1451388: (BAD_SHIFT) /3rdparty/chromeec/core/cortex-m/mpu.c: 142 in mpu_config_region_greedy() 136 137 /* 138 * Generate the subregion mask by walking through each, 139 * disabling if it is not completely contained in the requested 140 * range. 141 */ >>> CID 1451388: (BAD_SHIFT) >>> In expression "1 << natural_alignment", left shifting by more than 31 bits has undefined behavior. The shift amount, "natural_alignment", is as much as 32. 142 subregion_base = addr & ~((1 << natural_alignment) - 1); 143 subregion_size = 1 << (natural_alignment - 3); 144 *consumed = 0; 145 for (int sr_idx = 0; sr_idx < 8; sr_idx++) { 146 if (subregion_base < addr || 147 (subregion_base + subregion_size) > (addr + size)) /3rdparty/chromeec/core/cortex-m/mpu.c: 161 in mpu_config_region_greedy() 155 } 156 } else { 157 /* Not using subregions; all enabled */ 158 *consumed = 1 << natural_alignment; 159 } 160 >>> CID 1451388: (BAD_SHIFT) >>> In expression "1 << natural_alignment", left shifting by more than 31 bits has undefined behavior. The shift amount, "natural_alignment", is as much as 32. 161 return mpu_update_region(region, 162 addr & ~((1 << natural_alignment) - 1), 163 natural_alignment, 164 attr, enable, subregion_disable); 165 } 166 /3rdparty/chromeec/core/cortex-m/mpu.c: 142 in mpu_config_region_greedy() 136 137 /* 138 * Generate the subregion mask by walking through each, 139 * disabling if it is not completely contained in the requested 140 * range. 141 */ >>> CID 1451388: (BAD_SHIFT) >>> In expression "1 << natural_alignment", left shifting by more than 31 bits has undefined behavior. The shift amount, "natural_alignment", is 32. 142 subregion_base = addr & ~((1 << natural_alignment) - 1); 143 subregion_size = 1 << (natural_alignment - 3); 144 *consumed = 0; 145 for (int sr_idx = 0; sr_idx < 8; sr_idx++) { 146 if (subregion_base < addr || 147 (subregion_base + subregion_size) > (addr + size)) /3rdparty/chromeec/core/cortex-m/mpu.c: 161 in mpu_config_region_greedy() 155 } 156 } else { 157 /* Not using subregions; all enabled */ 158 *consumed = 1 << natural_alignment; 159 } 160 >>> CID 1451388: (BAD_SHIFT) >>> In expression "1 << natural_alignment", left shifting by more than 31 bits has undefined behavior. The shift amount, "natural_alignment", is 32. 161 return mpu_update_region(region, 162 addr & ~((1 << natural_alignment) - 1), 163 natural_alignment, 164 attr, enable, subregion_disable); 165 } 166 ** CID 1451387: Control flow issues (UNREACHABLE) /src/soc/amd/common/block/i2c/i2c.c: 107 in dw_i2c_soc_init() ________________________________________________________________________________________________________ *** CID 1451387: Control flow issues (UNREACHABLE) /src/soc/amd/common/block/i2c/i2c.c: 107 in dw_i2c_soc_init() 101 continue; 102 103 if (dw_i2c_init(bus, cfg)) 104 printk(BIOS_ERR, "Failed to init i2c bus %d\n", bus); 105 continue; 106 >>> CID 1451387: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "soc_i2c_misc_init(bus, cfg);". 107 soc_i2c_misc_init(bus, cfg); 108 } 109 } 110 111 void i2c_soc_early_init(void) 112 { ** CID 1451386: Control flow issues (UNREACHABLE) /src/mainboard/google/poppy/variants/rammus/mainboard.c: 44 in get_wifi_sar_cbfs_filename() ________________________________________________________________________________________________________ *** CID 1451386: Control flow issues (UNREACHABLE) /src/mainboard/google/poppy/variants/rammus/mainboard.c: 44 in get_wifi_sar_cbfs_filename() 38 sku_id = variant_board_sku(); 39 if (sku_id & 0x200) 40 return "wifi_sar-shyvana.hex"; 41 else 42 return "wifi_sar-leona.hex"; 43 >>> CID 1451386: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "return "wifi_sar_defaults.h...". 44 return WIFI_SAR_CBFS_DEFAULT_FILENAME; ** CID 1451385: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 289 in platform_ec_i2c_read() ________________________________________________________________________________________________________ *** CID 1451385: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/chromeec/common/i2c_controller.c: 289 in platform_ec_i2c_read() 283 static int platform_ec_i2c_read(const int port, const uint16_t addr_flags, 284 uint8_t reg, uint8_t *in, int in_size) 285 { 286 if (!IS_ENABLED(CONFIG_SMBUS_PEC) && I2C_USE_PEC(addr_flags)) 287 return EC_ERROR_UNIMPLEMENTED; 288 >>> CID 1451385: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "({...; 0;}) && addr_flags & (8192U /* 1U << 13 */)" is always false regardless of the values of its operands. This occurs as the logical operand of "if". 289 if (IS_ENABLED(CONFIG_SMBUS_PEC) && I2C_USE_PEC(addr_flags)) { 290 int i, rv; 291 /* addr_8bit = 7 bit addr_flags + 1 bit r/w */ 292 uint8_t addr_8bit = I2C_STRIP_FLAGS(addr_flags) << 1; 293 uint8_t out[3] = {addr_8bit, reg, addr_8bit | 1}; 294 uint8_t pec_local = 0, pec_remote; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 months, 1 week

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2021