c0rnelius

Here is an IMG with just u-boot flash to it; https://github.com/pyavitz/binary/releases/download/images/k1-spacemit-boot.img Using it will bypass the SPI and allow you to boot from USB NVME EMMC. Granted, an Armbian IMG would need to have already been flashed or transferred to one of them. It could be useful if say, you b0rked the SPI and wanna attempt to fix it or to use the SD card as a chainload mech to boot into the NVMe.

I don't own an OPI RV2, but I do have a few K1's. I suggest trying without that NVMe attached as it may be a contributing factor to boot fails. Technically correct. But I've seen some peps attempt some odd things and then wonder why it doesn't work. With serial attached, stop auto boot with the SPACEBAR. From there run `nvme` and you'll be provided with options. Are you suggesting you wanna bypass SPI by using an SD card to boot into say an NVMe or USB? Should be easy enough. Partition an SD card with an 4MiB offset and flash the u-boot bins to it. U-boot should then check for what ever is available to boot from; USB SD NVME MMC. If there is no extlinux.conf, boot.scr or *.efi to boot from on the SD, it will look else where.

Some NVMe's just don't play nice with some units. I have one such NVMe, which is why I rarely try to use it. Also u-boot is not set up to look for an infinite amount of $devnum. Currently it is hard coded to look for nvme 0:1. So I suggest moving the NVMe to the first available. According to the boot log you have more than one PCIE link up [ 1.438] PCIE-0: Link up (Gen2-x2, Bus0) <-- Thats where you want to attach the NVMe [ 1.600] PCIE-2: Link up (Gen2-x2, Bus2) Honestly though. It looks like the NVMe you are trying to use isn't compat.

The armbian boot loader is diff than the vendors. It checks for specific things in a particular order. nvme_devtype=nvme nvme_devnum=0 nvme_bootpart=1 autoboot=if test -e ${devtype} ${devnum}:${distro_bootpart} /extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /boot/extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot/boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} EFI/BOOT/BOOTRISCV64.EFI; then \ load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} EFI/BOOT/BOOTRISCV64.EFI; bootefi ${kernel_addr_r}; \ fi; nvme part; \ setenv devtype $nvme_devtype; \ setenv devnum $nvme_devnum; \ setenv distro_bootpart $nvme_bootpart; \ if test -e ${devtype} ${devnum}:${distro_bootpart} /extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/extlinux/extlinux.conf; then \ sysboot ${devtype} ${devnum}:${distro_bootpart} any 0x2000000 /boot/extlinux/extlinux.conf; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} /boot/boot.scr; then \ load ${devtype} ${devnum}:${distro_bootpart} 0x2000000 /boot/boot.scr; source 0x2000000; \ elif test -e ${devtype} ${devnum}:${distro_bootpart} EFI/BOOT/BOOTRISCV64.EFI; then \ load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} EFI/BOOT/BOOTRISCV64.EFI; bootefi ${kernel_addr_r}; \ fi; bootcmd=echo "Loading K1-X Environment ..."; \ echo ""; \ echo "Running NVMe Scan ..."; \ nvme scan; \ run autoboot SD takes priority. After that it checks for an eMMC and if nothing on the eMMC is found it can use, it then moves on to check the NVMe. What this means? If the unit has an SPI, it needs to be updated with the Armbian boot loader. If the bootloader finds an extlinux.conf, boot.scr or *.EFI on the eMMC it will attempt to boot from it. I have a BPI-F3 which has no SPI. What I do in that case is boot from SD, format the eMMC and transfer the install to the NVMe. I then flash u-boot to the eMMC and wham oh. System boots from NVMe. In the case of an SPI, its the same. As long as it doesn't find anything of use on the eMMC your good.

