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

[Simon Glass]

Hi Michael,

On Tue, 1 Apr 2025 at 23:22, Michael Brown <mcb30 at ipxe.org> wrote:
>
> 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();

We have discussed combining this code with the similar code in boot/bootm.c

>
> 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?

The dm_remove_devices_active() is supposed to handle this, but it is
possible that one of the drivers lacks a remove() method.

Regards,
Simon