All Activity

You will have to make a choice which bootloader firmware you use. And then also which boot method and/or bootmanager. Armbian images for Rockchip SBC's are as simple as possible, so only 1 OS, no ad-hoc kernel selection. That means 1 partition for rootfs, no others. Different methods have different advantages and disadvantages. If you want other boot method and/or bootmanager, you will need to add a boot partition yourself, usually FAT formatted and type 0xEF00 (called ESP). The Armbian rockchip64 supports it all, no problem. Especially the Rock5B, which is more or less the blue-print of high-end ARM64 SBC. But all this own custom action also make it not Armbian anymore, but just a generic UEFI ARM64 computer. Where you could also boot from a CD-ROM .iso image and run a traditional Linux distro installer like used on x86 PC's.

I had once put EDK2 on the SPI flashed and it seems to run fine, I was able to enter the menu. > i used this specific armbian image But Armbian images use U-boot right? So if it boot from the SD-card EDK2 shouldn't launch right. Armbian images are UEFI compatible?

You made me curious, so I rebooted for the first time after my previous report to activate my current versions. I' m now at kernel 7.0.0-0.rc1.15.fc45.aarch64 and U-Boot 2026.07-rc1 (May 22 2026 - 00:00:00 +0000). No regressions can be observed and it works as fast as before.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Hello All.. I am trying to get rknpu working properly. I have resolute minimal install with 6.1 vendor kernel installed. Default install does not have `/dev/rknpu` and shows error with loading the rknpu driver. Can any one help resolve this? This is with fresh install of the OS on the NVME drive: There is no NPU option in the dtb list for orangepi5plus. PRETTY_NAME="Armbian 26.5.1 resolute" NAME="Ubuntu" VERSION_ID="26.04" VERSION="26.04 (Resolute Raccoon)" VERSION_CODENAME=resolute ID=ubuntu ID_LIKE=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" PRIVACY_POLICY_URL="https://www.armbian.com" UBUNTU_CODENAME=resolute LOGO="armbian-logo" ARMBIAN_PRETTY_NAME="Armbian 26.5.1 resolute" This is the error in dmesg [ 15.981999] RKNPU fdab0000.npu: Adding to iommu group 0 [ 15.982175] RKNPU fdab0000.npu: RKNPU: rknpu iommu is enabled, using iommu mode [ 15.982308] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 15.985241] RKNPU fdab0000.npu: Looking up mem-supply from device tree [ 15.988551] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdab0000-0xfdabffff] [ 15.988583] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdac0000-0xfdacffff] [ 15.988603] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdad0000-0xfdadffff] [ 15.989174] [drm] Initialized rknpu 0.9.8 20240828 for fdab0000.npu on minor 1 [ 15.993547] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 15.996066] RKNPU fdab0000.npu: RKNPU: bin=0 [ 15.996288] RKNPU fdab0000.npu: leakage=8 [ 15.996320] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 15.996356] debugfs: Directory 'fdab0000.npu-rknpu' with parent 'vdd_npu_s0' already present! [ 16.005738] RKNPU fdab0000.npu: pvtm=868 [ 16.011925] RKNPU fdab0000.npu: pvtm-volt-sel=3 [ 16.012005] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 16.012037] debugfs: Directory 'fdab0000.npu-rknpu' with parent 'vdd_npu_s0' already present! [ 16.012656] RKNPU fdab0000.npu: Looking up mem-supply from device tree [ 16.014725] RKNPU fdab0000.npu: avs=0 [ 16.014836] RKNPU fdab0000.npu: rockchip_pvtpll_set_volt_sel: error cfg clk_id=6 voltsel (-1) [ 16.015007] RKNPU fdab0000.npu: l=15000 h=85000 hyst=5000 l_limit=0 h_limit=800000000 h_table=0

