Nick A

@sicxnull This might be the patch that fixed it. It's in mainline u-boot now. I would use a newer u-boot. https://lists.denx.de/pipermail/u-boot/2025-March/582900.html

@sicxnull I would need to look at your sources. Not sure if it's a dts or u-boot patch fix.

@MeJune You can check out my work starting with the 'Add warpme kernel 6.17' commit here: https://github.com/NickAlilovic/build/commits/v20251014/ I’m using warpme patches from his minimyth2 repo, though I’ve modified them to ensure they apply correctly. I also used my own patches for Transpeed, as his implementation differs from mine. u-boot: https://github.com/warpme/minimyth2/tree/master/script/bootloaders/u-boot-aw/files https://github.com/warpme/minimyth2/blob/master/script/bootloaders/u-boot-aw/Makefile kernel: https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.19/files https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.19/Makefile An easier way to do this is to create a board config and use the official Armbian patch set. While Transpeed is already mainlined, the implementation is incomplete. You will still need a patch to include your missing Transpeed DTS nodes. If you are happy with 6.17, then use this build: https://github.com/NickAlilovic/build/commits/v20251014/ This build generates a kernel .deb package in output/debs. You can use it to upgrade your existing Armbian installation. I haven't tried this myself, so I make no promises that it will work; please ensure you have a backup before proceeding. Backing Up the SD Card (from another PC) The most reliable way to back up an SD card is to create a full disk image on a separate computer. sudo dd if=/dev/sdX of=armbian_backup.img bs=1M status=progress If your system is running on eMMC, you can back it up to an external USB or SD card using built-in Armbian tools. Using armbian-ddbr: Many Armbian builds include this utility specifically for eMMC backup/restore. Boot Armbian from an external SD card (so the eMMC is not in use). Run the command: sudo armbian-ddbr. Select the backup option to create a compressed image of your internal storage. Using armbian-config: Some versions offer a "Backup" or "Clone" option under the System or Maintenance menus

@billymore I got this from AI. It's not perfect. I haven't done this before. To convert a standard Armbian root filesystem (typically an ext4 partition) into the rootfs.cpio.lzma.uboot format required for RAM booting, you must package the file tree into a CPIO archive, compress it with LZMA, and then wrap it with a U-Boot header. 1. Extract the Armbian RootFS First, you need the actual files from your Armbian image. Mount the image to a temporary directory on your Linux PC: mkdir -p /tmp/armbian_root If you have your Armbian .img file ready, run this command to find the start sector of the root partition (usually the second partition): fdisk -l armbian_image.img Multiply that Start number by 512 to get the exact offset for the mount command. sudo mount -o loop,offset=YOUR_OFFSET armbian_image.img /tmp/armbian_root A standard Armbian rootfs doesn't have an init file in the root directory; it uses sbin/init (a symlink to systemd). A RAM disk requires an executable at /init. sudo ln -s sbin/init /tmp/armbian_root/init 2. Create the CPIO Archive Pack the entire filesystem into a newc format CPIO archive. It is critical to perform this step as root to preserve file permissions. cd /tmp/armbian_root sudo find . | sudo cpio -H newc -o > /tmp/rootfs.cpio 3. Compress with LZMA Compress the archive using the LZMA algorithm to minimize its size for RAM loading: lzma -9 /tmp/rootfs.cpio # This creates /tmp/rootfs.cpio.lzma 4. Add the U-Boot Header Use the mkimage tool (from the u-boot-tools package) to add the 64-byte legacy header that U-Boot uses to identify the ramdisk. mkimage -A arm64 -O linux -T ramdisk -C lzma -n "Armbian Initramfs" -d /tmp/rootfs.cpio.lzma /tmp/rootfs.cpio.lzma.uboot -A arm: Target architecture (use arm64 if applicable). -T ramdisk: Identifies the image type as a RAM filesystem. -C lzma: Specifies the compression used. -d: Input data file. sunxi-fel -v uboot u-boot-sunxi-with-spl.bin \ write 0x40080000 Image \ write 0x4fa00000 dtbs/allwinner/sun50i-h313-tanix-tx1.dtb \ write 0x4fe00000 rootfs.cpio.lzma.uboot (Note: If you are using a raw Image instead of a uImage, use booti instead of bootm). Once U-Boot initializes over the USB cable, it will drop to a prompt. You must run this to start the OS: Armbian’s default kernel might not have a large enough ramdisk_size allocated in its config. Update your bootargs to include a size limit (in KB). If your rootfs is 500MB: setenv bootargs "console=ttyS0,115200 root=/dev/ram0 rw" booti 0x40080000 0x4fe00000 0x4fa00000 ramdisk_size=600000

@billymore The "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" error indicates that the Linux kernel could not locate or mount the root file system during startup. . This is commonly caused by a missing or corrupted initial RAM filesystem (initramfs), an incorrect root= boot parameter write 0x4ff00000 rootfs.cpio.lzma.uboot

@Jain Ziad I'm currently working on hardware acceleration, though I can't say yet if it will outperform the official Radxa builds since it uses the same drivers. I'll keep the community updated on the results.

