Active threads

thank you for your reply! I reverted to the stock ubuntu for opi5 for now. I will have a new device in my hands in the next days, I will then try this

hi @spaceship we 'need to start working on it', what that means is that if you search around sufficiently, it is likely u-boot (the bootloader) and linux already supported A733. the task is 'system integration' to build that into Armbian. But as with all things, it means work, to spend hours / days figuring out how to do that and to do so and send a pull request for Armbian to include it. The challenges in life is such that most of us (including me) has very little fragmented time / energy to work on it. Perhaps that if more users 'request' it and support Armbian by way of donations, maybe they'd try to put it together and complete this work. The initial integration is one thing, the trouble is that linux keeps moving and linux 7.0 is about to be real. Hence, say you take what is there now integrate it, and no sooner 7.0 is out, you need to keep maintaining it. Hence, for a more sustainable setup, perhaps is for the community to fund Armbian to do so with donations, and efforts from the side. it is good for the community to support this effort both finanically and efforts from the side, this is to ensure that there is no "influence from a controlling (3rd) party" (possibly including a govt) i.e. no conflict of interest, e.g. to try to embed exploits in it for the govt's or 3rd party purpose, as in that the project is truly open source and inspected to prevent such exploits. but for what is worth, what it takes is a 'project' to get from here to integration e.g. in an 'edge' 7.0 kernel. --- off-topic but related, the security situation affecting commonly used commodity devices sold globally is *bad* https://www.kaspersky.com/about/press-releases/kaspersky-discovers-keenadu-a-multifaceted-android-malware-that-can-come-preinstalled-on-new-devices https://securelist.com/keenadu-android-backdoor/118913/ https://www.tomsguide.com/computing/malware-adware/dangerous-new-keenadu-malware-found-pre-installed-on-cheap-android-phones-and-tablets-how-to-stay-safe https://www.forbes.com/sites/daveywinder/2026/02/17/android-backdoor-pre-installed-on-devices---thousands-already-infected/

Hello NickA, fire-hound from discord here ... You do a tremendous service for us all, keep it up buddy! I loaded your recent build from here: https://github.com/NickAlilovic/build/releases and can confirm it works on my A7A. It correctly detected my Pimorony NVME Base lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mtdblock0 31:0 0 8M 0 disk mmcblk0 179:0 0 29.2G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 28.6G 0 part /var/lib/containers/storage/overlay /var/log.hdd / zram0 254:0 0 3.9G 0 disk [SWAP] zram1 254:1 0 50M 0 disk /var/log zram2 254:2 0 0B 0 disk nvme0n1 259:0 0 238.5G 0 disk └─nvme0n1p1 259:1 0 238.5G 0 part /srv/dev-disk-by-uuid-b28b2f5c-ee2e-4ded-959e-22bc63051b1d and: screenfetch _,met$$$$$gg. root@radxa-cubie-a7a ,g$$$$$$$$$$$$$$$P. OS: Debian 13 trixie ,g$$P"" """Y$$.". Kernel: aarch64 Linux 6.6.98-vendor-sun60iw2 ,$$P' `$$$. Uptime: 11h 14m ',$$P ,ggs. `$$b: Packages: 661 `d$$' ,$P"' . $$$ Shell: bash 5.2.37 $$P d$' , $$P Disk: 4.9G / 271G (2%) $$: $$. - ,d$$' CPU: ARM Cortex-A55 Cortex-A76 @ 8x 1.794GHz $$\; Y$b._ _,d$P' RAM: 534MiB / 7928MiB Y$$. `.`"Y$$$$P"' `$$b "-.__ `Y$$ `Y$$. `$$b. `Y$$b. `"Y$b._ `"""" So far so good The issues: 1. The typical Armbian image has a module in the armbian-config and radxa's rsetup where one can set up the two leds conveiently to other than full on and heartbeat for the green and blue gpio leds respectively. I find it to be a nuisance to dig for that manually 2. The Ovralys module in armbian-config is returning an error - when entering DTO001 module (Device Tree Overlays) saying: Invalid overlay_prefix that might require deeper digging into the issue i guess? What works: Open Media Vault registers the NVME nicely as additional storage. I suspect booting off that NVME would work for an updated SPI bootloader i could test that if you want me to? If you need any other info or output I stand at Your disposal 😁

You should also consider the bootloader (type and version), in principle you do not need the dtb- package as the dtb files are also in the kernel package (enough when doing own extlinux). U-Boot philosophy is to provide just enough so that the kernel/initrd/DTB can load and started. Audio is not part of that I think. LE certainly used other bootloader and as you already showed has more non-upstreamed patches. See my experience:

Neither of these is good advice. dd does not verify written data and balena etcher has known issues, hence it is not recommended either. Either use Armbian Imager (https://docs.armbian.com/User-Guide_Getting-Started/) or USBimager (https://gitlab.com/bztsrc/usbimager). Both are known to work.

I don't like my chances of any resolution to this problem but here goes. I'll start off by saying thanks for providing this repository, I recently went on holidays and was able to use my little magcubic box to watch content off my nas remotely. It was mostly great. One issue I have come across is most of my SD content (ripped from DVD) just displays a black screen. I encode it to 10 bit x265 the same as I do for blurays. Blurays at 1080p play fine, the DVD rips at 480p and 576p just display a black screen, audio works. When comparing them with MediaInfo the only real difference (aside from resolution) is the color primaries, transfer characteristics and matrix coefficient tags. Blurays are bt.709 and the DVD rips are bt.601. Also NTSC vs PAL for the blurays. I've also come across some files that I believe I downloaded at some point that are DVD resolutions, 10 bit x265 PAL that play ok. In MediaInfo these files are missing the all the tags mentioned above. I don't know how this is possible... To troubleshoot I've tried converting a non working file to 25 FPS (PAL) and setting the elements above to bt.709 but no dice. I've run mpv from the terminal in verbose mode and tried to compare a working file to non working file and nothing is really standing out. I think ffmpeg is just serving up black frames with v4l2 in certain circumstances, maybe when the color primaries are bt.601. I'm not overly confident the method I used above to set the bt.709 values would actually work. I installed mplayer and this plays the files ok but doesn't have hardware acceleration. This is why I think the issue is ffmpeg and v4l2. Probably not relevant but 2160p content plays (bt.2020). It really struggles with it but it displays an image. Any ideas would be great. At this stage I'm probably going to take a 10 second clip of a non working file and just run it through bunch of different encode settings until I get something that displays and work backwards from there.

Armbian 25.11.2 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + Box64 arm64 v0.4.1 ed9827920 (https://ryanfortner.github.io/box64-debs/) + proton-10.0-4-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/download/proton-10.0-4/wine-proton-10.0-4-amd64-wow64.tar.xz) + dgVoodoo2 (https://github.com/dege-diosg/dgVoodoo2/releases) + DXVK-stripped v2.4.1 30~40fps@720p (low settings) box64 environment variables: DRAGON BALL XENOVERSE

i took a look through your repo and used 2025.01 plus the patches in your u-boot-h616 directory and booting from EMMC works now. Thanks for the nudge!

Hello everybody. I'm new to this and I would like to install Linux on my BTV X p212 TV box. I saw that there are several versions of systems but I couldn't find them for this specific one and I would like to know if you can help me? Please. Ps: I searched here on the forum, google but I couldn't find it.

Good news: this is merged in Armbian main now, many thanks to @c0rnelius and @Igor for reviewing this. So no more need to grab my fork, just clone Armbian/build:main. I was able to build and quick-test orangepirv2/edge-kernel and this looks fine including Wifi. There are of course unsolved quirks currently. With edge-kernel, Wayland does not work, we need to use Xorg. And with the current bcmdhd Wifi driver, AP mode is not possible. This is caused by outdated file in armbian-firmware for bcmdhd and may be the same on OrangePi5. There is a mechanism to load a different fw_bcm43456c5_ag.bin (the one downloadable from github/xunlong seems to work). LG // Sven-Ola

As it turned out, Orange Pi does not support Power Delivery Negotiations and requires a "dumb" power supply providing 5V 4A. My power supply delivered 2A and then went into protection mode; the board itself had nothing to do with it

Make sure you have ili9486.ko in your ko module folder: modinfo ili9486 Can you use the DTS that I published in: https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/#findComment-208446 But change the "compatible" line with waveshare,rpi-lcd-35 , Delete the stuff under the "compatible" line, until the "}vsync-len = <0>;", and replace it with what you had in your DTS. Change these lines, if they are different: spi-max-frequency = <24000000>; rotate = <270>; bgr; fps = <30>; buswidth = <8>; regwidth = <16>; Reference: https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/piscreen-overlay.dts

You are not using Armbian. Ophub is a fork of Armbian. They do not contribute to Armbian development nor do they participate in these forums. You need to go to ophub to ask this question, as no one here can help you.

What is in armbianEnv.txt then? Anyway you need to load and edit it such that you make sure loglevel=7 Then there will be more text after Starting kernel ... You also seem to have a power and/or reliability problem w.r.t. cables as characters are missing in your debug log text.

High chance this uses some proprietary hardware for 3.5mm audio jack. It has been like that for decades and you probably need to find some firmware blob somewhere maybe. I have also a similar situation, most part s of the computer work fine with Debian Trixie etc, but it took ages to get sound working and still buggy, endless beep or crash occasionally. If you are lucky is it maybe only a mute setting or so, use aumix etc to look what is going on. Not something Armbian specific I guess, but up to you to figure out. Then also mention various versions, what BIOS/UEFI version the computer is loaded with, what Armbian kernel and also specific image release (if it is an unmodified image writer based installation).

Hi, is it still working now?

Linux is not a real time operating system Realtime OSes have a 1 ms accuracy You need an arduino dedicated only to make your square wave

Moved to userspace forum

Weston 15.0 has arrived, bringing a brand new Lua-based shell for fully customizable window management, an experimental Vulkan renderer, and a host of improvements to color handling, media playback, and display performance. View the full article

@MeJune You can check out my work starting with the 'Add warpme kernel 6.17' commit here: https://github.com/NickAlilovic/build/commits/v20251014/ I’m using warpme patches from his minimyth2 repo, though I’ve modified them to ensure they apply correctly. I also used my own patches for Transpeed, as his implementation differs from mine. u-boot: https://github.com/warpme/minimyth2/tree/master/script/bootloaders/u-boot-aw/files https://github.com/warpme/minimyth2/blob/master/script/bootloaders/u-boot-aw/Makefile kernel: https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.19/files https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.19/Makefile An easier way to do this is to create a board config and use the official Armbian patch set. While Transpeed is already mainlined, the implementation is incomplete. You will still need a patch to include your missing Transpeed DTS nodes. If you are happy with 6.17, then use this build: https://github.com/NickAlilovic/build/commits/v20251014/ This build generates a kernel .deb package in output/debs. You can use it to upgrade your existing Armbian installation. I haven't tried this myself, so I make no promises that it will work; please ensure you have a backup before proceeding. Backing Up the SD Card (from another PC) The most reliable way to back up an SD card is to create a full disk image on a separate computer. sudo dd if=/dev/sdX of=armbian_backup.img bs=1M status=progress If your system is running on eMMC, you can back it up to an external USB or SD card using built-in Armbian tools. Using armbian-ddbr: Many Armbian builds include this utility specifically for eMMC backup/restore. Boot Armbian from an external SD card (so the eMMC is not in use). Run the command: sudo armbian-ddbr. Select the backup option to create a compressed image of your internal storage. Using armbian-config: Some versions offer a "Backup" or "Clone" option under the System or Maintenance menus

i recently purchased an orange pi 5 plus 16gb with the wifi / bt card, the aluminum wifi case, fan and 1tb ssd. when i go to the official website i see different images there none of which seem to work 100%. i mean i was able to get each up and running but what i noticed is that the graphical drivers would not load. i saw a youtube video claiming armbian has the right driver support for the mali 610 gpu. can someone assist me getting this to work? im big into emulation gaming and right now it doesnt even have Vulkan support i crave. someone help thanks

Boot with serial attached and see if the DRAM is being properly detected. If not this patch would appear to solve the issue. https://lore.kernel.org/linux-sunxi/2813637.mvXUDI8C0e@jernej-laptop/T/#t

Hi Gaetano, I'd be suprised if Buster did work with such a newer kernel. dwc2 is Pi specific and will not work on Allwinner/Sunxi hardware. The OTG usb controller is completely different, please see the wiki: https://linux-sunxi.org/USB_OTG_Controller_Register_Guide Overlays will only load overlays found in /boot/dtb/overlay/ while user defined ones exist in /boot/overlay-user/ As expected otg is the default mode, firstly those warnings are normal when decompiling the dtb back dts as not everything gets translated back. For small modifications you can use sudo armbian-add-overlay which compiles the overlay and places it within /boot/overlay-user This problem seems to occur every now and again in some kernel releases, please refer to here: for a solution. I would refer back to the board schematic before adjusting the dts. On the Pcduino2 and Pcduino3, the OTG micro USB passes through a small resistor rather than a fuse so causes a slight voltage drop. Just make sure that you have a good quality lead that ensures the board gets 5V but slightly over is better. sudo armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu PMIC DC-IN C.St. 22:19:42 960 MHz 0.39 14% 9% 5% 0% 0% 0% 33.7 °C 30.2 °C 5.34V 0/6^C Best of luck Ryzer

I see there is a "UART" on the front board image, but I guess it does not work for you. Check the sorroundings for possibile missing resistors, sometimes they remove some small SMD resistors to make the UART non-functional. Also note that you must use an adapter that is capable of 1.5Mbps; not all of them can reach such baud rates (AFAIR pl2303 can't, but CH301 should work)

Collabora is excited to see Monado at the heart of the new OpenXR runtime for Android XR, a major milestone for Open Source XR interoperability. View the full article