Re: U-Boot interferes with initrd binary — Revert "efi: Correct smbios-table installation" ?

[Michael Brown]

On 31/03/2025 18:31, Christian Kohlschütter wrote:
> Whoa! Good eyes, Michael!
> 
> What is my Fritzbox doing to my initrd, and why does reverting the commit fix it?
> 
> FWIW, I also have a capture with an ethernet frame from another device on my network (ARP, ethertype 0x0806), so this is probably the content of some ethernet receive buffer...

I've taken a quick look through the U-Boot codebase, and I can't 
immediately see where the Ethernet device gets disabled as a result of 
calling ExitBootServices().  It's possibly worth noting that U-Boot may 
have relied upon iPXE's behavior prior to commit 
https://github.com/ipxe/ipxe/commit/562c74e1e:

   [efi] Run ExitBootServices shutdown hook at TPL_NOTIFY

   ... <snip lengthy explanation as to why we need to do this> ...

   Avoid calling into an underlying SNP protocol instance from within our
   shutdown hook at TPL_NOTIFY, since the underlying SNP driver may
   attempt to raise the TPL to TPL_CALLBACK (which would cause a fatal
   error).  Failing to shut down the underlying SNP device is safe to do
   since the underlying device must, in any case, have installed its own
   ExitBootServices hook if any shutdown actions are required.

So, older versions of iPXE would have called Snp->Stop(), which in 
U-Boot's efi_net_stop() will call eth_halt().  Current versions of iPXE 
will not call Snp->Stop(), and will rely on the underlying SNP driver to 
have dealt with its own ExitBootServices() requirements.

I can't find any evidence of U-Boot installing an 
EVT_SIGNAL_EXIT_BOOT_SERVICES event to call eth_halt() when 
ExitBootServices() is called.

The closest I can find is a block of code in U-Boot's 
efi_exit_boot_services():

   bootm_disable_interrupts();
   if (IS_ENABLED(CONFIG_USB_DEVICE))
      udc_disconnect();
   board_quiesce_devices();
   dm_remove_devices_active();

but I don't know precisely what these various functions are supposed to 
do, and I can't find any path that leads from any of these to eth_halt().

Is it possible that U-Boot is failing to call eth_halt() in response to 
ExitBootServices(), and is therefore leaving the network device active 
and performing DMA while the kernel starts up?

Michael