skylake/kabylake: no register access

[atomozero]

When I try to EFI boot the beta 3 it gets stuck at the last icon

the laptop have ‎NVIDIA GeForce MX150 end Intel Corei7 8a

[atomozero]

Intel_extreme: CALLED status_t init_hardware() devfs: "intel_810" api_versione missing i810: init_hardware() - no supported devices

[rudolfc]

Hi! So it looks like VESA is in use, not the intel_extreme driver. Can you enter the bootmenu and see what modes are listed there? if you have choices there, select one and continue the boot to see what happens. You could also try 'use failsafe graphics driver' from the bootmenu to see if that makes a difference.

If you have a succesfull boot, please upload the resulting /var/log/syslog to the ticket for extra info.

Is it possible to boot a 32bit version of Haiku on that system? If so, what happens? Can you access the bootmenu there and see what modes are offered to you here? that might be different from a 64bit version, at least I think I saw that over here a few times.

Good luck with testing!

[atomozero]

On My laptop i cant boot a 32bit version :(

[atomozero]

In attachments the screenshot on failsafe graphics driver

[atomozero]

:( dont work Revision 55684

[atomozero]

Syslog haiku-master-hrev55684-x86_64-anyboot

[rudolfc]

Thanks! Your panel isn't detected by the driver unfortunately, and I saw that some register seem to not been mapped. This might be a hint your laptop uses some power management shutting off parts of the Intel graphics card. Would you maybe have the option to set some power settings in the BIOS, connect mains power to it? I assume at least that the intel gfx card has been set as primary card in the BIOS (?)

I will do some searching in documentation to see if I can find a hint for manually enabling some powerwells.

[rudolfc]

BTW Also the GART driver has a 'unmappable' output text, which I did not see before..

[rudolfc]

Oh BTW, if you are able to set the desktop in the same resolution as the booticons screen is in, I expect you have a desktop with the intel_extreme driver, where you cannot set other modes succesfully, apart from colordepth and virtual size. This is the effect if no screen is detected.

[atomozero]

syslog with the laptop powered on

[atomozero]

the bios option

[atomozero]

the bios does not allow me to set the video card :(

The resolution I see in haiku boot is the same one that works for me in windows 3000x2000, but even lower resolutions give me the same result that hangs at the last icon

[rudolfc]

Hello again, Can you please upload a devices list? (type listdev in terminal). I need the exact ID's from the graphics card. I just found out that on newer cards an extra port was added. If you have that, I'll attempt to scan that port too in the driver :-) Might be the panel sits there..

[atomozero]

but I cannot complete the boot. is there any way to do this without completing the boot?

:(

in safe mode it enters kdl

[atomozero]

info nvidia

[rudolfc]

Perfect, thank you! ;-) (Kabylake Mobile GT2, ID = 0x5917)

You should have that extra port. Updating driver as we speak..

[rudolfc]

Hi, please try hrev55689: it has that extra port added. Hopefully your panel is indeed sitting there :-)

Please upload a new syslog along with your observations, thank you in advance..

[atomozero]

as soon as the nightly is available I try it now. however it goes thanks a lot :)

[rudolfc]

Hi, perfect. Another update done: hrev55690 You'll get that with the next nightly at once. In the meantime I found out that post skylake systems have more differences than was expected: the PLLs are different again, which could be the explanation for the trouble on external screens for a lot of people, and maybe also for your screen.

Anyhow, each update gets us closer to a correctly working system ;-)

[atomozero]

hrev55692 - syslog

[atomozero]

hrev55692 - screen 1

[atomozero]

hrev55692 - screen 2

[rudolfc]

Hmm, the extra port is scanned, but is also not connected unfortunately. I'll search more, hopefully I can think of something usefull here..

[rudolfc]

BTW van you tell me what your screen's native mode is?

[atomozero]

I think 3000x2000, work fine on Windows :)

[rudolfc]

Would you happen to have documentation on it?

[rudolfc]

Oh, maybe you can fetch it from windows as well, look at the screen properties there..

[atomozero]

if you need any specific data, just ask. I try to track it down

[rudolfc]

