coreboot July 2016

coreboot@coreboot.org

47 participants
135 discussions

Re: [coreboot] kgpe-d16
by Stefan Reinauer 12 Jul '16

12 Jul '16

* ron minnich <rminnich(a)gmail.com> [160620 20:19]: > I have a kgpe-d16 with coreboot and it *was* working with linux. I now have a > linux kernel that won't boot on fuctory bios or coreboot. I can't recall > changing anything ... > > If somebody's got a known good .config for linux I could sure use it. I'm > booting stock tinycore and it seems to hang a lot. The Ubuntu 16.04 default config worked fine on the system. Stefan

1 0

Re: [coreboot] Help on setting clock speed in coreboot
by Naveed Ghori 12 Jul '16

12 Jul '16

We take the pins direct off the E3845 (only really need the tx (pin BD14 (GPIO_S0_SC[57]))). The pins direct are TTL so we had to use a TTL-USB serial port converter. From: Mayuri Tendulkar [mailto:mayuri.tendulkar@aricent.com] Sent: Tuesday, 12 July 2016 9:37 AM To: Naveed Ghori; coreboot Subject: Re: Help on setting clock speed in coreboot Thanks. We tried 115200, but it didn't work. We checked TTL levels and tried to match, but no luck. Are you using PCU UART (same as minnowboard) or anything different? From: Naveed Ghori [mailto:naveed.ghori@dti.com.au] Sent: 11 July 2016 18:17 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>>; coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>> Subject: Re: Help on setting clock speed in coreboot Hi, Garbage usually means baud rate. Did you try 115200baud? If you are still getting garbage I would recommend seeing it on the scope and making sure voltage levels are fine. The output by default would be TTL level and may need to be converted. I have used some TTL (1.8V if I remember correctly (TTL-232RG) to convert the signal so I could read the output. Cheers, Naveed From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Mayuri Tendulkar Sent: Tuesday, 12 July 2016 8:27 AM To: coreboot Subject: [coreboot] Help on setting clock speed in coreboot Hi Team I have a customized board based on Intel valley island design. Reference design uses Intel Baytrail processor E3825, while my design is using E3845. I am customizing coreboot for this E3845, but getting just garbage on coreboot, so not able to debug where it is stuck. When I add memory test as secondary payload, I cd see some operations happening on console but not able to decode it. Tried with all possible baud rates, but no success. USB and display also not enumerating. Can you please give some clue? Is it due to different core speed for E3835(1.33GHZ) vs E3845(1.91GHz). Where is the option to change this in coreboot? Appreciate your support. 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." "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] Help on setting clock speed in coreboot
by Naveed Ghori 12 Jul '16

12 Jul '16

Hi, Garbage usually means baud rate. Did you try 115200baud? If you are still getting garbage I would recommend seeing it on the scope and making sure voltage levels are fine. The output by default would be TTL level and may need to be converted. I have used some TTL (1.8V if I remember correctly (TTL-232RG) to convert the signal so I could read the output. Cheers, Naveed From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Mayuri Tendulkar Sent: Tuesday, 12 July 2016 8:27 AM To: coreboot Subject: [coreboot] Help on setting clock speed in coreboot Hi Team I have a customized board based on Intel valley island design. Reference design uses Intel Baytrail processor E3825, while my design is using E3845. I am customizing coreboot for this E3845, but getting just garbage on coreboot, so not able to debug where it is stuck. When I add memory test as secondary payload, I cd see some operations happening on console but not able to decode it. Tried with all possible baud rates, but no success. USB and display also not enumerating. Can you please give some clue? Is it due to different core speed for E3835(1.33GHZ) vs E3845(1.91GHz). Where is the option to change this in coreboot? Appreciate your support. 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."

2 1

Help on setting clock speed in coreboot
by Mayuri Tendulkar 12 Jul '16

12 Jul '16

Hi Team I have a customized board based on Intel valley island design. Reference design uses Intel Baytrail processor E3825, while my design is using E3845. I am customizing coreboot for this E3845, but getting just garbage on coreboot, so not able to debug where it is stuck. When I add memory test as secondary payload, I cd see some operations happening on console but not able to decode it. Tried with all possible baud rates, but no success. USB and display also not enumerating. Can you please give some clue? Is it due to different core speed for E3835(1.33GHZ) vs E3845(1.91GHz). Where is the option to change this in coreboot? Appreciate your support. 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] PAYLOAD_SEGMENT_BSS not getting cleared in selfboot.c
by Aaron Durbin 11 Jul '16

11 Jul '16

