coreboot December 2016

coreboot@coreboot.org

57 participants
121 discussions

FOSDEM 2017
by Carl-Daniel Hailfinger 10 Dec '16

10 Dec '16

Hi, FOSDEM 2017 deadlines are soon. Do we want to have a full developer room, a talk or just a stand? Unfortunately I won't be able to attend, so someone else will have to be the formal contact for organizing our stand/devroom/talk. I will help with submitting proposals if this is desired by the person organizing our stand/devroom/... Who is willing to take care of our FOSDEM 2017 presence? https://fosdem.org/2017/news/2016-07-20-call-for-participation/ Deadlines: Developer Rooms: 9 September Main Track Talks: 10 October Stands: 31 October Lightning talks: 25 November Regards, Carl-Daniel

2 1

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

09 Dec '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 42 new defect(s) introduced to coreboot found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 42 defect(s) ** 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 36 out of 45 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 1325836: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1413 in cbfs_print_entry_info() ________________________________________________________________________________________________________ *** CID 1325836: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1413 in cbfs_print_entry_info() 1407 char *hash_str = bintohex(hash->hash_data, hash_len); 1408 uint8_t local_hash[hash_len]; 1409 if (vb2_digest_buffer(CBFS_SUBHEADER(entry), 1410 ntohl(entry->len), hash_type, local_hash, 1411 hash_len) != VB2_SUCCESS) { 1412 fprintf(fp, "failed to hash '%s'\n", name); >>> CID 1325836: Resource leaks (RESOURCE_LEAK) >>> Variable "hash_str" going out of scope leaks the storage it points to. 1413 break; 1414 } 1415 int valid = memcmp(local_hash, hash->hash_data, hash_len) == 0; 1416 const char *valid_str = valid ? "valid" : "invalid"; 1417 1418 fprintf(fp, " hash %s:%s %s\n", ** CID 1323515: Error handling issues (CHECKED_RETURN) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323515: Error handling issues (CHECKED_RETURN) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() 106 } else { 107 return SBIUsage(); 108 } 109 --ac, ++av; 110 } 111 >>> CID 1323515: Error handling issues (CHECKED_RETURN) >>> Calling "stat(bl, &file_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.] 112 stat(bl, &file_stat); 113 filesize = file_stat.st_size + MIN_SIZE; 114 buf = calloc(sizeof(uint8_t), filesize); 115 116 if (buf == NULL) { 117 puts("Memory allocation error"); ** CID 1323512: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323512: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() 106 } else { 107 return SBIUsage(); 108 } 109 --ac, ++av; 110 } 111 >>> CID 1323512: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "bl" to "stat", which dereferences it. [Note: The source code implementation of the function has been overridden by a builtin model.] 112 stat(bl, &file_stat); 113 filesize = file_stat.st_size + MIN_SIZE; 114 buf = calloc(sizeof(uint8_t), filesize); 115 116 if (buf == NULL) { 117 puts("Memory allocation error"); ** CID 1323511: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 80 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323511: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 80 in CreateSecureBootImage() 74 * Purpose : 75 * Input : none 76 * Output : none 77 *---------------------------------------------------------------------*/ 78 int CreateSecureBootImage(int ac, char **av) 79 { >>> CID 1323511: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "privkey" = "NULL". 80 char *outfile, *configfile, *arg, *privkey = NULL, *bl = NULL; 81 int status = 0; 82 uint32_t sbiLen; 83 struct stat file_stat; 84 uint32_t add_header = 1; 85 outfile = *av; ** CID 1323510: Error handling issues (NEGATIVE_RETURNS) /util/broadcom/secimage/io.c: 81 in DataRead() ________________________________________________________________________________________________________ *** CID 1323510: Error handling issues (NEGATIVE_RETURNS) /util/broadcom/secimage/io.c: 81 in DataRead() 75 len = FileSizeGet(file); 76 if (len < *length) 77 *length = len; 78 else 79 /* Do not exceed the maximum length of the buffer */ 80 len = *length; >>> CID 1323510: Error handling issues (NEGATIVE_RETURNS) >>> "len" is passed to a parameter that cannot be negative. 81 if (fread((uint8_t *)buf, 1, len, file) != len) { 82 printf("Error reading data (%d bytes) from file: %s\n", 83 len, filename); 84 return -1; 85 } 86 fclose(file); ** CID 1323509: Resource leaks (RESOURCE_LEAK) /util/broadcom/secimage/io.c: 84 in DataRead() ________________________________________________________________________________________________________ *** CID 1323509: Resource leaks (RESOURCE_LEAK) /util/broadcom/secimage/io.c: 84 in DataRead() 78 else 79 /* Do not exceed the maximum length of the buffer */ 80 len = *length; 81 if (fread((uint8_t *)buf, 1, len, file) != len) { 82 printf("Error reading data (%d bytes) from file: %s\n", 83 len, filename); >>> CID 1323509: Resource leaks (RESOURCE_LEAK) >>> Variable "file" going out of scope leaks the storage it points to. 84 return -1; 85 } 86 fclose(file); 87 return 0; 88 } 89 ** CID 1323508: Resource leaks (RESOURCE_LEAK) /util/broadcom/secimage/misc.c: 56 in FillHeaderFromConfigFile() ________________________________________________________________________________________________________ *** CID 1323508: Resource leaks (RESOURCE_LEAK) /util/broadcom/secimage/misc.c: 56 in FillHeaderFromConfigFile() 50 ptr += strlen("Reserved="); 51 sscanf(ptr, "%x", &Reserved); 52 h1->Reserved = Reserved; 53 } 54 } 55 } >>> CID 1323508: Resource leaks (RESOURCE_LEAK) >>> Variable "fp" going out of scope leaks the storage it points to. ** CID 1323473: Memory - illegal accesses (STRING_NULL) /util/broadcom/secimage/misc.c: 36 in FillHeaderFromConfigFile() ________________________________________________________________________________________________________ *** CID 1323473: Memory - illegal accesses (STRING_NULL) /util/broadcom/secimage/misc.c: 36 in FillHeaderFromConfigFile() 30 31 fp = fopen(ConfigFileName, "rb"); 32 if (fp != NULL) { 33 printf("\r\n Reading config information from file \r\n"); 34 byte_count = fread(filebuffer, 1, 2048, fp); 35 if (byte_count > 0) { >>> CID 1323473: Memory - illegal accesses (STRING_NULL) >>> Passing unterminated string "filebuffer" to "strstr", which expects a null-terminated string. [Note: The source code implementation of the function has been overridden by a builtin model.] 36 ptr = strstr((char *)filebuffer, "Tag="); 37 if (ptr) { 38 ptr += strlen("Tag="); 39 sscanf(ptr, "%x", &Tag); 40 h1->Tag = Tag; 41 } ________________________________________________________________________________________________________ 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] Developing Coreboot
by Klemens Nanni 08 Dec '16