Orange Pi 5 Ultra HDMI RX no video when connecting Walksnail VTX Ascent. When I connect Walksnail Ascent VRX, the picture is fine, but when I connect VTX Ascent to VRX, the system doesn't see the HDMI RX. Specifically, it sees the source but can't lock it. The settings are set to 1080p60. I've tried different kernel and OS builds, but the result remains the same. What are the ways to solve this problem at the software level, since I specifically chose the Orange Pi 5 Ultra because of its built-in HDMI IN. [ 41.859256] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 42.371741] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 43.358027] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 43.358032] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 47.623748] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 48.131739] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 49.106851] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 49.106858] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 53.409063] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 53.921736] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 54.876109] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 54.876117] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 59.155931] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 59.678402] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 60.623901] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 60.623907] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 64.892299] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 65.411737] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 66.391898] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 66.391904] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 70.706000] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 71.225068] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 72.155904] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 72.155910] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 That's just when the Walksnail VRX ascension begins on orangepi@orangepi5-ultra:~$ v4l2-ctl -d "$DEV" --get-dv-timings Video timings: Active width: 1280 Active height: 720 Total width: 1650 Total height: 750 Frame format: progressive Polarity: +vsync +hsync Pixel frequency: 74250000 Hz (60.00 frames per second) Horizontal front panel: 110 Horizontal synchronization: 40 Horizontal rear panel: 220 Vertical front panel: 5 Vertical synchronization: 5 Vertical screen: 20 Standards: CTA-861 CTA-861 VIC: 4 Flags: frame rate can be reduced by 1/1.001, CE-video, has CTA-861 VIC Here is an example of how you can connect Walksnail VTX Ascent to VRX Ascent - HDMI in Orange Pi 5 Ultra orangepi@orangepi5-ultra:~$ v4l2-ctl -d "$DEV" --query-dv-timings VIDIOC_QUERY_DV_TIMINGS: error: Locking not available Active width: 0 Active height: 0 Total width: 0 Total height: 0 Frame format: Progressive

We're releasing Armbian Imager 2.0. We rebuilt the whole thing, the interface and the flashing engine underneath it. The part you'll notice first: your board boots already set up. Username, password, Wi-Fi, timezone, language. You tell Imager once, it writes that into the image, and the board comes up configured on first boot. No monitor, no keyboard, none of that blind first login. Set it up once. It configures itself.This is the big change in 2.0. You build a profile in settings: username and password, an SSH key, your Wi-Fi network and country code, timezone, locale, shell. Imager writes it straight into the image's filesystem while it flashes. Power on the board, it reads the profile and brings itself up. Qualcomm boards over QDL get the same treatment. It's the difference between "flash, hook up a screen and keyboard, sit through the setup" and "flash, slot the card, switch on." I didn't expect to care this much about it, and now I can't flash without it. Pick everything on one screenThe old pop-up windows are gone. In their place is a single animated flow: manufacturer, board, OS, device, all on one page that moves with you. You page through the board and vendor grids, the distro logos are drawn by hand, and the app glides instead of slamming between screens. Settings got the same redesign. So did the cache manager, which now shows where your gigabytes actually went, by category, and clears them in a tap. Know what you're writing before you write itEvery image tells you what it is up front: build date, badges for the desktop and the kernel branch, a label when it ships with something preinstalled like the SDK build, openHAB, or Kali. Anything you've already downloaded carries a small check, so you don't pull it twice. If you want the trunk rolling releases, there's a filter for them, with a plain warning before you commit. And images that can't be written to a card, like the VM disk formats, simply aren't in the list. Every write, checked byte for byteThe download is verified against its SHA256. After writing, the app reads the card back and compares it to the source, byte for byte. While that runs, your board floats over a warm glow that follows the progress, with one line telling you the stage instead of a wall of numbers. When the check turns green, it's because the data on the card matches. Not because we're optimistic. Bring your own images, online or offlineHave an image of your own? Drop it in. We handle img, iso, xz, gz, bz2, and zst, and decompress before writing. Lose your connection partway through the day and Imager still works: the offline mode was reworked so your cache and your own files stay one click away. The same app on Mac, Linux, and WindowsSame look and behavior on all three. On Mac it's a single universal build for Intel and Apple Silicon. Pick a light theme, a dark one, or let it follow the system. Eighteen languages, chosen automatically from your locale. Free and open source, the way it started. Get itArmbian Imager 2.0 is available now, free, on Mac, Linux, and Windows. It does the same job it always has, writing a good image to a card. The new part is what happens after: you power the board on, and it's already yours. Download Armbian Imager 2.0 View the full article

