coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

KGPE-D16: Excessive power consumption in idle
by Daniel Kulesz 11 Feb '17

11 Feb '17

Hi, I just compiled and flashed the lastest master on my KGPE-D16 with pretty much the default config. My board has only one of the CPU sockets populated with an Opteron 6276. Things seem to work fine so far, except the power consumption. The "sensors" command reports a CPU power consumption of about ~85W (!) in idle: --- k10temp-pci-00cb Adapter: PCI adapter temp1: +21.2°C (high = +70.0°C) fam15h_power-pci-00c4 Adapter: PCI adapter power1: 85.13 W (crit = 115.11 W) nouveau-pci-0500 Adapter: PCI adapter GPU core: +1.01 V (min = +0.60 V, max = +1.20 V) fan1: 0 RPM temp1: +37.0°C (high = +95.0°C, hyst = +3.0°C) (crit = +105.0°C, hyst = +5.0°C) (emerg = +135.0°C, hyst = +5.0°C) k10temp-pci-00c3 Adapter: PCI adapter temp1: +24.1°C (high = +70.0°C) --- With the vendor bios, the power consumption reported by "sensors" was just about the half - around 43W. I measured the consumption also on the power socket, and the whole systems seems to draw around 91W in idle (which is strange, since the GPU + hard drives + fans certainly don't take only 6W, but yeah...). Anyways, with the vendor bios, the power consumption of the whole system was around 60W (tested with a different power supply, but as a rough measure I guess this is representative). In coreboot's menuconfig, I can't select any power saving options or such as it was possible for other boards, which leaves me a bit puzzled. Anyone having simular issues? Cheers, Daniel

2 2

Warning: Changed changed cmos.layout on many systems
by Arthur Heymans 11 Feb '17

11 Feb '17

Hi In patch [1] "util/nvramtool: Bail out on unaligned multi-byte entries" was found that coreboot does not support options that span multiple bytes and are not aligned. I tried to fix the affected boards by this in [2]. I modes some options around in cmos.layout of some boards.This can be a pain for users since it can result in unexpected changes in settings, since the RTC nvram often remains the same with a new cmos.layout. To make sure that your RTC nvram settings are correct after this gets merged you can have nvramtool use the layout file from the tree against which you can set settings: nvramtool -y src/mainboard/"your_vendor"/"your_board"/cmos.layout -a and adapt the settings accordingly using (-w). I don't think nvramtool has an option to use cmos_layout.bin from the cbfs of an image to change options on the RTC nvram. Such an option would be desirable though. In [2] an idea was proposed of a script that can automatically handle such migration. I'm quite fond of that idea. Any thoughts? The affected systems are: adi/rcc-dff amd/serengeti_cheetah_fam10 asus/kcma-d8 asus/kfsn4-dre asus/kgpe-d16 esd/atom15 hp/dl165_g6_fam10 intel/littleplains intel/minnowmax intel/mohonpeak kontron/ktqm77 lenovo/t400 lenovo/x200 msi/ms9652_fam10 pcengines/apu1 supermicro/h8dmr_fam10 supermicro/h8qme_fam10 [1] "util/nvramtool: Bail out on unaligned multi-byte entries" https://review.coreboot.org/#/c/18246/ [2] "mb/*/*/cmos.layout: Make multibyte options byte aligned" https://review.coreboot.org/#/c/18321/ Kind regards --- Arthur Heymans

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 10 Feb '17

10 Feb '17

The ASUS KGPE-D16 fails verification for branch master as of commit 0e3c59e258e0eb1cabe2ab15286f73efbf36294d The following tests failed: BOOT_FAILURE Commits since last successful test: 0e3c59e ddr3 spd: move accessor code into lib/spd_bin.c 2e08b59 ddr3 spd: Rename read_spd_from_cbfs() to read_ddr3_spd_from_cbfs() ded1e05 util/romcc: Don't reference a variable after checking it for NULL 44a46a1 device/dram: use global DIMM_SPD_SIZE Kconfig variable d09dc6b cbmem_console: Remove "buffer_" prefix from all structure fields 24de3a3 vendorcode/intel/skykabylake: Update FSP UPD header files 6ff7e8f vendorcode/intel/skykabylake: Update CpuConfigFspData.h file 0254c2d southbridge/intel/common/firmware: allow locking ME without HAVE_ME_BIN 7d14af8 soc/intel/apollolake: dump CSE status See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

2 1

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

10 Feb '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 34 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 34 defect(s) ** CID 1370577: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfscomptool.c: 83 in benchmark() ________________________________________________________________________________________________________ *** CID 1370577: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfscomptool.c: 83 in benchmark() 77 78 clock_gettime(CLOCK_MONOTONIC, &t_e); 79 printf("compressing %d bytes to %d took %ld seconds\n", 80 bufsize, outsize, 81 t_e.tv_sec - t_s.tv_sec); 82 } >>> CID 1370577: Resource leaks (RESOURCE_LEAK) >>> Variable "compressed_data" going out of scope leaks the storage it points to. 83 return 0; 84 } 85 86 int compress(char *infile, char *outfile, char *algoname) 87 { 88 int err = 1; ** CID 1370575: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfscomptool.c: 83 in benchmark() ________________________________________________________________________________________________________ *** CID 1370575: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfscomptool.c: 83 in benchmark() 77 78 clock_gettime(CLOCK_MONOTONIC, &t_e); 79 printf("compressing %d bytes to %d took %ld seconds\n", 80 bufsize, outsize, 81 t_e.tv_sec - t_s.tv_sec); 82 } >>> CID 1370575: Resource leaks (RESOURCE_LEAK) >>> Variable "data" going out of scope leaks the storage it points to. 83 return 0; 84 } 85 86 int compress(char *infile, char *outfile, char *algoname) 87 { 88 int err = 1; ** CID 1361275: (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 838 in parse_subpart_dir() ________________________________________________________________________________________________________ *** CID 1361275: (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 831 in parse_subpart_dir() 825 memcpy(hdr.name, data + offset, sizeof(hdr.name)); 826 offset += sizeof(hdr.name); 827 828 validate_subpart_dir_without_checksum((struct subpart_dir *)&hdr, name); 829 830 assert(size > subpart_dir_size(&hdr)); >>> CID 1361275: (TAINTED_SCALAR) >>> Passing tainted variable "subpart_dir_size(&hdr)" to a tainted sink. 831 alloc_buffer(subpart_dir_buf, subpart_dir_size(&hdr), "Subpart Dir"); 832 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE); 833 834 /* Read Subpart Dir entries. */ 835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf); 836 struct subpart_dir_entry *e = &subpart_dir->e[0]; /util/cbfstool/ifwitool.c: 838 in parse_subpart_dir() 832 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE); 833 834 /* Read Subpart Dir entries. */ 835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf); 836 struct subpart_dir_entry *e = &subpart_dir->e[0]; 837 uint32_t i; >>> CID 1361275: (TAINTED_SCALAR) >>> Using tainted variable "hdr.num_entries" as a loop boundary. 838 for (i = 0; i < hdr.num_entries; i++) { 839 memcpy(e[i].name, data + offset, sizeof(e[i].name)); 840 offset += sizeof(e[i].name); 841 offset = read_member(data, offset, sizeof(e[i].offset), 842 &e[i].offset); 843 offset = read_member(data, offset, sizeof(e[i].length), ** CID 1361274: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1361274: Insecure data handling (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 717 in alloc_bpdt_buffer() 711 { 712 struct bpdt_header bpdt_header; 713 assert((offset + BPDT_HEADER_SIZE) < size); 714 bpdt_read_header((uint8_t *)data + offset, &bpdt_header, name); 715 716 /* Buffer to read BPDT header and entries. */ >>> CID 1361274: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "get_bpdt_size(&bpdt_header)" to a tainted sink. 717 alloc_buffer(b, get_bpdt_size(&bpdt_header), name); 718 719 struct bpdt *bpdt = buffer_get(b); 720 memcpy(&bpdt->h, &bpdt_header, BPDT_HEADER_SIZE); 721 722 /* ** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) /util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry() ________________________________________________________________________________________________________ *** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) /util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry() 1294 static size_t init_subpart_dir_entry(struct subpart_dir_entry *e, 1295 struct buffer *b, size_t offset) 1296 { 1297 memset(e, 0, sizeof(*e)); 1298 1299 assert(strlen(b->name) <= sizeof(e->name)); >>> CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 12 bytes on destination array "e->name" of size 12 bytes might leave the destination string unterminated. 1300 strncpy((char *)e->name, (char *)b->name, sizeof(e->name)); 1301 e->offset = offset; 1302 e->length = buffer_size(b); 1303 1304 return (offset + buffer_size(b)); 1305 } ** CID 1353793: Resource leaks (RESOURCE_LEAK) /util/nvidia/cbootimage/src/data_layout.c: 1096 in resign_bl() ________________________________________________________________________________________________________ *** CID 1353793: Resource leaks (RESOURCE_LEAK) /util/nvidia/cbootimage/src/data_layout.c: 1096 in resign_bl() 1090 1091 if (read_from_image(context->input_image_filename, 1092 offset, bl_length, 1093 &image, &image_actual_size, file_type_bin)) { 1094 printf("Error reading image file %s.\n", 1095 context->input_image_filename); >>> CID 1353793: Resource leaks (RESOURCE_LEAK) >>> Variable "image" going out of scope leaks the storage it points to. 1096 return -ENOMEM; 1097 } 1098 1099 pages_in_image = ICEIL(image_actual_size, page_size); 1100 1101 /* Create a local copy of the bl */ ** CID 1353781: Control flow issues (NO_EFFECT) /util/nvidia/cbootimage/src/cbootimage.c: 242 in main() ________________________________________________________________________________________________________ *** CID 1353781: Control flow issues (NO_EFFECT) /util/nvidia/cbootimage/src/cbootimage.c: 242 in main() 236 context.input_image_filename); 237 goto fail; 238 } 239 240 /* Get BCT_SIZE from input image file */ 241 bct_size = get_bct_size_from_image(&context); >>> CID 1353781: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "bct_size < 0U". 242 if (bct_size < 0) { 243 printf("Error: Invalid input image file %s\n", 244 context.input_image_filename); 245 goto fail; 246 } 247 ** CID 1353028: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353028: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() 335 pspdir[4+4*i+2] = 1; 336 pspdir[4+4*i+3] = 0; 337 } else if (fw_table[i].filename != NULL) { 338 pspdir[4+4*i+0] = fw_table[i].type; 339 340 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353028: Error handling issues (NEGATIVE_RETURNS) >>> "fd" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 341 fstat(fd, &fd_stat); 342 pspdir[4+4*i+1] = (uint32_t)fd_stat.st_size; 343 344 pspdir[4+4*i+2] = pos + rom_base_address; 345 pspdir[4+4*i+3] = 0; 346 ** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() 278 int i; 279 uint32_t rom_base_address = 0xFFFFFFFF - rom_size + 1; 280 281 for (i = 0; fw_table[i].type != AMD_FW_INVALID; i++) { 282 if (fw_table[i].filename != NULL) { 283 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353027: Error handling issues (NEGATIVE_RETURNS) >>> "fd" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 284 fstat(fd, &fd_stat); 285 286 switch (fw_table[i].type) { 287 case AMD_FW_IMC: 288 pos = ALIGN(pos, 0x10000U); 289 romsig[1] = pos + rom_base_address; ** CID 1353022: Error handling issues (CHECKED_RETURN) /util/nvidia/cbootimage/src/cbootimage.c: 297 in main() ________________________________________________________________________________________________________ *** CID 1353022: Error handling issues (CHECKED_RETURN) /util/nvidia/cbootimage/src/cbootimage.c: 297 in main() 291 begin_update(&context); 292 /* Signing the bct. */ 293 e = sign_bct(&context, context.bct); 294 if (e != 0) 295 printf("Signing BCT failed, error: %d.\n", e); 296 >>> CID 1353022: Error handling issues (CHECKED_RETURN) >>> Calling "fwrite" without checking return value (as is done elsewhere 38 out of 47 times). 297 fwrite(context.bct, 1, context.bct_size, 298 context.raw_file); 299 printf("New BCT file %s has been successfully generated!\n", 300 context.output_image_filename); 301 goto fail; 302 } ** CID 1353021: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 355 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353021: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 355 in integrate_psp_firmwares() 349 " will not fit %s. Exiting.\n", 350 rom_size, fw_table[i].filename); 351 free(base); 352 exit(1); 353 } 354 >>> CID 1353021: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 355 read(fd, (void *)(base + pos), (size_t)fd_stat.st_size); 356 357 pos += fd_stat.st_size; 358 close(fd); 359 pos = ALIGN(pos, 0x100U); 360 } else { ** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() 335 pspdir[4+4*i+2] = 1; 336 pspdir[4+4*i+3] = 0; 337 } else if (fw_table[i].filename != NULL) { 338 pspdir[4+4*i+0] = fw_table[i].type; 339 340 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353020: Error handling issues (CHECKED_RETURN) >>> Calling "fstat(fd, &fd_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 341 fstat(fd, &fd_stat); 342 pspdir[4+4*i+1] = (uint32_t)fd_stat.st_size; 343 344 pspdir[4+4*i+2] = pos + rom_base_address; 345 pspdir[4+4*i+3] = 0; 346 ** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 310 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 310 in integrate_firmwares() 304 " will not fit %s. Exiting.\n", 305 rom_size, fw_table[i].filename); 306 free(base); 307 exit(1); 308 } 309 >>> CID 1353019: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 310 read(fd, (void *)(base + pos), (size_t)fd_stat.st_size); 311 312 pos += fd_stat.st_size; 313 close(fd); 314 pos = ALIGN(pos, 0x100U); 315 } ** CID 1353018: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353018: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() 278 int i; 279 uint32_t rom_base_address = 0xFFFFFFFF - rom_size + 1; 280 281 for (i = 0; fw_table[i].type != AMD_FW_INVALID; i++) { 282 if (fw_table[i].filename != NULL) { 283 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353018: Error handling issues (CHECKED_RETURN) >>> Calling "fstat(fd, &fd_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 284 fstat(fd, &fd_stat); 285 286 switch (fw_table[i].type) { 287 case AMD_FW_IMC: 288 pos = ALIGN(pos, 0x10000U); 289 romsig[1] = pos + rom_base_address; ** CID 1347335: (UNINIT) /util/cbfstool/elfheaders.c: 999 in write_phdrs() /util/cbfstool/elfheaders.c: 1001 in write_phdrs() /util/cbfstool/elfheaders.c: 1002 in write_phdrs() /util/cbfstool/elfheaders.c: 1003 in write_phdrs() ________________________________________________________________________________________________________ *** CID 1347335: (UNINIT) /util/cbfstool/elfheaders.c: 999 in write_phdrs() 993 } else { 994 /* Accumulate file size and memsize. The assumption 995 * is that each section is either NOBITS or full 996 * (sh_size == file size). This is standard in that 997 * an ELF section doesn't have a file size component. */ 998 if (sec->shdr.sh_flags & SHF_EXECINSTR) >>> CID 1347335: (UNINIT) >>> Using uninitialized value "phdr.p_flags". 999 phdr.p_flags |= PF_X | PF_R; 1000 if (sec->shdr.sh_flags & SHF_WRITE) 1001 phdr.p_flags |= PF_W; 1002 phdr.p_filesz += buffer_size(&sec->content); 1003 phdr.p_memsz += sec->shdr.sh_size; 1004 } /util/cbfstool/elfheaders.c: 1001 in write_phdrs() 995 * is that each section is either NOBITS or full 996 * (sh_size == file size). This is standard in that 997 * an ELF section doesn't have a file size component. */ 998 if (sec->shdr.sh_flags & SHF_EXECINSTR) 999 phdr.p_flags |= PF_X | PF_R; 1000 if (sec->shdr.sh_flags & SHF_WRITE) >>> CID 1347335: (UNINIT) >>> Using uninitialized value "phdr.p_flags". 1001 phdr.p_flags |= PF_W; 1002 phdr.p_filesz += buffer_size(&sec->content); 1003 phdr.p_memsz += sec->shdr.sh_size; 1004 } 1005 } 1006 /util/cbfstool/elfheaders.c: 1002 in write_phdrs() 996 * (sh_size == file size). This is standard in that 997 * an ELF section doesn't have a file size component. */ 998 if (sec->shdr.sh_flags & SHF_EXECINSTR) 999 phdr.p_flags |= PF_X | PF_R; 1000 if (sec->shdr.sh_flags & SHF_WRITE) 1001 phdr.p_flags |= PF_W; >>> CID 1347335: (UNINIT) >>> Using uninitialized value "phdr.p_filesz". 1002 phdr.p_filesz += buffer_size(&sec->content); 1003 phdr.p_memsz += sec->shdr.sh_size; 1004 } 1005 } 1006 1007 /* Write out the last phdr. */ /util/cbfstool/elfheaders.c: 1003 in write_phdrs() 997 * an ELF section doesn't have a file size component. */ 998 if (sec->shdr.sh_flags & SHF_EXECINSTR) 999 phdr.p_flags |= PF_X | PF_R; 1000 if (sec->shdr.sh_flags & SHF_WRITE) 1001 phdr.p_flags |= PF_W; 1002 phdr.p_filesz += buffer_size(&sec->content); >>> CID 1347335: (UNINIT) >>> Using uninitialized value "phdr.p_memsz". 1003 phdr.p_memsz += sec->shdr.sh_size; 1004 } 1005 } 1006 1007 /* Write out the last phdr. */ 1008 if (num_needs_write != num_written) { ** CID 1302457: Control flow issues (MISSING_RESTORE) /util/cbfstool/flashmap/fmap.c: 485 in fmap_append_area_test() ________________________________________________________________________________________________________ *** CID 1302457: Control flow issues (MISSING_RESTORE) /util/cbfstool/flashmap/fmap.c: 485 in fmap_append_area_test() 479 if ((*fmap)->nareas != 1) { 480 printf("FAILURE: failed to increment number of areas\n"); 481 goto fmap_append_area_test_exit; 482 } 483 484 status = pass; >>> CID 1302457: Control flow issues (MISSING_RESTORE) >>> Jumped to here, skipping restore. 485 fmap_append_area_test_exit: 486 return status; 487 } 488 489 static int fmap_find_area_test(struct fmap *fmap) 490 { ** CID 1302456: Error handling issues (NEGATIVE_RETURNS) /util/cbfstool/flashmap/fmap.c: 601 in fmap_find_test() ________________________________________________________________________________________________________ *** CID 1302456: Error handling issues (NEGATIVE_RETURNS) /util/cbfstool/flashmap/fmap.c: 601 in fmap_find_test() 595 printf("FAILURE: bsearch returned false positive\n"); 596 goto fmap_find_test_exit; 597 } 598 599 /* simple test case: fmap at (total_size / 2) + 1 */ 600 offset = (total_size / 2) + 1; >>> CID 1302456: Error handling issues (NEGATIVE_RETURNS) >>> "fmap_size(fmap)" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 601 memcpy(&buf[offset], fmap, fmap_size(fmap)); 602 603 if ((unsigned)fmap_find(buf, total_size - 1) != offset) { 604 printf("FAILURE: lsearch failed to find fmap\n"); 605 goto fmap_find_test_exit; 606 } ** CID 1302455: Null pointer dereferences (NULL_RETURNS) /util/cbfstool/partitioned_file.c: 199 in partitioned_file_reopen() ________________________________________________________________________________________________________ *** CID 1302455: Null pointer dereferences (NULL_RETURNS) /util/cbfstool/partitioned_file.c: 199 in partitioned_file_reopen() 193 partitioned_file_close(file); 194 return NULL; 195 } 196 197 const struct fmap_area *fmap_fmap_entry = 198 fmap_find_area(file->fmap, SECTION_NAME_FMAP); >>> CID 1302455: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "fmap_fmap_entry". 199 if ((long)fmap_fmap_entry->offset != fmap_region_offset) { 200 ERROR("FMAP's '%s' section doesn't point back to FMAP start (did something corrupt this file?)\n", 201 SECTION_NAME_FMAP); 202 partitioned_file_close(file); 203 return NULL; 204 } ** CID 1302453: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test() ________________________________________________________________________________________________________ *** CID 1302453: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test() 557 } 558 free(my_str); 559 free(str); 560 561 status = pass; 562 fmap_flags_to_string_test_exit: >>> CID 1302453: Resource leaks (RESOURCE_LEAK) >>> Variable "my_str" going out of scope leaks the storage it points to. 563 return status; 564 565 } 566 567 static int fmap_find_test(struct fmap *fmap) 568 { ** CID 1302452: (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test() /util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test() ________________________________________________________________________________________________________ *** CID 1302452: (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test() 557 } 558 free(my_str); 559 free(str); 560 561 status = pass; 562 fmap_flags_to_string_test_exit: >>> CID 1302452: (RESOURCE_LEAK) >>> Variable "str" going out of scope leaks the storage it points to. 563 return status; 564 565 } 566 567 static int fmap_find_test(struct fmap *fmap) 568 { /util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test() 557 } 558 free(my_str); 559 free(str); 560 561 status = pass; 562 fmap_flags_to_string_test_exit: >>> CID 1302452: (RESOURCE_LEAK) >>> Variable "str" going out of scope leaks the storage it points to. 563 return status; 564 565 } 566 567 static int fmap_find_test(struct fmap *fmap) 568 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Back to original BIOS
by Igor Skochinsky 10 Feb '17

