All Activity

The base device tree for the Renegade (roc-rk3328-cc) already includes a PWM2 device but armbian does not include the .dtbo to enable it. Thus, it is also unavailable through armbian-config. The Libre builds of Debian support it, but not armbian. I have copied the overlay from the Libre build of Debian for Renegade and it applies correctly on after I manually add it to the overlay directory: /boot/dtb-6.12.32-current-rockchip64/rockchip/overlay/rockchip-rk3328-pwm2.dtbo Note that as of today armbian-config is having a general issue with loading overlays via armbianEnv.txt. This can be bypassed by avoiding using armbian-config for overlays and editing armbianEnv.txt directly and adding the overlay name to the overlays= line minus the "rockchip-" prefix. FWIW - here's the overlay source: =========================== /dts-v1/; / { compatible = "libretech,roc-rk3328-cc\0rockchip,rk3328"; fragment@0 { target = <0xffffffff>; __overlay__ { status = "okay"; }; }; __fixups__ { pwm2 = "/fragment@0:target:0"; }; };

That's completely understandable. Given how long the A10 and A20 have been around, I wouldn't expect recent kernels to be thoroughly tested on them. Even from my perspective HDMI is more of a nice-to-have rather than a priority. I realize I might be an exception in this, but I prefer trying to fix issues myself rather than relying on someone else to do it. The only real barrier is my own lack of knowledge. That said, I believe I’ve firmly gotten to grips with device trees now. I acknowledge that I still have some way to go before I can confidently dig into driver development myself. I really appreciate the effort from you and others in making the build system so easy to use. Thanks to that, I’m able to apply my own fixes where needed with relatively minimal technical knowledge of the intricacies of Linux. I actually noticed the change today while browsing kernel.org. Exactly what I had in mind.

Further, I can't find any reference to an Amlogic S905M cpu. (https://en.wikipedia.org/wiki/Amlogic) In a google search, I see reports of some people saying the actual cpu is an S905L while others report having an S905X2. You might want to open up the stick to see what the actual CPU is.

That is not an Armbian build, but a third party fork of Armbian. These forums are for Armbian. You need to direct your question to the provider of the software you are testing, as we can't answer questions for third party software.

That github page tells you that the in-kernel driver is better than morrownr's driver. Have you tried that first? Search for rtw88 in the /lib/modules folder Try rebuilding armbian, find rtw88 or 8812au in the linux configuration menu and activate them.

Hello, I'm trying to get Armbian (Ubuntu 24.10 XFCE Desktop) running on a retro game stick device with the following specs: CPU: Amlogic S905M RAM: 8 GB Samsung (2x K4B4G1646B) Storage: Samsung 128 GB MicroSD (new, flashed via balenaEtcher) Ports: 1x USB-A, 1x MicroSD slot, 1x MicroUSB power (possibly supports OTG), 1x HDMI male output Original firmware: EmuELEC (working fine from factory SD card) What I tried: Flashed Armbian Ubuntu 24.10 (from debmfc GitHub) to the SD card Tried box=s905_generic in the config file Replaced dtb.img with several DTBs, including: meson-gxbb-p200.dtb meson-gxbb-p201.dtb meson-gxbb-xtmqbox.dtb Performed toothpick method to boot from SD card Green LED turns on, but: No HDMI output CPU stays cold, no signs of booting USB devices receive no power No blinking, no UART logs (I don’t have serial access yet) It feels like the CPU doesn’t even begin to initialize Linux – maybe it doesn't load the u-boot from the SD at all? Any idea what else I can try? Is there a minimal verified Armbian image known to boot on S905M-based TV sticks? Do I need to trigger multiboot somehow? Could this be a special bootloader variant? Could I use the original EmuELEC SD and inject Armbian files into it? Any help or known working image would be greatly appreciated. Thanks in advance!

