All Activity

Hello to regular contributors and everybody who are interested in this issue! I am late to the thread, as I had to decommission my production setup based on Espressobin V5 before trying everything out. Finally I've completed Physical-to-Virtual migration using QEMU and made board available for this new experience. As @bschnei made his developments community available It was also worth for me making my findings accessible for general public thus improving Espressobin support. I forked @bschnei repo https://github.com/bschnei/ebu-bootloader to my Github https://github.com/quiseleve/espressobin-bootloader and made several changes to build bootloaders for Espressobin V5 and V7. Here are the final changes brought to @bschnei repo : root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git remote add upstream https://github.com/bschnei/ebu-bootloader.git root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git fetch upstream From https://github.com/bschnei/ebu-bootloader * [new branch] main -> upstream/main root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git diff --stat upstream/main...main .github/workflows/build.yml | 92 ++++++++++++++++++++++++++++++++++++++++++--------------------------------- Makefile | 2 ++ patches/0001-fix-tfa-fip-build-behavior.patch | 36 +++++++++++++++++++++++++++++ 3 files changed, 90 insertions(+), 40 deletions(-) This allowed building bootload firmware directly in Github's Workflow and trying them out over UART 1st before flashing it to onboard SPi. ./mox-imager -D /dev/ttyUSB0 -b 3000000 -E flash-image-v5_2GB.CPU_1000_DDR_800.bin Although Workflow run builds both v5 and v7 variants, I tested 2Gb RAM v5 board, as my 1Gb v7 is currently in production, but there is a high confidence level, that v7 works as well. DDR_TOPOLOGY variable used for my specific v5 motherboard : Memory Type: DDR3 Total Capacity: 2 GB Bus Width: 16-bit Chip Selects (CS): 2 (Dual CS) It is worth saying that I built initially the 1.2GHz bootloader, but it appeared worthless, as my physical silicon turned out to be limited to 1GHz only. I found it by retrieving a 32-bit hex string for v5 board : => md 0xd0012604 1 d0012604: 19896301 .c.. => This hex string gives us the definitive answers we need. In the Marvell Armada 3720 architecture, this specific register reads from the factory OTP (One-Time Programmable) fuses. The lower bits define the chip's official Speed Bin Index: 0 = 800 MHz Maximum 1 = 1000 MHz (1.0 GHz) Maximum 2 = 1200 MHz (1.2 GHz) Maximum Because my board register ends in 01, my specific SoC is officially rated by the factory for a maximum clock speed of 1000 MHz (1.0 GHz). This completely explains why the WTMI secure firmware threw the invalid voltage error when I forced a 1.2 GHz build. The chip physically lacks the factory-fused voltage calibration profile for the 1.2 GHz tier because it wasn't born as a 1.2 GHz chip. Thus I decided changing the Build Target to 1.0 GHz. More discussions could be found here as well : I've also built Armbian-unofficial 26.5.2 sid image to assess overall compatibility. Here is an excerpt from initial boot logs directly from the bootloader initiation : TIM-1.0 mv_ddr-devel-g7bcb9dc DDR3 16b 2GB 2CS WTMI-devel-18.12.1-f423ac6 WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V Setting clocks: CPU 1000 MHz, DDR 800 MHz CZ.NIC's Armada 3720 Secure Firmware v2024.04.15 (Jul 9 2026 20:33:31) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):sandbox/v2.14 NOTICE: BL1: Built : 20:33:33, Jul 9 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):sandbox/v2.14 NOTICE: BL2: Built : 20:33:35, Jul 9 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):sandbox/v2.14 NOTICE: BL31: Built : 20:33:36, Jul 9 2026 U-Boot 2026.04-dirty (Jul 09 2026 - 20:32:03 +0000) DRAM: 2 GiB Core: 48 devices, 24 uclasses, devicetree: separate WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 Hit any key to stop autoboot: 0 MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1664 bytes read in 25 ms (64.5 KiB/s) ## Executing script at 06d00000 144 bytes read in 19 ms (6.8 KiB/s) 28134196 bytes read in 1702 ms (15.8 MiB/s) Wrong Image Type for bootm command ERROR -91: can't get kernel image! 37059072 bytes read in 2231 ms (15.8 MiB/s) 18537158 bytes read in 1121 ms (15.8 MiB/s) 12062 bytes read in 35 ms (335.9 KiB/s) ## Loading init Ramdisk from Legacy Image at 0a000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 18537094 Bytes = 17.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Working FDT set to 6f00000 Loading Ramdisk to 7d940000, end 7eaeda86 ... OK Loading Device Tree to 000000007d93a000, end 000000007d93ff1d ... OK Working FDT set to 7d93a000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 261.1-2 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.42.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 armbi_root: clean, 28918/949664 files, 425190/3849216 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian-unofficial 26.5.2 sid! [ OK ] Created slice system-getty.slice - Slice /system/getty. [ OK ] Created slice system-modprobe.slice - Slice /system/modprobe. [ OK ] Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty. [ OK ] Created slice user.slice - User and Session Slice. [ OK ] Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch. [ OK ] Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch. [ OK ] Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point. Expecting device dev-ttyMV0.device - /dev/ttyMV0... [ OK ] Reached target imports.target - Image Downloads. [ OK ] Reached target remote-fs.target - Remote File Systems. [ OK ] Reached target slices.target - Slice Units. [ OK ] Reached target swap.target - Swaps. [ OK ] Listening on syslog.socket - Syslog Socket. [ OK ] Listening on systemd-ask-password.socket - Query the User Interactively for a Password. [ OK ] Listening on systemd-creds.socket - Credential Encryption/Decryption. [ OK ] Listening on systemd-factory-reset.socket - Factory Reset Management. [ OK ] Listening on systemd-hostnamed.socket - Hostname Service Socket. -- Boot 3e598d120dc346829e12f836344429a1 -- Jul 11 00:11:05 espressobin kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034] Jul 11 00:11:05 espressobin kernel: Linux version 6.12.95-current-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0> Jul 11 00:11:05 espressobin kernel: 5:185m5:185mKASLR disabled due to lack of seed Jul 11 00:11:05 espressobin kernel: Machine model: Globalscale Marvell ESPRESSOBin Board Jul 11 00:11:05 espressobin kernel: efi: UEFI not found. .. Jul 11 00:11:05 espressobin kernel: armada_37xx_wdt d0008300.watchdog: Initial timeout 120 sec Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: host bridge /soc/pcie@d0070000 ranges: Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: MEM 0x00e8000000..0x00efefffff -> 0x00e8000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: IO 0x00efff0000..0x00efffffff -> 0x0000000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: issuing PERST via reset GPIO for 10ms Jul 11 00:11:05 espressobin kernel: mvneta d0030000.ethernet end0: renamed from eth0 .... This bootloader seems to deliver many if not all of its promises to name few of them: cpu frequency scaling is operational : root@espressobin:~# cpupower frequency-info analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 1000 us hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 250 MHz (asserted by call to kernel) Entropy and random number generation (RNG) issue seems to have been resolved as bschnei's ebu-bootloader fork explicitly includes patches to fix this. The ebu-bootloader patches bypass the OS entirely and tackle the problem before Linux even starts. When Linux kernel boots, it immediately detects this perfect cryptographic seed provided by U-Boot and uses it to instantly initialize the OS-level Cryptographic Random Number Generator (CRNG). Here is my kernel ring buffer timestamps: root@espressobin:~# dmesg | grep -E "crng|random" [ 11.785705] systemd[1]: Starting systemd-random-seed.service - Load/Save OS Random Seed... [ 13.071384] random: crng init done [ 13.398576] systemd[1]: Finished systemd-random-seed.service - Load/Save OS Random Seed. The bootloader and kernel working together fixed the entropy pool in exactly 13.07 seconds from the moment the Linux kernel started executing. Because crng init done happened before the systemd service even finished writing to the disk, it proves the kernel didn't just rely on slow user-space disk jitter. The hardware security engine initialized almost immediately. Because the ebu-bootloader fork compiled correctly patches, the underlying Trusted Firmware-A (TF-A) and the secure processor (WTMI-devel), the hardware crypto mailboxes are wide open and working perfectly the moment Linux asks for them. You don't even need haveged or any software workarounds. Your hardware is resolving its own entropy natively in just over a second from user-space initialization! U-Boot UEFI Support is out of the box as well. I am booting seemlessly both legacy OS (from my old production setup) as well a new OS build which I used for this testbed root@espressobin:~# cat /etc/debian_version forky/sid root@espressobin:~# uname -a Linux espressobinv5 6.12.95-current-mvebu64 #1 SMP PREEMPT Sat Jul 4 11:43:36 UTC 2026 aarch64 GNU/Linux