On Mon, Jul 11, 2016 at 3:19 PM, Aaron Durbin <adurbin(a)google.com> wrote: > Hello, > > I have a historical question regarding the current selfboot.c > implementation surrounding PAYLOAD_SEGMENT_BSS. > > Documentation/cbfs.txt indicates that PAYLOAD_SEGMENT_BSS should be cleared: > > "PAYLOAD_SEGMENT_BSS 0x20535342 The memory speicfied by the > segment should be zeroed" > > And we have code which looks for partial segments backed by file > contents that zeros the memory that the file contents don't cover. > > But I don't see anywhere where we actually honor PAYLOAD_SEGMENT_BSS > by zero'ing the memory covered by it. > > Is this an oversight or is it explicitly not done, but no reasoning is > documented? > > Given the current semantics I think this memory region should be cleared. > Patch pushed: https://review.coreboot.org/15603 > -Aaron

1 0

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

11 Jul '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 55 new defect(s) introduced to coreboot found with Coverity Scan. 94 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 55 defect(s) ** CID 1357464: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 71 in platform_i2c_transfer() ________________________________________________________________________________________________________ *** CID 1357464: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 71 in platform_i2c_transfer() 65 /* Set the slave address */ 66 ASSERT (count > 0); 67 ASSERT (segments != NULL); 68 ASSERT (segments->read == 0); 69 70 /* Clear the start and stop detection */ >>> CID 1357464: Incorrect expression (UNUSED_VALUE) >>> Assigning value from "regs->ic_clr_start_det" to "status" here, but that stored value is overwritten before it can be used. 71 status = regs->ic_clr_start_det; 72 status = regs->ic_clr_stop_det; 73 74 /* Set addressing mode to 7-bit and fast mode */ 75 cmd = regs->ic_con; 76 cmd &= ~(IC_CON_10B | IC_CON_SPEED); ** CID 1357463: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 91 in platform_i2c_transfer() ________________________________________________________________________________________________________ *** CID 1357463: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 91 in platform_i2c_transfer() 85 /* Enable the I2C controller */ 86 regs->ic_enable = IC_ENABLE_CONTROLLER; 87 88 /* Clear the interrupts */ 89 status = regs->ic_clr_rx_under; 90 status = regs->ic_clr_rx_over; >>> CID 1357463: Incorrect expression (UNUSED_VALUE) >>> Assigning value from "regs->ic_clr_tx_over" to "status" here, but that stored value is overwritten before it can be used. 91 status = regs->ic_clr_tx_over; 92 status = regs->ic_clr_tx_abrt; 93 94 /* Process each of the segments */ 95 bytes_transferred = 0; 96 read_length = 0; ** CID 1357462: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 90 in platform_i2c_transfer() ________________________________________________________________________________________________________ *** CID 1357462: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 90 in platform_i2c_transfer() 84 85 /* Enable the I2C controller */ 86 regs->ic_enable = IC_ENABLE_CONTROLLER; 87 88 /* Clear the interrupts */ 89 status = regs->ic_clr_rx_under; >>> CID 1357462: Incorrect expression (UNUSED_VALUE) >>> Assigning value from "regs->ic_clr_rx_over" to "status" here, but that stored value is overwritten before it can be used. 90 status = regs->ic_clr_rx_over; 91 status = regs->ic_clr_tx_over; 92 status = regs->ic_clr_tx_abrt; 93 94 /* Process each of the segments */ 95 bytes_transferred = 0; ** CID 1357461: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 89 in platform_i2c_transfer() ________________________________________________________________________________________________________ *** CID 1357461: Incorrect expression (UNUSED_VALUE) /src/soc/intel/quark/i2c.c: 89 in platform_i2c_transfer() 83 regs->ic_tar = chip; 84 85 /* Enable the I2C controller */ 86 regs->ic_enable = IC_ENABLE_CONTROLLER; 87 88 /* Clear the interrupts */ >>> CID 1357461: Incorrect expression (UNUSED_VALUE) >>> Assigning value from "regs->ic_clr_rx_under" to "status" here, but that stored value is overwritten before it can be used. 89 status = regs->ic_clr_rx_under; 90 status = regs->ic_clr_rx_over; 91 status = regs->ic_clr_tx_over; 92 status = regs->ic_clr_tx_abrt; 93 94 /* Process each of the segments */ ** CID 1357460: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/quark/reg_access.c: 230 in reg_read() ________________________________________________________________________________________________________ *** CID 1357460: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/quark/reg_access.c: 230 in reg_read() 224 ctx->display_prefix = "GPIO"; 225 value = reg_gpio_read(step->reg); 226 break; 227 228 case LEG_GPIO_REGS: 229 ctx->display_prefix = "Legacy GPIO"; >>> CID 1357460: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "reg_legacy_gpio_read(step->reg)" to "value" here, but that stored value is overwritten before it can be used. 230 value = reg_legacy_gpio_read(step->reg); 231 232 case PCIE_AFE_REGS: 233 ctx->display_prefix = "PCIe AFE"; 234 value = reg_pcie_afe_read(step->reg); 235 break; ** CID 1357459: Uninitialized variables (UNINIT) /src/mainboard/google/gru/mainboard.c: 173 in setup_rtc() ________________________________________________________________________________________________________ *** CID 1357459: Uninitialized variables (UNINIT) /src/mainboard/google/gru/mainboard.c: 173 in setup_rtc() 167 setup_usb_drd0_dwc3(); 168 setup_usb_drd1_dwc3(); 169 } 170 171 static void setup_rtc(void) 172 { >>> CID 1357459: Uninitialized variables (UNINIT) >>> Declaring variable "time" without initializer. 173 struct rtc_time time; 174 int ret; 175 176 /* Show the current time to see that the EC RTC is working */ 177 google_chromeec_init(); 178 ret = rtc_get(&time); ** CID 1357458: Insecure data handling (TAINTED_SCALAR) /payloads/libpayload/libcbfs/cbfs_core.c: 255 in cbfs_get_contents() ________________________________________________________________________________________________________ *** CID 1357458: Insecure data handling (TAINTED_SCALAR) /payloads/libpayload/libcbfs/cbfs_core.c: 255 in cbfs_get_contents() 249 250 void *data = m->map(m, handle->media_offset + handle->content_offset, 251 on_media_size); 252 if (data == CBFS_MEDIA_INVALID_MAP_ADDRESS) 253 return NULL; 254 >>> CID 1357458: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "*size" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 255 ret = malloc(*size); 256 if (ret != NULL && !cbfs_decompress(algo, data, ret, *size)) { 257 free(ret); 258 ret = NULL; 259 } 260 ** CID 1357457: Resource leaks (RESOURCE_LEAK) /src/arch/x86/acpi_device.c: 737 in acpi_dp_add_integer_array() ________________________________________________________________________________________________________ *** CID 1357457: Resource leaks (RESOURCE_LEAK) /src/arch/x86/acpi_device.c: 737 in acpi_dp_add_integer_array() 731 return NULL; 732 733 for (i = 0; i < len; i++) 734 if (!acpi_dp_add_integer(dp_array, NULL, array[i])) 735 break; 736 >>> CID 1357457: Resource leaks (RESOURCE_LEAK) >>> Ignoring storage allocated by "acpi_dp_add_array(dp, dp_array)" leaks it. 737 acpi_dp_add_array(dp, dp_array); 738 739 return dp_array; 740 } 741 742 struct acpi_dp *acpi_dp_add_gpio(struct acpi_dp *dp, const char *name, ** CID 1357456: Resource leaks (RESOURCE_LEAK) /src/arch/x86/acpi_device.c: 763 in acpi_dp_add_gpio() ________________________________________________________________________________________________________ *** CID 1357456: Resource leaks (RESOURCE_LEAK) /src/arch/x86/acpi_device.c: 763 in acpi_dp_add_gpio() 757 /* Pin in the GPIO resource, typically zero */ 758 acpi_dp_add_integer(gpio, NULL, pin); 759 760 /* Set if pin is active low */ 761 acpi_dp_add_integer(gpio, NULL, active_low); 762 >>> CID 1357456: Resource leaks (RESOURCE_LEAK) >>> Ignoring storage allocated by "acpi_dp_add_array(dp, gpio)" leaks it. 763 acpi_dp_add_array(dp, gpio); 764 765 return gpio; ** CID 1357455: (RESOURCE_LEAK) /payloads/libpayload/libcbfs/cbfs_core.c: 218 in cbfs_get_handle() /payloads/libpayload/libcbfs/cbfs_core.c: 151 in cbfs_get_handle() /payloads/libpayload/libcbfs/cbfs_core.c: 158 in cbfs_get_handle() ________________________________________________________________________________________________________ *** CID 1357455: (RESOURCE_LEAK) /payloads/libpayload/libcbfs/cbfs_core.c: 218 in cbfs_get_handle() 212 offset += ntohl(file.len) + ntohl(file.offset); 213 if (offset % CBFS_ALIGNMENT) 214 offset += CBFS_ALIGNMENT - (offset % CBFS_ALIGNMENT); 215 } 216 media->close(media); 217 LOG("WARNING: '%s' not found.\n", name); >>> CID 1357455: (RESOURCE_LEAK) >>> Variable "handle" going out of scope leaks the storage it points to. 218 return NULL; 219 } 220 221 void *cbfs_get_contents(struct cbfs_handle *handle, size_t *size, size_t limit) 222 { 223 struct cbfs_media *m = &handle->media; /payloads/libpayload/libcbfs/cbfs_core.c: 151 in cbfs_get_handle() 145 146 if (!handle) 147 return NULL; 148 149 if (get_cbfs_range(&offset, &cbfs_end, media)) { 150 ERROR("Failed to find cbfs range\n"); >>> CID 1357455: (RESOURCE_LEAK) >>> Variable "handle" going out of scope leaks the storage it points to. 151 return NULL; 152 } 153 154 if (media == CBFS_DEFAULT_MEDIA) { 155 media = &handle->media; 156 if (init_default_cbfs_media(media) != 0) { /payloads/libpayload/libcbfs/cbfs_core.c: 158 in cbfs_get_handle() 152 } 153 154 if (media == CBFS_DEFAULT_MEDIA) { 155 media = &handle->media; 156 if (init_default_cbfs_media(media) != 0) { 157 ERROR("Failed to initialize default media.\n"); >>> CID 1357455: (RESOURCE_LEAK) >>> Returning without freeing "media" leaks the storage that it points to. 158 return NULL; 159 } 160 } else { 161 memcpy(&handle->media, media, sizeof(*media)); 162 } 163 ** CID 1357454: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f12/Proc/Mem/NB/LN/mnln.c: 255 in MemConstructNBBlockLN() ________________________________________________________________________________________________________ *** CID 1357454: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f12/Proc/Mem/NB/LN/mnln.c: 255 in MemConstructNBBlockLN() 249 NBPtr->BeforeDqsTraining = MemNBeforeDQSTrainingLN; 250 NBPtr->AfterDqsTraining = MemNAfterDQSTrainingLN; 251 NBPtr->OtherTiming = MemNOtherTimingLN; 252 NBPtr->GetSocketRelativeChannel = MemNGetSocketRelativeChannelNb; 253 NBPtr->TechBlockSwitch = MemNTechBlockSwitchLN; 254 NBPtr->SetEccSymbolSize = (VOID (*) (MEM_NB_BLOCK *)) memDefRet; >>> CID 1357454: Memory - illegal accesses (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 255 NBPtr->TrainingFlow = (VOID (*) (MEM_NB_BLOCK *))(memNTrainFlowControl[DDR3_TRAIN_FLOW]); 256 NBPtr->MinDataEyeWidth = MemNMinDataEyeWidthNb; 257 NBPtr->ChangeNbFrequencyWrap = MemNChangeNbFrequencyWrapLN; 258 NBPtr->AllocateC6Storage = MemNAllocateC6StorageClientNb; 259 260 MemNInitNBDataNb (NBPtr); ** CID 1357453: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/ON/mnon.c: 254 in MemConstructNBBlockON() ________________________________________________________________________________________________________ *** CID 1357453: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/ON/mnon.c: 254 in MemConstructNBBlockON() 248 NBPtr->BeforeDqsTraining = MemNBeforeDQSTrainingON; 249 NBPtr->AfterDqsTraining = MemNAfterDQSTrainingON; 250 NBPtr->OtherTiming = MemNOtherTimingON; 251 NBPtr->GetSocketRelativeChannel = MemNGetSocketRelativeChannelNb; 252 NBPtr->TechBlockSwitch = MemNTechBlockSwitchON; 253 NBPtr->SetEccSymbolSize = (VOID (*) (MEM_NB_BLOCK *)) memDefRet; >>> CID 1357453: Memory - illegal accesses (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 254 NBPtr->TrainingFlow = (VOID (*) (MEM_NB_BLOCK *)) memNTrainFlowControl[DDR3_TRAIN_FLOW]; 255 NBPtr->MinDataEyeWidth = MemNMinDataEyeWidthNb; 256 NBPtr->PollBitField = MemNPollBitFieldNb; 257 NBPtr->BrdcstCheck = MemNBrdcstCheckON; 258 NBPtr->BrdcstSet = MemNSetBitFieldNb; 259 NBPtr->GetTrainDly = MemNGetTrainDlyNb; ** CID 1357452: (OVERRUN) /src/vendorcode/amd/agesa/f15/Proc/Mem/NB/mn.c: 502 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/mn.c: 499 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f16kb/Proc/Mem/NB/mn.c: 579 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f12/Proc/Mem/NB/mn.c: 497 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/mn.c: 495 in MemNTrainingFlowUnb() ________________________________________________________________________________________________________ *** CID 1357452: (OVERRUN) /src/vendorcode/amd/agesa/f15/Proc/Mem/NB/mn.c: 502 in MemNTrainingFlowUnb() 496 */ 497 BOOLEAN 498 MemNTrainingFlowUnb ( 499 IN OUT MEM_NB_BLOCK *NBPtr 500 ) 501 { >>> CID 1357452: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 502 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 503 return TRUE; 504 } 505 /*---------------------------------------------------------------------------- 506 * LOCAL FUNCTIONS 507 * /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/mn.c: 499 in MemNTrainingFlowUnb() 493 */ 494 BOOLEAN 495 MemNTrainingFlowUnb ( 496 IN OUT MEM_NB_BLOCK *NBPtr 497 ) 498 { >>> CID 1357452: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 499 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 500 return TRUE; 501 } 502 /*---------------------------------------------------------------------------- 503 * LOCAL FUNCTIONS 504 * /src/vendorcode/amd/agesa/f16kb/Proc/Mem/NB/mn.c: 579 in MemNTrainingFlowUnb() 573 */ 574 BOOLEAN 575 MemNTrainingFlowUnb ( 576 IN OUT MEM_NB_BLOCK *NBPtr 577 ) 578 { >>> CID 1357452: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 579 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 580 return TRUE; 581 } 582 583 /* -----------------------------------------------------------------------------*/ 584 /** /src/vendorcode/amd/agesa/f12/Proc/Mem/NB/mn.c: 497 in MemNTrainingFlowUnb() 491 */ 492 BOOLEAN 493 MemNTrainingFlowUnb ( 494 IN OUT MEM_NB_BLOCK *NBPtr 495 ) 496 { >>> CID 1357452: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 497 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 498 return TRUE; 499 } 500 /*---------------------------------------------------------------------------- 501 * LOCAL FUNCTIONS 502 * /src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/mn.c: 495 in MemNTrainingFlowUnb() 489 */ 490 VOID 491 MemNTrainingFlowUnb ( 492 IN OUT MEM_NB_BLOCK *NBPtr 493 ) 494 { >>> CID 1357452: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 495 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 496 return; 497 } 498 /*---------------------------------------------------------------------------- 499 * LOCAL FUNCTIONS 500 * 501 *---------------------------------------------------------------------------- ** CID 1357451: (OVERRUN) /src/vendorcode/amd/agesa/f15/Proc/Mem/NB/mn.c: 309 in MemNTrainingFlowNb() /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/mn.c: 306 in MemNTrainingFlowNb() /src/vendorcode/amd/agesa/f12/Proc/Mem/NB/mn.c: 304 in MemNTrainingFlowNb() /src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/mn.c: 302 in MemNTrainingFlowNb() ________________________________________________________________________________________________________ *** CID 1357451: (OVERRUN) /src/vendorcode/amd/agesa/f15/Proc/Mem/NB/mn.c: 309 in MemNTrainingFlowNb() 303 BOOLEAN 304 MemNTrainingFlowNb ( 305 IN OUT MEM_NB_BLOCK *NBPtr 306 ) 307 { 308 if (MemNGetBitFieldNb (NBPtr, BFDdr3Mode)!= 0) { >>> CID 1357451: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 309 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 310 } else { 311 memNTrainFlowControl[DDR2_TRAIN_FLOW] (NBPtr); 312 } 313 return TRUE; 314 } /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/mn.c: 306 in MemNTrainingFlowNb() 300 BOOLEAN 301 MemNTrainingFlowNb ( 302 IN OUT MEM_NB_BLOCK *NBPtr 303 ) 304 { 305 if (MemNGetBitFieldNb (NBPtr, BFDdr3Mode)!= 0) { >>> CID 1357451: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 306 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 307 } else { 308 memNTrainFlowControl[DDR2_TRAIN_FLOW] (NBPtr); 309 } 310 return TRUE; 311 } /src/vendorcode/amd/agesa/f12/Proc/Mem/NB/mn.c: 304 in MemNTrainingFlowNb() 298 BOOLEAN 299 MemNTrainingFlowNb ( 300 IN OUT MEM_NB_BLOCK *NBPtr 301 ) 302 { 303 if (MemNGetBitFieldNb (NBPtr, BFDdr3Mode)!= 0) { >>> CID 1357451: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 304 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 305 } else { 306 memNTrainFlowControl[DDR2_TRAIN_FLOW] (NBPtr); 307 } 308 return TRUE; 309 } /src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/mn.c: 302 in MemNTrainingFlowNb() 296 BOOLEAN 297 MemNTrainingFlowNb ( 298 IN OUT MEM_NB_BLOCK *NBPtr 299 ) 300 { 301 if (MemNGetBitFieldNb (NBPtr, BFDdr3Mode)!= 0) { >>> CID 1357451: (OVERRUN) >>> Overrunning array "memNTrainFlowControl" of 1 4-byte elements at element index 1 (byte offset 4) using index "1". 302 memNTrainFlowControl[DDR3_TRAIN_FLOW] (NBPtr); 303 } else { 304 memNTrainFlowControl[DDR2_TRAIN_FLOW] (NBPtr); 305 } 306 return TRUE; 307 } ** CID 1357450: (NO_EFFECT) /src/soc/intel/skylake/romstage/i2c.c: 59 in i2c_early_init_bus() /src/soc/intel/apollolake/i2c_early.c: 42 in i2c_early_init_bus() ________________________________________________________________________________________________________ *** CID 1357450: (NO_EFFECT) /src/soc/intel/skylake/romstage/i2c.c: 59 in i2c_early_init_bus() 53 uintptr_t base; 54 uint32_t value; 55 void *reg; 56 57 /* Find the PCI device for this bus controller */ 58 devfn = i2c_bus_to_devfn(bus); >>> CID 1357450: (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "devfn < 0U". 59 if (devfn < 0) 60 return; 61 62 /* Look up the controller device in the devicetree */ 63 dev = PCI_DEV(0, PCI_SLOT(devfn), PCI_FUNC(devfn)); 64 tree_dev = dev_find_slot(0, devfn); /src/soc/intel/apollolake/i2c_early.c: 42 in i2c_early_init_bus() 36 uintptr_t base; 37 uint32_t value; 38 void *reg; 39 40 /* Find the PCI device for this bus controller */ 41 devfn = i2c_bus_to_devfn(bus); >>> CID 1357450: (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "devfn < 0U". 42 if (devfn < 0) { 43 printk(BIOS_ERR, "I2C%u device not found\n", bus); 44 return -1; 45 } 46 47 /* Look up the controller device in the devicetree */ ** CID 1357449: (NO_EFFECT) /src/soc/intel/apollolake/i2c.c: 37 in lpss_i2c_base_address() /src/soc/intel/skylake/i2c.c: 33 in lpss_i2c_base_address() /src/soc/intel/skylake/romstage/i2c.c: 35 in lpss_i2c_base_address() /src/soc/intel/apollolake/i2c_early.c: 101 in lpss_i2c_base_address() ________________________________________________________________________________________________________ *** CID 1357449: (NO_EFFECT) /src/soc/intel/apollolake/i2c.c: 37 in lpss_i2c_base_address() 31 unsigned devfn; 32 struct device *dev; 33 struct resource *res; 34 35 /* bus -> devfn */ 36 devfn = i2c_bus_to_devfn(bus); >>> CID 1357449: (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "devfn >= 0U". 37 if (devfn >= 0) { 38 /* devfn -> dev */ 39 dev = dev_find_slot(0, devfn); 40 if (dev) { 41 /* dev -> bar0 */ 42 res = find_resource(dev, PCI_BASE_ADDRESS_0); /src/soc/intel/skylake/i2c.c: 33 in lpss_i2c_base_address() 27 unsigned devfn; 28 struct device *dev; 29 struct resource *res; 30 31 /* bus -> devfn */ 32 devfn = i2c_bus_to_devfn(bus); >>> CID 1357449: (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "devfn >= 0U". 33 if (devfn >= 0) { 34 /* devfn -> dev */ 35 dev = dev_find_slot(0, devfn); 36 if (dev) { 37 /* dev -> bar0 */ 38 res = find_resource(dev, PCI_BASE_ADDRESS_0); /src/soc/intel/skylake/romstage/i2c.c: 35 in lpss_i2c_base_address() 29 { 30 unsigned devfn; 31 pci_devfn_t dev; 32 33 /* Find device+function for this controller */ 34 devfn = i2c_bus_to_devfn(bus); >>> CID 1357449: (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "devfn < 0U". 35 if (devfn < 0) 36 return 0; 37 38 /* Form a PCI address for this device */ 39 dev = PCI_DEV(0, PCI_SLOT(devfn), PCI_FUNC(devfn)); 40 /src/soc/intel/apollolake/i2c_early.c: 101 in lpss_i2c_base_address() 95 unsigned devfn; 96 pci_devfn_t dev; 97 uintptr_t base; 98 99 /* Find device+function for this controller */ 100 devfn = i2c_bus_to_devfn(bus); >>> CID 1357449: (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "devfn < 0U". 101 if (devfn < 0) 102 return (uintptr_t)NULL; 103 104 /* Form a PCI address for this device */ 105 dev = PCI_DEV(0, PCI_SLOT(devfn), PCI_FUNC(devfn)); 106 ** CID 1357448: Control flow issues (NO_EFFECT) /src/soc/intel/apollolake/include/soc/i2c.h: 31 in i2c_bus_to_devfn() ________________________________________________________________________________________________________ *** CID 1357448: Control flow issues (NO_EFFECT) /src/soc/intel/apollolake/include/soc/i2c.h: 31 in i2c_bus_to_devfn() 25 #define I2C_LPSS_RESET_RELEASE_HC ((1 << 1) | (1 << 0)) 26 #define I2C_LPSS_RESET_RELEASE_IDMA (1 << 2) 27 28 /* Convert I2C bus number to PCI device and function */ 29 static inline int i2c_bus_to_devfn(unsigned bus) 30 { >>> CID 1357448: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "bus >= 0U". 31 if (bus >= 0 && bus <= 3) 32 return PCI_DEVFN(LPSS_DEV_SLOT_I2C_D0, bus); 33 else if (bus >= 4 && bus <= 7) 34 return PCI_DEVFN(LPSS_DEV_SLOT_I2C_D1, (bus - 4)); 35 else 36 return -1; ** CID 1357447: Control flow issues (MISSING_BREAK) /src/soc/intel/quark/reg_access.c: 232 in reg_read() ________________________________________________________________________________________________________ *** CID 1357447: Control flow issues (MISSING_BREAK) /src/soc/intel/quark/reg_access.c: 232 in reg_read() 226 break; 227 228 case LEG_GPIO_REGS: 229 ctx->display_prefix = "Legacy GPIO"; 230 value = reg_legacy_gpio_read(step->reg); 231 >>> CID 1357447: Control flow issues (MISSING_BREAK) >>> The above case falls through to this one. 232 case PCIE_AFE_REGS: 233 ctx->display_prefix = "PCIe AFE"; 234 value = reg_pcie_afe_read(step->reg); 235 break; 236 237 case RMU_TEMP_REGS: ** CID 1357446: Control flow issues (DEADCODE) /src/northbridge/intel/x4x/raminit.c: 424 in sdram_detect_ram_speed() ________________________________________________________________________________________________________ *** CID 1357446: Control flow issues (DEADCODE) /src/northbridge/intel/x4x/raminit.c: 424 in sdram_detect_ram_speed() 418 } else { // DDR3 419 // Limit frequency for MCH 420 maxfreq = (s->max_ddr2_mhz == 800) ? MEM_CLOCK_800MHz : MEM_CLOCK_667MHz; 421 maxfreq >>= 3; 422 freq = MEM_CLOCK_1333MHz; 423 if (maxfreq) { >>> CID 1357446: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "freq = maxfreq + 2;". 424 freq = maxfreq + 2; 425 } 426 if (freq > MEM_CLOCK_1333MHz) { 427 freq = MEM_CLOCK_1333MHz; 428 } 429 ** CID 1357445: Control flow issues (DEADCODE) /src/soc/rockchip/rk3399/display.c: 108 in rk_display_init() ________________________________________________________________________________________________________ *** CID 1357445: Control flow issues (DEADCODE) /src/soc/rockchip/rk3399/display.c: 108 in rk_display_init() 102 edid.y_resolution = edid.mode.va; 103 rkvop_mode_set(conf->vop_id, &edid, detected_mode); 104 105 rkvop_enable(conf->vop_id, lcdbase, &edid); 106 107 switch (detected_mode) { >>> CID 1357445: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "case VOP_MODE_HDMI:". 108 case VOP_MODE_HDMI: 109 /* should not be here before HDMI supported */ 110 return; 111 case VOP_MODE_EDP: 112 default: 113 if (rk_edp_enable()) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/coreboot?tab=overview To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&…

