Active threads

apt upgrade, after update armbian stops loading

Ok, try with this dts file /boot/overlay-user/bt_enable_clean.dts /dts-v1/; /plugin/; &pio { bt_en_pin: bt_en_pin { pins = "PH1"; // GPIO225 function = "gpio_out"; bias-pull-up; drive-strength = <20>; output-high; }; }; Compile it: sudo armbian-add-overlay /boot/overlay-user/bt_enable_clean.dts and enable it in /boot/armbianEnv.txt user_overlays=bt_enable_clean Then see if better on reboot.

Do you have idea with chip S928X-K in device Ugoos SK1 ? if you have Rom please share for me thank you so much

Here is the login prompt that failed: And about my SD Card, it is just a class 10 SanDisk Ultra card but does not say A1 anywhere. So next I tried the pre-built image for Cubieboard and it booted too! This is more stable than before, but as soon as I try to do downloads or file operations, I start seeing similar page state or mmc errors. I think this might be related to RAM frequencies as you mentioned. Is there a way I can change DRAM clock on a system after it boots? Adding to that, is there a way I can enable the display on this after it boots, or install drivers using an overlay? That would be great to test things out. I am trying to build again but it keeps failing at the same stage as last time, even after pulling the latest version. I think I should try either docker or a VM to build this, because it does not seem to be working on WSL. Thanks, Shivam

Thanks for your reply. You're right — the image I initially used came from the debmfc GitHub fork. I understand now that it's not officially supported by Armbian. I now tried the image from Armbian itself: Armbian 25.8.0-trunk.90 Bookworm Gnome However, I wanted to follow up on the CPU identification part, as you mentioned uncertainty about the S905M. I’ve opened up the stick and inspected the hardware. The SoC is clearly labeled as: Amlogic S905M Quad-Core Additionally: RAM: 2x Samsung K4B4G1646B (total 8GB DDR3) Storage: no internal NAND/eMMC, boots entirely from MicroSD Original SD card runs EmuELEC out-of-the-box I’ve attached pictures of the board below (top and bottom views), including close-ups of the SoC and RAM chips and screenshots of the partitions of the normal EMUELEC Emulator. I also tested your suggestion about verifying the CPU. It is definitely not an S905L or S905X2. This unit appears to be an Amlogic S905M I now tried the image from Armbian itself: Armbian 25.8.0-trunk.90 Bookworm Gnome and it still does not give any display output. I opened up the Game Stick and on the CPU iteself it says "@mlogic S905M

A little typo in the commands: patch -b sun50i-h6-orangepi-3-lts.dtso opi3lts-dtb.patch Should be: patch -b sun50i-h6-orangepi-3-lts.dts opi3lts-dtb.patch it should be .dts and not .dtso, its'n not an overlay. Sorry if that confused anyone.

Can you help me install a unlocked version of android.

Unable to reproduce. Probably date and time is out of sync. Edit: aha, this is / was the problem: https://github.com/armbian/build/commit/aa5526a9189097b87ada0784cff61bda85e46609 Which means next week community build will have this auto-fixed.

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.

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

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.

@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

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.

Just plugged a M.2 M key to E key adapter with an Intel AX200 iwlwifi (installed the firmware) booted up and Wifi 6 is going without using a USB port. My project is one step closer!!! Just have to get that last USB-C port working.

Description fix build error with new compiler update uboot to v2024.04 ras314: fix sd-card regulator error How Has This Been Tested? [x] Build and Boot CLI/Gnome image on mba8mp [x] Build and Boot CLI/Gnome image on mba8mp-ras314 Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings View the full article

Sounds good, thank you Werner! If anyone wants to share their favorite boards then please go ahead too 🙂

No

Description Fix the peripheral aliases to ensure consistent allocation when enabled, so that kernel assignment matches the numbering convention of the SOC. This targets the Allwinner A10 and A20 and ensures, that for example if enabling UART2 exposes it correctly in userspace as ttyS2 rather than dynamically assigning it to the first avaliable ttySx slot. Secondly spidev overlays creates an instance of spidevX.Y based on the bus specified with armbianEnv.txt however it does not correctly configure the corresponding pins into spi mode. To resolve this the individual spi bus overlays have been include in the makefile. The desired bus must be enabled alongside spidev or seperately if using another spi device driver in order to be functional. I have also corrected the A10 spi overlays where they incorrectly target the A20. How Has This Been Tested? Built and tested on Pcduino 2 running 6.12.23-current-sunxi Built and tested on Pcduino 3 running 6.14.5-edge sunxi Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] My changes generate no new warnings View the full article

hi , can i use these image to boot armbian to my s805X Amlogic soc.

Hi, If you are having trouble sourcing a proper serial dongle, you could also try to set (or cap) the serial console's baudrate yourself in armbianEnv.txt. Use/replace the following: console=comfort extraargs=console=ttyS2,115200 earlyprintk=ttyS2,115200 This should prevent your bootscript from setting the kernel's serial baudrate to 1M5 and at least give you some kernel logging during booting. Not sure if the login prompt will follow the same baudrate, as `getty` (or one of it's variants) might use different default settings. Groetjes,

@maka into this file: https://github.com/hqnicolas/ubuntu-rockchip-joshua/blob/main/config/suites/noble.sh it makes refference to the kernel repo: https://github.com/hqnicolas/linux-rockchip that contains the dts file: https://github.com/hqnicolas/linux-rockchip/blob/arm64--dts--rockchip--add-rk3566-h96max-v56/arch/arm64/boot/dts/rockchip/rk3566-h96max-v56.dts That have the USB setup: &usb2phy0 { status = "okay"; }; &usb2phy1 { status = "disabled"; }; &usb_host0_ehci { status = "disabled"; }; &usb_host0_ohci { status = "disabled"; }; &usb_host1_ehci { status = "disabled"; }; &usb_host1_ohci { status = "disabled"; }; &usbdrd_dwc3 { dr_mode = "host"; extcon = <&usb2phy0>; status = "okay"; }; &usbdrd30 { status = "okay"; }; &usbhost_dwc3 { status = "okay"; }; &usbhost30 { status = "okay"; }; &pinctrl { usb { vcc5v0_otg_en: vcc5v0-otg-en { rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>; }; }; There Are 3 Branches:

Does anyone know if this will be solved in new releases or should we use an old kernel 6.6.75 as alternative? Then the next question : can we avoid an update of the kernel when using the apt command upgrade? Already found the solution: Use armbian-config and disable upgrade of firmware