bootstd EFI bootmeth: network bootflow downloads EFI app but never becomes valid (err ‑22/‑114) on qemu_arm64
Ryan Persée
ryan.persee at gmail.com
Mon Mar 9 22:45:50 CET 2026
Hello,
As the title says, I'm trying to get u-boot to discover and boot an EFI
application (iPXE) over the network with DHCP+TFTP.
I can get the EFI application to start if I run commands (bootflow scan +
bootefi) manually, but after reading the documentation, I expected u-boot
to automatically register a bootflow after the scan, and run it
automatically.
## Environment
- U-Boot version: U-Boot 2026.01 (compiled from sources)
- Target: qemu_arm64
- EFI-related bootmeths present (from `bootmeth list`):
```text
=> bootmeth list
Order Seq Name Description
----- --- ------------------ ------------------
0 0 extlinux Extlinux boot from a block device
1 1 script Script boot from a block device
glob 2 efi_mgr EFI bootmgr flow
3 3 efi EFI boot from an .efi file
4 4 qfw QEMU boot using firmware interface
5 5 pxe PXE boot from a network device
glob 6 vbe_simple VBE simple
----- --- ------------------ ------------------
(7 bootmeths)
```
- To narrow down the issue, I restricted bootmeths to only the EFI loader:
```text
=> bootmeth order efi
=> bootmeth list
Order Seq Name Description
----- --- ------------------ ------------------
0 3 efi EFI boot from an .efi file
----- --- ------------------ ------------------
(1 bootmeth)
```
## Network/TFTP setup
- DHCP/TFTP server: `dnsmasq` on the host
- For ARM64 EFI clients (DHCP option 93 = 11), dnsmasq returns the bootfile
`arm64-efi/snp.efi`:
```ini
dhcp-match=set:arm64efi,option:client-arch,11
enable-tftp
tftp-root=/var/lib/tftpboot
dhcp-boot=tag:arm64efi,arm64-efi/snp.efi
```
- File on disk:
```bash
$ file /var/lib/tftpboot/arm64-efi/snp.efi
/var/lib/tftpboot/arm64-efi/snp.efi: PE32+ executable for EFI
(application), ARM64, 6 sections
```
So the TFTP payload appears to be a valid ARM64 EFI application.
## Steps to reproduce
1. Start QEMU with `qemu_arm64` and virtio-net pointing to the dnsmasq/TFTP
server.
2. Interrupt autoboot to get a U-Boot prompt.
3. Ensure only the `efi` bootmeth is active:
```bash
bootmeth order efi
bootmeth list
```
4. Set `fdt_addr_r`:
```bash
env set fdt_addr_r 0x44000000
```
5. Run a full bootflow scan with errors shown:
```bash
bootflow scan -lae
```
(Initially, before setting `fdt_addr_r`, I saw `err=-22` on the network
bootflow; after setting `fdt_addr_r` that changed to `err=-114` — see logs
below.)
## Observed behavior
### Before setting `fdt_addr_r` (for context)
When I first ran `bootflow scan -lae` with only `efi` enabled and **no**
`fdt_addr_r` in the environment, I saw:
```text
Scanning bootdev 'virtio-net#32.bootdev':
BOOTP broadcast 1
DHCP client bound to address 172.18.0.243 (2 ms)
Using virtio-net#32 device
TFTP from server 172.18.0.2; our IP address is 172.18.0.243
Filename 'arm64-efi/snp.efi'.
Load address: 0x40400000
Loading: #####################
11.7 MiB/s
done
Bytes transferred = 305664 (4aa00 hex)
6 efi base ethernet 0 virtio-net#32.bootdev.0
arm64-efi/snp.efi
** No media/partition found, err=-22
...
(7 bootflows, 0 valid)
```
So:
- DHCP and TFTP succeed.
- `bootfile` is `arm64-efi/snp.efi`.
- A bootflow entry is created but stays in `base` state and has `err=-22`.
- No bootflows are considered valid.
### After setting `fdt_addr_r`
After:
```bash
env set fdt_addr_r 0x44000000
bootflow scan -lae
```
I now get:
```text
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part Name Filename
--- ----------- ------ -------- ---- ------------------------
----------------
Scanning bootdev 'fw-cfg at 9020000.bootdev':
0 efi base qfw 0 <NULL>
** No media/partition found, err=-524
Scanning bootdev 'usb_mass_storage.lun0.bootdev':
1 efi media usb_mass_ 0 usb_mass_storage.lun0.boo
** No partition found, err=-2
2 efi media usb_mass_ 1 usb_mass_storage.lun0.boo
** No partition found, err=-2
3 efi media usb_mass_ 2 usb_mass_storage.lun0.boo
** No partition found, err=-2
4 efi media usb_mass_ 3 usb_mass_storage.lun0.boo
** No partition found, err=-2
Scanning bootdev 'virtio-blk#35.bootdev':
5 efi media virtio 0 virtio-blk#35.bootdev.who
** No partition found, err=-93
Scanning bootdev 'virtio-net#32.bootdev':
BOOTP broadcast 1
DHCP client bound to address 172.18.0.243 (2 ms)
Using virtio-net#32 device
TFTP from server 172.18.0.2; our IP address is 172.18.0.243
Filename 'arm64-efi/snp.efi'.
Load address: 0x40400000
Loading: #####################
4.9 MiB/s
done
Bytes transferred = 305664 (4aa00 hex)
6 efi base ethernet 0 virtio-net#32.bootdev.0
arm64-efi/snp.efi
** No media/partition found, err=-114
No more bootdevs
--- ----------- ------ -------- ---- ------------------------
----------------
(7 bootflows, 0 valid)
```
So with `fdt_addr_r` set:
- DHCP and TFTP still succeed; the same EFI binary is downloaded.
- The bootflow for `virtio-net#32.bootdev.0` stays in `base` state, now
with `err=-114`.
- There are still `(0 bootflows, 0 valid)`.
- No attempt to actually execute the downloaded EFI application is visible
on the console.
Separately, `file(1)` on the TFTP payload shows:
```text
/var/lib/tftpboot/arm64-efi/snp.efi: PE32+ executable for EFI
(application), ARM64, 6 sections
```
## Expected behavior
Given that:
- The EFI bootmeth (`efi`) is present and enabled.
- The network bootdev (`virtio-net#32.bootdev`) successfully completes DHCP
and downloads the bootfile.
- The bootfile is a PE32+ ARM64 EFI application on disk.
I expected:
- A bootflow for `virtio-net#32` to reach a “ready” or equivalent state
(i.e. no error), and
- `bootflow scan -b` to attempt to execute the downloaded EFI application
via the EFI loader.
Instead, the bootflow remains in `base` state with `err=-22` (before
setting `fdt_addr_r`) or `err=-114` (after setting `fdt_addr_r`), and is
not considered valid, so it never gets booted.
## Notes
- This is all on QEMU (`qemu_arm64`), but my end goal is to use the EFI
bootmeth to automatically boot into iPXE on real ARM64 hardware using the
same network flow.
- Running `bootefi` manually after DHCP+TFTP fetched the file does work:
```text
=> bootefi 0x40400000
Booting /arm64-efi\snp.efi
iPXE initialising devices...
iPXE 1.0.0+ -- Open Source Network Boot Firmware -- https://ipxe.org
Features: DNS FTP HTTP HTTPS iSCSI NFS TFTP VLAN AoE EFI Menu
net0: 52:54:00:12:34:56 using SNP on SNP-0xbe690010 (Ethernet) [open]
[Link:up, TX:0 TXE:0 RX:0 RXE:0]
Configuring (net0 52:54:00:12:34:56)...... ok
net0: 172.18.0.243/255.255.0.0 gw 172.18.0.1
net0: fe80::5054:ff:fe12:3456/64
Next server: 172.18.0.2
...
```
Can you please help me on this? And/or explain what I'm doing wrong?
Kind regards.
More information about the U-Boot
mailing list