coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

using overlayfs to have several coreboot dev envs
by Charlotte Plusplus 13 Nov '16

13 Nov '16

Hello With the cross compiling tool chain, coreboot takes 1G. If you are a bit short on space, or if you want to save writes to your SSD, instead of having multiple copies of the coreboot source folder, I have found out overlayfs is very practical. If you have done git clone in /opt/coreboot/src/, simply create 4 extra folders there: coreboot-normal coreboot-fallback coreboot-normal.upper coreboo-fallback.upper The first 2 will contain a pseudo filesystem, the last 2 will contain the files that uniquely different between your versions Then run: mount -t overlayfs overlay -o lowerdir=/opt/coreboot/src/ coreboot,upperdir=/opt/coreboot/src/coreboot-normal.upper /opt/coreboot/src/coreboot-normal mount -t overlayfs overlay -o lowerdir=/opt/coreboot/src/ coreboot,upperdir=/opt/coreboot/src/coreboot-fallback.upper/ /opt/coreboot/src/coreboot-fallback You can have as many as you want in parallel. Useful if you are testing a feature but want to alternate quickly without having to recompile the other branch When you are done, umount your folders, you will see your changes are only in the .upper folder. The original folder will not be affected. Charlotte

1 0

Re: [coreboot] More details about ram issues
by Nico Huber 13 Nov '16

13 Nov '16