10 Feb '17

>Четверг, 9 февраля 2017, 12:16 +01:00 от Michal Widlok <michalwd1979(a)gmail.com>: > >Hello, > >Igor - I've checked it again. Mac is really at addresses 0x5F6000, 0x5F7000 - or my ghex editor does not work :-). The flash chip is 8MB (0x800000), so fits right in. I will try Yours procedure, but I'm concerned about cutting image at 0x400000 - are You talking about 4MB flash? All my laptops has 8MB. Ah, looks like you should use the files from the 7UET94WW directory, which are 8MB for (unpacked) FL1 and 4MB for FL2 (you should use 200000- 400000 from it). > >Zoran - Michael is OK. In fact in polish Michal should end with special polish letter "ł", so I'm not sure if "international" Michael is not better anyway. > >Best Regards, >Michal Widlok > > >On Thu, Feb 9, 2017 at 9:50 AM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com > wrote: >>Hello Igor, >> >>Interesting emails. I should admit. For sure worth exploration, especially GIT Hub application. :-) >> >>Michal (finally, I got your correct name, idiot me), >> >>I'll come back to this thread. I am last 3 days very busy. Very very busy, but, certainly, I'll get free time, and will explore this opportunity, since it makes my old, not so sharp anymore eyes very wide! >> >>Thank you all, >>Zoran >> >>On Wed, Feb 8, 2017 at 10:46 PM, Igor Skochinsky via coreboot < coreboot(a)coreboot.org > wrote: >>>P.S. >>> >>> >>>Hello Michal, >>> >>>The T400 BIOS is in a Pre-UEFI Phoenix FFV format. You can use phoenix_extract.py[1] to extract modules from it. >>> >>>To go back to Lenovo BIOS you can try the following: >>> >>>1) download an update from lenovo (e.g. 7uuj49us.exe) >>>2) unpack it with innounp >>> >>>2b) apparently innoextract [2] can be used on non-Windows platforms >>> >>>[2]: http://constexpr.org/innoextract/ >>> >>> >>>3a) take the FL2 file (e.g. $01B8100.FL2), cut out from 0x200000 to 0x400000 and use the resulting image to replace coreboot in the BIOS region (end of flash). >>>3b) take the FL1 file (e.g. $01B8100.FL1), unpack it with bcpvd from [1] and flash the result (it's a complete flash image with descriptor and ME) after cutting it at 0x400000 >>>4) according to the descriptor in unpacked FL1 , the GbE region is at 001F6000 - 001F7FFF, so that's the most likely place for storing the MAC address. I'm not sure why your desc.rom lists 5F6000 - 005F7FFF... I think that's outside the flash chip. >>> >>>[1]: https://github.com/coreboot/bios_extract >>> >>>-- >>>WBR, >>> Igor mailto:roxfan@skynet.be >>> >>> >>> >>>-- >>>WBR, >>> Igor mailto:skochinsky@mail.ru >>>-- >>>coreboot mailing list: coreboot(a)coreboot.org >>>https://www.coreboot.org/mailman/listinfo/coreboot >> > >-- >coreboot mailing list: coreboot(a)coreboot.org >https://www.coreboot.org/mailman/listinfo/coreboot WBR, Igor mailto:skochinsky@mail.ru

