Active threads

Thanks for your comments. I did not touch the regulator@40 values at all - only the opp frequencies in line with suggestions from @prahal and some cache settings. cpufreq sampling_rates were changed to about 40000 (depending on the cluster) for kernels 6.6 by a script in /etc/rc.local. The script does not apply anymore in linux 6.12. Instead of disabling the A72 cluster altogether, reducing the burden on the CPUs during data transfers helps to substantially reduce crashes and avoids triggering the watchdog timer.

TallMan - Thanks for the recommendations. I thought I would try them, and use it as a learning experience for Armbian - I made a hash of it, I think, and sorry, I need some help again. First I looked for kernel 6.16.4 online, and found at least two, with different SHA checksums. Then it occurred to me that perhaps they were listed in Armbios-config, so after reading about it in the documentation, I booted it and eventually found a list of kernels available, so I selected Vendor 6.16.4 and tried to install it. Somewhere I went wrong, but don't know where - the process seemed to be running fine, and something (?) seemed to be installed. Eventually it needed a reboot - but once again I had a brick. I didn't get as far as installing the OS on EMMC or SSD. I reflashed the SD card with vendor kernel 6.1 as previously, to start again from scratch, but am not confident about trying the update again - hence the need for one or two pointers. Sorry about this - your help would be appreciated. Keith

The easiest way to do this is through a chroot (or perhaps systemd-nspawn) but how practical this is will be dependent on your end goals. I do this all the time.

At the risk of speaking too soon, I think I have found the issue. I need to revert some changes, and do some final testing, but hopefully a PR will be inbound to fix this in the next couple of days.

https://paste.armbian.com/nocivefiki

https://debug.armbian.de tl;dr: get an USB uart adapter and debug via serial console.

moved

SOLD

I found the error, please don't do it again. Just Search for Supported boards before buying Partners boards that will work in this case: https://www.armbian.com/partners/

Probably never will until roll-over to next LTS version. We don't have people to maintain this.

Even with the new version,I am still running into the same error dmesg.multitool.log

"if you have ever booted a different distribution then your box will be incompatible with the Armbian build" are you serious? No matter after all this linux on arm shit problems i had last week, i really must say that a windows 10 + kodi.exe on a thin client is really the best in quality (dxva) and stability. And it only eats 1-2w more power than this u1 thingie. So, i just keep my moonlight on windows and put tvheadend together with the wintv solohd into a vmware player. bye bye.

You should also be updating your /etc/apt/sources.list.d/armbian.list as well (otherwise you will be mixing bookworm armbian packages with trixie debian packages)

How do install armbian in my TX98 TV BOX Processor:Allwinner H313 I bought it on tiktok shop

