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

Christian Kohlschütter christian at kohlschutter.com
Mon Mar 31 19:31:00 CEST 2025


On 31. Mar 2025, at 19:15, Michael Brown <mcb30 at ipxe.org> wrote:
> 
> On 31/03/2025 17:49, Christian Kohlschütter wrote:
>> # hexdump  /.aaaaargh
>> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 0044100 ffff ffff ffff 15dc f9c8 6f16 e188 0000
>> 0044110 00a0 52b0 a01c 6d59 0000 0000 0000 0000
>> 0044120 0000 0000 0000 0000 0000 0000 0000 0000
>> 0044130 0000 0000 0000 0000 0000 0000 e1a8 6097
> 
> This looks suspiciously like a broadcast Ethernet packet from a source MAC address of dc:15:c8:f9:16:6f with an ethertype of 0x88e1.  Some quick research suggests that these are HomePlug Management packets generated by a "Fritz!" home router.
> 
>>> commit 06ef8089f876b6dabf56caba31a05c003f03c629 (HEAD)
>>> Author: Simon Glass <sjg at chromium.org>
>>> Date:   Sun Dec 31 08:25:55 2023 -0700
>>> 
>>>     efi: Correct smbios-table installation
>>>         At present this code allocates memory when writing the tables and
>>>     then unnecessarily adds another memory map when installing it.
>>>         Adjust the code to allocate the tables using the normal U-Boot
>>>     mechanism. This avoids doing an EFI memory allocation early in
>>>     U-Boot, which may use memory that would be overwritten by a
>>>     'load' command, for example.
>>>         Signed-off-by: Simon Glass <sjg at chromium.org>
> 
> No idea how that could relate to the packet you're seeing being written into random memory locations, sorry.  I'll leave it to one of the U-Boot developers to respond.
> 
> Thanks,
> 
> Michael
> 

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



More information about the U-Boot mailing list