Hi everyone, how's it going? I'm new to the forum and I'm having trouble getting my Chinese T95 mini TV box to run Linux. I want to switch it to a basic server, but I'm having problems booting it from the SD card. I'm using the sunxi-fel mode method in Linux. I tested Armbian_23.8.1_Orangepipc_jammy_current_6.1.47_minimal.img and others like Armbian_23.8.1_Orangepipc_jammy_current_6.1.47.img. I used the .bin file generated on this forum. Boot it using the method `sudo sunxi-fel -v -p uboot u-boot-sunxi-with-spl.bin` in the terminal. TV BOX Model: T95mini | R69 - EMCP V2.0 - H3 Allwinner. The screenshots below show the screen freezing. I'm a total noob, guys, if you could please explain the procedures, indicate what needs to be done to make it work. Thanks in advance libretech_all_h3_cc_h3_mem_336 - u-boot-sunxi-with-spl.bin

Hi everyone, wanted to share what we found attempting Armbian support for Zero2. Zero2 utilises an Android-style partition layout from FriendlyElec, which I found to be fundamentally incompatible with Armbian's partition scheme. It seems to use an Android layout (boot at partition 4, rootfs at partition 8, etc.) vs Armbian's standard GPT layout. U-Boot is configured to look for partitions at specific Android-style locations Zero2 assigns SD=mmcblk0, eMMC=mmcblk2 (opposite of typical RK3528 boards) What I think is needed: Adapt hinlink_rk3528_defconfig for Android partition layout Modify partition table generation in the Armbian build system Update bootloader scripts to match partition locations Handle the inverted mmcblk device assignments LED mapping adjustments (Zero2 uses 2-LED system: sys_led, user_led vs typical 3-LED RK3528 boards) Network interface detection (single ethernet vs dual on R3S/hinlink) The device tree is already merged (rk3528-nanopi-zero2.dtb - thanks Jonas!), so that part is straightforward. It's specifically the bootloader/partition integration that's the blocker. Would love to hear thoughts. For now as a workaround, we've stayed with FriendlyElec's Ubuntu base to keep our project moving.

Glad I fell on this post Igor, Thank you for the share.. (download was indeed really fast!) I managed to install without any issues. (been using buster for way too long) Cheers, Again thanks in advance!

I already see what the issue is: I have configured things in such a way that strange/new machines get served differently then known/existing ones. In addition, the known/existing ones need an extra setting in case of systemd-resolved. This makes a quick test with some random VM like this appear doing things wrong, but is actually expected. If I purge --autoremove netplan.io and put a symlink ln -sf /usr/lib/systemd/network/89-ethernet.network.example /etc/systemd/network/89-ethernet.network, there is working network again after reboot or restart service.

Same trick as in but with N2+ image sha256sum: 5627794e883fc3b8b9ccf918efe4e5427621761402e8e2d10b05730495fc19ce Armbian_25.11.1_Odroidn2_trixie_current_6.12.58_minimal.i mg.xz and 1 reboot, then with armbian-config set my timezone to CET and reboot again: root@odroidn2:~# timedatectl Local time: Fri 2025-11-28 19:50:36 CET Universal time: Fri 2025-11-28 18:50:36 UTC RTC time: Fri 2025-11-28 18:59:21 Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: no NTP service: active RTC in local TZ: no root@odroidn2:~# timedatectl Local time: Fri 2025-11-28 20:00:31 CET Universal time: Fri 2025-11-28 19:00:31 UTC RTC time: Fri 2025-11-28 19:00:32 Time zone: Europe/Amsterdam (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no It seems it took several seconds for a sync, but nothing strange I think. However, important notice is that networking has picked the wrong DNS server; It seems to assume 'router IP = DNS IP' which is not the case in my case, so several things fail, especially in-house things, not what goes outside. This is not the case when network-manager+openresolv do the network config (and no netplan.io). I run 2 computers with systemd-networkd+systemd-resolved, but that took a lot of time and reading and some config tweaking before those do simply the same as before with network-manager+openresolv. And no benefit, only that they can run slightly easier as container with own MAC-address (real HW must be off then of course) and also a bit easier as container host.