All Activity

Thanks @laibsch, I took a look at the build framework, bvut couldn't see how to use/build a specific kernel version. I need to experiment with kernels 6.2 - 6.5

Steam games are working now, I tested some games a week ago. But the steam client alone took ~5gb. So, I would not recomend unless you have a 16gb board.

I am using hangover-10.18, which is Fex-Emu 2510. https://github.com/AndreRH/hangover/releases/tag/hangover-10.18 I didn't benchmark. But I think rn, the main bottleneck is the GPU (PanVk driver is now only ~60% performance of the libMali driver).

Another video you'd like to see.

So, would I replace that line with ${PWD:<my_password>}?

Yes I have been upgrading for several years. I really appreciate the effort you've gone to to send me these commands, but would the best solution be to start again with a fresh install? It would be a lot of work on my part, but if it will give the best outcome?

I tried FEX-emu, but on our devices it's slower. It is optimised for snapdragon while box64 is more optimised for the lower-end SBC ARM-SOC. Here a video I once made about it. Things have changed a lot, fex-emu has matured at lot in this time. I didn't know it was build for steam back then so didn't test that. Also have no steam games that would run.

Have you guys ever try FEX-emu instead of box64? I heard FEX is 10%~20% faster than box64

Hi @wolf7250, You can download the package without installing as follows: cd /tmp/ mkdir fliepeltje cd /tmp/fliepeltje/ apt-get download armbian-bsp-cli-helios4-current dpkg -x armbian-bsp-cli-helios4_*.deb ${PWD:?} Then backup the current bootscript as follows: cd /boot/ sudo cp boot.cmd boot.cmd~org sudo cp boot.scr boot.scr~org Then copy the new bootscript and convert it to U-Boot script format as follows: cd /boot/ sudo cp /tmp/fliepeltje/usr/share/armbian/boot.cmd ${PWD:?} sudo mkimage -C none -A arm -T script -d boot.cmd boot.scr Then reboot to check if all went well. Gr, PS syntax is on purpose, of course you can replace ${PWD:?} with . but that might be easy to miss when reading the instruction.

Hi, Seems you have upgraded for several years already? Perhaps something has changed over the years, meaning that the armbian-bsp-cli package did not get installed somehow. I am not sure what will happen if you DO install that package now, so the safest best would be to just get the bootscript from the package and convert it on your machine. Gr,

Here the link to the video. Thanks to Mike from Mekotronics. https://mekotronics.wetransfer.com/downloads/9a21fbbbd8123b75cb5119d632bb565020251208034519/a7c7d3?t_lsid=dd63b65e-c41d-4c4e-81ea-66eea92954d0&t_network=link&t_rid=YXV0aDB8NjE4ZTI0ZjkyMDYzZGYwMDY5Y2FhMmFh&t_s=download_link&t_ts=1765165519

ii armbian-config 26.2.0-trunk.48.1205.194441 all Armbian config: The Next Generation ii armbian-firmware 25.11.2 all Armbian - Linux firmware ii hostapd 3:2.10-6~armbian22.02.3+1 armhf IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator No LSB modules are available. Distributor ID: Debian Description: Armbian 25.11.2 bookworm Release: 12 Codename: bookworm # PLEASE DO NOT EDIT THIS FILE BOARD=helios4 BOARD_NAME="Helios4" BOARDFAMILY=mvebu BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=2efd215a DISTRIBUTION_CODENAME=buster DISTRIBUTION_STATUS=supported VERSION=20.05.2 LINUXFAMILY=mvebu BRANCH=current ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=Image Seems odd to me that this file thinks I'm still on buster with Armbian at version 20.05.2 😕 Yes. Definitely

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.