All Activity

With the aid of Claude.Ai .. v26.5.1 for Rock 5A running Armbian Linux 6.18.35-current-rockchip64 Starting Point is the Radxa DTS needed to add an include ... #include <dt-bindings/soc/rockchip,vop2.h> Modified this section. Changed the compatible string, added the power-supply key and fixed the active area (width and height) dsi0_panel: panel@0 { status = "okay"; compatible = "panel-dsi-simple"; reg = <0>; backlight = <&dsi0_backlight>; power-supply = <&vcc_lcd_mipi0>; vdd-supply = <&vcc_lcd_mipi0>; vccio-supply = <&vcc_1v8_s0>; reset-gpios = <&gpio3 RK_PC1 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&dsi0_lcd_rst_gpio>; prepare-delay-ms = <120>; reset-delay-ms = <120>; init-delay-ms = <120>; enable-delay-ms = <100>; disable-delay-ms = <120>; unprepare-delay-ms = <120>; width-mm = <135>; height-mm = <217>; Modified this section (renamed the endpoint) &mipi_dcphy0 { status = "okay"; }; &route_dsi0 { status = "okay"; connect = <&vp3_out_dsi0>; }; &dsi0_in_vp2 { status = "disabled"; }; &dsi0_in_vp3 { status = "okay"; }; to simply &mipidcphy0 { status = "okay"; }; Added this section / endpoint &vp3 { #address-cells = <1>; #size-cells = <0>; vp3_out_dsi0: endpoint@ROCKCHIP_VOP2_EP_MIPI0 { reg = <ROCKCHIP_VOP2_EP_MIPI0>; remote-endpoint = <&dsi0_in_vp3>; }; }; And then completely redid the i2c touch controller section to be &i2c5 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i2c5m2_xfer>; clock-frequency = <400000>; #address-cells = <1>; #size-cells = <0>; gt9xx: gt9271@14 { status = "okay"; compatible = "goodix,gt9271"; reg = <0x14>; pinctrl-names = "default"; pinctrl-0 = <&gt9xx_gpio>; interrupt-parent = <&gpio3>; interrupts = <RK_PC6 IRQ_TYPE_EDGE_FALLING>; irq-gpios = <&gpio3 RK_PC6 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio3 RK_PC5 GPIO_ACTIVE_HIGH>; touchscreen-size-x = <1200>; touchscreen-size-y = <1920>; AVDD28-supply = <&vcc_tp>; VDDIO-supply = <&vcc_tp>; }; Final DTS is attached. Worked for 6.18.53. I had Claude write a bash script to pull everything and make the required changes and compile the device tree and can make it available, if needed. rock-5a-radxa-display-10fhd.dts

@Guido Giuntoli You are a candidate to test the new feature. https://github.com/armbian/build/pull/10113

I successfully got the Radxa Display10FHD display working this weekend on Armbian 26.5.1 (Gnome) after extensive Claude AI help in fixing default Radxa DTS. I'll do a separate post / topic for that but it involved refactoring some of the endpoints, adding a missing header and fixing the touchscreen driver name. I used Claude and it was really helpful.

nevermind, it can infact run armbian, but only by booting using a usb stick(change root drive using bootargs) only. The fx6 still have an un-bypassable secure boot, so booting using usb stick is the only option here, also it works great with the banana pi m4's firmware

No. There is basically no open source resources going to the amlogic CPUs these days. Generally Amlogic doesn't support or help open source development, so most developers have moved on to other platforms (rockchip and allwinner) that are somewhat more supportive.

split into new topic for the reason above.

There is no proof it is the same problem. As I told you in topic: your Ultra does not have the same SoC as the original/normal OPi5. So this posting in the wrong group and is getting annoying. You should focus on RK3588, not the RK3588S Also the Ultra is community support only, so you are part of that. Make sure you understand installing latest kernels and U-Boot etc yourself manually and also building Armbian yourself. From latest other post here, I conclude that the 7.1 kernel at least can show some sign of life from NVME. Xunlong dumps HW on the market at a high rate, you cannot trust or build on that reliably. Check everything, even their 'official' image, where do the sources come from etc. My perception is that they just clone a certain old version of the Armbian build system, then make it work, likely only boot from SD-card and then they go on the next HW/marketing/vaporware.

