Raul

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. 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!

Thanks for your suggestions so far. I built an image using the following parameters (see end of post) and now it boots pure uefi: 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: vs rock-5-itx seems more accurate: https://github.com/armbian/build/blob/main/config/boards/rock-5-itx.conf I used the following in my compile command : 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.

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?

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: 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. 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?

Hello Everytime I reboot I have to wait many minutes before the NIC auto-negotiates and connects. The problem seems to be at the PHY layer as the LED does not light up at all ... see time span between 23:22:20 and 23:23:52 : Why is this happening? Only enP3p49s0 is plugged in and NetworkManager-wait-online.service is disabled. Thanks

Hello I built the core minimal image successfully a few times while I was experimenting with kernel config options and then finally when I enabled all the settings I wanted somehow a different component of the build process started failing repeatedly since last few days: Why is this happening. All I did was edit linux-rockchip-rk3588-edge.config and symlink linux-rockchip-rk3588-current.config -> linux-rockchip-rk3588-edge.config

On my Rock5 ITX I am currently manually setting fan speed using commands like : ``` echo 32 | tee /sys/devices/platform/pwm-fan/hwmon/hwmon12/pwm1 ``` bump numbers to 64/128/256 for higher speeds. Change the hwmon/hwmon* number to match what your OS uses ... Sometimes the machine boots with 100% fan speed that does now slow down after full boot and I have to manually set it like this. At other times it boots up normally with low fan speed. Not sure why Armbian does not use sensors by default to scale fan speeds automatically based upon temperature. But later this week I will add the script before I start applying more load/apps to my system.