Re: main's recent loader.efi broken in an example aarch64 update context

On 2022-May-20, at 10:31, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-May-17, at 18:09, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> [I've cc'd some folks that recently committed onto main's stand/
>> or did the llvm14 toolchain merge. I've no clue what makes the
>> difference.]
>> 
>> Note: the MACCHIATObin Double Shot has a EDK2 based
>> UEFI/ACPI context for how it is set up to boot.
>> 
>> In trying to update a MACCHIATObin Double Shot to a main
>> vintage with llvm14 I got boot attempts that look like the
>> below at the tail of its visible activity (serial console):
>> 
>> QUOTE
>> Loading kernel...
>> /boot/kernel/kernel text=0x2a8 text=0x91b040 text=0x216434 data=0x1b8128 data=0x
>> 0+0x2ae000 0x8+0x130980+0x8+0x157b86
>> Loading configured modules...
>> /boot/kernel/cryptodev.ko text=0x16c3 text=0x27a0 data=0x628+0x10 0x8+0xcd8+0x8+
>> 0x96c
>> /boot/kernel/zfs.ko text=0xa81a0 text=0x209310 data=0x26a88+0xba46c 0x8+0x32a78+
>> 0x8+0x2c37e
>> /etc/hostid size=0x25
>> /boot/entropy size=0x1000
>> No valid device tree blob found!
>> WARNING! Trying to fire up the kernel, but no device tree blob found!
>> EFI framebuffer information:
>> addr, size     0x0, 0x0
>> dimensions     0 x 0
>> stride         0
>> masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
>> 
>> 
>> Synchronous Exception at 0x00000000B460F554
>> END QUOTE
>> 
>> Part of the update was updating the loader.efi copies:
>> 
>> # ls -Tldt /mnt/efi/*/*
>> -r-xr-xr-x  1 root  wheel  1204828 May 14 18:53:16 2022 /mnt/efi/boot/bootaa64.efi
>> -r-xr-xr-x  1 root  wheel  1204828 May 14 18:53:16 2022 /mnt/efi/freebsd/loader.efi
>> 
>> 
>> 
>> I had to revert to copies of a prior loader.efi vintage that
>> I had around to copy in order to boot the otherwise updated
>> USB3 drive. Nothing else had to change. Copied from:
>> 
>> CA72_Mbin_ZFS aarch64  1400057 1400057 # ls -Tldt /boot/efi/efi/*/*
>> -rwxr-xr-x  1 root  wheel  1287580 Apr 28 21:46:46 2022 /boot/efi/efi/boot/bootaa64.efi
>> -rwxr-xr-x  1 root  wheel  1287580 Apr 28 21:46:46 2022 /boot/efi/efi/freebsd/loader.efi
>> 
>> 
> 
> 
> By the way, yesterday I tried updating my amd64 context's loader.efi use
> based on an install from a buildworld buildkernel made from the same
> source files (by content). The amd64 one worked fine. So the problem is
> somehow more specific to my aarch64 context.
> 
> But I just tried the armv7 system and it got:
> 
> . . .
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...               
> Using DTB provided by EFI at 0x47edf000.
> Kernel entry at 0xb2e00200...
> Kernel args: (null)
> undefined instruction
> pc : [<b8dd34a4>]          lr : [<b8e3128c>]
> reloc pc : [<44e3f4a4>]    lr : [<44e9d28c>]
> sp : b9f6a328  ip : b69e1c00     fp : b9f6a368
> r10: b9f6a374  r9 : 00000000     r8 : b8f1f11c
> r7 : c0e03000  r6 : 00008000     r5 : b6981500  r4 : 00000000
> r3 : 00000065  r2 : 00000076     r1 : b8f1b847  r0 : 00000000
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Code: e08f0000 e1a0e00f ea01776e 00144492 (00146ddf) 
> UEFI image [0xb8dd3000:0xb8f2632b] pc=0x4a4 '/efi\boot\bootarm.efi'
> Resetting CPU ...
> 

Updating to recent enough to include:

	• git: 0d6600b579be - main - Set mm before passing it to the UEFI firmware Andrew Turner 

made the then-built loader.efi 's for aarch64 and armv7
work agin.

The fixed problem appears to be a Undefined Behavior
for which the llvm14 based toolchain handles
differently.

It looks like the Undefined Behavior goes back to:

QUOTE
author	Rebecca Cran <bcran_at_FreeBSD.org>	2019-03-06 05:39:40 +0000
committer	Rebecca Cran <bcran_at_FreeBSD.org>	2019-03-06 05:39:40 +0000
commit	ce37b71e6809fe5074be54230da9cf09543d3cdd (patch)
tree	6dcce17c6e090289b79e78f72e3f2904d8ba171b /stand/efi/loader/bootinfo.c
parent	151c6d102035a05ff5c62b7df02bb7b3247dd0f7 (diff)
download	src-ce37b71e6809fe5074be54230da9cf09543d3cdd.tar.gz
src-ce37b71e6809fe5074be54230da9cf09543d3cdd.zip
Add retry loop around GetMemoryMap call to fix fragmentation bug
The call to BS->AllocatePages can cause the memory map to become framented,
causing BS->GetMemoryMap to return EFI_BUFFER_TOO_SMALL more than once. For
example this can happen on the MinnowBoard Turbot, causing the boot to stop
with an error. Avoid this by calling GetMemoryMap in a loop.

Reviewed by:	imp, tsoome, kevans
Differential Revision:	

https://reviews.freebsd.org/D19341

Notes

Notes:
    svn path=/head/; revision=344839
END QUOTE

I do not know if MFCs will be done to avoid continuing
to depend on various toolchain vintage's detailed
handling of the Undefined Behavior --or not.


===
Mark Millard
marklmi at yahoo.com