coreboot August 2016

coreboot@coreboot.org

53 participants
132 discussions

Re: [coreboot] Strange postcodes
by Patrick Rudolph 07 Aug '16

07 Aug '16

Hi. Most post codes use pre defined values instead of hardcoded values ( src/include/console/post_codes.h) . Sadly there's no documentation of possible post codes, as it's board specific. Binary blobs, like Intel mrc.bin, have their own 16bit post code set. Asm code is of course sending post codes to, and of course it's not using any c function to do so. Regards, Patrick Am 7. August 2016 10:11:32 MESZ, schrieb "Łukasz Dobrowolski" <spectrallynx(a)gmail.com>: >Hello! >I'm porting cb to ThinkPad X120e. I've used code from asrock/e350m1 as >basis and made some small changes. > >I'm getting following postcodes. Those are after "50" so romstage.c >finished executing. (System sometimes goes this far, other times it >hangs earlier.) > 79 24 98 7A A8 F8 > >I tried to find them in like this: > grep -R 'post_code(0x24);' >I've only found "24", it's in device/pci_device.c:1113. Whatever is >sending the rest of the postcodes is not using post_code() function. > >I can think of 3 explanations: > Payload is sending those postcodes. -> Seams unlikely, I'm >using Seabios. I've read some of the code and can't find any places >that would send the codes. > ASM parts of cb/AGESA. > EC(ITE IT8518E) is sending the codes. > >Any thoughts? > >-- >coreboot mailing list: coreboot(a)coreboot.org >https://www.coreboot.org/mailman/listinfo/coreboot -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

1 0

Strange postcodes
by Łukasz Dobrowolski 07 Aug '16

07 Aug '16

Hello! I'm porting cb to ThinkPad X120e. I've used code from asrock/e350m1 as basis and made some small changes. I'm getting following postcodes. Those are after "50" so romstage.c finished executing. (System sometimes goes this far, other times it hangs earlier.) 79 24 98 7A A8 F8 I tried to find them in like this: grep -R 'post_code(0x24);' I've only found "24", it's in device/pci_device.c:1113. Whatever is sending the rest of the postcodes is not using post_code() function. I can think of 3 explanations: Payload is sending those postcodes. -> Seams unlikely, I'm using Seabios. I've read some of the code and can't find any places that would send the codes. ASM parts of cb/AGESA. EC(ITE IT8518E) is sending the codes. Any thoughts?

1 0

FS2 for anyone who can use it
by ron minnich 07 Aug '16

07 Aug '16

I have an FS2 if someone can use it. I may have mentioned this before. I can bring it to berlin with me if you will be at the meeting. ron

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 05 Aug '16

