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

Basicly, a LLM has dozens of transformer layers (attention layer + ffn layer). We cannot load the whole model data, or even a single transformer layer on NPU sram(~1MB). So, we put the whole model in RAM, transport a slice of data to NPU by command stream each time, then next slice. Several times of the model size may be transported between ddr and npu. This cost is huge so I still run LLM on pure cpu.

It's ARMv7 so it could potentially run 64bit instructions. https://developer.arm.com/documentation/den0013/0400/Introduction-to-Assembly-Language/The-ARM-instruction-sets I recall reading that opi pc is running 64-bit from someone here on armbian forums now that I think about it, but don't remember where. It could also be a Mandela effect and I am completely wrong. If so, I'm sorry, did not mean to make you upset. Not hard to miss at all, or you think everybody has every single board memorized? 😉 If you included that you think it should run 32 bit instructions and has a 32bit kernel, I would have asked you to provide "uname -m" to confirm, no need to be nasty. 🙃 Kinda strange that you could get the system running with su in 64bit with a 32bit kernel though.

If you plan to add this to the Armbian framework to have it included, I suggest to bring the drive in a dkms compatible state and create an extension (https://github.com/armbian/build/tree/main/extensions) to add this driver to specific boards. I know that other out-of-tree wifi drivers are added here (https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh), however this is already a huge mess and I won't allow any more additions, rather than looking forward to some point in the future when this is dissolved in to individual extensions which make things hopefully more maintainable. AI will probably a huge help in this matter.

If this is really the case, then this must be an upstream issue since Armbian does not touch this file AFAIK. Picked a random userspace from armhf (since you did not state which you are using) ~/build/cache/rootfs/bin# file su su: setuid ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=b24ceef58082e181650b17e52819559be2d3a97b, for GNU/Linux 3.2.0, stripped