July 2019 - coreboot - mail.coreboot.org

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com July 10, 2019

July 10, 2019

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 52 new defect(s) introduced to coreboot found with Coverity Scan. 146 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 20 of 52 defect(s) ** CID 1403002: (UNINIT) /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 548 in dramc_find_gating_window() /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 542 in dramc_find_gating_window() ________________________________________________________________________________________________________ *** CID 1403002: (UNINIT) /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 548 in dramc_find_gating_window() 542 pass_count_1[dqs]++; 543 544 if (pass_begin[dqs] == 1 && 545 pass_count_1[dqs] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) 546 dqs_high[dqs] = 0; 547 >>> CID 1403002: (UNINIT) >>> Using uninitialized value "pass_count_1[0]". 548 if (pass_count_1[0] * DQS_GW_FINE_STEP > DQS_GW_FINE_END && 549 pass_count_1[1] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) { 550 dramc_dbg("All bytes gating window > 1 coarse_tune," 551 " Early break\n"); 552 *dly_fine_xt = DQS_GW_FINE_END; 553 *coarse_tune = GATING_END; /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 542 in dramc_find_gating_window() 536 dramc_dbg("[Byte %d]First pass (%d, %d, %d)\n", 537 dqs, dly_coarse_large, 538 dly_coarse_0p5t, *dly_fine_xt); 539 } 540 541 if (pass_begin[dqs] == 1) >>> CID 1403002: (UNINIT) >>> Using uninitialized value "pass_count_1[dqs]". 542 pass_count_1[dqs]++; 543 544 if (pass_begin[dqs] == 1 && 545 pass_count_1[dqs] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) 546 dqs_high[dqs] = 0; 547 ** CID 1403001: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1403001: Null pointer dereferences (FORWARD_NULL) /src/soc/mediatek/mt8183/gpio.c: 184 in gpio_set_spi_driving() 178 case 5: 179 reg = (void *)(IOCFG_LM_BASE + GPIO_DRV0_OFFSET); 180 offset = 8; 181 break; 182 } 183 >>> CID 1403001: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "reg" to "read32", which dereferences it. 184 clrsetbits_le32(reg, 0xf << offset, reg_val << offset); ** CID 1403000: Null pointer dereferences (NULL_RETURNS) /src/mainboard/amd/serengeti_cheetah_fam10/get_bus_conf.c: 40 in get_hcid() ________________________________________________________________________________________________________ *** CID 1403000: Null pointer dereferences (NULL_RETURNS) /src/mainboard/amd/serengeti_cheetah_fam10/get_bus_conf.c: 40 in get_hcid() 34 u32 busn = (sysconf.pci1234[i] >> 12) & 0xff; 35 u32 devn = sysconf.hcdn[i] & 0xff; 36 struct device *dev; 37 38 dev = dev_find_slot(busn, PCI_DEVFN(devn,0)); 39 >>> CID 1403000: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "dev". 40 switch (dev->device) { 41 case 0x7458: /* 8132 */ 42 id = 1; 43 break; 44 case 0x7454: /* 8151 */ 45 id = 2; ** CID 1402999: Memory - illegal accesses (OVERRUN) /src/console/vtxprintf.c: 110 in number() ________________________________________________________________________________________________________ *** CID 1402999: Memory - illegal accesses (OVERRUN) /src/console/vtxprintf.c: 110 in number() 104 } 105 if (type & SPECIAL) { 106 if (base == 8) 107 call_tx('0'), count++; 108 else if (base == 16) { 109 call_tx('0'), count++; >>> CID 1402999: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 17 bytes at byte offset 33 by dereferencing pointer "digits + 33". 110 call_tx(digits[33]), count++; 111 } 112 } 113 if (!(type & LEFT)) { 114 while (size-- > 0) 115 call_tx(c), count++; ** CID 1402998: Control flow issues (DEADCODE) /src/lib/fit_payload.c: 231 in fit_payload() ________________________________________________________________________________________________________ *** CID 1402998: Control flow issues (DEADCODE) /src/lib/fit_payload.c: 231 in fit_payload() 225 fit_update_chosen(dt, (char *)CONFIG_LINUX_COMMAND_LINE); 226 #endif 227 fit_update_memory(dt); 228 229 /* Collect infos for fit_payload_arch */ 230 kernel.size = config->kernel->size; >>> CID 1402998: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "0U" inside this statement: "fdt.size = (dt ? dt_flat_si...". 231 fdt.size = dt ? dt_flat_size(dt) : 0; 232 initrd.size = config->ramdisk ? config->ramdisk->size : 0; 233 234 /* Invoke arch specific payload placement and fixups */ 235 if (!fit_payload_arch(payload, config, &kernel, &fdt, &initrd)) { 236 printk(BIOS_ERR, "ERROR: Failed to find free memory region\n"); ** CID 1402997: Control flow issues (DEADCODE) /src/arch/x86/pirq_routing.c: 115 in pirq_get_next_free_irq() ________________________________________________________________________________________________________ *** CID 1402997: Control flow issues (DEADCODE) /src/arch/x86/pirq_routing.c: 115 in pirq_get_next_free_irq() 109 /* We can, Now let's assume we can use this IRQ */ 110 irq = i; 111 /* And assume we have not yet routed it */ 112 int already_routed = 0; 113 /* Have we already routed it ? */ 114 for (link = 0; link < CONFIG_MAX_PIRQ_LINKS; link++) { >>> CID 1402997: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (pirq[link] == irq) { ...". 115 if (pirq[link] == irq) { 116 already_routed = 1; 117 break; 118 } 119 } 120 /* If it's not yet routed, use it */ ** CID 1402996: Memory - illegal accesses (NO_EFFECT) /src/arch/x86/pirq_routing.c: 137 in pirq_route_irqs() ________________________________________________________________________________________________________ *** CID 1402996: Memory - illegal accesses (NO_EFFECT) /src/arch/x86/pirq_routing.c: 137 in pirq_route_irqs() 131 { 132 int i, intx, num_entries; 133 unsigned char irq_slot[MAX_INTX_ENTRIES]; 134 unsigned char pirq[CONFIG_MAX_PIRQ_LINKS]; 135 struct irq_routing_table *pirq_tbl; 136 >>> CID 1402996: Memory - illegal accesses (NO_EFFECT) >>> Calling "memset" with size 0: "memset(pirq, 0, 0UL)" does nothing. 137 memset(pirq, 0, CONFIG_MAX_PIRQ_LINKS); 138 139 pirq_tbl = (struct irq_routing_table *)(addr); 140 num_entries = (pirq_tbl->size - 32) / 16; 141 142 /* Set PCI IRQs. */ ** CID 1402995: Control flow issues (DEADCODE) /src/arch/x86/pirq_routing.c: 124 in pirq_get_next_free_irq() ________________________________________________________________________________________________________ *** CID 1402995: Control flow issues (DEADCODE) /src/arch/x86/pirq_routing.c: 124 in pirq_get_next_free_irq() 118 } 119 } 120 /* If it's not yet routed, use it */ 121 if (!already_routed) 122 break; 123 /* But if it was already routed, try the next one */ >>> CID 1402995: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "continue;". 124 continue; 125 } 126 /* Now we got our IRQ */ 127 return irq; 128 } 129 ** CID 1401086: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1401086: Null pointer dereferences (FORWARD_NULL) /src/soc/qualcomm/qcs405/clock.c: 246 in clock_configure_spi() 240 } else if (blsp == 2) 241 spi_clk = (struct qcs405_clock *)&gcc->blsp2_qup0_spi_clk; 242 243 else 244 printk(BIOS_ERR, "BLSP%d not supported\n", blsp); 245 >>> CID 1401086: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "spi_clk" to "clock_configure", which dereferences it. 246 clock_configure(spi_clk, spi_cfg, hz, ARRAY_SIZE(spi_cfg)); 247 } 248 249 void clock_configure_i2c(uint32_t hz) 250 { 251 struct qcs405_clock *i2c_clk = ** CID 1398603: (CONSTANT_EXPRESSION_RESULT) /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 125 in transfer_pll_to_spm_control() /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 124 in transfer_pll_to_spm_control() ________________________________________________________________________________________________________ *** CID 1398603: (CONSTANT_EXPRESSION_RESULT) /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 125 in transfer_pll_to_spm_control() 119 (0xffff << 16) | (0x1 << 0), 120 (0xb16 << 16) | (0x1 << 0)); 121 122 /* Set SPM pinmux */ 123 clrbits_le32(&mtk_spm->pcm_pwr_io_en, (0xff << 0) | (0xff << 16)); 124 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel, 0xffffffff); >>> CID 1398603: (CONSTANT_EXPRESSION_RESULT) >>> "((uint32_t)read32(&mtk_spm->dramc_dpy_clk_sw_con_sel2) & 4294967295U /* ~((uint32_t)0) */) | 0xffffffffU" is always 0xffffffff regardless of the values of its operands. This occurs as an argument to a function call. 125 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel2, 0xffffffff); 126 127 setbits_le32(&mtk_spm->spm_power_on_val0, (0x1 << 8) | (0xf << 12)); 128 setbits_le32(&mtk_spm->spm_s1_mode_ch, 0x3 << 0); 129 130 shu_lev = (shu_lev == 1) ? 2 : 1; /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 124 in transfer_pll_to_spm_control() 118 clrsetbits_le32(&mtk_spm->poweron_config_set, 119 (0xffff << 16) | (0x1 << 0), 120 (0xb16 << 16) | (0x1 << 0)); 121 122 /* Set SPM pinmux */ 123 clrbits_le32(&mtk_spm->pcm_pwr_io_en, (0xff << 0) | (0xff << 16)); >>> CID 1398603: (CONSTANT_EXPRESSION_RESULT) >>> "((uint32_t)read32(&mtk_spm->dramc_dpy_clk_sw_con_sel) & 4294967295U /* ~((uint32_t)0) */) | 0xffffffffU" is always 0xffffffff regardless of the values of its operands. This occurs as an argument to a function call. 124 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel, 0xffffffff); 125 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel2, 0xffffffff); 126 127 setbits_le32(&mtk_spm->spm_power_on_val0, (0x1 << 8) | (0xf << 12)); 128 setbits_le32(&mtk_spm->spm_s1_mode_ch, 0x3 << 0); 129 ** CID 1394268: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libdram/libdram.c: 187 in bdk_libdram_tune_node() ________________________________________________________________________________________________________ *** CID 1394268: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libdram/libdram.c: 187 in bdk_libdram_tune_node() 181 } 182 183 // disabled by default for now, does not seem to be needed much? 184 // Automatically tune the ECC byte DLL read offsets 185 // FIXME? allow override of the filtering 186 // FIXME? allow programmatic override, not via envvar? >>> CID 1394268: Possible Control flow issues (DEADCODE) >>> Execution cannot reach the expression "lmc_config.s.mode32b == 0" inside this statement: "if (do_eccdll && !do_dllro_...". 187 if (do_eccdll && !do_dllro_hw && (lmc_config.s.mode32b == 0)) { // do not do HW-assist twice for ECC 188 BDK_TRACE(DRAM, "N%d: Starting ECC DLL Read Offset Tuning for LMCs\n", node); 189 errs = perform_HW_dll_offset_tuning(node, 2, 8/* ECC bytelane */); 190 BDK_TRACE(DRAM, "N%d: Finished ECC DLL Read Offset Tuning for LMCs, %d errors\n", 191 node, errs); 192 tot_errs += errs; ** CID 1393983: (INTEGER_OVERFLOW) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1150 in initialize_ddr_clock() ________________________________________________________________________________________________________ *** CID 1393983: (INTEGER_OVERFLOW) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() 1140 best_en_idx = strtoul(s, NULL, 0); 1141 override_pll_settings = 1; 1142 } 1143 1144 if (override_pll_settings) { 1145 best_pll_MHz = ddr_ref_hertz * (best_clkf+1) / (best_clkr+1) / 1000000; >>> CID 1393983: (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "best_en_idx" used as array index. 1146 best_calculated_ddr_hertz = ddr_ref_hertz * (best_clkf + 1) / ((best_clkr + 1) * (_en[best_en_idx])); 1147 best_error = ddr_hertz - best_calculated_ddr_hertz; 1148 } 1149 1150 ddr_print("clkr: %2llu, en[%d]: %2d, clkf: %4llu, pll_MHz: %4llu, ddr_hertz: %8llu, error: %8lld <==\n", 1151 best_clkr, best_en_idx, _en[best_en_idx], best_clkf, best_pll_MHz, /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1150 in initialize_ddr_clock() 1144 if (override_pll_settings) { 1145 best_pll_MHz = ddr_ref_hertz * (best_clkf+1) / (best_clkr+1) / 1000000; 1146 best_calculated_ddr_hertz = ddr_ref_hertz * (best_clkf + 1) / ((best_clkr + 1) * (_en[best_en_idx])); 1147 best_error = ddr_hertz - best_calculated_ddr_hertz; 1148 } 1149 >>> CID 1393983: (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "best_en_idx" used as array index. 1150 ddr_print("clkr: %2llu, en[%d]: %2d, clkf: %4llu, pll_MHz: %4llu, ddr_hertz: %8llu, error: %8lld <==\n", 1151 best_clkr, best_en_idx, _en[best_en_idx], best_clkf, best_pll_MHz, 1152 best_calculated_ddr_hertz, best_error); 1153 1154 /* Try lowering the frequency if we can't get a working configuration */ 1155 if (best_error == ddr_hertz) { ** CID 1393982: Memory - illegal accesses (UNINIT) ________________________________________________________________________________________________________ *** CID 1393982: Memory - illegal accesses (UNINIT) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 437 in report_ddr3_dimm() 431 volt_str = "1.5V"; 432 if (spd_voltage & 2) 433 volt_str = "1.35V"; 434 if (spd_voltage & 4) 435 volt_str = "1.2xV"; 436 >>> CID 1393982: Memory - illegal accesses (UNINIT) >>> Using uninitialized value "volt_str" when calling "report_common_dimm". 437 report_common_dimm(node, dimm_config, dimm, ddr3_dimm_types, 438 DDR3_DRAM, volt_str, ddr_interface_num, 439 num_ranks, dram_width, dimm_size_mb); 440 } 441 442 const char *ddr4_dimm_types[16] = { ** CID 1393981: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-init-ddr3.c: 745 in Perform_Read_Deskew_Training() ________________________________________________________________________________________________________ *** CID 1393981: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-init-ddr3.c: 745 in Perform_Read_Deskew_Training() 739 perform_octeon3_ddr3_sequence(node, rank_mask, ddr_interface_num, 0x0A); /* LMC Deskew Training */ 740 741 lock_retries = 0; 742 743 perform_read_deskew_training: 744 // maybe perform the NORMAL deskew training sequence multiple times before looking at lock status >>> CID 1393981: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "normal_loops" as a loop boundary. 745 for (loops = 0; loops < normal_loops; loops++) { 746 DRAM_CSR_MODIFY(phy_ctl, node, BDK_LMCX_PHY_CTL(ddr_interface_num), 747 phy_ctl.s.phy_dsk_reset = 0); /* Normal Deskew sequence */ 748 perform_octeon3_ddr3_sequence(node, rank_mask, ddr_interface_num, 0x0A); /* LMC Deskew Training */ 749 } 750 // Moved this from Validate_Read_Deskew_Training ** CID 1393980: Incorrect expression (NO_EFFECT) /src/vendorcode/cavium/bdk/libdram/libdram.c: 89 in bdk_dram_clear_mem() ________________________________________________________________________________________________________ *** CID 1393980: Incorrect expression (NO_EFFECT) /src/vendorcode/cavium/bdk/libdram/libdram.c: 89 in bdk_dram_clear_mem() 83 /* The above pointer got address 8 to avoid NULL pointer checking 84 in bdk_phys_to_ptr(). Correct it here */ 85 ptr--; 86 uint64_t *end = bdk_phys_to_ptr(bdk_numa_get_address(node, skip)); 87 while (ptr < end) 88 { >>> CID 1393980: Incorrect expression (NO_EFFECT) >>> Assigning "*ptr" to itself has no effect. 89 *ptr = *ptr; 90 ptr++; 91 } 92 } 93 ddr_print("N%d: Clearing DRAM: start 0x%llx length 0x%llx\n", node, skip, len); 94 bdk_zero_memory(bdk_phys_to_ptr(bdk_numa_get_address(node, skip)), len); ** CID 1393973: (DEADCODE) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 101 in read_entire_spd() /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 120 in read_entire_spd() /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 112 in read_entire_spd() ________________________________________________________________________________________________________ *** CID 1393973: (DEADCODE) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 101 in read_entire_spd() 95 uint32_t *ptr = (uint32_t *)spd_buf; 96 97 for (int bank = 0; bank < (spd_size >> 8); bank++) 98 { 99 /* this should only happen for DDR4, which has a second bank of 256 bytes */ 100 if (bank) >>> CID 1393973: (DEADCODE) >>> Execution cannot reach this statement: "bdk_twsix_write_ia(node, bu...". 101 bdk_twsix_write_ia(node, bus, 0x36 | bank, 0, 2, 1, 0); 102 int bank_size = 256; 103 for (int i = 0; i < bank_size; i += 4) 104 { 105 int64_t data = bdk_twsix_read_ia(node, bus, address, i, 4, 1); 106 if (data < 0) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 120 in read_entire_spd() 114 } 115 else 116 *ptr++ = bdk_be32_to_cpu(data); 117 } 118 /* Restore the bank to zero */ 119 if (bank) >>> CID 1393973: (DEADCODE) >>> Execution cannot reach this statement: "bdk_twsix_write_ia(node, bu...". 120 bdk_twsix_write_ia(node, bus, 0x36 | 0, 0, 2, 1, 0); 121 } 122 123 /* Store the SPD in the device tree */ 124 /* FIXME(dhendrix): No need for this? cfg gets updated, so the caller 125 * (libdram_config()) has what it needs. */ /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 112 in read_entire_spd() 106 if (data < 0) 107 { 108 free(spd_buf); 109 bdk_error("Failed to read SPD data at 0x%x\n", i + (bank << 8)); 110 /* Restore the bank to zero */ 111 if (bank) >>> CID 1393973: (DEADCODE) >>> Execution cannot reach this statement: "bdk_twsix_write_ia(node, bu...". 112 bdk_twsix_write_ia(node, bus, 0x36 | 0, 0, 2, 1, 0); 113 return -1; 114 } 115 else 116 *ptr++ = bdk_be32_to_cpu(data); 117 } ** CID 1393972: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 1011 in perform_dll_offset_tuning() ________________________________________________________________________________________________________ *** CID 1393972: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 1011 in perform_dll_offset_tuning() 1005 /* Disable l2 sets for DRAM testing */ 1006 limit_l2_ways(node, 0, ways_print); 1007 #endif 1008 1009 // testing is done on all LMCs simultaneously 1010 // FIXME: for now, loop here to show what happens multiple times >>> CID 1393972: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "loops" as a loop boundary. 1011 for (loop = 0; loop < loops; loop++) { 1012 /* Perform DLL offset tuning */ 1013 errs = auto_set_dll_offset(node, dll_offset_mode, num_lmcs, ddr_interface_64b, do_tune); 1014 } 1015 1016 #if USE_L2_WAYS_LIMIT ** CID 1393971: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() ________________________________________________________________________________________________________ *** CID 1393971: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() 1140 best_en_idx = strtoul(s, NULL, 0); 1141 override_pll_settings = 1; 1142 } 1143 1144 if (override_pll_settings) { 1145 best_pll_MHz = ddr_ref_hertz * (best_clkf+1) / (best_clkr+1) / 1000000; >>> CID 1393971: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "best_en_idx" as an index into an array "_en". 1146 best_calculated_ddr_hertz = ddr_ref_hertz * (best_clkf + 1) / ((best_clkr + 1) * (_en[best_en_idx])); 1147 best_error = ddr_hertz - best_calculated_ddr_hertz; 1148 } 1149 1150 ddr_print("clkr: %2llu, en[%d]: %2d, clkf: %4llu, pll_MHz: %4llu, ddr_hertz: %8llu, error: %8lld <==\n", 1151 best_clkr, best_en_idx, _en[best_en_idx], best_clkf, best_pll_MHz, ** CID 1393969: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libbdk-hal/bdk-qlm.c: 421 in bdk_qlm_eye_display() ________________________________________________________________________________________________________ *** CID 1393969: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libbdk-hal/bdk-qlm.c: 421 in bdk_qlm_eye_display() 415 result = 0; 416 } 417 else 418 result = -1; 419 420 if (need_free) >>> CID 1393969: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "free((void *)eye);". 421 free((void*)eye); 422 return result; ** CID 1393967: Code maintainability issues (UNUSED_VALUE) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 658 in auto_set_dll_offset() ________________________________________________________________________________________________________ *** CID 1393967: Code maintainability issues (UNUSED_VALUE) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 658 in auto_set_dll_offset() 652 } /* for (lmc = 0; lmc < num_lmcs; lmc++) */ 653 654 bdk_watchdog_poke(); 655 656 // run the test(s) 657 // only 1 call should be enough, let the bursts, etc, control the load... >>> CID 1393967: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "run_dram_tuning_threads(node, num_lmcs, bytemask)" to "tot_errors" here, but that stored value is overwritten before it can be used. 658 tot_errors = run_dram_tuning_threads(node, num_lmcs, bytemask); 659 660 for (lmc = 0; lmc < num_lmcs; lmc++) { 661 // record stop cycle CSRs here for utilization measure 662 stop_dram_dclk[lmc] = BDK_CSR_READ(node, BDK_LMCX_DCLK_CNT(lmc)); 663 stop_dram_ops[lmc] = BDK_CSR_READ(node, BDK_LMCX_OPS_CNT(lmc)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Suggestion Computer-On-Module implementations
by Frans Hendriks July 10, 2019

July 10, 2019

Hi All, Variants can be used for mainboards. The variants are used for boards within the same mainboard manufacturer directory. Computer-On-Module (COM) can be used on different carriers which do not have same manufacturer. Proposal is creating a COM directory 'src/com' where the module manufacturer and module name are used. (Similar to mainboard). In this src/com directory common module support is placed. mainboard will use this COM module and contains the 'variant' code. What's the opinion on this suggestion? Met vriendelijke groet / Best regards, Frans Hendriks Eltan B.V. www.eltan.com

3 2

Fwd: Re: Kernel Panics on corebooted systems with linux 4.19 ( >4.9)
by Kinky Nekoboi July 9, 2019

July 9, 2019

-------- Weitergeleitete Nachricht -------- Betreff: Re: [coreboot] Re: Kernel Panics on corebooted systems with linux 4.19 ( >4.9) Datum: Tue, 9 Jul 2019 12:04:33 +0200 Von: Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe> An: Felix Held <felix-coreboot(a)felixheld.de> Kopie (CC): user(a)localhost.com Vendor firmware i did not, and i guess cannot anymore test. Tested in my case (KGPE-D16) with libreboot (coreboot 4.6) with and without microcode.Same behaviour. kernel 4.9 works flawless btw Am 09.07.19 um 12:02 schrieb Felix Held: > Hi! > >> Tested it both with microcode and without microcode. It doesent changes >> the behaviour. > > Uh, that's indeed not good then. Have you tried if this also happens > with older coreboot versions or when running under the vendor firmware? > > Regards > Felix >

1 0

Re: Kernel Panics on corebooted systems with linux 4.19 ( >4.9)
by Kinky Nekoboi July 9, 2019

July 9, 2019

Addional info: linux 4.19 works flawless on corebooted F2A85m, thinkpad x220, w520, x60, t60, apu2 Am 09.07.19 um 12:04 schrieb Kinky Nekoboi: > Vendor firmware i did not, and i guess cannot anymore test. > > Tested in my case (KGPE-D16) with libreboot (coreboot 4.6) with and > without microcode.Same behaviour. > > kernel 4.9 works flawless btw > > Am 09.07.19 um 12:02 schrieb Felix Held: >> Hi! >> >>> Tested it both with microcode and without microcode. It doesent changes >>> the behaviour. >> Uh, that's indeed not good then. Have you tried if this also happens >> with older coreboot versions or when running under the vendor firmware? >> >> Regards >> Felix >>

1 0

Problem with rewriting gpio config using coreboot PAD_CFG_* macros
by Maxim Polyakov July 9, 2019

July 9, 2019

Hi all! In the commit https://review.coreboot.org/c/coreboot/+/33565, I tried to rewrite the PCH GPIOs configuration using macros instead of raw values of the DW0 and DW1 registers. However, macros from src/soc/intel/common/block/include/intelblocks/gpio_defs.h can't determine the setting for each pads. 1) Why do the standard macros (like PAD_CFG_NF, PAD_CFG_GPO, ...) set RX Level/Edge Configuration (RXEVCFG bit[26:25] DW0 register) to 0? From Doc(1) RXEVCFG = 0 -> "determines if the internal RX pad state should be passed on to the next logic stage as is, as level signal". Is this correct if the pad is used as a functional output, PAD_CFG_NF()? At the same time, after resetting, by default, the RXEVCFG field is set to 2h = Drive '0'. If I understood correctly, this means that the pad state will not be transmitted to the next logic block and the interrupt controller will not receive signal from the pad. Maybe this setting will be better for PAD_CFG_NF() or PAD_CFG_GPO()? See https://review.coreboot.org/c/coreboot/+/34144 [1] p1429, Intel 100/C230 Series Chipset Family PCH Volume 2 (February 2019) 2) The macros PAD_CFG_NF() and PAD_CFG_GPO() are defined correctly. In this case, I mast to add new macros, how this is done in commit https://review.coreboot.org/c/coreboot/+/33565. I think adding new macros with strange names isn't the best way. But only in this case, I can set the GPIOs configuration, which fully corresponds to the inteltool log. On the other hand, if I ignore the PAD_CFG0_TRIG_OFF setting (set RX Level/Edge Configuration (RXEVCFG) to 0 = Level), then I need only 2 macros: PAD_CFG_NF_TX_DIS and PAD_CFG_NF_RX_DIS. All Chromebooks install RXEVCFG to 0 and it works. The motherboard works well in both cases. I would like to get your opinion on this. So, maybe I should ignore Drive '0' setting for Level/Edge Configuration (bit[26:25] DW0 register) and use standard macros? Information about GPIOs was obtained from the inteltool log. My motherboard is asrock-h110m-dvs with Intel Skylake/Kaby Lake CPU. Thanks! -- Regards, Maxim Polyakov Software Engineer, YADRO.

2 1

Re: Question about blobs
by Raul Rangel July 8, 2019

July 8, 2019

If you have the source code to build a binaryPI, I think you can `cd binarypi/stoney-pi/AmdAgesaPkg && make Agesa_B2_Target`. I've never tried it though. On Wed, Jul 3, 2019 at 4:58 AM Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> wrote: > > Hi again, > > A clarification. From the StoneyPI_1_3_0_A.ZIP file I've got under NDA is it possible to compile it and get the AGESA.bin file? > For instance, for the fam15tn family the coreboot build process generates a libagesa.fam15tn.a file which is integrated in the > final coreboot.rom file. Could it be possible to do the same from a PI family? The build process in coreboot is only prepared to > use a wrapper and the AGESA.bin file, but maybe is it possible to generate the AGESA.bin from the zip file... > > Thanks! > > ________________________________ > De: Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> > Enviado: martes, 2 de julio de 2019 14:25 > Para: Kyösti Mälkki > Cc: coreboot(a)coreboot.org > Asunto: [coreboot] Re: Question about blobs > > Hi Kyösti! Thanks for the info! > > >AMD contracted SilverBack for the tasks on StoneyRidge (and > >MerlinFalcon apparently). The source is a heavily modified StoneyPI > >package. You may get the unmodified one from AMD reps under NDA. Or > >pay SilverBack for the development you would be more capable of doing > >yourself, and you still might not get a license that allows > >distributing the work. There was a promise of scrubbing and > >relicensing StoneyPI source but... Let's just say legalities messed it > >up, I don't have the details. > > Yes, the AMD reps we're in touch answer me to get in touch with SilverBack to get support :( > We've been able to get a more recent StoneyPI_1_3_0_A.ZIP under NDA because I've seen > this version fixed the issue: > > EMBSWDEV-4487: System is not booting when memory is connected only to DIMM 1 slot > > maybe related with our problem, but I don't know how to integrate this code into coreboot... > And if you say that the current work in coreboot is from a heavily modified base from SilverBack > I don't have any chance to make it work... > > >As for the the other blobs (MullinsPI, CarrizoPI, KaveriPI), those > >were either built at SAGE (R.I.P.) or AMD AES (R.I.P.) and I have been > >told the repositories and toolchains were never officially transferred > >to SilverBack's possession. In other words, even if you paid, > >SilverBack is not likely to work on those. > > Then, no more options to get a working BIOS than SilverBack? > > >I believe we have talked before. Maybe it was about CarrizoPI? I was > >asking for commercial adopters around coreboot and binaryPI, in > >attempts to get to the same negotiation table with AMD management. Did > >You or Your manager ever respond? > > Yes. I began asking in the coreboot mailing list about the Bettong mainboard. I added TPM support > and tianocore to that demoboard. I remember the email and I answered it giving my support because > we thought coreboot is the way to go to support our custom board. > > Regards, > Jorge > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

1 0

HPET MSI/FSB on AMD 16h
by Andriy Gapon July 5, 2019

July 5, 2019

I am using a PCEngines APU2 system and I noticed that its HPET timers do not advertise FSB (MSI) interrupt delivery capability. That is despite the fact that BKDG for family 16h models 30h - 3Fh says that those capability bits are hardwired to 1. I took a quick look through coreboot sources (APU2 firmware is coreboot) and noticed something interesting. It seems that the repository includes code for AGESA (src/vendorcode/amd/agesa) and there I see that the MSI capability can be turned on / off via a special PM I/O register. It appears that HPET MSI support is disabled on some platforms by default: src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c: TRUE, // HpetMsiDis src/vendorcode/amd/agesa/f16kb/Proc/Fch/Interface/Family/Yangtze/EnvDefYangtze.c: TRUE, // HpetMsiDis Does anyone know what is a reason for that? Are there any hardware errata related to that feature? I think that MSI delivery is more efficient and "sexy" than the traditional delivery via IO-APIC (although everything is integrated). Also, is there a way to override that default in a mainboard configuration? Thank you. -- Andriy Gapon

4 7

Does Coreboot support the following options to enable/disable?
by ashmita.chakraborty＠ltts.com July 5, 2019

July 5, 2019

Does the coreboot support the following options to enable/disable: HyperThreading - Disabled Execute Disable Bit - Enabled Intel Virtualization Tech- Enabled Intel (R) TXT- Disabled Enhanced Error Containment Mode -Disabled MLC Streamer -Enabled MLC Spatial Prefetcher -Enabled DUC Data Prefetcher -Enabled DUC Instruction Prefetcher -Enabled LLC Prefetch - Enabled Intel Configurable TDB -Enabled TDP Level -level 2 Please let me know. Thanks in advance. Regards, Ashmita Chakraborty

3 2

Re: Does Coreboot support the following options to enable/disable?
by Lance Zhao July 5, 2019

July 5, 2019

That's Denverton? If the selection is not part of fspupd file https://github.com/IntelFsp/FSP/tree/master/DenvertonNSFspBinPkg/Include, then probably they only have default setting. We can't enable/disable those option through FSP didn't mean those feature is not available. Lance Ashmita Chakraborty <Ashmita.Chakraborty(a)ltts.com> 于2019年7月3日周三上午2:10写道： > Hi Ranga, > > Exactly, only Hyperthreading is available. I could not find Intel > Virtualization Tech , MLC streamer, etc. So here's my question if all these > options support coreboot for Xeon D-15xx? > > > Thanks&Regards, > > Ashmita Chakraborty > ------------------------------ > *From:* Ranga Rao <rangarao(a)ircona.com> > *Sent:* Wednesday, July 3, 2019 1:15:07 PM > *To:* Ashmita Chakraborty; coreboot(a)coreboot.org > *Subject:* RE: [coreboot] Re: Does Coreboot support the following options > to enable/disable? > > > Hi Ashmita, > > > > I could see HyperThreading Enable/Disable in Upd_Data_region > > FSP-master\BroadwellDEFspBinPkg\include\fspvpd.h > > > > Regards > > Ranga > > > > *From:* Ranga Rao <rangarao(a)ircona.com> > *Sent:* Wednesday 3 July 2019 08:18 > *To:* Ashmita Chakraborty <Ashmita.Chakraborty(a)Ltts.com>; > coreboot(a)coreboot.org > *Subject:* [coreboot] Re: Does Coreboot support the following options to > enable/disable? > > > > Hi Ashmita, > > > > Broadwell-DE / Xeon D support still depends Intel's closed-source FSP > (Firmware Support Package) binary-only blobs. > > Broadwell-DE SoC / Xeon D Support Added To Coreboot > > > > Hope you could configure them through fsp_upd_data? > > > > Regards > > Ranga > > > > > > > > > > *From:* Ashmita Chakraborty <Ashmita.Chakraborty(a)Ltts.com> > *Sent:* Wednesday 3 July 2019 08:14 > *To:* Ranga Rao <rangarao(a)ircona.com>; coreboot(a)coreboot.org > *Subject:* Re: [coreboot] Does Coreboot support the following options to > enable/disable? > > > > Dear Ranga, > > > > These options are meant for Xeon D-15xx series family. So will the > coreboot support these options? The coreboot will be built for Xeon D-15xx > processor. Yes, I have access to them in fsp_early_init through > fsp_upd_data. > > > > Thanks&Regards, > > Ashmita Chakraborty > > > ------------------------------ > > *From:* Ranga Rao <rangarao(a)ircona.com> > *Sent:* Tuesday, July 2, 2019 8:41 PM > *To:* Ashmita Chakraborty; coreboot(a)coreboot.org > *Subject:* RE: [coreboot] Does Coreboot support the following options to > enable/disable? > > > > Hi, > > > > As these features are processor/SoC specific and they are part of FSPM, > they should be configurable > > during fsp early init in coreboot, though you may not find a KConfig > option to enable/disable > > > > Do you have access to them in *fsp_early_init* through *fsp_upd_data?* > > > > Regards > > Ranga > > > > -----Original Message----- > From: ashmita.chakraborty(a)ltts.com <ashmita.chakraborty(a)ltts.com> > Sent: Tuesday 2 July 2019 07:34 > To: coreboot(a)coreboot.org > Subject: [coreboot] Does Coreboot support the following options to > enable/disable? > > > > Does the coreboot support the following options to enable/disable: > > > > HyperThreading - Disabled > > Execute Disable Bit - Enabled > > Intel Virtualization Tech- Enabled > > Intel (R) TXT- Disabled > > Enhanced Error Containment Mode -Disabled > > MLC Streamer -Enabled > > MLC Spatial Prefetcher -Enabled > > DUC Data Prefetcher -Enabled > > DUC Instruction Prefetcher -Enabled > > LLC Prefetch - Enabled > > Intel Configurable TDB -Enabled > > TDP Level -level 2 > > > > > > Please let me know. > > > > Thanks in advance. > > > > Regards, > > Ashmita Chakraborty > > _______________________________________________ > > coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an > email to coreboot-leave(a)coreboot.org > > *L&T Technology Services Ltd* > > www.LTTS.com > > This Email may contain confidential or privileged information for the > intended recipient (s). If you are not the intended recipient, please do > not use or disseminate the information, notify the sender and delete it > from your system. > > *L&T Technology Services Ltd* > > www.LTTS.com > > This Email may contain confidential or privileged information for the > intended recipient (s). If you are not the intended recipient, please do > not use or disseminate the information, notify the sender and delete it > from your system. > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 2

New on blogs.coreboot.org: [GSoC] KASan in Coreboot
by blogs.coreboot.org July 3, 2019

July 3, 2019

1 0