[ipxe-devel] Network Stack Initialization on Apollo Lake Systems

[Geert Stappers]

On Mon, Mar 30, 2020 at 12:16:30PM -0400, Jacob Caughfield wrote:
> Hi all,
> 
> I've run into an issue where ipxe.efi fails to detect/initialize any NICs
> when the uefi network stack is disabled. When the stack is enabled,
> everything works perfectly. However, as I understand it, iPXE does not
> require the UEFI stack as long as it has a driver for the NICs -- indeed on
> our non Apollo Lake systems with the same NICs (I210  8086:1533) the UEFI
> network stack does not need to be enabled for iPXE to detect and initialize
> the interface.
> 
> So far every Apollo Lake system we've tested (5 or so baseboards)
> exhibit this issue. Here's a paste <https://pastebin.com/mimn0s9E> of a log
> from a failing system, the failure being:
> 
> EFIDRV PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) could not connect new drivers: Error 0x7f37e09a

Also in the same "paste bin"
| Register(0x24) @ Bar(0x0)
| Finding PCI Driver...
| 0000:06:00.0 (probe) has mem 709ded2f io 73a58598 irq 255
| EFIPCI 0000:06:00.0 (8086:1533 class 020000) has driver "i210"
| EFIDRV PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) has driver "PCI"
| EFIDRV PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) before disconnecting:
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) DevicePath supported
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) DevicePath opened 180x (H) by DxeCore(?) for <NULL>
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) PciIo supported
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) PciIo opened 23x (H) by DxeCore(?) for <NULL>
| EFIDRV PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) disconnecting existing drivers
| EFIDRV PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) after disconnecting:
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) DevicePath supported
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) DevicePath opened 180x (H) by DxeCore(?) for <NULL>
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) PciIo supported
| HANDLE PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) PciIo opened 23x (H) by DxeCore(?) for <NULL>
| EFIDRV PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) connecting new drivers
| EFIDRV PciRoot(0x0)/Pci(0x14,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) could not connect new drivers: Error 0x7f37e09a (http://ipxe.org/7f37e09a)
| Failed to add EFI root bus: Error 0x7f37e09a (http://ipxe.org/7f37e09a)
| Adding EISA root bus
| Adding Hyper-V root bus
| Failed to add Hyper-V root bus: No such device (http://ipxe.org/2c834087)
| Adding ISA root bus
| Adding ISAPnP root bus

FWIW  I did visit the above ipxe.org/err URLs
and do remember that I have seen them recently before ...

 
> It appears to me like the uefi ConnectController boot service is what
> actually returns the error, but it I don't think that iPXE controls the
> internal behavior of that function; perhaps the root cause of failure is
> elsewhere? It could be that Apollo Lake simply implements some critical
> component in a different location, and we would merely need to point iPXE
> there in order to work around the issue -- but I don't understand the iPXE
> stack well enough to really speculate.
> 
> Do you have any suggestions on how we could continue to debug, or how we
> could potentially work around this issue?

be part of the iPXE community
such as partiate in mailinglist discussion
 
> Thanks!

Looking forward to further colaboration.


Regards
Geert Stappers
-- 
Silence is hard to parse