r4g3k1d

@jernej Thanks! I tested the DRAM patch you suggested and it appears to have solved the boot problem on my Tanix TX6. As a first test I applied the patch to the older Armbian image I had been using: Armbian 26.11.0-trunk.44 Debian 13 Trixie kernel 6.18.50-current-sunxi64 That image previously would not boot with the recent U-Boot, but after rebuilding U-Boot with the DRAM probing fix it booted successfully, including a cold boot. I then repeated the work using the newer Armbian image: Armbian 26.11.0-trunk.59 Debian 13 Trixie kernel 6.18.54-current-sunxi64 U-Boot 2026.07 This one also boots successfully with the patch. I am no longer transplanting the old U-Boot 2022.10 — this is a freshly rebuilt recent U-Boot with the DRAM fix applied. From the build verification, on this H6 / 4 GB configuration the fix prevents the DRAM probing code from trying to access physical address 0x100000000, which is outside the addressable range. For my server use I have also disabled the internal eMMC, Wi-Fi SDIO and Bluetooth UART in the Device Tree, since I do not need them. I am booting entirely from microSD and using Ethernet. I have not applied the newer MMC driver patches yet, because with the eMMC disabled they are not currently necessary for my use case. So I cannot say whether those changes would also solve the eMMC-related cold-boot issue I was seeing previously. I will continue doing several cold-boot tests with the 6.18.54 image, including after leaving the box completely unpowered for several hours, but so far the DRAM patch looks like the fix for the U-Boot boot failure. Thanks again for pointing me in the right direction!

Hi, I wanted to share what I did to get a recent Armbian build working reliably on my Tanix TX6 (Allwinner H6), in case it helps other users or developers. My TX6 would not boot the recent Armbian image normally. The image I was testing was based on Debian 13 Trixie with: Linux 6.18.50-current-sunxi64 The Linux/rootfs part itself was usable, but the board would not boot correctly with the boot chain included in the recent image. 1. Getting the recent image to boot What finally worked was creating a hybrid image. I kept the recent Armbian Linux partition/root filesystem unchanged, but replaced the low-level boot components with those from an older TX6-compatible image. In practice, I transplanted the older: SPL U-Boot TF-A / boot chain into the recent image. The older working bootloader was based on U-Boot 2022.10, while the newer image contained a much newer U-Boot. After doing this, the recent Debian 13 / kernel 6.18.50 system started booting successfully on the Tanix TX6. So in my case the first problem did not appear to be the Debian root filesystem itself, but rather compatibility between the newer boot chain and this particular TX6. I am currently keeping the working boot-related packages on hold so that a normal upgrade does not overwrite the configuration that boots correctly: armbian-bsp-cli-tanix-tx6-current armbian-firmware linux-dtb-current-sunxi64 linux-image-current-sunxi64 linux-u-boot-tanix-tx6-current This is only a temporary precaution while I test stability. 2. Cold boot problem Once the hybrid image was booting, I found a second problem. If the TX6 had been completely disconnected from power for several hours, the first boot would sometimes stop around: Scanning for Btrfs filesystems At first I thought Btrfs might be involved, but the root filesystem is actually EXT4. If I waited several minutes, the system eventually produced a kernel panic with a blocked task. The visible stack trace contained MMC-related functions including: mmc_rescan mmc_attach_mmc mmc_add_card mmc_blk_probe mmc_blk_alloc_req disk_scan_partitions The strange part was that if I then removed power and immediately powered the box again, the second boot normally succeeded. So the pattern was basically: Long power-off ↓ First cold boot → hangs / kernel panic Immediate power cycle ↓ Second boot → works normally 3. Storage identification After a successful boot I checked the MMC devices. On my TX6: mmcblk0 = microSD containing Armbian mmcblk2 = internal eMMC The internal eMMC identifies as: MBG4GC and was operating as: MMC HS200 150 MHz 8-bit bus 1.8 V signalling The loaded Device Tree contained: /soc/mmc@4020000 -> microSD /soc/mmc@4021000 -> Wi-Fi / SDIO /soc/mmc@4022000 -> internal eMMC 4. Disabling the internal eMMC As a test, I disabled only the internal eMMC controller in Linux while leaving the microSD controller enabled. I created this Device Tree overlay: /dts-v1/; /plugin/; / { fragment@0 { target-path = "/soc/mmc@4022000"; __overlay__ { status = "disabled"; }; }; }; Compiled it with: dtc -@ -I dts -O dtb \ -o /boot/overlay-user/tx6-no-emmc.dtbo \ tx6-no-emmc.dts and enabled it in: /boot/armbianEnv.txt with: user_overlays=tx6-no-emmc I tested the overlay against a temporary DTB first and confirmed: mmc@4022000 = disabled mmc@4020000 = okay After rebooting, Linux no longer detected the internal eMMC, while Armbian continued running normally from the microSD. No Android/eMMC partitions were erased or modified. 5. Results so far Since disabling the internal eMMC, the cold-boot issue has not returned. The box has successfully booted on the first attempt after being completely disconnected from power for: ~3 hours overnight ~2 days and additional cold boots have also succeeded. Before disabling the eMMC, the first boot after a long power-off could fail repeatedly. This makes the eMMC initialization strongly suspicious in my case. However, I cannot say whether the root cause is: - the eMMC hardware itself - HS200 timing - the H6 MMC controller - Device Tree configuration - kernel 6.18.x MMC behaviour - or some interaction between these So I would not claim that the eMMC itself is faulty. What I can say is: disabling mmc@4022000 has made this particular TX6 consistently boot so far. 6. Bluetooth I also had repeated Realtek Bluetooth errors such as: hci0 command 0xfc61 tx timeout so I blacklisted: hci_uart The Bluetooth errors disappeared, but the cold-boot problem still occurred before I disabled the eMMC. Therefore I do not currently believe Bluetooth was the cause of the boot hang. Current setup The system is now running as a small home server with: Armbian / Debian 13 Linux 6.18.50-current-sunxi64 Docker Caddy Portainer Tailscale from a microSD card. The internal eMMC is disabled only at the Linux Device Tree level. So far the machine has been considerably more reliable with this configuration. If it is useful for debugging, I can provide: - photos of the kernel panic / stack trace - the exact DT overlay - boot logs - the working hybrid image layout - details of the old and new bootloader versions I would be interested to know whether anyone else with an H6 / Tanix TX6 can reproduce the cold-boot problem with the eMMC enabled.