Here is an example of an overlay for adding an RTC to the radxa zero /dts-v1/; /plugin/; / { compatible = "radxa,zero", "amlogic,g12a"; fragment@0 { target-path = "/"; __overlay__ { aliases { rtc0 = &rtc; }; }; }; fragment@1 { target = <&i2c3>; __overlay__ { #address-cells = <1>; #size-cells = <0>; rtc: rtc@68 { compatible = "dallas,ds1307"; reg = <0x68>; wakeup-source; }; }; }; __overrides__ { rtc = <0>,"+0"; addr = <&rtc>, "reg:0"; }; }; Key bits here: * aliases (some of these AML units have vrtc on rtc0, so it may need to be set to rtc1) * i2c# (this should be obvious) * compatible string * wakeup-source The i2c-dev module must be force loaded in some cases. If it isn't hard coded into the kernel, you can add it to /etc/modules

https://forums.kali.org/ There is an arm64 section.

Add to /etc/rc.local and reboot. echo "1" > /sys/devices/system/cpu/cpufreq/boost && echo "performance" | tee /sys/devices/system/cpu/cpu[0-9]/cpufreq/scaling_governor &&

Not sure its related, but on the MusePi Pro I was getting odd happenings with the PCIe. Adding this to the command line resolved it my case: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off

@sven-ola https://lore.kernel.org/spacemit/20260310161853.3900605-1-gaohan@iscas.ac.cn/T/#t Sometime soon-ish I'll be doing another PR with early SD card and CPU freq scaling support. The above link should at least get you boot from eMMC or NVMe.

Welcome to Armbian! Documentation: https://docs.armbian.com | Community support: https://forum.armbian.com IP address: xx.x.x.xx Create root password: ***** Repeat root password: ***** Developer Preview Build This Armbian image was generated automatically for development and testing purpose. It may include unfinished features or unstable components. If you are not here to report issues or just test it, please do not use this image in production. Expect things to change — or even break — as improvements are made. Creating a new user account. Press <Ctrl-C> to abort Please provide a username (eg. your first name): Disabling user account creation procedure root@orangepi3-lts:~# rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth bluetooth unblocked unblocked 1 wlan phy0 unblocked unblocked 2 bluetooth hci0 unblocked unblocked root@orangepi3-lts:~# bluetoothctl [NEW] Media /org/bluez/hci0 SupportedUUIDs: 0000110a-0000-1000-8000-00805f9b34fb SupportedUUIDs: 0000110b-0000-1000-8000-00805f9b34fb Agent registered [CHG] Controller 30:96:18:9E:A7:02 Pairable: yes hci0 new_settings: powered bondable ssp br/edr le secure-conn [bluetoothctl]> show Controller 30:96:18:9E:A7:02 (public) Manufacturer: 0x01ec (492) Version: 0x09 (9) Name: orangepi3-lts Alias: orangepi3-lts Class: 0x00400000 (4194304) Powered: yes PowerState: on Discoverable: no DiscoverableTimeout: 0x000000b4 (180) Pairable: yes UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: SIM Access (0000112d-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0554 Discovering: no Roles: central Roles: peripheral Advertising Features: ActiveInstances: 0x00 (0) SupportedInstances: 0x10 (16) SupportedIncludes: tx-power SupportedIncludes: appearance SupportedIncludes: local-name SupportedSecondaryChannels: 1M SupportedSecondaryChannels: 2M SupportedSecondaryChannels: Coded SupportedCapabilities.MinTxPower: 0xffffffec (-20) SupportedCapabilities.MaxTxPower: 0x0008 (8) SupportedCapabilities.MaxAdvLen: 0xfb (251) SupportedCapabilities.MaxScnRspLen: 0xfb (251) SupportedFeatures: CanSetTxPower SupportedFeatures: HardwareOffload [bluetoothctl]> exit root@orangepi3-lts:~# uname -a Linux orangepi3-lts 6.12.74-current-sunxi64 #6 SMP Thu Feb 19 15:29:56 UTC 2026 aarch64 GNU/Linux

I'm not seeing any bluetooth error, are you? rfkill unblock all

Which kernel? Should work on 6.12.y, although I see issues with it on 6.18.y, as there were changes made to that wireless patch set that don't agree with my DTS changes. In fairness, I haven't checked to see if it works at all regardless of my changes on that kernel though. Its on my list of things to investigate. The new DTS changes require an updated hciattach_opi binary. "known to work on 6.12.y" https://github.com/armbian/build/blob/main/packages/blobs/bt/hciattach/hciattach_opi_arm64_upstream

Looks like the same adjustment that was made for EDGE needs to be done so for CURRENT.

U-Boot SPL 2025.07-armbian-2025.07-Se37d-P526e-H8869-V8e92-Bb703-R448a (Aug 19 2025 - 04:10:01 +0000) DRAM: 4096 MiB Trying to boot from MMC2 NOTICE: BL31: v2.12.5(debug):armbian NOTICE: BL31: Built : 04:09:39, Aug 19 2025 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b5100, model: BananaPi BPI-M4-Zero INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: Probing for PMIC on I2C: INFO: PMIC: found AXP313 INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2025.07-armbian-2025.07-Se37d-P526e-H8869-V8e92-Bb703-R448a (Aug 19 2025 - 04:10:01 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: BananaPi BPI-M4-Zero DRAM: 4 GiB Core: 65 devices, 22 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0, mmc@4022000: 1 Loading Environment from FAT... Unable to use mmc 1:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) Net: using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready eth0: usb_ether starting USB... USB EHCI 1.00 USB OHCI 1.0 Bus usb@5311000: 1 USB Device(s) found Bus usb@5311400: 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 4641 bytes read in 1 ms (4.4 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 280 bytes read in 0 ms Load fdt: /boot/dtb/allwinner/sun50i-h618-bananapi-m4-zero.dtb MMC: no card present ** Bad device specification mmc 0 ** 43728 bytes read in 4 ms (10.4 MiB/s) Working FDT set to 4fa00000 1358 bytes read in 3 ms (441.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-bananapi-m4-sdio-wifi-bt.dtbo 4203 bytes read in 2 ms (2 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 17177939 bytes read in 543 ms (30.2 MiB/s) 38219784 bytes read in 1207 ms (30.2 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=0x42760000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 17177875 Bytes = 16.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 48f9e000, end 49fffd13 ... OK Loading Device Tree to 0000000048f2a000, end 0000000048f9dfff ... OK Working FDT set to 48f2a000 Starting kernel ... Armbian 25.8.1 Trixie ttyS0 bananapim4zero login: root Password: _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.8.1 for BananaPi BPI-M4-Zero running Armbian Linux 6.12.35-current-sunxi64 Packages: Debian stable (trixie) Updates: Kernel upgrade enabled and 6 packages available for upgrade IPv4: (LAN) xx.xx.xx.xx (WAN) xx.xx.xx.xx Performance: Load: 16% Uptime: 0 min Memory usage: 4% of 3.83G CPU temp: 46°C Usage of /: 5% of 29G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@bananapim4zero:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk2 179:0 0 29.1G 0 disk └─mmcblk2p1 179:1 0 28.8G 0 part /var/log.hdd / mmcblk2boot0 179:32 0 4M 1 disk mmcblk2boot1 179:64 0 4M 1 disk zram0 252:0 0 1.9G 0 disk [SWAP] zram1 252:1 0 50M 0 disk zram2 252:2 0 0B 0 disk root@bananapim4zero:~# https://www.armbian.com/bananapi-m4-zero/ Seems fine to me?

Boot with serial attached and see if the DRAM is being properly detected. If not this patch would appear to solve the issue. https://lore.kernel.org/linux-sunxi/2813637.mvXUDI8C0e@jernej-laptop/T/#t