1 0

PAYLOAD_SEGMENT_BSS not getting cleared in selfboot.c
by Aaron Durbin 11 Jul '16

11 Jul '16

Hello, I have a historical question regarding the current selfboot.c implementation surrounding PAYLOAD_SEGMENT_BSS. Documentation/cbfs.txt indicates that PAYLOAD_SEGMENT_BSS should be cleared: "PAYLOAD_SEGMENT_BSS 0x20535342 The memory speicfied by the segment should be zeroed" And we have code which looks for partial segments backed by file contents that zeros the memory that the file contents don't cover. But I don't see anywhere where we actually honor PAYLOAD_SEGMENT_BSS by zero'ing the memory covered by it. Is this an oversight or is it explicitly not done, but no reasoning is documented? Given the current semantics I think this memory region should be cleared. -Aaron

1 0

Re: [coreboot] Bring up Intel Camelback Mountain Board with coreboot+FSP failed
by Yang, York 06 Jul '16

06 Jul '16

The CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER need to be set in order to find the microcode from cbfs. Thanks, York From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Zoran Stojsavljevic Sent: Monday, July 04, 2016 2:33 PM To: Zeh, Werner <werner.zeh(a)siemens.com> Cc: 詹皓鈞 <ddtsssssss(a)gmail.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Bring up Intel Camelback Mountain Board with coreboot+FSP failed Hello Werner, Could be that you are correct. I know that INTEL PED team themselves up-streamed the whole BDW-DE Coreboot code into Coreboot. Here is the pointer proving that: https://www.coreboot.org/pipermail/coreboot-gerrit/2016-April/042490.html +config CPU_MICROCODE_HEADER_FILES + string + default "../intel/cpu/broadwell_de/microcode/M1050663_07000001.h ../intel/cpu/broadwell_de/microcode/M1050662_0000000A.h ../intel/cpu/broadwell_de/microcode/MFF50661_F1000008.h" The same I found in Jim's Coreboot config files: # CONFIG_BUILD_WITH_FAKE_IFD is not set CONFIG_TTYS0_BASE=0x3f8 CONFIG_CPU_MICROCODE_HEADER_FILES="../intel/cpu/broadwell_de/microcode/M1050663_07000001.h ../intel/cpu/broadwell_de/microcode/M1050662_0000000A.h ../intel/cpu/broadwell_de/microcode/MFF50661_F1000008.h" CONFIG_FSP_LOC=0xffeb0000 CONFIG_SOC_INTEL_FSP_BROADWELL_DE=y York (Yang) is the one who can precisely answer on these questions. and maybe provide the latest MCUs, or at least these could be used for googlthe more recent BDX-DE MCUs. Also, BDX-DE CPUID is important (I think for CPUIDs 0x50661, 0x50662, 0x50663 and assuming also 0x50664), so for different CPUIDs different MCU updates should be used (not 100% sure, thought). Best Regards, Zoran On Mon, Jul 4, 2016 at 12:39 PM, Zeh, Werner <werner.zeh(a)siemens.com<mailto:werner.zeh@siemens.com>> wrote: Hi Jim. According to the Postcode it seems like you have no valid microcode for the used CPU. In src/drivers/intel/fsp1_0/cache_as_ram.inc is the code which ends up in the endless loop while this code is shown. Check which CPU you really use on your mainboard and add the right microcode to you configuration. This should solve your issue. Werner Von: coreboot [mailto:coreboot-bounces@coreboot.org<mailto:coreboot-bounces@coreboot.org>] Im Auftrag von ??? Gesendet: Freitag, 1. Juli 2016 05:46 An: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Betreff: [coreboot] Bring up Intel Camelback Mountain Board with coreboot+FSP failed Dear Sir, I just clone the latest coreboot source code from GIT<http://review.coreboot.org/p/coreboot> and FSP from Intel FSP website<https://downloadcenter.intel.com/download/25701>. Using " make crossgcc-i386 CPU=4 " to setup the compilation environment. But the Camelback Mountain board could not bring up successfully, it always hang with POST CODE = 0xCE. From the Intel FSP spec 1.0, it seems that system halt before loading FSP. Attached is my .config file, is there anyone hit the fail symptoms same as me and any idea to solve it? Thanks a lot, Jim -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

