<div dir="ltr"><div><div><div>Ok, I found a way to get usable inteltool results: I ran inteltool -f on a borrowed W530 that has the exact same CPU 3940XM, the exact same integrated GPU (HD4000) and the exact same screen as my W520. Only the southbridge is different: QM77 instead of QM67<br><br></div>Now I will have to check the documentation of the registers to use this information to get native video init working.<br><br></div><div>Is there anything else I should run before I have to give it back??<br></div><div><br></div></div>Charlotte<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 10:06 PM, Charlotte Plusplus <span dir="ltr"><<a href="mailto:pluspluscharlotte@gmail.com" target="_blank">pluspluscharlotte@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hello<br><br></div>Yes I have included this patch 17389 in my build. Unfortunately, it  gave me the raminit logs failures attached before. I will try to see what's stored in the MRC cache. I would like to  make the ram init conditional on the boot status, which means having 2 mrc cache: one for  normal, one for fallback. This way, I flush one and  debug ram issues with less fear (because the W520 I am porting coreboot to is my main laptop)</div><div><br></div><div>For native video, I have 2 memory segments:<br></div><div>Memory at f1400000 (64-bit, non-prefetchable) [size=4M]<br>Memory at e0000000 (64-bit, prefetchable) [size=256M]<br></div><div><br></div><div>I guess I should always read from the first one. <br><br></div><div>It seems to work, but I am always getting the same result at different addresses<br>$ ./iotools mem_read32 f14C7200<br>0xf000ff53<br>$ ./iotools mem_read32 f14C7201<br>0xf000ff53<br>$ ./iotools mem_read32 f14C7202<br>0xf000ff53<br>$ ./iotools mem_read32 f14C7203<br>0xf000ff53<br>$ ./iotools mem_read32  f1400000<br></div><div>0xf000ff53<br><br></div>Here is the romstage that I tried using with non native raminit. It gave me no video, but besides that it goes to payload and work fine. I wonder if I should declare the HD4000 in the peidata. It seems the video was just not initialized at all.<br><br>For brightness in the payloads, if it cause security issues, I guess I can do  without it.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>Charlotte<br><div><div><br><br></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 7:32 AM, Nico Huber <span dir="ltr"><<a href="mailto:nico.huber@secunet.com" target="_blank">nico.huber@secunet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_7753492303309090838HOEnZb"><div class="m_7753492303309090838h5">On 16.11.2016 06:08, Charlotte Plusplus wrote:<br>
> Hello<br>
><br>
> On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber <<a href="mailto:nico.h@gmx.de" target="_blank">nico.h@gmx.de</a>> wrote:<br>
><br>
>> I've seen a garbled image, too, lately. When I built with native<br>
>> raminit by chance but with a completely different gfx init code<br>
>> (3rdparty/libgfxinit). So it might still be some problem in the<br>
>> raminit. This was also on an Ivy Bridge system with four DIMMs,<br>
>> btw. I suspected that the native raminit just wasn't tested in that<br>
>> configuration.<br>
>><br>
><br>
> Interesting, I noticed some patterns with raminit too. Most of my problems<br>
> with the native raminit happen with 4x 8Gb DIMMS. The more sticks I have,<br>
> the less likely native ram training is to succeed. I have logged a few of<br>
> the failed attempt in case anyone else is interested (attached).<br>
><br>
> Basically, the training can fail several times with the exact same<br>
> parameters that it later succeeds with. Also, failure is a function of<br>
> speed. All the attempts I have done but not attached can be summed up like<br>
> this: failure of the native ram training is also more likely with a MCU<br>
> over 666MHz. But whenever the raminit succeed, the memory is stable in<br>
> memtests (I did several passes to check.<br>
><br>
> Now that I can use Windows 10 with Coreboot, I decided to experiment a bit<br>
> more. First, I tried changing the SPD settings with Thaiphoon Burner. The<br>
> sticks I have advertise they supported both 1.35 and 1.5V profiles (SPD:<br>
> 006=03) which I feared might cause issue. Changing that to 1.5V only (SPD:<br>
> 006=00) did not help, even if it did help with another computer that I<br>
> borrowed to do some comparisons with (I was afraid my sticks were at fault)<br>
><br>
> Then I tried manually filling XMP profile 1 with known to be working values<br>
> (either published, or found during native raminit training). It seemed to<br>
> help but the results were inconsistent. Between my tests for different<br>
> value, I was clearing the MRC cache.<br>
><br>
> Then I had a weird idea: what if the ram training or the MRC cache clearing<br>
> was the cause of the problem? I changed my protocol to do: clear cache,<br>
> train after changing the SPD/MCU frequency/etc, then when it succeeds<br>
> disable the MRC cache clearing hook, and do a few reboots or a power off<br>
> before doing the memtest. And this was sufficient to get stabilility at<br>
> 666Mhz and frequencies above without having to tweak the SPD anymore (like<br>
> adding some latency to the detected values)<br>
><br>
> Currently 800Mhz is validated, I haven't tested 933 MHz because ram<br>
> training success seems to be a probability that goes down with the<br>
> frequency, and pressing on the power button every time it fails quickly<br>
> gets boring!<br>
><br>
> I have no way to prove that, but I believe that the ram training by itself<br>
> interferes with the stability of the RAM, or that there is some non<br>
> deterministic part in the code. I don't know why or how, it's a lot of code<br>
> that I haven't read in detail, but it's what my tests suggests. I would<br>
> love to compare these results to ones the blob raminit would give. But blob<br>
> raminit causes video issues. So I'm trying to focus on native video init<br>
> first, in case it helps me to use mrc.bin.<br>
<br>
</div></div>I can't recall if Patrick or you mentioned this already, there's a rela-<br>
ted patch up for review:<br>
  <a href="https://review.coreboot.org/#/c/17389/" rel="noreferrer" target="_blank">https://review.coreboot.org/#/<wbr>c/17389/</a><br>
Do you have that already applied locally?<br>
<span><br>
><br>
> Well, I don't see any setting that could really break something. The<br>
>> code might just be buggy. I'll go through the settings anyway, taking<br>
>> src/mainboard/lenovo/t520/devi<wbr>cetree.cb as example:<br>
>><br>
><br>
> I used this code as a source, as I figured the screen was likely to be the<br>
> same.<br>
><br>
> That's about ACPI, let's not care (the last appendix in the ACPI spec if<br>
>> you want to have a look).<br>
>><br>
><br>
> I will check that too because Fn Home and Fn end (brightness + and -) don't<br>
> work in memtest86, even if they work in linux and windows<br>
<br>
</span>That's expected. coreboot does the brightness control through ACPI.<br>
And ACPI is something for bloated OSs not for payloads (it comes with<br>
a whole bunch of code including a byte-code interpreter).<br>
<br>
A workaround would be to do the EC event handling in SMM until ACPI<br>
takes over. But that's usually discouraged as SMM has security issues.<br>
So we want as little code as possible in SMM.<br>
<span><br>
><br>
><br>
>> Those are real register settings, you can dump the whole GMA MMIO<br>
>> space with `inteltool -f` (hoping that your system doesn't hang). The<br>
>> registers are described in [1, chapter 2.4].<br>
>><br>
><br>
> Sorry, but it did hang.  I couldn't even ssh to it. Any alternative to get<br>
> the info?<br>
<br>
</span>Look up the base address of the gfx MMIO space:<br>
  $ lspci -vs 00:02.0 | grep Memory<br>
or<br>
  $ head -1 /sys/devices/pci0000:00/0000:0<wbr>0:02.0/resource<br>
<br>
Grab a copy of iotools: <a href="https://github.com/adurbin/iotools.git" rel="noreferrer" target="_blank">https://github.com/adurbin/iot<wbr>ools.git</a><br>
You should be able to read single registers with the mem_read32 command:<br>
  # ./iotools mem_read32 $((base+register_offset))<br>
<span class="m_7753492303309090838HOEnZb"><font color="#888888"><br>
Nico<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>