08 Dec '16

On Thu, Dec 08, 2016 at 08:00:49PM +0300, serdar tunc wrote: >Good Evening, >I am computer engineering student in Canakkale Onsekiz Mart University >and its my fourth year. >I want to be a part of Coreboot Project. I compiled Coreboot and >Libreboot for qemu emulator and as soon as possible i am going to >install Coreboot in x200. As you can see i am interested in opensource >projects and low level programming like C and Assembly. I wanted to >start somewhere but i couldn't found where to start. There is not >associated documents in Coreboot Wiki and i tought it could be helpful >if i contact with Coreboot team. Can you lead me for where should i >start, what should i do, what should i learn and read? It will be >great if you send me documents about this. Have a good night. With my >best regards. Nice to hear that, be welcome! In general I'd say you pick a topic of interest and dig into it, try finding bugs or improving existing parts. The wiki can always be improved: Some boards need a page, various sections are somewhat short/outdated/confusing/etc. so in case you're coming across besaid documenatation (or not): Go ahead and improve/start writing it. You don't have to make big changes in order to contribute, even the smallest improvements are welcome. Some project ideas[1] already exist, if you find something that suits you: Go for it! /kl3 1: https://www.coreboot.org/Project_Ideas

1 0

Developing Coreboot
by serdar tunc 08 Dec '16

08 Dec '16

Good Evening, I am computer engineering student in Canakkale Onsekiz Mart University and its my fourth year. I want to be a part of Coreboot Project. I compiled Coreboot and Libreboot for qemu emulator and as soon as possible i am going to install Coreboot in x200. As you can see i am interested in opensource projects and low level programming like C and Assembly. I wanted to start somewhere but i couldn't found where to start. There is not associated documents in Coreboot Wiki and i tought it could be helpful if i contact with Coreboot team. Can you lead me for where should i start, what should i do, what should i learn and read? It will be great if you send me documents about this. Have a good night. With my best regards. Serdar Oktay TUNÇ

1 0

Re: [coreboot] Neutralizing ME firmware
by Persmule 07 Dec '16

07 Dec '16

Hi Lee, Now I am doubting whether I would get arrested like Dmitry Sklyarov <https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd.> if I were to step on the land of USA, for I do not know the opinion about my actions of those DMCA <https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act>-supporters. Regard, Persmule 在 2016年11月30日 00:27, Lee Whitney 写道: > > Hi Persmule, > > > In case you didn't see it, your article was well received on HN (link > below). > > > Also I made an offer in the comments, good anytime if you come through > Texas someday: > > >Beautiful work. Standing offer to buy dinner for any of the contributors > >if they come through Dallas. > > Keep up the good work. > > Regards, > Lee > > https://news.ycombinator.com/item?id=13056997 >

3 2

[RFC] How to add “nested” time stamps?
by Paul Menzel 06 Dec '16

06 Dec '16