@marcosdsdba I would compile this on the box. Install kernel headers. Post the errors you are getting. https://github.com/NickAlilovic/build/releases/download/20250306/linux-headers-edge-sunxi64_25.05.0-trunk_arm64__6.12.11-S62b2-Da873-P8a5c-C1abcH02eb-HK01ba-Vc222-B9bbb-R448a.deb

@sicxnull

@Kevin su Excellent work! Porting the SV6256P driver all the way to kernel 6.12 is a huge achievement. Most users usually just give up and plug in a USB Wi-Fi adapter to avoid the headache of legacy drivers.

@marcosdsdba

@zcrself Your board might be missing some components for UART to work properly. Have you tested your TTL to USB adaptor on other boards to see if it works?

@marcosdsdba the only driver that works is from kernel 4.4. Unless someone figures out a way to port this to a modern kernel, your only option is to use a usb wifi adapter.

@zcrselfhttps://github.com/NickAlilovic/build/releases/tag/Mainline try this image.

@alexc Thanks for your patch and suggestions. It turns out the DRM heap isn't strictly required for DisplayPort Alt mode, but I'm sure it resolved other issues within the 6.6 kernel. I assumed it was the DRM heap because it was the only missing kernel configuration option. I suppose the kernel doesn't report missing source code drivers, or I simply didn't notice. It’s great to have your help getting this Armbian BSP build function. At least until a mainline version is released

@Brow Mosh AI is wrong. Mainline supports - Your PMIC - Your DRAM timing - Your HDMI (Patches have been around for years but not accepted in mainline yet. I included it in my builds.) - Your regulators Supported in mainline but might need some dts changes. - Your weird SD wiring - Your eMMC layout ( Could be a gpio# issue) If you are booting into the kernel then I believe your SD is somewhat working. Maybe you need few tweaks to your dts or your DRAM settings are off. A failing or cheap SD card could also be your issue. Kernel boots Reaches userspace Shows login banner Without a DTS I can’t help you much. Also, can you post some boot logs. FEL over USB is your last option. It is possible. But I don't think your AI model will help much. I noticed with some AI models they will encourage you to quit when they can't find the correct information. The owner of the AI model wants you to pay for their deep learning version.

@Bones558 I made a custom U-Boot to fix the boot splash, but so far it only works on micro-HDMI. This patch fixed the U-Boot splash for HDMI on the A7A. It also fixes the splash on the A7Z via micro-HDMI. However, when using DisplayPort Alt Mode, there is a different disp0_hdmi0 node that I need to apply the fix to. I'll play around with it tomorrow.

@marcosdsdba Can you take a picture or just tell us the Wi-Fi chip you have on your board?

@Rodrigo Campos The 20251014 build uses a newer kernel, but audio through the A/V out port is currently broken. I haven't had time to fix it yet, so if you don't need that port, feel free to use this version. 20251226 was a work in progress. Never had time to push it. I'll create a new one soon.

@Robin Hoo I don't have UFS so I can't test it. But I think if you add enable_extension "ufs" to https://raw.githubusercontent.com/NickAlilovic/build/refs/heads/Radxa-A7A/config/boards/radxa-cubie-a7a.csc it might work. git clone https://github.com/NickAlilovic/build.git --branch Radxa-A7A cd build echo 'enable_extension "ufs" ' >> config/boards/radxa-cubie-a7a.csc or echo 'enable_extension "ufs" ' >> config/boards/radxa-cubie-a7z.csc ./compile.sh

@billymore I was able to detect my transpeed box using the toothpick trick. Here are some links that might help figure it out. Maybe even going on irc and asking the sunxi guys. https://oftc.catirclogs.org/linux-sunxi/search?q=tx1 https://groups.google.com/g/linux-sunxi/c/OrktE3duFDA

@billymore https://linux-sunxi.org/Tanix_TX1 Use a toothpick or any other non-conductive stick to push the button inside the A/V connector when powering up the box. Connect a USB-A/USB-A cable to the only USB port and a host PC. https://www.slashinit.com/posts/boot-uboot-orange-pi-zero-2-using-usb-mode/ https://linux-sunxi.org/FEL/USBBoot

@Brow Mosh Have you tried extracting your arndroid dts to find the gpio settings for emmc? The only other thing I can suggest at this point is trying mainline U-Boot booted over USB (FEL). Booting mainline U-Boot via FEL completely bypasses SD.

@Bones558 Try these images. No boot splash on a7z yet. I'll look into it when I have time. https://github.com/NickAlilovic/build/releases/tag/Radxa-a7a-a7z-v0.6

@Kevin su Armbian uses one kernel config for both server and desktop images. You could compile your own server image and enable this option. I can help you with build errors. SBCs often have relatively weak single-core performance compared to x86 servers. Full preemption prevents a single long-running kernel task from causing noticeable "stutter" in network responses or shell interaction.

@Kevin su I wouldn’t call fully preemptive scheduling “not suitable” for server use, especially on ARM SBCs. On modern kernels, CONFIG_PREEMPT=y has low overhead and is widely used by Armbian even for headless/server images. For a purely headless system under sustained, throughput-focused load, CONFIG_PREEMPT_VOLUNTARY can be a reasonable alternative, but the difference is usually small. It’s more a tuning preference than a correctness issue.