@alexc

I tested the modified kernel and asked Claude to report it, he reported it like this.

System Refinement and Build Optimization Report

Feedback

1. MSI Fix Confirmed Working

Details: The MSI fix has been verified and successfully tested on Hailo8L (sun60iw2/A733 platform).

Result: Massive reduction in system load: load avg dropped from 18+ to ~12, and Frigate CPU usage plummeted from 485% to 83% during real-world inference.

High Priority

2. sunxi-autogen.h in .gitignore

Issue: This file is currently ignored by .gitignore, yet it is strictly required for the build to succeed and is not automatically generated.

Solution: Either implement automatic generation of this file inside the Makefile OR properly document the creation steps in the README.

3. Undocumented LOCALVERSION Behavior

Issue: Building from a dirty Git tree automatically appends a + suffix to the kernel version string, leading to a critical vermagic mismatch for compiled modules.

Solution: Document this behavior in the README or enforce proper default behavior in the default configuration file.

Medium Priority

4. Missing BSP_TOP Export

Issue: Running make olddefconfig crashes unless BSP_TOP=bsp/ is explicitly passed as an environment variable.

Solution: Add path auto-detection directly into the root Makefile to make the build self-contained.

5. Missing DKMS Config for hailo_pci

Issue: Since this is an out-of-tree module, users must manually rebuild it after every routine kernel update.

Solution: Provide a DKMS configuration to automate the rebuild process on the OS level.

Low Priority

6. hailo_pci Driver Integration in initramfs

Issue: The module is not automatically included in the initramfs image during the build phase.

Solution: Create a dedicated hook script or add a section in the documentation explaining manual configuration via modules-load.d and update-initramfs.

7. Overly Permissive /dev/hailo0 Permissions (World-Writable)

Issue: The device node permissions are set to crw-rw-rw- (anyone can write to it), which poses a security risk.

Solution: Deploy a standard udev rule to restrict permissions and grant access safely via a dedicated system group.

 

!!! At the moment, I confirm that it works with these edits.

@Sand_Death

Really interesting read! Would it be possible to submit these changes through GitHub or as a kernel patch? We'd love to see the full context of the changes—the code actually provides such a clear picture of what's happening (even more so than the docs!), so a proper review of the diff would be great.

 

EDIT: Looking at the description, it seems Claude addressed the issue on the Hailo driver side rather than fixing it in the PCIe driver. Personally, I don't think that's the ideal approach, since the BSP PCIe driver appears to be the root cause. If you get a chance to try my patch instead, I'd be interested to hear how it works for you.

Edited June 13Jun 13 by alexc

@alexc

Hi, thanks for the response and for the patch!

Just to clarify — we actually used your PCIe BSP fix (commit a9eaa51d) and the stock, unmodified hailo_pci 4.21.0 driver from the official Hailo GitHub (v4.21.0 tag). No changes were made to the Hailo driver side at all.

Earlier in the process we had experimented with workarounds on the Hailo driver (INTx bypass + polling thread), but those were reverted completely before the final test. The report describes the end state: your kernel patch + stock driver.

Result with your fix:

hailo 0000:04:00.0: Enabled MSI interrupt

No INTx fallback, no polling. Load average dropped from 18+ to ~12, Frigate CPU from ~485% to ~83% (real inference on 9 cameras).

Regarding the GitHub PR / kernel patch — that would be great. The fix is clearly in the right place (PCIe driver), and a proper patch submission would help other Allwinner A733 users with PCIe devices.
 

Hello friends. I ask for help in creating firmware with TOC0. Unfortunately, I once launched Android firmware from a Teclast tablet on my A7A board, and apparently eFuse burned out. Now standard firmware with eGON.BT0 will not run on this board. Or tell me where to fix it so that the firmware from the sources is compiled with TOC0.

@flintduvaд secure boot might be similar to older Allwinner SOCs.

 

https://forum.armbian.com/topic/58803-i-need-secure-image-x98h-pro/#comment-235213

 

 

Thank you, bro. I'll try it this evening after work. I'll post the results.