Dear coreboot folks, I’d like to add more time stamps for instrumentation/benchmarking. I started with the timer initialization, and submitted two change sets [1][2]. After rebuilding the utility `cbmem`, the relevant output looks like below. ``` 60:device initialization 457,880 (9,886) 120:starting timer init 472,001 (14,121) 121:finished timer init 472,008 (6) 70:device setup done 472,751 (742) ``` Would that be acceptable to have nested entries? The down side is, the time from *device initialization* to *device setup done* has to be calculated manually now. Also, I just chose the numbers 120 and 121 arbitrarily. Are there any best practices for that to keep that extensible? Thanks, Paul PS: If somebody has an idea on the weird build error on the DMP Vortex86EX [3], I’d appreciate any help. ``` ROMCC romstage.inc timestamp_serialized.h:23.16: bad type specifier :ident: src/arch/x86/Makefile.inc:254: recipe for target '/dev/cb-build/coreboot-gerrit.0/DMP_EX/mainboard/dmp/vortex86ex/romstage.inc' failed make[1]: *** [/dev/cb-build/coreboot-gerrit.0/DMP_EX/mainboard/dmp/vortex86ex/romstage.inc] Error 1 make[1]: Leaving directory '/home/coreboot/slave-root/workspace/coreboot-gerrit' ``` [1] https://review.coreboot.org/17701 [2] https://review.coreboot.org/17702 [3] https://qa.coreboot.org/job/coreboot-gerrit/47088/testReport/junit/%28root%…

3 2

Re: [coreboot] commit 94f8699 bricks my Lenovo X230
by Furquan Shaikh 05 Dec '16

05 Dec '16

Can you please try this out and let me know if it fixes things for you: https://review.coreboot.org/#/c/17728/1 For some reason I am not able to add you as a reviewer to the change. On Mon, Dec 5, 2016 at 7:51 PM, Furquan Shaikh <furquan.m.shaikh(a)gmail.com> wrote: > I have found the issue. Working on the fix right now. > > > On Mon, Dec 5, 2016 at 7:33 PM, Furquan Shaikh <furquan.m.shaikh(a)gmail.com > > wrote: > >> Hello Iru, >> >> On Mon, Dec 5, 2016 at 7:22 PM, Iru Cai <mytbk920423(a)gmail.com> wrote: >> >>> Hi, >>> >>> The latest git code bricks my Lenovo X230. After a git bisect, I found >>> the bad commit is 9438699[1] and reverting will work. The log from USB >>> debug console says there's an exception after the ``erase MRC cache`` >>> message. >>> >> >> Can you please attach the complete log so that I can take a look? >> >>> >>> Lenovo X230 has two flash chips. I don't know if it's related to this. >>> >> yes, that could be related. >> >>> >>> [1]: https://review.coreboot.org/#/c/17684/ >>> >>> Iru >>> >>> -- >>> Please do not send me Microsoft Office/Apple iWork documents. Send >>> OpenDocument instead! http://fsf.org/campaigns/opendocument/ >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >

1 0

Re: [coreboot] commit 94f8699 bricks my Lenovo X230
by Furquan Shaikh 05 Dec '16

05 Dec '16

I have found the issue. Working on the fix right now. On Mon, Dec 5, 2016 at 7:33 PM, Furquan Shaikh <furquan.m.shaikh(a)gmail.com> wrote: > Hello Iru, > > On Mon, Dec 5, 2016 at 7:22 PM, Iru Cai <mytbk920423(a)gmail.com> wrote: > >> Hi, >> >> The latest git code bricks my Lenovo X230. After a git bisect, I found >> the bad commit is 9438699[1] and reverting will work. The log from USB >> debug console says there's an exception after the ``erase MRC cache`` >> message. >> > > Can you please attach the complete log so that I can take a look? > >> >> Lenovo X230 has two flash chips. I don't know if it's related to this. >> > yes, that could be related. > >> >> [1]: https://review.coreboot.org/#/c/17684/ >> >> Iru >> >> -- >> Please do not send me Microsoft Office/Apple iWork documents. Send >> OpenDocument instead! http://fsf.org/campaigns/opendocument/ >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

Re: [coreboot] commit 94f8699 bricks my Lenovo X230
by Furquan Shaikh 05 Dec '16

05 Dec '16

Hello Iru, On Mon, Dec 5, 2016 at 7:22 PM, Iru Cai <mytbk920423(a)gmail.com> wrote: > Hi, > > The latest git code bricks my Lenovo X230. After a git bisect, I found the > bad commit is 9438699[1] and reverting will work. The log from USB debug > console says there's an exception after the ``erase MRC cache`` message. > Can you please attach the complete log so that I can take a look? > > Lenovo X230 has two flash chips. I don't know if it's related to this. > yes, that could be related. > > [1]: https://review.coreboot.org/#/c/17684/ > > Iru > > -- > Please do not send me Microsoft Office/Apple iWork documents. Send > OpenDocument instead! http://fsf.org/campaigns/opendocument/ > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

commit 94f8699 bricks my Lenovo X230
by Iru Cai 05 Dec '16

05 Dec '16

Hi, The latest git code bricks my Lenovo X230. After a git bisect, I found the bad commit is 9438699[1] and reverting will work. The log from USB debug console says there's an exception after the ``erase MRC cache`` message. Lenovo X230 has two flash chips. I don't know if it's related to this. [1]: https://review.coreboot.org/#/c/17684/ Iru -- Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2016