All Activity

I haven’t tested this yet but there’s some work done on vp9 and vc1 support for Allwinner. https://github.com/jernejsk/linux-1/tree/vp9-v1 https://github.com/jernejsk/linux-1/tree/vc1-v2

I warmly back @Werner suggestion; dkms for legacy wifi drivers is the best way to go (I only need to do it myself for some wifi drivers still laying around ...)

@Werner Great suggestion! The repo has been updated to support DKMS and Extension. https://github.com/cdhigh/armbian_sv6256p

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'm trying to use the radxa 4k camera with armbian. The camera worked on Radxa OS but i wanted to have more camera drivers, hence why I made a custom armbian build with more drivers enabled. The /boot/dtb/ folder was missing so I tried to get the same structure as what I have on my radxa zero3 /boot/dtb/qcom/overlay/qcs6490-radxa-cm-q64-rpi-cm5-io-cam0-imx415.dtbo /boot/dtb/qcom/qcs6490-radxa-dragon-q6a.dtb armbianEnv.txt rootfstype=ext4 user_overlays=qcs6490-radxa-dragon-q6a-cam1-radxa-camera-4k overlay_prefix=qcs6490 overlays=radxa-dragon-q6a-cam1-radxa-camera-4k fdtfile=qcom/qcs6490-radxa-dragon-q6a.dtb usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I used the overlays that I build with radxa overlays both use 6.18.2-current-qcs6490

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?

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.

Hey OP, the Loader.zip link is dead. Mind resharing it? Can't proceed without it. Thanks!Hey OP, the Loader.zip link is dead. Mind resharing it? Can't proceed without it. Thanks!

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

my rock64 sometimes hangs with unknow reason. Enabling/testing watchdog did not help. Does hardware watchdog is working at all ? some outputs: # dmesg | grep -i watchd [ 0.838922] dw_wdt ff1a0000.watchdog: No valid TOPs array specified [ 0.928770] rk_gmac-dwmac ff540000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 3.920201] systemd[1]: Using hardware watchdog 'Synopsys DesignWare Watchdog', version 0, device /dev/watchdog0 [ 3.921218] systemd[1]: Watchdog running with a hardware timeout of 28s. # wdctl Device: /dev/watchdog0 Identity: Synopsys DesignWare Watchdog [version 0] Timeout: 28 seconds Timeleft: 18 seconds Pre-timeout: 0 seconds After doing kernel panic via echo c > /proc/sysrq-trigger device not rebooting. On raspberry pi that test is working fine.

Bedna I know that su command is a compiled binary but Orange Pi PC has a 32 bit ARM processor and not a 64 bit Intel (x86_64) processor. I find that extremely hard and impossible to believe that you missed the point.

Yes, applications are compiled into binaries, su is not a script. This is on for example Arch: $ file $(which su) /usr/bin/su: setuid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=d47af40eeb87fea42d555df0d1385bc9a4b4df2c, for GNU/Linux 4.4.0, stripped Ok? So it's compiled with rust instead of C, still a binary. I find that extremely hard impossible to believe. https://www.reddit.com/r/learnprogramming/comments/lyw9gf/can_someone_explain_what_people_mean_by_binaries

i am running a H96(model RK3318) android tv box, its old, i have lost itss remote as well. basically noow i am tryinh to install ambrain os on it, but the conditon now is , even the android id now visible on the tv/monitor, basically when i insert the power cable on the display "boot" is showing with blue light. after few sec, some number like "07:01" is showing, but when i connect my htmi cable, the tv is detecting the htmi. but its showing no signal. basically there is no output on the display. i have tried many methods, there is no problem in htmi, or tv or cable. the andoird itself not booting. and the sd card method for ambrain also not working . tried the toothpick method and everything. but still its nott working!. i dont know why there is no output on the display. i dont know whhat issue. usb, htmi, everything is working. even charger also working.

@WallaceWebs Fabulous, this is a milestone fix.

I have been able to download it from the first page, are you sure?

