coreboot January 2017

coreboot@coreboot.org

75 participants
186 discussions

Re: [coreboot] Question about PCIe separate reference clock
by Kyösti Mälkki 13 Jan '17

13 Jan '17

On Fri, Jan 13, 2017 at 6:01 PM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > About "Asynchronous clock mode on mainboard side", I guess. > > > Both the device and bridge have the fields "slot clock configuration" and > "common clock configuration". > Again assuming the mainboard side is CPU (some AMD SoC) and you are running coreboot and can bodify binaryPI / AGESA firmware. You can spoof this in the firmware and leave "Common Clock Configuration" bit unset on both sides, even if they report "Slot Clock Configuration = 1". This affects the ASPM L0s and L1 latencies devices report in the Link Capabilities register, but may also change hardware behaviour since specs require link retraining after bit is set. On our board, both the"slot clock configuration" of device (E8860) and > bridge are 1. > > > Does it mean the "on mainboard" side it does not support "Asynchronous > clock mode"? > So, any specs from the mainboard or CPU side of the link? Ultimately your 100MHz clock stability and jitter is affected by the choice of your 25MHz crystal part and PCB layout, right? Kyösti > ------------------------------ > *From:* Predrag Vidic <pvidic(a)gmail.com> > *Sent:* Friday, January 13, 2017 10:29 AM > > *To:* Zheng Bao > *Cc:* Zoran Stojsavljevic; coreboot(a)coreboot.org > *Subject:* Re: [coreboot] Question about PCIe separate reference clock > > Hi Zheng, > > Schematic is simple and OK. I assume you are trying to run Wolf > VPXxx-E8860-xxxx or similar GPU borad. You can't do much there if there is > a hardware problem but it is most possibly a software setup problem. > > VPX does not have incomming clock so it is by default in async_clock mode. > The question is did you allowed that mode on the main board side? > > Asynchronous clock mode is not default mode for a motherboard. Check if > the mode is allowed. Second, check if the other PCIe device can work on the > motherboard PCIe slot. > > Regards, > Predrag > > > On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > >> Here is the ref clk part. Please review. >> >> No refclk routes to VPX connector. >> >> >> Thanks. >> >> >> Zheng >> ------------------------------ >> *From:* Predrag Vidic <pvidic(a)gmail.com> >> *Sent:* Thursday, January 12, 2017 6:53 PM >> *To:* Zheng Bao >> *Cc:* Zoran Stojsavljevic; coreboot(a)coreboot.org >> >> *Subject:* Re: [coreboot] Question about PCIe separate reference clock >> >> Hi Zheng, >> >> Without knowing the particular solution for the PCIe transmitter you have >> on your board, I'd check refclk pins on your design for the proper >> termination. The problem can be in irregular readings from the pins. >> >> Reragds, >> Predrag >> >> On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: >> >>> Q: do you use local xtal attached to Si52111-B5 to generate local PCIe >>> 25MHz clock? >>> >>> Zheng: yes >>> >>> >>> Q: If you dothis, my next question is how you synchronize these two >>> clocks: Local >>> PCIe 25 MHz and common reference clock from CPU? >>> >>> Zheng: We do NOT sync these two. >>> >>> >>> Q: Since these two clocks, as I understand above scenario, are >>> asynchronous to each other?! >>> >>> Zheng: yes. Asynchronous. >>> >>> >>> The VPX connector does not have a PCIe ref clock signal, so we can not >>> send CPU PCIe ref clock to >>> >>> device. The PCIe spec says if the separate refclk on devices should be >>> 100MHz ± 300PPM, with SSC >>> >>> off. We believe our board meet this requirement. So we doubt the >>> problem lies in PCI configration space. >>> >>> >>> Zheng >>> >>> >>> >>> ------------------------------ >>> *From:* Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> >>> *Sent:* Thursday, January 12, 2017 9:22 AM >>> *To:* Zheng Bao; Predrag Vidic >>> *Cc:* coreboot(a)coreboot.org >>> *Subject:* Re: [coreboot] Question about PCIe separate reference clock >>> >>> Hello Zheng, >>> >>> For decades, I've been FW/SW engineer, but I do understand a little >>> bit of a HW. I have looked into the Si52111-B5 data sheet for >>> clarification. >>> >>> My problem here is to understand, your use case: do you use local xtal >>> attached to Si52111-B5 to generate local PCIe 25MHz clock? If you do >>> this, my next question is how you synchronize these two clocks: Local >>> PCIe 25 MHz and common reference clock from CPU? >>> >>> Since these two clocks, as I understand above scenario, are >>> asynchronous to each other?! >>> >>> Please, clarify for us your use case. >>> >>> Thank you, >>> Zoran >>> _______ >>> >>> On 1/12/17, Zheng Bao <fishbaoz(a)hotmail.com> wrote: >>> > Our VPX design uses separate reference clock source, which is >>> Si52111-B5 (No >>> > spread), instead of common ref clock from CPU. >>> > Now The system is unstable. Reading PCIE configuration space is >>> unstable >>> > too. (If we add some fly wire to make it work with common ref clock, >>> the >>> > system becomes stable.) >>> > >>> > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit >>> indicates >>> > that the >>> > component uses the same physical reference clock that the >>> > platform provides on the connector. If the device uses an >>> > independent clock irrespective of the presence of a reference >>> > clock on the connector, this bit must be clear. >>> > For a multi-Function device, each Function must report the >>> > same value for this bit.) >>> > >>> > Based on my understanding, the BIOS need to read bit "Slot Clock >>> > Configurationclear" to see if >>> > separate ref clock is used. BIOS then write bit "Common Clock >>> > Configuration". >>> > >>> > On our board, the bit "Slot Clock Configuration" is always 1, which I >>> assume >>> > should be 0. >>> > >>> > My question is, how the hardware affect the bit "Slot Clock >>> Configuration"? >>> > How do we need to design our board to make the bit "Slot Clock >>> > Configuration" be 0? >>> > >>> > Thanks. >>> > >>> > Zheng >>> > >>> > >>> >> >> > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Question about PCIe separate reference clock
by Zheng Bao 13 Jan '17

