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