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

dl8dtl

dl8dtl

Developer
I've read

Emrion

Thread 'Update of the bootcodes for a GPT scheme (x64 architecture)'

This how-to is about the update of the bootcodes on FreeBSD as it's little to no documented. It only covers the GPT scheme and is intended for people with little knowledge of FreeBSD.

Edit: I wrote a script that gives the right commands to type after inspecting your system and can possibly execute them. Take a look at: https://github.com/Emrion/uploaders

Run this script and ask questions in that thread: https://forums.freebsd.org/threads/...gure-how-to-update-the-freebsd-loaders.94237/


When to update?
At each upgrade of the...
  • Thanks
  • Like

… but it's for an amd64 architecture.
As my firewall uses an arm64 board, I'm a bit confused what exactly needs to be done there. All the files in `/boot` are a little different. In particular, there is no `/boot/gptzfsboot`.
As there's a high risk of shooting into my foot, can anyone explain what would be needed for this architecture?
(The system is a ZFS root one, and of course uses GPT.)
 
I can't really help you because I've never got an arm64 machine on hand. This is why sysutils/loaders-update works only on amd64 (I would like it works on other arch, but I need help and tests).

Reading some web infos, it seems that only UEFI is functioning on arm64.

So, look into your boot disk, you should have an efi partition. Mount it, if not already mounted (it may be mounted in /boot/efi/). List the *.efi files you have inside. There you can try to replace them (keep original names) by /boot/loader.efi.

The efi loader that actually boots your machine can be seen with # efibootmgr -v.
 
The EFI partition is mounted by default. It contains

# ls -l /boot/efi/EFI/BOOT/bootaa64.efi
-rwxr-xr-x 1 root wheel 1180812 Feb 4 2023 /boot/efi/EFI/BOOT/bootaa64.efi
# efibootmgr -v
BootCurrent: 0000

The /boot directory itself (on ZFS root volume) has:

# ls -l /boot/*.efi
-r-xr-xr-x 1 root wheel 179272 May 21 23:03 /boot/boot1.efi
-r-xr-xr-x 1 root wheel 124920 May 21 23:03 /boot/gptboot.efi
-r-xr-xr-x 2 root wheel 853948 May 21 23:03 /boot/loader.efi
-r--r--r-- 1 root wheel 16365 May 21 23:03 /boot/loader.help.efi
-r-xr-xr-x 1 root wheel 725900 May 21 23:03 /boot/loader_4th.efi
-r-xr-xr-x 2 root wheel 853948 May 21 23:03 /boot/loader_lua.efi
-r-xr-xr-x 1 root wheel 655912 May 21 23:03 /boot/loader_simp.efi

So it's loader.efi to copy over? It's quite a bit smaller than the loader installed right now.
 
I think your EFI partition looks good. This is from my Raspberry Pi 5:
Code: 
root@devpi5:~ # ls -l /boot/efi/EFI/BOOT/
total 848
-rwxr-xr-x  1 root wheel 853788 Dec  7 20:16 bootaa64.efi
which is running
Code: 
root@devpi5:~ # freebsd-version -ku
14.4-RELEASE-p3
14.4-RELEASE-p3
Some of the non-x86 boards (like the Raspberry Pi series) needs to have another partition to actually boot and / or load initial firmware from. For the Pi series this is a FAT partition
Code: 
root@devpi5:~ # gpart show -p nda1
=>        40  7814037088    nda1  GPT  (4T)
          40     1048576  nda1p1  ms-basic-data  (512M)
     1048616     1048576  nda1p2  efi  (512M)
     2097192    33554432  nda1p3  freebsd-swap  (16G)
    35651624  7778385504  nda1p4  freebsd-zfs  (4T)
If I mount it it contains this
Code: 
root@devpi5:~ # ls -l /mnt
total 2656
-rwxr-xr-x  1 root wheel 2031616 May  1 08:15 RPI_EFI.fd
-rwxr-xr-x  1 root wheel   78373 Jun 11  2025 bcm2712-d-rpi-5-b.dtb
-rwxr-xr-x  1 root wheel   78377 Jun 11  2025 bcm2712-rpi-5-b.dtb
-rwxr-xr-x  1 root wheel   78333 Jun 11  2025 bcm2712-rpi-500.dtb
-rwxr-xr-x  1 root wheel   79091 Jun 11  2025 bcm2712-rpi-cm5-cm4io.dtb
-rwxr-xr-x  1 root wheel   79157 Jun 11  2025 bcm2712-rpi-cm5-cm5io.dtb
-rwxr-xr-x  1 root wheel   79132 Jun 11  2025 bcm2712-rpi-cm5l-cm4io.dtb
-rwxr-xr-x  1 root wheel   79198 Jun 11  2025 bcm2712-rpi-cm5l-cm5io.dtb
-rwxr-xr-x  1 root wheel   78381 Jun 11  2025 bcm2712d0-rpi-5-b.dtb
-rwxr-xr-x  1 root wheel     331 Jun 11  2025 config.txt
drwxr-xr-x  1 root wheel   16384 Dec  7 20:25 overlays
If you tell us what type of arm64 board you have, somebody might be able to give you better answers.
 
dl8dtl said:
It's quite a bit smaller than the loader installed right now.
Click to expand...
Well, don't copy loader.efi then, unless you're ready to repair a non-bootable media. My experience says that the size tends to increase thru the versions, not shrink. It should be loader.efi, yet. I see no alternative.

I'm curious to read the solution. Yes, someone will give you a more sure answer.

