All Activity

After wanting to use Debian 13 (Trixie) @Nick A suggested trying to build it myself, and this was my first experience building an Armbian image. I encountered some obstacles, but I got through them. I saw that the model was mentioned branch v20251014. I tried building it (Mate Desktop), which as build smoother than (v20250306) before. I tried booting it with this box (Transpeed 8K618-T) and and found that the wifi was not visible. I followed the troubleshooting methods in the previous thread solved it. I have installed additional IR remote and OpenVFD. Now everything is smooth and happy. The only thing left is the video acceleration, but that would be difficult because it is beyond my ability. Finally, thank you, @Nick A

Even though current is an LTS kernel it probably makes more sense to focus on vendor an edge. vendor because its rockchip bsp and close to being feature-complete. And edge for likely becoming the next LTS kernel which ultimately become current at some point. You can try to see what actually works on current at this time. You can ignore 6.15-6.17 since those patches, if still present, are for archival purposes only and will be remove at some point. In theory it could be re-used but may introduce confusion. If in doubt, copy and rename. Edit: Seems like lots of stuff has been mainlined already. So I suggest shifting your primary focus on edge.

@jock I didn't know the problem could be the watchdog, nor did I know about the existence of the open-source Trust OS. Do you think it's feasible to include the open-source Trust OS in this testing process, or does the open-source Trust OS solve all these problems? My idea wasn't to change it at runtime; my idea is to flash, reboot, test, save the result, repeatedly until all possible combinations are exhausted.

@Gian Luca Please try libMali route: + Flash Armbian 25.8.1 Noble Gnome (Vendor Kernel: 6.1.115) + Disable the Panthor overlay + Install libMali https://github.com/ginkage/libmali-rockchip/releases/download/v1.9-1-04f8711/libmali-valhall-g610-g24p0-wayland-gbm_1.9-1_arm64.deb + Install the WSI https://github.com/ginkage/vulkan-wsi-layer/releases/tag/v1.3.276-1-d48decd (for Wayland, XWayland only) mesa (Panfrost/PanVk) route: + Flash Armbian 25.8.1 Noble Gnome/XFCE (Vendor Kernel: 6.1.115) + Enable the Panthor overlay + Install the "mesa-vulkan-drivers" https://launchpad.net/~ernstp/+archive/ubuntu/mesarc (for both Wayland and X11)

Armbian 25.8.1 Noble XFCE (BSD Kernel: 6.1.115) + PanVk - mesa 25.2.6 (https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + wine-10.17-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.17) + DXVK-sarek-stripped v1.11.0 (https://github.com/pythonlover02/DXVK-Sarek/actions) ~30fps@720p Dark Souls: Remastered

Hi Armbian Community, I'm creating a board configuration for NanoPi Zero2 (RK3528A) and wanted to coordinate with the community before submitting. Great News: Mainline Support Exists! I discovered that Jonas Karlman has already merged NanoPi Zero2 device tree support into mainline Linux kernel: Device tree: rk3528-nanopi-zero2.dts (merged for v6.15-6.18) U-Boot support: Also merged Source: https://github.com/ziyao233/rk3528-mainline Since the hinlink-h28k.csc config already provides RK3528 support, creating a NanoPi Zero2 config should be straightforward. Quick Questions Is anyone already working on this? (Don't want to duplicate!) Kernel branch: Should I target current (6.12) or edge (6.15+) for the DTB? Bootconfig: Can I reuse hinlink_rk3528_defconfig or does Zero2 need its own? My Plan # Copy existing RK3528 config cp hinlink-h28k.csc nanopi-zero2.csc # Update: BOARD_NAME="NanoPi Zero2" BOOT_FDT_FILE="rockchip/rk3528-nanopi-zero2.dtb" KERNEL_TARGET="current,edge" Testing Commitment Hardware: NanoPi Zero2 arriving next week Use case: Production IoT device (headless, Docker, eMMC boot) Will test: Full manufacturing flow, LED control, eMMC boot, network, Docker Will contribute: Tested config + documentation Why This Board? Tiny form factor: 40×40mm Production-ready: Good margins, reliable supply Sufficient specs: 2GB RAM, eMMC, single GbE Mainline support: Thanks to Jonas Karlman's work! Any advice before I proceed? Happy to collaborate or take guidance from maintainers. Thanks! 🙏