13 Jan '17

About "Asynchronous clock mode on mainboard side", I guess. Both the device and bridge have the fields "slot clock configuration" and "common clock configuration". On our board, both the"slot clock configuration" of device (E8860) and bridge are 1. Does it mean the "on mainboard" side it does not support "Asynchronous clock mode"? Zheng ________________________________ From: Predrag Vidic <pvidic(a)gmail.com> Sent: Friday, January 13, 2017 10:29 AM To: Zheng Bao Cc: Zoran Stojsavljevic; coreboot(a)coreboot.org Subject: Re: [coreboot] Question about PCIe separate reference clock Hi Zheng, Schematic is simple and OK. I assume you are trying to run Wolf VPXxx-E8860-xxxx or similar GPU borad. You can't do much there if there is a hardware problem but it is most possibly a software setup problem. VPX does not have incomming clock so it is by default in async_clock mode. The question is did you allowed that mode on the main board side? Asynchronous clock mode is not default mode for a motherboard. Check if the mode is allowed. Second, check if the other PCIe device can work on the motherboard PCIe slot. Regards, Predrag On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: Here is the ref clk part. Please review. No refclk routes to VPX connector. Thanks. Zheng ________________________________ From: Predrag Vidic <pvidic(a)gmail.com<mailto:pvidic@gmail.com>> Sent: Thursday, January 12, 2017 6:53 PM To: Zheng Bao Cc: Zoran Stojsavljevic; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Question about PCIe separate reference clock Hi Zheng, Without knowing the particular solution for the PCIe transmitter you have on your board, I'd check refclk pins on your design for the proper termination. The problem can be in irregular readings from the pins. Reragds, Predrag On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: Q: do you use local xtal attached to Si52111-B5 to generate local PCIe 25MHz clock? Zheng: yes Q: If you dothis, my next question is how you synchronize these two clocks: Local PCIe 25 MHz and common reference clock from CPU? Zheng: We do NOT sync these two. Q: Since these two clocks, as I understand above scenario, are asynchronous to each other?! Zheng: yes. Asynchronous. The VPX connector does not have a PCIe ref clock signal, so we can not send CPU PCIe ref clock to device. The PCIe spec says if the separate refclk on devices should be 100MHz ± 300PPM, with SSC off. We believe our board meet this requirement. So we doubt the problem lies in PCI configration space. Zheng ________________________________ From: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com<mailto:zoran.stojsavljevic@gmail.com>> Sent: Thursday, January 12, 2017 9:22 AM To: Zheng Bao; Predrag Vidic Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Question about PCIe separate reference clock Hello Zheng, For decades, I've been FW/SW engineer, but I do understand a little bit of a HW. I have looked into the Si52111-B5 data sheet for clarification. My problem here is to understand, your use case: do you use local xtal attached to Si52111-B5 to generate local PCIe 25MHz clock? If you do this, my next question is how you synchronize these two clocks: Local PCIe 25 MHz and common reference clock from CPU? Since these two clocks, as I understand above scenario, are asynchronous to each other?! Please, clarify for us your use case. Thank you, Zoran _______ On 1/12/17, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: > Our VPX design uses separate reference clock source, which is Si52111-B5 (No > spread), instead of common ref clock from CPU. > Now The system is unstable. Reading PCIE configuration space is unstable > too. (If we add some fly wire to make it work with common ref clock, the > system becomes stable.) > > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit indicates > that the > component uses the same physical reference clock that the > platform provides on the connector. If the device uses an > independent clock irrespective of the presence of a reference > clock on the connector, this bit must be clear. > For a multi-Function device, each Function must report the > same value for this bit.) > > Based on my understanding, the BIOS need to read bit "Slot Clock > Configurationclear" to see if > separate ref clock is used. BIOS then write bit "Common Clock > Configuration". > > On our board, the bit "Slot Clock Configuration" is always 1, which I assume > should be 0. > > My question is, how the hardware affect the bit "Slot Clock Configuration"? > How do we need to design our board to make the bit "Slot Clock > Configuration" be 0? > > Thanks. > > Zheng > >