Interesting, high res!. What laptop do you have exactly if I may ask? (I'll look up the specs, hope to find more details on things)..

[atomozero]

Huawei Matebook Mach-W19

​https://consumer.huawei.com/en/laptops/matebook-x-pro-2019/specs/ ​https://en.wikipedia.org/wiki/Huawei_MateBook_X_Pro ​https://awesomeopensource.com/project/nekr0z/linux-on-huawei-matebook-13-2019 ​http://blog.ruanxiang.net/blog/2019/04/19/linux-on-huawei-matebook-x-pro/

[korli]

It's annoying that the syslog gets truncated with <DROP>. the boot beginning is always missing.

[atomozero]

can I do something to keep it from being truncated?

[korli]

maybe you can check with on-screen debug log to see how much it is until the data is logged in syslog. Important is the EDID data that the bootloader finds.

@waddlesplash any idea?

[waddlesplash]

You can try increasing the syslog buffer size in the kernel settings file.

[atomozero]

syslog complete hrev55692

[rudolfc]

thanks for the log. From the looks of it the gfx hardware isn't accessible. I see the kerneldriver hitting unknown ref freq( all '1's found), and we also see this in the accelerant (Reg dump in the beginning, but also the scaler setup by BIOS part, I don't trust both being setup (all '1's).

@korli would you have an idea? Is something wrong with memory mapping maybe?

[atomozero]

hrev55848 Screen debug 1

[atomozero]

I do not have the possibility to attach the syslog but it seems to me that with the hrev55848 something has changed, I have attached two photos :)

[rudolfc]

The driver is developing further indeed. Since your hardware isn't responding yet the driver can't actually do something usefull I'm afraid. Though if your UEFI BIOS lets Haiku know some VESA info the driver will pick it up these days (if you run a new enough nightly that is).

The latest driver I posted seperately in ticket #17350 for testing there, you could try to install that to see if you at least get a screen in the mode you are starting with, but I guess chances are still slim it works for you.

https://dev.haiku-os.org/attachment/ticket/17350/eDP_sandyIvy_hrev55875_x64.zip

Also, it might be if you install the driver (you are running 64bit I am assuming?) in the unpackaged user hierarchy the system won't pick it up as on UEFI systems this still is a problem. In that case you'd have to run a totally unpacked system and place the driver in the system hierarchy.

A current nightly would also contain the driver, but unfortunately these are currently not generated it seems..

[atomozero]

maybe new driver

[atomozero]

sorry i am not sure i put it in the right folder

i put both files in system/non-packaged/add-ons/kernel/drivers/bin

thx :)

[korli]

proposed change ​https://review.haiku-os.org/c/haiku/+/4978

if the bios doesn't power up the intel graphics but only the nvidia, this could help.

[rudolfc]

Sounds nice! If it has no expected downside other than a bit of power drain I would say apply it :-)

Would this be ok like this for all generations?

[korli]

yes, it only has an effect for PCI devices with PM capability.

[korli]

patched in hrev55897. please provide a syslog for hrev55897 or newer.

[rudolfc]

hi atomozero, the nightly for that hrev55897 is there in the meantime: could you first test that instead of a custom installed driver? It's interesting to see if this power-up code would let your card be accessible..

For the drivers in user unpackaged it would be:

• accelerant in: home/config/non-packaged/add-ons/accelerants/
• kerneldriver in: home/config/non-packaged/add-ons/kernel/drivers/bin/
• shortcut to kerneldriver in: home/config/non-packaged/add-ons/kernel/drivers/dev/graphics/

On non UEFI systems this works, so takes precedence over the (read-only) system hierarchy.

On UEFI AFAIK you need to create a completely unpackaged system, and then you can overwrite the system driver and accelerant: same sort of setup as just described for the user unpackaged thing (but without non-packaged, and in system instead of home)

Please upload a syslog again after you test the current nightly and if you want the driver I pointed you to as well: but nightly should take precedence ;-)

Thank you!

[atomozero]

