Radxa Cubie A7A/A7Z - Allwinner a733

[Sand_Death]

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

[alexc]

@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 13 by alexc

[Sand_Death]

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

[flintduvaд]

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.

[Nick A]

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

 

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

 

 

[flintduvaд]

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

[flintduvaд]

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.

[Nick A]

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 22 by Nick A

[IoT_maker]

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?

[parker-int64]

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.