<div dir="ltr"><div>So I used inteltool, checked to compute the values, then even tried with autoport.<br><br></div>The number match, the EDID is correct, and the panel is properly detected. But the internal display still shows a garbled picture with stretched letters. I'm out of ideas to get native video init working.<br><br> register "gfx.did" = "{ 0x80000100, 0x80000240, 0x80000410, 0x80000410, 0x00000005 }"<br> register "gfx.use_spread_spectrum_clock" = "1"<br> register "gfx.link_frequency_270_mhz" = "1"<br><br> register "gpu_dp_b_hotplug" = "4"<br> register "gpu_dp_c_hotplug" = "4"<br> # Enable DisplayPort Hotplug with 6ms pulse<br> register "gpu_dp_d_hotplug" = "0x06"<br><br> # Enable Panel as LVDS and configure power delays<br> register "gpu_panel_port_select" = "0" # LVDS<br> register "gpu_panel_power_cycle_delay" = "6"<br> register "gpu_panel_power_up_delay" = "300" # T1+T2: 30ms<br> register "gpu_panel_power_down_delay" = "300" # T5+T6: 30ms<br> register "gpu_panel_power_backlight_on_delay" = "3000" # T3: 300ms<br> register "gpu_panel_power_backlight_off_delay" = "3000" # T4: 300ms<br>#0x0c6014: 0x89046004<br> register "gpu_cpu_backlight" = "0x00001155"<br> register "gpu_pch_backlight" = "0x11551155"<br><br><br>Log:<br><br>PCI: 00:00.0 init ...<br>Disabling PEG12.<br>Disabling PEG11.<br>Disabling PEG10.<br>Disabling PEG60.<br>Disabling PEG IO clock.<br>Set BIOS_RESET_CPL<br>CPU POWER_UNIT: 8<br>CPU TDP: 440<br>CPU TDP: 55 Watts<br>CPU POWER_LIMIT HI: 33318<br>CPU POWER_LIMIT LO: 14451128<br>CPU POWER_LIMIT NOMINAL HI: 0<br>CPU POWER_LIMIT NOMIAL LO: 30<br>PCI: 00:00.0 init finished in 6714 usecs<br>PCI: 00:02.0 init ...<br>GT Power Management Init<br>IVB GT2 35W Power Meter Weights<br>GT Power Management Init (post VBIOS)<br>Initializing VGA without OPROM.<br>EDID:<br>00 ff ff ff ff ff ff 00 06 af ed 11 00 00 00 00 <br>00 16 01 04 90 22 13 78 02 21 35 ad 50 37 aa 24 <br>11 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 <br>01 01 01 01 01 01 7c 38 80 d4 70 38 32 40 3c 30 <br>aa 00 58 c1 10 00 00 18 7c 38 80 7e 72 38 32 40 <br>3c 30 aa 00 58 c1 10 00 00 18 00 00 00 fe 00 41 <br>55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe <br>00 42 31 35 36 48 54 4e 30 31 2e 31 20 0a 00 81 <br>Extracted contents:<br>header: 00 ff ff ff ff ff ff 00<br>serial number: 06 af ed 11 00 00 00 00 00 16<br>version: 01 04<br>basic params: 90 22 13 78 02<br>chroma info: 21 35 ad 50 37 aa 24 11 50 54<br>established: 00 00 00<br>standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01<br>descriptor 1: 7c 38 80 d4 70 38 32 40 3c 30 aa 00 58 c1 10 00 00 18<br>descriptor 2: 7c 38 80 7e 72 38 32 40 3c 30 aa 00 58 c1 10 00 00 18<br>descriptor 3: 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20<br>descriptor 4: 00 00 00 fe 00 42 31 35 36 48 54 4e 30 31 2e 31 20 0a<br>extensions: 00<br>checksum: 81<br><br>Manufacturer: AUO Model 11ed Serial Number 0<br>Made week 0 of 2012<br>EDID version: 1.4<br>Digital display<br>6 bits per primary color channel<br>Digital interface is not defined<br>Maximum image size: 34 cm x 19 cm<br>Gamma: 220%<br>Check DPMS levels<br>Supported color formats: RGB 4:4:4<br>First detailed timing is preferred timing<br>Established timings supported:<br>Standard timings supported:<br>Detailed timings<br>Hex of detail: 7c3880d4703832403c30aa0058c110000018<br>Detailed mode (IN HEX): Clock 144600 KHz, 158 mm x c1 mm<br> 0780 07bc 07ec 0854 hborder 0<br> 0438 0442 044c 046a vborder 0<br> -hsync -vsync <br>Did detailed timing<br>Hex of detail: 7c38807e723832403c30aa0058c110000018<br>Detailed mode (IN HEX): Clock 144600 KHz, 158 mm x c1 mm<br> 0780 07bc 07ec 09fe hborder 0<br> 0438 0442 044c 046a vborder 0<br> -hsync -vsync <br>Hex of detail: 000000fe0041554f0a202020202020202020<br>ASCII string: AUO<br>Hex of detail: 000000fe004231353648544e30312e31200a<br>ASCII string: B156HTN01.1 <br>Checksum<br>Checksum: 0x81 (valid)<br>bringing up panel at resolution 1920 x 1080<br>Borders 0 x 0<br>Blank 212 x 50<br>Sync 48 x 10<br>Front porch 60 x 10<br>Spread spectrum clock<br>Dual channel<br>Polarities 1, 1<br>Data M1=10108272, N1=8388608<br>Link frequency 270000 kHz<br>Link M1=280785, N1=524288<br>Pixel N=7, M1=22, M2=8, P1=2<br>Pixel clock 144489 kHz<br>waiting for panel powerup<br>panel powered up<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 11:54 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>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??<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div><span class="HOEnZb"><font color="#888888">Charlotte<br></font></span></div><div class="HOEnZb"><div class="h5"><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="m_-1637269859220962756HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-1637269859220962756HOEnZb"><font color="#888888"><div><br></div>Charlotte<br><div><div><br><br></div></div></font></span></div><div class="m_-1637269859220962756HOEnZb"><div class="m_-1637269859220962756h5"><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_-1637269859220962756m_7753492303309090838HOEnZb"><div class="m_-1637269859220962756m_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_-1637269859220962756m_7753492303309090838HOEnZb"><font color="#888888"><br>
Nico<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>