Hello, and thank you for the suggestions. Just to clarify, I am not using an ILI9341 or ST7789 display. My display is a ST7735S (1.8", 128x160), a generic model purchased from AliExpress. The main issue is that while this setup worked perfectly on older Armbian kernels, it's no longer working with the current Kernel 6.12.x. It seems like the necessary module might have been removed or changed in the newer versions. I am not using a desktop environment; my goal is to use the display directly from the console/framebuffer (no X11). I’ve made some progress, but now I’m stuck. Here’s what I'm observing: The system does create a framebuffer device at /dev/fb0. When I use a tool like fbi to show an image, it runs without any errors. If I try to dump the framebuffer device (e.g., cat /dev/fb0), it outputs data, which suggests something is being written to the buffer. The problem is on the physical display itself: the screen's backlight turns on, but it remains completely blank (white). No image is ever displayed. I'm unfortunately not sure how to proceed from here. It feels like the display is being initialized enough to turn on the backlight, but the actual image data isn't being displayed correctly. I suspect the driver is not sending the right commands. Does anyone have an idea what I could try next? Thank you!

@FucusMeDeep don't throw yourself into this, I'm not the best example to be messing with junk, but times have changed, if it were really interesting I would recommend it. with that time and money I buy a board https://www.banana-pi.org/ anything that involves reinventing the wheel there is already ready, don't use material discarded by someone else. develop something on top of these boards, go further create something at a higher level than what you want to create. do this project with a more documented and healthy board: CH573F from Nanjing Qinheng Microelectronics Part of the document's included below: WCH 官方网站 www.wch.cn(zh-CN) / www.wch-ic.com(en) 时钟和电源 时钟： 32Mhz HSE 高速无源晶体输入 32.768k LSE 低速无源晶体输入 电源： 3.3V-5.5V电源输入，3.3V LDO最大100mA额外输出 USB电源串有二极管，防止电流倒灌 同时二极管可以通过短路焊盘旁路 5V带有TVS二极管 接口和按键 接口： 12Pin 2.54mm间距 I/O接口 * 2 按键： 复位/B23按键 * 1 Boot/B22按键 * 1

@RealAn DTS for Kernel 6.1: Unfortunately, all boards for TV Box device are embargoed upon landing in my country's territory. If any Golden Knight wants to do the development, I believe this is a good time.

https://github.com/radxa-pkg/aic8800/releases/tag/4.0+git20250410.b99ca8b6-2 The above should get you to a useable page. Download the USB version of the .deb package. I stored mine in the /root but had to copy it to the /tmp directory and install it from there. I installed the .deb package after the apt upgrade process, then rebooted. There may be a more recent version of the package. If I find it, I'll post a link Hope this helps, let me know if you run into trouble.

i can say that linux-image-6.12.43+deb12-arm64 works

Thanks for the reply @hexdump , the thing I don't understand is that in the thread I mentioned in my first message to this thread : the person claims to have successfully installed the OS on the internal eMMC on my very same box. Why running from eMMC wouldn't be possible on mine? What I am afraid of is that maybe there is some information / log which might be important in the outputs I provided in my pictures in the first message which I fail to recognize. About the message from @SteeMan I don't understand what he means by "and patch and apply it to a newer u-boot and build a newer u-boot"... In the /boot/build-u-boot/readme.txt file the instructions only have 3 different u-boots possible (s905x, s905x2 and s905x3) and all of them are like "git clone, run make" and that's it. Could you please be more explicit in what I should do or point me to some useful documentation? Thanks a lot for your help.

This build has disabled ffmpeg, I don't know it is possible to build with it for wayland client. I recommend x11 client because it is the most usable client with the most features. FreeRDP developers is developing a new sdl client for all platforms: linux, mac, wayland, x11, but that is still at an early stage. If you run xfreerdp, make sure to use gfx:AVC444 so that server sends h264 stream to you, then freerdp will use ffmpeg to decode it. You can check /proc/mpp_service/ to see if mpp hardware decoder is used. But don't expect the cpu will be extremely low, freerdp is decoding two avc420 streams and then combine them into one yuv444 frame, and then use cpu to convert yuv444 to rgb, then render it to x11, hardware decoder can only off-load few of the cpu load.

Not sure whether is specific to Opi5-Plus, on Arch Linux mpv-0.40.0 somehow also did not support --hwdec=v4l2request as such had to resort to the mpv-full-git which supports --hwdec=v4l2request. Debian-Trixie's repo mpv-0.40.0 also doesn't seems to support --hwdec=v4l2request.

I had the same problem when trying this directly on my Banana PI M5. But when I connected from my notebook via ssh everything worked fine and I could create the root and user password. Afterwards login was also possible directly on the machine.

Hi, I guess this happens because of the "-x" option in rsync which tells rsync to not cross the filesystem hierarchy. /var/log is typically a mount (/dev/zram1) so it will not be synced.

I suggest booting from µSD and then making a copy of eMMC to somewhere and reinstall after that. You can then restore whatever you need from your eMMC backup. Most likely that will be vastly less headache and much higher chances of success.