Hello
On Tue, Nov 8, 2016 at 11:30 AM, Patrick Rudolph siro@das-labor.org wrote:
Good point, I've should have mentioned that.
Well, I found out by myself the hard way after scratching my head. It is the best way to learn I suppose :-)
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.
The boot is already quite slow, around 6 seconds. cbmem -t shows about 1.5 seconds are spend at the beginning of ram init and another at the end of ramstage. I don't know if there is a way to trim that safely, but I am reluctant to add anything that will cause me to stare longer at a black screen while testing this ram stuff.
My best idea is make using mrc_cache conditional to having a reboot count <10 (or the largest value that can be held, or some impossible value that can still be stored there with nvramtool), and manually setting the reboot count with nvramtool when I want. That should be a simple workaround, if the nvram variables are accessible at this point (I have to check)
In init_dram_ddr3(), would something like that work to replace mrc_cache = find_current_mrc_cache
unsigned char byte; byte = cmos_read(RTC_BOOT_BYTE);
if (boot_count(byte) < 10) { mrc_cache = find_current_mrc_cache(); }
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.
If other vendors support passing ram parameters, why not?
At the moment I'm thinking of a nvram option like MemoryOverride: freq, tCAS, tRCD, tRP, tRAS
Why would it be an impossible interface? Just read the nvram, if you find the option, override the defaults values of ctr->tCK, ctrl->CAS, ctrl->tRCD, ctrl->tRP and ctrl->tRAS in dram_init. Do this unless the setting can't be applied by the chips.
I have no idea whether this is possible, because until about a week ago I had no idea how the ram init worked. It just seems to make sense to do it this way.
Another nice use: memtest could write to the nvram to increase the latencies when it finds error, update the reboot count to the value that would cause the update of the MRC cache, and issue a reboot. coreboot would then use these new values, and memtest would try again to see if the new setup is stable.
That would be a nice way to automate the tedious step of making the ram work.
It could also help validate ram init algorithms, since I now understand they are a bit of a black box. I mean, it's not normal that reading and applying the SPD information from my sticks results in an unstable system.
An option for a safety check should be added somewhere.
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).
I didn't know that :-( After some googling I see it was reversed. There must be no documentation so no easy way to add Ivy Bridge optimizations :-(
I think it's another good reason to have a way to interface ram setting with userland tools.
Also, XMP would require to adjust the voltage (especially for profile 2 that is currently not read), but I don't think it is done currently. Or maybe I just don't understand it. This means the information we get from reading the XMP profile, which also contains some voltage information, can not be relied upon for stability, as only half of it is applied.
Maybe using XMP should be made a config time option (with warning about stability since the voltage information is ignored, and only timings are used) until the voltages can also be applied?
I will try to run more tests to see if ignoring XMP can help me with my stability issues before I go on with the overrides.
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.
I have no way to log output at the moment. I am waiting for my FT232. All I can do I check the stability in memtest. I also prefer memtest verdict as a final arbitrator, because all that matters is stability.
You can enable raminit logging by checking "Output verbose RAM init debug messages" in menu Debugging. It doesn't work well with cbmem logging.
Already done, and indeed I have truncated lines :-(
Charlotte