All Activity

After a few days of testing I have to say it works great. No issue whatsoever. Stable, usb, eth, wifi, bt works. Great work!

I have a few of those and when connected to RPi5 PSU and set to 12V, it can power my Rock5B with NVME SSD and some other peripherals as well.

I tested the new driver in my box (the router and box are in two different rooms). As you can see, just as @WallaceWebs mentioned, the upload speed has improved significantly. Before merging this pull request, the speed was 8.25Mbps, and now it is 33.46Mbps. Idle Latency: 11.17 ms (jitter: 1.63ms, low: 10.02ms, high: 12.42ms) Download: 38.57 Mbps (data used: 22.8 MB) 97.38 ms (jitter: 31.45ms, low: 16.86ms, high: 432.50ms) Upload: 33.46 Mbps (data used: 54.8 MB) 127.94 ms (jitter: 41.37ms, low: 28.14ms, high: 628.78ms) Packet Loss: 0.0%

> As I mentoined earlier, I use fixed 12V for ROCK5B, else no success. For NanoPi-R6C it works with 5V 3A (27W RPI5 PSU). I ordered a USB-PD trigger board that does the negotiation before the board and output a constant voltage, I will see how it goes

Hi @Sand_Death, Thanks a lot for identifying this! Could you please check if this also happens on the kernel provided by Radxa? If it works on their side, it's likely something we need to address in our configuration. Since PCIe is still handled by the vendor's BSP, if it's a bug on their end, it would be best to open an issue with Radxa first. I'm happy to take a closer look once I have some time later.

The (standard) Armbian images for Rock5b use boot.scr, not efi/boot/bootaa64.efi from an extra FAT/ESP partition. So no surprise. If you use the EDK2 UEFIv1.1 in the SPI-flash, you should use a generic UEFI ARM64 image. 1 such is Armbian for UEFI ARM64, look at the download options. I don't know, but make sure it is one with latest mainline kernel 7.0.x. What I have used is a Debian Sid nocloud image just as a quick test (testing that image on a NanoPi-R6C, should also work on Rock5b, not the UEFI/bootloader behavior. See https://cloud.debian.org/images/cloud/sid/daily/latest/debian-sid-nocloud-arm64-daily.tar.xz As I mentoined earlier, I use fixed 12V for ROCK5B, else no success. For NanoPi-R6C it works with 5V 3A (27W RPI5 PSU).

Hi everyone, sorry for the delay @meco> My recommendation would be to flash the u-boot spi bin inside the u-boot deb generated by armbian build I tried using a u-boot I compiled via the Armbian build system. With this I'm able to go a little bit further, U-boot start try to load Linux and then nothing. I had once 4 lines of print from Linux but nothing more and it's not reproducible. With this setup it looks a lot like my Nixos build with Linux starting and stopping after a few logs lines. I tried with Armbian on a SD card and on a USB stick same behavior @Michael Fischer > i was able to boot using UEFI spi by flashing https://github.com/edk2-porting/edk2-rk3588/releases the rock5b image I tried that. When flashing the Armbian image on the SD card it booted via UBoot at got stuck at the same place than in the first post. I think it's because the rom code tries sd card first for the next stage bootloader. So I flashed the image on a USB stick but it didn't boot, I entered the bios via uart, selected the usb key in the "Boot manager menu" and pressed Enter but I kept going back to the BIOS. I'm not sure that Armbian images are UEFI compatible anyway. I'm starting to wonder if my board is just broken... But at the same time I have an SD card with Android that works perfectly fine

@8lall0 Thank you very much for helpfull comittment. I put the changes into the Repro. New Release 0.7

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