hello, for s905w2 is this rom working?

this post started 2023 & some engineers told that armbian does not support S905W2 . its 2026. ... did someone try ? for s905w2 does this rom well work? please tell me "YES" bc i need a armbian for S905w2 @SteeMan @Devmfc

hello. i read top post & ....S905w2... I need a armbian for s905w2 can i use this rom ? link

Hey, thanks for the PSU suggestion! I actually tested the power theory by stripping all USB accessories (dongles, hubs, keyboard) and running just the board + HDMI, but it still drops to initramfs. I also know the PSU and hardware are 100% good because DietPi boots perfectly on this exact same setup. I dug around in the initramfs shell and ran blkid. Here is the output: /dev/mmcblk1: PTUUID="[uuid]" PTTYPE="gpt" The issue: The kernel sees the raw SD card, but it's completely blind to the partitions (p1, p2). It looks like this specific build might be missing the ext4 drivers in the initramfs, which is why it can't find the UUID to mount the rootfs. For the devs, here is the exact image causing the issue: Armbian_26.2.1_Radxa-zero3_trixie_vendor_6.1.115_minimal.img (Flashed via BalenaEtcher, verified successfully, and ignored all Windows format prompts). I'm switching over to the official Radxa Debian image for now so I can finally get my onboard AIC8800 Wi-Fi working, but I wanted to drop these debug notes here in case this is a regression in the recent build.

