All Activity

From @fevangelou 1. Install the "rkdeveloptool" tool first, as instructed in: https://docs.radxa.com/en/zero/zero3/low-level-dev/rkdeveloptool?host-os=debian sudo apt-get update sudo apt-get install -y libudev-dev libusb-1.0-0-dev dh-autoreconf pkg-config libusb-1.0 build-essential git wget git clone https://github.com/rockchip-linux/rkdeveloptool cd rkdeveloptool autoreconf -i ./configure make -j $(nproc) sudo cp rkdeveloptool /usr/local/sbin/ At the time of writing, this installed version 1.32. If you installed "rkdeveloptool" from Ubuntu's repos, it would install version 1.0 which may work, but let's be on the safe side here... 2. Connect and boot the device to loader/maskrom mode 2.1 While pressing the reset button (back/right) with a pin, connect the USB 2.0 port (back/left) and the power cable. Gotta be careful here not to miss the reset button pressing while connecting the cables. 2.2 Use the rkdeveloptool tool to identify the device and the mode it is on ("loader" or "maskrom"). $ rkdeveloptool ld ...should show the connected device if point 2.1 was successful - e.g. on my 8GB RAM device it printed this: DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=304 Loader Or after I had already flashed Armbian, it would show: DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=304 Maskrom (If you installed "rkdeveloptool" from Ubuntu's repo, the command is "rkdeveloptool list" if I recall correctly - every other "rkdeveloptool" command following though is the same) Now grab the latest release of Armbian for this device. At the time of writing it was: https://github.com/armbian/community/releases/download/25.11.0-trunk.106/Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img.xz (the name of the device is on the filename) Extract the included .img file with (sudo apt install xz-tools): $ unxz Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img.xz 2.2.1 If in "loader" mode (see the last part of the command's output above), simply flash Armbian directly. E.g. $ sudo rkdeveloptool wl 0x0 Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img (if you attempt to flash the attached bootloaders, you'll get a "device not supported" error - Armbian already contains a bootloader) 2.2.2 If in "maskrom" mode (e.g. if you are re-flashing Armbian), flash the bootloader first: # For the 8GB RAM device use the attached (in this post) H96-MAX-8gb-MiniLoaderAll.bin file $ sudo rkdeveloptool db H96-MAX-8gb-MiniLoaderAll.bin # For the 4GB RAM device use the attached (in this post) H96-MAX-4gb-MiniLoaderAll.bin file $ sudo rkdeveloptool db H96-MAX-4gb-MiniLoaderAll.bin ...and then re-flash Armbian as you did the first time: $ sudo rkdeveloptool wl 0x0 Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img 2.3 Reboot the device with: $ sudo rkdeveloptool rd Done! If all goes well, once you reboot the device you will be asked to set a root password and optionally a sudo user. Rebooting afterwards you should now be greeted with: _ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.11 rolling for h96-tvbox-3566 running Armbian Linux 6.12.44-current-rockchip64 Packages: Debian stable (bookworm), possible distro upgrade (trixie) Updates: Kernel upgrade enabled and 2 packages available for upgrade Support: for advanced users (rolling release) IPv4: (LAN) 192.168.1.10 (WAN) 1.2.3.4 Performance: Load: 3% Uptime: 2 min Memory usage: 2% of 7.50G CPU temp: 40°C Usage of /: 3% of 57G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop Last login: Sat Aug 30 12:47:54 2025 Key points: - If you do this the first time, it's obviously a matter of just flashing the latest Armbian image directly. - You don't need to open the device or compile Armbian.

Nice work, Armbian support for RK3318/RK3328 boxes makes these cheap devices so much more useful.