setting ipxe rom path deslects ipxe option
by Andrew Engelbrecht 06 Jul '16

06 Jul '16

when using "make menuconfig", i selected "add pxe rom" then i selected the field below to set the path of the pxe rom image. i entered the path, then pressed enter. as a result, the "add pxe rom" option was disabled. i then re-enabled that option and saw the path that i entered. if not paying attention, one might think they've enabled pxe, but fail to enable it. i think this is likely a bug. i expected the pxe option to not be disabled by entering a pxe image path. andrew

2 1

Re: [coreboot] Windows only seeing 2GB of 4G (Seabios
by Naveed Ghori 05 Jul '16

05 Jul '16

But I should still see 4GB without any patch. Right? Windows only see 1.92GB as “Installed Memory (RAM)” in Control Panel->System. I am happy for the system to see up to 4GB only. From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Tuesday, 7 June 2016 1:13 PM To: Naveed Ghori Cc: coreboot Subject: Re: [coreboot] Windows only seeing 2GB of 4G (Seabios Hello Naveed, For you to read: https://en.wikipedia.org/wiki/Physical_Address_Extension Important: With PAE, IA-32<https://en.wikipedia.org/wiki/IA-32> architecture is augmented with additional address lines used to select the additional memory, so physical address size increases from 32 bits to 36 bits. Then, after reading, this can/will help you: https://wj32.org/wp/2011/02/23/pae-patch-updated-for-windows-7-sp1/<https://linkprotect.cudasvc.com/url?a=https://wj32.org/wp/2011/02/23/pae-pa…> Zoran On Tue, Jun 7, 2016 at 6:23 AM, Naveed Ghori <naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au>> wrote: Hi all, I am booting a 32 bit Win 7 image (via Seabios). Windows is detecting only 1.92GB (even though there is 8GB of memory available. Being a 32 bit OS I would have expected it to see at least 4GB. Coreboot logs shows: Available memory below 4GB: 0x7ae00000 (1966M) Available memory above 4GB: 6144M What can cause the full 4GB to not be seen. Should I install only 4GB of memory instead of 4GB? I have ordered some to try in any case. Best Regards, Naveed Naveed Ghori | Lead Firmware & Driver Engineer DTI Group Ltd | Transit Security & Surveillance 31 Affleck Road, Perth Airport, Western Australia 6105, AU P +61 8 9373 2905<tel:%2B61%208%209373%202905>,151 | F +61 8 9479 1190<tel:%2B61%208%209479%201190> | naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au> Visit our website www.dti.com.au<https://linkprotect.cudasvc.com/url?a=http://www.dti.com.au&c=E,1,J7GyvbswE…> The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments. -- 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…>

3 5

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 July 2016