On 12.11.2016 06:40, Charlotte Plusplus wrote: > Using my new usb debug cable, here is a full debug output from setting > max_mem_clock_mhz=800 (image normal) : clocks selected 9-9-9-24, getting > about 750 errors in memtest after 3 min > > max_mem_clock_mhz=934 (image fallback) : clocks selected 10-10-10-28 which > is so optimistic it can't boot and remain stucks in a loop of "PLL busy..." > > Before, when I was manually setting the SPD latency, I could get fewer > errors and even boot at 934. > > So I followed Nico advice and created mainboard_fill_pei_data to do a non > native ram init with the same max_mem_clock_mhz=800, with a fallback at 666. > > It compiled fine with CONFIG_USE_BLOBS=y and CONFIG_USE_NATIVE_RAMINIT > manually disabled, but I must have done something wrong, as it shows the > 666 from the fallback, and gets stuck in the "PLL busy" loop Looks like it's booting the fallback path, maybe because something went wrong on the normal path? I haven't got USB debug working with the MRC blob reliably for over a year now, btw. But you should definitely see messages before coreboot jumps into the blob. If you get there and it seems to hang, disable USB debug in romstage (the blob doesn't have de- bug output anyway). > > On reboot to fallback, max_mem_clock_mhz=666 (image fallback) is correctly > selected, with clocks 7-7-7-20 and as usual a bunch of errors in the memtest > > It's late and I may have done some obvious mistake in > mainboard_fill_pei_data, but I can't spot it. (and I don't understand the > ts_addresses part) A wild guess: TS stands for thermal sensor (for each DIMM). Shouldn't matter. But according to your comments A2 and A4 should be exchanged (matters if your DIMMs have different SPDs or you didn't populate all slots). Nico

2 1

Does the Core2Quad Mobile Q9100 require microcode updates?
by Daniel Kulesz 12 Nov '16

12 Nov '16

Hi, I am considering upgrading my Coreboot'ing Thinkpad T500 with a Core2Quad Mobile Q9100 [1] (which requires some hardware modifications but is doable). My question is: Does this CPU require the microcode updates or will it run without? Practical experience from someone running this or a simular CPU from the same family (Q9000, Q9300) would be appreciated! Cheers, Daniel [1] http://ark.intel.com/products/37033/Intel-Core2-Quad-Processor-Q9100-12M-Ca…

1 0

Re: [coreboot] More details about ram issues
by Charlotte Plusplus 12 Nov '16

12 Nov '16

Using my new usb debug cable, here is a full debug output from setting max_mem_clock_mhz=800 (image normal) : clocks selected 9-9-9-24, getting about 750 errors in memtest after 3 min max_mem_clock_mhz=934 (image fallback) : clocks selected 10-10-10-28 which is so optimistic it can't boot and remain stucks in a loop of "PLL busy..." Before, when I was manually setting the SPD latency, I could get fewer errors and even boot at 934. So I followed Nico advice and created mainboard_fill_pei_data to do a non native ram init with the same max_mem_clock_mhz=800, with a fallback at 666. It compiled fine with CONFIG_USE_BLOBS=y and CONFIG_USE_NATIVE_RAMINIT manually disabled, but I must have done something wrong, as it shows the 666 from the fallback, and gets stuck in the "PLL busy" loop On reboot to fallback, max_mem_clock_mhz=666 (image fallback) is correctly selected, with clocks 7-7-7-20 and as usual a bunch of errors in the memtest It's late and I may have done some obvious mistake in mainboard_fill_pei_data, but I can't spot it. (and I don't understand the ts_addresses part)

1 0

Re: [coreboot] More details about ram issues
by Patrick Rudolph 12 Nov '16

12 Nov '16

Am Fri, 11 Nov 2016 13:53:16 +0100 schrieb Nico Huber <nico.h(a)gmx.de>: > Hi Charlotte, > > On 11.11.2016 08:14, Charlotte Plusplus wrote: > > So I did many more tests today (more than 6h, and flashing around 30 > > times), with SPD settings hardcoded into raminit, and without the > > mrc cache interfering. > > thanks for the analysis and summing this up. > > > > > TLDR: coreboot tries to increase the frequency without increasing > > the voltage, and that doesn't work for all memory. > > > > Basically, with the problematic ram sticks, I can boot perfectly > > fine at DDR3-1866 speed, but even the slower setting 11-11-11-31 > > gives errors on the memtest. This is inconsistent with information > > I found about my memory from its SPD information, and from other > > people who overclock this exact same memory. > > > > Even at 10-10-10-27, I still get errors at DDR3-1600 speeds. Far > > fewer than before, but some errors sill. > > > > After reading more about XMP and SPD, it is my understanding that : > > - JEDEC specs stop at 1600, and after that XMP is required > > - even before 1600, XMP also offers profiles, and they are not > > optional: some memory is otherwise unable to work at its advertised > > speed > > This would mean the memory is just broken. But that's what I suspect > of any memory that's supposed to run out of spec. > Yes XMP is required to run "out of spec". That's why all Intel Processors only advertise DDR3-1600 as maximum frequency on Intel's homepage. XMP is optional. I don't think that XMP is the problem. My guess is that raminit doesn't set all required registers to fine tune the memory controller to get it stable. > > - XMP profiles are some kind of overclocking: they usually require > > adjusting the voltage, to deal with this increased speed > > Not kind of overclocking, simply overclocking. There's only one > voltage specified for DDR3, IIRC. > > > - in XMP profile bytes, voltage increase information is given > > precisely > > - nowhere in the code I saw anything increasing the voltage, while > > XMP requires that > > > > I conclude that while there may be errors in selecting the SPD > > settings, even if the SPD is manually corrected with known-good > > settings, or if overshooting with very generous latencies, some > > errors do remain as the ram is being asked to operate outside its > > voltage specifications (given the frequency) > > > > 1.5V is a JEDEC spec, but RAM is advertised based on the information > > contained in the XMP profiles, which at the moment do not seem fully > > supported. > > JEDEC is the standard. If the XMP support is half-baked it should be > disabled by default. Maybe we should even put a warning in the log if > we encounter an XMP profile with anything else than 1.5V (if it's > common that those DIMMs are broken ex factory). > Yes, we could add a warning that XMP profile will be used. I personly never had problems with it. > > > > I do not know how to adjust the voltage (it should require talking > > to the IMC of the CPU) but I think that as soon as this is done, > > stability should improve. > > > > If someone can propose a patch doing that (either using the voltage > > read from SPD, or by manually entering voltage information), I will > > be happy to test it. > > Depending on the board the voltage might not be configurable at all. > Why should it be if there is only one voltage defined in the standard? > The W520 does only have 1.5V DDR voltage. If it's stable with vendor bios, it's not a DDR voltage problem at all. > > > > For now, I urge caution when operating even at DDR-1866 > > frequencies. Most boards do set up 933 as their max_mem_clock_mhz. > > It is not very prudent to do that until the voltage situation can > > be solved. > > If the board can work at that frequency, that's just fine. If the > voltage is a problem, it's due to the memory module. IMHO, the rule > should be to ignore SPD frequency settings that include an out of spec > voltage. That's what sandybridge raminit does. Only XMP profiles with DDR voltage of 1.5V are used. Profiles that do have other voltage setting are ignored. Regards, Patrick > > If you want to do further testing, you can try to find out which com- > binations of processor and DIMMs work with the Vendor BIOS or the MRC > blob (I wouldn't expect that it supports non-JEDEC stuff, but it would > be nice to know if something can be fixed in coreboot easily). > > Nico

3 2

Re: [coreboot] More details about ram issues
by Nico Huber 12 Nov '16

12 Nov '16

On 11.11.2016 16:59, Charlotte Plusplus wrote: > Hello > > On Fri, Nov 11, 2016 at 7:53 AM, Nico Huber <nico.h(a)gmx.de> wrote: > >>> After reading more about XMP and SPD, it is my understanding that : >>> - JEDEC specs stop at 1600, and after that XMP is required >>> - even before 1600, XMP also offers profiles, and they are not optional: >>> some memory is otherwise unable to work at its advertised speed >> >> This would mean the memory is just broken. But that's what I suspect of >> any memory that's supposed to run out of spec. >> > > I think it is a being too extreme. All of the ram sold, and most of what is > being used contains XMP profiles. It is hard to say how much of the > installed base may have problems when using XMP profiles without adapting > the voltage since not many people use coreboot, and not many of those who > use coreboot will be running memtest for hours. You claimed that the XMP profile is non-optional for some modules. That's what I call broken (independently of coreboot). > > >>> - XMP profiles are some kind of overclocking: they usually require >>> adjusting the voltage, to deal with this increased speed >> >> Not kind of overclocking, simply overclocking. There's only one voltage >> specified for DDR3, IIRC. >> > > It is indeed Intel fault for rating the IMC only to 1600, and putting a > hack on top of that to make RAM go faster. But they made this hack a > standard, adopted by manufacturers. So it is not just overclocking in the > usual sense. It is Intel and ram-manufacturers validated overclocking, > where the XMP profiles contain speed settings + voltage, and negociate with > the system to get this voltage. > > It is stable, or it wouldn't be used in production by so many bioses. I have no idea about XMP adoption. So I can only guess: Those many BIOSes are a fraction of all BIOSes, which are a fraction of all PC firmware, which are a fraction of all firmware for PC-like devices... in the end a very tiny fraction in a world full of DDR3. > > >> JEDEC is the standard. If the XMP support is half-baked it should be >> disabled by default. Maybe we should even put a warning in the log if we >> encounter an XMP profile with anything else than 1.5V (if it's common >> that those DIMMs are broken ex factory). >> > > So many standards to chose from lol I wouldn't call the XMP support half > baked. It is a very nice addition, as based on my understanding, some > combination of chipsets + RAM may not even be able boot without XMP > profiles. The XMP implementation just needs to be completed to also do the > voltage part. Which either does not work if the board is not designed for it or would include hardware modifications. > > Likewise, we can't say that 99% of the DIMMs are broken. The XMP profiles > have been tested and validated. > > In my opinion, XMP should be a compile time option, defaulting to y, but > with a warning of possible ram errors. > > Most of the boards have a max_mem_clock_mhz at 933, which concerns me just > as much in terms of ram errors. > > I would suggest RAM settings to override that, and the selected SPD > settings. This way that unstable settings detected in memtest86 can be > adjusted in nvramgui without having to recompile. Which would open the path to brick your system by nvram settings. Not a feature of BIOSes that I'd want coreboot to adopt. > > I will do more research to see if I can do that in userland (like MSR can > be used for CPU overclocking, there must be a way to specify ram voltage) > > End result until XMP voltage can be adjustable in some way or another: > - most system will be unaffected > - unstable system can put max_mem_clock_mhz override to 666 or see if they > can get something better with manual SPD > - userland programs may automate that last part > - when XMP voltage is supported (and 100 MHz for ivy bridge instead of 133 > as Patrick noted, etc), coreboot will have gained much more flexibility in > RAM initialization to deal with similar situations that may arise with new > specs > > It will also be very nice to have all that work without blobs. Agreed. > > Depending on the board the voltage might not be configurable at all. Why >> should it be if there is only one voltage defined in the standard? >> > > No, XMP calls for precise voltage. From wikipedia: > > bit 0 Module Vdd voltage twentieths (0.00 or 0.05) > bits 4:1 Module Vdd voltage tenths (0.0–0.9) > bits 6:5 Module Vdd voltage units (0–2) > > The standard call for the DIMM asking the system a specific voltage. It is > a negociation of speed, latency and voltage, cf > https://en.wikipedia.org/wiki/Serial_presence_detect#Extreme_Memory_Profile… > I know what it is. It's not the standard board manufacturers usually work with. > >> If the board can work at that frequency, that's just fine. If the >> voltage is a problem, it's due to the memory module. IMHO, the rule >> should be to ignore SPD frequency settings that include an out of spec >> voltage >> > > XMP is a specification. It should be supported. I think the only mistake is > that the voltage part is not being applied. It's not out of spec, it's > within another spec. > > >> If you want to do further testing, you can try to find out which com- >> binations of processor and DIMMs work with the Vendor BIOS or the MRC >> blob (I wouldn't expect that it supports non-JEDEC stuff, but it would >> be nice to know if something can be fixed in coreboot easily). > > > I tested the Lenovo bios in depth with memtest86. It works just fine. Which is a sign that the voltage setting isn't causing trouble. Since the W520 doesn't support anything beside 1.5V, as Patrick pointed out. > > Could you give me some suggestions to use the MRC blob? I don't see > anything like that in coreboot soure. (And actually, if it's a intel blob, > I would expect that it will support XMP) Enable CONFIG_USE_BLOBS and disable CONFIG_USE_NATIVE_RAMINIT. And you have to implement mainboard_fill_pei_data() in romstage.c (e.g. like kontron/ktqm77). If it's working, you can compare settings made by the blob and the native raminit with inteltool dumps. You can of course com- pare settings of the vendor BIOS too, but I'd expect less noise from the MRC blob. Nico > > I will try to find a way to adjust the voltage from userland. I will do > more test when I have either the blob thing or the voltage working. > > Thanks > Charlotte >

2 1

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

11 Nov '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 240 new defect(s) introduced to coreboot found with Coverity Scan. 6 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 240 defect(s) ** CID 1365731: Null pointer dereferences (NULL_RETURNS) /src/drivers/intel/fsp2_0/hand_off_block.c: 109 in save_hob_list() ________________________________________________________________________________________________________ *** CID 1365731: Null pointer dereferences (NULL_RETURNS) /src/drivers/intel/fsp2_0/hand_off_block.c: 109 in save_hob_list() 103 static void *fsp_hob_list_ptr CAR_GLOBAL; 104 105 static void save_hob_list(int is_recovery) 106 { 107 uint32_t *cbmem_loc; 108 cbmem_loc = cbmem_add(CBMEM_ID_FSP_RUNTIME, sizeof(*cbmem_loc)); >>> CID 1365731: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "cbmem_loc". 109 *cbmem_loc = (uintptr_t)fsp_get_hob_list(); 110 } 111 112 ROMSTAGE_CBMEM_INIT_HOOK(save_hob_list); 113 114 const void *fsp_get_hob_list(void) ** CID 1365730: (BUFFER_SIZE) /src/mainboard/google/eve/romstage.c: 41 in mainboard_memory_init_params() /src/mainboard/google/eve/romstage.c: 42 in mainboard_memory_init_params() ________________________________________________________________________________________________________ *** CID 1365730: (BUFFER_SIZE) /src/mainboard/google/eve/romstage.c: 41 in mainboard_memory_init_params() 35 { 1, 0, 4, 5, 3, 2, 7, 6 } }; 36 /* Rcomp resistor */ 37 const u16 rcomp_resistor[] = { 200, 81, 162 }; 38 /* Rcomp target */ 39 const u16 rcomp_target[] = { 100, 40, 40, 23, 40 }; 40 >>> CID 1365730: (BUFFER_SIZE) >>> You might overrun the 12 byte destination string "mem_cfg->DqByteMapCh0" by writing the maximum 24 bytes from "dq_map". 41 memcpy(&mem_cfg->DqByteMapCh0, dq_map, sizeof(dq_map)); 42 memcpy(&mem_cfg->DqsMapCpu2DramCh0, dqs_map, sizeof(dqs_map)); 43 memcpy(&mem_cfg->RcompResistor, rcomp_resistor, sizeof(rcomp_resistor)); 44 memcpy(&mem_cfg->RcompTarget, rcomp_target, sizeof(rcomp_target)); 45 46 mem_cfg->MemorySpdPtr00 = mainboard_get_spd_data(); 47 mem_cfg->MemorySpdPtr10 = mem_cfg->MemorySpdPtr00; 48 mem_cfg->MemorySpdDataLen = SPD_LEN; /src/mainboard/google/eve/romstage.c: 42 in mainboard_memory_init_params() 36 /* Rcomp resistor */ 37 const u16 rcomp_resistor[] = { 200, 81, 162 }; 38 /* Rcomp target */ 39 const u16 rcomp_target[] = { 100, 40, 40, 23, 40 }; 40 41 memcpy(&mem_cfg->DqByteMapCh0, dq_map, sizeof(dq_map)); >>> CID 1365730: (BUFFER_SIZE) >>> You might overrun the 8 byte destination string "mem_cfg->DqsMapCpu2DramCh0" by writing the maximum 16 bytes from "dqs_map". 42 memcpy(&mem_cfg->DqsMapCpu2DramCh0, dqs_map, sizeof(dqs_map)); 43 memcpy(&mem_cfg->RcompResistor, rcomp_resistor, sizeof(rcomp_resistor)); 44 memcpy(&mem_cfg->RcompTarget, rcomp_target, sizeof(rcomp_target)); 45 46 mem_cfg->MemorySpdPtr00 = mainboard_get_spd_data(); 47 mem_cfg->MemorySpdPtr10 = mem_cfg->MemorySpdPtr00; 48 mem_cfg->MemorySpdDataLen = SPD_LEN; ** CID 1365389: (OVERRUN) /src/mainboard/google/eve/romstage.c: 41 in mainboard_memory_init_params() ________________________________________________________________________________________________________ *** CID 1365389: (OVERRUN) /src/mainboard/google/eve/romstage.c: 41 in mainboard_memory_init_params() 35 { 1, 0, 4, 5, 3, 2, 7, 6 } }; 36 /* Rcomp resistor */ 37 const u16 rcomp_resistor[] = { 200, 81, 162 }; 38 /* Rcomp target */ 39 const u16 rcomp_target[] = { 100, 40, 40, 23, 40 }; 40 >>> CID 1365389: (OVERRUN) >>> Overrunning array "mem_cfg->DqByteMapCh0" of 12 bytes by passing it to a function which accesses it at byte offset 23 using argument "24UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 41 memcpy(&mem_cfg->DqByteMapCh0, dq_map, sizeof(dq_map)); 42 memcpy(&mem_cfg->DqsMapCpu2DramCh0, dqs_map, sizeof(dqs_map)); 43 memcpy(&mem_cfg->RcompResistor, rcomp_resistor, sizeof(rcomp_resistor)); 44 memcpy(&mem_cfg->RcompTarget, rcomp_target, sizeof(rcomp_target)); 45 46 mem_cfg->MemorySpdPtr00 = mainboard_get_spd_data(); 47 mem_cfg->MemorySpdPtr10 = mem_cfg->MemorySpdPtr00; 48 mem_cfg->MemorySpdDataLen = SPD_LEN; /src/mainboard/intel/kblrvp/romstage.c: 32 in mainboard_memory_init_params() 26 27 void mainboard_memory_init_params(FSPM_UPD *mupd) 28 { 29 FSP_M_CONFIG *mem_cfg; 30 mem_cfg = &mupd->FspmConfig; 31 >>> CID 1365389: (OVERRUN) >>> Overrunning array "mem_cfg->DqByteMapCh0" of 12 bytes by passing it to a function which accesses it at byte offset 23. 32 mainboard_fill_dq_map_data(&mem_cfg->DqByteMapCh0); 33 mainboard_fill_dqs_map_data(&mem_cfg->DqsMapCpu2DramCh0); 34 mainboard_fill_rcomp_res_data(&mem_cfg->RcompResistor); 35 mainboard_fill_rcomp_strength_data(&mem_cfg->RcompTarget); 36 37 mem_cfg->DqPinsInterleaved = 0; ** CID 1365388: (OVERRUN) /src/mainboard/google/eve/romstage.c: 42 in mainboard_memory_init_params() ________________________________________________________________________________________________________ *** CID 1365388: (OVERRUN) /src/mainboard/google/eve/romstage.c: 42 in mainboard_memory_init_params() 36 /* Rcomp resistor */ 37 const u16 rcomp_resistor[] = { 200, 81, 162 }; 38 /* Rcomp target */ 39 const u16 rcomp_target[] = { 100, 40, 40, 23, 40 }; 40 41 memcpy(&mem_cfg->DqByteMapCh0, dq_map, sizeof(dq_map)); >>> CID 1365388: (OVERRUN) >>> Overrunning array "mem_cfg->DqsMapCpu2DramCh0" of 8 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 42 memcpy(&mem_cfg->DqsMapCpu2DramCh0, dqs_map, sizeof(dqs_map)); 43 memcpy(&mem_cfg->RcompResistor, rcomp_resistor, sizeof(rcomp_resistor)); 44 memcpy(&mem_cfg->RcompTarget, rcomp_target, sizeof(rcomp_target)); 45 46 mem_cfg->MemorySpdPtr00 = mainboard_get_spd_data(); 47 mem_cfg->MemorySpdPtr10 = mem_cfg->MemorySpdPtr00; 48 mem_cfg->MemorySpdDataLen = SPD_LEN; /src/mainboard/intel/kblrvp/romstage.c: 33 in mainboard_memory_init_params() 27 void mainboard_memory_init_params(FSPM_UPD *mupd) 28 { 29 FSP_M_CONFIG *mem_cfg; 30 mem_cfg = &mupd->FspmConfig; 31 32 mainboard_fill_dq_map_data(&mem_cfg->DqByteMapCh0); >>> CID 1365388: (OVERRUN) >>> Overrunning array "mem_cfg->DqsMapCpu2DramCh0" of 8 bytes by passing it to a function which accesses it at byte offset 15. 33 mainboard_fill_dqs_map_data(&mem_cfg->DqsMapCpu2DramCh0); 34 mainboard_fill_rcomp_res_data(&mem_cfg->RcompResistor); 35 mainboard_fill_rcomp_strength_data(&mem_cfg->RcompTarget); 36 37 mem_cfg->DqPinsInterleaved = 0; 38 mem_cfg->MemorySpdPtr00 = mainboard_get_spd_data(); 39 if (mainboard_has_dual_channel_mem()) 40 mem_cfg->MemorySpdPtr10 = mem_cfg->MemorySpdPtr00; 41 mem_cfg->MemorySpdDataLen = SPD_LEN; ** CID 1364082: Integer handling issues (NO_EFFECT) /src/soc/rockchip/common/spi.c: 170 in rockchip_spi_set_sample_delay() ________________________________________________________________________________________________________ *** CID 1364082: Integer handling issues (NO_EFFECT) /src/soc/rockchip/common/spi.c: 170 in rockchip_spi_set_sample_delay() 164 assert(bus >= 0 && bus < ARRAY_SIZE(rockchip_spi_slaves)); 165 struct rockchip_spi *regs = rockchip_spi_slaves[bus].regs; 166 unsigned int rsd; 167 168 /* Rxd Sample Delay */ 169 rsd = DIV_ROUND_CLOSEST(delay_ns * (SPI_SRCCLK_HZ >> 8), 1*GHz >> 8); >>> CID 1364082: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "rsd >= 0U". 170 assert(rsd >= 0 && rsd <= 3); 171 clrsetbits_le32(&regs->ctrlr0, SPI_RXDSD_MASK << SPI_RXDSD_OFFSET, 172 rsd << SPI_RXDSD_OFFSET); 173 } 174 175 int spi_claim_bus(struct spi_slave *slave) ** CID 1363355: (SIZEOF_MISMATCH) /src/drivers/intel/fsp2_0/upd_display.c: 37 in fspm_display_arch_params() /src/drivers/intel/fsp2_0/upd_display.c: 40 in fspm_display_arch_params() ________________________________________________________________________________________________________ *** CID 1363355: (SIZEOF_MISMATCH) /src/drivers/intel/fsp2_0/upd_display.c: 37 in fspm_display_arch_params() 31 { 32 /* Display the architectural parameters for MemoryInit */ 33 printk(BIOS_SPEW, "Architectural UPD values for MemoryInit at: 0x%p\n", 34 new); 35 fsp_display_upd_value("Revision", sizeof(old->Revision), 36 old->Revision, new->Revision); >>> CID 1363355: (SIZEOF_MISMATCH) >>> Passing argument "old->NvsBufferPtr" of type "void * const" and argument "4UL /* sizeof (old->NvsBufferPtr) */" to function "fsp_display_upd_value" is suspicious. 37 fsp_display_upd_value("NvsBufferPtr", sizeof(old->NvsBufferPtr), 38 (uintptr_t)old->NvsBufferPtr, 39 (uintptr_t)new->NvsBufferPtr); 40 fsp_display_upd_value("StackBase", sizeof(old->StackBase), 41 (uintptr_t)old->StackBase, 42 (uintptr_t)new->StackBase); /src/drivers/intel/fsp2_0/upd_display.c: 40 in fspm_display_arch_params() 34 new); 35 fsp_display_upd_value("Revision", sizeof(old->Revision), 36 old->Revision, new->Revision); 37 fsp_display_upd_value("NvsBufferPtr", sizeof(old->NvsBufferPtr), 38 (uintptr_t)old->NvsBufferPtr, 39 (uintptr_t)new->NvsBufferPtr); >>> CID 1363355: (SIZEOF_MISMATCH) >>> Passing argument "old->StackBase" of type "void * const" and argument "4UL /* sizeof (old->StackBase) */" to function "fsp_display_upd_value" is suspicious. 40 fsp_display_upd_value("StackBase", sizeof(old->StackBase), 41 (uintptr_t)old->StackBase, 42 (uintptr_t)new->StackBase); 43 fsp_display_upd_value("StackSize", sizeof(old->StackSize), 44 old->StackSize, new->StackSize); 45 fsp_display_upd_value("BootLoaderTolumSize", ** CID 1362811: Resource leaks (RESOURCE_LEAK) /src/southbridge/amd/sr5650/sr5650.c: 804 in add_ivrs_device_entries() ________________________________________________________________________________________________________ *** CID 1362811: Resource leaks (RESOURCE_LEAK) /src/southbridge/amd/sr5650/sr5650.c: 804 in add_ivrs_device_entries() 798 sibling = sibling->sibling) 799 add_ivrs_device_entries(dev, sibling, depth + 1, 800 depth, root_level, current, length); 801 802 if (depth == 0) 803 free(root_level); >>> CID 1362811: Resource leaks (RESOURCE_LEAK) >>> Returning without freeing "root_level" leaks the storage that it points to. 804 } 805 806 unsigned long acpi_fill_mcfg(unsigned long current) 807 { 808 struct resource *res; 809 resource_t mmconf_base = EXT_CONF_BASE_ADDRESS; ** CID 1362809: Null pointer dereferences (FORWARD_NULL) /src/soc/marvell/mvmap2315/load_validate.c: 97 in load_and_validate() ________________________________________________________________________________________________________ *** CID 1362809: Null pointer dereferences (FORWARD_NULL) /src/soc/marvell/mvmap2315/load_validate.c: 97 in load_and_validate() 91 = (void *)read32( 92 &mvmap2315_mcu_secconfig->boot_callback_pointer); 93 u8 image_digest[32]; 94 95 image_info = find_bdb_image(bdb_info, image_type); 96 >>> CID 1362809: Null pointer dereferences (FORWARD_NULL) >>> Comparing "image_info" to null implies that "image_info" might be null. 97 if (!image_info) 98 image_failure(); 99 100 set_flash_parameters(&flash_info, image_info); 101 102 if (flash_init(bootrom_info->flash_media, MVMAP2315_MMC_CLK_MHZ)) ** CID 1362808: (CONSTANT_EXPRESSION_RESULT) /src/soc/marvell/mvmap2315/mcu.c: 34 in mvmap2315_calc_checksum() /src/soc/marvell/mvmap2315/mcu.c: 34 in mvmap2315_calc_checksum() ________________________________________________________________________________________________________ *** CID 1362808: (CONSTANT_EXPRESSION_RESULT) /src/soc/marvell/mvmap2315/mcu.c: 34 in mvmap2315_calc_checksum() 28 const u8 *bytes = data; 29 int i; 30 31 for (i = csum = 0; i < size; i++) 32 csum += bytes[i]; 33 >>> CID 1362808: (CONSTANT_EXPRESSION_RESULT) >>> The expression "~csum && 255" is suspicious because it performs a Boolean operation on a constant other than 0 or 1. 34 return (~csum) && 0xFF; 35 } 36 37 void mcu_irq(void) 38 { 39 printk(BIOS_DEBUG, "waiting for MCU msg...\n"); /src/soc/marvell/mvmap2315/mcu.c: 34 in mvmap2315_calc_checksum() 28 const u8 *bytes = data; 29 int i; 30 31 for (i = csum = 0; i < size; i++) 32 csum += bytes[i]; 33 >>> CID 1362808: (CONSTANT_EXPRESSION_RESULT) >>> "~csum" is always 1/true regardless of the values of its operand. This occurs as the logical first operand of "&&". 34 return (~csum) && 0xFF; 35 } 36 37 void mcu_irq(void) 38 { 39 printk(BIOS_DEBUG, "waiting for MCU msg...\n"); ** CID 1362592: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1362592: Null pointer dereferences (NULL_RETURNS) /src/drivers/generic/max98357a/max98357a.c: 41 in max98357a_fill_ssdt() 35 struct acpi_dp *dp; 36 37 if (!dev->enabled || !config) 38 return; 39 40 /* Device */ >>> CID 1362592: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "acpi_device_scope(dev)" when calling "acpigen_write_scope". 41 acpigen_write_scope(acpi_device_scope(dev)); 42 acpigen_write_device(acpi_device_name(dev)); 43 acpigen_write_name_string("_HID", MAX98357A_ACPI_HID); 44 acpigen_write_name_integer("_UID", 0); 45 acpigen_write_name_string("_DDN", dev->chip_ops->name); 46 acpigen_write_STA(ACPI_STATUS_DEVICE_ALL_ON); ** CID 1357458: Insecure data handling (TAINTED_SCALAR) /payloads/libpayload/libcbfs/cbfs_core.c: 258 in cbfs_get_contents() ________________________________________________________________________________________________________ *** CID 1357458: Insecure data handling (TAINTED_SCALAR) /payloads/libpayload/libcbfs/cbfs_core.c: 258 in cbfs_get_contents() 252 253 void *data = m->map(m, handle->media_offset + handle->content_offset, 254 on_media_size); 255 if (data == CBFS_MEDIA_INVALID_MAP_ADDRESS) 256 return NULL; 257 >>> 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.] 258 ret = malloc(*size); 259 if (ret != NULL && !cbfs_decompress(algo, data, ret, *size)) { 260 free(ret); 261 ret = NULL; 262 } 263 ** CID 1357457: Resource leaks (RESOURCE_LEAK) /src/arch/x86/acpi_device.c: 742 in acpi_dp_add_integer_array() ________________________________________________________________________________________________________ *** CID 1357457: Resource leaks (RESOURCE_LEAK) /src/arch/x86/acpi_device.c: 742 in acpi_dp_add_integer_array() 736 return NULL; 737 738 for (i = 0; i < len; i++) 739 if (!acpi_dp_add_integer(dp_array, NULL, array[i])) 740 break; 741 >>> CID 1357457: Resource leaks (RESOURCE_LEAK) >>> Ignoring storage allocated by "acpi_dp_add_array(dp, dp_array)" leaks it. 742 acpi_dp_add_array(dp, dp_array); 743 744 return dp_array; 745 } 746 747 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: 768 in acpi_dp_add_gpio() ________________________________________________________________________________________________________ *** CID 1357456: Resource leaks (RESOURCE_LEAK) /src/arch/x86/acpi_device.c: 768 in acpi_dp_add_gpio() 762 /* Pin in the GPIO resource, typically zero */ 763 acpi_dp_add_integer(gpio, NULL, pin); 764 765 /* Set if pin is active low */ 766 acpi_dp_add_integer(gpio, NULL, active_low); 767 >>> CID 1357456: Resource leaks (RESOURCE_LEAK) >>> Ignoring storage allocated by "acpi_dp_add_array(dp, gpio)" leaks it. 768 acpi_dp_add_array(dp, gpio); 769 770 return gpio; ** 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/f12/Proc/Mem/NB/mn.c: 497 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/mn.c: 499 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f15/Proc/Mem/NB/mn.c: 502 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f16kb/Proc/Mem/NB/mn.c: 579 in MemNTrainingFlowUnb() /src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/mn.c: 495 in MemNTrainingFlowUnb() ________________________________________________________________________________________________________ *** CID 1357452: (OVERRUN) /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/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/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/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/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/f12/Proc/Mem/NB/mn.c: 304 in MemNTrainingFlowNb() /src/vendorcode/amd/agesa/f14/Proc/Mem/NB/mn.c: 306 in MemNTrainingFlowNb() /src/vendorcode/amd/agesa/f15/Proc/Mem/NB/mn.c: 309 in MemNTrainingFlowNb() /src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/mn.c: 302 in MemNTrainingFlowNb() ________________________________________________________________________________________________________ *** CID 1357451: (OVERRUN) /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/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/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/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 1357446: Control flow issues (DEADCODE) /src/northbridge/intel/x4x/raminit.c: 374 in sdram_detect_ram_speed() ________________________________________________________________________________________________________ *** CID 1357446: Control flow issues (DEADCODE) /src/northbridge/intel/x4x/raminit.c: 374 in sdram_detect_ram_speed() 368 } else { // DDR3 369 // Limit frequency for MCH 370 maxfreq = (s->max_ddr2_mhz == 800) ? MEM_CLOCK_800MHz : MEM_CLOCK_667MHz; 371 maxfreq >>= 3; 372 freq = MEM_CLOCK_1333MHz; 373 if (maxfreq) { >>> CID 1357446: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "freq = maxfreq + 2;". 374 freq = maxfreq + 2; 375 } 376 if (freq > MEM_CLOCK_1333MHz) { 377 freq = MEM_CLOCK_1333MHz; 378 } 379 ** CID 1355168: (CONSTANT_EXPRESSION_RESULT) /src/soc/rockchip/rk3399/clock.c: 595 in rkclk_configure_spi() /src/soc/rockchip/rk3399/clock.c: 610 in rkclk_configure_spi() /src/soc/rockchip/rk3399/clock.c: 614 in rkclk_configure_spi() ________________________________________________________________________________________________________ *** CID 1355168: (CONSTANT_EXPRESSION_RESULT) /src/soc/rockchip/rk3399/clock.c: 595 in rkclk_configure_spi() 589 case 0: 590 write32(&cru_ptr->clksel_con[59], 591 SPI_CLK_REG_VALUE(0, src_clk_div)); 592 break; 593 case 1: 594 write32(&cru_ptr->clksel_con[59], >>> CID 1355168: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (CLK_SPI_PLL_SEL_MASK << CLK_SPI1_PLL_SEL_SHIFT) | (CLK_SPI_PLL_DIV_CON_MASK << CLK_SPI1_PLL_DIV_CON_SHIFT) */) | ((32768 /* CLK_SPI_PLL_SEL_GPLL << CLK_SPI1_PLL_SEL_SHIFT */) | (src_clk_div - 1 << CLK_SPI1_PLL_DIV_CON_SHIFT))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 595 SPI_CLK_REG_VALUE(1, src_clk_div)); 596 break; 597 case 2: 598 write32(&cru_ptr->clksel_con[60], 599 SPI_CLK_REG_VALUE(2, src_clk_div)); 600 break; /src/soc/rockchip/rk3399/clock.c: 610 in rkclk_configure_spi() 604 SPI3_DIV_CON_MASK << SPI3_DIV_CON_SHIFT, 605 SPI3_PLL_SEL_PPLL << SPI3_PLL_SEL_SHIFT | 606 (src_clk_div - 1) << SPI3_DIV_CON_SHIFT)); 607 break; 608 case 4: 609 write32(&cru_ptr->clksel_con[60], >>> CID 1355168: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (CLK_SPI_PLL_SEL_MASK << CLK_SPI4_PLL_SEL_SHIFT) | (CLK_SPI_PLL_DIV_CON_MASK << CLK_SPI4_PLL_DIV_CON_SHIFT) */) | ((32768 /* CLK_SPI_PLL_SEL_GPLL << CLK_SPI4_PLL_SEL_SHIFT */) | (src_clk_div - 1 << CLK_SPI4_PLL_DIV_CON_SHIFT))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 610 SPI_CLK_REG_VALUE(4, src_clk_div)); 611 break; 612 case 5: 613 write32(&cru_ptr->clksel_con[58], 614 SPI_CLK_REG_VALUE(5, src_clk_div)); 615 break; /src/soc/rockchip/rk3399/clock.c: 614 in rkclk_configure_spi() 608 case 4: 609 write32(&cru_ptr->clksel_con[60], 610 SPI_CLK_REG_VALUE(4, src_clk_div)); 611 break; 612 case 5: 613 write32(&cru_ptr->clksel_con[58], >>> CID 1355168: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (CLK_SPI_PLL_SEL_MASK << CLK_SPI5_PLL_SEL_SHIFT) | (CLK_SPI_PLL_DIV_CON_MASK << CLK_SPI5_PLL_DIV_CON_SHIFT) */) | ((32768 /* CLK_SPI_PLL_SEL_GPLL << CLK_SPI5_PLL_SEL_SHIFT */) | (src_clk_div - 1 << CLK_SPI5_PLL_DIV_CON_SHIFT))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 614 SPI_CLK_REG_VALUE(5, src_clk_div)); 615 break; 616 default: 617 printk(BIOS_ERR, "do not support this spi bus\n"); 618 } 619 } ** CID 1355167: (CONSTANT_EXPRESSION_RESULT) /src/soc/rockchip/rk3399/clock.c: 667 in rkclk_configure_i2c() /src/soc/rockchip/rk3399/clock.c: 671 in rkclk_configure_i2c() /src/soc/rockchip/rk3399/clock.c: 675 in rkclk_configure_i2c() ________________________________________________________________________________________________________ *** CID 1355167: (CONSTANT_EXPRESSION_RESULT) /src/soc/rockchip/rk3399/clock.c: 667 in rkclk_configure_i2c() 661 case 4: 662 write32(&pmucru_ptr->pmucru_clksel[3], 663 PMU_I2C_CLK_REG_VALUE(4, src_clk_div)); 664 break; 665 case 5: 666 write32(&cru_ptr->clksel_con[61], >>> CID 1355167: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (I2C_DIV_CON_MASK << CLK_I2C5_DIV_CON_SHIFT) | (CLK_I2C_PLL_SEL_MASK << CLK_I2C5_PLL_SEL_SHIFT) */) | ((src_clk_div - 1 << CLK_I2C5_DIV_CON_SHIFT) | (32768 /* CLK_I2C_PLL_SEL_GPLL << CLK_I2C5_PLL_SEL_SHIFT */))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 667 I2C_CLK_REG_VALUE(5, src_clk_div)); 668 break; 669 case 6: 670 write32(&cru_ptr->clksel_con[62], 671 I2C_CLK_REG_VALUE(6, src_clk_div)); 672 break; /src/soc/rockchip/rk3399/clock.c: 671 in rkclk_configure_i2c() 665 case 5: 666 write32(&cru_ptr->clksel_con[61], 667 I2C_CLK_REG_VALUE(5, src_clk_div)); 668 break; 669 case 6: 670 write32(&cru_ptr->clksel_con[62], >>> CID 1355167: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (I2C_DIV_CON_MASK << CLK_I2C6_DIV_CON_SHIFT) | (CLK_I2C_PLL_SEL_MASK << CLK_I2C6_PLL_SEL_SHIFT) */) | ((src_clk_div - 1 << CLK_I2C6_DIV_CON_SHIFT) | (32768 /* CLK_I2C_PLL_SEL_GPLL << CLK_I2C6_PLL_SEL_SHIFT */))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 671 I2C_CLK_REG_VALUE(6, src_clk_div)); 672 break; 673 case 7: 674 write32(&cru_ptr->clksel_con[63], 675 I2C_CLK_REG_VALUE(7, src_clk_div)); 676 break; /src/soc/rockchip/rk3399/clock.c: 675 in rkclk_configure_i2c() 669 case 6: 670 write32(&cru_ptr->clksel_con[62], 671 I2C_CLK_REG_VALUE(6, src_clk_div)); 672 break; 673 case 7: 674 write32(&cru_ptr->clksel_con[63], >>> CID 1355167: (CONSTANT_EXPRESSION_RESULT) >>> "((65280 /* (I2C_DIV_CON_MASK << CLK_I2C7_DIV_CON_SHIFT) | (CLK_I2C_PLL_SEL_MASK << CLK_I2C7_PLL_SEL_SHIFT) */) | ((src_clk_div - 1 << CLK_I2C7_DIV_CON_SHIFT) | (32768 /* CLK_I2C_PLL_SEL_GPLL << CLK_I2C7_PLL_SEL_SHIFT */))) << 16" is 0xffffffffff000000 regardless of the values of its operands. This occurs as the bitwise first operand of "|". 675 I2C_CLK_REG_VALUE(7, src_clk_div)); 676 break; 677 case 8: 678 write32(&pmucru_ptr->pmucru_clksel[2], 679 PMU_I2C_CLK_REG_VALUE(8, src_clk_div)); 680 break; ________________________________________________________________________________________________________ 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] More details about ram issues
by Nico Huber 11 Nov '16

11 Nov '16

Hi Charlotte, On 11.11.2016 08:14, Charlotte Plusplus wrote: > So I did many more tests today (more than 6h, and flashing around 30 > times), with SPD settings hardcoded into raminit, and without the mrc cache > interfering. thanks for the analysis and summing this up. > > TLDR: coreboot tries to increase the frequency without increasing the > voltage, and that doesn't work for all memory. > > Basically, with the problematic ram sticks, I can boot perfectly fine at > DDR3-1866 speed, but even the slower setting 11-11-11-31 gives errors on > the memtest. This is inconsistent with information I found about my memory > from its SPD information, and from other people who overclock this exact > same memory. > > Even at 10-10-10-27, I still get errors at DDR3-1600 speeds. Far fewer than > before, but some errors sill. > > After reading more about XMP and SPD, it is my understanding that : > - JEDEC specs stop at 1600, and after that XMP is required > - even before 1600, XMP also offers profiles, and they are not optional: > some memory is otherwise unable to work at its advertised speed This would mean the memory is just broken. But that's what I suspect of any memory that's supposed to run out of spec. > - XMP profiles are some kind of overclocking: they usually require > adjusting the voltage, to deal with this increased speed Not kind of overclocking, simply overclocking. There's only one voltage specified for DDR3, IIRC. > - in XMP profile bytes, voltage increase information is given precisely > - nowhere in the code I saw anything increasing the voltage, while XMP > requires that > > I conclude that while there may be errors in selecting the SPD settings, > even if the SPD is manually corrected with known-good settings, or if > overshooting with very generous latencies, some errors do remain as the ram > is being asked to operate outside its voltage specifications (given the > frequency) > > 1.5V is a JEDEC spec, but RAM is advertised based on the information > contained in the XMP profiles, which at the moment do not seem fully > supported. JEDEC is the standard. If the XMP support is half-baked it should be disabled by default. Maybe we should even put a warning in the log if we encounter an XMP profile with anything else than 1.5V (if it's common that those DIMMs are broken ex factory). > > I do not know how to adjust the voltage (it should require talking to the > IMC of the CPU) but I think that as soon as this is done, stability should > improve. > > If someone can propose a patch doing that (either using the voltage read > from SPD, or by manually entering voltage information), I will be happy to > test it. Depending on the board the voltage might not be configurable at all. Why should it be if there is only one voltage defined in the standard? > > For now, I urge caution when operating even at DDR-1866 frequencies. Most > boards do set up 933 as their max_mem_clock_mhz. It is not very prudent to > do that until the voltage situation can be solved. If the board can work at that frequency, that's just fine. If the voltage is a problem, it's due to the memory module. IMHO, the rule should be to ignore SPD frequency settings that include an out of spec voltage. If you want to do further testing, you can try to find out which com- binations of processor and DIMMs work with the Vendor BIOS or the MRC blob (I wouldn't expect that it supports non-JEDEC stuff, but it would be nice to know if something can be fixed in coreboot easily). Nico

2 1

Porting romstage to 64 bit
by Nico Heijningen 11 Nov '16

11 Nov '16

Hi, all Based on work of Scott Duplichan [1] and the patches of Stefan Reinauer [2] I try to get the romstage of Coreboot compiled and working as 64 bit. I tried doing so by: Setting select ARCH_ROMSTAGE_X86_64 in the Kconfig of my CPU. Then the x86_64-elf-gcc compiler tells me "error: CPU you selected does not support x86-64 instruction set" So I change the .xcompile file from GCC_CFLAGS_x86_64 += -march=i686 to GCC_CFLAGS_x86_64 += -march=x86_64. After doing that I run into the "error: cast to pointer from integer of different size" which I fix by using (uintptr_t) casts. Together with adding .code32 to src/arch/x86/walkcbfs.S and changing the condition of the LD_ramstage flag in src/arch/x86/Makefile.inc from CONFIG_ARCH_ROMSTAGE_X86_32 to CONFIG_ARCH_RAMSTAGE_X86_32 (is this a bug or intentional; altering the ramstage linker flags based on the compilation architecture of the romstage?) However, then I run into the following error: "E: ELF is unsupported arch: 62" originating from util/cbfstool/rmodule.c. Apparently the cbfstool doesn't support relocation for 64 bit ELF files? Should I try to add this or am I making another obvious mistake? Can I disable relocation, I have more than enough room on my flashchip? Finally, I cannot find the man pages of the elf gcc compiler for selecting the correct --architecture --march and --oformat, where should I look? Regards, Thatux [1] https://www.coreboot.org/pipermail/coreboot/2015-January/079135.html [2] https://www.coreboot.org/pipermail/coreboot-gerrit/2015-June/027849.html

1 0

Re: [coreboot] More details about ram issues
by Charlotte Plusplus 11 Nov '16

11 Nov '16

So I did many more tests today (more than 6h, and flashing around 30 times), with SPD settings hardcoded into raminit, and without the mrc cache interfering. TLDR: coreboot tries to increase the frequency without increasing the voltage, and that doesn't work for all memory. Basically, with the problematic ram sticks, I can boot perfectly fine at DDR3-1866 speed, but even the slower setting 11-11-11-31 gives errors on the memtest. This is inconsistent with information I found about my memory from its SPD information, and from other people who overclock this exact same memory. Even at 10-10-10-27, I still get errors at DDR3-1600 speeds. Far fewer than before, but some errors sill. After reading more about XMP and SPD, it is my understanding that : - JEDEC specs stop at 1600, and after that XMP is required - even before 1600, XMP also offers profiles, and they are not optional: some memory is otherwise unable to work at its advertised speed - XMP profiles are some kind of overclocking: they usually require adjusting the voltage, to deal with this increased speed - in XMP profile bytes, voltage increase information is given precisely - nowhere in the code I saw anything increasing the voltage, while XMP requires that I conclude that while there may be errors in selecting the SPD settings, even if the SPD is manually corrected with known-good settings, or if overshooting with very generous latencies, some errors do remain as the ram is being asked to operate outside its voltage specifications (given the frequency) 1.5V is a JEDEC spec, but RAM is advertised based on the information contained in the XMP profiles, which at the moment do not seem fully supported. I do not know how to adjust the voltage (it should require talking to the IMC of the CPU) but I think that as soon as this is done, stability should improve. If someone can propose a patch doing that (either using the voltage read from SPD, or by manually entering voltage information), I will be happy to test it. For now, I urge caution when operating even at DDR-1866 frequencies. Most boards do set up 933 as their max_mem_clock_mhz. It is not very prudent to do that until the voltage situation can be solved. Charlote

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