Is there any proper complete cannonical documentation for /boot/armbianEnv.txt ?

On LUKS partition surprise: 420MB/s write, 350MB/s read. Hynix module is "DRAM-less". And it works with Armbian 24.8.1 with kernel 6.1.75 (testing now, will test also with 6.10.x kernel).

I installed the latest stable (and updated) debian image on clearfogpro from SD card. I then chose "boot from SD, install on SATA ..." as I have a M.2 SSD card which is viewed as /dev/sda device, with the "armbian-install" utility. However, this one does not offer to boot directly from M2. SSD, which should be possible as there is a DIP switch configuration for it. I tried to burn the iso image on sata with "dd" and then, to "dd" the u-boot.sata on "/dev/sda" (bs=512 seek=1). When switching to sata boot (dip switch), it begins well, the sata device is found, but nothing happens after, the iso image is not loaded. How can I boot directly from M.2 SSD with system installed on it ?

Why is so much of the eMMC unused at the start? In the old script, the first partition starts at 700M (M = million bytes), and in Armbian 23.11.1, that has been increased to 1000M. These are the parted commands: parted -s "${DEV_EMMC}" mklabel msdos parted -s "${DEV_EMMC}" mkpart primary fat32 1000M 1512M parted -s "${DEV_EMMC}" mkpart primary ext4 1513M 100% BTW The Armbian 23.11.1 version also contains the umount /var/log.hdd fix from the post above.

I managed to build u-boot-2024.10 with Btrfs for 32-bit (using systemd-nspawn). See: https://docs.u-boot.org/en/latest/build/index.html It would be more easy to do for native aarch64, but that I already knew when building for 'machine' 'qemu-arm64'. As example for my NanoPi-NEO, all in extra separate src/build folder: dpkg -L linux-u-boot-nanopineo-current - add/change CONFIG_CMD_BTRFS=y CONFIG_FS_BTRFS=y in nanopi_neo_defconfig make menuconfig and save the .config make -j8 - see platform_install.sh how and where to write the newly build u-boot-sunxi-with-spl.bin (about 570kByte, so fits in my MBR partition starting at sector 2048) So after merging boot files from the mmcblk0p1 Ext4 partition to a folder /boot on mmcblk0p2 Btrfs rootfs, I started fdisk and made Btrfs rootfs p1 (using the same start-end sectors), so only 1 partition. Same as you actually have on standard Armbian images. And comment out the line in fstab for mount of separate boot partition (or add nofail option maybe). Then reboot and restarted without problems. I did actually all via remote ssh, although i also had serial USB console cable connected as I wanted to see the boot log, but was as expected. A remark I saw was that it could not write environment to FAT. That is something I need to think about. Do I gain something if that is possible. Currently not on single OS SBCs for me I guess. A bootFAT might be more convenient for people who rely more or only on a Windows/MacOS computer as their main desktop. I use Linux so no issue with fixing SD-cards in case of non-boot because I messed up something testing or so. What went wrong afterwards is my backup script via ssh. For SoCs that use binary blob bootloader, I copy/compare/backup the first sectors till p1 (usually 2048 or so, so a 1 MiB file). That size determination went wrong, it created a 257MiB file in /tmp, so fails with a 512MiB SBC. But learning more now after 10+ years SBCs, I think I should do that smarter, just re-use platform_install.sh or so. I think I will have to look at 1st boot resize script(s). It is max SD-card, so all space gone for Ext4. I really hate that. Even more when done on fixed/soldered eMMC or NVME. Ext4 cannot be shrunk in a running system later on. Btrfs can, so last hack I did on an Ext4 downloaded image (RPiOS64 Lite) was double the image file, max Ext4 on that image and then convert to Btrfs with btrfs-convert. It also need kernel cmdline and fstab change still, but that is more or less it.