Looks like I'm stupid. I can’t figure out which _defconfig is used to compile u-boot for cubie-A7A. I understand that 2022.07 is used as the source, but there is no necessary _defconfig in the configs folder. Accordingly, I don’t understand which file to write a patch for, or which patch to make changes to. I ask for help in writing the required patch.

https://github.com/radxa-pkg/u-boot-aw2501
 

This is the radxa u-boot build. The important build scripts are in the  Makefile.local and the ones in the main directory. 
 

I believe the patch directory is in the Debian folder. 
 

https://github.com/radxa-pkg/u-boot-aw2501/blob/main/.github/local/Makefile.local

 

https://docs.radxa.com/en/cubie/a7a/low-level-dev/build-system/u-boot

 

Use AI to help you figure it out.

 

My armbian build downloads the official uboot deb package. But I also added a directory for custom uboot packages that overrides the official package.

Edited June 22Jun 22 by Nick A

Hi @Nick A — great work on these builds, I've been testing both your BSP (v0.6.4, kernel 6.6.98) and Mainline (V0.1, kernel 6.18.19) images on a Cubie A7Z with a custom carrier board. Both work well for general use.

I've been trying to get a W5500 SPI-to-Ethernet chip working on SPI2 and ran into a consistent issue across both kernels that might be worth looking at.

Issue: sunxi-spi-ng child device never gets probed

The SPI2 controller itself initialises correctly on both kernels:

sunxi-spi-ng 2542000.spi: probe success (Version 2.5.4)

But the child device (spi2.0) never gets a driver bound to it. The w5100-spi driver is loaded, the modalias matches (spi:w5500), fw_devlink=off is set, yet:

echo spi2.0 | tee /sys/bus/spi/drivers/w5100/bind → No such device

echo spi2.0 | tee /sys/bus/spi/drivers_probe → accepted, no effect, zero dmesg output

Dynamic debug enabled (module w5100 +p) → zero probe activity

This reproduces on:

Radxa BSP kernel 5.15.147-21-a733 (official r6 image)

Your BSP build kernel 6.6.98

Your Mainline build kernel 6.18.19

All three use the same spi-sunxi-ng.ko / spi_sunxi_ng driver (same allwinner,sunxi-spi-v1.3 compatible string).

Hardware confirmed good: the same W5500 chip on the same physical pins works perfectly when an ESP32-S3 is plugged in instead — DHCP, real network data, everything. Raw spidev access on the Radxa also reads correct W5500 registers. The bug is specifically in sunxi-spi-ng's child device registration preventing any driver from binding.

Overlay used:

dts

/dts-v1/; /plugin/; &spi2 { status = "okay"; sunxi,spi-bus-mode = <1>; sunxi,spi-cs-mode = <0>; eth0: ethernet@0 { compatible = "wiznet,w5500"; reg = <0>; spi-max-frequency = <20000000>; }; };

Note: sunxi,spi-bus-mode = <0> is rejected at probe time with error -22 ("unsupport hw bus mode 0x0"), so <1> is the only accepted value.

Has anyone else seen this? Is there a known workaround for getting SPI child devices to bind under sunxi-spi-ng on A733?

Thanks for the great work Nick.

 

I recently bought a SPI screen and managed to drive it with panel-mipi-dbi in the newer kernel (apparently this module didn't exist in Radxa's official image with kernel 5.15).

 

The panel was a ST7789V 240*320 TFT LCD and I have a A7Z, with the `Radxa-cubie-A7a-a7z-v0.6.4` server image installed.

 