It's just an old armhf "armV7" kind of thing, but thanks to it will work for more Ai content.

It's and old Allwinner chip, ARMv7-based. GPU is PowerVR SGX544MP1, which is not supported in Mesa and will not work in Armbian. Wi-Fi is AP6212, a Broadcom/Synaptics SYN43436S chip, should work fine. Armbian build for M3 is community-supported, by @AaronNGray. Maybe they'll shed more light on this board.

The other usual thing is then PSU. So also maybe try a different one. Else I cannot really help you, not being able to find rootfs can have pure software cause, but is unlikely if other people can run it successfully. I wish I had bought this SBC a year ago, but I didn't and now they are sold out where I looked, so cannot see If I can reproduce the problem. You need to look in more detail yourself, like connecting serial debug console and setting loglevel to 7 in armbianEnv.txt. Also post which exact image is (sha256sum), so other people can try the same thing.

I also thought the same so i was using a sandisk 32 gb sd card so i switched to samsung 64 gb one but same issue in it also, i think the problem is something else.

If it worked once and now not anymore, it might be the SD-card that is the problem. It might be a as bad that it is a fake SD-card.

I've also encountered this. SATA fails on some drives but not others. Possibly related to how much power they draw.

I've added a ton of info. I can provide logs if needed. This is a bug with Armbian and/or uboot. I believe I've traced it to the preboot code, so that would be uboot? https://github.com/armbian/build/issues/9532 https://lists.denx.de/pipermail/u-boot/2026-July/624426.html I have two versions of Armbian, one works and one doesn't: Armbian_26.5.1_Odroidhc4_trixie_current_6.18.33_minimal.img.xz - fails Armbian_25.8.1_Odroidhc4_bookworm_current_6.12.41_minimal.img.xz - works

Moved post to the correct forum section

Hello Im a begginer and dont know Linux. I have a tv box : enyBox x98q Cpu amlogic s905w2 2g ram 16g rom My need to install MetaTrader5 on linux on this tv box. I downloaded both files on site this link: debian 13 ubuntu 26.04 I need to learn the install way by watching a video clip. I request you for making it

Does anyone have an image version 24.11.0-trunk.351? It seems they have been purged. Also, what is the latest working image for jetson nano?

Same thing is happeing with me at first it booted correctly with armbian imager then suddenly it crashed and after that whenever i tried to flash it using armbian imgaer its giving error of initramfs , btw iam using Radxa zero 3w , any solution or any step iam doing wrong , i have tried it with different imager but same problem.