Me too. I was not paying attention to this due to dealing with many non technical things in past few months and as already mentioned, those upgrades are not being tested on older boards. We simply don't have enough resources, test automation is limited - HDMI is not tested in any case. There is more or less just one main person doing general maintenance on Allwinner with occasional help of random people. 6.14 is already EOL and we just switched to 6.15 (EDGE branch), but we will probably stay on stable CURRENT branch with 6.12.y for awhile as its fairly stabilized in general across several platforms. IMO it is best to backport this patch for 6.12.y or fix whatever breaks this.

@Igor I can only guess that something has changed within the drm framework somewhere between kernel 6.6 and 6.12. After a bit of digging I did find the patch mentioned in my previous post, which I can confirm does restore HDMI functionality albiet with what appear to be minor errors. Taken from Pcduino3: ryan@pcduino3:~$ sudo dmesg | grep drm [sudo] password for ryan: [ 1.000426] sun4i-drm display-engine: bound 1e00000.display-frontend (ops 0xc0caec14) [ 1.000666] sun4i-drm display-engine: bound 1e20000.display-frontend (ops 0xc0caec14) [ 1.001260] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc0cae380) [ 1.001797] sun4i-drm display-engine: bound 1e40000.display-backend (ops 0xc0cae380) [ 1.002745] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.002787] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc0cac870) [ 1.003623] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.003671] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xc0cac870) [ 1.005703] sun4i-drm display-engine: bound 1c16000.hdmi (ops 0xc0caf610) [ 1.007882] [drm] Initialized sun4i-drm 1.0.0 for display-engine on minor 0 [ 1.068719] sun4i-drm display-engine: [drm] *ERROR* Unsupported infoframe type: 131 [ 1.068755] sun4i-drm display-engine: [drm] *ERROR* Unsupported infoframe type: 129 [ 1.126922] sun4i-drm display-engine: [drm] fb0: sun4i-drmdrmfb frame buffer device [ 4.022304] [drm] Initialized simpledrm 1.0.0 for 7e000000.framebuffer on minor 1 [ 4.150136] simple-framebuffer 7e000000.framebuffer: [drm] fb1: simpledrmdrmfb frame buffer device [ 4.537321] [drm] Initialized lima 1.1.0 for 1c40000.gpu on minor 2 [ 8.416996] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 8.783119] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 8.785117] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. kernel 6.14 already has the changes adopted so does not need to be patched. I appreciate that boards like the pcduino2 are over a decade old now and not likely to achive the same attention as something like the orange pi zero.

Did you make any progress with this? Also looking to build something with I2S.

I have noticed regression on A20, probably also on A10 few weeks ago ... but so far we haven't been able to do anything - almost no active developer have those boards. ... and Welcome!

From https://github.com/morrownr/8821au-20210708

Welcome! This question is a bit off topic here as general Armbian updates are not part of HA extension. As this is community supported hardware, stable BSP upgrades - where OS version is stored - might not be generated, while kernel and everything else is getting upgrades. tl;dr; Don't worry about this. For board related topics proceed here https://forum.armbian.com/forum/173-allwinner-sunxi/

Hey if it’s still available I will pay the shipments

Hey, @arbeiter! It shouldn't be necessary to put the device in Maskrom mode, Loader mode should be enough - you can do that by using a toothpick to activate the reset button in the 3.5 mm jack (example photo attached) before plugging the device with the USB-A-USB-A cable. For the flashing - you should run rkdeveloptool ld (to list recognized devices) and see if the box is in LOADER mode rkdeveloptool write 0 Ambian-unofficial... Here should be the latest gnome desktop verison that I compiled. Please be advised that your version is M9S and, as far as I know, the only difference is that M9 comes with Android and M9S comes with Android TV; this image hasn't been tested on M9S. Don't forget to freeze the kernel updates from armbian-config; you should be able to update the other packages normally after this. For me the box has been stable, no hangs whatsover and, as described, the VPU and the NPU work, but the GPU doesn't (that's why it's blacklisted). Haven't tried the remote nor the LCD screen.