Sorry Ryzer, I missed your last post. For the WiFi, I use morrow_nr drivers, it is a lengthy process to compile the driver, but it works. This is the wifi dongle, using RTL8812BU: https://www.amazon.com.au/Adapter-（AC1200-867Mbps-WPS，Support-10-6-10-15/dp/B09BNJPQYT What I also found is that a significant change has happened between kernel 5 and 6 with regards to OTG. I tried to lay with that a bit, but I am out of my depth and didn't get anywhere with it: &usbotg_hs { compatible = "st,stm32mp15-hsotg", "snps,dwc2"; dr_mode = "otg"; usb-role-switch; <------ this is the major change between kernel 5 and 6 wrt OTG /* Other DWC2 specific properties and PHY configuration / ... }; Then on the user side, setting up the gadget requires the following: To switch to device mode echo "device" > /sys/class/usb_role/.dwc2-role-switch/role To switch to host mode echo "host" > /sys/class/usb_role/*.dwc2-role-switch/role

The same problem on the Pi 5 Ultra, has anyone managed to solve this problem? Or is this a global bug for all Orange devices?

@y52 very cool!

Hello to regular contributors and everybody who are interested in this issue! I am late to the thread, as I had to decommission my production setup based on Espressobin V5 before trying everything out. Finally I've completed Physical-to-Virtual migration using QEMU and made board available for this new experience. @bschnei made a great job and his developments are community available. It was also worth for me making my findings accessible for general public thus improving Espressobin support. I forked @bschnei repo https://github.com/bschnei/ebu-bootloader to my Github https://github.com/quiseleve/espressobin-bootloader and made several changes to build bootloaders for Espressobin V5 and V7. Here are the final changes brought to @bschnei repo : root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git remote add upstream https://github.com/bschnei/ebu-bootloader.git root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git fetch upstream From https://github.com/bschnei/ebu-bootloader * [new branch] main -> upstream/main root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git diff --stat upstream/main...main .github/workflows/build.yml | 92 ++++++++++++++++++++++++++++++++++++++++++--------------------------------- Makefile | 2 ++ patches/0001-fix-tfa-fip-build-behavior.patch | 36 +++++++++++++++++++++++++++++ 3 files changed, 90 insertions(+), 40 deletions(-) This allowed building bootload firmware directly in Github's Workflow and trying them out over UART 1st before flashing it to onboard SPi. ./mox-imager -D /dev/ttyUSB0 -b 3000000 -E flash-image-v5_2GB.CPU_1000_DDR_800.bin Although Workflow run builds both v5 and v7 variants, I tested 2Gb RAM v5 board, as my 1Gb v7 is currently in production, but there is a high confidence level, that v7 works as well. DDR_TOPOLOGY variable used for my specific v5 motherboard : Memory Type: DDR3 Total Capacity: 2 GB Bus Width: 16-bit Chip Selects (CS): 2 (Dual CS) It is worth saying that I built initially the 1.2GHz bootloader, but it appeared worthless, as my physical silicon turned out to be limited to 1GHz only. I found it by retrieving a 32-bit hex string for v5 board : => md 0xd0012604 1 d0012604: 19896301 .c.. => This hex string gives us the definitive answers we need. In the Marvell Armada 3720 architecture, this specific register reads from the factory OTP (One-Time Programmable) fuses. The lower bits define the chip's official Speed Bin Index: 0 = 800 MHz Maximum 1 = 1000 MHz (1.0 GHz) Maximum 2 = 1200 MHz (1.2 GHz) Maximum Because my board register ends in 01, my specific SoC is officially rated by the factory for a maximum clock speed of 1000 MHz (1.0 GHz). This completely explains why the WTMI secure firmware threw the invalid voltage error when I forced a 1.2 GHz build. The chip physically lacks the factory-fused voltage calibration profile for the 1.2 GHz tier because it wasn't born as a 1.2 GHz chip. Thus I decided changing the Build Target to 1.0 GHz. More discussions could be found here as well : I've also built Armbian-unofficial 26.5.2 sid image to assess overall compatibility. Here is an excerpt from initial boot logs directly from the bootloader initiation : TIM-1.0 mv_ddr-devel-g7bcb9dc DDR3 16b 2GB 2CS WTMI-devel-18.12.1-f423ac6 WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V Setting clocks: CPU 1000 MHz, DDR 800 MHz CZ.NIC's Armada 3720 Secure Firmware v2024.04.15 (Jul 9 2026 20:33:31) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):sandbox/v2.14 NOTICE: BL1: Built : 20:33:33, Jul 9 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):sandbox/v2.14 NOTICE: BL2: Built : 20:33:35, Jul 9 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):sandbox/v2.14 NOTICE: BL31: Built : 20:33:36, Jul 9 2026 U-Boot 2026.04-dirty (Jul 09 2026 - 20:32:03 +0000) DRAM: 2 GiB Core: 48 devices, 24 uclasses, devicetree: separate WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 Hit any key to stop autoboot: 0 MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1664 bytes read in 25 ms (64.5 KiB/s) ## Executing script at 06d00000 144 bytes read in 19 ms (6.8 KiB/s) 28134196 bytes read in 1702 ms (15.8 MiB/s) Wrong Image Type for bootm command ERROR -91: can't get kernel image! 37059072 bytes read in 2231 ms (15.8 MiB/s) 18537158 bytes read in 1121 ms (15.8 MiB/s) 12062 bytes read in 35 ms (335.9 KiB/s) ## Loading init Ramdisk from Legacy Image at 0a000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 18537094 Bytes = 17.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Working FDT set to 6f00000 Loading Ramdisk to 7d940000, end 7eaeda86 ... OK Loading Device Tree to 000000007d93a000, end 000000007d93ff1d ... OK Working FDT set to 7d93a000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 261.1-2 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.42.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 armbi_root: clean, 28918/949664 files, 425190/3849216 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian-unofficial 26.5.2 sid! [ OK ] Created slice system-getty.slice - Slice /system/getty. [ OK ] Created slice system-modprobe.slice - Slice /system/modprobe. [ OK ] Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty. [ OK ] Created slice user.slice - User and Session Slice. [ OK ] Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch. [ OK ] Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch. [ OK ] Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point. Expecting device dev-ttyMV0.device - /dev/ttyMV0... [ OK ] Reached target imports.target - Image Downloads. [ OK ] Reached target remote-fs.target - Remote File Systems. [ OK ] Reached target slices.target - Slice Units. [ OK ] Reached target swap.target - Swaps. [ OK ] Listening on syslog.socket - Syslog Socket. [ OK ] Listening on systemd-ask-password.socket - Query the User Interactively for a Password. [ OK ] Listening on systemd-creds.socket - Credential Encryption/Decryption. [ OK ] Listening on systemd-factory-reset.socket - Factory Reset Management. [ OK ] Listening on systemd-hostnamed.socket - Hostname Service Socket. -- Boot 3e598d120dc346829e12f836344429a1 -- Jul 11 00:11:05 espressobin kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034] Jul 11 00:11:05 espressobin kernel: Linux version 6.12.95-current-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0> Jul 11 00:11:05 espressobin kernel: 5:185m5:185mKASLR disabled due to lack of seed Jul 11 00:11:05 espressobin kernel: Machine model: Globalscale Marvell ESPRESSOBin Board Jul 11 00:11:05 espressobin kernel: efi: UEFI not found. .. Jul 11 00:11:05 espressobin kernel: armada_37xx_wdt d0008300.watchdog: Initial timeout 120 sec Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: host bridge /soc/pcie@d0070000 ranges: Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: MEM 0x00e8000000..0x00efefffff -> 0x00e8000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: IO 0x00efff0000..0x00efffffff -> 0x0000000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: issuing PERST via reset GPIO for 10ms Jul 11 00:11:05 espressobin kernel: mvneta d0030000.ethernet end0: renamed from eth0 .... This bootloader seems to deliver many if not all of its promises to name few of them: cpu frequency scaling is operational : root@espressobin:~# cpupower frequency-info analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 1000 us hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 250 MHz (asserted by call to kernel) Entropy and random number generation (RNG) issue seems to have been resolved as bschnei's ebu-bootloader fork explicitly includes patches to fix this. The ebu-bootloader patches bypass the OS entirely and tackle the problem before Linux even starts. When Linux kernel boots, it immediately detects this perfect cryptographic seed provided by U-Boot and uses it to instantly initialize the OS-level Cryptographic Random Number Generator (CRNG). Here are my kernel ring buffer timestamps: root@espressobin:~# dmesg | grep -E "crng|random" [ 11.785705] systemd[1]: Starting systemd-random-seed.service - Load/Save OS Random Seed... [ 13.071384] random: crng init done [ 13.398576] systemd[1]: Finished systemd-random-seed.service - Load/Save OS Random Seed. The bootloader and kernel working together fixed the entropy pool in exactly 13.07 seconds from the moment the Linux kernel started executing. Because crng init done happened before the systemd service even finished writing to the disk, it proves the kernel didn't just rely on slow user-space disk jitter. The hardware security engine initialized almost immediately. Because the ebu-bootloader fork compiled correctly patches, the underlying Trusted Firmware-A (TF-A) and the secure processor (WTMI-devel), the hardware crypto mailboxes are wide open and working perfectly the moment Linux asks for them. You don't even need haveged or any software workarounds. Your hardware is resolving its own entropy natively in just over a second from user-space initialization! U-Boot UEFI Support is out of the box as well. I am booting seemlessly both legacy OS (from my old production setup) as well as a new OS build which I used for this testbed root@espressobin:~# cat /etc/debian_version forky/sid root@espressobin:~# uname -a Linux espressobinv5 6.12.95-current-mvebu64 #1 SMP PREEMPT Sat Jul 4 11:43:36 UTC 2026 aarch64 GNU/Linux