We're releasing Armbian Imager 2.0. We rebuilt the whole thing, the interface and the flashing engine underneath it. The part you'll notice first: your board boots already set up. Username, password, Wi-Fi, timezone, language. You tell Imager once, it writes that into the image, and the board comes up configured on first boot. No monitor, no keyboard, none of that blind first login. Set it up once. It configures itself.This is the big change in 2.0. You build a profile in settings: username and password, an SSH key, your Wi-Fi network and country code, timezone, locale, shell. Imager writes it straight into the image's filesystem while it flashes. Power on the board, it reads the profile and brings itself up. Qualcomm boards over QDL get the same treatment. It's the difference between "flash, hook up a screen and keyboard, sit through the setup" and "flash, slot the card, switch on." I didn't expect to care this much about it, and now I can't flash without it. Pick everything on one screenThe old pop-up windows are gone. In their place is a single animated flow: manufacturer, board, OS, device, all on one page that moves with you. You page through the board and vendor grids, the distro logos are drawn by hand, and the app glides instead of slamming between screens. Settings got the same redesign. So did the cache manager, which now shows where your gigabytes actually went, by category, and clears them in a tap. Know what you're writing before you write itEvery image tells you what it is up front: build date, badges for the desktop and the kernel branch, a label when it ships with something preinstalled like the SDK build, openHAB, or Kali. Anything you've already downloaded carries a small check, so you don't pull it twice. If you want the trunk rolling releases, there's a filter for them, with a plain warning before you commit. And images that can't be written to a card, like the VM disk formats, simply aren't in the list. Every write, checked byte for byteThe download is verified against its SHA256. After writing, the app reads the card back and compares it to the source, byte for byte. While that runs, your board floats over a warm glow that follows the progress, with one line telling you the stage instead of a wall of numbers. When the check turns green, it's because the data on the card matches. Not because we're optimistic. Bring your own images, online or offlineHave an image of your own? Drop it in. We handle img, iso, xz, gz, bz2, and zst, and decompress before writing. Lose your connection partway through the day and Imager still works: the offline mode was reworked so your cache and your own files stay one click away. The same app on Mac, Linux, and WindowsSame look and behavior on all three. On Mac it's a single universal build for Intel and Apple Silicon. Pick a light theme, a dark one, or let it follow the system. Eighteen languages, chosen automatically from your locale. Free and open source, the way it started. Get itArmbian Imager 2.0 is available now, free, on Mac, Linux, and Windows. It does the same job it always has, writing a good image to a card. The new part is what happens after: you power the board on, and it's already yours. Download Armbian Imager 2.0 View the full article

SoC:ik316-h board: IK316Q-EMCP_V4.1 i belive it's apart of the h6 familly, correct me if i'm wrong. Well, i'm trying to boot from a sd card, but it doesn't work, i tried the toothpick methof but it still don't work. I tried with the sd and without the sd card, but it doesn't enter into android recovery mode, the only way i can get into fastboot is by using adb, however if i try to enter the bootloader by selecting it on the andorid recovery or fastboot menu it just crashes. Do you guys know any way of how can i proceed? Will be better if i change the firmware? Should i just buy ice cream and cry in the shower? I need help, the img i'm using is Armbian_community_26.2.0-trunk.886_X96q_trixie_current_6.18.28_minimal.img, because i believe it's the most compatible to my board. Feel free to ask any questions.

