All Activity

@XFer012 Here's a patch of the changes @stary presporak made to the decompiled DTB. Trying to create a patch using the original DTS but I don't have much free time right now. changes.patch

@Julio Cesar Goldner Vendramini Are you planning on submitting this to Armbian as a PR so it gets included?

Next week we'll be in Long Beach, California for AWE USA 2026. Catch our talk exploring OpenXR, from its practical foundation for cross-platform XR interoperability, to its extension support across devices, and more! View the full article

@jshkol I think the best way to support both the Orange Pi and Radxa A733 is to use the Orange Pi repository as the base. Radxa uses containers to build U-Boot and the kernel, which makes the Armbian scripts complicated and messy. Dok2b was able to build a Debian image for Cubie using Orange Pi's sources. https://github.com/dok2d/cubie-a7z-debian/tree/master/scripts

@alexc This happens on their kernel too, I created a topic on their forum (https://forum.radxa.com/t/hailo8-pcie-fw-control-timeout-on-cubie-a7a-with-asmedia-pcie-switch/31023), I suspect that the problem is on the Allwinner side and a patch is needed not even from Radxa but from Allwinner. But yesterday I was looking at their forum and there are quite a lot of complaints about the PCIe line, but this remains unanswered, I suspect that they think this is a feature and not a bug. If you need any other help or further study of the problem, I am ready to help in any way I can.

moved to tvboxes

edit: nope it looks like that the server was blacklisted somewhere in my adblocker blacklist.

@Ovaday First of all, thank you for the initiative. This repository contains the files that will be used as example to enable your board in Armbian: https://github.com/hqnicolas/ArmBoardBringUp The example file you're referring to is this one: https://github.com/hqnicolas/ArmBoardBringUp/blob/main/config/boards/h96-tvbox-3566.tvb The boot settings you should use may vary considerably from this reference, but your device will need a configured bootloader. https://github.com/hqnicolas/ArmBoardBringUp/tree/main/patch/u-boot/v2026.04/board_h96-tvbox-3566 You will need to focus on the new kernels like: https://github.com/hqnicolas/ArmBoardBringUp/tree/main/patch/kernel/archive/rockchip64-7.1/dt The repository you need to interact with to include these files is this one: https://github.com/armbian/build You need to validate everything before publishing, so do some hard work using this compiler: https://docs.armbian.com/Developer-Guide_Overview/

I again apologize, even though I can not see what was "hostile" in what I wrote. I simply misunderstood and apologized for that, even though I think you are the passive aggressive one here. I am so sorry. (I will add you to ignore list so I will never accidentally interact with you again, so no need to leave the community if it is due to me)

Hi everyone! 👋 I managed to get Armbian running on a generic RK3518 TV box — mainline U-Boot, onboard Ethernet, and AIC8800D80 SDIO Wi-Fi all working. I couldn't find a single RK3518 thread here when I started, so I wrote everything up to help the community. Full step-by-step guide, device tree, and the loader binaries I built are in my GitHub repo: 👉https://github.com/juliovendramini/rk3518_armbian Happy to answer questions. Hope it helps someone! 🙂

Created a Pull Request: https://github.com/armbian/linux-rockchip/pull/500 Final DTB: rk3566-box-X88PRO20-npu.dtb @Hqnicolas do you know how I can add the board as selectable from the Armbian website? Do I have to also add DTS that will work for latest kernel?

@stary presporak your attached DTS is no longer available. Can I find it somewhere? Or is it merged within @alexc work already? Thanks!

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 all- I also noticed this board as having favorable price-to-performance and *importantly* availability of inventory in the US. As a result I too wanted to be able to run Armbian on it. I've managed to get an Armbian build working using the vendor (xunlong/Orange Pi) supplied kernel source and bootloader. I was able to successfully compile and run Bookworm and Trixie including installation to an installed NVMe SSD drive. I also used some of the work by @Nick A in https://github.com/NickAlilovic/build/tree/Radxa-mainline-WIP as a basis. I tried to keep everything Orange Pi specific out of the "sun60iw2.conf" family file and put it in the board.csc with hope that the family file can be shared by both Radxa and OPi A733 based boards in the future. https://github.com/armbian/build/pull/9967 Notably missing is support for the GPU or hardware acceleration. Video output still works but it is not taking advantage of the video capabilities of the A733 chip so graphics performance is very limited. Full disclosure: my main use case is for a headless server.

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.