Active threads

Okay, trying another HDMI cable fixed it, although on radxa's debian it worked with the same cable but thanks.

This also happens on other kernels. Issue is present on final 6.18.0 kernel as well as on the older 6.12 kernel. It seems to be related to some kernel options that are set to "m". Need to figure out which kernel options would need to be set to "y" (built-in) on Armbian to avoid this issue on power-on.

I do not have your board but have you tied looking in armbian-config?

Armbian 25.8.2 Noble XFCE (BSD Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + GE-proton-10.25 (https://github.com/GloriousEggroll/proton-ge-custom) + DXVK-stripped v1.6.1 ~60fps@1080p Half Life 2

I ran into a similar issue, I think it was related to having the wifi usb adapter plugged in at the same time. after a second reboot with the adapter unplugged I was able to get to the first run setup screen and set the root password and create my local user account. new to armbian, replaced a failed image from the stock odroid c1+ ubuntu 18 release with the latest, was happy to get it up and running, as we used this board to drive our home 3d printer. unrelated - i did apply to be a board maintainer, happy to help if/when/where I can

Hey @Sergey Lepeshkin, your information proved very helpful! I have a tv box in the same vein as yours, but mine is version Z01S-V13.3, so they probably revised it a little bit. Thanks for finding the UART pins! I will try it out and post what I find! My objective here is to overclock it, install active cooling and a heatsink, and see how it runs some emulators. Btw, quick question, performance wise the box would be faster on Armbian or Android? Thanks!

Hi @wolf7250, The $PWD is an environment variable that represents the current working directory. The lone period "." also represents the current working directory. $PWD has nothing to do with your password - unless your folder names are the same as your password and/or vice versa. As to your question, yes, I would think a fresh reinstall from scratch is going to be the best way forward. But I have no idea how easy that will be with transferring OMV settings from old to new etc. OMV is unbeknownst to me. On the other hand, if the workaround with the new load addresses in `armbianEnv.txt` work (and they seem to work just fine) it's more of a matter of how "correct" you want your situation to be. Things seems to be working. Groetjes,

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

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

@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

https://users.armbian.com/users.armbian.com/jock/web/rk3318/ It seems like old firmware is stored here.

Well I got it to display something, it isn't exactly what I want but I am just happy I got it to do something. I decided to try with the orangepi image from their website "Orangepizero3_1.0.2_ubuntu_jammy_desktop_xfce_linux6.1.31.img". I was going to share image from what it's displaying but for some reason I keep getting an error trying to upload. Basically it's showing the orangepi boot logo but then all messed up, it's all over the place. ------ edit got image to upload. ------

But if that were the case, simply leaving it powered off for a while and then turning it back on should fix it, but it doesn't. As I mentioned, I have to re-flash them from scratch with Android before I can reinstall Armbian. Additionally, the boards are completely exposed (out of the casing), with a heatsink on the SoC and proper ventilation. The power supply shouldn't be the issue either, as it is also fully ventilated.

posting output of : armbianmonitor -u Helps with support.

While doing various tests, also other bootloader than EDK2-UEFI v1.1 that I had in eMMC, I discovered that with 2026.01-rc2_armbian-2026.01-rc2-S365a-Pa203-He3cc-V062a-Bbf55-R448a kernel 6.18.0-rc7-edge-rockchip64 did not find/enable audio via HDMI. I moved the computer to other room where I rely on the speakers in the monitor, else I would not have discovered it as I also use networked pulseaudio. What works is 2025.01-armbian-2025.01-S6d41-Pdb4b-H2194-V062a-Bb703-R448a, so sort of last-known-good, got that via: sudo apt install linux-u-boot-nanopi-r6c-current=25.8.1 and wrote the binary with dd to eMMC Another issue is that the monitor does get out of sleep too late, so the loglevel=7 effect can only be seen on extra serial console, whereas with the UEFI bootloader, the HDMI gets always initalized properly, so before kernel is loaded. Note that this is with booting via grub. So with EDK2-UEFI v1.1 bootloader, I get a normal Debian graphical kernel selection menu, like on x86-64. With Opensuse Tumbleweed it is slightly different, as that also automatically duplicates on serial console (if 't' is pressed , from 'text'). So this is actually quite ideal. The only disadvantage is that it does not want to store boot entries (but works on ROCK5B in SPI-flash). I probably need an own build on SD-card first to see how 2026.01 (or later) can do the same as EDK2-UEFI v1.1 more or less. I should note that with EDK2-UEFI v1.1 bootloader, I do not load the DTB that comes with the kernel version. I used the setting 'vendor' or 'mainline' in the UEFI settings, that gets stored well actually. Now with the 25.8.1 U-Boot, I manually added a devitree loader line in grub.cfg, but that will be overwritten, so need to see what makes sense.

I fixed my i2c gpio ldo regulator issue by disabling the axp_gpio in the device tree. &axp_gpio { status = "disabled"; }; The separate driver must have been rewriting the registers configured by the regulators driver. Now back to the LCD

First thing backup all the configs with another linux computer. Then you can try to chroot the sd card on the other linux computer and run passwd as root.

You’re more than welcome to clone my repository and fix the frame buffer console. All the sources are there except u-boot.

Got it connected now to a simple 13.8V PSU and it’s working a treat, just working my way around Linux and Runners but all good ! Thank you for the help @eselarm!

@laibsch, the answer to your question is in my last post. All those bad/"half-broken" adapters don't have problems with sequential writing/reading. And if you consider helpful pointing me to some obscure GUI writing tools as helpful, sorry, it's was not. I trust "dd" more then any of them. Very helpful was, however, @eselarm's post and I expressed my gratitude for it. To be honest, I don't really understand the intention of your last post. Could be my English is not good enough... Anyway, if my tone was was too harsh, I apologize for it.

Thank you, @Mangix. We bumped u-boot to v2025.10 for Helios, so I would assume those commits are already incorporated, aren't they? I have only looked at commit dates, not actual code.

@robertoj OK. I managed to build Armbian, selecting mipi-panel-dbi support and booting to 16-bit. After setting it up and running the dts you provided, my screen still doesn't work. I'm probably doing something wrong, because although the screen glows white, it still shows barely noticeable backlight flickering. I also tried to do it according to Pancake's instructions, but I also didn't have any success. This log with Pancake's cat log.txt [ 1.623324] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.173154] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.242555] sdiohal:sdiohal_parse_dt adma_tx:1, adma_rx:1, pwrseq:0, irq type:data, gpio_num:0, blksize:840 [ 7.591150] systemd[1]: Starting systemd-backlight@backlight:backlight_gpio.service - Load/Save Screen Backlight Brightness of backlight:backlight_gpio... [ 7.652908] systemd[1]: Finished systemd-backlight@backlight:backlight_gpio.service - Load/Save Screen Backlight Brightness of backlight:backlight_gpio. user@orangepizero3:~$ hostnamectl Static hostname: orangepizero3 Icon name: computer Machine ID: a5f7b63422b54dc5a365def0a7294555 Boot ID: 4445f89ef8cb4b999e3fa684f292ca2a Operating System: Armbian-unofficial 26.02.0-trunk bookworm Kernel: Linux 6.16.8-edge-sunxi64 Architecture: arm64 And this log with DTS from you cat log.txt [ 1.623908] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.172898] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.242212] sdiohal:sdiohal_parse_dt adma_tx:1, adma_rx:1, pwrseq:0, irq type:data, gpio_num:0, blksize:840 But I'm very happy that I managed to build my first Linux, albeit in such a simple way. My pinout Displ OpiZ3 Vcc - out 3.3v Gnd - gnd Cs - ph9 Reset - pc14 Dc/rc - pc7 Sdi(mosi) - ph7 Sck - ph4 Led - 5v Sdo(miso) - ph8

Hi, I’ve installed Armbian to my Vero4k+ and all works fine except wired ethernet, the thing is it kind of works, but when I use different dtb files: meson-gxl-s905d-vero4k-plus.dtb wifi works, bluetooth works eth doesn’t, eth0 interface is UP but can’t get IP or set one, meson-gxl-s905d-p230.dtb wifi works, bluetooth doesn’t, eth generally works but when testing with iperf3 in server mode it’s great cca 930mbps 0 errors, but in client mode it depends of OS (ubuntu or debian) and kernel (5 or 6) used from 1-350mbps but with looooot of errors (cca. 67000 for 10 sec test) and if I limit link speed to 100mbps it doesn’t change much, also lot of errors, if I boot it to osmc it works fine (920mbps symetrical, also some errors on client side but fine). Is there anything I can do to troubleshoot - fix this? Thank you