Dear Bedna Even though the Orange Pi PC had a 64-bit ARM processor it could not execute a program of the Intel x86-64 architecture The purpose of my post was not to ask for help, it was simply to notify the port maintainer(s) for this SoC that there was a command/executable/compiled/binary/program (use the name that looks best and most correct for you) of the Intel 64 architecture in the /usr/ bin directory of an ARM 32 system. I did not imagine that Armbian foruns get so hostile and aggressive and I will close my account as soon as possible.

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

I am coming from a yocto build for a dev board. I had to make u-boot patches, kernel config changes, and custom DTS tree. I'm trying to adapt this to Armbian, one step at a time. I started with building am image for sk-am62b.conf. I did not expect u-boot to boot from correctly. I was glad to see console messages, but expectedly, u-boot didn't continue. I made a new board config for this, duplicating sk-am62b.conf, but changing a critical line I made to get this to work previously. TIBOOT3_FILE="tiboot3-am62x-gp-evm.bin" Now, the boot process gets through u-boot and loads the Linux kernel. However, the kernel halts because it cannot find the root file system. Waiting for root device PARTUUID=26aa2b10-02... I confirmed the device in u-boot, and it seems to agree. Environment size: 5112/126972 bytes => echo load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile} load mmc 1:2 0x88000000 /boot/dtb/ti/k3-am625-sk.dtb => run finduuid => echo part uuid ${boot} ${bootpart} uuid part uuid mmc 1:2 uuid => part uuid mmc 1:2 26aa2b10-02 I then modified my board config: BOOT_FDT_FILE="myir-6254-am62x/myir-6254-am62x.dts" But after booting, u-boot didn't acknowledge this: (From the u-boot environment) fdtfile=ti/k3-am625-sk.dtb So, I finished applying my u-boot patches that I made under the Yocto build. Some of these changes may be redundant: edited: am62x_evm_a53_defconfig + CONFIG_DEFAULT_FDT_FILE="myir-6254-am62x.dts" +CONFIG_TI_FDT_FOLDER_PATH="myir-6254-am62x" After booting into u-boot, now I see the change made: fdtfile=myir-6254-am62x.dts Then I see this: Running uenvcmd ... 14857759 bytes read in 983 ms (14.4 MiB/s) 36805120 bytes read in 1549 ms (22.7 MiB/s) Failed to load '/dtb/myir-6254-am62x.dts' libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree Scanning for bootflows in all bootdevs This is not unexpected either - since the files are not the image yet. When u-boot can't find the device tree, it loads a grub interface. And when I 'e'dit that I see the line linux /Image root=PARTUUID=076c4a2a-02 rootwait rootfstype=ext4 and change it to: linux /Image root=/dev/mmcblk1p2 rootwait rootfstype=ext4 The kernel sees the rootfs, and proceeds to boot. If I change it to using the PARTUUID, as above, it also boots. If I manually place the DTB file where u-boot reported it is is looking (copied from my running yocto system) (in /dtb/) The kernel boots, without the grub interface. However, the same situation occurs, where it is waiting for the root device. Waiting for root device PARTUUID=26aa2b10-02... I have a few things going on here. I think in order to boot to an OS I need: 1) Solve why the kernel does not see the root partition when booting from u-boot (but does when I can get into the grub interface) 2) How to properly implement a custom device tree structure. I know there are overlays, but I'd prefer to just drop in my whole custom tree. Once I get there, I can proceed to implement some of the kernel modification I did within the yocto build environment, but this first. Thanks for the assistance.

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

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