05 Aug '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 59 new defect(s) introduced to coreboot found with Coverity Scan. 10 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 59 defect(s) ** CID 1361276: Uninitialized variables (UNINIT) /util/cbfstool/cbfs_image.c: 1165 in cbfs_payload_make_elf() ________________________________________________________________________________________________________ *** CID 1361276: Uninitialized variables (UNINIT) /util/cbfstool/cbfs_image.c: 1165 in cbfs_payload_make_elf() 1159 if (elf_writer_add_section(ew, &shdr, &tbuff, name)) { 1160 ERROR("Unable to add ELF section: %s\n", name); 1161 elf_writer_destroy(ew); 1162 return -1; 1163 } 1164 >>> CID 1361276: Uninitialized variables (UNINIT) >>> Using uninitialized value "empty_sz". 1165 if (empty_sz != 0) { 1166 struct buffer b; 1167 1168 buffer_init(&b, NULL, NULL, 0); 1169 memset(&shdr, 0, sizeof(shdr)); 1170 shdr.sh_type = SHT_NOBITS; ** 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 1361273: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1361273: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/host/lib21/host_key.c: 175 in vb21_private_key_read() 169 *key_ptr = NULL; 170 171 rv = vb2_read_file(filename, &buf, &size); 172 if (rv) 173 return rv; 174 >>> CID 1361273: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "buf" to a tainted sink. 175 rv = vb21_private_key_unpack(key_ptr, buf, size); 176 177 free(buf); 178 179 return rv; 180 } ** CID 1361272: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1361272: Insecure data handling (TAINTED_SCALAR) /3rdparty/vboot/host/lib21/host_key.c: 449 in vb21_packed_key_read() 443 *key_ptr = NULL; 444 445 if (vb2_read_file(filename, &buf, &size)) 446 return VB2_ERROR_READ_PACKED_KEY_DATA; 447 448 /* Sanity check: make sure key unpacks properly */ >>> CID 1361272: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "buf" to a tainted sink. 449 if (vb21_unpack_key(&key, buf, size)) 450 return VB2_ERROR_READ_PACKED_KEY; 451 452 *key_ptr = (struct vb21_packed_key *)buf; 453 454 return VB2_SUCCESS; ** CID 1361268: (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1102 in cbfs_payload_make_elf() /util/cbfstool/cbfs_image.c: 1106 in cbfs_payload_make_elf() /util/cbfstool/cbfs_image.c: 1113 in cbfs_payload_make_elf() /util/cbfstool/cbfs_image.c: 1162 in cbfs_payload_make_elf() /util/cbfstool/cbfs_image.c: 1187 in cbfs_payload_make_elf() /util/cbfstool/cbfs_image.c: 1196 in cbfs_payload_make_elf() ________________________________________________________________________________________________________ *** CID 1361268: (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1102 in cbfs_payload_make_elf() 1096 1097 xdr_get_seg(&segs[i], &serialized_seg[i]); 1098 } 1099 1100 if (cbfs_payload_decompress(segs, buff, segments)) { 1101 ERROR("Failed to decompress payload.\n"); >>> CID 1361268: (RESOURCE_LEAK) >>> Variable "segs" going out of scope leaks the storage it points to. 1102 return -1; 1103 } 1104 1105 if (init_elf_from_arch(&ehdr, arch)) 1106 return -1; 1107 /util/cbfstool/cbfs_image.c: 1106 in cbfs_payload_make_elf() 1100 if (cbfs_payload_decompress(segs, buff, segments)) { 1101 ERROR("Failed to decompress payload.\n"); 1102 return -1; 1103 } 1104 1105 if (init_elf_from_arch(&ehdr, arch)) >>> CID 1361268: (RESOURCE_LEAK) >>> Variable "segs" going out of scope leaks the storage it points to. 1106 return -1; 1107 1108 ehdr.e_entry = segs[segments-1].load_addr; 1109 1110 ew = elf_writer_init(&ehdr); 1111 if (ew == NULL) { /util/cbfstool/cbfs_image.c: 1113 in cbfs_payload_make_elf() 1107 1108 ehdr.e_entry = segs[segments-1].load_addr; 1109 1110 ew = elf_writer_init(&ehdr); 1111 if (ew == NULL) { 1112 ERROR("Unable to init ELF writer.\n"); >>> CID 1361268: (RESOURCE_LEAK) >>> Variable "segs" going out of scope leaks the storage it points to. 1113 return -1; 1114 } 1115 1116 for (int i = 0; i < segments; i++) { 1117 struct buffer tbuff; 1118 /util/cbfstool/cbfs_image.c: 1162 in cbfs_payload_make_elf() 1156 } 1157 1158 1159 if (elf_writer_add_section(ew, &shdr, &tbuff, name)) { 1160 ERROR("Unable to add ELF section: %s\n", name); 1161 elf_writer_destroy(ew); >>> CID 1361268: (RESOURCE_LEAK) >>> Variable "segs" going out of scope leaks the storage it points to. 1162 return -1; 1163 } 1164 1165 if (empty_sz != 0) { 1166 struct buffer b; 1167 /util/cbfstool/cbfs_image.c: 1187 in cbfs_payload_make_elf() 1181 1182 } 1183 1184 if (elf_writer_serialize(ew, &elf_out)) { 1185 ERROR("Unable to create ELF file from stage.\n"); 1186 elf_writer_destroy(ew); >>> CID 1361268: (RESOURCE_LEAK) >>> Variable "segs" going out of scope leaks the storage it points to. 1187 return -1; 1188 } 1189 1190 /* Flip buffer with the created ELF one. */ 1191 buffer_delete(buff); 1192 *buff = elf_out; /util/cbfstool/cbfs_image.c: 1196 in cbfs_payload_make_elf() 1190 /* Flip buffer with the created ELF one. */ 1191 buffer_delete(buff); 1192 *buff = elf_out; 1193 1194 elf_writer_destroy(ew); 1195 >>> CID 1361268: (RESOURCE_LEAK) >>> Variable "segs" going out of scope leaks the storage it points to. 1196 return 0; 1197 } 1198 1199 int cbfs_export_entry(struct cbfs_image *image, const char *entry_name, 1200 const char *filename, uint32_t arch) 1201 { ** CID 1361266: (RESOURCE_LEAK) /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 178 in VbWriteNvStorage() /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 182 in VbWriteNvStorage() /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 184 in VbWriteNvStorage() /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 186 in VbWriteNvStorage() /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 189 in VbWriteNvStorage() /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 195 in VbWriteNvStorage() ________________________________________________________________________________________________________ *** CID 1361266: (RESOURCE_LEAK) /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 178 in VbWriteNvStorage() 172 173 int VbWriteNvStorage(VbNvContext* vnc) { 174 unsigned offs, blksz; 175 VbSharedDataHeader *sh = VbSharedDataRead(); 176 177 if (!vnc->raw_changed) >>> CID 1361266: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 178 return 0; /* Nothing changed, so no need to write */ 179 180 /* Get the byte offset from VBNV */ 181 if (ReadFileInt(ACPI_VBNV_PATH ".0", &offs) < 0) 182 return -1; 183 if (ReadFileInt(ACPI_VBNV_PATH ".1", &blksz) < 0) /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 182 in VbWriteNvStorage() 176 177 if (!vnc->raw_changed) 178 return 0; /* Nothing changed, so no need to write */ 179 180 /* Get the byte offset from VBNV */ 181 if (ReadFileInt(ACPI_VBNV_PATH ".0", &offs) < 0) >>> CID 1361266: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 182 return -1; 183 if (ReadFileInt(ACPI_VBNV_PATH ".1", &blksz) < 0) 184 return -1; 185 if (VBNV_BLOCK_SIZE > blksz) 186 return -1; /* NV storage block is too small */ 187 /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 184 in VbWriteNvStorage() 178 return 0; /* Nothing changed, so no need to write */ 179 180 /* Get the byte offset from VBNV */ 181 if (ReadFileInt(ACPI_VBNV_PATH ".0", &offs) < 0) 182 return -1; 183 if (ReadFileInt(ACPI_VBNV_PATH ".1", &blksz) < 0) >>> CID 1361266: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 184 return -1; 185 if (VBNV_BLOCK_SIZE > blksz) 186 return -1; /* NV storage block is too small */ 187 188 if (0 != VbCmosWrite(offs, VBNV_BLOCK_SIZE, vnc->raw)) 189 return -1; /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 186 in VbWriteNvStorage() 180 /* Get the byte offset from VBNV */ 181 if (ReadFileInt(ACPI_VBNV_PATH ".0", &offs) < 0) 182 return -1; 183 if (ReadFileInt(ACPI_VBNV_PATH ".1", &blksz) < 0) 184 return -1; 185 if (VBNV_BLOCK_SIZE > blksz) >>> CID 1361266: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 186 return -1; /* NV storage block is too small */ 187 188 if (0 != VbCmosWrite(offs, VBNV_BLOCK_SIZE, vnc->raw)) 189 return -1; 190 191 /* Also attempt to write using mosys if using vboot2 */ /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 189 in VbWriteNvStorage() 183 if (ReadFileInt(ACPI_VBNV_PATH ".1", &blksz) < 0) 184 return -1; 185 if (VBNV_BLOCK_SIZE > blksz) 186 return -1; /* NV storage block is too small */ 187 188 if (0 != VbCmosWrite(offs, VBNV_BLOCK_SIZE, vnc->raw)) >>> CID 1361266: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 189 return -1; 190 191 /* Also attempt to write using mosys if using vboot2 */ 192 if (sh && (sh->flags & VBSD_BOOT_FIRMWARE_VBOOT2)) 193 VbWriteNvStorage_mosys(vnc); 194 /3rdparty/vboot/host/arch/x86_64/lib/crossystem_arch.c: 195 in VbWriteNvStorage() 189 return -1; 190 191 /* Also attempt to write using mosys if using vboot2 */ 192 if (sh && (sh->flags & VBSD_BOOT_FIRMWARE_VBOOT2)) 193 VbWriteNvStorage_mosys(vnc); 194 >>> CID 1361266: (RESOURCE_LEAK) >>> Variable "sh" going out of scope leaks the storage it points to. 195 return 0; 196 } 197 198 199 /* 200 * Get buffer data from ACPI. ** CID 1361263: Error handling issues (NEGATIVE_RETURNS) /3rdparty/vboot/host/lib/crossystem.c: 743 in InAndroid() ________________________________________________________________________________________________________ *** CID 1361263: Error handling issues (NEGATIVE_RETURNS) /3rdparty/vboot/host/lib/crossystem.c: 743 in InAndroid() 737 struct stat s; 738 739 /* In Android, mosys utility located in /system/bin 740 check if file exists. Using fstat because for some 741 reason, stat() was seg faulting in Android */ 742 fd = open(MOSYS_ANDROID_PATH, O_RDONLY); >>> CID 1361263: 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.] 743 if (fstat(fd, &s) == 0) { 744 close(fd); 745 return 1; 746 } 747 close(fd); 748 return 0; ** CID 1361261: Control flow issues (MISSING_BREAK) /src/soc/intel/quark/reg_access.c: 167 in reg_cpu_cr_write() ________________________________________________________________________________________________________ *** CID 1361261: Control flow issues (MISSING_BREAK) /src/soc/intel/quark/reg_access.c: 167 in reg_cpu_cr_write() 161 default: 162 die("ERROR - Unsupported CPU register!\n"); 163 164 case 0: 165 write_cr0(value); 166 >>> CID 1361261: Control flow issues (MISSING_BREAK) >>> The above case falls through to this one. 167 case 4: 168 write_cr4(value); 169 } 170 } 171 172 static uint32_t reg_gpe0_read(uint32_t reg_address) ** CID 1361259: Insecure data handling (INTEGER_OVERFLOW) /3rdparty/vboot/host/lib21/host_keyblock.c: 56 in vb21_keyblock_create() ________________________________________________________________________________________________________ *** CID 1361259: Insecure data handling (INTEGER_OVERFLOW) /3rdparty/vboot/host/lib21/host_keyblock.c: 56 in vb21_keyblock_create() 50 return VB2_KEYBLOCK_CREATE_DATA_KEY; 51 52 kb.sig_offset = kb.key_offset + key->c.total_size; 53 kb.c.total_size = kb.sig_offset + sig_size; 54 55 /* Allocate buffer and copy header and data key */ >>> CID 1361259: Insecure data handling (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "kb.c.total_size" used as critical argument to function. [Note: The source code implementation of the function has been overridden by a builtin model.] 56 buf = calloc(1, kb.c.total_size); 57 if (!buf) { 58 free(key); 59 return VB2_KEYBLOCK_CREATE_ALLOC; 60 } 61 ** CID 1361254: (CHECKED_RETURN) /util/cbfstool/cbfs_image.c: 850 in cbfs_payload_decompress() /util/cbfstool/cbfs_image.c: 881 in cbfs_payload_decompress() ________________________________________________________________________________________________________ *** CID 1361254: (CHECKED_RETURN) /util/cbfstool/cbfs_image.c: 850 in cbfs_payload_decompress() 844 845 /* Find out and allocate the amount of memory occupied 846 * by the binary data */ 847 for (int i = 0; i < num_seg; i++) 848 new_buff_sz += segments[i].mem_len; 849 >>> CID 1361254: (CHECKED_RETURN) >>> Calling "buffer_create" without checking return value (as is done elsewhere 13 out of 16 times). 850 buffer_create(&new_buffer, new_buff_sz, "decompressed_buff"); 851 852 in_ptr = buffer_get(buff) + new_offset; 853 out_ptr = buffer_get(&new_buffer) + new_offset; 854 855 for (int i = 0; i < num_seg; i++) { /util/cbfstool/cbfs_image.c: 881 in cbfs_payload_decompress() 875 in_ptr += segments[i].len; 876 out_ptr += segments[i].len; 877 segments[i].compression = CBFS_COMPRESS_NONE; 878 continue; 879 } 880 >>> CID 1361254: (CHECKED_RETURN) >>> Calling "buffer_create" without checking return value (as is done elsewhere 13 out of 16 times). 881 buffer_create(&tbuff, segments[i].mem_len, "segment"); 882 883 if (decompress(in_ptr, segments[i].len, buffer_get(&tbuff), 884 (int) buffer_size(&tbuff), 885 &decomp_size)) { 886 ERROR("Couldn't decompress payload segment %u\n", i); ** 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: 284 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353028: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 284 in integrate_psp_firmwares() 278 pspdir[4+4*i+2] = 1; 279 pspdir[4+4*i+3] = 0; 280 } else if (fw_table[i].filename != NULL) { 281 pspdir[4+4*i+0] = fw_table[i].type; 282 283 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.] 284 fstat(fd, &fd_stat); 285 pspdir[4+4*i+1] = fd_stat.st_size; 286 287 pspdir[4+4*i+2] = pos + ROM_BASE_ADDRESS; 288 pspdir[4+4*i+3] = 0; 289 ** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 239 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 239 in integrate_firmwares() 233 struct stat fd_stat; 234 int i; 235 236 for (i = 0; fw_table[i].type != AMD_FW_INVALID; i ++) { 237 if (fw_table[i].filename != NULL) { 238 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.] 239 fstat(fd, &fd_stat); 240 241 switch (fw_table[i].type) { 242 case AMD_FW_IMC: 243 pos = ALIGN(pos, 0x10000); 244 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 34 out of 42 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: 290 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353021: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 290 in integrate_psp_firmwares() 284 fstat(fd, &fd_stat); 285 pspdir[4+4*i+1] = fd_stat.st_size; 286 287 pspdir[4+4*i+2] = pos + ROM_BASE_ADDRESS; 288 pspdir[4+4*i+3] = 0; 289 >>> CID 1353021: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 290 read (fd, base+pos, fd_stat.st_size); 291 292 pos += fd_stat.st_size; 293 pos = ALIGN(pos, 0x100); 294 close (fd); 295 } else { ** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_psp_firmwares() 278 pspdir[4+4*i+2] = 1; 279 pspdir[4+4*i+3] = 0; 280 } else if (fw_table[i].filename != NULL) { 281 pspdir[4+4*i+0] = fw_table[i].type; 282 283 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.] 284 fstat(fd, &fd_stat); 285 pspdir[4+4*i+1] = fd_stat.st_size; 286 287 pspdir[4+4*i+2] = pos + ROM_BASE_ADDRESS; 288 pspdir[4+4*i+3] = 0; 289 ** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 257 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 257 in integrate_firmwares() 251 break; 252 default: 253 /* Error */ 254 break; 255 } 256 >>> CID 1353019: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 257 read (fd, base+pos, fd_stat.st_size); 258 259 pos += fd_stat.st_size; 260 pos = ALIGN(pos, 0x100); 261 close (fd); 262 } ________________________________________________________________________________________________________ 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