That's probably the boot partition in fat32. You can't read linux partitions in Windows without tools. So it's normal you can't read an armbian image in windows since it doesn't use fat partitions. Why it doesn't boot is another case. I would try to build my own image with either legacy or mainline kernel. I don't have the board so no idea what works on it.

It is nog normal desktop images are not available. You can always install a desktop to server images. I use taskset for desktops that need a lot of dependancies. sudo apt install taskset sudo taskset For the xu4 there should be not much difference with the armbian desktop images except for the background image.

@GmP ok, so the leds in the previous dtso are wrongly addressed? Because in the latest dtso I see 7 leds addressed on segment 0, instead the previous dtso declares 4 sparsely addressed leds. edit: note also that your board is T98_RK3318, not T9_RK3318

@jock I have also tested the driver for a rk3318-T9, please see below in case it is useful for the device tree overlay.

Here you are the correct dtso for the latest version of the tm16xx / kernel. Note that this is not the same model of rk3328-t9.dtso found in https://github.com/jefflessard/tm16xx-display however I do think it will work with that model as well. The automatic generated dtso file for the rk3328 from vfd seems to be icorrect as it is addressing segment 7 of fd655. rk3318-t9.dtso

Hi, my feedback with rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and agressif fancontrol setting like this: # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input MINTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=30 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=30 MAXTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=50 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=50 MINSTART=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINSTOP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINPWM=20 is: All it's Okok Without the tunning file DTB and Fancontrol, the nighmare restart. Today, update, original DTB file restore and CRASH when Luks begin to unciffer my DDs Il restore DTB file and my fancontrol setting and: Return to Okok situation. To conclude, i use my helios without problem when this files is installed. My helios64 always crash if i return to original setting after a update.

Thanks for the reply. My question was worded improperly. It should have been "Latest compile for odroid xu4 doesn't have a desktop. Any reason why?" Sorry

Yes you are perfectly right. It took me some "minutes" to figure out. Just in case I do have the overlay dtso for the previous tm16xx version. No scrolling message however. Use ../value instead. rx3318-H50.dtso-old.txt

@GmP thanks for the contribution, but I want to advice you that the driver changed in kernel 6.17 due to kernel developers requests and suggestion, so that device tree overlay is suitable only up to 6.16 I made a pull request to include the device tree overlays: https://github.com/armbian/build/pull/8848

I also happened to get an X88pro13 TV box on my desk. Since it promises good performance, I've been experimenting with getting Armbian running.. My first attempts look promising. Armbian-update and armbian-config are working. It could be a good platform for Smart-Home, Console and desktop Armbian is running well. _ _ _ __ __ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ ___ _ _ _ _ ___ / _|/ _(_)__(_)__ _| | / _ \| '_| ' \| '_ \ / _` | ' \___| || | ' \/ _ \ _| _| / _| / _` | | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| \_,_|_||_\___/_| |_| |_\__|_\__,_|_| v25.11 rolling for Hugsun X88pro running Armbian Linux 6.1.115-vendor-rk35xx Packages: Ubuntu stable (noble) Support: DIY (custom image) IPv4: (LAN) 192.168.178.71 (WAN) 130.185.10.185 Performance: Load: 82% Uptime: 0 min Local users: 3 Memory usage: 7% of 3.82G CPU temp: 41°C Usage of /: 10% of 58G RX today: 262 KiB Commands: Configuration : armbian-config Monitoring : htop HDMI output, LAN, Wi-Fi, and USB 2.0 are supported. Audio not tested yet. Bluetooth and USB 3.0 aren't working yet and require further investigation. IR remote control is also not working. I've shared my results and instructions for creating the image at: https://github.com/joilg/x88pro A ready-made image for an Armbian server with a console interface is available at: https://github.com/joilg/x88pro/tags A desktop version can also be easily created. Please try this version and let me know if you encounter any problems. johlnx