Syslog hrev55898 no news :(

[rudolfc]

Thanks for the dump: still no access to the card's registers.

@korli, can you see in the log if the right version is running here, concerning the power-up patch you suggested here?

Thanks a lot!

[korli]

@rudolfc hrev55898 seems to be the right version. The power-up patch didn't help it seems.

[rudolfc]

Hello again, can you please test hrev55928 or later? If all is right your internal panel should now be recognized so with a bit of luck you should be able to boot to the desktop now, though modesetting still doesn't work. On a fresh nightly I mean.

Can you upload a new syslog from the attempt?

Thank you!

[atomozero]

syslog hrev55942 :( no news guys

[rudolfc]

Hello, The intel graphics driver is loaded (see halfway the syslog) and it doesn't have access to the registers of the graphics card. The BIOS did setup ACPI info listing the cardtype and a panel of 1024x768 which I am assuming is -not- the resolution of your panel.

• which native resolution does your laptop panel have?
• can you try changing the selection on which card gets booted a few times (BIOS and seperate try via keyboard shortcuts if possible: can you also fully disable the nvidia card for instance?)

Another user also did not have register access up in the driver, but somehow that suddenly works over there. It would be interesting to find which trick did it and if it would work for you as well. Though you'd still have the wrong panel info there probably, it would mean a big step forward I think.

For your info see here: https://dev.haiku-os.org/ticket/17632#comment:14

Hope I make sense here.. Thanks for trying!

[atomozero]

Native resolution

[atomozero]

Unfortunately from the bios I can only select from which disk I can boot :( thank you for your time :)

[rudolfc]

New test: can you instruct your BIOS to block above 4G (PCIe) memory use? and if you enable that blocking setting and boot Haiku, can you upload a syslog from the attempt?

Note that blocking this in the bootoptions from Haiku's bootmenu alone seems not enough..

The above is new info from the other ticket that just came up!

[atomozero]

this is the maximum I can edit from the bios

[rudolfc]

Hmm, oke, nothing to test then, maybe apart from trying the bootoption from haiku to ignore above 4G if it's there. Are you running 32 or 64bit btw?

[rudolfc]

looks like I have an update for you tonight. I am currently testing with both the intel_gart and intel_extreme driver modified and indeed detecting 64-bit BARs for register access and framebuffer access, which on my systems both map in the lower 32bit range, but I guess that for some users this is not the case, like you.

Once I have committed this change, I'll inform you here..

[rudolfc]

Hmm, and I'm bypassed I see ;-) You can check tommorrow's nighty as Jerome Duval just added the same extensions as I did.

please test hrev55946 or later and upload a new syslog!

Thank you :-)

[korli]

hey rudolf, I noticed radeon_hd and intel_extreme weren't up to date with 64-bit handling. I have an intel system with such 64-bit BARs, but the device isn't yet supported anyway.

[rudolfc]

Funny we were working on the same thing at the same time. I think it's another good sign that Haiku is developing faster and faster :-)

So, while we did double work, it was still interesting to learn more about this. Indeed I saw on skylake and ivybridge that both register and framebuffer have 64bit bars, while generation 3 still uses 32bit types. This will no doubt help close tickets :-)

[korli]

hi rudolf, glad it's ok. I'm testing with jasperlake graphics, it's working now with 64-bit handling, without changes in the accelerant. It doesn't find the VBT though (it's not in the opregion it seems, checked on Linux). I'll commit the IDs, and send a syslog for you to see.

[atomozero]

syslog hrev55954 - Big News :)

[atomozero]

Screenshot hrev55954

[atomozero]

only problem encountered, the desktop is displayed only in a rectangle with respect to the entire screen

[atomozero]

hrev56001 works!!! full native resolution 3000x2000! thx!

[atomozero]

if I try to pass resolutions different from the native one I am presented with this situation

[korli]

nice to know. Please upload a syslog.

[korli]

Thanks. What happens with smaller resolutions? I see in "hrev56095 syslog Intel Driver" a set_display_mode with 1920x1080 instead of 3000x2000.

[atomozero]

I immediately try the smaller resolutions, I have attached the two images because in native mode there is no 1920x1440 resolution. The 3000x2000 version is great, but failing to scale the applications makes the system unusable. The 1920X1200 resolution is squashed and not very pleasant to use.

[atomozero]

lower resolutions work fine

[atomozero]

on the fifth resolution change Haiku was not happy, but it worked