Hi all, I own an Acer Aspire VN7-572G and have not been impressed with its OEM firmware. After discovering that it does not utilise Intel's Boot Guard technology, that several Skylake and Kabylake laptops (it has a Skylake chip, but I read that the platforms are similar) have received successful coreboot ports and reading the porting guide on the wiki, I figured that I could give porting coreboot to my laptop a shot. When I was done, I figured that I had an image that might boot so I flashed it to my laptop with a Raspberry Pi and a SOIC clip. However, here's what it does: a) It powers on quietly, as expected; b) The backlight and power LED light up; c) The fans spin up to high and then it stays that way. It does nothing else. The display is dark too. After 15 minutes and a second attempt, I figured that I could no longer blame anything on a long first boot-up and gave up and flashed back to stock. Now, in all honesty I should have tried first without cleaning Intel ME but I find it so much more likely that I did something wrong than that cleaning ME was the sole problem. Can anyone advise me on how to continue? My code is here: https://github.com/benjamindoron/coreboot
On Mon, Sep 02, 2019 at 02:50:15PM +1000, Benjamin Doron wrote:
c) The fans spin up to high and then it stays that way. It does nothing else. The display is dark too.
The display is approximately the last thing you'll get to work. Find yourself some serial console connection to use (I think RasPis can be used as EHCI debug port device) or use our flash console feature (which might be less reliable, so this should be a backup or last resort option) to figure out how far coreboot gets.
Now, in all honesty I should have tried first without cleaning Intel ME but I find it so much more likely that I did something wrong than that cleaning ME was the sole problem.
Tampering with the ME firmware certainly won't help ;-)
Can anyone advise me on how to continue? My code is here: https://github.com/benjamindoron/coreboot
I don't have more to add, except wishing you good luck with your endeavour :-)
Patrick
PS: Your follow-up email with a coreboot binary ended up in the moderation queue and I rejected it: Please be mindful about user's mailboxes before broadcasting a multi-megabytes image to the world :-)
Hi Benjamin,
On Mon, Sep 2, 2019 at 1:31 PM Patrick Georgi via coreboot coreboot@coreboot.org wrote:
On Mon, Sep 02, 2019 at 02:50:15PM +1000, Benjamin Doron wrote:
c) The fans spin up to high and then it stays that way. It does nothing else. The display is dark too.
The display is approximately the last thing you'll get to work. Find yourself some serial console connection to use (I think RasPis can be used as EHCI debug port device) or use our flash console feature (which might be less reliable, so this should be a backup or last resort option) to figure out how far coreboot gets.
coreboot can also use a FTDI FT232H or FT2232H USB board to output debug logs via usbdebug. Note that they must be FT232*H*, and not FT232*R*, for it to work. You would also need an USB to UART (not RS232) adapter to connect the FTDI board to a computer to actually read the log.
Now, in all honesty I should have tried first without cleaning Intel ME but I find it so much more likely that I did something wrong than that cleaning ME was the sole problem.
Tampering with the ME firmware certainly won't help ;-)
Indeed. This can cause bugs that nobody knows why they would happen. For instance, the ME configures clocking-related parameters, which it might not do when its firmware is crippled by e.g. me_cleaner. This can cause lots of weird bugs, such as the LPC bus not working.
Can anyone advise me on how to continue? My code is here: https://github.com/benjamindoron/coreboot
I don't have more to add, except wishing you good luck with your endeavour :-)
I see this is a Skylake laptop... Laptops are usually harder to port because of the limited debug capabilities and the custom and usually undocumented embedded controller (referred to as EC). I would suggest trying to find documentation for your mainboard (schematics and boardviews are the most useful resources) on the Internet.
You should know that coreboot on Skylake uses a FSP binary. I see you're using the older FSP 1.1, I would suggest using the Kaby Lake FSP 2.0 (compatible with Skylake) since more people know about / use it (harder to run into unknown bugs).
I would recommend using coreboot's Gerrit code collaboration tool [1] to work on your board port, as it's much easier (at least for me) to suggest modifications on there. Plus, changes get merged through Gerrit, so having your change there is already a step forward :)
You are now probably wondering how to do that. It should be explained in [2].
[1]: https://review.coreboot.org/ [2]: https://doc.coreboot.org/lessons/lesson2.html
Patrick
Best regards,
Angel
PS: Your follow-up email with a coreboot binary ended up in the moderation queue and I rejected it: Please be mindful about user's mailboxes before broadcasting a multi-megabytes image to the world :-)
I think it's easier to review coreboot source code than binary coreboot images :D
Hi, I built another binary with FSP 2.0, Intel ME untouched and logging to the SPI chip enabled. I observed the same behaviour as before, except now the fans don't spin up to "high." I hadn't realised that FSP 2.0 could be used Skylake. Nice of Intel to make two distinct, retail architectures so similar and even nicer of them not to document this fact on their Github page. :-)
I tested the Intel ME theory with a cleaned, mostly-stock OEM BIOS and got the original behaviour: fans on high, no display, so I suppose that I can't consider cleaning ME just yet.
The log that I extracted seems too short: "strings" lists additional lines with timestamps. How can I properly extract these? I currently only have the log of the bootblock, attaching below.
PS: Your follow-up email with a coreboot binary ended up in the moderation queue and I rejected it: Please be mindful about user's mailboxes before broadcasting a multi-megabytes image to the world :-)
Right, sorry.
I think it's easier to review coreboot source code than binary coreboot images :D
Yeah, I don't know what I was thinking.
I would recommend using coreboot's Gerrit code collaboration tool [1] to
work on
your board port, as it's much easier (at least for me) to suggest
modifications
on there. Plus, changes get merged through Gerrit, so having your change
there
is already a step forward :)
It's certainly not complete, so how could it belong? Thanks, Benjamin Doron
On Tue, Sep 3, 2019 at 1:01 AM Angel Pons th3fanbus@gmail.com wrote:
Hi Benjamin,
On Mon, Sep 2, 2019 at 1:31 PM Patrick Georgi via coreboot coreboot@coreboot.org wrote:
On Mon, Sep 02, 2019 at 02:50:15PM +1000, Benjamin Doron wrote:
c) The fans spin up to high and then it stays that way. It does nothing else. The display is dark too.
The display is approximately the last thing you'll get to work. Find yourself some serial console connection to use (I think RasPis can be used as EHCI debug port device) or use our flash console feature (which might be less reliable, so this should be a backup or last resort option) to figure out how far coreboot gets.
coreboot can also use a FTDI FT232H or FT2232H USB board to output debug logs via usbdebug. Note that they must be FT232*H*, and not FT232*R*, for it to work. You would also need an USB to UART (not RS232) adapter to connect the FTDI board to a computer to actually read the log.
Now, in all honesty I should have tried first without cleaning Intel
ME but
I find it so much more likely that I did something wrong than that
cleaning
ME was the sole problem.
Tampering with the ME firmware certainly won't help ;-)
Indeed. This can cause bugs that nobody knows why they would happen. For instance, the ME configures clocking-related parameters, which it might not do when its firmware is crippled by e.g. me_cleaner. This can cause lots of weird bugs, such as the LPC bus not working.
Can anyone advise me on how to continue? My code is here: https://github.com/benjamindoron/coreboot
I don't have more to add, except wishing you good luck with your endeavour :-)
I see this is a Skylake laptop... Laptops are usually harder to port because of the limited debug capabilities and the custom and usually undocumented embedded controller (referred to as EC). I would suggest trying to find documentation for your mainboard (schematics and boardviews are the most useful resources) on the Internet.
You should know that coreboot on Skylake uses a FSP binary. I see you're using the older FSP 1.1, I would suggest using the Kaby Lake FSP 2.0 (compatible with Skylake) since more people know about / use it (harder to run into unknown bugs).
I would recommend using coreboot's Gerrit code collaboration tool [1] to work on your board port, as it's much easier (at least for me) to suggest modifications on there. Plus, changes get merged through Gerrit, so having your change there is already a step forward :)
You are now probably wondering how to do that. It should be explained in [2].
Patrick
Best regards,
Angel
PS: Your follow-up email with a coreboot binary ended up in the moderation queue and I rejected it: Please be mindful about user's mailboxes before broadcasting a multi-megabytes image to the world :-)
I think it's easier to review coreboot source code than binary coreboot images :D
The log that I extracted seems too short: "strings" lists additional lines with timestamps.
On second thought, I probably didn't see any of these. In that case, I suppose that it's romstage code that is the issue?
And alternatively, it's the FSP. I don't know how that's supposed to work, but maybe I misconfigured it or maybe I should have used its cache-as-RAM feature (FSP-T? I forgot what it was called in the menu).
For some reason, the console log that I attempted to attach did not seem to reach the list. I'll paste it here:
"coreboot-4.10-528-g809b7513a2-2.0-beta1 Mon Sep 2 20:08:20 UTC 2019 bootblock starting (log level: 7)... CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz CPU: ID 406e3, Skylake D0, ucode: 000000cb CPU: AES supported, TXT NOT supported, VT supported MCH: device id 1904 (rev 08) is Skylake-U PCH: device id 9d48 (rev 21) is Skylake-U Premium IGD: device id 1916 (rev 07) is Skylake ULT GT2 misccfg_mask:fff000ff misccfg_value:43200 CBFS: 'Master Header Locator' located CBFS at [270200:800000) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size b3cc" (many null characters follow, but this is the end of the log)
I looked into FSP-T (TempRamInit on FSP 2.0) and apparently it does not support Skylake. That shouldn't be a problem, I've seen some laptops supported by coreboot using its 'common' cache-as-RAM, but it made me more certain that it's my romstage code at fault (FSP-T isn't needed, coreboot works on these laptops, etc).
I ended up investigating romstage.c + pei_data.c vs only romstage.c to discover that the former was deprecated and that ultimately, the code that I had been using for romstage.c with FSP 2.0 may have been a leftover from when I had been trying to use FSP 1.1. I'll paste a diff below in case it helps/anyone is interested.
"--- thenromstage.c 2019-09-18 15:18:13.165824532 +1000 +++ romstage.c 2019-09-17 19:26:56.417327000 +1000 @@ -16,12 +16,12 @@ * GNU General Public License for more details. */
-#include <string.h> #include <assert.h> #include <soc/romstage.h> #include <spd_bin.h> +#include <string.h>
-static void mainboard_fill_dq_map_data(void *dq_map_ch0, void *dq_map_ch1) +static void mainboard_fill_dq_map_data(void *dq_map_ptr) { /* DQ byte map */ const u8 dq_map[2][12] = { @@ -29,18 +29,16 @@ 0x0F, 0x00, 0xFF, 0x00, 0xFF, 0x00 }, { 0x33, 0xCC, 0x00, 0xCC, 0x33, 0xCC, 0x33, 0x00, 0xFF, 0x00, 0xFF, 0x00 } }; - memcpy(dq_map_ch0, dq_map[0], sizeof(dq_map[0])); - memcpy(dq_map_ch1, dq_map[1], sizeof(dq_map[1])); + memcpy(dq_map_ptr, dq_map, sizeof(dq_map)); }
-static void mainboard_fill_dqs_map_data(void *dqs_map_ch0, void *dqs_map_ch1) +static void mainboard_fill_dqs_map_data(void *dqs_map_ptr) { /* DQS CPU<>DRAM map */ const u8 dqs_map[2][8] = { { 0, 1, 3, 2, 4, 5, 6, 7 }, { 1, 0, 4, 5, 2, 3, 6, 7 } }; - memcpy(dqs_map_ch0, dqs_map[0], sizeof(dqs_map[0])); - memcpy(dqs_map_ch1, dqs_map[1], sizeof(dqs_map[1])); + memcpy(dqs_map_ptr, dqs_map, sizeof(dqs_map)); }
static void mainboard_fill_rcomp_res_data(void *rcomp_ptr) @@ -70,10 +68,8 @@ dump_spd_info(&blk); assert(blk.spd_array[0][0] != 0);
- mainboard_fill_dq_map_data(&mem_cfg->DqByteMapCh0, - &mem_cfg->DqByteMapCh1); - mainboard_fill_dqs_map_data(&mem_cfg->DqsMapCpu2DramCh0, - &mem_cfg->DqsMapCpu2DramCh1); + mainboard_fill_dq_map_data(&mem_cfg->DqByteMapCh0); + mainboard_fill_dqs_map_data(&mem_cfg->DqsMapCpu2DramCh0); mainboard_fill_rcomp_res_data(&mem_cfg->RcompResistor); mainboard_fill_rcomp_strength_data(&mem_cfg->RcompTarget); "
While I unfortunately can't test anything for the moment because my Pi is out of commission, I'll reconfigure the devicetree based on values extracted from the OEM's BIOS and hope that this gets me a somewhat working port.
Angel, the link you sent is unavailable now, but is the gist of it that I attempt to commit and Gerrit automatically puts it into review?
Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where the link was moved?
Benjamin Doron benjamin.doron00@gmail.com schrieb am Mi., 18. Sep. 2019, 12:34:
Angel, the link you sent is unavailable now, but is the gist of it that I attempt to commit and Gerrit automatically puts it into review?
Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where the link was moved?
Yes, that's the same document.
Hi Benjamin,
Yes, the link was moved there the other day.
Best regards,
Angel
On Wed, Sep 18, 2019, 12:34 Benjamin Doron benjamin.doron00@gmail.com wrote:
Angel, the link you sent is unavailable now, but is the gist of it that I attempt to commit and Gerrit automatically puts it into review?
Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where the link was moved? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Sorry, I'll commit this instead of continuing to post here but I thought that I should add that the diff is useless too.
On Wed., 18 Sep. 2019, 8:40 pm Angel Pons, th3fanbus@gmail.com wrote:
Hi Benjamin,
Yes, the link was moved there the other day.
Best regards,
Angel
On Wed, Sep 18, 2019, 12:34 Benjamin Doron benjamin.doron00@gmail.com wrote:
Angel, the link you sent is unavailable now, but is the gist of it that I attempt to commit and Gerrit automatically puts it into review?
Also, would this (https://doc.coreboot.org/tutorial/part2.html) be where the link was moved? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi again, I've been working on this over at https://review.coreboot.org/c/coreboot/+/35523 and I've found that Tianocore doesn't seem to be logging (or doesn't start, but there's no error, so there's no reason to assume that) and SeaBIOS crashed for me. Without a display, how can I find out where my computer's up to?
I'm assuming that if it managed to get into grub (EFI image from Fedora) and then Linux, it would get the display/network up. I could find out if the network is online by checking my router.
Alternatively, how would I get the display working?
Do you have an EHCI debug dongle, like USB FT232H? If enabled at coreboot's config, it could be plugged into a USB port (usually 2.0) and will be printing a coreboot boot log to another computer.
On Wed, Sep 25, 2019 at 7:19 PM Benjamin Doron benjamin.doron00@gmail.com wrote:
Hi again, I've been working on this over at https://review.coreboot.org/c/coreboot/+/35523 and I've found that Tianocore doesn't seem to be logging (or doesn't start, but there's no error, so there's no reason to assume that) and SeaBIOS crashed for me. Without a display, how can I find out where my computer's up to?
I'm assuming that if it managed to get into grub (EFI image from Fedora) and then Linux, it would get the display/network up. I could find out if the network is online by checking my router.
Alternatively, how would I get the display working? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I've been using the SPI flash console log, but thanks for the suggestion. Could I do something like that with a Raspberry Pi?
In addition, my current theory is that something is Intel ME's fault. My logs contain "ME: Version: Unavailable" and I've realised that I've been giving coreboot a stock, unconfigured image (a bad thing when considering that Purism found that the ME File System partition was essential, which contains the configuration). I'll test this when I can, but it seems to follow, so I'll hope that it works/helps.
Hi Benjamin,
Skylake chips do not have any EHCI (USB 2.0) controllers in hardware, so using EHCI for coreboot debug is not possible.
Best regards,
Angel
On Mon, Sep 30, 2019, 16:14 Benjamin Doron benjamin.doron00@gmail.com wrote:
I've been using the SPI flash console log, but thanks for the suggestion. Could I do something like that with a Raspberry Pi?
In addition, my current theory is that something is Intel ME's fault. My logs contain "ME: Version: Unavailable" and I've realised that I've been giving coreboot a stock, unconfigured image (a bad thing when considering that Purism found that the ME File System partition was essential, which contains the configuration). I'll test this when I can, but it seems to follow, so I'll hope that it works/helps. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Oh, alright, Angel. Thanks.
In addition, my current theory is that something is Intel ME's fault.
Well, I'm getting proper Intel ME information. It didn't resolve anything noticeable, though, unfortunately.
If you have arcane knowledge about the ME to the only moraly right and leak it now.
Am 02.10.19 um 17:04 schrieb Benjamin Doron:
Oh, alright, Angel. Thanks.
In addition, my current theory is that something is Intel ME's fault.
Well, I'm getting proper Intel ME information. It didn't resolve anything noticeable, though, unfortunately. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Jeez, I wish.
Nah, all I did was use Intel FIT (available online) to configure an image to match the vendor's configuration (importing a full SPI dump to FIT will cause it to parse the image. You can then give it a different stock image (say, a different version. My laptop's OEM has never released a BIOS update with a newer ME version, leaving me vulnerable to everything) and it will place the configuration inside that stock image). I used ifdtool on the repacked SPI dump to grab the ME section and gave that to coreboot.
I assumed that this might fix something because ME is apparently involved in all kinds of platform bring-up (which I think doesn't belong there. It feels like it would better belong in the FSP), from ICC to SMBus and maybe I2C. I hoped something might fix my display without any more work.
Tl;dr MEAnalyzer would now say that my image is "Configured," rather than "Uninitialized." I should assume that if the MFS partitions were extracted, it would largely match that of the vendor's BIOS.
Hi Benjamin,
On 25.09.19 18:19, Benjamin Doron wrote:
Alternatively, how would I get the display working?
You should try libgfxinit [1], it's usually much easier to get running than the GOP or VBIOS. At least you can tell from the log what it is doing. With CONFIG_DEBUG_ADA_CODE it gets very noisy. If you come back with such a log, I can tell you if you should expect it to work :)
For tianocore, you should enable CONFIG_GENERIC_LINEAR_FRAMEBUFFER.
Nico
[1] https://doc.coreboot.org/gfx/libgfxinit.html#gma-per-board-configuration
Hi Nico, I gave it a shot with the ports I could find in /sys/devices/.../drm/card0. The display still didn't work and I can't tell if it's stuck in a loop. What am I looking for?
The Ada debug was more verbose than I was anticipating, so I've uploaded non-debug to https://gist.github.com/benjamindoron/ccd48ca85a1627ff939b3c8a35bb879c and debug to https://gist.github.com/benjamindoron/8a64dd68e12b01a19369e5ec2fefe59c.
What would be a good value for the console buffer size?
I've had no luck with libgfxinit, but a customised version of Kabylake's VBT (using Intel BMP to modify it to be more like the vendor's configuration) in place of the outdated vendor one got the backlight working.
I guess I can now either try the stock Kabylake VBT or review the customisations.
Hi again, I had the display working with Kabylake's VBT but without my laptop's dedicated graphics card. I've since been working on that.
I added the port for the dGPU ("device pci 01.0") to the devicetree, disabled "SkipExtGfxScan" and set "PrimaryDisplay" to Switchable Graphics, matching, as I see it, the vendor's configuration. This still does not make it work. The display backlight turns on but nothing ever appears on the display. I've even tried it with the added dGPU port as the sole change, with the same result.
I've applied a minimal set of tweaks to the VBT (editing T3 time and PWM frequency to better match the display), but it's otherwise the same as Kabylake's VBT.
What am I missing? Some PCIe configuration? A PCIe root port (vendor UEFI displays one more root port than lspci. I had thought that this could be for M.2/NVMe, whichever this system can support, but I could be wrong, even if "device pci 01.0" is commonly the GPU port)? Should I select ONBOARD_VGA_IS_PRIMARY? Or am I missing some other initialisation that only the OptionROM can do/some GPIO power stuff (I'm using TianoCore, which cannot run them. As Linux appears to ignore them, I thought that this doesn't matter)?
I'd appreciate any and all help.
Hi Benjamin,
On Sat, Jan 4, 2020, 01:57 Benjamin Doron benjamin.doron00@gmail.com wrote:
Hi again, I had the display working with Kabylake's VBT but without my laptop's dedicated graphics card. I've since been working on that.
Is this laptop using Nvidia Optimus? If so, the displays are only connected to the integrated GPU.
I added the port for the dGPU ("device pci 01.0") to the devicetree,
disabled "SkipExtGfxScan" and set "PrimaryDisplay" to Switchable Graphics, matching, as I see it, the vendor's configuration. This still does not make it work. The display backlight turns on but nothing ever appears on the display. I've even tried it with the added dGPU port as the sole change, with the same result.
I've applied a minimal set of tweaks to the VBT (editing T3 time and PWM frequency to better match the display), but it's otherwise the same as Kabylake's VBT.
What am I missing? Some PCIe configuration? A PCIe root port (vendor UEFI displays one more root port than lspci. I had thought that this could be for M.2/NVMe, whichever this system can support, but I could be wrong, even if "device pci 01.0" is commonly the GPU port)? Should I select ONBOARD_VGA_IS_PRIMARY? Or am I missing some other initialisation that only the OptionROM can do/some GPIO power stuff (I'm using TianoCore, which cannot run them. As Linux appears to ignore them, I thought that this doesn't matter)?
With libgfxinit, you don't need any VBIOS for the Intel GPU. The Nvidia GPU might need a VBIOS, but I don't think you need to run it in coreboot, as the OS should be able to handle it.
I'd appreciate any and all help.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Best regards,
Angel
Is this laptop using Nvidia Optimus? If so, the displays are only connected to the integrated GPU.
I'm not sure, but the datasheet seems to suggest so, displaying exactly what your conclusion was, that the display is connected only to the SoC. If more proof is needed, where might I find it and what do I do practically? Is this ONBOARD_VGA_IS_PRIMARY or is "PrimaryDisplay" "Display_iGFX?" Or is there something else?
Alternatively, is https://review.coreboot.org/c/coreboot/+/31448 (CONFIG_MULTIPLE_VGA_ADAPTERS) relevant?
This has been superseded by 38202 , and together with 38200 + 38201 + 38203 really helped to get a discrete GPU working on G505S and A88XM-E. These boards have both AMD integrated and discrete GPU, but maybe the "CONFIG_MULTIPLE_VGA_ADAPTERS changes" like these will help your NVidia as well! I really encourage you to try to apply their relevant parts to your board and share your feedback.
On Sun, Jan 5, 2020 at 10:27 PM Benjamin Doron benjamin.doron00@gmail.com wrote:
Alternatively, is https://review.coreboot.org/c/coreboot/+/31448 (CONFIG_MULTIPLE_VGA_ADAPTERS) relevant? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Those are AMD boards. What type of configuration would I be looking for on an Intel Skylake laptop?
Presently, I've been trying Intel FSP 2.0's GOP driver with a near-stock VBT and including VGABIOSes for both cards to boot a UEFI payload. Do your patches work with the GOP driver initialising the display or would I need to have coreboot run the OptionROMs?
Does this depend on where the display is wired up to? I don't know how APUs are set up with a dGPU.
The trouble, of course, is the devicetree settings. I wouldn't know what to set "PrimaryDisplay" to.
Regardless, thanks for your help.
On 05.01.20 20:26, Benjamin Doron wrote:
Alternatively, is https://review.coreboot.org/c/coreboot/+/31448 (CONFIG_MULTIPLE_VGA_ADAPTERS) relevant?
No, better ignore this option. It has very weird semantics (allows to overwrite one Option ROM with others, AFAICS) and was only ever used with (broken?) AMD code.
Nico
Hi Benjamin,
On 05.01.20 19:30, Benjamin Doron wrote:
Is this laptop using Nvidia Optimus? If so, the displays are only connected to the integrated GPU.
I'm not sure, but the datasheet seems to suggest so, displaying exactly what your conclusion was, that the display is connected only to the SoC. If more proof is needed, where might I find it and what do I do practically?
well, you can boot with the vendor firmware, enable the discrete GPU and check in your OS (xrandr, for instance, I guess) where the display is connected.
Is this ONBOARD_VGA_IS_PRIMARY or is "PrimaryDisplay" "Display_iGFX?" Or is there something else?
*If* it's Optimus:
o You'll have to enabled both integrated and discrete GPUs.
o You'll always use the integrated one to handle displays. PrimaryDisplay = Display_iGFX
o Select ONBOARD_VGA_IS_PRIMARY if you ever want to use open-source gfx init or an Option ROM (for the iGPU). (This is the generic coreboot switch, redundant with the PrimaryDisplay option of FSP. Better keep these settings synchronized.)
o You'll most likely have to figure out how to toggle power to the dGPU. This is mainboard specific, can be a GPIO, for instance. So I suggest to boot with the vendor firmware, dump GPIOs, toggle the dGPU, and dump again. With some luck you'll find a GPIO that changes respec- tively. You can find an example of similar code in src/drivers/lenovo/ hybrid_graphics/.
o You'll have to load the nvidia firmware (extracted from vendor image) in coreboot and make it available to the OS via ACPI. Older devices had Option ROMs (to be run by legacy BIOS) for this, I'm not sure if those are still available on newer devices. - If you have an Option ROM: Add it to CBFS as `pciVVVV,DDDD.rom` where VVVV and DDDD are the vendor and device IDs of your dGPU in hex. coreboot should pick it up and do the rest. - If not: I'd suggest to dig into your vendor firmware's DSDT (and SSDTs) and the Linux kernel driver for your dGPU to figure out what is provided to the OS and how. Please document your findings first, if you go this way, then we can discuss integration into coreboot.
Nico
well, you can boot with the vendor firmware, enable the discrete GPU and check in your OS (xrandr, for instance, I guess) where the display is connected.
eDP? That's probably not very helpful to you, I'm sorry. Doesn't that just say that it's an internal connector?
o You'll always use the integrated one to handle displays. PrimaryDisplay = Display_iGFX
And SkipExtGfxScan is disabled?
o You'll most likely have to figure out how to toggle power to the dGPU. This is mainboard specific, can be a GPIO, for instance. So I suggest to boot with the vendor firmware, dump GPIOs, toggle the dGPU, and dump again. With some luck you'll find a GPIO that changes respec- tively. You can find an example of similar code in src/drivers/lenovo/ hybrid_graphics/.
I'll work on this, then.
o You'll most likely have to figure out how to toggle power to the dGPU. This is mainboard specific, can be a GPIO, for instance. So I suggest to boot with the vendor firmware, dump GPIOs, toggle the dGPU, and dump again. With some luck you'll find a GPIO that changes respec- tively. You can find an example of similar code in src/drivers/lenovo/ hybrid_graphics/.
I'll work on this, then.
A couple of GPIOs do change when the dGPU is enabled or disabled. But why would any additional code need to be written? I thought that the point of passing gpio.h to ramstage was that it resolved these issues, allowing us to do what vendor firmware does where it counts, without understanding/parsing individual values.
Of course, I haven't tried another image yet so the above could be true, and therefore, irrelevant, but I wouldn't know it.
A couple of GPIOs do change when the dGPU is enabled or disabled.
I'm astonished, but the GPIOs that I had saved seem to correspond to the dGPU being disabled. I'll go through them again. I also saw one appear before and two others disappear now. As they all appear in the datasheet, I'm leaving them at the values that I have for these three.
Am I correct that gpio.h is enough to have the GPIOs set correctly?
And thanks, Nico.
I'm astonished, but the GPIOs that I had saved seem to correspond to the dGPU being disabled.
Upon further investigation, it seems to have more to do with whether I shutdown or restarted. Either way, I need to go through them in more detail.
(sorry for the spam?)
On 06.01.20 06:18, Benjamin Doron wrote:
A couple of GPIOs do change when the dGPU is enabled or disabled.
I'm astonished, but the GPIOs that I had saved seem to correspond to the dGPU being disabled. I'll go through them again. I also saw one appear before and two others disappear now. As they all appear in the datasheet, I'm leaving them at the values that I have for these three.
Am I correct that gpio.h is enough to have the GPIOs set correctly?
`gpio.h` only sets a snapshot of the GPIO state. I doesn't program any additional logic. All GPIOs that need to change its state during runtime need additional programming, either in C or ASL (ACPI).
I suggest to decode the changing GPIO registers, if you haven't already. Some may be configured as inputs and might only change state as a result of other changes...
Nico
On 06.01.20 00:34, Benjamin Doron wrote:
well, you can boot with the vendor firmware, enable the discrete GPU and check in your OS (xrandr, for instance, I guess) where the display is connected.
eDP? That's probably not very helpful to you, I'm sorry. Doesn't that just say that it's an internal connector?
Not sure how. But can't `xrandr` tell you what graphics card (driver) is used for that?
o You'll always use the integrated one to handle displays. PrimaryDisplay = Display_iGFX
And SkipExtGfxScan is disabled?
Yes. With this and correct GPIO settings (with dGPU enabled) the dGPU should show up on the PCI bus. That's the first thing to look at (in coreboot logs). When it shows up, next step is to make it work with the OS...
Nico
I'm using some code (https://review.coreboot.org/c/coreboot/+/35523/55/src/mainboard/acer/aspire_...) to set the GPIO pins.
the dGPU should show up on the PCI bus
Although the GPIO settings work, the PCI device does not appear. Neither I2C controller appears either (15.0 and 15.1).
In the log: "Enumerating buses... system76: DGPU present system76: DGPU reset start system76: DGPU disable power set DGPU power disabled, wait and continue system76: DGPU enable power system76: DGPU reset finished Root Device scanning..." and "PCI: Static device PCI: 00:01.0 not found, disabling it."
Additionally, it predictably stops executing almost immediately after, when it had continued through scanning the buses, enabling resources and continuing towards the payload. The last lines of the log are: "PCI: Leftover static devices: PCI: 00:01.0 PCI: 00:14.1 PCI: 00:15.0 PCI: 00:15.1 PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:16.4"
Why isn't the device appearing and why is the process halting now?
Hi Bemjamin,
On 26.01.20 07:51, Benjamin Doron wrote:
I'm using some code (https://review.coreboot.org/c/coreboot/+/35523/55/src/mainboard/acer/aspire_...) to set the GPIO pins.
can you elaborate on that. How did you figure out the GPIO pins? why are you using this system76 sequence?
the dGPU should show up on the PCI bus
Although the GPIO settings work,
How did you confirm that?
the PCI device does not appear.
Hmmm, looking at the code, it doesn't seem to leave much time. IIRC, a PCI device should be given 100ms (or was it 200ms?) to show up.
Neither I2C controller appears either (15.0 and 15.1).
That is really odd, now I'm a little bit concerned about the well- being of your board.
Nico
Hi Nico,
How did you figure out the GPIO pins?
I found the schematics online.
why are you using this system76 sequence?
The Lenovo hybrid_graphics code wasn't relevant enough, so I looked for the function and arguments to call to set GPIOs. Once I had code to do that, I didn't care to remove the system76 references, but it is fairly generic code.
Hmmm, looking at the code, it doesn't seem to leave much time. IIRC, a PCI device should be given 100ms (or was it 200ms?) to show up.
Right. Well, the schematics define a *slightly* different sequence of GPIOs. If a dGPU is present (DGPU_PRESENT asserted low indicates "OPTIMUS," as opposed to "UMA"), DGPU_PWR_EN is meant to be sent. I think that triggers a VGA core power enable GPIO pin and then DGPU_PWROK can be checked.
So, if PWROK means powered on (rather than that power is in a stable state, which seems to be the case for system76), it can't check PWROK after disabling power, so I commented out that loop and just added a delay.
The delay does sound like it is too short, could this be the problem? Also, does it make sense to cut the code down to just using the above 3 pins, ignoring HOLD_RST and never sending power disable?
Note: Even if it is a problem, somehow, it still gets PWROK. Hopefully, this does not mean that it's getting a result set in gpio.h. With GPIO debugging on, I did not see the messages as this code ran, only higher up in the ramstage log.
Some other questions: 1. Can and should this be done in ramstage, or should it be done earlier? 2. I added in "pc_keyboard_init(NO_AUX_DEVICE)" because the drivers in the ec directory would run that to initialise their chips. (Do I need "CONFIG_DRIVERS_PS2_KEYBOARD?") The printk before it never gets logged. What does this mean and is it related/relevant? 3. Do I need to do anything with the EC? I know that the vendor firmware includes the EC's ROM in a padding section at the top of the BIOS section, but I did successfully boot into an OS using coreboot before. The laptop responds to the power key, LED indicators and the battery work (well, OS thought it wasn't present, but that was ACPI related), fans presumably spin and if I tried charging it, it did that too.
As an aside, the first PCIe root port now appears. I don't know how this might be tangled up with the dGPU, "pci 01.0" or anything else, but maybe it could be appearing because of the SUBSYSTEM_{VENDOR,DEVICE}? In which case, perhaps boot is freezing up because the dGPU isn't actually available?
That is really odd, now I'm a little bit concerned about the well- being of your board.
No, they appear with the vendor firmware. I'd find it very weird, but maybe I need "SOFTWARE_I2C?"
I have the display working again, but no dGPU. Linux won't boot anymore either, it fails with "NMI Watchdog: watchdog detected hard LOCKUP on CPU #" or just bootloops.
coreboot no longer hangs in PCI (I re-enabled some devices I didn't think I needed, perhaps some are critical?) and the I2C controllers appear with the "SerialIoDevMode" UPD set appropriately.
Hello again, I've attempted an experiment with the vendor firmware to get to the bottom of this.
With the vendor firmware, Primary Display can be set to: Auto, IGFX (possibly PEG and PCI. I haven't tried these, it also may be one or the other that appear) and SG. There is an option to "Select PCIE card," which describes the behaviour of the DGPU_POWER_EN pin. (Auto: Skip GPIO-based power enable and Elk Creek 4 and PEG Eval, for DGPU_POWER_EN is ActiveLow or ActiveHigh).
In any configuration of "Select PCIE card" with Primary Display set to SG, the dGPU appears. However, in any configuration of "Select PCIE card" with Primary Display set to IGFX, the dGPU does not appear. The default configuration in the vendor firmware is Primary Display: SG; Select PCIE card: Auto.
o You'll always use the integrated one to handle displays. PrimaryDisplay = Display_iGFX
o You'll most likely have to figure out how to toggle power to the dGPU.
The dGPU appears with PrimaryDisplay=Display_Switchable. Optimus isn't implemented yet, so power consumption is likely increased and nouveau can't find the vbios. In addition, I see the following error in dmesg:
"NVRM: GPU 0000:01:00.0: Failed to enable MSI; falling back to PCIe virtual-wire interrupts."
I thought I had tried this option before, but perhaps there was a different option at the time that was preventing the display from working (perhaps an improperly configured VBT). In any case, there's a little bit of clean-up for me to do and then this hopefully can be committed.
Thank you everyone for helping me along the way.
With libgfxinit, you don't need any VBIOS for the Intel GPU.
I first got a working display with the GOP driver, but I'll try libgfxinit again. Would there be a difference between the vendor's VBT and the one that I've been using with the FSP?
The Nvidia GPU might need a VBIOS, but I don't think you need to run it in coreboot, as the OS should be able to handle it.
`sudo lspci -vvv | grep "Expansion ROM"` is only giving me one for the integrated GPU, so I'm slightly confused (but it's mentioned here (https://coreboot.coreboot.narkive.com/zEkIcuSS/ultimate-vgabios-extraction-n...) that the Linux kernel method only worked for the integrated GPU, so perhaps this is expected. However, now I'm also concerned that the vendor firmware could be patching the ROM in memory). I've been including one for the dGPU anyway.
Thanks for your help.
Hi all, I've built another image and barring some easily explained (yet potentially hard to fix) issues in the EC ACPI code, most things are functional. Except for the headphone jack. The HDA init_pin_configs are the same in both the vendor firmware and coreboot, yet neither the headphone jack nor the microphone work.
Some differences exist between the vendor firmware and coreboot in the codec#{0,2} files, and changes in those files with the vendor firmware when headphones are inserted or removed.
How can I fix this? Do bytes from some of the additional nodes that appear in the codec file need to be added into hda_verb? If so, how do I know which?
-
Angel Pons -
Benjamin Doron -
benjamin.doron00＠gmail.com
-
Kinky Nekoboi -
Mike Banon -
Nico Huber -
Patrick Georgi