Hi, On 14.11.2016 06:43, Charlotte Plusplus wrote: > Hello > > Here is the current status of my W520: > - native video init gives a garbled image (picture available upon request > lol). it may be due to the resolution of the screen being hardcoded > somewhere, or more likely me using the wrong information since the W520 > uses 1980x1080 > - non native video works fine
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. > - with native ram init, the memory tends to be unstable unless great care > is used (basically blindly increasing SPD latencies and setting > max_mem_clock_mhz=666) > - with native ram init, even with that sometimes the boots stop on: > "discover timC write: > CPB > t123: 1048, 6000, 7620" > - with non native ram init, there is no video > - various dmaerr unless iommu is disabled > - the USB3 controller is not showing in lscpi, even if I am quite sure it > is on the right PCIE (likely due to the RCBA32 I am using) > - the modem codec is not detected by snd-hda-intel even if the probe is > forced > - some other unknown things may not work. > > At the moment, I am trying to advance with native video first as it is a > low hanging fruit: I'm quite sure the gfx.did or LVDS settings in my > devicetree must be wrong. > > How can I guess the right ones after booting with the videorom? 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: > # IGD Displays > register "gfx.ndid" = "3" > register "gfx.did" = "{ 0x80000100, 0x80000240, 0x80000410, 0x80000410, > 0x00000005 }" That's about ACPI, let's not care (the last appendix in the ACPI spec if you want to have a look). > # Enable DisplayPort Hotplug with 6ms pulse > register "gpu_dp_d_hotplug" = "0x06" Not native gfx init related, I wonder why the firmware should set this at all. > # Enable Panel as LVDS and configure power delays > register "gpu_panel_port_select" = "0" # LVDS > register "gpu_panel_power_cycle_delay" = "5" > 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" = "2000" # T3: 200ms > register "gpu_panel_power_backlight_off_delay" = "2000" # T4: 200ms 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]. > register "gfx.use_spread_spectrum_clock" = "1" This is set in DPLL_CTL bits 15:13 (there are two registers, just boot with only the internal display and read the first register, 0xc6014 [1, 2.3.1]). > register "gfx.link_frequency_270_mhz" = "1" This setting is only documented for Nehalem ([3, 2.10.1] the lowest 8 bits). Linux always assumes 270MHz for Sandy/Ivy Bridge (which con- tradicts our setting for the MacBookAir4,2 but that might be wrong). > register "gpu_cpu_backlight" = "0x1155" Just wrong see [2, chapter 3.9.2], it must not be higher than the up- per 16 bits in the next register. > register "gpu_pch_backlight" = "0x06100610" The upper 16 bits give a divisor for the backlight PWM [1, 2.5.2]. The lower give the duty cycle, iff bit30 of register 0xc8250 is set, which we do not set (i.e. the gpu_cpu_backlight value above is in charge). So the lower 16 bits can be just zero. Hope that helps, Nico [1] https://01.org/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf [2] https://01.org/sites/default/files/documentation/ivb_ihd_os_vol3_part3.pdf [3] https://01.org/sites/default/files/documentation/ilk_ihd_os_vol3_part2r2.pdf -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot