Active threads

I've a similar issue but on a different board nanopi m4v2. Could you also help me in troubleshooting the problem? In addition to video problems at 4K I'm getting also Bluetooth problems with my keyboard. Feel free to ask for extra info.

@Sergey LepeshkinThank you, is there anyway to get it out and reveal the cpu (may fake, but worth trying) Also, i don't even know why they put a fake update screen on a fake tv box but i found a guy with same problem on me : I don't know what to do, my box does have the usb debugging and i will try to debug it

Etcher used to be / is broken. https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card https://docs.armbian.com/User-Guide_Troubleshooting/

There are those of us that spend months working on these things. There is nothing about this that is easy. It is a hobby to waste a lot of time on. If you really wanted to proceed further you are really going to need to hook up to the debug serial port to get an ideal of the boot messages that are occuring. From an earlier post it looks like the serial connection points were identified and hooking up a USB serial adapter to them would give more information. But getting a random TV box working is usually a many month project as a lot needs to be learned about this while environment first.

Try to upgrade from 25.5.1 but base-files not present in repository. Missed again. @Igor can you fix it?

Regardless of which version I boot ("official" or home built with current) , the apt repositories are the same. And after I apt update && apt upgrade the "current" release, the "rolling" message disappears from the MOTD. I understand that I should not care of these MOTD messages, the meaning is not what I thought it was.

Hi @Ed van den Enden, Looks like the on-chip RTC is used for initial time-setting by the kernel in your case. It also seems that the overlay to enable i2c is now loaded correctly! I can help with two options, you can choose which one you want to use: Option 1: Use the `rtc-sync` script with the cronjob and systemd modification. Option 2: Use the user-overlay that will move the I2C "external" RTC to the first slot, naming it `rtc0`. The on-chip RTC will move to the second slot, `rtc1`. Option 1 will need more modifications in your configuration, but will work nonetheless. You can find the script attached here: Put the rtc-sync script in /usr/local/sbin/. Change onwership/permissions: sudo chown root:staff /usr/local/sbin/rtc-sync sudo chmod 0775 /usr/local/sbin/rtc-sync Create the cronjob /etc/cron.d/rtc-sync as follows: #min hr mon day dow run-as command 30 * * * * root /usr/local/sbin/rtc-sync -Ad update Modify ntp service unit file by adding the following to the end of the file (/lib/systemd/system/ntpsec.service OR /lib/systemd/system/ntp.service depending on which ntp package you have installed): # Added to sync wallclock to an external RTC [Service] ExecStartPre=-/usr/local/sbin/rtc-sync -A -d start ExecStopPost=-/usr/local/sbin/rtc-sync -A -d stop Option 2 will require adding the user-overlay file and changing only your armbianEnv.txt. I can only give you the user-overlay i used that works for the orangepi zero, but as this uses the same CPU as your board, it should work. if it does not work, you will always have option 1 as fallback. You can find the user-overlay (rtc1-soc.dts) and the instruction on how to compile and add this to armbianEnv.txt in this topic here: The user-overlay is also included down here: In addition to the user-overlay, you will also need to disable the `fake-hwclock` service, as that tries to emulate a real RTC by reloading the last known wallclock from a file that was created when the system was shutdown/rebooted. Instructions for this also in the same linked topic. Pick your option and try it out. If it all works well, for option 2 you will find that the i2c RTC is named rtc0, for option 1 you will see i2c RTC is still rtc1, but the rtc-sync script, cronjob and systemd modification will use the i2c RTC to set the wallclock (after it's set improperly by rtc0). Feel free to check back in if it still does not work. Groetjes,

Maybe try another power adapter Or add to /boot/armbiEnv.txt extraargs=pcie_aspm=off nvme_core.default_ps_max_latency_us=0 pci=pcie_bus_safe Otherwise you could try an image of Radxa first, if that works then it might be an issue with the dtb

I have two of these cheap Chinese sticks and I was wondering if I could load a better OS onto them I think there's only a USB port

That's why I am here To ask for help I could not find any installable packages I am a novice user