Can't confirm, still the same thing. U-boot built 7 days ago (linux-u-boot-odroidm1-edge/sid,now 26.8.0-trunk.105 arm64) # uname -r 7.0.11-edge-rockchip64 # grep -a --null-data U-Boot /dev/mtd0ro U-Boot SPL 2026.01_armbian-2026.01-S127a-Pb401-H8652-Vab81-Bd0d2-R448a (May 31 2026 - 05:41:25 +0000) # grep -a --null-data U-Boot /dev/mmcblk1 U-Boot SPL 2026.01_armbian-2026.01-S127a-Pb401-H8652-Vab81-Bd0d2-R448a (May 31 2026 - 05:41:25 +0000) 100 Mbps link still performs much better by some unknown reason. Hmm. (I've already tested the cable, any other computer/laptop transmits the data just fine at full Gigabit speed)

I was running armbian on emmc on an X96Air 4GB/64GB 1GBit S905X3 box a while ago and then after a power down it bricked. No boot screen, no android (obviously) - it sent a HDMI signal, but nothing. Managed to recover it and get Android flashed on it again then Armbian again on SD then emmc. Just done "apt upgrade" to get things up to date. All went well, then a reboot, and..... bricked again. Nothing obvious, no issues. I'll go through the process again - Android -> armbian sd -> armbian emmc But is there a known issue with any boxes that just brick themselves? Any ways to avoid it? This box is particularly useful because of the USB3 port with Gbit ethernet and I want to make use of it. Previously when I'd been testing it it had been rock solid for a few months with good uptime and no issues - until the brick.

Please don't test it yet. I have a problem with my development environment. I will upload a new version once I've resolved it.

@alexc Had to take a couple days break while we wait for a ordered Oscilloscope and CH341 to arrive. Current focus is SPI-NOR which is the most dangerous part of this EDK2 port due to the vendor of the board not releasing it to the public. That doesn't stop us tinkerers from from physically pulling it from the on-board SPI-NOR, so holding back such a valuable piece of the puzzle serves what purpose? They released it for the Rockchip SoC so who knows. After the SPI-NOR is conquered I hope to get some runtime pixels on the screen. I say around that time the EDK2 will be more of a usable boot loader to start on the alpha release (compiled public release). Right now I can boot to a generic Ubuntu 26.04 with working ssh and uart so things are looking good. Working with Opus 4.8 has been surprisingly very productive. These models have got so much better, I find myself getting more sleep by using Openclaw HEARTBEAT.md to nudge Opus 4.8 every 30 minutes to autonomously work on the port in my absence My good guy has a full report of his work done and ready to review by lunchtime

I could try one more thing: I could try a *third* USB-C power supply. However, there don't exist very many 5A@5V power supplies on the market. I would try a 3A@5V rated power supply. Have you guys had any problem with power supplies on the RV2? What power supply do you use? Would it be of any help that I buy a Raspberry Pi 5 power supply made by Raspberry Pi Ltd, that's rated 5.1V@5A? https://www.raspberrypi.com/products/27w-power-supply/ https://www.amazon.de/-/en/Official-Raspberry-Pi-USB-C-Supply-black/dp/B0CN3MRV16 Actually in this context is it a good thing to use a power supply rated 5.1V rather than 5.0V? Anyhow as far as the 3.3V supply on the RV2 is concerned, the voltage converter should treat 5.1V and 5.0V equally, it has a wide accepted voltage interval.