2 1

Coreboot support for Apollo Lake
by Tahnia Lichtenstein 10 Feb '17

10 Feb '17

Hi there, I am new to coreboot (and Intel Atom development), so please excuse me if I ask clumsy questions... I am tasked to get a bootloader (including the whole firmware stack) running on a custom developed Intel Atom Apollo Lake board, loading Windows 10 IoT Enterprise. So I want to use coreboot for this (probably along with either SeaBIOS or Tianocore). However, I am still waiting to receive an Intel Apollo Lake CRB, so I do not yet have access to the sample code that comes with the CRB. This also means I can't yet try to load the currently available coreboot project for Apollo Lake RVP. It seems like the coreboot code for the Apollo Lake RVP is very bare bones. Will this code work on a CRB as is, or is there a lot of extra development I would need to do myself to get it running? If there is a lot of development work to be done, then is the coreboot community looking at doing this in the nearby future? Otherwise, if I need to do the remaining development, is it going to be mostly integration work in the sense that I need to copy code from the Apollo Lake SoC project into the RVP project? Or will it mostly be new development like configuring the correct interfaces, drivers, etc? Best regards, Tahnia

1 0

FSP + coreboot + UEFI + Windows 10 on Intel Apollo Lake E39xx
by r&d2 09 Feb '17