Hello @4A studio ,I'm sorry for the late reply. I accidentally installed the image to a partition on the Micro SD card using the `dd` command (of=/dev/sd*2). I eventually resolved the issue by using the correct `dd` command (of=/dev/sd*).

@bedna Thanks for the pointers, I'll try tonight or tomorrow. And yes, my plan was to set up a swap file on the SSD. @SteeMan I don't know if I'm doing something else wrong, but on my /etc/default/armbian-zram-config I have ENABLED=false and SWAP=false, but I keep seeing the swap mounted on lsblk and listed on htop

Similar quick test here: N100 with PCIe ethernt and wifi HW, already a br0 with enslaved ethernet, I set up a working hostapd.conf, enabled hostapd.service and added /etc/systemd/network/22-wlp2s0.network [Match] Name=wlp2s0 [Network] Bridge=br0 ConfigureWithoutCarrier=yes Then reboot and properly working AP. Is Opensuse Tumbleweed. But it is rather 'static', not as flexible/dynamic as with NM. For example, if I do networkctl down wlp2s0 ; sleep 30 ; networkctl up wlp2s0 the AP still works, but network list shows failed for wlp2s0 I though maybe it has to do with the fact that Tumbleweed has no sysV compatibility anymore (folder /etc/init.d/ is not there), so no option that something goes wrong potentially due to some sync issues, but I think I cannot draw that conclusion. Quick check shows no relation between hostapd.service and systemd-networkd, but it is much more extensive than for debian13 for sure.

It has been offically supported. Thanks! https://armbian.com/boards/norco-emb-3531

This should be specified down to just 2 things: Armbian U-Boot package and kernel package. The DTB package is redundant as the .dtb file is in the kernel package. For more low-level tests, I usually rename boot.scr and use manual extlinux, so easy to select a certain kernel+initrd+dtb(o). This also works for example with Opensuse Tumbleweed as userspace although (Wayland KDE ) GUI not anymore with vendor 6.1.115. For just standard Ext4 rootfs, note that multiple kernels is automatically handled by standard Debian package u-boot-menu (see its config in /etc/default/u-boot).

