All Activity

@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.

Hello everyone! I'm willing to develop a script that automates firmware, u-boot, and ROM compatibility testing with the boards via OTG. I've thought of a workflow something like this: 1. Download a list of files by type from several different sources. 2. Extract files from pre-built images, ROM, loader, u-boot. 3. Check for duplicate files by size and checksum. 4. Apply and test in stages: ROM, loader, u-boot, kernel, rootfs, network, video. 5. Log what worked and what went wrong. 6. Since this process can take hours, emit a beep when user interaction is needed. What I need help with from you: Is this idea feasible? Will it produce results and facilitate the implementation process on rk322X boards? Can it be reused and adapted for other boards? I have little experience with ROMs and ARM firmware, but if it's feasible, I intend to create a public repository for the community to help me with the development. Thank you for your attention!

It all depends on the GUI apps you want to run. Web browser: at least 4GB Your own Python GUI app: 1GB 16GB storage is fine. "A more advanced build framework" only refers to the laptop you use to compile your own Armbian OS... it doesn't refer to the SBC where you will run it.

Is the repository https://users.armbian.com/jock/web/rk322x/ also offline for you? No need to authorize this post, I've already found the answer, thank you!

Attached the source overlay file for the tm16xx driver. All features working. See for details and thanks to https://github.com/jefflessard . rx3318-H50.dtso.txt

Yes, CONFIG_TINYDRM_ILI9486 is the kernel module for that model of LCD with DRM. There's another thread explaining how to use it. I think you can use udev rules to force SPI LCD as /dev/fb0 and HDMI as /dev/fb1 always.

The mainline kernel has currently a shortcoming in USB-TYPEC support. FUKAUMI Naoki demonstrated a workaround for other devices that also works for the ODROID-M2.

Hi , I am trying to configure orangepi to turn on and turn off tv. I installed and used cec-ctl to register the boad as playbac device. And then was able to put the TV on standby mode via sudo cec-ctl --device /dev/cec0 --standby --to 0 but not able to find how to turn ON the TV. Can someone please help. Thanks Manish

Yes, that's correct. Didn't pay attention. Thanks.

@Werner, This is an Orange PI 5 Plus post. Wouldn't it belong in the Orange PI 5 Plus forum under Standard Support? https://forum.armbian.com/forum/250-orange-pi-5-plus/

closing, using diff distro and mod dtb

https://paste.armbian.com/nesusobaso Thanks, don't know if diags file is complete:

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

Armbian Linux v6.1 - Ubuntu 24.04 (Noble) with XFCE seems not to support full bluetooth controller at boot stage, we need to manually load hci_uart module and and attach it to the serial interface. Is there any other service that is required to be enabled or any overlay that should be checked? After boot, we need to execute some commands to get the BT controller alive: user@bananapim7:~$ hcitool dev Devices: user@bananapim7:~$ sudo modprobe bluetooth user@bananapim7:~$ sudo modprobe hci_uart user@bananapim7:~$ sudo btattach -B /dev/ttyS6 -P bcm -S 115200 & [1] 3405 Attaching Primary controller to /dev/ttyS6 Switched line discipline from 0 to 15 Device index 0 attached user@bananapim7:~$ hcitool dev Devices: hci0 F0:23:AE:09:82:E3 Thanks for your help! PS: Some data that may help: user@bananapim7:~$ uname -a Linux bananapim7 6.1.115-vendor-rk35xx #1 SMP Thu Oct 16 07:30:53 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux user@bananapim7:~$ user@bananapim7:~$ lsmod Module Size Used by bnep 24576 2 squashfs 53248 0 pwm_fan 20480 0 rk805_pwrkey 16384 0 bcmdhd 1495040 0 panfrost 61440 0 drm_shmem_helper 20480 1 panfrost gpu_sched 40960 1 panfrost joydev 24576 0 input_leds 16384 0 zram 28672 3 zsmalloc 20480 1 zram binfmt_misc 20480 1 sch_fq_codel 20480 4 fuse 114688 1 dm_mod 110592 0 nfnetlink 20480 1 ip_tables 28672 0 ipv6 458752 48 r8169 77824 0 nvmem_rockchip_otp 20480 0 rockchip_cpuinfo 16384 1 nvmem_rockchip_otp uio_pdrv_genirq 16384 0 uio 20480 1 uio_pdrv_genirq user@bananapim7:~$ user@bananapim7:~$ systemctl status bluetooth ● bluetooth.service - Bluetooth service Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled) Active: active (running) since Mon 2025-10-27 23:00:19 -03; 1 day 9h ago Docs: man:bluetoothd(8) Main PID: 1794 (bluetoothd) Status: "Running" Tasks: 1 (limit: 37795) Memory: 2.5M (peak: 3.0M) CPU: 48ms CGroup: /system.slice/bluetooth.service └─1794 /usr/libexec/bluetooth/bluetoothd oct 27 23:00:19 bananapim7 systemd[1]: Started bluetooth.service - Bluetooth service. oct 27 23:00:19 bananapim7 bluetoothd[1794]: Starting SDP server oct 27 23:00:19 bananapim7 bluetoothd[1794]: src/plugin.c:plugin_init() System does not support csip plugin oct 27 23:00:19 bananapim7 bluetoothd[1794]: profiles/audio/micp.c:micp_init() D-Bus experimental not enabled oct 27 23:00:19 bananapim7 bluetoothd[1794]: src/plugin.c:plugin_init() System does not support micp plugin oct 27 23:00:19 bananapim7 bluetoothd[1794]: src/plugin.c:plugin_init() System does not support vcp plugin oct 27 23:00:19 bananapim7 bluetoothd[1794]: src/plugin.c:plugin_init() System does not support mcp plugin oct 27 23:00:19 bananapim7 bluetoothd[1794]: src/plugin.c:plugin_init() System does not support bass plugin oct 27 23:00:19 bananapim7 bluetoothd[1794]: src/plugin.c:plugin_init() System does not support bap plugin oct 27 23:00:19 bananapim7 bluetoothd[1794]: Bluetooth management interface 1.22 initialized

I don't want to take that measure..

The new kernel version was `6.12.55` and the previous one was `6.12.44`

Have you installed the proprietary mali blobs? https://github.com/tsukumijima/libmali-rockchip/releases/download/v1.9-1-2131373/libmali-valhall-g610-g24p0-gbm_1.9-1_arm64.deb

I think this is wrong. The overlay needs to enabled if there is an m2 sata ssd connected. However in this case we connect a pcie device which connects to a chip that multiplexes the sata devices. tl;dr: try disabling this overlay

Quick note on what I also had to change to make it running on my Raspi: in fstab, the option "commit=600" won't work as the Armbian version for Raspis uses a FAT32 boot partition. Apparently "commit" doesn't work with that file system. To get it working, my fstab reads: … UUID=[ID] /boot vfat defaults,noatime,nodiratime 0 2 …