1 0

Using as default external monitor for booting in x230
by Car.cuevas 13 Jan '17

13 Jan '17

Hi all, First thanks to all for such an amazing job, I just realized that Coreboot is already working in the lenovo x230, and I am really thinking in flash it and give a try :) But since I have a mod in my x230 for having FHD (edp screen), somehow I will need to somehow setup on the bios that I need to use the external Digital output (the one used for the dock station) as default... Is it any way to configure that? thanks very much in advance :)

1 0

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

13 Jan '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 32 new defect(s) introduced to coreboot found with Coverity Scan. 12 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 32 defect(s) ** CID 1368413: Control flow issues (DEADCODE) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/dram/dfs.c: 1236 in gen_rk3399_ctl_params() ________________________________________________________________________________________________________ *** CID 1368413: Control flow issues (DEADCODE) /3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/dram/dfs.c: 1236 in gen_rk3399_ctl_params() 1230 tmp0 |= (1 << 24); 1231 #endif 1232 for (i = 0; i < timing_config->ch_cnt; i++) { 1233 if (tmp0 | tmp1) 1234 mmio_setbits_32(CTL_REG(i, 305), 1 << 16); 1235 if (tmp0) >>> CID 1368413: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "mmio_setbits_32(4289200128U...". 1236 mmio_setbits_32(CTL_REG(i, 70), tmp0); 1237 if (tmp1) 1238 mmio_setbits_32(CTL_REG(i, 71), tmp1); 1239 } 1240 #endif 1241 } ** 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 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 { ** CID 1302451: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 240 in fmap_print() ________________________________________________________________________________________________________ *** CID 1302451: Resource leaks (RESOURCE_LEAK) /util/cbfstool/flashmap/fmap.c: 240 in fmap_print() 234 kv_pair_fmt(pair, "area_flags_raw", "0x%02x", 235 fmap->areas[i].flags); 236 237 /* Print descriptive strings for flags rather than the field */ 238 flags = fmap->areas[i].flags; 239 if ((str = fmap_flags_to_string(flags)) == NULL) >>> CID 1302451: Resource leaks (RESOURCE_LEAK) >>> Variable "pair" going out of scope leaks the storage it points to. 240 return -1; 241 kv_pair_fmt(pair, "area_flags", "%s", str); 242 free(str); 243 244 kv_pair_print(pair); 245 kv_pair_free(pair); ** CID 1241790: Insecure data handling (TAINTED_SCALAR) /util/cbfstool/lzma/C/LzFind.c: 653 in Bt2_MatchFinder_Skip() ________________________________________________________________________________________________________ *** CID 1241790: Insecure data handling (TAINTED_SCALAR) /util/cbfstool/lzma/C/LzFind.c: 653 in Bt2_MatchFinder_Skip() 647 static void Bt2_MatchFinder_Skip(struct CMatchFinder *p, uint32_t num) 648 { 649 do 650 { 651 SKIP_HEADER(2) 652 HASH2_CALC; >>> CID 1241790: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "hashValue" as an index to pointer "p->hash". 653 curMatch = p->hash[hashValue]; 654 p->hash[hashValue] = p->pos; 655 SKIP_FOOTER 656 } 657 while (--num != 0); 658 } ________________________________________________________________________________________________________ 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] Question about PCIe separate reference clock
by Predrag Vidic 13 Jan '17

