Active threads

Can you post/do something like this: I use Armbian Trixie on ARM64 computer to do builds. I banned Ubuntu (certainly old Jammy) and also do not use docker.

Я пытаюсь собрать образ Abian Trixie с включенным в ядро модулем поддержки CONFIG_DRM_PANEL_MIPI_DBI. Однако, сколько бы раз я ни собирал образ, при проверке модуля modinfo модуль panel-mipi-dbi не обнаруживается. В конфигурации /boot/config (ядро) закомментирована строка: #CONFIG_DRM_PANEL_MIPI_DBI is not set Я установил параметр M для модуля ядра panel-mipi-dbi. Также я установил параметр Y. Я также пытался изменить файл .config перед запуском сборки образа. Я использовал как Docker, так и сборку без Docker. Я использую Ubuntu 22.04.

I am afraid you need to dig deeper than those 'convenience installers'. I never used armbian-install but have been running Armbian from Btrfs for several years. It is easy and low failure risk if just simple SBC with only SD-card like NanoPi-NEO, but you get many options where various modern U-Boot builds / bootloaders can go wrong. Do the math permutation and you will realize. I know Armbian can be booted from single Btrfs formatted partition, but it meant full custom own U-Boot and own partition setup. That also involves whether you use subvolumes or not and whether you set 1 as default, other then the root of the filesystem ( ID <= 5 is that). Also features, I use zstd compression, but I am not 100% if the whole chain does also support it. So you need serial console cable to see/log what is going on and also set kernel loglevel to 7 (in armbianEnv.txt). It would also help if you post sha256sum of image you tested/used. That allows others like myself to quickly check/reproduce in virtual machine or so (I don't have OPi5) and not pick a newer build or so next week when time to help you.

Yeah I am glad that atleast I can get into desktop environment by manually doing a lightdm restart. ls /dev/fb* returns: /dev/fb0 I feel like I've tried everything possible and ended up just making a custom script that restarts lightdm a few seconds after booting, it's not ideal and it bothers me that it isn't working properly but yeah. - I am using adafruit,yx240qv29 - Yes I am using XFCE currently but I've tried Gnome too. - the Slick greeter - Orangepizero3_1.0.2_ubuntu_jammy_server_linux6.1.31 / but have tried MANY others. Also what might be useful for others, just the DTS wasn't enough for things to work, also had to create a config in /etc/X11/xorg.conf.d/ and add these lines: Section "Device" Identifier "ILI9341-Device" Driver "fbdev" Option "fbdev" "/dev/fb0" EndSection However things aren't super stable yet, the screen sometimes will randomly stop working, first I though maybe there is a screensaver or something but that doesn't seem to be the issue. Leaves me to think it's maybe power related and need to use shorter cables and a better 3.3v power supply (currently using the 3.3v from the opiz3). Lastly maybe shortening my jumper wires might make a difference. Previously the screen was all the way glitched as seen in my earlier post, I had shortened the dc, miso, mosi and SCLK jumpers but maybe I should make them even shorter. What makes me think it might be power related is also because sometimes the screen seems to go slightly dimm and then brighten back up, it's subtle but visible. Lastly I might have the depth or spi frequency not dialed in yet.

I think the confusion here is that `ip_tables` is the module reference and `iptables` is the binary built in reference. Microk8s requires this to be a module and not built in. I am compiling a standard kernel as speak to see if setting the appropriate nettable to `m` from '*` will work.

@Octavio Cuatrochio, you need root privileges to modify any partition at runtime. If you want to modify firmware, get update.zip to your PC, modify it, and flash using android's Settings->About->Local update.

Hello. Im trying to configurate and adapt OrangePI Zero 2W board to a custom extension board with multiple RS485 drivers. For now, im trying to configurate a single secondary UART (UART2) to initialize with muxed Rx\Tx pins and in RS485 (with software driven RTS pin). My current DT overlay is: And it is partially works. Works as UART. Able to send and receive data with muxed Rx\Tx. For RTS... its complicated. Seems RTS(PH4 GPIO) are initialized and acquired by UART2 software, and stay low during initial idling. After im trying to send any data (echo 123 >> /dev/ttyS2), RTS goes HIGH and stuck in this state before reboot. Im have tried to send big blob at 9600 and check the RTS with statserial. But as i see, RTS is 1 (active???) from inital to complete and after, and never changes.

Thanks for the suggestion, but it didn't work for me. Both /var/log/postgresql and /var/log.hdd/postgresql reverted to their pre-intervention ownership and permissions when I rebooted.

I am glad you made the LCD work with a DRM driver Three clarifications: the driver panel-mipi-dbi is provided in the OS image you write in the microSD. The DTS is something you get from this thread, and install it with armbian-add-overlay. Kungfupancake provides a txt or a bin file that defines the configuration sent to the LCD, when the kernel driver starts, and instructions on how to install it. The panel-mipi-dbi driver (the recent versions I tried) does not support X11, and you need 100% Wayland, and 0% X11 See my thread to install rpi-greeter (one of the 2 login managers that work with Wayland), and Labwc:

Those are super cheap maybe a dollar if shipped from Asia and an absolute essential tool for debugging. Get yourself one. http://debug.armbian.de

Hello and thank you for the problem report. What solution did orangepi.org provide for you? As you can see, nobody in the Armbian community was interested to step up and support this board and from what I have heard through the grapevine this is because of the poor support that orangepi.org gives to FOSS projects and communities such as armbian.com. Armbian has already pushed another update for Sunxi64. Maybe you are in luck and the problem is already fixed. If not, we are happy to accept a PR once orangepi.org has published a solution.

@Mohammad Adel here are some links that will help you. Find your Dram settings https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/#findComment-218660 Find boot.bin and extract dts. https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/#findComment-187672

I find the lack of GRUB via HDMI too problematic, so I put EDK2-UEFI v1.1 in eMMC again. I needed to wipe it completely, just writing the part without partition table normally done for U-Boot kept using the 2025.10 U-boot that was written there. I do not know how that comes. I know EDK2-UEFI v1.1 will divert to SD-card, so I though I use that to test U-Boot again. - blkdiscard SD-card - write U-Boot SPL 2026.01-rc2_armbian-2026.01-rc2-S365a-Pb445-He3cc-V062a-Bbf55-R448a (Dec 03 2025 - 04:31:42 +0000) to it - type reboot After restart and desktop login no HDMI audio. Kernel log showed long series of audio driver related errors - shutdown and pull USB-C powerplug - plug it in again and let it boot - then no audio error and also hear a 'plop' in the monitor that means the audio is enabled/working So it seems something does not reset correctly, so powercycle needed, while HDMI monitor is kept powered and HDMI cable stays connected all the time. What is different now: - kernel 6.18.0-edge-rockchip64 - eMMC contains EDK2-UEFI v1.1 and passes control/boot to SD-card U-Boot But I think it is the powercycle that is the key thing. An interesting new feature of the 2026.01-rc2 U-Boot is that the CPU clock go down to 480 MHz when mainline kernel, was 1GHz. Is not lowering idle power though, is 3 W, is 1.5 W with vendor kernel. Not clear why that is.

Yes, One/some/all of those kernel configs may be needed for analog audio. Start with the activating configs that correlate with the missing kernel modules * snd_soc_sunxi_machine * snd_soc_sunxi_ahub * snd_soc_sunxi_ahub_dam If it still doesn't work, activate all the 2 other linux kernel configs: internalcodec and aaudio

@Malay Your board isn't a board supported by Armbian. It is status "Community Support" which means there is no maintainer for the board and it is people like you from the user community submitting PRs that keep it active.

@MMorales@mmie4jbcu i have the same x88 pro 20 clone like you guys, on the pcb is written "x88pro-rk3566-4d32-v1.0", which should state for 4gb ddr and 32gb rom i guess? I installed latest armbian for station m2 with image-included demo-box.dtb, everything is working so far, despite bluetooth (CDtech-208821C=RTL8821CS). installed armbian-firmware-full but bt still doesn't work. Maybe usefull for just Linux-Users (i don't have a windows pc): original loader didn't allow me to boot from sd-card, rkdeveloptool (or xrock or rdeveltool-gui) didn't work for me, so i used proprietary upgrade_tool for linux from rockchip: https://docs.radxa.com/en/zero/zero3/low-level-dev/upgrade-tool I downloaded this loader from radxa https://dl.radxa.com/rock3/images/loader/rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin and flashed it with: sudo ./upgrade_tool wl 0x0 rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin After that i put in the sdcard and it bootet straight (wait for min. 5 seconds) to armbian!

