Active threads

Link Star H68K is, according to multiple sources, exactly the same as Hinlink H68K. But that's not the problem (yet). I'd been using an old version of RKDevTool (2.84 IIRC) which was unable to load the .img file from the Armbian site, but uninformative as to the nature of the problem. Updating to RKDevTool 3.37 at least yielded an error message when attempting to load the image: Googling this suggests a corrupted download (not the problem here, the SHA sum matches) or a raw .img format rather than the packed .img format expected by RKDevTool. So I compiled an image according to the Armbian Build Framework instructions. Same error message. More Googling suggests that a couple of Linux CLI utilities, upgrade_tool or rkdeveloptool, may be able to flash a raw image to the board's EMMC. More later...

After boot, check systemctl status easy-eai-nano-bcmdhd.service --no-pager journalctl -u easy-eai-nano-bcmdhd.service -b --no-pager ls -l /lib/firmware/fw_bcm43455c0_ag.bin /lib/firmware/nvram_ap6255.txt dmesg | grep -Ei 'bcmdhd|dhd|4345|ap6255|firmware|nvram|wlan|sdio' iw dev rfkill list tr -d '\0' </proc/device-tree/wireless-wlan/wifi_chip_type; echo dmesg | grep -Ei 'rfkill_wlan|bcmdhd|dhd|4345|ap6255|firmware|nvram|wlan' lsmod | grep -E 'bcmdhd|dhd_static|rfkill' iw dev rfkill list modinfo bcmdhd_sdio cat /etc/modprobe.d/bcmdhd-easy-eai-nano.conf dmesg | grep -Ei 'bcmdhd|dhd|43430|43438|ap6212|firmware|nvram|wlan' iw dev rfkill list

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.

Hi @Nick A — great work on these builds, I've been testing both your BSP (v0.6.4, kernel 6.6.98) and Mainline (V0.1, kernel 6.18.19) images on a Cubie A7Z with a custom carrier board. Both work well for general use. I've been trying to get a W5500 SPI-to-Ethernet chip working on SPI2 and ran into a consistent issue across both kernels that might be worth looking at. Issue: sunxi-spi-ng child device never gets probed The SPI2 controller itself initialises correctly on both kernels: sunxi-spi-ng 2542000.spi: probe success (Version 2.5.4) But the child device (spi2.0) never gets a driver bound to it. The w5100-spi driver is loaded, the modalias matches (spi:w5500), fw_devlink=off is set, yet: echo spi2.0 | tee /sys/bus/spi/drivers/w5100/bind → No such device echo spi2.0 | tee /sys/bus/spi/drivers_probe → accepted, no effect, zero dmesg output Dynamic debug enabled (module w5100 +p) → zero probe activity This reproduces on: Radxa BSP kernel 5.15.147-21-a733 (official r6 image) Your BSP build kernel 6.6.98 Your Mainline build kernel 6.18.19 All three use the same spi-sunxi-ng.ko / spi_sunxi_ng driver (same allwinner,sunxi-spi-v1.3 compatible string). Hardware confirmed good: the same W5500 chip on the same physical pins works perfectly when an ESP32-S3 is plugged in instead — DHCP, real network data, everything. Raw spidev access on the Radxa also reads correct W5500 registers. The bug is specifically in sunxi-spi-ng's child device registration preventing any driver from binding. Overlay used: dts /dts-v1/; /plugin/; &spi2 { status = "okay"; sunxi,spi-bus-mode = <1>; sunxi,spi-cs-mode = <0>; eth0: ethernet@0 { compatible = "wiznet,w5500"; reg = <0>; spi-max-frequency = <20000000>; }; }; Note: sunxi,spi-bus-mode = <0> is rejected at probe time with error -22 ("unsupport hw bus mode 0x0"), so <1> is the only accepted value. Has anyone else seen this? Is there a known workaround for getting SPI child devices to bind under sunxi-spi-ng on A733?

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

@erebus041 were you able to install Armbian on the TV box?

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.

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

@y52 very cool!

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

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

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?

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*).

@bedna Thanks for the pointers, I'll try tonight or tomorrow. And yes, my plan was to set up a swap file on the SSD. @SteeMan I don't know if I'm doing something else wrong, but on my /etc/default/armbian-zram-config I have ENABLED=false and SWAP=false, but I keep seeing the swap mounted on lsblk and listed on htop

Similar quick test here: N100 with PCIe ethernt and wifi HW, already a br0 with enslaved ethernet, I set up a working hostapd.conf, enabled hostapd.service and added /etc/systemd/network/22-wlp2s0.network [Match] Name=wlp2s0 [Network] Bridge=br0 ConfigureWithoutCarrier=yes Then reboot and properly working AP. Is Opensuse Tumbleweed. But it is rather 'static', not as flexible/dynamic as with NM. For example, if I do networkctl down wlp2s0 ; sleep 30 ; networkctl up wlp2s0 the AP still works, but network list shows failed for wlp2s0 I though maybe it has to do with the fact that Tumbleweed has no sysV compatibility anymore (folder /etc/init.d/ is not there), so no option that something goes wrong potentially due to some sync issues, but I think I cannot draw that conclusion. Quick check shows no relation between hostapd.service and systemd-networkd, but it is much more extensive than for debian13 for sure.

It has been offically supported. Thanks! https://armbian.com/boards/norco-emb-3531

This should be specified down to just 2 things: Armbian U-Boot package and kernel package. The DTB package is redundant as the .dtb file is in the kernel package. For more low-level tests, I usually rename boot.scr and use manual extlinux, so easy to select a certain kernel+initrd+dtb(o). This also works for example with Opensuse Tumbleweed as userspace although (Wayland KDE ) GUI not anymore with vendor 6.1.115. For just standard Ext4 rootfs, note that multiple kernels is automatically handled by standard Debian package u-boot-menu (see its config in /etc/default/u-boot).