13 Jan '17

Hi Zheng, Schematic is simple and OK. I assume you are trying to run Wolf VPXxx-E8860-xxxx or similar GPU borad. You can't do much there if there is a hardware problem but it is most possibly a software setup problem. VPX does not have incomming clock so it is by default in async_clock mode. The question is did you allowed that mode on the main board side? Asynchronous clock mode is not default mode for a motherboard. Check if the mode is allowed. Second, check if the other PCIe device can work on the motherboard PCIe slot. Regards, Predrag On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > Here is the ref clk part. Please review. > > No refclk routes to VPX connector. > > > Thanks. > > > Zheng > ------------------------------ > *From:* Predrag Vidic <pvidic(a)gmail.com> > *Sent:* Thursday, January 12, 2017 6:53 PM > *To:* Zheng Bao > *Cc:* Zoran Stojsavljevic; coreboot(a)coreboot.org > > *Subject:* Re: [coreboot] Question about PCIe separate reference clock > > Hi Zheng, > > Without knowing the particular solution for the PCIe transmitter you have > on your board, I'd check refclk pins on your design for the proper > termination. The problem can be in irregular readings from the pins. > > Reragds, > Predrag > > On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > >> Q: do you use local xtal attached to Si52111-B5 to generate local PCIe >> 25MHz clock? >> >> Zheng: yes >> >> >> Q: If you dothis, my next question is how you synchronize these two >> clocks: Local >> PCIe 25 MHz and common reference clock from CPU? >> >> Zheng: We do NOT sync these two. >> >> >> Q: Since these two clocks, as I understand above scenario, are >> asynchronous to each other?! >> >> Zheng: yes. Asynchronous. >> >> >> The VPX connector does not have a PCIe ref clock signal, so we can not >> send CPU PCIe ref clock to >> >> device. The PCIe spec says if the separate refclk on devices should be >> 100MHz ± 300PPM, with SSC >> >> off. We believe our board meet this requirement. So we doubt the problem >> lies in PCI configration space. >> >> >> Zheng >> >> >> >> ------------------------------ >> *From:* Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> >> *Sent:* Thursday, January 12, 2017 9:22 AM >> *To:* Zheng Bao; Predrag Vidic >> *Cc:* coreboot(a)coreboot.org >> *Subject:* Re: [coreboot] Question about PCIe separate reference clock >> >> Hello Zheng, >> >> For decades, I've been FW/SW engineer, but I do understand a little >> bit of a HW. I have looked into the Si52111-B5 data sheet for >> clarification. >> >> My problem here is to understand, your use case: do you use local xtal >> attached to Si52111-B5 to generate local PCIe 25MHz clock? If you do >> this, my next question is how you synchronize these two clocks: Local >> PCIe 25 MHz and common reference clock from CPU? >> >> Since these two clocks, as I understand above scenario, are >> asynchronous to each other?! >> >> Please, clarify for us your use case. >> >> Thank you, >> Zoran >> _______ >> >> On 1/12/17, Zheng Bao <fishbaoz(a)hotmail.com> wrote: >> > Our VPX design uses separate reference clock source, which is >> Si52111-B5 (No >> > spread), instead of common ref clock from CPU. >> > Now The system is unstable. Reading PCIE configuration space is unstable >> > too. (If we add some fly wire to make it work with common ref clock, the >> > system becomes stable.) >> > >> > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit >> indicates >> > that the >> > component uses the same physical reference clock that the >> > platform provides on the connector. If the device uses an >> > independent clock irrespective of the presence of a reference >> > clock on the connector, this bit must be clear. >> > For a multi-Function device, each Function must report the >> > same value for this bit.) >> > >> > Based on my understanding, the BIOS need to read bit "Slot Clock >> > Configurationclear" to see if >> > separate ref clock is used. BIOS then write bit "Common Clock >> > Configuration". >> > >> > On our board, the bit "Slot Clock Configuration" is always 1, which I >> assume >> > should be 0. >> > >> > My question is, how the hardware affect the bit "Slot Clock >> Configuration"? >> > How do we need to design our board to make the bit "Slot Clock >> > Configuration" be 0? >> > >> > Thanks. >> > >> > Zheng >> > >> > >> > >

