Hello

I flashed EDK2 to SPI and  I am able to enter the UEFI menu and change things, but it seems that u-boot takes over the boot process to actually boot the kernel.

 

I also built a custom resolute image using the command below which I flashed to SDCard:
 

Quote

./compile.sh BOARD=rock-5-itx RELEASE=resolute BUILD_DESKTOP=no BUILD_MINIMAL=yes EXT=uefi-edk2-rk3588 UEFI_EDK2_BOARD_ID=rock-5-itx  CLEAN_LEVEL=make

Then I added a Grub entry for the SDCard image with this custom build but when I boot it it shows that u-boot is being used not UEFI. 

 

Quote

[Sep23 19:43] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[  +0.000000] Linux version 7.1.13-edge-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #4 SMP PREEMPT Wed Sep  2 12:32:39 UTC 2026
[  +0.000000] KASLR enabled
[  +0.000000] Machine model: Radxa ROCK 5 ITX
[  +0.000000] efi: EFI v2.11 by Das U-Boot

 

The default Grub boot is from emmc with an EFI FAT32, /boot EXT4, and / F2FS which is  armbian trixie, and it works well - but  with u-boot so I am trying to test how booting via pure UEFI will work so I can migrate to a pure UEFI setup on EMMC as the default - but the custom image is not  preventing u-boot from taking over the boot sequence. I am not sure  I need to flash something to emmc first to prevent u-boot because u-boot takes over before grub and then the custom image starts to boot. 

 

Q: What do I need to do to switch to a pure UEFI boot sequence?

Edited September 23Sep 23 by Raul

3 hours ago, Raul said:

BOARD=rock-5-itx

If you use this instead of BOARD=uefi-arm64 the image will be tailored for rock-5-itx and contain the U-Boot binary on the SD-card (written between sectors 34-32k ) and the EDK2 in the SPI will detect that and chainload that U-Boot. Also then that U-boot will find boot.scr which takes precedence over generic UEFI via file efi/boot/bootaa64.efi.

 

So wipe the U-Boot would make EDK2 use itself and use the EFI bootmethod. Or rename/hide boot.scr, then the U-Boot is still used, but it will then use its EFI loader to also load efi/boot/bootaa64.efi but it usually does not initialize non-critical things like HDMI, so you might see blank screen first.

In general, Armbian mainlinae based kernels, at least rockcchip64, understands all about UEFI, so you can keep the image or work done so far. You can simply add a general arm65 kernel or so, if new enough, it will include all drivers/HW about RK3588. I have the ROCK5B, is very flexible, same as the ITX.

Thanks. So if I switch to  BOARD=uefi-arm64  then the armbian build will create an image without the u-boot components and it will boot purely in uefi mode? My doubts are around what happens in the pre-boot stage before the kernel itself loads - uefi needs to read the EFI partition and present the grub menu - so how does the custom image stop this process? What do I need to do so that entire boot chain is limited to EDK2/UEFI from the pre-boot stage itself?

8 minutes ago, Raul said:

So if I switch to  BOARD=uefi-arm64  then the armbian build will create an image without the u-boot components and it will boot purely in uefi mode?

yes

9 minutes ago, Raul said:

so how does the custom image stop this process?

as I mentioned; an RK3588 wirh EDK2 in SPI will load U-Boot from SD-card (if it is there)

 

10 minutes ago, Raul said:

What do I need to do so that entire boot chain is limited to EDK2/UEFI from the pre-boot stage itself?

as I mentioned, wipe U-Boot from SD-card; use dd to zero sectors 34-32767. 

 

 

But maybe first make clear what partitions you have, for example use:

sudo lsblk --raw --bytes --output SIZE,START,NAME,FSTYPE,LABEL,UUID,MOUNTPOINTS /dev/mmcblk0
 

Thanks for your suggestions so far. 
 I built an image using the following parameters (see end of post) and now it boots pure uefi:

 

Quote

[Sep29 20:58] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[  +0.000000] Linux version 6.18.46-current-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #4 SMP Sun Aug 23 12:27:10 UTC 2026
[  +0.000000] KASLR enabled
[  +0.000000] Machine model: Radxa ROCK 5 ITX
[  +0.000000] earlycon: uart8250 at MMIO32 0x00000000feb50000 (options '')
[  +0.000000] printk: legacy bootconsole [uart8250] enabled
[  +0.000000] efi: EFI v2.7 by EDK II
...
[  +0.001102] SMBIOS 3.3.0 present.
[  +0.000302] DMI: Radxa ROCK 5 ITX/ROCK 5 ITX, BIOS v1.1 04/09/2025
 

 

This seems to have created an sdcard image without the u-boot after dd command, because now I got a grub menu and still booted the old EMMC system but without the system finding any traces of u-boot to kick-in.

 

Not sure about =uefi-arm64  as it seems to be too generic:

 

Quote

# aarch64 via UEFI for all UEFI-enabled boards
declare -g BOARD_NAME="UEFI arm64"
declare -g BOARD_VENDOR="generic"
declare -g BOARDFAMILY="uefi-arm64"
declare -g BOARD_MAINTAINER="igorpecovnik rpardini"
declare -g INTRODUCED="2022"
declare -g KERNEL_TARGET="current,edge,legacy,cloud"
declare -g KERNEL_TEST_TARGET="current"
declare -g BOOT_LOGO=desktop

 

vs rock-5-itx seems more accurate: https://github.com/armbian/build/blob/main/config/boards/rock-5-itx.conf

 

Quote

