Using Maciej Pijanowski's m920q review, I was able to get coreboot booting on a Lenovo m720q.
However, I get a strange error in Linux under coreboot.
e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): Failed to disable ULP
There is also a potentially related ACPI complaint: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - _SB_.PCI0.IGBE (20230331/dspkginit-438)
The gbe Ethernet controller is built in:
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10)
Several other existing boards seem also have I219 devices but I couldn’t find any special handling for this. I'm not familiar with ULP, but it seems the ME could turned it on. I still have the original ME and GBE sections in the flash.
Has anyone seen this issue before? Or should I try to add coreboot code to disable ULP in the Ethernet PHY? (seems a bit strange).
Thanks!
Hello!
Lately I spent a lot of time debugging this nightmare error. However, I ran into this problem while using Intel Slim Bootloader on Alder Lake S board, but I believe my experience would still be relevant.
In my build ACPI was complaining about several methods like `_SB.PC00.LPCB.H_EC.ECWT`, `_TZ.FNCL`, `_TZ.TZ00._TMP` and etc. We've found out that this errors are related to Embedded Controller that we do not have on our motherboard. So disabling Embedded Controller Availability (in FSP) fixed ACPI errors, but it didn't fix the ethernet problem. So do not just focus on ACPI error.
You also have to be sure that ME and GbE regions are fine. To make sure, just fetch these regions from the original vendor binary where ethernet works.
What REALLY helped solve the issue was disabling PCIe Gen5 (x16) and PCIe Gen4 (x4) controllers (PCIe Gen5 x8 was already disabled AFAIR). I'm not sure if this is the right way to do it, but I disabled them via Device Enable register within Host Bridge (D0:F0) in the early stages of initilization, even before running FSP-M. To find out more about D0:F0 device and the register, refer to the Intel documentation for your generation of processor.
I'm not a PCI expert, so I cannot say for sure why these changes helped us. Board's schematics contains labels like "PCIe3.0/GBE" and "PCIE4.0/SATA/GBE" (part of x4) around PCIe lanes. The lane around the first label is connected to I219 chip (via PCIe 3.0). So it's possible that PCIe lanes are not configured correctly => when x4 is enabled, the firmware uses the wrong lane for GbE. If somebody knows more about this, I would appreciate any information.
Anyway, you can start your debugging journey by using the debug version of e1000e driver. Feel free to use my patched driver[1]. It works with Linux kernel v5.10.
I hope something from this wall of text will be helpful to you. Good luck!
[1] https://github.com/Joursoir/e1000e
On Tue, 2 Apr 2024 19:14:25 -0500 "Mr. Gadha via coreboot" coreboot@coreboot.org wrote:
Using Maciej Pijanowski's m920q review, I was able to get coreboot booting on a Lenovo m720q.
However, I get a strange error in Linux under coreboot.
e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): Failed to disable ULP
There is also a potentially related ACPI complaint: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - _SB_.PCI0.IGBE (20230331/dspkginit-438)
The gbe Ethernet controller is built in:
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10)
Several other existing boards seem also have I219 devices but I couldn’t find any special handling for this. I'm not familiar with ULP, but it seems the ME could turned it on. I still have the original ME and GBE sections in the flash.
Has anyone seen this issue before? Or should I try to add coreboot code to disable ULP in the Ethernet PHY? (seems a bit strange).
Thanks!
Thanks for info. The issue for me turned out to be an incorrect “subsystem id” in the device tree. I found it a bit surprising since the e1000e driver doesn’t seem to directly care, but perhaps other workarounds got triggered that caused issues. I found it also behaved well without setting it.
Now Ethernet works and there are no ACPI complaints!
On Apr 3, 2024, at 1:34 PM, Joursoir chat@joursoir.net wrote:
Hello!
Lately I spent a lot of time debugging this nightmare error. However, I ran into this problem while using Intel Slim Bootloader on Alder Lake S board, but I believe my experience would still be relevant.
In my build ACPI was complaining about several methods like `_SB.PC00.LPCB.H_EC.ECWT`, `_TZ.FNCL`, `_TZ.TZ00._TMP` and etc. We've found out that this errors are related to Embedded Controller that we do not have on our motherboard. So disabling Embedded Controller Availability (in FSP) fixed ACPI errors, but it didn't fix the ethernet problem. So do not just focus on ACPI error.
You also have to be sure that ME and GbE regions are fine. To make sure, just fetch these regions from the original vendor binary where ethernet works.
What REALLY helped solve the issue was disabling PCIe Gen5 (x16) and PCIe Gen4 (x4) controllers (PCIe Gen5 x8 was already disabled AFAIR). I'm not sure if this is the right way to do it, but I disabled them via Device Enable register within Host Bridge (D0:F0) in the early stages of initilization, even before running FSP-M. To find out more about D0:F0 device and the register, refer to the Intel documentation for your generation of processor.
I'm not a PCI expert, so I cannot say for sure why these changes helped us. Board's schematics contains labels like "PCIe3.0/GBE" and "PCIE4.0/SATA/GBE" (part of x4) around PCIe lanes. The lane around the first label is connected to I219 chip (via PCIe 3.0). So it's possible that PCIe lanes are not configured correctly => when x4 is enabled, the firmware uses the wrong lane for GbE. If somebody knows more about this, I would appreciate any information.
Anyway, you can start your debugging journey by using the debug version of e1000e driver. Feel free to use my patched driver[1]. It works with Linux kernel v5.10.
I hope something from this wall of text will be helpful to you. Good luck!
[1] https://github.com/Joursoir/e1000e
On Tue, 2 Apr 2024 19:14:25 -0500 "Mr. Gadha via coreboot" coreboot@coreboot.org wrote:
Using Maciej Pijanowski's m920q review, I was able to get coreboot booting on a Lenovo m720q.
However, I get a strange error in Linux under coreboot.
e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): Failed to disable ULP
There is also a potentially related ACPI complaint: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - _SB_.PCI0.IGBE (20230331/dspkginit-438)
The gbe Ethernet controller is built in:
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10)
Several other existing boards seem also have I219 devices but I couldn’t find any special handling for this. I'm not familiar with ULP, but it seems the ME could turned it on. I still have the original ME and GBE sections in the flash.
Has anyone seen this issue before? Or should I try to add coreboot code to disable ULP in the Ethernet PHY? (seems a bit strange).
Thanks!
-- Joursoir _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Joursoir -
mr gadha -
Mr. Gadha