All Activity

Hi there, How about the output of dpkg --list | grep 'armbian' lsb_release -a cat /etc/armbian-release ? Just to be sure, you are using armbian right? Gr,

That command doesn't output anything....

Hi, Hmm that looks like the "old" bootscript still. Odd. Can you share the output of dpkg --list | grep 'bsp-cli' ?

Sure! # DO NOT EDIT THIS FILE # # Please edit /boot/armbianEnv.txt to set supported parameters # setenv load_addr "0x300000" # default values setenv rootdev "/dev/mmcblk0p1" setenv rootfstype "ext4" setenv verbosity "1" setenv emmc_fix "off" setenv spi_workaround "off" setenv ethaddr "00:50:43:84:fb:2f" setenv eth1addr "00:50:43:25:fb:84" setenv eth2addr "00:50:43:84:25:2f" setenv eth3addr "00:50:43:0d:19:18" echo "Boot script loaded from ${devtype}" if load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt; then env import -t ${load_addr} ${filesize} fi setenv bootargs "console=ttyS0,115200 root=${rootdev} rootwait rootfstype=${rootfstype} ubootdev=${devtype} scandelay loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}" load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}zImage fdt addr ${fdt_addr_r} fdt resize 65536 for overlay_file in ${overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-${overlay_file}.dtbo; then echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done if test "${overlay_error}" = "true"; then echo "Error applying DT overlays, restoring original DT" load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} else if test -e ${devtype} ${devnum} ${prefix}dtb/overlay/${overlay_prefix}-fixup.scr; then load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-fixup.scr echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" source ${load_addr} fi if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr echo "Applying user provided fixup script (fixup.scr)" source ${load_addr} fi fi # eMMC fix if test "${emmc_fix}" = "on"; then echo "Applying eMMC compatibility fix to the DT" fdt rm /soc/internal-regs/sdhci@d8000/ cd-gpios fdt set /soc/internal-regs/sdhci@d8000/ non-removable fi # SPI - SATA workaround if test "${spi_workaround}" = "on"; then echo "Applying SPI workaround to the DT" fdt addr ${fdt_addr} fdt resize fdt set /soc/internal-regs/sata@e0000 status "disabled" fdt set /soc/internal-regs/sata@a8000 status "disabled" fdt set /soc/spi@10680 status "okay" fdt set /soc/spi@10680/spi-flash@0 status "okay" fi bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Hi there, U-Boot was updated. Can you share the contents of `/boot/boot.cmd`? Just to be sure 🙂 Groetjes,

Thanks @djurny, does this output indicate that the U-Boot was updated and the new bootscript is doing it's job? Booting from MMC U-Boot SPL 2025.10_armbian-2025.10-Se50b-P915a-H9530-V9a59-Bbf55-R448a (Nov 24 2025 - 08:37:53 +0000) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from MMC1 U-Boot 2025.10_armbian-2025.10-Se50b-P915a-H9530-V9a59-Bbf55-R448a (Nov 24 2025 - 08:37:53 +0000) SoC: MV88F6828-B0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) Core: 33 devices, 22 uclasses, devicetree: separate MMC: mv_sdh: 0 Loading Environment from MMC... Reading from MMC(0)... *** Warning - bad CRC, using default environment Model: Helios4 Board: Helios4 Net: Warning: ethernet@70000 (eth1) using random MAC address - 4a:c2:c1:92:17:69 eth1: ethernet@70000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2967 bytes read in 15 ms (192.4 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 275 bytes read in 12 ms (21.5 KiB/s) 28834 bytes read in 34 ms (828.1 KiB/s) 14341219 bytes read in 1365 ms (10 MiB/s) 8678912 bytes read in 819 ms (10.1 MiB/s) Working FDT set to 2040000 Kernel image @ 0x2080000 [ 0x000000 - 0x846e00 ] ## Loading init Ramdisk from Legacy Image at 03000000 ... Image Name: uInitrd Created: 2025-12-08 1:59:54 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 14341155 Bytes = 13.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Working FDT set to 2040000 Loading Ramdisk to 0f252000, end 0ffff423 ... OK Loading Device Tree to 0f1e2000, end 0f251fff ... OK Working FDT set to f1e2000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 252.39-1~deb12u1 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.38.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: clean, 66751/1782272 files, 757075/7712800 blocks done. done. Begin: Running /scripts/local-bottom ... /scripts/local-bottom/mdadm: 2: /scripts/local-bottom/mdadm: rm: not found done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian 25.11.2 bookworm!