Hi @Kwiboo and Armbian rk35xx maintainers, I'm hitting a boot-time eMMC reliability issue on NanoPi R76S with the current Armbian U-Boot 2026.04 build, and the community-known workaround from OpenWrt PR #23520 breaks kernel boot completely in our Armbian environment. Sharing detailed reproduction and requesting guidance. ## Setup - Board: NanoPi R76S (RK3576), 4GB LPDDR5, 64GB Hynix eMMC (hC8aP, manfid 0x000090) - Armbian build: derived from 26.5.1, `linux-u-boot-nanopi-r76s-vendor 26.5.1` - U-Boot: 2026.04_armbian-2026.04-S88dc-P3cfe-H30d2-V3c1d-Bd0d2-R448a - Kernel: 6.1.115-vendor-rk35xx (Armbian rk35xx vendor kernel) - BL31: v2.3 fwver v1.20 ## Baseline Symptom (Reproducible ~50%) `sudo reboot` from Linux → SPL/BL31/U-Boot proper OK → boot.scr loads (255 B) → first `ext4load` of kernel Image fails with `fs_devread read error - block`. Second `ext4load` also fails, block layer reports `No partition table - mmc 0`. Reproduction across both warm reboot and cold power cycle. Matches OpenWrt issue #23491 exactly. Interestingly `mmc rescan` in U-Boot prompt re-reads mmc info (58.2 GiB Hynix detected, partition table intact) but subsequent `boot` command still fails — suggesting U-Boot driver leaves stale state that even a manual rescan cannot clear. ## Attempted Workarounds (All Failed in Our Environment) ### v1: 26 MHz variant (aggressive) - U-Boot embedded DT `mmc@2a330000`: dropped `cap-mmc-highspeed`, `mmc-hs400-1_8v`, `mmc-hs400-enhanced-strobe`; set `max-frequency=<26000000>` - Kernel DT overlay (same node): same property removal + 26 MHz - Result: `Starting kernel ...` reached, then **immediate hang, no dmesg**. ### v2: OpenWrt PR #23520 exact patch (52 MHz, U-Boot only) - U-Boot DT: kept `cap-mmc-highspeed`, removed only `mmc-hs400-1_8v` and `mmc-hs400-enhanced-strobe`; set `max-frequency=<52000000>` (52 MHz HS) - Kernel DT: untouched (HS400ES) - Result: U-Boot loads kernel at 44.5 MiB/s (HS speed confirmed), reaches `Starting kernel ...`, then **hang, no dmesg**. ### v3: Symmetric 52 MHz on both U-Boot and kernel DT - U-Boot DT: same as v2 - Kernel DT overlay: removed HS400 properties + 52 MHz cap - Result: identical hang after `Starting kernel ...`. Observation: **any modification to U-Boot's embedded DT for mmc@2a330000 appears to make the Armbian vendor kernel silently fail before earlycon initialization.** The stock Armbian U-Boot + stock kernel DT combination boots kernel reliably (log flushes normally), but exhibits the ~50% warm-reboot bug. Rolling back U-Boot to the original (via slot B rootfs `u-boot.itb`) restores kernel boot immediately. ## Questions 1. Has anyone successfully applied OpenWrt PR #23520's workaround (or any variant) to Armbian's vendor kernel on RK3576? If so, what was the specific property combination? 2. Is this a known incompatibility between the mainline U-Boot mmc probe path and the Armbian rk35xx vendor kernel's dw_mshc driver? The Rockchip PSCI handoff seems to fail silently before console_init. 3. Would upgrading to U-Boot 2026.07 (just released) help? My search showed zero mmc/sdhci commits in v2026.04..v2026.07 range for rockchip. Am I missing a Karlman patch series that isn't yet in Armbian's fork? 4. Any suggested next step: (a) chase FriendlyElec BSP U-Boot behavior, (b) patch the vendor kernel's dw_mshc probe to handle inherited controller state, or (c) accept as known-limitation until Armbian moves to kernel 6.6+? 5. If (b), which specific probe/reset path in `drivers/mmc/host/dw_mmc-rockchip.c` or `sdhci-of-dwcmshc.c` should we audit? Any references to similar rk3588 handoff issues that were resolved? Full boot logs (successful, failed variants v1/v2/v3, rollback recovery) available on request. Willing to test patches against test board and report back with UART logs. Thanks for maintaining rockchip U-Boot, Peter Rim Related: - https://github.com/openwrt/openwrt/issues/23491 - https://github.com/openwrt/openwrt/pull/23520 - https://github.com/armbian/build/pull/9869 (R76S migration to v2026.04) rk3576-mmc-bug-attachments.tar.gz

Then I don't know why it does not work, and I would assume this combination of SBC and NVME just won't work. Such cases exists, although frustrating that is does not work. You could cross check, but I don't know it you have other brands NVME to try with the OPi5 Ultra. I would also be not surprised if there is simply something wrong of missing in the U-Boot or DTB (all versions, even the one from manufacturer/xunlong). You can look at versions history of U-Boot for example, just to see how much your luck is or would be. And/or until someone with the same combination sees this topic. I only have Samsung NVME's. primarily 970+ in a ROCK5B, is also RK3588 4-lane PCIEv3 and older earlier 970 in an ROCK3A (2-lane PCIEv3). The latter one works but only with a very specific set of U-Boot, BTB and kernel (for my use case).