this post started 2023 & some engineers told that armbian does not support S905W2 . its 2026. ... did someone try ? for s905w2 does this rom well work? please tell me "YES" bc i need a armbian for S905w2 @SteeMan @Devmfc

Hey, thanks for the PSU suggestion! I actually tested the power theory by stripping all USB accessories (dongles, hubs, keyboard) and running just the board + HDMI, but it still drops to initramfs. I also know the PSU and hardware are 100% good because DietPi boots perfectly on this exact same setup. I dug around in the initramfs shell and ran blkid. Here is the output: /dev/mmcblk1: PTUUID="[uuid]" PTTYPE="gpt" The issue: The kernel sees the raw SD card, but it's completely blind to the partitions (p1, p2). It looks like this specific build might be missing the ext4 drivers in the initramfs, which is why it can't find the UUID to mount the rootfs. For the devs, here is the exact image causing the issue: Armbian_26.2.1_Radxa-zero3_trixie_vendor_6.1.115_minimal.img (Flashed via BalenaEtcher, verified successfully, and ignored all Windows format prompts). I'm switching over to the official Radxa Debian image for now so I can finally get my onboard AIC8800 Wi-Fi working, but I wanted to drop these debug notes here in case this is a regression in the recent build.

It's just an old armhf "armV7" kind of thing, but thanks to it will work for more Ai content.

