[coreboot] More details about ram issues
Patrick Rudolph
siro at das-labor.org
Tue Nov 8 17:30:53 CET 2016
Am Tue, 8 Nov 2016 02:15:31 -0500
schrieb Charlotte Plusplus <pluspluscharlotte at gmail.com>:
> Hello
>
> I have done further ram testing.
>
> My first guess was to disable the XMP code - it didn't help, but I
> may have done things wrong as I was trying with a normal and a
> fallback mode to try more combinations of options, and apparently the
> ram settings are cached and shared between normal and fallback, even
> when max_mem_clock_mhz differ.
>
Good point, I've should have mentioned that.
> That's not a good thing when working on ram issues, so I wonder, is
> there any way to manually invalidate that mrc cache during tests?? (I
> almost want to comment the function in raminit.c) Since I don't have
> a USBDEBUG yet, I go to a linux shell to check the cbmem output
> between tests. So anything I can type to disable the mrc cache would
> do.
>
At the moment there's no such functionality I'm aware of. Of course you
can comment store_current_mrc_cache() and it will always do full
raminit training.
> Alternatively, a really nice thing to have would be a nvram option to
> pass max_mem_clock_mhz without having to recompile, and invalidate
> this cache if the settings do not match, to cover cases like this
> one. Also, overclockers would love that. So this option could even
> be used to pass custom SPD timings, as some bios do. It would require
> more thinking on what to do and how, but it looks like a nice feature
> to me. Would it be acceptable to add that to coreboot?
>
That's a nice idea, but there's no interface (yet). It also would be
nice to have a vendor independent solution.
> Anyway, I tried to downclock at various frequencies:
> - 666 Mhz: CAS 7-7-7-20 : all sticks work, individually and together
> - 800 Mhz: CAS 9-9-9-24: 1 stick doesn't work, the others do, but I
> still get errors during the memtest step 8.
>
> I regret it is not possible to manually enter the right SPD
> information that I know to work: 11-11-11-29 for DDR3-2000,
> 11-11-11-31 for DDR3-2133 - and something slightly larger for
> DDR3-1600. So I have DDR3-2133 sticks that I am forced to run at
> DDR3-1333 speeds because otherwise the selected SPD settings make
> everything unstable :-(
>
The raminit code is based on sandybridge, and doesn't have all ivy
bridge optimizations. For exmaple it isn't possible to use a base
frequency of 100Mhz (no DDR3-2000 or DDR3-1800 modes supported).
> If only I could slightly increase the latency, I could run at least at
> DDR3-1600 speeds with 0 error in memtest. I'm thinking of tweaking
> dram_find_common_params with:
>
> ctrl->tRAS = MAX(ctrl->tRAS, dimm->tRAS) +X;
>
Please have a look at dram_timing(). I don't think it's a good idea to
do tests without having logging output, but it's up to you.
> and manually trying X=1, X=2 etc. until I can finally have memtest
> running without error.
>
> Would there be any issues with that? Any better idea?
>
> Here is an extract from the log:
>
You can enable raminit logging by checking "Output verbose RAM init
debug messages" in menu Debugging. It doesn't work well with cbmem
logging.
Regards
Patrick
> find_current_mrc_cache_local: No valid MRC cache found.
> Revision : 11
> Type : b
> Key : 3
> Banks : 8
> Capacity : 4 Gb
> Supported voltages : 1.35V 1.5V
> SDRAM width : 8
> Bus extension : 0 bits
> Bus width : 64
> Optional features : DLL-Off_mode RZQ/7 RZQ/6
> Thermal features : PASR ext_temp_range
> Thermal sensor : no
> Standard SDRAM : yes
> Rank1 Address bits : normal
> DIMM Reference card: B
> Manufacturer ID : 9e02
> Part number : CMSX16GX3M2B2133
> Not a DDR3 SPD!
> Row addr bits : 16
> Column addr bits : 10
> Number of ranks : 2
> DIMM Capacity : 8192 MB
> CAS latencies : 6 7 8 9 10 11
> tCKmin : 1.000 ns
> tAAmin : 10.250 ns
> tWRmin : 15.000 ns
> tRCDmin : 10.250 ns
> tRRDmin : 6.500 ns
> tRPmin : 10.250 ns
> tRASmin : 29.000 ns
> tRCmin : 39.375 ns
> tRFCmin : 260.750 ns
> tWTRmin : 7.625 ns
> tRTPmin : 8.375 ns
> tFAWmin : 30.875 ns
> channel[0] rankmap = 0x3
> Not a DDR3 SPD!
> Not a DDR3 SPD!
> Starting RAM training (0).
> PLL busy... PLL busy... PLL busy...done
> MCU frequency is set at : 800 MHz
> Selected DRAM frequency: 800 MHz
> Minimum CAS latency : 9T
> Selected CAS latency : 9T
> Selected CWL latency : 7T
> Selected tRCD : 9T
> Selected tRP : 9T
> Selected tRAS : 24T
> Selected tWR : 12T
> Selected tFAW : 25T
> Selected tRRD : 6T
> Selected tRTP : 7T
> Selected tWTR : 7T
> Selected tRFC : 209T
> XOVER CLK [c14] = 3000000
> XOVER CMD [320c] = 24000
> XOVER CLK [d14] = 0
> XOVER CMD [330c] = 4000
> DBP [4000] = 187999
> RAP [4004] = cc197476
> OTHP [400c] = a08b4
> ODT stretch [400c] = 0
> ODT stretch [400c] = a08b4
> REFI [4298] = 6cd11860
> SRFTP [42a4] = 41f88200
> DBP [4400] = 187999
> RAP [4404] = cc197476
> OTHP [440c] = a08b4
> ODT stretch [440c] = 0
> ODT stretch [440c] = a08b4
> REFI [4698] = 6cd11860
> SRFTP [46a4] = 41f88200
> Done dimm mapping
>
> MCU frequency is set at : 800 MHz
> XOVER CLK [c14] = 3000000
> XOVER CMD [320c] = 24000
> XOVER CLK [d14] = 0
> XOVER CMD [330c] = 4000
> DBP [4000] = 187999
> RAP [4004] = cc197476
> OTHP [400c] = a08b4
> ODT stretch [400c] = 0
> ODT stretch [400c] = a08b4
> REFI [4298] = 6cd11860
> SRFTP [42a4] = 41f88200
> DBP [4400] = 187999
> RAP [4404] = cc197476
> OTHP [440c] = a08b4
> ODT stretch [440c] = 0
> ODT stretch [440c] = a08b4
> REFI [4698] = 6cd11860
> SRFTP [46a4] = 41f88200
> Done dimm mapping
>
>
> For 666:
>
> Trying stored timings.
> Starting RAM training (1).
> PLL busy... PLL busy...done
> MCU frequency is set at : 666 MHz
> XOVER CLK [c14] =
> f000000
>
> XOVER CMD [320c] = 4024000
> XOVER CLK [d14] = 0
> XOVER CMD [330c] = 4000
> DBP [4000] = 146777
> RAP [4004] = ca156465
> OTHP [400c] = a0690
> ODT stretch [400c] = 0
> REFI [4298] = 5aae1450
> SRFTP [42a4] = 41f97200
> DBP [4400] = 146777
> RAP [4404] = ca156465
> OTHP [440c] = a0690
> ODT stretch [440c] = 0
> ODT stretch [440c] = a0690
> REFI [4698] = 5aae1450
> SRFTP [46a4] = 41f97200
> Done dimm mapping
>
>
> The timestamps are:
> 0:1st timestamp 1,789
> 1:start of rom stage 59,405 (57,616)
> 2:before ram initialization 1,768,793
> (1,709,388) 3:after ram initialization
> 1,818,226 (49,432) 4:end of
> romstage 1,828,566 (10,340)
> 8:starting to load ramstage 1,833,895 (5,329)
> 15:starting LZMA decompress (ignore for x86) 1,833,926 (30)
> 16:finished LZMA decompress (ignore for x86) 1,848,244
> (14,317) 9:finished loading ramstage
> 1,848,254 (9) 10:start of ramstage
> 3,186,861 (1,338,607) 30:device
> enumeration 3,186,890 (29) 40:device
> configuration 3,195,250 (8,359)
> 50:device enable 3,207,057
> (11,806) 60:device initialization
> 3,207,563 (506) 70:device setup done
> 3,378,965 (171,402) 75:cbmem
> post 3,378,968 (3) 80:write
> tables 3,378,972 (4) 90:load
> payload 3,399,267 (20,294)
> 15:starting LZMA decompress (ignore for x86) 3,399,430 (163)
> 16:finished LZMA decompress (ignore for x86) 3,413,428
> (13,998) 99:selfboot jump
> 3,413,449 (21)
>
>
> Full cbmem attached from various attempts (when I have more than 1
> stick in place, the log is truncated)
More information about the coreboot
mailing list