And I have put the work on [Github](https://github.com/parker-int64/sun60i-a733-dtoverlays). During the experiment, I discovered that the PWM (used for display backlight) in the allwinner BSP seems to have a bug.

The Allwinner Sunxi PWM driver may incorrectly reverts the PWM pin to GPIO input immediately after switching the pinctrl state. Thus I can control the PWM with the file nodes but can't attached it to related pins.

For example, I'm using the `sun60i-a733-pwm1-7.dtso` overlay, which is supposed to enable the PJ25. After enabling the overlay, I noticed that the PWM nodes were created and I can controll these nodes. But the pinctrl suggest that it was unclamied:

 

$ cat /sys/kernel/debug/pinctrl/2000000.pinctrl/pinmux-
  pins | grep PJ25
  pin 313 (PJ25): UNCLAIMED

 

Later on, AI found out that the `devm_pinctrl_put(pctl);` in bsp/drivers/pwm/pwm-sunxi.c  may have been incorrectly called on the clean stage of the `sunxi_pwm_pin_set_state`:

   520  static int sunxi_pwm_pin_set_state(struct device *dev, char *name)
   521  {
   522          struct pinctrl *pctl;
   523          struct pinctrl_state *state = NULL;
   524          int err;
   525
   526          pctl = devm_pinctrl_get(dev);
   527          if (IS_ERR(pctl)) {
   528                  sunxi_err(dev, "pinctrl_get failed\n");
   529                  err = PTR_ERR(pctl);
   530                  return err;
   531          }
   532
   533          state = pinctrl_lookup_state(pctl, name);
   534          if (IS_ERR(state)) {
   535                  sunxi_err(dev, "pinctrl_lookup_state(%s) failed\n", name);
   536                  err = PTR_ERR(state);
   537                  goto exit;
   538          }
   539
   540          err = pinctrl_select_state(pctl, state);
   541          if (err) {
   542                  sunxi_err(dev, "pinctrl_select_state(%s) failed\n", name);
   543                  goto exit;
   544          }
   545
   546  exit:
   547          /*
   548           * devm_pinctrl_put() releases the last pinctrl reference,
   549           * causing pinmux_disable_setting() to restore the pin to
   550           * its default GPIO function. The devres framework will
   551           * release this resource automatically when the device is
   552           * destroyed.
   553           */
   554          devm_pinctrl_put(pctl);
   555          return err;
   556
   557  }

 

Also it gives me a workaround `sunxi-pwm-child-pinctrl.c`, introduces an additional pinctrl reference, preventing `devm_pinctrl_put()` from reducing the reference count to zero.  Both the patch file and the workaround source is available on Github. However I only tried the workaround since I have some trouble compile the full kernel at the moment, will try some time later and update more details on Github.

 

And at last the pwm-backlight worked as expected and my LCD light up.

 

 I have been working on the same A733 GPU problem from the vendor-kernel side and now have a hardware-validated Cubie A7Z image available.
  
   Verified on a physical A7Z:
  
   - PowerVR BXM-4-64 hardware rendering instead of llvmpipe
   - Vulkan, OpenCL 3.0, EGL/GBM and OpenGL ES 3.2
   - Hardware-accelerated Plasma Wayland/KWin
   - Packaged XWayland acceleration
   - Ready-to-flash Debian 12 image
   - Vendor-kernel fallback and early-fsck recovery boot entries
  
   Repository and validation evidence:
   https://github.com/cuihuir/radxa-a7z-debian12

  
   This is not an Armbian image and currently uses the 5.15 A733 BSP kernel with the matching PowerVR DDK. It may still be useful as a working reference for comparison with the experimental
   mainline PowerVR work in this thread. Additional A7Z hardware reports are welcome.

@humanus

 

I am back in the lab and near completion of the EDK2 port. @edk2-a733

 

A Gift:

I have found some useful documentation that could help everyone in this thread. 

A733_Datasheet_V0.92.pdf [3.7MB]

A733_User Manual_V0.92.pdf [73MB]

I'm struggling to build the kernel with the USB_F_TCM module. I would like to know if the USB 3.0 OTG support is available yet or if the hardware support isn't quite ready yet. 
I attempted to provide my current kernel build's config file, but I got a 200 error when trying to upload it.

The Allwinner A733 EDK2 Port has hit a major milestone. NVME link is up and running. 

Looks great, but Allwinner A733 is 2x Cortex-A76 and 6x Cortex-A55

Maybe Claude should apologize.

 

@eselarm 

holy smokes I didn't even catch it, thanks!

 

Opus 5 Reply: "

Definitive — the reviewer is right, and it's a real bug rather than a typo. MIDR straight off the silicon:

cpu0-cpu5  part=0xd05  Cortex-A55   max 1794 MHz
cpu6-cpu7  part=0xd0b  Cortex-A76   max 2002 MHz

2× Cortex-A76 + 6× Cortex-A55. Our README says it correctly in one place (line 352) and incorrectly in another (line 120), and — worse — SunxiSmbiosDxe reports 4x A76 + 4x A55 in the SMBIOS Type 4 table, so every OS that boots this firmware is being told the wrong CPU topology. That's not a doc nit; it's wrong data on the wire.

Let me see the surrounding context before fixing."

Edited August 25Aug 25 by Jacob George

On 7/18/2026 at 9:21 PM, parker-int64 said:

I recently bought a SPI screen and managed to drive it with panel-mipi-dbi in the newer kernel (apparently this module didn't exist in Radxa's official image with kernel 5.15).

 

I am glad that someone else is also using that LCD driver. In the Raspberry community, it is also the favorite driver for LCDs, since it is universal and works well with Wayland.

 

 

There are several threads here, in the Raspberry forum and the notro repository: https://github.com/notro/panel-mipi-dbi/discussions

 

The signal inversion seems to be a deliberate change from linux 5.x to linux 6.x.

 

This panel-mipi-dbi can also be used with bigger SPI LCDs, but you need to upgrade to 6.x (cant remember which) to use the big and cheap ILI9486, ILI9488, and even accelerated video is possible.

 

 

 

I have seen the Orange Pi 4 Pro being mentioned. Is it similar enough to the Radxa A7* to use the same DTS? Is the Oranpe Pi Zero 3w also similar enough? (it has the same form factor as the Radxa A7z and same A733).

 

Jacob, you should understand everything that Claude produces for you. Keep track of what it's changing in the EDK code.

Make a diff patch from the unchanged code, and the code you are compiling. All the differences need to be sanity-checked by regular users, and rationalized by experts.

And share a link to the starting original EDK.

Edited August 25Aug 25 by robertoj

@robertoj

I thought that is what github provides, a complete track record of commits, pushes and changes? It's all there, I also have had contributor's. It's being sanity checked. The Orange Pi 4 Pro is nearly identical to Radxa Cubie A7A, I will be making a branch for the A7A shortly.

On 8/26/2026 at 6:42 AM, Jacob George said:

@robertoj

I thought that is what github provides, a complete track record of commits, pushes and changes? It's all there, I also have had contributor's. It's being sanity checked. The Orange Pi 4 Pro is nearly identical to Radxa Cubie A7A, I will be making a branch for the A7A shortly.

Thank you Jacob

I hope to get a orange pi zero 3w in the near future, for NPU tasks (face and pose detection)

Hi folks, is there coverage for the Cubie A7S? thanks

Following on from @cuihuir’s A7Z image (PowerVR + Vulkan + OpenCL + Wayland) and @robertoj’s interest in the Zero 3W above — ported the same bring-up to an Orange Pi Zero 3W on Armbian (not Debian) and wrote it up in full: https://github.com/davidhfrankelcodes/pvr-a733-armbian

 

Same SoC/GPU (A733, sun60iw2, PowerVR BXM-4-64), different distro/kernel base, so a few things diverged. Three things came out of it that I don’t think exist anywhere else yet, in case they’re useful to others on Cubie/Zero3W/4Pro too since the DTS issue below isn’t board-specific:

 

1. GCC 15 build fix for the pvrsrvkm DRM-PRIME patch from ayiejosh/a733-powervr-fex — it doesn’t build as published under GCC 15’s -Wstringop-overread (-Werror in kernel builds), which is what Ubuntu 26.04/Armbian resolute ships. Standalone patch, no functional change: patches/gcc15-stringop-overread-fix.patch

 

2. A published Vulkan feature-strip layer — zink needs geometryShader and VK_EXT_robustness2/nullDescriptor, which this closed driver doesn’t report. The original repo describes faking these (“the feature-strip layer”) but never shipped source for it; this is a from-scratch implementation, verified with a pixel-readback test (real GPU-rendered output, not just “it didn’t crash”): vk-feature-strip/vk_layer_pvr_strip.c

 

3. The GPU clock is capped at 600 MHz on every sun60iw2 board Armbian ships — checked the Zero 3W, 4 Pro, and Armbian’s own Cubie A7Z DTB, none of them set it. Root cause: the vendor driver (sunxi_platform.c in the img-bxm-dkms source) reads a plain clk_rate DT property and hardcodes 600 MHz if it’s missing — it’s not the standard OPP/devfreq framework. Each board’s DTS already ships a GPU OPP table with a vendor-supplied 1008 MHz step (with real voltage data), just never wired up. A small DT overlay fixes it — verified stable with clpeak, throughput scales ~1:1 with the clock ratio (35 → 59.88 GFLOPS float4): dts-overlay/sun60i-a733-gpu-clk-1008m.dts

 

Full log with every step, dead ends, and exact package versions: https://github.com/davidhfrankelcodes/pvr-a733-armbian/blob/main/ARMBIAN-REPLICATION.md

 

Known limitation, not attempted on purpose: a live GPU-composited desktop reproducibly deadlocks the kernel under this closed driver (same wall the original repo hit) — off-screen rendering is the ceiling regardless of distro, as far as I can tell. Maybe I need to read Armbian posts more broadly to find out.

 

Happy to answer questions or compare notes if anyone’s hitting the same DTS gap on a different sun60iw2 board. I did most of this with LLM (claude).

Hello.

 

I’m having a problem with my new A7A: the wired network won't start. I'm seeing these errors in dmesg. I’d appreciate any help.

 

 dmesg | grep 4500000.ethernet
[    3.608064] [      T1] dwmac-sunxi 4500000.ethernet: IRQ eth_wake_irq not found
[    3.620779] [      T1] sunxi:stmmac-4500000.ethernet:[INFO]: Phy use soc fanout
[    3.732369] [      T1] sunxi:stmmac-4500000.ethernet:[INFO]: Not found delay-maps in dts
[    3.807708] [      T1] sunxi:stmmac-4500000.ethernet:[INFO]: RGMII use internal transmit clock
[    3.817738] [      T1] dwmac-sunxi 4500000.ethernet: User ID: 0x20, Synopsys ID: 0x53
[    3.840266] [      T1] dwmac-sunxi 4500000.ethernet:         DWMAC4/5
[    3.849643] [      T1] dwmac-sunxi 4500000.ethernet: DMA HW capability register supported
[    3.849646] [      T1] dwmac-sunxi 4500000.ethernet: RX Checksum Offload Engine supported
[    3.849649] [      T1] dwmac-sunxi 4500000.ethernet: TX Checksum insertion supported
[    3.849651] [      T1] dwmac-sunxi 4500000.ethernet: Wake-Up On Lan supported
[    3.849696] [      T1] dwmac-sunxi 4500000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    3.867460] [      T1] dwmac-sunxi 4500000.ethernet: device MAC address 6a:4e:c2:02:37:de
[    3.867465] [      T1] dwmac-sunxi 4500000.ethernet: Enabled RFS Flow TC (entries=10)
[    3.867469] [      T1] dwmac-sunxi 4500000.ethernet: Using 32/40 bits DMA host/device width
[    4.113902] [      T1] sunxi:stmmac-4500000.ethernet:[INFO]: probe success (Version 0.3.2)
[   21.737564] [    T910] dwmac-sunxi 4500000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   22.069459] [    T910] dwmac-sunxi 4500000.ethernet eth0: PHY [stmmac-0:01] driver [Generic PHY] (irq=POLL)
[   23.084613] [    T910] dwmac-sunxi 4500000.ethernet: Failed to reset the dma
[   23.092308] [    T910] dwmac-sunxi 4500000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[   23.103005] [    T910] dwmac-sunxi 4500000.ethernet eth0: __stmmac_open: Hw setup failed
[   23.973831] [    T910] dwmac-sunxi 4500000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   24.305606] [    T910] dwmac-sunxi 4500000.ethernet eth0: PHY [stmmac-0:01] driver [Generic PHY] (irq=POLL)
[   25.321556] [    T910] dwmac-sunxi 4500000.ethernet: Failed to reset the dma
[   25.329227] [    T910] dwmac-sunxi 4500000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[   25.329235] [    T910] dwmac-sunxi 4500000.ethernet eth0: __stmmac_open: Hw setup failed
[   25.397667] [    T910] dwmac-sunxi 4500000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   25.725509] [    T910] dwmac-sunxi 4500000.ethernet eth0: PHY [stmmac-0:01] driver [Generic PHY] (irq=POLL)
[   26.737548] [    T910] dwmac-sunxi 4500000.ethernet: Failed to reset the dma
[   26.745206] [    T910] dwmac-sunxi 4500000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[   26.745215] [    T910] dwmac-sunxi 4500000.ethernet eth0: __stmmac_open: Hw setup failed
[   26.812831] [    T910] dwmac-sunxi 4500000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   27.141519] [    T910] dwmac-sunxi 4500000.ethernet eth0: PHY [stmmac-0:01] driver [Generic PHY] (irq=POLL)
[   28.154000] [    T910] dwmac-sunxi 4500000.ethernet: Failed to reset the dma
[   28.161642] [    T910] dwmac-sunxi 4500000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[   28.161650] [    T910] dwmac-sunxi 4500000.ethernet eth0: __stmmac_open: Hw setup failed
[   28.223930] [    T910] dwmac-sunxi 4500000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   28.553610] [    T910] dwmac-sunxi 4500000.ethernet eth0: PHY [stmmac-0:01] driver [Generic PHY] (irq=POLL)
[   29.573918] [    T910] dwmac-sunxi 4500000.ethernet: Failed to reset the dma
[   29.581569] [    T910] dwmac-sunxi 4500000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[   29.592224] [    T910] dwmac-sunxi 4500000.ethernet eth0: __stmmac_open: Hw setup failed

