Re: main's recent loader.efi broken in an example aarch64 update context
- In reply to: Mark Millard : "Re: main's recent loader.efi broken in an example aarch64 update context"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 22 May 2022 10:38:49 UTC
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