loader needs to be updated – again, but on arm64 [SOLVED]

[dl8dtl]

Yes, I git pulled the most recent version before.
Btw., can you commit a "chmod +x" for the script? Git always complains about a local conflict otherwise.

# efibootmgr -v
BootCurrent: 0000

(Same output on both boards.)

With -g, it seems to do the job:

# ./loaders-update show-me -g
loaders-update v1.4.0

Scaning only EFI loaders, excluding BIOS loaders.
One or more efi partition(s) have been found.

Examining diskid/DISK-Z0HA32PEK2L2p1...
Efi partition diskid/DISK-Z0HA32PEK2L2p1 is already mounted in /boot/efi.
EFI loader /boot/efi/EFI/BOOT/bootaa64.efi is up-to-date.

-------------------------------
Your current boot method is UEFI.
Boot device:
One or more target partition(s) have been found...
All loaders are up-to-date.
-------------------------------

Btw.², these boards use a first-stage bootloader that can be interacted with on the (serial) console ("Das U-Boot"). It might make sense to preserve the old loader image under another name, like /boot/efi/EFI/BOOT/bootaa64.old. I'm afraid it needs to fit the old FAT 8+3 naming convention.

 

[Emrion]

Btw., can you commit a "chmod +x" for the script? Git always complains about a local conflict otherwise.

I don't use git locally for this repo. Furthermore, I know almost nothing to git . It seems, I can't do that on the web site.

I forced the -g option for arm64, so you won't need to set it anymore.
The efibootmgr output is especially poor on your machine. I did a cosmetic change to polish the text results of loaders-update.

It might make sense to preserve the old loader image under another name,

I already thought to that and concluded, it's an useless feature or at least, a little too complicated. If you save the file with other extension than .efi, the firmware won't propose this file for boot. If you save the file with .efi, loaders-update will propose to update it each time you run it.

It's not impossible that said. I can use a specific token in the name of the saved loaders or a specific directory. But it will complicate the script for almost nothing. I never had a problem with the update of the loaders and if it happens one day, I will boot on an USB key to mend the thing.

Maybe one day, I will change my mind.

 

[dl8dtl]

I prepared you a pull request for the executable permissions. So you just need to accept it. ;-)

Once my test system is done compiling LLVM, I'll give it a try whether U-Boot could be convinced to run a file like bootaa64.old (without the ".efi" extension).

 

[dl8dtl]

This machine was running an older -current system, which has been quite unstable unfortunately. It crashed every now and then. So I eventually installed a FreeBSD 15.0-RELEASE on it now. Running your script appears to work fine on this system as well:

root@rock:~/uploaders # ./loaders-update show-me
loaders-update v1.4.0

Scaning only EFI loaders, excluding BIOS loaders.
One or more efi partition(s) have been found.

Examining mmcsd0p1...
Efi partition mmcsd0p1 is already mounted in /boot/efi.
EFI loader /boot/efi/efi/freebsd/loader.efi is up-to-date.
EFI loader /boot/efi/efi/boot/bootaa64.efi is up-to-date.

-------------------------------
Your current boot method is UEFI.
One or more target partition(s) have been found...
All loaders are up-to-date.
-------------------------------

tl;dr It might make sense to create a backup copy of the boot code. ;-)

Using a different name than the default bootaa64.efi is not trivial but possible. Basically, one would have to pick up the individual parts of the respective EFI boot command:

boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; in=$stdin; out=$stdout; err=$stderr;setenv stdin serial;setenv stdout serial; setenv stderr serial; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi; setenv stdin $in;setenv stdout $out; setenv stderr $err;

by copy & pasting it on the U-Boot prompt, so essentially (in my case)

load mmc 1 1:1 ${kernel_addr_r} efi/boot/bootaa64.bak
bootefi ${kernel_addr_r} ${fdt_addr_r}

did the trick, allowing me to bootstrap the kernel using an alternative copy of the bootcode.

 

[Emrion]

loaders-update 1.4.0 has been committed in the main branch of ports.
It includes support for arm64 and some bug fixes, but not a backup system.

I'm waiting for bug reports concerning arm64...