Firstly can you actually connect to the repo without issues? I my case I was getting timeouts and i suspect it was being blocked by my ISP for whatever reason and to work around I to tether my SBC to mobile for internet via mobile data then install the packages this way. This is my current ffmpeg: ffmpeg -version ffmpeg version 5.1.4-0+deb12u1.v4l2request Copyright (c) 2000-2023 the FFmpeg de velopers built with gcc 12 (Debian 12.2.0-14) configuration: --prefix=/usr --extra-version=0+deb12u1.v4l2request --toolchain=h ardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gn ueabihf --arch=arm --enable-gpl --disable-stripping --enable-gnutls --enable-lad spa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable -libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgls lang --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enab le-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable- libpulse --enable-librabbitmq --enable-librist --enable-librubberband --enable-l ibshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt -- enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable -libv4l2 --enable-v4l2-request --enable-v4l2-m2m --enable-libvidstab --enable-li bvorbis --enable-libvpx --enable-libwebp --enable-libudev --enable-libx265 --ena ble-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi - -enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enabl e-sdl2 --disable-sndio --enable-libjxl --enable-pocketsphinx --enable-librsvg -- enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --ena ble-frei0r --enable-libx264 --enable-libplacebo --enable-librav1e --enable-share Admittedly not the most up to date as it has been a while since I last attempted. From what I can tell from the latest pages it looks like using drm* has now been replaced with v4l2request more recently. I doubt it would specifically related to the duo2 and more likely at the soc dtsi definitions level. Now I encountered many of the same problems you did earlier but the older A10/A20 VE is limited to physically access only the first 256mb of memory. The H3 does not have the same constraints. @robertoj You are using a more modern setup? what is your current reported ffmpeg version.

OK...I think it worked in OrangePi3 LTS 🙂 ...first, clean up the remnants: ................................................................. sudo apt purge v4l2loopback-dkms sudo apt autoremove ............................................................... armbian-config then I had to switch to a different kernel: edge:6.15.4-edge-sunxi64 ....then update the system: apt update / upgrade / reboot ! install from GitHub: v4l2loopback and then: cd ~/v4l2loopback .................................................................... VERSION=$(grep -oP 'PACKAGE_VERSION="\K[^"]+' dkms.conf) sudo cp -r . /usr/src/v4l2loopback-$VERSION sudo dkms add -m v4l2loopback -v $VERSION sudo dkms build -m v4l2loopback -v $VERSION sudo dkms install -m v4l2loopback -v $VERSION dkms status sudo modprobe v4l2loopback ls /dev/video* ................................................................... I guess it's OK now: ................................................................ but in my opinion the module is not working properly 😞

It doesn't seem to make a difference:

None of the images are no longer working for me, no matter which recent image I take, the A5E board just remains stuck with a solid blue light (with some green light flickering). I even tried compiling armbian myself, but that also didn't work. The only image working for me is the 25.02 version from earlier this year. I am using the Radxa A5E v1.2 version with 4gb ram. I also mounted the SD card to a linux machine and looked into /var/log for a boot file or reading the journal but I don't see any logs written. Have somebody stumbled unto a solution or does somebody have advice me how I can get the logs to find the culprit?

I can see that after multiples update that the situation for the video acceleration seems to be better in full HD not in 4K, could you help me to understand how? In addition I'd like to add that I'm still getting problems with my Bluetooth keyboard and touch-pad being laggy especially when there is Ethernet traffic ongoing, i don't know if the bus of the Ethernet, the WiFi and Bluetooth card is shared in this SBC. Could you explain me how can i monitor this problem ? to conclude this morning I got a new packages issue, I runned the command "sudo armbianmonitor -u" and i pubblished the results to: https://paste.armbian.com/geyahoxavi

Meanwhile, I upgraded the old rebooting (working) orangepi zero(1)s from U-boot "SPL 2019.04-armbian (Nov 18 2019 - 23:36:05 +0100)" to U-boot "SPL 2024.01-armbian-2024.01-S866c-P6b16-Ha5c2-V367a-Bb703-R448a (Apr 29 2025 - 02:50:09 +0000)" and they also now poweroff on reboot. So the problem is clearly u-boot, and not SD card vendor, kernel (they all run the same "6.12.43-current-sunxi #1 SMP Wed Aug 20 16:30:58 UTC 2025 armv7l") or whatever else. I'll see if I can manage to test U-boot v2025.07... Btw, one thing I noticed with old working boot.cmd/scr was that load_addr was "0x44000000" while it is now "0x45000000" - no idea what significance may have.