I'm close to buy one of these machines, just to see. It's just, I won't know what to do with it. For me, it's more a gadget than a computer. :rolleyes:
 
Hmm, I see now that I failed to answer the question. Bad on me.
answer: yes, it should be loader.efi.
To add to the answer in #6;
- have a way to boot your machine from a different media handy (usb stick or SD card, whatever your machine needs)
- make a backup copy of the boot loader on the efi partition
- copy loader.efi over the boot loader on the efi partition (keep the name)
- if the new loader doesn't work, restore from your backup copy
 
Thanks, tingo, your RPi's bootcode size looks similar to my newly built loader.efi, so I used that one (under the name bootaa64.efi).
tingo said:
Some of the non-x86 boards (like the Raspberry Pi series) needs to have another partition to actually boot and / or load initial firmware from.
Click to expand...
The DTBs are lokated in /boot/efi/dtb here, rather than in a separate partition.
This is a RockPi board.

Tell you what, the newly copied (smaller :-)) loader worked:

Consoles: EFI console serial port
Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/arm64 EFI loader, Revision 3.0

Command line arguments: loader.efi
Image base: 0xf0e24000
EFI version: 2.80
EFI Firmware: Das U-Boot (rev 8224.1792)
Console: efi,comconsole (0)
Load Path: /efi\boot\bootaa64.efi
Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/NVMe(0x1,8c-e3-8e-03-00-52-15-ac)/HD(1,GPT,0c7b2499-a4cf-11ed-9ba6-0cc47ad8b808,0x8000,0x19000)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/NVMe(0x1,8c-e3-8e-03-00-52-15-ac)/HD(1,GPT,0c7b2499-a4cf-11ed-9ba6-0cc47ad8b808,0x8000,0x19000)
Setting currdev to disk0p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/NVMe(0x1,8c-e3-8e-03-00-52-15-ac)/HD(2,GPT,0c7b2499-a4cf-11ed-9ba6-0cc47ad8b808,0x21000,0x1d1a4948)
Setting currdev to zfs:zroot/ROOT:
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
Loading kernel...
/boot/kernel/kernel text=0x2a8 text=0x85cf90 text=0x1b5774 data=0x101aa8 data=0x0+0x2bb000 0x8+0xfb160+0x8+0x120517|
Loading configured modules...
/boot/kernel/zfs.ko text=0xada7c text=0x24e400 data=0x2d778+0xaad1c 0x8+0x35148+0x8+0x2e8e9
/boot/kernel/umodem.ko text=0x2040 text=0x13b0 data=0x6f8+0x4 0x8+0xeb8+0x8+0xb2c
loading required module 'ucom'
/boot/kernel/ucom.ko text=0x24ec text=0x3650 data=0x948+0x858 0x8+0x1188+0x8+0xafd
/etc/hostid size=0x25
/boot/entropy size=0x1000

Hit [Enter] to boot immediately, or any other key for command prompt.


So to summarize, the correct command (here) was indeed

# cp /boot/loader.efi /boot/efi/EFI/BOOT/bootaa64.efi

Thanks for all who participated!
 
For your script, the partition layout here looks that way:

# gpart show
=> 40 488397088 diskid/DISK-Z0HA32PEK2L2 GPT (233G)
40 32728 - free - (16M)
32768 102400 1 efi (50M)
135168 488261960 2 freebsd-zfs (233G)

Mind the quite a bit strange disk name …
 
Give me a bit of time, please.
As this one is my firewall system, I wouldn't want to use it for random tests. However, I have another RockPi with a comparable hardware setup that can be used for tests. I just have to pull it out from a drawer, and update it to a recent OS version. "make buildworld" takes more than a day on these tiny systems. ;-/
 
I found it …
rockpi.jpg
 
I notice one major difference in the setup to my firewall system:

root@rock:~ # gpart show
=> 40 250347440 mmcsd0 GPT (119G)
40 32728 - free - (16M)
32768 102400 1 efi (50M)
135168 230686720 2 freebsd-ufs (110G)
230821888 19525592 3 freebsd-swap (9.3G)

=> 40 500118112 diskid/DISK-S35ENX0K262963 GPT (238G)
40 500118112 1 freebsd-zfs (238G)

Here, the system uses UFS as root (on a large SD card), and while the SSD is ZFS, it's used as an additional storage only.
 
There is no risk if you use loaders-update in show-me mode as it won't change anything. It will probably tell you that the loaders are up-to-date.
 
I tried updating first, but a -current kernel panics with a stack overflow after seconds.
So returning to a FreeBSD 15 (-current of 1.5 years ago).

root@rock:/home/j/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.
Would run: cp /boot/loader.efi /boot/efi/EFI/BOOT/bootaa64.efi

-------------------------------
sysctl: unknown oid 'machdep.bootmethod'
Cannot get the boot method.
Updatable EFI loader: 1
-------------------------------

Well, bootmethod on arm64 is always UEFI. When I hack it hard to use UEFI, it says:

root@rock:/home/j/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.
Would run: cp /boot/loader.efi /boot/efi/EFI/BOOT/bootaa64.efi

-------------------------------
sysctl: unknown oid 'machdep.bootmethod'
Your current boot method is UEFI.
Boot device:
Updatable EFI loader: 1
-------------------------------

So I think it would do the right thing.
 
As my previous 16-current kernel panicked after seconds, I'm trying to update LLVM first now. That might take a while …
 
You must log in or register to reply here.
Back
Top