[coreboot] native video init question

Charlotte Plusplus pluspluscharlotte at gmail.com
Wed Nov 16 06:08:03 CET 2016


Hello

On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber <nico.h at gmx.de> wrote:

> I've seen a garbled image, too, lately. When I built with native
> raminit by chance but with a completely different gfx init code
> (3rdparty/libgfxinit). So it might still be some problem in the
> raminit. This was also on an Ivy Bridge system with four DIMMs,
> btw. I suspected that the native raminit just wasn't tested in that
> configuration.
>

Interesting, I noticed some patterns with raminit too. Most of my problems
with the native raminit happen with 4x 8Gb DIMMS. The more sticks I have,
the less likely native ram training is to succeed. I have logged a few of
the failed attempt in case anyone else is interested (attached).

Basically, the training can fail several times with the exact same
parameters that it later succeeds with. Also, failure is a function of
speed. All the attempts I have done but not attached can be summed up like
this: failure of the native ram training is also more likely with a MCU
over 666MHz. But whenever the raminit succeed, the memory is stable in
memtests (I did several passes to check.

Now that I can use Windows 10 with Coreboot, I decided to experiment a bit
more. First, I tried changing the SPD settings with Thaiphoon Burner. The
sticks I have advertise they supported both 1.35 and 1.5V profiles (SPD:
006=03) which I feared might cause issue. Changing that to 1.5V only (SPD:
006=00) did not help, even if it did help with another computer that I
borrowed to do some comparisons with (I was afraid my sticks were at fault)

Then I tried manually filling XMP profile 1 with known to be working values
(either published, or found during native raminit training). It seemed to
help but the results were inconsistent. Between my tests for different
value, I was clearing the MRC cache.

Then I had a weird idea: what if the ram training or the MRC cache clearing
was the cause of the problem? I changed my protocol to do: clear cache,
train after changing the SPD/MCU frequency/etc, then when it succeeds
disable the MRC cache clearing hook, and do a few reboots or a power off
before doing the memtest. And this was sufficient to get stabilility at
666Mhz and frequencies above without having to tweak the SPD anymore (like
adding some latency to the detected values)

Currently 800Mhz is validated, I haven't tested 933 MHz because ram
training success seems to be a probability that goes down with the
frequency, and pressing on the power button every time it fails quickly
gets boring!

I have no way to prove that, but I believe that the ram training by itself
interferes with the stability of the RAM, or that there is some non
deterministic part in the code. I don't know why or how, it's a lot of code
that I haven't read in detail, but it's what my tests suggests. I would
love to compare these results to ones the blob raminit would give. But blob
raminit causes video issues. So I'm trying to focus on native video init
first, in case it helps me to use mrc.bin.

Well, I don't see any setting that could really break something. The
> code might just be buggy. I'll go through the settings anyway, taking
> src/mainboard/lenovo/t520/devicetree.cb as example:
>

I used this code as a source, as I figured the screen was likely to be the
same.

That's about ACPI, let's not care (the last appendix in the ACPI spec if
> you want to have a look).
>

I will check that too because Fn Home and Fn end (brightness + and -) don't
work in memtest86, even if they work in linux and windows


> Those are real register settings, you can dump the whole GMA MMIO
> space with `inteltool -f` (hoping that your system doesn't hang). The
> registers are described in [1, chapter 2.4].
>

Sorry, but it did hang.  I couldn't even ssh to it. Any alternative to get
the info?

> Hope that helps,

Yes it does!!! Thank you!! That gives me various pointers for various
things to try!!

Thanks,
Charlotte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161116/06d4c668/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raminit-fail-4sticks-800.gz
Type: application/x-gzip
Size: 84296 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161116/06d4c668/attachment-0003.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raminit-works-4sticks-666.gz
Type: application/x-gzip
Size: 95337 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161116/06d4c668/attachment-0004.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raminit-works-4sticks-800.gz
Type: application/x-gzip
Size: 340781 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161116/06d4c668/attachment-0005.gz>


More information about the coreboot mailing list