Re: e1000e ULP issue

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]