Introduction This guide describes a tested method for running Android, Armbian, and Ubuntu on the same NVMe SSD of the Orange Pi 5 Plus. This is not an official Orange Pi installation procedure. The entire workflow was developed through extensive real-world testing. The following configuration has been successfully verified: ✅ Android boots from the NVMe SSD. ✅ Armbian boots from the same NVMe SSD via UEFI. ✅ Ubuntu boots from the same NVMe SSD via UEFI. ✅ All three operating systems coexist on a single NVMe SSD. ✅ Armbian and Ubuntu share the same EFI partition. ✅ Android, Armbian, and Ubuntu can share a common data partition. 1. Requirements Hardware Orange Pi 5 Plus. An NVMe SSD (the larger the better, and it must have a larger capacity than the eMMC to provide free space for Armbian and Ubuntu). A 16GB or 32GB eMMC module (16GB recommended). A microSD card for UEFI. A PC/Laptop or an NVMe USB enclosure for partition management. A microSD card can also be used instead of eMMC for Android, but a large-capacity card is not recommended because it reduces the available space for Linux on the NVMe SSD. Software Android ROM (tested and verified; the AGTV ROM can be flashed directly to the eMMC using rkdeveloptool). Armbian. Ubuntu. UEFI image. BalenaEtcher, Rufus, or any software capable of writing IMG files to a microSD card. A partition manager such as GParted, DiskGenius, or MiniTool Partition Wizard. 2. Boot Method Android Android uses the standard Rockchip boot process. Requirements: The SPI flash must be empty or completely erased. Android boots directly from the NVMe SSD. Armbian and Ubuntu Armbian and Ubuntu boot through UEFI. Write the UEFI image to a microSD card. Insert the microSD card whenever you want to boot Linux. Both operating systems share the same EFI partition on the NVMe SSD. 3. NVMe Partition Layout The NVMe SSD contains two groups of partitions. Android Keep all Android system partitions intact, for example: boot vendor_boot dtbo vbmeta super metadata userdata ... Do not modify any Android system partition. Linux Create the following additional partitions: EFI Armbian RootFS Ubuntu RootFS Data The Data partition can be shared between Armbian and Ubuntu. 4. Preparing Android Flash Android to the eMMC. Boot Android and verify that everything works correctly. Boot Armbian or Ubuntu from a microSD card or an external SSD (this Linux installation will later be used to copy its RootFS to the NVMe SSD after partitioning). Back up the entire eMMC using the dd command. Restore the Android image from the eMMC to the NVMe SSD using dd. After this step, the NVMe SSD will contain the complete Android partition layout. Since the NVMe SSD is larger than the eMMC: The beginning of the NVMe SSD will contain all Android partitions. The remaining space will remain Unallocated, which will later be used for the Linux partitions. Next, erase all data on the eMMC and remove the eMMC module from the Orange Pi 5 Plus. Then power on the board and verify that Android boots successfully from the NVMe SSD. This confirms that the system is running entirely from the NVMe drive rather than from the eMMC. 5. Creating Space for Linux Keep all Android partitions unchanged. Using tool on either Windows or Linuxuse the Unallocated space located after the Android partitions, create the following partitions: EFI (used to boot Armbian and Ubuntu through UEFI) Armbian Ubuntu Data 6. Installing Armbian Restore or copy the Armbian RootFS to the Armbian partition on the NVMe SSD. Copy the EFI boot files to the EFI partition. Update the UUIDs if necessary. Verify that Armbian boots successfully through UEFI. 7. Installing Ubuntu Restore or copy the Ubuntu RootFS to the Ubuntu partition on the NVMe SSD. Copy the EFI boot files to the EFI partition. Update the UUIDs if necessary. Verify that Ubuntu boots successfully through UEFI. 8. Booting the Operating Systems Boot Android Remove the microSD card containing the UEFI bootloader. Make sure the SPI flash is empty. [7/10/2026 10:56 AM] Vũ Minh Tâm: The Orange Pi 5 Plus will boot Android directly from the NVMe SSD. Boot Armbian or Ubuntu Insert the microSD card containing the UEFI bootloader. Select the desired operating system from the UEFI boot menu. The selected Linux system will boot from its corresponding partition on the NVMe SSD. 9. Current Status The following configuration has been successfully verified: ✅ Android running from the NVMe SSD. ✅ Armbian running from the NVMe SSD. ✅ Ubuntu running from the NVMe SSD. ✅ Armbian and Ubuntu share the same EFI partition. ✅ Android, Armbian, and Ubuntu can share a common Data partition (NTFS is recommended). ✅ Switching between Android and Linux only requires inserting or removing the microSD card. 10. Notes This method has only been tested on the Orange Pi 5 Plus. It is based entirely on real-world testing and is not an official Orange Pi installation procedure. Some adjustments may be required when using different firmware versions, bootloaders, or hardware revisions. It is strongly recommended to back up both the eMMC and the NVMe SSD before modifying the partition layout. 11. Discussion If you have successfully implemented a similar setup or know of a simpler approach, feel free to share your experience. Any suggestions or improvements are welcome and will help make this guide even better.

Unfortunately, Link Star H68K is not one of the supported boards. Hinlink H68K is Community Maintained and is provided as-is with no guaranteed support and no any maintainer listed. If you can figure out what is different in the bootloader and device tree, you should be able to adapt what is in the Hinlink H68K build configuration.