coreboot March 2021

coreboot@coreboot.org

26 participants
31 discussions

coding style discussions, again.
by Patrick Georgi 26 Mar '21

26 Mar '21

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

3 2

Re: [flashrom] Fail flashing
by Mike Banon 25 Mar '21

25 Mar '21

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/

1 0

Apollo Lake platform does not keep RTC time on reboot
by Wolfgang Kamp - datakamp 25 Mar '21

25 Mar '21

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

1 0

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

25 Mar '21

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…

1 0

TrenchBoot forum starts in 3 hours! what TrenchBoot can give you on top of coreboot?
by Mike Banon 24 Mar '21

24 Mar '21

Dear friends, in just 3 hours (16:00 GMT) there's a TrenchBoot forum - and you are welcome to visit us at https://trenchboot.org/tdf-schedule.html . To those who are new to TrenchBoot and wonder what it's all about: 1) please take a look at my small write-up on what advantage TrenchBoot could give you on top of coreboot firmware - [1] 2) check out the 3mdeb articles about TrenchBoot - [2] 3) and of course join the #trenchboot channel on OSFW Slack - [3] - for the archived videos with more info! [1] https://www.reddit.com/r/3mdeb/comments/mbjak0/events_trenchboot_forum_on_2… [2] https://blog.3mdeb.com/tags/trenchboot/ [3] https://osfw.slack.com/ -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Protectli FW6C HAP bit
by lain 23 Mar '21

23 Mar '21

Does somebody successfully operates this Platform with HAP bit set ?

2 3

Re: CPU and MB temperature
by web25322986p1 21 Mar '21

21 Mar '21

*Hi MikeI recorded the patch, unfortunately no success, does not boot. I'm not sure that I did everything right, Google translators must use and the result is not easy to understand. For the time being the .rom File without patching again, so he starts. Everything with Menuconfig would manage the passable way for a man of my age. Is the patch incorporated, in the future, so that I can try again later?Best regards and thank you Gottfried * -- ********************* Gottfried Kunze Telefon 03421 7732269 Mobil 0160 91012179

2 1

Listing an address with gdb
by Himanshu Chauhan 19 Mar '21

19 Mar '21

Hi, I am working on a hypervisor and running coreboot as guest. During a VMExit, I am seeing coreboot RIPs. Since coreboot is mix of 16-bit/32-bit code and because of relocations, I not able to find the listing of the code at specific address. For example, address is: 0x7f37806 I want to attach the coreboot binary to GDB and then do list *0x7f37806 How can I do that? Regards Himanshu

2 3

CPU and MB temperature
by web25322986p1 18 Mar '21

18 Mar '21

*Hi For me, Coreboot works on an Asus F2A85-M and A88XM-e. It lacks the CPU and MB temperature in LM sensors, there are negative values and the fan control does not work. I have not activated Hudson blobs and leave all settings, except for the insertion of onboard graphic file and identifier. Which settings in Menuconfig are the temperatures pass properly? Thanks for good tips Gottfried * -- ********************* Gottfried Kunze Telefon 03421 7732269 Mobil 0160 91012179

2 1

Kann keinen Thread eröffnen
by web25322986p1 18 Mar '21

18 Mar '21

Hallo, ich bitte um Hilfe Ich habe mich bei der Mailinglistcoreboot(a)coreboot.org angemeldet, um eine Frage zu stellen. Bei den Boards F2A85-M und A88XM-E mit coreboot bekommt lmsensors keine CPU- u. MB Temperatur, der Lüfter wird nicht gesteuert. Trotz Anmeldung bei der Mailiglist (bin eingeloggt) kann ich jedoch keinen Thread beginnen. Ich erhalte stets: *Error 404 not found. ??? Gottfried * -- ********************* Gottfried Kunze Telefon 03421 7732269 Mobil 0160 91012179

3 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 March 2021