Made some progress today. For debugging, I built my own image with the Edge kernel (6.18). However, this time, the board did not even boot up and there was also no signal on HDMI. The last idea I had was to downgrade the kernel using armbian-config. But since the Ethernet is not working, I was trying to setup WiFi because armbian-config was trying to load apt cache but without internet, I cannot load anything. After multiple reboots, I slowly cached the apt. Then the armbian-config loaded. I downgraded the kernel from 6.12.60 to 6.6.63 and then the Ethernet started working fine! ☺️ Current version: $ uname -a Linux rockpi.dev.com 6.6.63-current-rockchip64 #2 SMP PREEMPT Fri Nov 22 14:38:37 UTC 2024 aarch64 GNU/Linux $ lsb_release -a Distributor ID: Debian Description: Armbian_community 26.2.0-trunk.44 trixie Release: 13 Codename: trixie I am now confident that somewhere after Kernel 6.6, the Ethernet is broken in Rockpi 4B.

That's not really possible either. The only thing that is possible is using my kernel build in Armbian environment to see how it is performing for you. With my jumpstart image, this is actually quite easy to implement. For this, both root filesystems just need to be mounted and extlinux/prepare-jump-start ${target-rootfs-mount-point} needs to be executed in the jumpstart rootfs. If the target system is now being booted with firmware that uses mainline U-Boot as the payload, nothing stands in the way of booting with my kernel. And don't worry, prepare-jump-start only adds files to the target rootfs. Nothing will be overwritten or deleted. If you want to give it a whirl, speak up and I will upload a current image. But you will be disappointed, because the stock kernel only provides the functionalities available with the officially released kernel. Both Armbian and my kernel build have already applied patches that may appear in a future official release. I doubt that you will succeed, because even the fedora organization only does a full rebuild once per release cycle. There is no advantage in rebuilding a component unmodified that leads to the same result as the package already provided. It only makes sense to do this when branching off the release version in order to create a synchronized basis for further development. Only modified packages will be replaced or upgraded. My weekly upgrade gives me several gigabytes of new packages each time because I'm on Rawhide. Somehow, I can no longer manage to stick to any official release versions.