1 0

SMBIOS table enablement in coreboot
by Mayuri Tendulkar 13 Jan '17

13 Jan '17

Hi We are using coreboot for our board based on Intel Baytrail 3845. When we use dmidecode -t to get DDR details, we get empty. It means data is missing in SMBIOS. Are there any settings in coreboot to enable this? 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."

1 0

Re: [coreboot] chat.coreboot.org is on
by Carl-Daniel Hailfinger 13 Jan '17

13 Jan '17

Hello Zoran, I think a forum is too time-consuming to be useful. A forum makes sense if you have volunteers with too much spare time like the various Linux distributions. A forum also means you need moderators to handle takedown requests, complaints from users and other stuff. If you take a look at most forums, you will notice that people add their signature (with lots of smileys and useless info) to each post and the signal/noise ratio gets really bad after some time. There is also the danger that all forum contents will be lost if we ever migrate from one forum software to another or if the server with the forum crashes/dies. With distributed mailing list archives, that is really unlikely. Regards, Carl-Daniel On 07.01.2017 10:45, Zoran Stojsavljevic wrote: > If you allow me, the (much) better decision will be to organize web > forum/web domain http://www.coreboot.forum.com. Something lookalike: > http://www.forums.fedoraforum.org/ > > There are many advantages why to do this. I'll spell out few. Much > higher visibility. Much more professional approach. > > On Sat, Jan 7, 2017 at 8:42 AM, Patrick Georgi <patrick(a)georgi-clan.de > <mailto:patrick@georgi-clan.de>> wrote: > > we've set up a mattermost instance on https://chat.coreboot.org/ > in the hope to lower the barriers to entry into our community. > > It comes with a bridge to IRC, history (but not web-indexable, > which was a major concern with IRC logs so far) and the ability to > start topic channels that are discoverable yet separate from the > main discussion. >

2 1

How to understand register address on x86?
by 김유석 13 Jan '17

13 Jan '17

Dear Sir. This time, I try to read the "V2_Avoton_BWG_Rev1_6_review.pdf" Page 169. Is see below. But I don't understand the SLOTCAP address (*B0:D1**-**4:F0**:*Offset 0x54[31:19]). Could you explain this mean to me? Thank you.

1 0

Re: [coreboot] Question about PCIe separate reference clock
by Zheng Bao 13 Jan '17

13 Jan '17