How do I build Coreboot with both normal and fallback?
by Yaroslav K. 05 Aug '16

05 Aug '16

Hello! Coreboot's bootblock_normal.c supports booting a fallback romstage if a normal romstage boot fails. But you can only specify either "fallback" or "normal" in CONFIG_CBFS_PREFIX. So how do I build an image with both normal and fallback stages set? -- Yaroslav

1 0

Re: [coreboot] w83627 uart port is not workable with coreboot in linux
by Nico Huber 05 Aug '16

05 Aug '16

Hi Cheng, On 25.07.2016 04:33, cheng yichen wrote: > Hi all > > After i follow kontron/ktqm77 setting. I can't solve the issue. > I try to change iqr(for com1) to 5 or 6. but system can't print linux > message and minicom is not workable. Can you confirm that you see the full coreboot log on your UART? With log level >= debug, it should end with lines about loading the payload, containing a line starting with "Jumping to boot code at". If you see this line, it's unlikely to be a coreboot issue. If not, please provide a full log with highest log level. Also the output of `lspci -xxx`, `cbmem -c` and your devicetree.cb might be helpful. Another way to test the UART is to use Linux' earlycon driver, e.g. with earlycon=uart8250,io,0x3f8,115200n8 in your kernel command line. This driver is simpler than the serial8250 (it doesn't use interrupts and is closer to what coreboot's driver does). Nico > > > > dump from superiotool > Found Winbond W83627DHG-P/-PT (id=0xb0, rev=0x73) at 0x2e > Register dump: > idx 02 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > val ff b0 73 ff 00 42 00 00 ff 50 80 00 00 eb 21 00 ff > def 00 b0 NA ff 00 MM 00 MM RR 50 00 00 RR e2 21 00 00 > LDN 0x00 (Floppy) > idx 30 60 61 70 74 f0 f1 f2 f4 f5 > val 01 03 f0 06 02 8e 00 ff 00 00 > def 01 03 f0 06 02 8e 00 ff 00 00 > LDN 0x01 (Parallel port) > idx 30 60 61 70 74 f0 > val 01 03 78 07 04 3f > def 01 03 78 07 04 3f > LDN 0x02 (COM1) > idx 30 60 61 70 f0 > val 01 03 f8 04 40 > def 01 03 f8 04 00 > LDN 0x03 (COM2) > idx 30 60 61 70 f0 f1 > val 01 02 f8 03 40 00 > def 01 02 f8 03 00 00 > LDN 0x05 (Keyboard) > > > dump from dmesg > > home# dmesg | grep -i tty > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic > root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1 > console=ttyS0,115200n8 quiet splash vt.handoff=7 > [ 0.000000] Kernel command line: > BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic > root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1 > console=ttyS0,115200n8 quiet splash vt.handoff=7 > [ 0.000000] console [tty1] enabled > [ 0.000000] console [ttyS0] enabled > [ 1.637664] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a > 16550A > [ 1.658835] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) > is a 16550A > [ 3.412478] fbcon: Remapping primary device, fb1, to tty 1-63 > [ 44.378835] systemd[1]: Created slice system-serial\x2dgetty.slice. > [ 44.380198] systemd[1]: Created slice system-getty.slice. > > > > > > 2016-07-22 20:24 GMT+08:00 Kyösti Mälkki <kyosti.malkki(a)gmail.com>: > >> On Fri, Jul 22, 2016 at 1:14 PM, cheng yichen <blessyichen(a)gmail.com> >> wrote: >>> Hi all >>> >>> My platform is braswell SOC with W83627dhg superIO. In post stage I can >> get >>> debug message over w83627 uart1(3f8/irq4). but after boot to linux, uart >>> port is not woarkable. I test the function by minicom but I can't receive >>> and send data. I can get uart information by dmesg command. >>> How to initial it in corebooot? >> >> Does not sound like a coreboot issue to me. >> >> Do you have CTS/RTS hardware handshake disabled in minicom >> configuration? If you directed kernel console to serial port, you >> should not (cannot) use the port for user apps. >> >> HTH, >> Kyösti >> > > >