09 Feb '17

Hi everybody, I'm conducting a feasibility study about a product based on Intel Apollo Lake E39xx. The product should make use of the FSP/coreboot/UEFI combination to boot Windows 10 o.s. Has anybody tried this combination on any of the available evaluation boards (Juniper Hill, Oxbow Hill, Leaf Hill) ? Thanks in advance. Andrea

2 1

Re: [coreboot] Problem of compiling the new architecture
by Aaron Durbin 09 Feb '17

09 Feb '17

On Thu, Feb 9, 2017 at 6:49 AM, Maxim Gusev via coreboot <coreboot(a)coreboot.org> wrote: > Hello! > > Please help to solve one problem... > When I am trying to compile the sources of my specific architecture, my > compiler tries to build "src/cpu/x86/lapic/boot_cpu.c". > > "CC bootblock/commonlib/cbfs.o > CC bootblock/commonlib/lz4_wrapper.o > CC bootblock/commonlib/mem_pool.o > CC bootblock/commonlib/region.o > CC bootblock/console/die.o > CC bootblock/console/post.o > CC bootblock/cpu/x86/lapic/boot_cpu.o" > > But it is not x86 compatible arch. How to escape this dirs? > > As I can see in src/cpu/x86/lapic/Makefile.inc there is a bootblock-y += > boot_cpu.c so it will be always in the bootblock stage (with any arch)? > I think the compiler should see only the src/cpu/MY_ARCH/lapic/Makefile.inc. > What shell I do? $ git grep lapic | grep Makefile You'll see that either a cpu Makefile is adding that generic x86 directory or some chipset Makefile. Double check what you are building and follow the Makefile dependencies. > > Thanks! > > Regards, > Maxim > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Problem of compiling the new architecture
by Maxim Gusev 09 Feb '17

