Nick A Posted May 22 Author Posted May 22 (edited) @Sand_Death I just updated my build with @alexc's BSP changes, which include the latest AIC8800 drivers. I'm building an image right now, so I haven't tested it yet. I haven't tested Ethernet either. Maybe Alex can help you with that. Edited May 22 by Nick A 0 Quote
alexc Posted May 22 Posted May 22 My board is A7Z so unfortunately I couldn't fully test the Ethernet drivers. Hi @qq20739111 / @humanus, any luck with the on board Ethernet? FYI, my new version utilizes mainline MMC drivers as well. And I'm looking into PCIE at the moment. 0 Quote
alexc Posted May 22 Posted May 22 (edited) OK, it looks like the BSP PCIe driver might have some issues related to power management. I’m not entirely sure of the root cause yet, but when I connected an NVMe drive, it got extremely hot and failed to initialize properly. The NVMe dmesg output suggested adding the following kernel parameters: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off This resolved the NVMe issues on my side. I’ll try to dig deeper into the root cause, but @humanus please give it a try as well. Edited May 22 by alexc 0 Quote
Marvin-03 Posted May 27 Posted May 27 I tried to boot via EMMC using alexc's/Nick's BSP Kernel (6.18) and had a kernel panic: https://pastebin.com/aPhDfFzr The crash occurs in thread T77 (a background worker) while it is attempting to scan for SD cards (mmc_rescan). More specifically, the crash occurs when calling sd_uhs2_power_up, which is requested by mmc_attach_sd_uhs2. Here, the kernel is attempting to power up the power supply for the UHS-II SD card protocol. 0 Quote
alexc Posted May 27 Posted May 27 Hi @Marvin-03, could you try the latest build? It looks like your board is still using the BSP MMC driver, but we migrated to the mainline MMC driver last week. That should at least resolve the issue you're currently seeing. Also looking forward to your testing on the eMMC side, since the A7Z does not have eMMC support. 0 Quote
Marvin-03 Posted May 28 Posted May 28 (edited) @Nick A I had to modify the "0011-Add-BSP-support-files-afa7aabb90" patch in the "Radxa-mainline-WIP-test" branch to allow compiling. This is the new patch file: https://pastebin.com/3Qc2bGPY After flashing the image to the emmc I got this bootlog: https://pastebin.com/eqsZ2d1r It seems like it wont leave the U-Boot. I used this command to flash the image: sudo dd if=/mnt/transcend/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a7a_trixie_edge_6.18.19_gnome_desktop.img of=/dev/mmcblk1 bs=4M status=progress conv=fsync @alexc Do you know if the A523 and A733 use the same pcie driver? I've already optimized the A523 pcie driver and its in the mainline armbian. Edited May 29 by Marvin-03 0 Quote
keegat Posted May 29 Posted May 29 Hello, I am attempting to run armbian off of UFS on an a7z and running into issues. I don't know if I'm missing something fairly basic. - Board is unmodified by me. I don't know how commonly sellers mod these boards themselves, but there is a bit of scuffing on the ram and UFS chip. It has 8gb ram, the official hsf, and the official power supply. Display over HDMI, USB hub for IO. - I can boot the official radxa image from the ufs, flashing it with sudo dd if=<path_to_image> of=/dev/sda bs=4M status=progress conv=fsync - I have successfully built and booted armbian trixie 6.6 kernel with kde on the sd card. I had to do some tty backflips to get kde to launch once it booted, but it did run. I have also booted the released armbian xfce build from sd, which I had no problems with at all. - Currently I have the official radxa image booted off the sd card, and I have been attempting to build and flash armbian for ufs. - I built with ./compile.sh, board selection: radxa-cubie-a7z-ufs, vendor 6.6, trixie, desktop, kde, no extras - Flashed to the ufs with the same command from above from my session on the radxa build sd card, and rebooted without the sd card. The green LED comes on solid, then the fan kicks in, then the LED turns off. My display comes up out of sleep, black screen for a second, then no signal. - After about 25 minutes, I disconnected power, and booted back into the sd card. Here is the boot.log from the ufs: https://pastebin.com/ASpndqVU 0 Quote
Nick A Posted May 29 Author Posted May 29 (edited) @Marvin-03 that's odd. The test branch I cloned has "0011-Add-BSP-support-files-54e9e5fb62" patch. Compiles fine on my build. Try to clone it again. git clone https://github.com/NickAlilovic/build.git --branch Radxa-mainline-WIP-test Edited May 29 by Nick A 0 Quote
Marvin-03 Posted May 29 Posted May 29 (edited) @Nick A My bad, cleaned my build folder and it compiled fine. Still, it is still stuck in the bootloader Bootlog: https://pastebin.com/ckqP10Bb I tried with both of my board with and without emmc installed. UPDATE: After applying Nick's changes it works fine with gnome. The EMMC still doesnt get recognized by the kernel driver. Zitat After flashing the image to the emmc I got this bootlog: https://pastebin.com/eqsZ2d1r The bootlog is still the same when booting via EMMC with the new image. Edited May 30 by Marvin-03 0 Quote
alexc Posted May 29 Posted May 29 @Marvin-03 Just to confirm: for both boards, with and without eMMC, are you using the same microSD card as the boot device? From the current boot log, it looks like there may be an issue with the microSD card. Both the previous boot log (using the BSP MMC driver) and the current boot log (using the mainline MMC driver) show problems detecting mmc0 (the microSD card). Could you try a different microSD card, preferably from another brand, and see if the issue persists? 0 Quote
Nick A Posted May 29 Author Posted May 29 (edited) @Marvin-03 It is past the bootloader. I only tested the build on XFCE, which boots fine. GNOME failing to boot properly might be due to the PowerVR or KMScon install script. If you need GNOME. Try removing the function post_family_tweaks__install_powervr_desktop(). https://github.com/NickAlilovic/build/blob/Radxa-mainline-WIP-test/config/sources/families/sun60iw2.conf#L467-L1045 Update: I removed both post_family_tweaks__install_powervr_desktop() and kmscon install funtions. Gnome works. But you need to use a serial device to fill in the first login information. Edited May 29 by Nick A 0 Quote
Marvin-03 Posted May 30 Posted May 30 Zitat OK, it looks like the BSP PCIe driver might have some issues related to power management. I’m not entirely sure of the root cause yet, but when I connected an NVMe drive, it got extremely hot and failed to initialize properly. The NVMe dmesg output suggested adding the following kernel parameters: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off This resolved the NVMe issues on my side. I’ll try to dig deeper into the root cause, but @humanus please give it a try as well. @alexc What pcie hat do you use? I use one from Yahboom made for the RPI 5, but my nvme wont show up and since logs show "sunxi:pcie-rc-6000000.pcie:[ERR]: Speed change timeout" it seems like the hat doesnt work. On the Cubie A5E I only get this timeout if the SSD isnt plugged in. 0 Quote
alexc Posted May 30 Posted May 30 @Marvin-03 You're probably right—it may be worth checking the FPC connection. A timeout usually only occurs when the PCIe/NVMe board is not being detected. I'm currently using an early MCUZone NVMe 2230 HAT. I recently ordered a new Waveshare AIO HAT as well, so once it arrives I'll be able to do some additional testing. 0 Quote
stary presporak Posted June 5 Posted June 5 I wanted to report a specific regression regarding CPU frequency scaling on the Radxa Cubie A7S and share the DTS workaround that fully restores complete functionality. The Regression Behavior November Kernel State: Using the kernel branch/commit built back in November (running Linux version 6.6.98-vendor-sun60iw2 #SMP PREEMPT Wed Nov 19 2025 ), CPU frequency scaling worked perfectly out of the box. All available frequencies scaled smoothly across both core clusters, and the benchmark results for my specific A7S board were fully aligned with Thomas Kaiser's provided optimization targets. May Kernel State: After updating to the recent kernel build (mid-May 2026), CPU frequency scaling completely broke under the stock DTB configuration. The core clusters refused to scale through their operational performance points properly. The Frequency Trick & DTS Fix The root cause was isolated to how cpufreq binds under the newer kernel configuration, specifically linked to the inclusion of CONFIG_CPUFREQ_DT_PLATDEV=y. To make the scaling work seamlessly on the latest May kernel, the underlying Device Tree needs a dedicated adjustment in the opp-table and driver mapping. By manually adapting the standard DTS bindings for the sun60iw2 platform to explicitly force correct platform-device scaling registration, all operational frequencies are now fully functional and stable again on the new kernel. Request for Review/Merge@Nick (or current DTB maintainer), cubie_a7s.zip could you please verify this behavior against the latest repository changes? If everything checks out on your end, please pull this DTS patch into the main Armbian sunxi tree so that the Cubie A7S doesn't remain locked to lower fallback states on fresh updates.Let me know if you need the raw diff -u dump of the modified .dts files attached! cubie_a7s.zip 0 Quote
stary presporak Posted June 5 Posted June 5 test with 1.5V CPU voltage, the SBC draws over two amps. You need a really good active heatsink. 7-Zip (r) 25.01 (arm64) : Igor Pavlov : Public domain : 2025-08-03 64-bit arm_v:8-A locale=en_US.UTF-8 Threads:8 OPEN_MAX:1024, ASM Compiler: ver:14.2.0 GCC 14.2.0 : UNALIGNED Linux : 6.6.98-vendor-sun60iw2 : #2 SMP PREEMPT Fri May 15 10:57:21 CEST 2026 : aarch64 PageSize:4KB hwcap:119FFB:CRC32:SHA1:SHA2:AES:ASIMD arm64 1T CPU Freq (MHz): 1267 2000 2000 2000 2000 2000 2000 4T CPU Freq (MHz): 366% 1621 367% 1631 8T CPU Freq (MHz): 742% 1561 746% 1580 RAM size: 5906 MB, # CPU hardware threads: 8 RAM usage: 1779 MB, # Benchmark threads: 8 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 9894 757 1272 9625 | 226530 685 2821 19317 23: 9405 767 1249 9583 | 219768 687 2768 19010 24: 8867 766 1245 9535 | 213378 689 2717 18722 25: 8382 753 1271 9571 | 205891 692 2649 18320 ---------------------------------- | ------------------------------ Avr: 9137 761 1259 9578 | 216392 688 2739 18842 Tot: 724 1999 14210 And the same test with 1.32V, SBC draws 1.5 amps Last login: Fri Jun 5 11:11:21 2026 from 192.168.11.50 root@radxa-cubie-a7s:~# 7zr b 7-Zip (r) 25.01 (arm64) : Igor Pavlov : Public domain : 2025-08-03 64-bit arm_v:8-A locale=en_US.UTF-8 Threads:8 OPEN_MAX:1024, ASM Compiler: ver:14.2.0 GCC 14.2.0 : UNALIGNED Linux : 6.6.98-vendor-sun60iw2 : #2 SMP PREEMPT Fri May 15 10:57:21 CEST 2026 : aarch64 PageSize:4KB hwcap:119FFB:CRC32:SHA1:SHA2:AES:ASIMD arm64 1T CPU Freq (MHz): 1393 1682 2000 2000 2000 2000 2000 4T CPU Freq (MHz): 369% 1606 367% 1634 8T CPU Freq (MHz): 743% 1552 745% 1573 RAM size: 5906 MB, # CPU hardware threads: 8 RAM usage: 1779 MB, # Benchmark threads: 8 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 9314 722 1254 9061 | 224321 686 2790 19128 23: 8943 752 1211 9113 | 217854 688 2739 18845 24: 8556 749 1228 9200 | 210699 688 2686 18487 25: 8216 754 1244 9382 | 202281 686 2623 17999 ---------------------------------- | ------------------------------ Avr: 8758 745 1234 9189 | 213789 687 2710 18615 Tot: 716 1972 13902 root@radxa-cubie-a7s:~# 0 Quote
stary presporak Posted June 5 Posted June 5 (edited) https://github.com/ThomasKaiser/sbc-bench/blob/master/results/rca7s.txt here are my results with an old (November 2025) kernel Edited June 5 by stary presporak 0 Quote
Jacob George Posted June 5 Posted June 5 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. 0 Quote
alexc Posted Saturday at 05:22 AM Posted Saturday at 05:22 AM @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. 0 Quote
Jacob George Posted Saturday at 01:56 PM Posted Saturday at 01:56 PM @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 0 Quote
operator Posted Tuesday at 02:00 PM Posted Tuesday at 02:00 PM I can not get anything over USB to UART, I did connected pins 6,8,10 it is COM6 Prolific PL2303GT cable, when I cros wire green and yellow I get response from Putty, please give me some advice, what am I missing? 0 Quote
humanus Posted Tuesday at 02:22 PM Posted Tuesday at 02:22 PM @Jacob George So we will be able to boot Windows on the A733 soon? This would be fun. 0 Quote
Sand_Death Posted 10 hours ago Posted 10 hours ago @Nick A @alexc Update: Hailo8 AI HAT issue - Root cause found First, a quick update on the Ethernet issue — I set the board aside for a while, noticed some activity in the GitHub repository, rebuilt the firmware, and it worked. Now I'm trying to run Frigate with a Hailo8 AI HAT (marketed for Raspberry Pi 5, with an M.2 slot). The device loads firmware successfully but becomes completely unresponsive. After extensive debugging I believe I found the root cause. Problem: MSI interrupts not working bash$ cat /sys/bus/pci/devices/0000:04:00.0/msi_irqs/ # empty — MSI not configured $ lspci -vvv -s 04:00.0 | grep MSI Capabilities: [e0] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 # Address is zero — MSI never configured by kernel $ cat /proc/interrupts | grep hailo # empty — no interrupt handler registered Interrupt: pin ? routed to IRQ 492 # "?" means no INTx routing either Hailo8 uses MSI interrupts to signal command completion. Without MSI, every fw_control ioctl waits 1000ms and times out. The device loads firmware successfully but becomes unusable for any actual inference. PCIe topology: 00:00.0 Root Port 01:00.0 ASMedia ASM1182e PCIe Switch (upstream) 02:07.0 ASMedia ASM1182e PCIe Switch (downstream) 04:00.0 Hailo-8 AI Processor Kernel: 6.18.19-edge-sun60iw2 (Armbian community build) It seems the sunxi PCIe driver does not support MSI for devices behind an ASMedia PCIe switch. Is this a known limitation? Is there a fix or workaround available? 0 Quote
humanus Posted 10 hours ago Posted 10 hours ago @Sand_Death congrats on finding this... I also found the sunxi PCIE driver to be limited. I think someone would need to develop it a bit, or write something from scratch, in order to get more devices to work. 0 Quote
Sand_Death Posted 5 hours ago Posted 5 hours ago @Nick A @alexc Sorry for being so pushy, I had some time today and was tinkering with this board (Claude helped me with this). Like all AI, it can make mistakes, but it thinks this is the root of the problem (I wasted almost 6 hours today on this and all the weekly limits lol). Anyway, here's his summary of what's wrong, but since I'm not a developer, I can neither confirm nor deny what he says. Hailo8 AI Accelerator on Radxa Cubie A7A - Full Debug Report Hardware: Board: Radxa Cubie A7A (Allwinner A733/sun60iw2, 8-core) AI HAT: Makerobo Hailo8 HAT (M.2 + FPC connector, designed for RPi5) PCIe topology: Root Port → ASMedia ASM1182e switch → Hailo-8 Kernel tested: BSP: 6.18.19-edge-sun60iw2 (NickAlilovic/build Radxa-A7A branch) Mainline BSP: 6.18.35 (alexcaoys/allwinner-bsp linux-6.18.y branch, custom build) Symptoms: Every fw_control ioctl times out with HAILO_DRIVER_TIMEOUT(87). Device loads firmware successfully, /dev/hailo0 is created, but becomes completely unusable for inference. Debug journey: First suspected power management (D3cold issues) — fixed with no_power_mode=1 parameter Suspected wrong FPC cable (RPi5 vs Radxa PIEX) — ruled out after comparing schematics, pinouts are identical Found RxErr+ on ASMedia switch ports in AER — suggested physical signal issues Root cause found: MSI interrupts not working MSI investigation results: # MSI not configured $ cat /sys/bus/pci/devices/0000:04:00.0/msi_irqs/ # empty $ lspci -vvv -s 04:00.0 | grep MSI Capabilities: [e0] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 # Address zero = MSI never configured # IRQ routing broken Interrupt: pin ? routed to IRQ 482 # "?" = no INTx routing either After building custom kernel 6.18.35 (alexcaoys/allwinner-bsp): # Progress! IRQ now routes properly Interrupt: pin A routed to IRQ 482 # pcie-msi IRQ exists! 479: 1 wakeupgen 153 Level pcie-msi But MSI still not working for endpoint devices: $ cat /sys/bus/pci/devices/0000:04:00.0/msi_irqs/ # still empty $ dmesg | grep ITS ITS: No ITS available, not enabling LPIs Root cause analysis: The sunxi-pcie driver handles MSI internally via wakeupgen interrupt controller (IRQ 479, pcie-msi). However, this MSI handler is not exposed as a standard PCI msi-controller node that endpoint devices (like Hailo8) can use through the standard Linux PCI MSI API. Without a proper msi-controller, pci_alloc_irq_vectors() falls back to legacy INTx. But INTx routing through ASMedia ASM1182e PCIe switch also doesn't work properly — device shows pin ? (no routing) instead of pin A. Hailo8 requires MSI for fw_control command completion notifications. Without working interrupts, every ioctl waits 1000ms and times out. What needs to be fixed: The sunxi-pcie driver needs to register a proper msi-controller so endpoint devices behind the PCIe bus can use standard PCI MSI API OR legacy INTx routing needs to work through ASMedia switch (currently pin ?) The DTB PCIe node has interrupt-names = "sii", "msi" but the MSI interrupt is not wired to standard PCI MSI infrastructure PCIe topology for reference: 00:00.0 Root Port (1f6d:abcd) 01:00.0 ASMedia ASM1182e upstream port 02:07.0 ASMedia ASM1182e downstream port 04:00.0 Hailo-8 AI Processor (1e60:2864) Links: Forum post: https://forum.radxa.com/t/hailo8-pcie-fw-control-timeout-on-cubie-a7a-with-asmedia-pcie-switch/31023 (posted about FPC cable and MSI issue) Hailo driver: https://github.com/hailo-ai/hailort-drivers/tree/hailo8 If necessary, I can also open an issue on GitHub and bring this problem to the attention of the board developers, because the behavior is the same on the stock core. 0 Quote
alexc Posted 1 hour ago Posted 1 hour ago Hi @Sand_Death, Thanks a lot for identifying this! Could you please check if this also happens on the kernel provided by Radxa? If it works on their side, it's likely something we need to address in our configuration. Since PCIe is still handled by the vendor's BSP, if it's a bug on their end, it would be best to open an issue with Radxa first. I'm happy to take a closer look once I have some time later. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.