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