[coreboot] More details about ram issues

[Charlotte Plusplus]

Hello

On Tue, Nov 8, 2016 at 11:30 AM, Patrick Rudolph <siro at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161108/25bbaa82/attachment-0001.html>