Active threads

When I change the country and keyboard settings with armbian-config, the keyboard change from qwerty to azerty but after a reboot, the keyboard is qwerty again. The country code stay correct as set in the config.

Hi there, Ok, after some walking back and forth, typos, reboots, rewriting entire images, multiple armbianEnv.txt files, looking into U-Boot sources, googling (of course) I managed to find some things and got U-Boot on my Helios64 to boot properly again. In short, the aarch64 requirements to the linux kernel, the way U-Boot sometimes will move the loaded kernel image in memory might overwrite the starting point of the inital ramdisk. The load addresses for kernel and initial ramdisk are mostly hardcoded in U-Boot but can be overridden by armbianEnv.txt or the bootscript. As Helios64 uses Rockchip rk3399 from the aarch64 family, the attached boot.scr might also work for you. This bootscript will only work on aarch64 systems, as it assumes the kernel is uncompressed! If you test this, make sure to make a backup of your existing boot.scr or read up on how to regenerate the boot.scr from your boot.cmd. Make sure you have serial console available Copy the attached bootscript to /boot Add verbosity=1 (if not already there) to your armbianEnv.txt Reboot Would be great that if you test, to share the serial console output here to see it it also works for you. I will also test and verify on one of my Nanopi R2Ss somewhere today or tomorrow. Will put all the details into a pull request. Groetjes, boot.scr

I don't know your plans for how things are supposed to proceed. But if you plan to continue using my firmware build, I would suggest transferring it to the SPI flash, provided you are not wanted to use any other firmware in there. - This relieves you from having to pay attention to restoring my firmware build when changing an image. - You have two firmware versions available to you, between which you can switch with the SPI-MMC boot switch. - Even without the eMMC module, you can boot an OS from another connected storage device. - The U-Boot console is also available with an HDMI monitor and a USB keyboard and can be used for analysis in the event of startup problems. Of course, it is also used to select various boot options if autoboot is interrupted.

My NanoPC-T4 is still alive: For a quick test, I used my NVME with my latest OS, which usually powers a different SBC: Please do not let it bother you that the NanoPC-T4 uses an outdated kernel to run the OS. This is due to my negligence in building the current kernel without the necessary hacks needed for proper HDMI functionality. Some of the hacks have now been proper implemented in mainline, while others are still in flight. Until this process is completed, I have decided out of laziness to temporarily use an outdated kernel, as I do not miss any functionalities that a current kernel could provide me. My status LED is not blinking at boot at all. To debug boot problems, blinking LEDs are the worst possible option. Only proper console logs are of value. During OS runtime, it is configured as an HDD LED to indicate access to the microSD, as this is important information for when it is safe to remove it. I am still running my firmware from the microSD, again out of laziness to copy it to the eMMC. But any of nessesary support for the NanoPC-T4 is availabe and maybe some boring day or some spezial demand let me revisit to configure it properly. Until then, the bitrottining configuration is sufficient to serve more or less as an always-on terminal server for several USB serial adapters, which provide me with console access to my other SBCs if necessary.

What do you think....? still needs touch and cam.

I've spent a couple of days googling and "all the AI'ng" this and I just can't find anything that will get my Orange Pi 5 or Orange Pi 3 Zero Pin 3 or 5 to do anything at all. First, I'm running: v25.2.3 for Orange Pi 5 running Armbian Linux 6.1.99-vendor-rk35xx (similar for the zero) $ ls /dev/i2c* /dev/i2c-0 /dev/i2c-10 /dev/i2c-2 /dev/i2c-6 /dev/i2c-7 /dev/i2c-9 $GPIO readall SDA.5 | IN | 3 SCL.5 | IN | 5 (it says OFF on the zero) $sudo i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- I've tried.. \boot\ overlays=i2c2 I've also tried overlay .dts to turn off uart_a (shares the same pins) /dts-v1/; /plugin/; / { fragment@0 { target = <&i2c2>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&uart_A>; __overlay__ { status = "disabled"; }; }; }; No matter what I do the pins are all high, zero signal at all ever. What am I missing? Thanks!

Thank you so much. 🤗 Let's buy the board, then.

I'm using Bluetouch in my iPhone as a bluetooth mouse (rarely when needed) for my OrangePi/Armbian/Kodi setup. All fine with that… except… with my iPhone paired to the OrangePi, it also connects all its audio to the OrangePi, *all the time* when in range, unless I completely disable bluetooth from the iPhone. According to the only instructions I've found, I've tried setting [General] Enable= in `/etc/bluetooth/main.conf`, and restarting the bluetooth service, but the only effect this has is that there's no audible output. The phone still connects its audio to the box, just with no audible output. How to completely disable Armbian from advertising itself as a bluetooth audio device, while being able to connect bluetooth peripherals?

Hi! I'm new here too. I tested my webcam using webcammictest.io, and it worked fine, so the hardware seems okay. If you're encountering the "Inappropriate ioctl for device" error with v4l2-ctl, it might be due to driver compatibility issues or kernel differences. You could try using a different Armbian version, like Jammy, to see if that resolves the problem

Seems Ubuntu from Canonical uses a customized kernel where CPU usage precision is improved. But Debian and Armbian use previous CPU usage precision settings?

I could solve the instability problems and I am using the 2.5Gbit port now without having errors and with full speed! changing the swich Flow Control On for 2.5Gbit devices ethtool -K <LAN-device> sg off sudo ip link set dev <LAN device> mtu 9000 using the actual dtb file posted above cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/ update-initramfs -u nano /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand nano /etc/rc.local for cpufreqpolicy in 0 4 ; do echo 1 > policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat policy${cpufreqpolicy}/cpuinfo_transition_latency) > policy${cpufreqpolicy}/ondemand/sampling_rate done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 10 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done exit 0 nano /usr/local/bin/make_nas_processes_faster.sh #!/bin/sh -e for i in `pgrep "iperf3|smb"` ; do ionice -c1 -p $i ; taskset -c -p 4 $i; done # >/dev/null 2>&1 running as a service