# Rockchip RK3588 SoC octa core 4-16GB SoC 2.5GBe eMMC USB3 NvME
BOARD_NAME="Rock 5 ITX"
BOARD_VENDOR="radxa"
BOARDFAMILY="rockchip-rk3588"
BOARD_MAINTAINER="amazingfate prahal"
INTRODUCED="2023"
BOOTCONFIG="rock-5-itx-rk3588_defconfig"
KERNEL_TARGET="current,edge,vendor"
KERNEL_TEST_TARGET="vendor,current"
FULL_DESKTOP="yes"
BOOT_LOGO="desktop"
BOOT_FDT_FILE="rockchip/rk3588-rock-5-itx.dtb"
BOOT_SUPPORT_SPI="yes"
IMAGE_PARTITION_TABLE="gpt"
declare -g UEFI_EDK2_BOARD_ID="rock-5-itx" # This _only_ used for uefi-edk2-rk3588 extension

 

I used the following in my compile command : 
 

Quote

./compile.sh   BOARD=rock-5-itx   RELEASE=trixie   BUILD_MINIMAL=yes   BUILD_DESKTOP=no   CLEAN_LEVEL=make  INSTALL_HEADERS=yes BOARD_VENDOR=radxa IMAGE_PARTITION_TABLE=gpt BOOTPART_REQUIRED=yes  UEFI_EDK2_BOARD_ID=rock-5-itx  ENABLE_EXTENSIONS=watchdog,uefi-edk2-rk3588,kernel-rust,grub-with-dtb,r8125-dkms
 

 

This is a sample command that worked for me.  Now I am running from sdcard with a pure uefi boot using my custom Armbian build.

Edited September 29Sep 29 by Raul

I have a ROCK5B running 24/7 as server (custom powering/UPS) for NAS, KVM, and has EDK2 UEFI v1.1 in MTD/SPI-flash, initially set to 'vendor' so I could boot vendor 6.1.x based kernel, but set to- and using mainline based since kernel 6.19 was released. This can be the Armbian -rockchip64 variant (edge or bleedingedge), but normally Debian Sid standard arm64 kernel (done via apt pinning), now at 7.2.8 and not a single issue, all works as expected. Of course certain RK vendor features like HW video encoding don't work, but I find it more important that I use a mainline based kernel.

 

The same ROCK5B also can boot vanilla Opensuse Tumbleweed, it can even boot from an USB installer stick and install the traditional way, like for a PC. That then needs the boot partition to be FAT32 formatted, either for grub-efi or grub-bls or systemd-boot. AFAIR EDK2 UEFI v1.1 can read Ext4, but not sure. For generic UEFI capable computers, you cannot assume that, so I simply settled for 1 FAT32 partition, 1 Btrfs rootfs partition and a swap partition. I all constructed that manually as images don't work if you want to run more than 1 Linux distro (or any other OS, like FreeBSD or MS-Windows).

 

I do not know if BOOTPART_REQUIRED=yes implies FAT32 formatted and tagged type ESP (0xEF00). Last time I used it it was XBOOTLDR type, not something a PC or RPi4/5 or EDK2 used for libvirt/KVM/QEMU accepts. If you never clone systems to other ARM SoCs it might not matter, but I keep all the same/aligned, so 'pure UEFI' might mean something else for you than for me. For example, the rootfs running on the ROCK5B will run unmodified on my RPI4 as I also use EDK2 UEFI there. Same for a testing clone in a KVM on NanoPi-R6C for example.

 

The DTB included in EDK2 UEFI v1.1 is kernel 6.10 based AFAIR, that is good enough for all-round Linux if enough RK3588 options are enabled in the kernel, which is of course the case for Armbian -rockchip64 kernels but also for rolling release/latest distro kernels. So in practice, I don't see/notice a difference between 7.2.x Armbian rockchip64 and 7.2.x Debian Sid arm64 and 7.2.x Opensuse Tumbleweed aarch64 and 7.2.x Armbian uefi-arm64. There are big differences, but will need looking into the respective kernel config files. 

 

I see all options are listed here: https://docs.armbian.com/build-framework/extensions/list/

So is a matter of reading. Maybe I do a test build for my ROCK5B and see if I can generate it the way I use and have it. I remember the grub-with-dtb is not compatible with how I want/use DTB's but it should work. Also uboot-btrfs option is great for smaller SBC's, no need to manually build U-Boot from denx.de what I did in the past. 

 

If 'something with grub' is done or installed, you can assume that U-Boot is not written into the image as that simply would ruin the desired behavior. Unless you have or want 'grub-uboot' package installed, but I think this is not supported by Armbian Build.

Ok I need bootpart separate because I will be encrypting my emmc rootfs and all disks on my NAS system.

 

"I do not know if BOOTPART_REQUIRED=yes implies FAT32 formatted and tagged type ESP (0xEF00)." - Yes it does that.

 

Quote

mmcblk1                                                                                                
├─mmcblk1p1  vfat        FAT32    ARMBI_EFI      XXXX-XXXX                                boot
├─mmcblk1p2  ext4        1.0      armbi_root     <UUID>     
 

 

The BOOTFS_TYPE=ext4 also works  (but my current sdcard image boot is fat32) and both options create a combo Boot+EFI partition with EXT4 and not a separate EFI(FAT32), /boot(EXT4) and / partition - I suppose the Armbian version can read EFI from ext4 as they would not support it otherwise. 

 

"The DTB included in EDK2 UEFI v1.1 is kernel 6.10 based AFAIR, that is good enough for all-round Linux" - I was wondering about the difference between the regular dtb and full-dtb - its on my research items list after I am done booting an encrypted rootfs from emmc tomorrow.   

 

 

Cheers!

Edited October 1Oct 1 by Raul