Hi @wolf7250, If you have doubts or concerns, you can leave the workaround in `armbianEnv.txt` and check the serial console output to verify that U-Boot was updated and the new bootscript is doing it's job. After verfication, you can remove the workaround (fixed load addresses) from `armbianEnv.txt`. The new bootscript will try to calculate the load addresses and if it cannot do that (due to missing U-Boot command) it will default back to the fixed load addresses - which you will have overruled with the ones in `armbianEnv.txt`. Gr,

@djurny and @FredK, thank you so much. I am now updated and on Armbian 25.11.2! @djurny I used the quick workaround from here and then performed a full upgrade. I have now run nand-sata-install. Is there a way to ensure that that has run successfully? Also do I now remove the quick workaround from the /boot/armbianEnv.txt? @FredK I did need to run the commands that you provided the link to as I was getting the same public key error. Thank you so much to both of you!

@snowbody you are using an older version of the driver with the current version of the display-service. That won't work. Since you are on 6.12 kernel, start by cloning the main branch of https://github.com/jefflessard/tm16xx-display.git it already contains the line-display backport.

Maybe this will work https://xdaforums.com/t/how-to-use-otg-in-twrp.3097688/

I don't really do anything special. Since the architecture of the devices I use is quite up-to-date, development for their support is also at the bleeding edge. It is therefore also of essential importance to use the latest software releases. My chosen distribution provides me with this quite promptly. But that's where it ends. I receive no support at all for using my devices there. She doesn't even provide me with firmware for my devices to start the system. The kernel provided by my distribution is only the one based on the currently released mainline source code. So if I want to use functionalities whose development is still in progress, I have to build the kernel myself with the appropriate patches, which I do regularly (E.g., I'm just building one so I can play around with RGA3). I haven't done much work in user space for a long time, but recently I've been building the FFmpeg package myself again since the availability of RKVDEC2. v4l-request works out-of-the-box with the GStreamer framework, but for FFmpeg, it will probably take some time until support is available in a release version. OK, the kernel is done. Now I have to deal with another video device: lrwxrwxrwx 1 root root 12 Dec 7 22:44 platform-fdb50000.video-codec-video-index0 -> ../../video3 lrwxrwxrwx 1 root root 12 Dec 7 22:44 platform-fdb60000.rga-video-index0 -> ../../video2 lrwxrwxrwx 1 root root 12 Dec 7 22:44 platform-fdb80000.rga-video-index0 -> ../../video0 lrwxrwxrwx 1 root root 12 Dec 7 22:44 platform-fdba0000.video-codec-video-index0 -> ../../video4 lrwxrwxrwx 1 root root 12 Dec 7 22:44 platform-fdc38100.video-codec-video-index0 -> ../../video1 lrwxrwxrwx 1 root root 12 Dec 7 22:44 platform-fdc70000.video-codec-video-index0 -> ../../video5 v4l2-compliance-odroid-m2.log

@usual user I've got a good handle on your setup through random posts, but I haven't been able to figure out how you got there. Is there something Armbian available that I'm missing, or are you following the Fedora docs, or your own process? Hoping there's something published that I haven't yet found.

https://users.armbian.com/users.armbian.com/jock/web/rk3318/ It seems like old firmware is stored here.

Well I got it to display something, it isn't exactly what I want but I am just happy I got it to do something. I decided to try with the orangepi image from their website "Orangepizero3_1.0.2_ubuntu_jammy_desktop_xfce_linux6.1.31.img". I was going to share image from what it's displaying but for some reason I keep getting an error trying to upload. Basically it's showing the orangepi boot logo but then all messed up, it's all over the place. ------ edit got image to upload. ------

But if that were the case, simply leaving it powered off for a while and then turning it back on should fix it, but it doesn't. As I mentioned, I have to re-flash them from scratch with Android before I can reinstall Armbian. Additionally, the boards are completely exposed (out of the casing), with a heatsink on the SoC and proper ventilation. The power supply shouldn't be the issue either, as it is also fully ventilated.

posting output of : armbianmonitor -u Helps with support.

check you power supply and soc temps