Is there a way to copy the system from sda1 [M2-Sata SSD (2280)] to emmc (uboot) from the running system without losing the configuration? If it's possible, how can I do this including configuring the changes? What is the maximum size for the M2-Sata SSD (2280)? https://wiki.kobol.io/helios64/m2/

Hello, With kernel 6.6.56-current-rockchip64 the audio works correctly: cat /proc/asound/cards 0 [RK809 ]: simple-card - Analog RK809 Analog RK809 1 [HDMI ]: simple-card - HDMI HDMI With kernel 6.12.30-current-rockchip64 the RK809 card is not available: cat /proc/asound/cards 0 [HDMI ]: simple-card - HDMI HDMI How can this be solved ? Thank you so much !

openssh-server should be installed by default on all images/configurations.

thanks again, I'll do this soon.

chatgpt advised to type ":UTC" or ":Europe/Berlin" and it helped.

Same answer as above. Without serial logs impossible to debug. It leaves to mention that this board is not officially supported but configuration has been provided by a community effort. Board status is unknown to the core Armbian team.

No. Yes. This is the most stable and well-developed kernel.

kernel_ramfs is located at /dev/block/mmcblk2p6 Have extracted with dd and copying through wifi adb. Interesting usb debugging is enabled in tvbox, but when connecting usb v3 cable to tvbox, host machine does not see the 'adb device', adb connection over wifi is ok. Has anybody used USB adb on this device?

No, that won’t work. This is a Armbian Linux forum. If you need android support try xda forums.

No one answers...... 🤐 I got tired of waiting and set up autologin according to these instructions. Everything is working.😁 You can use it.💯

I've checked the storage media and it seems to be a NAND - https://files.pine64.org/doc/datasheet/pine64/FORESEE_eMMC_NCEMBSF9-xxG SPEC A0 20150730.pdf Not sure if this is of any use in figuring out why it cannot see the boot partitions.

Hi guys Just to thank you for the very relevant information I found in this forum. I am posting my experience with armbian. I successfully installed the unofficial armbian version "25.05.0 onecloud noble 6.12.17 xfce desktop" on a generic MXQ TV Box S805 with HTC-MXQ-V4 card. It was hard work! this box calls the aml_autoscript on boot... but need to be adjusted to allow booting. this procedure works for the board i mentioned, i don´t know about others. Use at your risk !!! But booting from SD is a relativelly safe procedure. download "Armbian-unofficial_25.05.0-trunk_Onecloud_noble_current_6.12.17_xfce_desktop.img.xz" uncompress the image (7zip) save to SDcard (8GB recomended) - I have used rufus Two partitions will be created. Two partiotions will be created ... first FAT32 (armbi_boot) and second EXT4 (armbi_root). On FAT32 partition (boot): file: aml_autoscript (copy commands below and put inside aml_autoscript.cmd) # Define boot only from SD Card setenv bootdev "mmc 0" # SD card # Load armbianEnv.txt fatload ${bootdev} 0x10800000 /armbianEnv.txt && env import -t 0x10800000 ${filesize} # Boot Arguments (provided by armbianEnv.txt) #setenv bootargs "" setenv bootargs "${bootargs} rootwait rw" setenv bootargs "${bootargs} ${consoleargs}" setenv bootargs "${bootargs} ${extraargs}" # Booting fatload ${bootdev} 0x14000000 /uImage || exit 1 fatload ${bootdev} 0x15000000 /uInitrd || exit 1 fatload ${bootdev} 0x11800000 /dtb/meson8b-onecloud.dtb || exit 1 bootm 0x14000000 0x15000000 0x11800000 file: armbianEnv.txt (copy parameters below and put inside armbianEnv.txt) consoleargs="console=ttyS0,115200n8 console=tty0 no_console_suspend splash=verbose" bootargs="root=LABEL=armbi_root" extraargs="loglevel=7 rootfstype=ext4 earlyprintk ip=dhcp" On Linux, put aml_autoscript.cmd on an directory and compile "mkimage -C none -A arm -T script -d aml_autoscript.cmd aml_autoscript" Copy both aml_autoscript.cmd and compiled aml_autoscript to root of FAT32 partition Adjust (with above parameters) or create a file and copy armbianEnv.txt to root of FAT32 partition. Rename "meson8b-mxq.dtb" to "meson8b-onecloud.dtb" to be compatible with same name defined on aml_autoscript (you could rename the file ou change the script ... choose) Boot from SDCard (Turn tvBox off, with a toothpick, click the button inside AV conector, hold down and turn on the TV box, hold the button for 5 to 15 seconds ) if everything went well the firt boot occur and your tvbox could boot from SD in armbian Linux with kernel 6.12 The first boot is extremelly slow... a lot of time... Good luck!!

Ok, I'll wait for the release to land and test again. I agree, upgrading away from legacy is good. That said, as things are now this will break any installation that is using wlan when they upgrade their packages and are on the legacy kernel. And it's even worse as the user needs to know to update to latest release and only then swap kernels due to the timing of the wlan fix. To put it in different words, I'm not proposing we fix the legacy kernel. I'm saying we need to make sure that we're not breaking current users who have no way of knowing that things are going to be breaking.

@Diego Dagum are you using an apt caching mirror like apt-cacher-ng?