Hey @Kevin su , could you check my PR? I fixed the throughput issue. Download: 47.34 Mbps (data used: 46.4 MB) 331.60 ms (jitter: 73.01 ms, low: 12.78 ms, high: 769.94 ms) Upload: 44.14 Mbps (data used: 41.1 MB) 82.16 ms (jitter: 15.48 ms, low: 17.63 ms, high: 269.25 ms) Packet Loss: 0.0% Using a generic SBC with SSV6256P (MXQ Pro 4K 5G). Repo with the fix: https://github.com/WallaceWebsBR/armbian_sv6256p/tree/fix-ht-tx-ampdu

i used grub at the end of the day and booted from nvme.

I just discovered that /usr/bin/su in my Armbian: v26.2.1 for Orange Pi PC running Armbian Linux 6.12.58-current-sunxi is a x86_64 binary: $ ls -l /usr/bin/su -rwsr-xr-x 1 root root 50800 Mar 6 13:10 /usr/bin/su $ file /usr/bin/su /usr/bin/su: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header I installed the rust version, su-rs, but I thought it would be useful to warn about this. I checked /usr/bin and /usr/sbin and this is the only x86-64 executable.

If Windows can see the share but has trouble connecting, it's also worth checking the SMB version being used on both sides. I've run into cases where enabling the correct SMB protocol or recreating the saved Windows credentials fixed the issue right away.

I tried 0.6, wifi not working, i own one with EA6521. I made it work on 0.5 changing the .dts a little bit (thanks to Claude) Quote: cat /proc/device-tree/seekwcn_boot/gpio_chip_en 2>/dev/null | od -An -tu4 603979776 285212672 0 # Fix seekwcn_boot GPIOs sed -i 's/gpio_host_wake = <0x24 0x06 0x01>/gpio_host_wake = <0x24 0x12 0x00>/' /tmp/x88pro.dts sed -i 's/gpio_chip_wake = <0x24 0x10 0x00>/gpio_chip_wake = <0x24 0x11 0x00>/' /tmp/x88pro.dts sed -i 's/gpio_chip_en = <0x24 0x11 0x00>/gpio_chip_en = <0x24 0x06 0x00>/' /tmp/x88pro.dts # Fix sdio-pwrseq reset-gpios sed -i 's/post-power-on-delay-ms = <0x8c>/reset-gpios = <0x24 0x06 0x01>;\n\t\tpost-power-on-delay-ms = <0x8c>/' /tmp/x88pro.dts # Disable wireless-bluetooth and wireless-wlan nodes sed -i '0,/status = "okay"/{/wireless-bluetooth/{n;n;n;n;n;n;n;n;n;s/status = "okay"/status = "disabled"/}}' /tmp/x88pro.dts # Verify seekwcn_boot node grep -A 12 'seekwcn_boot {' /tmp/x88pro.dts cp /boot/dtb/rockchip/rk3528-x88pro.dtb /boot/dtb/rockchip/rk3528-x88pro.dtb.bak dtc -I dts -O dtb /tmp/x88pro.dts -o /boot/dtb/rockchip/rk3528-x88pro.dtb 2>/dev/null # 3. Fix module loading mv /etc/modules-load.d/aic8800-btlpm.conf /etc/modules-load.d/aic8800-btlpm.conf.disabled echo "blacklist aic8800_bsp" > /etc/modprobe.d/blacklist-aic.conf echo "blacklist aic8800_btlpm" >> /etc/modprobe.d/blacklist-aic.conf echo "blacklist aic8800_btlpm_sdio" >> /etc/modprobe.d/blacklist-aic.conf echo "extraargs=modprobe.blacklist=aic8800_bsp,aic8800_btlpm,aic8800_btlpm_sdio" >> /boot/armbianEnv.txt # 4. Build skw modules dkms add -m ea6621q -v 1.0 2>/dev/null || true dkms build -m ea6621q -v 1.0 dkms install -m ea6621q -v 1.0 # 5. Set module load order cat > /etc/modules-load.d/skw.conf << 'EOF' skw_bootcoms skw_sdio skw skwbt EOF Right now i cannot try it, if someone else wants to try this... EDIT: the if in the wifi section of the provisioning doesn't detect correctly, the searched directory doesn't exists so it won't install the module