@deva67

 

Yes, I run a Radxa Cubie A7S on mainline 6.18 (now 6.18.54) with an A733 patch
series on top. No BSP kernel; a few drivers are ported from Allwinner's BSP and
say so in their headers.

 

All of it is public as a build recipe: https://github.com/DockSeed/a7s-build

 

One ./build.sh builds the boot chain, the kernel and a Debian 13 image in a
container. The patches are single files with their origin in the header
(kernel/6.18/patches/). Vendor binaries (boot0 with the DRAM init, GPU and
WLAN firmware) are downloaded at build time, not shipped.

 

What I have measured on the A7S:
- eMMC at HS400 (200 MHz, 8 bit, 1.8 V): about 290 MB/s sequential read at
  64 KiB requests, md5-equal data, same result across cold starts.
- SD card at SDR104, 20 of 20 cold starts, about 91 MB/s sequential read.

I am not a kernel developer. The measurements come from my board; the analysis
and code were done with the help of an AI assistant (Claude).

 

@Nick A  @alexc

 

I can offer the patches one topic at a time, eMMC first, since
eMMC on the A7A/A7S still looked open here. Where should they go: into your
6.18 kernel, or onto the mainline work in PR #10712? I will prepare them for
whichever you prefer.

@normanherms great thanks. seems amazing work. I shall try it.

 

But I have an old 'weak' desktop Might be a showstopper for compiling the image (It's a i5 4570 cpu).

If I can successfully build images, I can volunteer to test too. Thanks.

@normanherms 

I was able to boot and ping the a7s board. I'm unable to ssh though. I don't have a TTL-bridge to setup the password!

PS the build took around 50mins.

 

EDIT: I was able to hook up a UART TTL bridge and login! bootlog here: https://pastebin.com/9H0gyYAJ

Edited October 5Oct 5 by deva67
updates