@djurny Sorry for the super late response. Here the answers on your questions: ls -Failh /dev/rtc* 457 lrwxrwxrwx 1 root root 4 Mar 7 01:56 /dev/rtc -> rtc0 107 crw------- 1 root root 253, 0 Mar 7 01:56 /dev/rtc0 542 crw------- 1 root root 253, 1 Mar 7 01:56 /dev/rtc1 ls -Failh /sys/class/rtc/ total 0 3926 drwxr-xr-x 2 root root 0 Jan 1 1970 ./ 10 drwxr-xr-x 63 root root 0 Jan 1 1970 ../ 8295 lrwxrwxrwx 1 root root 0 Jan 1 1970 rtc0 -> ../../devices/platform/soc/1f00000.rtc/rtc/rtc0/ 21463 lrwxrwxrwx 1 root root 0 Sep 3 23:18 rtc1 -> ../../devices/platform/soc/1c2ac00.i2c/i2c-0/0-0068/rtc/rtc1/ egrep -- . /sys/class/rtc/*/name /sys/class/rtc/rtc0/name:sun6i-rtc 1f00000.rtc /sys/class/rtc/rtc1/name:rtc-ds1307 0-0068 dmesg | egrep -i -- 'rtc' [ 1.042165] sun6i-rtc 1f00000.rtc: registered as rtc0 [ 1.042235] sun6i-rtc 1f00000.rtc: setting system clock to 1970-01-01T00:00:04 UTC (4) [ 1.774229] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes [ 1.776966] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes [ 19.347508] rtc-ds1307 0-0068: registered as rtc1 sudo hwclock --rtc=/dev/rtc0 # per default this is the H2+ built-in RTC 2025-09-03 23:32:07.935209+10:00 ==> date set to Australia (Tasmania) sudo hwclock --rtc=/dev/rtc1 # per default this is going to be the I2C RTC 2000-01-02 15:51:14.147878+11:00 ==> ?????????? So, I clearly don't understand the system. What do I want? Just the right time when connected to a wireless network. (If not available, my system switches to being an Access Point) If my system is acting as an Access Point, the date and time needs to be correct to, that's why I thought I need an RTC module. If not needed, how do I get the right time when my system operates as an Access Point. Thanks for helping

Hey there. Thanks for the detailed tutorial. I tried following it to install Armbian Trixie minimal on my Raspberry Pi 5's nVME (I'm on a headless setup with SSH access). The SD card that boots and runs the system so far is also an Armbian Trixie minimal installation. Apparently nobody has confirmed the instructions to work for that device / setup in this thread yet. So far I also have failed. After following through all steps my device wouldn't connect via ethernet (the LEDs didn't even blink). For simplifying things and rule out a source for possible mistakes, I then repeated the whole process without encrypting the drive, again without much success. Here's what I suspect to be the problem: The Armbian minimal image for the Raspberry family comes already with two partitions: a boot partition with a number of .dtb files for each device of the Raspberry family a "root" partition with all other files Device Boot Start End Sectors Size Id Type /dev/loop0p1 8192 532479 524288 256M b W95 FAT32 /dev/loop0p2 532480 3088383 2555904 1.2G 83 Linux I suspect it to boot in a different way than the image in the example, which seems to directily have all the files which I find in my second partition of the image. So, what I tried was to just create two partitions, mimicing the ones on the Image: Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 8192 532479 524288 256M b W95 FAT32 /dev/nvme0n1p2 532480 3907029167 3906496688 1.8T 83 Linux I would then just copy the contents of each partition respectively. But even that wouldn't boot the way it did with the SD card. Of course I could just use dd to copy the image to the 2TB nVME but that would take forever (20 h aprox.) and it wouldn't result in an encrypted system. My questions are: Is it even possible to use the way of copying boot files and contents in this tutorial to achieve a bootable nVME? If the image for the Raspi family relies on its own boot partition will I ever be able to use it for decrypting an encrypted drive before booting from it at all? Can I use it for both, booting the device and decrypting the drive, or would that be principally impossible? I'll be happy for any help for making it work or hint if the described procedure cannot work for my setup. Tonight I'll also join an install party and might have the opportunity to plug a screen to my Raspi and see if it gives hints during the boot sequence. EDIT: I think I understand now that this script is probably only for SD cards …

@Nick AHow to use your code repository(https://github.com/NickAlilovic/build) to add a 1.5GB RAM patch.

Here it is: https://paste.armbian.com/ququgojasu

Hi again, It took some time but finally I was able to take a look at it myself. It seems to me that the original kernel patch from @brentr is still a working solution as the affected kernel code didn't change in the current kernel. So by applying the original patch, 10mpbs Ethernet started working again on my Rockpi S. I'm not able I created PR #8575 - Fixes regression of failing 10Mbit built-in Ethernet in Rockpi S to add the patch again. I hope, that's ok as I'm lacking experience in this field so please apologize if I missed something, I just want to help and improve 🙂 Cheers,

Thank you all, I appreciate your patience! 🙏 I'm not sure on how deep I should go here. I started to learn about the process to address the problem that 10mpbs ethernet not is not working on my Rockpi S and I now know enough to deal with this problem. So my feeling is to not go further but focus on the functional problem to solve it 😉 Thanks again!

@SteeMani also did some commands prompted by chatgpt since it said it was manufactored by allwinner also related to cortex-a53, aida64 said it too, so i doubt that mine are using a allwinner h313 chip

@Nick Aalright, ill do it

Collabora is headed to Amsterdam. Meet us at Booth A63 in Hall 14 as we showcase GStreamer Analytics combined with ML, hardware-accelerated video decoding in Dante Studio using GStreamer, remote rendering for standalone XR, and more! View the full article

Context of the TV boxes section might be helpful, especially in the sticky thread re their status in Armbian.

Hi! @jwalds did yo mange to make hw decoding work with cedrus? (Note: you initially wrote cedar_ve, that's a different driver) I'm fighting with a nanopi duo2. If it works at your end I'd like to know your setup kernel version armbianEnv.txt whatelse has been installed, how could you please provide your dts / dto ? T.

Hi,any plans of porting Armbian to Ugoos AM9 s905x5 soc?

Hi again! Quick update after i wrote that below. I found something very promising here https://codesandbox.io/p/github/NathanJohnNJ/BananaPi-Camcorder/master This is a different approach. Behind the scenes the cedar_ve driver gets used which also supports encoding accel. I think I'll give it a try but that may take some time ... (btw. this is where some confusion exists, at several places - there are two drivers: cedrus aka. sunxi-cedrus and cedar_ve) -------------------------------------------------------------------------------- Im not using X11, i am using direct frambebuffer. But i'm quite sure the output is not the root cause as output to null also doesnt work So for testing there is no need for SPI LCD ffmpeg -hwaccel drm -i Big_Buck_Bunny_720_10s_10MB.mp4 -f null - @robertoj Maybe you can test this above and watch the framerate. if that achieves the 30fps run again with trace ffmpeg -v trace -hwaccel drm -i Big_Buck_Bunny_720_10s_10MB.mp4 -f null - and provide me the console output? also tested again mpv just with the input file and debug output (but this time not the specific v4l request thread) mpv Big_Buck_Bunny_720_10s_10MB.mp4 --msg-level=vd=v,vo=v,vo/gpu/vaapi-egl=trace ... ... [vd] No hardware decoding requested. [vd] Using software decoding. [vd] Detected 4 logical cores. [vd] Requesting 5 threads for decoding. [vd] Selected codec: h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10) [vd] DR failed - disabling. [vd] Using software decoding. [vd] Decoder format: 1280x720 yuv420p auto/auto/auto/auto/auto CL=mpeg2/4/h264 of course tested different parmeters but mpv always falls back to soft. mpv Big_Buck_Bunny_720_10s_10MB.mp4 --msg-level=vd=v,vo=v,vo/gpu/vaapi-egl=trace --no-config --hwdec=yes [vd] Trying hardware decoding via h264_v4l2m2m-v4l2m2m-copy. [vd] Using underlying hw-decoder 'h264_v4l2m2m' [ffmpeg/video] h264_v4l2m2m: Could not find a valid device [ffmpeg/video] h264_v4l2m2m: can't configure decoder Could not open codec.

That sounds very interesting. Where can I read more about this? @m11k I hope you are still active in this forum.

What's wrong with just using the curl command? It will upload the logs to one of our paste servers and it will be nicely formatted and colorful. Way easier to read.

You can also build from the release version, though I'm not sure it's fully that version for everything since the build process downloads updates from the internet. https://github.com/armbian/build/releases/tag/v25.8.1 At the top of that page, you can see how many commits have been added to main since the release of v25.8.1. You can download the source code at the bottom where it says Assets.

Share your displaying configuration by running "neofetch" and post it here. If your X11 is running on top of framebuffer, instead of DRM, it wont work. I also would like to get more debug from cedrus, linux's v4l2... but at least you can add -v to mpv to get more debug You only need the ffmpeg plugins offered by the original poster of the v4l2-request thread This is tested with mpv player only. v4l2-util and -ctl are only useful for webcams and video capture devices. v4l2loopback is not involved here. I don't have it I have an orange pi zero LTS, but I havent tested it there (I would use an SPI LCD, since it doesn't have an HDMI prot)

For debian problems, do what I do: Get the cheapest raspberry Recreate the problem Ask the question in the raspberry forum Apply solution to Armbian XD

Oh, sorry, I didn't notice the non-existent 6 and read it as Helios64. Of course, my description of the boot method is not limited to Rockchip devices; it works on all for which a mainline U-Boot is available. I have used it on iMX6, LX2160A and S922X devices, but my remaining devices are all based on Rockchip. The solutions are too varied to present a turnkey solution here. However, I am sure that only a corresponding configuration for implementation is required to achieve the desired behavior, but for that, the U-Boot documentation must be consulted to decide which solution should be chosen.

Thank you for your answer. My board is not Rockchip-based, we have been generalizing the discussion for quite a while now. Well, and this is where it would get interesting but ...

Since the RK3399 U-Boot can use an HDMI display and a USB keyboard, I would simply configure a jumpstart option in the boot flow that mounts a different root filesystem. When booting, you just have to select this option. If interacting with the firmware console is too complicated, the recovery system can be placed on a removable storage device. In this way, in case of need, only the rescue media needs to be connected and the system restarted; no firmware console access is required. A completely firmware-controlled fallback mechanism is also possible, but it requires further special configuration of the firmware. Read this thread to understand what I mean by my statement.

If tester is not available, I'd try powering failing ports with their respective cables but feeding them from pins powering other ports (eg with wires from some molex cable, just need to be careful with polarity and shortcuts) and then powering working ports from pins on the board feeding failing ports - to exclude failure of the power rail feeding these ports on the board. If cables are faulty, I'd check them for electrical connections and if they are ok, would replace capacitors.

What I like to do in such a case is link to archive.org. some spam got posted to this thread which I removed, so I felt like I might as well add an answer at the same time