Maybe a handful, I have most SBC's equipped with one permanently. And needed for Arduinos etc, you can even power tiny old things like RPI0/1 with it (if you connect red wire to 5V pin as well). In the meantime, you might think about some previous U-Boot and previous kernel. For quite some SBCs, there is trouble when U-Boot is new/mainline/releasecandidate and kernel vendor. I am currently also doing some tests on my NanoPi-R6C (RK3588s) because HDMI is not initialized fast enough (by U-Boot). And with 6.1.115 vendor kernel really choppy mouse updates and green tint, not complete flat green luckily, I can still see icons and mouse.

I managed to run Armbian, everything seems to work except the WiFi, which is module KM3306005. Any idea how to fix it?

Thank you for the kind words.

@Jerry Falken well this forum is more oriented on hardware and compiling stuffs rather than generic linux info that you can find every where on the net so I won't answer on this, google it You can remain also on old distros such as debian 9 stretch minimal without gui but with ssh support to run headless ngix apps. I don't think you need newer distros to run such easy apps , the important is improve a good firewall and also a fail2ban app to protect your system but, again, those are more generic linux questions rather than support on tvboxes socs

Have just tested Forky (Debian) release on both the 2A and the 2F, and in both cases the wireless driver survived an upgrade. I also tested the Plucky release on the 2A, and the wireless driver did not survive the stock upgrade. I have not tested the Plucky version on the 2F yet. Also it should be noted that the cron implementation in the Forky version for the 2A is fouled up. Any ordinary user's crontab has to be edited by root. Bad permissions on a number of files. Nice to know that at least the wireless adapter problem has attracted someone's interest.

Thanks! I think it will be a little bit of work, but I agree that it would be the best way forward. So I'll attempt to start again with a fresh install. Really appreciate your help!

Does this happen if you are running from an SD card also? Or is it specific to running off of emmc?