[coreboot] native video init question
Charlotte Plusplus
pluspluscharlotte at gmail.com
Sun Nov 20 04:23:42 CET 2016
So I used inteltool, checked to compute the values, then even tried with
autoport.
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.
register "gfx.did" = "{ 0x80000100, 0x80000240, 0x80000410,
0x80000410, 0x00000005 }"
register "gfx.use_spread_spectrum_clock" = "1"
register "gfx.link_frequency_270_mhz" = "1"
register "gpu_dp_b_hotplug" = "4"
register "gpu_dp_c_hotplug" = "4"
# Enable DisplayPort Hotplug with 6ms pulse
register "gpu_dp_d_hotplug" = "0x06"
# Enable Panel as LVDS and configure power delays
register "gpu_panel_port_select" = "0" # LVDS
register "gpu_panel_power_cycle_delay" = "6"
register "gpu_panel_power_up_delay" = "300" # T1+T2:
30ms
register "gpu_panel_power_down_delay" = "300" # T5+T6:
30ms
register "gpu_panel_power_backlight_on_delay" = "3000" # T3: 300ms
register "gpu_panel_power_backlight_off_delay" = "3000" # T4: 300ms
#0x0c6014: 0x89046004
register "gpu_cpu_backlight" = "0x00001155"
register "gpu_pch_backlight" = "0x11551155"
Log:
PCI: 00:00.0 init ...
Disabling PEG12.
Disabling PEG11.
Disabling PEG10.
Disabling PEG60.
Disabling PEG IO clock.
Set BIOS_RESET_CPL
CPU POWER_UNIT: 8
CPU TDP: 440
CPU TDP: 55 Watts
CPU POWER_LIMIT HI: 33318
CPU POWER_LIMIT LO: 14451128
CPU POWER_LIMIT NOMINAL HI: 0
CPU POWER_LIMIT NOMIAL LO: 30
PCI: 00:00.0 init finished in 6714 usecs
PCI: 00:02.0 init ...
GT Power Management Init
IVB GT2 35W Power Meter Weights
GT Power Management Init (post VBIOS)
Initializing VGA without OPROM.
EDID:
00 ff ff ff ff ff ff 00 06 af ed 11 00 00 00 00
00 16 01 04 90 22 13 78 02 21 35 ad 50 37 aa 24
11 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 7c 38 80 d4 70 38 32 40 3c 30
aa 00 58 c1 10 00 00 18 7c 38 80 7e 72 38 32 40
3c 30 aa 00 58 c1 10 00 00 18 00 00 00 fe 00 41
55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe
00 42 31 35 36 48 54 4e 30 31 2e 31 20 0a 00 81
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 06 af ed 11 00 00 00 00 00 16
version: 01 04
basic params: 90 22 13 78 02
chroma info: 21 35 ad 50 37 aa 24 11 50 54
established: 00 00 00
standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: 7c 38 80 d4 70 38 32 40 3c 30 aa 00 58 c1 10 00 00 18
descriptor 2: 7c 38 80 7e 72 38 32 40 3c 30 aa 00 58 c1 10 00 00 18
descriptor 3: 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20
descriptor 4: 00 00 00 fe 00 42 31 35 36 48 54 4e 30 31 2e 31 20 0a
extensions: 00
checksum: 81
Manufacturer: AUO Model 11ed Serial Number 0
Made week 0 of 2012
EDID version: 1.4
Digital display
6 bits per primary color channel
Digital interface is not defined
Maximum image size: 34 cm x 19 cm
Gamma: 220%
Check DPMS levels
Supported color formats: RGB 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: 7c3880d4703832403c30aa0058c110000018
Detailed mode (IN HEX): Clock 144600 KHz, 158 mm x c1 mm
0780 07bc 07ec 0854 hborder 0
0438 0442 044c 046a vborder 0
-hsync -vsync
Did detailed timing
Hex of detail: 7c38807e723832403c30aa0058c110000018
Detailed mode (IN HEX): Clock 144600 KHz, 158 mm x c1 mm
0780 07bc 07ec 09fe hborder 0
0438 0442 044c 046a vborder 0
-hsync -vsync
Hex of detail: 000000fe0041554f0a202020202020202020
ASCII string: AUO
Hex of detail: 000000fe004231353648544e30312e31200a
ASCII string: B156HTN01.1
Checksum
Checksum: 0x81 (valid)
bringing up panel at resolution 1920 x 1080
Borders 0 x 0
Blank 212 x 50
Sync 48 x 10
Front porch 60 x 10
Spread spectrum clock
Dual channel
Polarities 1, 1
Data M1=10108272, N1=8388608
Link frequency 270000 kHz
Link M1=280785, N1=524288
Pixel N=7, M1=22, M2=8, P1=2
Pixel clock 144489 kHz
waiting for panel powerup
panel powered up
On Thu, Nov 17, 2016 at 11:54 PM, Charlotte Plusplus <
pluspluscharlotte at gmail.com> wrote:
> 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
>
> Now I will have to check the documentation of the registers to use this
> information to get native video init working.
>
> Is there anything else I should run before I have to give it back??
>
> Charlotte
>
> On Wed, Nov 16, 2016 at 10:06 PM, Charlotte Plusplus <
> pluspluscharlotte at gmail.com> wrote:
>
>> Hello
>>
>> 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)
>>
>> For native video, I have 2 memory segments:
>> Memory at f1400000 (64-bit, non-prefetchable) [size=4M]
>> Memory at e0000000 (64-bit, prefetchable) [size=256M]
>>
>> I guess I should always read from the first one.
>>
>> It seems to work, but I am always getting the same result at different
>> addresses
>> $ ./iotools mem_read32 f14C7200
>> 0xf000ff53
>> $ ./iotools mem_read32 f14C7201
>> 0xf000ff53
>> $ ./iotools mem_read32 f14C7202
>> 0xf000ff53
>> $ ./iotools mem_read32 f14C7203
>> 0xf000ff53
>> $ ./iotools mem_read32 f1400000
>> 0xf000ff53
>>
>> 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.
>>
>> For brightness in the payloads, if it cause security issues, I guess I
>> can do without it.
>>
>> Charlotte
>>
>>
>>
>> On Wed, Nov 16, 2016 at 7:32 AM, Nico Huber <nico.huber at secunet.com>
>> wrote:
>>
>>> On 16.11.2016 06:08, Charlotte Plusplus wrote:
>>> > 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.
>>>
>>> I can't recall if Patrick or you mentioned this already, there's a rela-
>>> ted patch up for review:
>>> https://review.coreboot.org/#/c/17389/
>>> Do you have that already applied locally?
>>>
>>> >
>>> > 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
>>>
>>> That's expected. coreboot does the brightness control through ACPI.
>>> And ACPI is something for bloated OSs not for payloads (it comes with
>>> a whole bunch of code including a byte-code interpreter).
>>>
>>> A workaround would be to do the EC event handling in SMM until ACPI
>>> takes over. But that's usually discouraged as SMM has security issues.
>>> So we want as little code as possible in SMM.
>>>
>>> >
>>> >
>>> >> 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?
>>>
>>> Look up the base address of the gfx MMIO space:
>>> $ lspci -vs 00:02.0 | grep Memory
>>> or
>>> $ head -1 /sys/devices/pci0000:00/0000:00:02.0/resource
>>>
>>> Grab a copy of iotools: https://github.com/adurbin/iotools.git
>>> You should be able to read single registers with the mem_read32 command:
>>> # ./iotools mem_read32 $((base+register_offset))
>>>
>>> Nico
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161119/5e7d4613/attachment.html>
More information about the coreboot
mailing list