Here is the ref clk part. Please review. No refclk routes to VPX connector. Thanks. Zheng ________________________________ From: Predrag Vidic <pvidic(a)gmail.com> Sent: Thursday, January 12, 2017 6:53 PM To: Zheng Bao Cc: Zoran Stojsavljevic; coreboot(a)coreboot.org Subject: Re: [coreboot] Question about PCIe separate reference clock Hi Zheng, Without knowing the particular solution for the PCIe transmitter you have on your board, I'd check refclk pins on your design for the proper termination. The problem can be in irregular readings from the pins. Reragds, Predrag On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: Q: do you use local xtal attached to Si52111-B5 to generate local PCIe 25MHz clock? Zheng: yes Q: If you dothis, my next question is how you synchronize these two clocks: Local PCIe 25 MHz and common reference clock from CPU? Zheng: We do NOT sync these two. Q: Since these two clocks, as I understand above scenario, are asynchronous to each other?! Zheng: yes. Asynchronous. The VPX connector does not have a PCIe ref clock signal, so we can not send CPU PCIe ref clock to device. The PCIe spec says if the separate refclk on devices should be 100MHz ± 300PPM, with SSC off. We believe our board meet this requirement. So we doubt the problem lies in PCI configration space. Zheng ________________________________ From: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com<mailto:zoran.stojsavljevic@gmail.com>> Sent: Thursday, January 12, 2017 9:22 AM To: Zheng Bao; Predrag Vidic Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Question about PCIe separate reference clock Hello Zheng, For decades, I've been FW/SW engineer, but I do understand a little bit of a HW. I have looked into the Si52111-B5 data sheet for clarification. My problem here is to understand, your use case: do you use local xtal attached to Si52111-B5 to generate local PCIe 25MHz clock? If you do this, my next question is how you synchronize these two clocks: Local PCIe 25 MHz and common reference clock from CPU? Since these two clocks, as I understand above scenario, are asynchronous to each other?! Please, clarify for us your use case. Thank you, Zoran _______ On 1/12/17, Zheng Bao <fishbaoz(a)hotmail.com<mailto:fishbaoz@hotmail.com>> wrote: > Our VPX design uses separate reference clock source, which is Si52111-B5 (No > spread), instead of common ref clock from CPU. > Now The system is unstable. Reading PCIE configuration space is unstable > too. (If we add some fly wire to make it work with common ref clock, the > system becomes stable.) > > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit indicates > that the > component uses the same physical reference clock that the > platform provides on the connector. If the device uses an > independent clock irrespective of the presence of a reference > clock on the connector, this bit must be clear. > For a multi-Function device, each Function must report the > same value for this bit.) > > Based on my understanding, the BIOS need to read bit "Slot Clock > Configurationclear" to see if > separate ref clock is used. BIOS then write bit "Common Clock > Configuration". > > On our board, the bit "Slot Clock Configuration" is always 1, which I assume > should be 0. > > My question is, how the hardware affect the bit "Slot Clock Configuration"? > How do we need to design our board to make the bit "Slot Clock > Configuration" be 0? > > Thanks. > > Zheng > >

1 0

How to en/disable PCIe root port?
by 김유석 13 Jan '17

13 Jan '17

Dear Sir. Happy new year. My board is use the rangeley C2358 SoC. C2358 have a 4 PCIe root port. After kernel boot, i try to check the number of PCIe port that use the "lspci" command. but i can see just 2 port on my board. Result is see below. $ > lspci 00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC Transaction Router (rev 02) * 00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 1 (rev 02)** ** 00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 3 (rev 02)* 00:0b.0 Co-processor: Intel Corporation Atom processor C2000 QAT (rev 02) 00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02) Intel FAE is said to me that Modify the "descriptor.bin" use by FICT(supported by intel) binary or Modify the Coreboot source code. So I'm try to modify the descriptor.bin, but Not enabled the all PCIe ports. So, i'll Modify the coreboot source code, But I don't have a idea to enable all PCIe port. Please advise or show-up modify point of Coreboot. Thank you.

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
19
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 January 2017