Re: [coreboot] native video init question
ok, Nico, let's get this done :-)
I'm reviewing pending CLs from you, you'll need to fix the builds that
broke.
native graphics init has gone through several stages in linuxbios/coreboot,
in 2000, 2001, 2003, 2012, ...
I think the stuff you're pushing is some of the best we've seen.
Keep me posted on anything you need.
Thanks
ron
On Thu, Nov 24, 2016 at 12:01 PM Nico Huber wrote:
> Hi,
>
> On 20.11.2016 21:29, ron minnich wrote:
> > I also wonder if you could use the code Nico put in for the graphics
> init.
> > I have no idea if it's possible, Nico could tell us. But that code looks
> > really thorough and might work better.
>
> I suppose, it (libgfxinit) would just work (if you get it to compile).
> It's well tested on Ivy Bridge with the MRC blob (kontron/ktqm77, roda/
> rv11, roda/rw11) and Sandy Bridge with native raminit (lenovo/t420).
>
> To compile it, you need an Ada toolchain (this is where most people run
> off). And to get it running you need several patches in coreboot that
> are still under review. Tip of the minimum for kontron/ktqm77 is [1].
>
> If anyone wants to try, the most reliable way to get the Ada toolchain
> is to install a `gnat` or `gcc-ada` package matching gcc from your dis-
> tribution. Then rebuild the coreboot toolchain with `-l c,ada -b`, e.g.
> mv util/crossgcc/xgcc{,.bak} &&
> make BUILDGCC_OPTIONS="-l c,ada -b" CPUS=8 crossgcc-i386
> and wait for an unexpected long period (the `-b` makes it slow, but it's
> more likely to succeed).
>
> Nico
>
> [1] https://review.coreboot.org/#/c/17074/
>
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] native video init question
Hi,
On 20.11.2016 21:29, ron minnich wrote:
> I also wonder if you could use the code Nico put in for the graphics init.
> I have no idea if it's possible, Nico could tell us. But that code looks
> really thorough and might work better.
I suppose, it (libgfxinit) would just work (if you get it to compile).
It's well tested on Ivy Bridge with the MRC blob (kontron/ktqm77, roda/
rv11, roda/rw11) and Sandy Bridge with native raminit (lenovo/t420).
To compile it, you need an Ada toolchain (this is where most people run
off). And to get it running you need several patches in coreboot that
are still under review. Tip of the minimum for kontron/ktqm77 is [1].
If anyone wants to try, the most reliable way to get the Ada toolchain
is to install a `gnat` or `gcc-ada` package matching gcc from your dis-
tribution. Then rebuild the coreboot toolchain with `-l c,ada -b`, e.g.
mv util/crossgcc/xgcc{,.bak} &&
make BUILDGCC_OPTIONS="-l c,ada -b" CPUS=8 crossgcc-i386
and wait for an unexpected long period (the `-b` makes it slow, but it's
more likely to succeed).
Nico
[1] https://review.coreboot.org/#/c/17074/
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] native video init question
Excellent advice from Ron. ron minnich wrote: > The timing is extremely tricky sometimes. Just to clarify - I think Ron also refers to the timing for software (coreboot) interacting with hardware (GPU registers) above, and not so much to timing for how GPU hardware interacts with the panel. The latter must obviously be correct. The point is that the former must *also* be correct, and that it is not at all obvious when such requirements exist, nor are they very well documented. //Peter -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] native video init question
I'm working from memory here, I wrote this code over 4 years ago, but I did find out there's lots of ways to get a dark panel or other issues you mention. And it's very hard sometimes to get it all right. It's also easy to have it almost working with parameters that are so wrong that getting back to a dark screen is a good sign! To add to the fun, vendors can ship any number of panels with a given laptop that are very different in behavior. We had to put 4 panel types into the falco configuration and try to figure out which one it was. One thing you can try that sometimes works, if you have serial, is to do NO video initialization at all and let X11 do it instead. I did a lot of debug this way and on ivybridge it works pretty well. You can take the normal boot path and, again assuming you have serial, start Xorg and just see if you get a lightup. If so, well, you've got a starting point: you can put debug prints in the driver to show each and everything it does to the panel, and compare to coreboot. There may be a surprise in there somewhere. The timing is extremely tricky sometimes. You could also consider running the vga bios in the 'safe' mode (i.e. the emulator in coreboot) and tracing all the IOs. Sometimes you can learn something that way. I also wonder if you could use the code Nico put in for the graphics init. I have no idea if it's possible, Nico could tell us. But that code looks really thorough and might work better. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] native video init question
Hello
The correct timings are detected by X (cf below), so I checked the
existing gma_ivybridge init and I thought it may calculate clocks
wrong.
Then I found about https://review.coreboot.org/#/c/16504/ addressing
just this, so I tried to port it to gma_ivybridge
Unfortunately I must I have done something really wrong, because I now
get no display at all.
Before:
Data M1=10108272, N1=8388608
Link frequency 27 kHz
Link M1=280785, N1=524288
Pixel N=7, M1=22, M2=8, P1=2
Pixel clock 144489 kHz
After:
Data M1=10108272, N1=8388608
Link frequency 27 kHz
Link M1=280785, N1=524288
Pixel N=2, M1=13, M2=4, P1=2
Pixel clock 144642 kHz
My patch:
--- gma_ivybridge_lvds.c2016-11-20 14:24:57.944308878 -0500
+++ gma_ivybridge_lvds.c.orig 2016-11-20 12:51:24.273120162 -0500
@@ -29,9 +29,6 @@
#include
#include
#include
-#include
-
-#define BASE_FREQUENCY 10
static void link_train(u8 *mmio)
{
@@ -142,7 +139,6 @@
int i;
u8 edid_data[128];
struct edid edid;
- u32 target_frequency;
if (!IS_ENABLED(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT))
return 0;
@@ -209,19 +205,17 @@
u32 hfront_porch = edid.mode.hso;
u32 vfront_porch = edid.mode.vso;
- u32 smallest_err = 0x;
+ u32 candp1, candn;
+ u32 best_delta = 0x;
+ u32 target_frequency = (
+ edid.mode.lvds_dual_channel ? edid.mode.pixel_clock
+ : (2 * edid.mode.pixel_clock));
u32 pixel_p1 = 1;
- u32 pixel_p2;
u32 pixel_n = 1;
u32 pixel_m1 = 1;
u32 pixel_m2 = 1;
- /* p2 divisor must 7 for dual channel LVDS */
- /* and 14 for single channel LVDS */
- pixel_p2 = edid.mode.lvds_dual_channel ? 7 : 14;
- target_frequency = edid.mode.pixel_clock;
-
vga_textmode_init();
if (IS_ENABLED(CONFIG_FRAMEBUFFER_KEEP_VESA_MODE)) {
vga_sr_write(1, 1);
@@ -249,34 +243,40 @@
write32(mmio + LGC_PALETTE(0) + 4 * i, i * 0x010101);
}
- /* Find suitable divisors, m1, m2, p1, n. */
- /* refclock * (5 * (m1 + 2) + (m1 + 2)) / (n + 2) / p1 / p2 */
- /* should be closest to target frequency as possible */
- u32 candn, candm1, candm2, candp1;
- for (candm1 = 8; candm1 <= 18; candm1++) {
- for (candm2 = 3; candm2 <= 7; candm2++) {
- for (candn = 1; candn <= 6; candn++) {
- for (candp1 = 1; candp1 <= 8; candp1++) {
- u32 m = 5 * (candm1 + 2) + (candm2 + 2);
- u32 p = candp1 * pixel_p2;
- u32 vco =
DIV_ROUND_CLOSEST(BASE_FREQUENCY * m, candn + 2);
- u32 dot = DIV_ROUND_CLOSEST(vco, p);
- u32 this_err = ABS(dot -
target_frequency);
- if ((m < 70) || (m > 120))
- continue;
- if (this_err < smallest_err) {
- smallest_err = this_err;
- pixel_n = candn;
- pixel_m1 = candm1;
- pixel_m2 = candm2;
- pixel_p1 = candp1;
- }
- }
+ /* Find suitable divisors. */
+ for (candp1 = 1; candp1 <= 8; candp1++) {
+ for (candn = 5; candn <= 10; candn++) {
+ u32 cur_frequency;
+ u32 m; /* 77 - 131. */
+ u32 denom; /* 35 - 560. */
+ u32 current_delta;
+
+ denom = candn * candp1 * 7;
+ /* Doesnt overflow for up to
+ 500 kHz = 5 GHz. */
+ m = (target_frequency * denom + 6) / 12;
+
+ if (m < 77 || m > 131)
+ continue;
+
+ cur_frequency = (12 * m) / denom;
+ if (target_frequency > cur_frequency)
+ current_delta = target_frequency -
cur_frequency;
+ else
+ current_delta = cur_frequency -
target_frequency;
+
+
+ if (best_delta > current_delta) {
+ best_delta = current_delta;
+ pixel_n = candn;
+ pixel_p1 = candp1;
+ pixel_m2 = ((m + 3) % 5) + 7;
+ pixel_m1 = (m - pixel_m2) / 5;
}
}
}
- if (smallest_err == 0x) {
+ if (best
Re: [coreboot] native video init question
Charlotte Plusplus wrote: > 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. Correct timing/sequencing is just as important as correct numbers. //Peter -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] native video init question
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" = "{ 0x8100, 0x8240, 0x8410,
0x8410, 0x0005 }"
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" = "0x1155"
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: 7c3880d4703832403c30aa0058c11018
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: 7c38807e723832403c30aa0058c11018
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: 00fe0041554f0a202020202020202020
ASCII string: AUO
Hex of detail: 00fe004231353648544e30312e31200a
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 27 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 <
pluspluscharlo...@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 <
> pluspluscharlo...@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
Re: [coreboot] native video init question
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 < pluspluscharlo...@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 f140 (64-bit, non-prefetchable) [size=4M] > Memory at e000 (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 f140 > 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 > wrote: > >> On 16.11.2016 06:08, Charlotte Plusplus wrote: >> > Hello >> > >> > On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber 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 h
Re: [coreboot] native video init question
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 f140 (64-bit, non-prefetchable) [size=4M] Memory at e000 (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 f140 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 wrote: > On 16.11.2016 06:08, Charlotte Plusplus wrote: > > Hello > > > > On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber 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
Re: [coreboot] native video init question
On 16.11.2016 06:08, Charlotte Plusplus wrote: > Hello > > On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber 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/pci:00/: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 -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] native video init question
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" = "{ 0x8100, 0x8240, 0x8410, 0x8410,
> 0x0005 }"
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
