Active threads

that is why i am confused, I used the one image from here (armbian.com) https://www.armbian.com/odroid-xu4/ edit: what happens if the SBC starts the first time and you cut the power before hooking up with ssh - does it fall back to other credentials?

Why are you expecting this to work?

@kisgezenguz you're welcome. You can check the UART RX/TX paths with the multimeter in diode/continuity mode and checking the continuity against RX (or TX) and the various SMD components. But anyway, if you read 3.3v on all the UART pins, I can guess there are three other hypothesis: * the UART RX/TX pins are correctly connected, but not to the usual debug UART. rk3399 has several uarts, so perhaps that exposed UART is not the same configured in software to be used to log the debug. * MCU_D makes me think that UART is used for the little MCU embedded into rk3399. rk3399 has two small Cortex-M0 cores for very low power tasks. So again that UART is not what you are looking for. * the RX/TX pins are just shorted to high voltage level/pulled ups on purpose (improbable) edit: I just paid attention to the schematic you posted, but it looks it does not match what you've discovered: the schematic says you should read 5.0v on the VCC pin, instead you read 3.3v. Perhaps that MCU_D connector it's definitely not the one you are looking for.

I am asking if someone can refer me somewhere so I can update my current orangepi zero 3 hardware to bananpi m4 zero hardware.

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/) + ge-proton10-29 (https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton10-29) (GE-proton is more likely to be segment fault-proof than other wine-proton versions) + dgVoodoo2 (https://github.com/dege-diosg/dgVoodoo2/releases) + DXVK-stripped v2.7.1 ~30fps@720p (high settings - the lowest settings in game) box64 environment variables: Crysis 2 Maximum Edition

Just tried stock DietPI & Armbian builds using both current-rockchip64 and edge-rockchip64 utilizing U-Boot - thus completely eliminating the EDK2 UEFI factor. None handle multichannel audio correctly so I guess there is something still not mature enough in mainline/upstream for this. kernel-rk35xx-vendor:6.1.115 works perfectly even with EDK2 UEFI. Perhaps the Armbian devs need to take a look at what LibreELEC is doing as they managed to get it working in their mainline/upstream kernels.

You would just burn your downloaded image file to any USB storage, just like you would to an SD card (i.e. plug the USB storage into another device and burn the image to the storage)

I've setup an Armbian build environment that was able to build a Rock-S0, trixie, minimal image. Using the patch for the Rock-S0 also rk3308b based, as a basis, I would like to create a sv06-Ace patch using the rk-kernel.dts that I managed to pull from the OEM SV06 Ace firmware. If I get a working Armbian image for the SV06, Mainline klipper should be doable. Can someone point me to the documentation on howto do this. rk-kernel.dts

With a lot of trial and error I figured out the issue but not the cause. This seems to only effect HEVC (x265) videos when drm is successfully enabled with MPV from this repository. If I try a different player, they play fine but no hardware acceleration. If I encode the videos to x264 they play but hardware acceleration fails with the following error [ffmpeg/video] h264: v4l2_request_probe_video_device: set controls failed. Invalid argument (22) The issue is the width of the video. Outside of certain ranges it will display a black video (audio works). It doesn't seem to matter what the height is set to. Eg) 704x480, 704x960 image is displayed. 706x480, 706x960 black screen The ranges go for 14 pixels and each range is separated by 50 pixels. eg) widths in the range of 690 to 704 display an image. Widths between 706 and 752 display a black screen. 754 to 768 display an image. It's a strange one.... Here is a list of ranges that work. Any widths outside of these ranges produces a black screen. It only goes up to 1984 but I'm sure the same rules would apply above this value.

PREEMPT_RT is fully merged in mainline Linux as of 2024 (https://en.wikipedia.org/wiki/PREEMPT_RT).

Here is the updated image with Wifi and EMMC boot https://github.com/sicXnull/armbian-build/releases/download/mxqpro/Armbian-unofficial_26.02.0-trunk_Mxqpro-h313_trixie_current_6.12.74_cinnamon_desktop.img.xz

I don't know, perhaps the author knows. Try. If it doesn't work, then fe's wiki is misleading.

Please read the FAQ and installation instructions linked on the download page. https://www.armbian.com/amlogic-s9xx-tv-box/

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 drop. 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 😁

Hello, I would like to use Armbian on control hub too but without disassembling it. I tried latest renegade image and usb and internet were not working. What is exactly everything I need to change in the image to make the usb at least work? I tried enabling the rk3318-box-led-conf3 in some file I forgot but it did not work, maybe else more needed or I did it wrong. I would be very grateful if you could write what I need to change! I do not want to disassemble since it's legality in FTC rules is ambigous for me.

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.

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?