Hi all! Here follows the learning from circa 12 hours of trying to make Armbian with 7.1 and 6.18 kernel work. What worked and didn't work: 6.18 booted with 100% success rate from MicroSD. 7.1 did not boot at all for me from MicroSD. Debug log below. (Here the u-boot works, the kernel loads, but it fails around the point where it tries to mount the root filesystem.) 7.1 worked booted from NVMe SSD a few times, it started with some success rate there and then the success rate went to 0. The failures are in u-boot. 6.18 booted from NVMe SSD had a similar pattern as 7.1. So what caused me the most headache was that u-boot would not boot off the NVMe SSD. (Initially I had a few successes but the success rate went to 0.) It found the SSD, but said it can't find any partition. As for the PCIe networking card, I saw it work on both 7.1 and 6.18 images for a moment, but it did not work stably. Installing the "armbian-firmware" package didn't make a difference. I'd need to test this more though. Most of my time went to trying make the RV2 boot off the NVMe SSD. I wrote some detail thoughts and questions about u-boot's inability to boot off NVMe SSD below. Aside from any fixes you suggest, things to try that come to mind to me are: Wait for Linux 7.2 to be released, and then wait for an Armbian image with it. This is scheduled for August. Perhaps it just works a lot better as more RV2 functions have been mainlined, and it generally has been tested more by the community - Linux 7 is still so early. Try to boot the 7.1 kernel Armbian from SSD but with a /boot partition on a MicroSD card. Hardware setup To this RV2 was connected a Samsung 960 Pro 2TB in the 22x80mm M.2 slot (lower), and a RTL8127ATF SFP+ NIC, which was connected to the 22x30mm M.2 (upper) slot via an adapter. Both M.2/PCIe cards got 3.3V supply from the RV2 only. The M.2 to PCIe adapter has a 12V supply input, which was not used. This appeared to suffice for both cards because as you will see below the NIC's link LED did light up at one point. The power supply to the RV2 was a good 5V 5A power supply. I actually tried two different ones, and it did not affect the results. The RV2 feeds both M.2 connectors and the onboard WIFI from one 5V to 3.3V voltage converter, which appears to be a SY8286A. Its capacity is 6A, i.e. x 3.3V = 19.8W. The SSD should draw max 5W, and the NIC max 2W. Therefore I conclude that the power supply to both cards was fully adequate. (The said 5V to 3.3V converter is in on page 5 in the RV2's schematics @OPI RV2 V1_1_SCH_20250508(1).pdf" which is http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-RV2.html . Here it's only called U3, which has 17 PINs with specified names. Concluded it's SY8286A based on searching for a voltage converter with 17 PINs with matching names. It's 3x3mm and has 82% energy conversion efficiency meaning it may produce as much as 3.5W of heat. https://www.bulcomp-eng.com/datasheet/SY8286A (QFN20) - Datasheet 1.pdf ) U-boot fail when trying to boot 7.1 from NVMe SSD During the many hours I tested the RV2, I had the best success early in the testing: Early in the testing, I got the 7.1 kernel Armbian image to boot from the SSD circa 3-4 times. This was as quickly as on the first, second or third try, i.e. I try to boot and if it failed once or twice then at least on the third try it worked. On all other occasions, u-boot failed with the error "Couldn't find partition nvme na:1". What does "nvme na" even mean? At this stage I was booting from the u-boot on the SPI flash, that the RV2 came bundled with. This failure mode happened both before and after upgrading the SSD to the latest firmware. I tried to fix it by un-screwing and re-screwing the SSD in the M.2 slot to work around any potential issue with glap. I don't think that made any material difference. I thought what if there is an issue with the u-boot version, so I went through the u-boot SPI flashing process Sven-Ola pointed to using the "armbian-config" tool on the 6.18 kernel Armbian image. This only changed the look of the error message: Now instead u-boot printed "no nvme partition table available" once and then"** No partition table - nvme 0 **" "Couldn't find partition nvme 0:1" five times, and then left me in an u-boot prompt: From the u-boot prompt, I learned that the partitioning table is MBR and not GPT, because it says "DOS" partition type. After this, I tried "sysboot nvme 0:1 fat" which did boot into something, but I think it was actually to the MicroSD, because it behaved the same as when I try to boot the 7.1 kernel Armbian from MicroSD: it repeated "Begin: Running /scripts/local-block ... done." circa 20 times and then "Gave up waiting for root file system device." .. "ALERT! UUID=63ee7593-e111-4547-ac2f-6bdb8519ce11 does not exist. Dropping to a shell!". But, I'd need to re-test this more carefully to make any conclusion. Regarding this complaint that there would be no partition on the NVMe disk, I booted the RV2 from the 6.18 kernel Armbian on a MicroSD card, and there, "mount /dev/nvme0n1p1 /mnt" did work. Summary thoughts about u-boot's inability to boot from SSD + questions So to summarize, booting the OrangePI RV2 from a 2TB SSD worked a few times but eventually started having a 100% failure rate (circa 25 failures in a row), seeming to say it finds the NVMe disk but complains it can't find a partition, while we know that there was a partition. And these failures were in u-boot. Also since the failure was already in u-boot, the Linux kernel version doesn't matter. This made me think the error could be any of the following: Could it be that U-Boot has some incorrectness in its configuration for the power supply to the M.2 slots? However, I can't see the 5V to 3.3V voltage converter is software-configurable at all (see schematic above). Meanwhile the P1 PMIC is software-configurable. Could it be that the U-Boot has some incorrect configuration to the X1's PCI subsystem or PMIC configuration? Could there be a problem that U-Boot can't handle partitions that are almost 2TB in size? For safety, it could be a good idea to switch all these Armbian images to GPT partitioning table as DOS/MBR partition tables don't scale anyhow - 2TB is supposed to work, but people will like to boot the RV2 from 4TB+ SSD:s. Could there be a problem that U-Boot does not wait for appropriately long time for the SSD to initialize? Overall I found it a really peculiar issue that U-Boot says it finds the NVMe but appears to fail to read from it. @sven-ola Any idea? More tests and results re SSD For completeness, on the successfully booted system - that should be only 6.18 kernel booted from MicroSD - with time I did see some SSD failure reported: sven-ola suggested me to try connecting the SSD to the other M.2 slot instead, and that did not work any better. Maybe it worked worse. I could imagine that there was a situation with double bugs here, that the issue with the SSD inside Linux shows some issue with the PCIe drivers. For completeness, lspci -v shows this (on 6.18 booted from MicroSD): From inside this Linux, this simple test of the SSD works, and shows ~600M/sec. Having a look at this disk right now, I just saw something weird: I see /dev/nvme0n1 but no partitions - ls /dev/nvme0n0p* gives nothing. fdisk found no partitions (empty partition list printout). gdisk found three partitions but after 'fixing' the partition table. I'd need to look into this more. I have not done any changes to the SSD's partition table after the original flashing the disk with the Armbian image. Perhaps some bug some-where in this u-boot or Armbian caused the partition table to get overwritten, no idea? To show that the SSD can work, here is a cycle of re-flashing the 7.1 image and looking at its partition descriptors in Linux + fdisk's output + gdisk's output + trying to mount it. How the 7.1 kernel Armbian fails when trying to boot it from MicroSD For your reference, here is how the 7.1 kernel Armbian fails when I try to boot it from MicroSD. The failure rate is 100%, I did not get it to work a single time. @rm_ Thanks for the link to https://www.phoronix.com/news/SpacemiT-K1-K3-Linux-7.2 which links to https://lore.kernel.org/lkml/20260602070257-KYC5031219@kernel.org/ , which says "For boards of K1", "OrangePi RV2", "Enable eMMC/I2C/PCIe/PMIC/QSPI/USB". The meaning here is that the Linux 6.18 and also Linux 7.1 use special patched kernels, not just the mainline kernel. What's happening in Linux 7.2 is that more RV2 functionality moves in to the mainline kernel. This way, Sven-Ola is correct when he says that SD and NVME already work in Armbian edge 7.1.

Hey Community, I've been running a few services on Armbian devices and recently reviewed options for handling automated email notifications. Using an SMTP Service Provider like iDealSMTP for server alerts, backup reports, and application notifications seems like a practical approach when reliable email delivery is important. For small ARM-based servers, having proper SMTP authentication, delivery tracking, and support for transactional emails can simplify administration without requiring a fully self-hosted mail server. Sharing this as a discussion topic for anyone using email notifications on their Armbian systems.

@Jacob GeorgeThat's excellent progress, thanks for sharing! EDK2 support on the A733 would be a very welcome addition, and it's great to hear the port is moving along so quickly. One thing that would be especially valuable for the community is if some of the platform work could eventually be drafted as mainline kernel patches/drivers. That would save a lot of development effort and benefit everyone using these boards.There are already a few A733 patches in 7.x or in the queue. Looking forward to seeing the project reach the finish line.

Another option is to wipe the U-Boot from the SD-card and just use the SD-card only, no USB-adaptor needed. Then the only U-Boot in the system is the one in SPI-flash. I have done that once on an SBC with no SPI-flash but eMMC where the bootloader is stored. And that also involves GPT partitions and so on, not independent like SPI-flash. But as Werner says, backup is easy. For old 32-bit Armbians, I made some function in my unattended backup scripting to do that, so that after a year(s) or so, I can restore to get exactly the same system (when SD-card gets bad/broken for example).

Hello, I am new to the conversation but I would like to add something I am working on. I am almost done the EDK2 port to A733, see: https://github.com/vehoelite/edk2-a733 I am actively getting further everyday. I have let A.I. take full credit (seems to make Opus 4.8 work better) but regardless I suspect the port to be finished within a week or up to a month if I hit a snag.

Thanks for the guide - got my X96 Air back up and running after it died after running fine

@rm_ No, SD and NVME are working with Armbian edge 7.1, while USB does not. root@orangepirv2:~# uname -a Linux orangepirv2 7.1.0-rc3-edge-spacemit #3 SMP PREEMPT_DYNAMIC Sun May 10 21:08:09 UTC 2026 riscv64 GNU/Linux root@orangepirv2:~# blkid /dev/nvme0n1p1: LABEL="armbi_root" UUID="fdbd4ab2-2238-4a62-a079-74ff0582c8d2" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="00406d4f-01" /dev/mmcblk0p1: LABEL="armbi_root" UUID="63ee7593-e111-4547-ac2f-6bdb8519ce11" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="9ebf8299-01" /dev/zram0: UUID="3be872bc-b408-46c3-8ec9-d27500adc1dd" TYPE="swap" /dev/zram1: LABEL="log2ram" UUID="bace3aba-15ea-4833-a7ad-f7d9e39aa0c5" BLOCK_SIZE="4096" TYPE="ext4" root@orangepirv2:~# lsusb root@orangepirv2:~# lspci 0001:00:00.0 PCI bridge: SpacemiT X60 PCIe 2.0 x2 Root Complex (rev 01) 0002:00:00.0 PCI bridge: SpacemiT X60 PCIe 2.0 x2 Root Complex (rev 01) 0002:01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9B1 (DRAM-less) (rev 02) Anyhow, thanks for the Phoronix link // Sven-Ola

@johlnx I will give it a try. The main reason i bought this board was to place it on my parrents house as a backup storage device. Thats why i wanted the 1 Gbps port. And i understand that i would never get 1Gbps lan -> disk transfer with encryption and such, but 100Mbps is 10 times less. I would be happy with 200Mbps or 300Mbps actual performance. without gigabit support its limited to 100Mbps 😕 And thanks for the reply on the github "The board lacks an external Gigabit PHY; the internal PHY supports only 4 lines, which limits the speed to 100 Mbps." I understand that its physicaly impossible. So im just saying "im sad" I can probably get more than 100Mbps using wifi

For microSD card slot to even work at all, it is listed as a change that landed only in 7.2. https://www.phoronix.com/news/SpacemiT-K1-K3-Linux-7.2 This is why you get root filesystem UUID not found with 7.0-7.1

Sorry, forgot about that. Here are logs from a boot of Debian minimal with GNOME and updated packages: https://paste.armbian.com/eyaxadazow

https://github.com/ThomasKaiser/sbc-bench/blob/master/results/rca7s.txt here are my results with an old (November 2025) kernel