2 1

ASUS KFSN4-DRE (K8) Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 05 Aug '16

05 Aug '16

The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 6e05c33626e128c383470579f423b1ee569302ba The following tests failed: BOOT_FAILURE Commits since last successful test: 6e05c33 checkpatch: Add BLOCK_COMMENT_STYLE to ignore list 88a25ec 3rdparty/vboot: update to latest master 9a162d7 toolchain.inc: Update 'required toolchain' error text 751bff1 sb/amd/sb700: Do not reset fifo after skipping the sent bytes 8ff2480 chromeec: Chrome EC firmware source selection for EC and PD firmwares <9 commits skipped> d1a0051 google/gale: Add more board ID variants 40d62f3 google/gru: Add code to support I2C TPM for Kevin 5e6771b google/gru: Add support for Gru rev1 47ca65a payloads/coreinfo: Set KCONFIG_CONFIG value 5fafc6a soc/intel/quark: Support access to CPU CR registers See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Extracting EC firmware from EFI firmware
by ron minnich 04 Aug '16

04 Aug '16

That's quite neat ... ron On Thu, Aug 4, 2016 at 5:12 AM Łukasz Dobrowolski <spectrallynx(a)gmail.com> wrote: > I discovered that ITE often uses 8032 in their EC's. Those start from > address 0. > After some changing cbfs size in menuconfig and playing a bit with dd > i was able to get the board to turn on and display postcodes. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Extracting EC firmware from EFI firmware
by Łukasz Dobrowolski 04 Aug '16