If you need an image without desktop, there is always the build framework which allows you to build any combination of kernel and userspace and desktop you want.

More informations : after i wrote an armbian image on SD card with USBImager on my windows desktop (with verified checked) , The SD card is not readable , it appears as not formatted in windows. But if i write the image from BPI site, i can read the partition on the SD card and see the files on it. Maybe it helps

@Aroldo Bossoni The optimal would be understanding the reason why the watchdog triggers, but could be a difficult task without a hint because of the closed source proprietary trust os. The easiest thing is to provide armbian images with the opensource trust os rather than the proprietary, which is totally feasible because it just requires to swap a file in the armbian build scripts. That would blow the issue away, but unfortunately the proprietary trust os provided DDR scaling and virtual poweroff. The latter is a seldom used feature, but the DDR scaling provided a dramatic improvement in performance and it is hard to give up on that. Swapping the things at runtime is not savvy: when u-boot updates, the proprietary trust os will be reinstalled overwriting whatever you put in there. I would be happy with opensource Trust OS and no runtime DDR scaling, but stil having it at a fixed decent rate (660MHz, instead of the default 330MHz), but some boards do not boot at all when they are instructed to boot at 660MHz.

i`ll already fried that lcd. So this is the end Because short circuit is been in lcd, orange is a live for now. try to move on hdmi lcd+touch. Thanks for U`r help robertoj.

I confirm this issue. For the purposes of this experiment, I replaced the power supply with a similar one equipped with an LED. The power supply is connected to an electrostatic precipitator equipped with a power button. We turn on the electrostatic precipitator using the button. The power supply LED lights up. The Odroid M1 turns on and boots normally. We shut down the Odroid M1. We turn off the electrostatic precipitator using the button. After 2 seconds, we turn it back on. The Odroid M1 does NOT turn on again. Therefore, replacing the power supply did NOT solve the problem. Experimentally, we have determined that the Odroid M1 does NOT turn on again as long as the power supply LED remains lit, even when the electrostatic precipitator is turned off. Therefore, the issue lies with the residual charge in the power supply capacitors. If, with the electrostatic precipitator turned off, we wait until the power supply capacitors are depleted and the power supply LED goes out, then when we turn on the electrostatic precipitator again, the Odroid M1 turns on normally and boots normally. Meanwhile, the Raspberry Pi doesn't have this power supply issue. Therefore, this is a design flaw in the Odroid M1.

I would love to get this or support with the devices I own. I think we should continue developing Mini-AndroidTV-PCs as easy as possible and give that junk devices a sensful feasible life.😃

I installed the .deb package you suggested, however I don't think everything went as it should have: the device /dev/mali0 is still missing. I understood that this device must be present in order to be sure the device is used correctly. Is it right ? The kernel of Armbian Ubuntu Noble also has been updates: the version is 6.1.115-vendor-rk35xx now. The output of lsmod command is: Module Size Used by rk805_pwrkey 16384 0 nvmem_rockchip_otp 20480 0 r8169 77824 0 rockchip_cpuinfo 16384 1 nvmem_rockchip_otp adc_keys 16384 0

Thank you @Werner it just worked perfectly once disabled. That'll teach me to enable things. Beyond lower CPU usage compared to a USB to SATA adapter, I have some performance benchmarks. // write dd if=/dev/zero of=testfile bs=1M count=3000 oflag=direct 3145728000 bytes (3.1 GB, 2.9 GiB) copied, 11.382 s, 276 MB/s (usb) 3145728000 bytes (3.1 GB, 2.9 GiB) copied, 9.74696 s, 323 MB/s (sata) // read dd if=testfile of=/dev/null bs=1M iflag=direct 3145728000 bytes (3.1 GB, 2.9 GiB) copied, 10.8119 s, 291 MB/s (usb) 3145728000 bytes (3.1 GB, 2.9 GiB) copied, 9.09585 s, 346 MB/s (sata) And some Jellyfin CPU vs Hardware accelerated transcoding usage:

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