Was this 8812au.ko in the lib/modules folder originally, or did you copy it from somewhere else?

I'm not aware of any support by mainline linux for this processor. Maybe in a few years, but in general, Amlogic doesn't work with mainline linux to get their cpu's supported, so there is unlikely to ever be any support outside android for this box.

Hi Ryzer, thanks for your response! Okay, I will be on the lookout for some updates in your branch "pcduino2-and-3-improvements" and try again. Thanks for all your efforts to keep those old boards running!

Hello! I'm new to the Armbian world! I have successfully downloaded and got my OrangePi Zero 3 working on my end, but I do not know how to do updates. I've done apt update + apt upgrade and armbian-upgrade and they went fine, but I still see V25.2.3 upon entering the SSH session. To upgrade to latest V25.5.1 I need to to something else, or maybe wait until you update, or I need a fresh reinstall? Sorry if this seems a basic question. Anyways, thanks for your contribution Igor! I can run other things along Home Assistant with this image!

Hello, Have a Helios64 - was/is running on Buster and is no longer required. If anyone is interested, just pay for the postage. I am based in UK. It also has the wire strap for the 2.5G Network issue. Available without any drives. If a new home is not found by Aug-25, will dispose into a recycling center. pls contact me by private message. **** i5Js has adopted my Helios64. , thanks *** no longer available

@Igor Just tried with the latest image on https://dl.armbian.com/rock-5b-plus/Noble_vendor_gnome. This 100% works as I had tested, so either @armbuilder has a broken flash storage or had an error while writing to the storage medium. Gnome Desktop is working too

I happen to have got a Android tv box with a s905Y5 processor. I got this by a tv subscription from a company airtel in India. I unsubscribed from the subscription and my tv box is completely useless. it asks money for watching youtube!!!. I am extremely frustrated from this approach by this company so please help me save this from getting into e-waste. From my research i found that it runs android 14 with a custom launcher which checks for the subscription and a locked down kernel/bootloader which checks for signatures before boot. I came to know these from the uart output. I also found that it is basically a customised version of this box https://www.videostrong.com/products-show/vt9201-s905y5-aiot-solution

Thank you. I also can confirm this issue on Armbian 25.5.1 Bookworm, and that the suggest workaround works. For those interested, here is a more detailed explanation of what @Lars Christian Nygård said. Create a backup of original DTB. sudo cp /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dts /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts-orig.dts Decompile the DTB for the Orange Pi 3 LTS. sudo dtc -I dtb -O dts -o /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dts /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dtb Modify the decompiled DTS file according with your favorite editor, e.g. nano or vim. sudo nano /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dts Navigate to the "spi@5011000" section and modify it. Set "status" to "okay" and add the "spidev@0" section. spi@5011000 { compatible = "allwinner,sun50i-h6-spi\0allwinner,sun8i-h3-spi"; reg = <0x5011000 0x1000>; interrupts = <0x00 0x0b 0x04>; clocks = <0x06 0x53 0x06 0x51>; clock-names = "ahb\0mod"; dmas = <0x2e 0x17 0x2e 0x17>; dma-names = "rx\0tx"; pinctrl-names = "default"; pinctrl-0 = <0x31 0x32>; resets = <0x06 0x20>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x78>; spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; Save and compile the modified DTS file. sudo dtc -I dts -O dtb /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dts -o /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dtb Remove any previously configured overlay for SPI using "armbian-config" or editing the "/boot/armbianEnv.txt" file directly. No further modifications are needed to load our new recompiled DTB, since we directly modified the base DTB. Reboot when done.

ls: unable to get access to '/boot/dtb/overlays': No such file or directory. Despite this, I attached full tree of "boot" directory. boot_dir_content.txt

Difficult to see like this, better list the overlay directory: ls /boot/dtb/overlays

I don't see such interfaces. Could you point me if one of these are suitable?