One issue with Debian Trixie and encrypted root file systems is that they made some changes. There's an additional package you now need (in addition to cryptsetup-initramfs) prior to updating your initramfs so it will mount an encrypted root: systemd-cryptsetup Despite what this says, I had to install it manually. https://www.debian.org/releases/trixie/release-notes/issues.en.html#encrypted-filesystems-need-systemd-cryptsetup-package

Ah yes indeed. I meant laibsch. Sorry. I made an autoRevert.sh POC that hooks into the initramfs system. Assuming the partition layout described above the following script will revert to the other partition. It is assumed that if an update happened the updater will place a testBoot1 file inside the new boot directory and reboots. During initrd time the script will check for that file and rename it to testBoot2. If the script already detects a testBoot2 it will change the symlink of /boot to the other partition and reboots. Otherwise it is assumed that once the system is up testBoot2 is deleted from the running system if everything works. The script needs to be placed into /etc/initramfs-tools/scripts/init-premount/ and busybox needs to be installed as the script needs the more sophisticated basic commands. Then rebuild initrd. #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" if ! dpkg -s busybox>/dev/null 2>&1; then >&2 echo "Busybox not installed." exit 1 fi } case $1 in prereqs) prereqs exit 0 ;; esac reboot=0 echo mkdir /run/bootRevert mount /dev/mmcblk0p1 /run/bootRevert if [ -L "/run/bootRevert/boot" ]; then echo "/boot is a symlink. OK." cd /run/bootRevert currentTarget=$(readlink "boot") if [ -f "boot/testBoot2" ]; then echo -n "Reverting " if [ $currentTarget = "bootA" ]; then echo "to bootB." if [ -f "bootB/armbianEnv.txt" ]; then rm boot/testBoot2 ln -snf bootB boot reboot=1 else echo "Aborting revert. bootB seems to be empty." fi fi if [ $currentTarget = "bootB" ]; then echo "to bootA." if [ -f "bootA/armbianEnv.txt" ]; then rm boot/testBoot2 ln -snf bootA boot reboot=1 else echo "Aborting revert. bootA seems to be empty." fi fi else if [ -f "boot/testBoot1" ]; then echo "Going to testboot stage 2." mv boot/testBoot1 boot/testBoot2 else echo "No revert/testboot detected. Booting $currentTarget normally." fi fi fi cd / umount /run/bootRevert if [ $reboot = "1" ]; then sync echo "Rebooting..." reboot -f fi It seems then this concept works. As the script checks if /boot in the boot partition is a symlink and then does nothing if not it can also be placed in an unchanged armbian system without interfering. Perfect for creating new images. Still missing are the management scripts for: - converting an initially downloaded armbian image into an AB boot partition scheme - creating an image/update package from a running and well prepared or updated local armbian installation - a cronable management script to call a more specific download script and for switching partitions and rebooting - the download script that will attach to any distribution system that downloads the new update package places it into the other partition and adjusts machine identity; this download script could also just implement a backup of the running partition to the other partition so that switching back is possible if OTA is done using apt All of these can be done in shell.

Board say Orange Pi 5 V1.2

Hi , I am unable to boot my RK3568 board and cannot get it into MaskROM mode for recovery. The boot process fails with a "Synchronous Abort" in U-Boot SPL during DDR initialization. The device gets stuck in a boot loop. It starts DDR training (`ddrconfig:0`) but fails with a Data Abort exception. Standard methods to enter MaskROM /Loader have not worked. I have attached the full serial log (Boot_log.txt). Any guidance would be greatly appreciated. Thank you. Boot_log.txt

@fabiobassa Not work, I did wrongly or something. The rk322x image didn't have this ap6330 dtb overlay, so I pull it from another armbian image

Are u kidding me? This is freaking awesome Thanks guys, I will be patiently waiting..

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Finally there is a proper tor-browser available for arm64/aarch64: 1. Goto https://nightlies.tbb.torproject.org/nightly-builds/tor-browser-builds/ 2. Navigate into: tbb-nightly.<date>/nightly-linux-aarch64/ 3. Download tor-browser-linux-aarch64-tbb-nightly.<date>.tar.xz 4. Unpack with tar -Jxvf and run tor-browser/start-tor-browser.desktop Yay! (I'm sure you can compile it too from their github page)

Hey, has anyone tried using the BPI-3C1-27? Just wondering about price and if it’s really in stock.