Hi @Kwiboo and Armbian rk35xx maintainers, I'm hitting a boot-time eMMC reliability issue on NanoPi R76S with the current Armbian U-Boot 2026.04 build, and the community-known workaround from OpenWrt PR #23520 breaks kernel boot completely in our Armbian environment. Sharing detailed reproduction and requesting guidance. ## Setup - Board: NanoPi R76S (RK3576), 4GB LPDDR5, 64GB Hynix eMMC (hC8aP, manfid 0x000090) - Armbian build: derived from 26.5.1, `linux-u-boot-nanopi-r76s-vendor 26.5.1` - U-Boot: 2026.04_armbian-2026.04-S88dc-P3cfe-H30d2-V3c1d-Bd0d2-R448a - Kernel: 6.1.115-vendor-rk35xx (Armbian rk35xx vendor kernel) - BL31: v2.3 fwver v1.20 ## Baseline Symptom (Reproducible ~50%) `sudo reboot` from Linux → SPL/BL31/U-Boot proper OK → boot.scr loads (255 B) → first `ext4load` of kernel Image fails with `fs_devread read error - block`. Second `ext4load` also fails, block layer reports `No partition table - mmc 0`. Reproduction across both warm reboot and cold power cycle. Matches OpenWrt issue #23491 exactly. Interestingly `mmc rescan` in U-Boot prompt re-reads mmc info (58.2 GiB Hynix detected, partition table intact) but subsequent `boot` command still fails — suggesting U-Boot driver leaves stale state that even a manual rescan cannot clear. ## Attempted Workarounds (All Failed in Our Environment) ### v1: 26 MHz variant (aggressive) - U-Boot embedded DT `mmc@2a330000`: dropped `cap-mmc-highspeed`, `mmc-hs400-1_8v`, `mmc-hs400-enhanced-strobe`; set `max-frequency=<26000000>` - Kernel DT overlay (same node): same property removal + 26 MHz - Result: `Starting kernel ...` reached, then **immediate hang, no dmesg**. ### v2: OpenWrt PR #23520 exact patch (52 MHz, U-Boot only) - U-Boot DT: kept `cap-mmc-highspeed`, removed only `mmc-hs400-1_8v` and `mmc-hs400-enhanced-strobe`; set `max-frequency=<52000000>` (52 MHz HS) - Kernel DT: untouched (HS400ES) - Result: U-Boot loads kernel at 44.5 MiB/s (HS speed confirmed), reaches `Starting kernel ...`, then **hang, no dmesg**. ### v3: Symmetric 52 MHz on both U-Boot and kernel DT - U-Boot DT: same as v2 - Kernel DT overlay: removed HS400 properties + 52 MHz cap - Result: identical hang after `Starting kernel ...`. Observation: **any modification to U-Boot's embedded DT for mmc@2a330000 appears to make the Armbian vendor kernel silently fail before earlycon initialization.** The stock Armbian U-Boot + stock kernel DT combination boots kernel reliably (log flushes normally), but exhibits the ~50% warm-reboot bug. Rolling back U-Boot to the original (via slot B rootfs `u-boot.itb`) restores kernel boot immediately. ## Questions 1. Has anyone successfully applied OpenWrt PR #23520's workaround (or any variant) to Armbian's vendor kernel on RK3576? If so, what was the specific property combination? 2. Is this a known incompatibility between the mainline U-Boot mmc probe path and the Armbian rk35xx vendor kernel's dw_mshc driver? The Rockchip PSCI handoff seems to fail silently before console_init. 3. Would upgrading to U-Boot 2026.07 (just released) help? My search showed zero mmc/sdhci commits in v2026.04..v2026.07 range for rockchip. Am I missing a Karlman patch series that isn't yet in Armbian's fork? 4. Any suggested next step: (a) chase FriendlyElec BSP U-Boot behavior, (b) patch the vendor kernel's dw_mshc probe to handle inherited controller state, or (c) accept as known-limitation until Armbian moves to kernel 6.6+? 5. If (b), which specific probe/reset path in `drivers/mmc/host/dw_mmc-rockchip.c` or `sdhci-of-dwcmshc.c` should we audit? Any references to similar rk3588 handoff issues that were resolved? Full boot logs (successful, failed variants v1/v2/v3, rollback recovery) available on request. Willing to test patches against test board and report back with UART logs. Thanks for maintaining rockchip U-Boot, Peter Rim Related: - https://github.com/openwrt/openwrt/issues/23491 - https://github.com/openwrt/openwrt/pull/23520 - https://github.com/armbian/build/pull/9869 (R76S migration to v2026.04) rk3576-mmc-bug-attachments.tar.gz

Then I don't know why it does not work, and I would assume this combination of SBC and NVME just won't work. Such cases exists, although frustrating that is does not work. You could cross check, but I don't know it you have other brands NVME to try with the OPi5 Ultra. I would also be not surprised if there is simply something wrong of missing in the U-Boot or DTB (all versions, even the one from manufacturer/xunlong). You can look at versions history of U-Boot for example, just to see how much your luck is or would be. And/or until someone with the same combination sees this topic. I only have Samsung NVME's. primarily 970+ in a ROCK5B, is also RK3588 4-lane PCIEv3 and older earlier 970 in an ROCK3A (2-lane PCIEv3). The latter one works but only with a very specific set of U-Boot, BTB and kernel (for my use case).