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 <[email protected]> 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" <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