04 Aug '16

I discovered that ITE often uses 8032 in their EC's. Those start from address 0. After some changing cbfs size in menuconfig and playing a bit with dd i was able to get the board to turn on and display postcodes.

1 0

Re: [coreboot] USB3.0 enumeration in Baytrail E3845 with coreboot
by Naveed Ghori 04 Aug '16

04 Aug '16

Mayuri If you have eHCI enabled then it may use that instaed of xHCI. With eHCI you will not have any USB 3.0 support. There is switching mode for enabling xHCI in the OS and use eHCI during boot but it does not appear to be supported as is in the FSP. I had attempted to get this going but found the easier way is to enabled xHCI only. However you then have to mod Windows 7 install image (boot,img) file to support the xHCI intel drivers or you will not have any USB devices working in the installer (including the installation USB). Naveed From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Mayuri Tendulkar Sent: Thursday, 4 August 2016 1:15 PM To: Zoran Stojsavljevic Cc: coreboot Subject: Re: [coreboot] USB3.0 enumeration in Baytrail E3845 with coreboot Hi Zoran Thanks for your inputs. I am checking on Ubuntu. As per minnowmax, devicetree.cb file, below like says default will be EHCI. How we should change it at runtime, what is the setting? device pci 14.0 on end # 8086 0F35 - USB XHCI - Onboard & HSEC - Enabling both EHCI and XHCI will default to EHCI if not changed at runtime device pci 1d.0 on end # 8086 0F34 - USB EHCI - Enabling both EHCI and XHCI will default to EHCI if not changed at runtime regards Mayuri From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: 04 August 2016 01:06 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> Cc: coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>> Subject: Re: [coreboot] USB3.0 enumeration in Baytrail E3845 with coreboot Hello Mayuri, Some of us (at least me) know that INTEL USB 3.0 implementations have here and there mortal problems for years, as well as in CORE, also in ATOM families. There are lists of problems, but most of them are closed Intellectual Properties, INTEL Inside. I had yesterday terrible problem to set CANON PIXMA MG3650 home printer edition I bought in Saturn to pair over USB with my mobile i5-4300 INTEL Inside HSW laptop (CPUID 0x40561), so I needed 4 hours to investigate and find the interim solution for INTEL buggy embedded USB 3.0 root port (it is consumers' QA issue with INTEL design, so INTEL should take care of this, my best guess)... :-(( In this lieu I will advise you the two way approach. One is to contact/to engage with your INTEL FAE/representative, and ask him about the problems which are well described in internal INTEL documents (BYT wise). The other approach is to work out these problems yourself. So, there are several facts about the USB 3.0. There are (my best guess) some BYT USB fixes done by other people in Coreboot. I'll let these people to speak for themselves. If? You can also try to bring some Linux distros (Fedora for example) and try to see what is going on while you bring up the system (dmesg log). Also you can do the following commands: lsusb -v lsusb -t At least, you can do lsusb --h to see options which can help you to start debugging this issue. Zoran On Wed, Aug 3, 2016 at 11:23 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote: Hi I am facing issue in enumerating USB3.0 device on baytrail processor with coreboot with seabios. Is there any setting in coreboot where we need to enable this separately. Regards Mayuri "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot<https://linkprotect.cudasvc.com/url?a=https://www.coreboot.org/mailman/list…> "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

2 1

← Newer
1
...
8
9
10
11
12
13
14
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 August 2016