It's and old Allwinner chip, ARMv7-based. GPU is PowerVR SGX544MP1, which is not supported in Mesa and will not work in Armbian. Wi-Fi is AP6212, a Broadcom/Synaptics SYN43436S chip, should work fine. Armbian build for M3 is community-supported, by @AaronNGray. Maybe they'll shed more light on this board.

The other usual thing is then PSU. So also maybe try a different one. Else I cannot really help you, not being able to find rootfs can have pure software cause, but is unlikely if other people can run it successfully. I wish I had bought this SBC a year ago, but I didn't and now they are sold out where I looked, so cannot see If I can reproduce the problem. You need to look in more detail yourself, like connecting serial debug console and setting loglevel to 7 in armbianEnv.txt. Also post which exact image is (sha256sum), so other people can try the same thing.

I also thought the same so i was using a sandisk 32 gb sd card so i switched to samsung 64 gb one but same issue in it also, i think the problem is something else.

If it worked once and now not anymore, it might be the SD-card that is the problem. It might be a as bad that it is a fake SD-card.

I've also encountered this. SATA fails on some drives but not others. Possibly related to how much power they draw.

I've added a ton of info. I can provide logs if needed. This is a bug with Armbian and/or uboot. I believe I've traced it to the preboot code, so that would be uboot? https://github.com/armbian/build/issues/9532 https://lists.denx.de/pipermail/u-boot/2026-July/624426.html I have two versions of Armbian, one works and one doesn't: Armbian_26.5.1_Odroidhc4_trixie_current_6.18.33_minimal.img.xz - fails Armbian_25.8.1_Odroidhc4_bookworm_current_6.12.41_minimal.img.xz - works

Moved post to the correct forum section

Hello Im a begginer and dont know Linux. I have a tv box : enyBox x98q Cpu amlogic s905w2 2g ram 16g rom My need to install MetaTrader5 on linux on this tv box. I downloaded both files on site this link: debian 13 ubuntu 26.04 I need to learn the install way by watching a video clip. I request you for making it

Does anyone have an image version 24.11.0-trunk.351? It seems they have been purged. Also, what is the latest working image for jetson nano?

Same thing is happeing with me at first it booted correctly with armbian imager then suddenly it crashed and after that whenever i tried to flash it using armbian imgaer its giving error of initramfs , btw iam using Radxa zero 3w , any solution or any step iam doing wrong , i have tried it with different imager but same problem.

Hello @4A studio ,I'm sorry for the late reply. I accidentally installed the image to a partition on the Micro SD card using the `dd` command (of=/dev/sd*2). I eventually resolved the issue by using the correct `dd` command (of=/dev/sd*).