Hello storz, I wonder if you ever managed to get this to work. I used to have this working, but not anymore, and I wonder if I can make it work again. I have an Anker A8312 USB-C to HDMI adapter (which, like all similar adapters, really does DisplayPort in Alt mode over USB-C, and from there converts to HDMI). I previously used this on my PBP with Armbian Focal, and it worked fine just so long as I ran GNOME on X.org, as opposed to Wayland. I was able to connect an external monitor via an HDMI cable, it showed up in the GNOME display settings, and I was able to use it as one would expect. I unfortunately have a hard time finding out the exact kernel version I used at the time, but I believe it was a 4.9 rockchip kernel. I recently reinstalled my PBP using Armbian Noble and apparently there's a kernel regression that causes the adapter to not be recognised anymore. On a 6.1 kernel (which is what shipped with Armbian Noble as it came out), the device is not recognised at all. On a 6.12 kernel (currently available via updates, at the time of writing), the device does show up in lsusb, but only as a "billboard device" which means that the device wasn't correctly switched into DP Alt mode and is thus unusable for connecting a screen. I am still on GNOME on X.org, I still use the same adapter, and I still connect to the same monitor with the same cable as before. So with all other variables being identical, I do strongly suspect this to be a kernel or perhaps a firmware issue. Perhaps you (or someone else) have any pointers that might help me move towards getting this working again. I'd be most grateful for those. Thanks! Cheers, Florian

While doing various tests, also other bootloader than EDK2-UEFI v1.1 that I had in eMMC, I discovered that with 2026.01-rc2_armbian-2026.01-rc2-S365a-Pa203-He3cc-V062a-Bbf55-R448a kernel 6.18.0-rc7-edge-rockchip64 did not find/enable audio via HDMI. I moved the computer to other room where I rely on the speakers in the monitor, else I would not have discovered it as I also use networked pulseaudio. What works is 2025.01-armbian-2025.01-S6d41-Pdb4b-H2194-V062a-Bb703-R448a, so sort of last-known-good, got that via: sudo apt install linux-u-boot-nanopi-r6c-current=25.8.1 and wrote the binary with dd to eMMC Another issue is that the monitor does get out of sleep too late, so the loglevel=7 effect can only be seen on extra serial console, whereas with the UEFI bootloader, the HDMI gets always initalized properly, so before kernel is loaded. Note that this is with booting via grub. So with EDK2-UEFI v1.1 bootloader, I get a normal Debian graphical kernel selection menu, like on x86-64. With Opensuse Tumbleweed it is slightly different, as that also automatically duplicates on serial console (if 't' is pressed , from 'text'). So this is actually quite ideal. The only disadvantage is that it does not want to store boot entries (but works on ROCK5B in SPI-flash). I probably need an own build on SD-card first to see how 2026.01 (or later) can do the same as EDK2-UEFI v1.1 more or less. I should note that with EDK2-UEFI v1.1 bootloader, I do not load the DTB that comes with the kernel version. I used the setting 'vendor' or 'mainline' in the UEFI settings, that gets stored well actually. Now with the 25.8.1 U-Boot, I manually added a devitree loader line in grub.cfg, but that will be overwritten, so need to see what makes sense.

Device: A95X F1 TV Box SoC: Amlogic S905W OS: Armbian Linux Server (v6.12 and v6.18) & Desktop versions. Installation: To NAND/eMMC. The Issue: I am deploying about 10 units. The installation to NAND goes smoothly, and the system boots correctly. However, after running perfectly for a few hours, the devices crash: Video output goes to a black screen. Network is dead (No SSH, No PING). Power cycling the device does not recover the system; it remains in this "bricked" state. Recovery Method: Once the device crashes, I cannot simply reinstall Armbian. I am forced to: Flash the stock Android firmware using the USB Burning Tool. Reinstall Armbian from scratch. Troubleshooting done: Tested on multiple units (10 different boxes). Tested over a period of one month with various incremental updates. Tested both Server and Desktop images. Result remains the same: corruption/crash after a few hours of uptime. ¿Some help?

@Nick Aforgot to add, it has allwinner h313, also how do you backup or dump stock? I need it so I will be able to return if something won't work. Also thanks for help.

From https://github.com/armbian/build/pull/5056#issuecomment-1529793978

I fixed my i2c gpio ldo regulator issue by disabling the axp_gpio in the device tree. &axp_gpio { status = "disabled"; }; The separate driver must have been rewriting the registers configured by the regulators driver. Now back to the LCD

display-service -c [INFO] all digits and leds on /usr/sbin/display-service: 116: cannot create /sys/class/leds/display/message: Permission denied == could it be the the tm16xx module does not create "message", I have seen (Hqnicolas) succes, but guess the "message" got created compiling tm16xx and(!) patching with https://lwn.net/Articles/1027664/ . did not solve this (got errors). Maybe related to kernel version? : 6.12.58-current-rockchip64.

More info, but not yet the video that shows what pins.