09 Feb '17

Hello! Please help to solve one problem... When I am trying to compile the sources of my specific architecture, my compiler tries to build "src/cpu/x86/lapic/boot_cpu.c". "CC bootblock/commonlib/cbfs.o CC bootblock/commonlib/lz4_wrapper.o CC bootblock/commonlib/mem_pool.o CC bootblock/commonlib/region.o CC bootblock/console/die.o CC bootblock/console/post.o CC bootblock/cpu/x86/lapic/boot_cpu.o" But it is not x86 compatible arch. How to escape this dirs? As I can see in src/cpu/x86/lapic/Makefile.inc there is a bootblock-y += boot_cpu.c so it will be always in the bootblock stage (with any arch)? I think the compiler should see only the src/cpu/MY_ARCH/lapic/Makefile.inc. What shell I do? Thanks! Regards, Maxim

1 0

Re: [coreboot] Back to original BIOS
by Michal Widlok 09 Feb '17

09 Feb '17

Hello, Igor - I've checked it again. Mac is really at addresses 0x5F6000, 0x5F7000 - or my ghex editor does not work :-). The flash chip is 8MB (0x800000), so fits right in. I will try Yours procedure, but I'm concerned about cutting image at 0x400000 - are You talking about 4MB flash? All my laptops has 8MB. Zoran - Michael is OK. In fact in polish Michal should end with special polish letter "ł", so I'm not sure if "international" Michael is not better anyway. Best Regards, Michal Widlok On Thu, Feb 9, 2017 at 9:50 AM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Hello Igor, > > Interesting emails. I should admit. For sure worth exploration, especially > GIT Hub application. :-) > > Michal (finally, I got your correct name, idiot me), > > I'll come back to this thread. I am last 3 days very busy. Very very busy, > but, certainly, I'll get free time, and will explore this opportunity, > since it makes my old, not so sharp anymore eyes very wide! > > Thank you all, > Zoran > > On Wed, Feb 8, 2017 at 10:46 PM, Igor Skochinsky via coreboot < > coreboot(a)coreboot.org> wrote: > >> P.S. >> >> >> Hello Michal, >> >> The T400 BIOS is in a Pre-UEFI Phoenix FFV format. You can use >> phoenix_extract.py[1] to extract modules from it. >> >> To go back to Lenovo BIOS you can try the following: >> >> 1) download an update from lenovo (e.g. 7uuj49us.exe) >> 2) unpack it with innounp >> >> 2b) apparently innoextract [2] can be used on non-Windows platforms >> >> [2]: http://constexpr.org/innoextract/ >> >> >> 3a) take the FL2 file (e.g. $01B8100.FL2), cut out from 0x200000 to >> 0x400000 and use the resulting image to replace coreboot in the BIOS region >> (end of flash). >> 3b) take the FL1 file (e.g. $01B8100.FL1), unpack it with bcpvd from [1] >> and flash the result (it's a complete flash image with descriptor and ME) >> after cutting it at 0x400000 >> 4) according to the descriptor in unpacked FL1 , the GbE region is at >> 001F6000 - 001F7FFF, so that's the most likely place for storing the MAC >> address. I'm not sure why your desc.rom lists 5F6000 - 005F7FFF... I think >> that's outside the flash chip. >> >> [1]: https://github.com/coreboot/bios_extract >> >> >> >> *-- WBR, Igor mailto:roxfan@skynet.be >> <roxfan(a)skynet.be>* >> >> >> >> >> >> *-- WBR, Igor mailto:skochinsky@mail.ru >> <skochinsky(a)mail.ru>* >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2017