Search the Community

Hi, I've a rock-3a board with an NVMe device and a BTRFS filesystem using the whole disk ( no partitions ) I've seen some devices having BTRFS support in u-boot, so first thing I built the u-boot images using the extension: cat extensions/uboot-btrfs.sh # Enable BTRFS support in u-boot function post_config_uboot_target__enable_uboot_btrfs_support() { display_alert "u-boot for ${BOARD}/${BRANCH}" "u-boot: enable BTRFS filesystem support" "info" run_host_command_logged scripts/config --enable CONFIG_CMD_BTRFS } And patched the configuration of the board: git diff . diff --git a/config/boards/rock-3a.conf b/config/boards/rock-3a.conf index 401894fa5..90f8a8a72 100644 --- a/config/boards/rock-3a.conf +++ b/config/boards/rock-3a.conf @@ -15,12 +15,15 @@ BOOT_SPI_RKSPI_LOADER="yes" IMAGE_PARTITION_TABLE="gpt" BOOTFS_TYPE="fat" +# Enable btrfs support in u-boot +enable_extension "uboot-btrfs" + function post_family_config__rock-3a_use_mainline_uboot_except_vendor_and_add_sata_target() { display_alert "$BOARD" "Configuring ($BOARD) standard and sata uboot target map" "info" UBOOT_TARGET_MAP=" ./compile.sh artifact BOARD=rock-3a BRANCH=current RELEASE=trixie BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,img ROOTFS_TYPE=btrfs FIXED_IMAGE_SIZE=4096 DISABLE_IPV6=false WHAT=uboot With this I flashed the SPI image: root@rock-3a:~# flashcp u-boot-rockchip-spi.bin /dev/mtd0 root@rock-3a:~# cat /proc/mtd dev: size erasesize name mtd0: 01000000 00001000 "spi4.0" So, then I booted it without the SD card I use for the /boot partition, used the serial port ( as it didn't autoboot ) and I saw: => nvme info Device 0: Vendor: 0x2646 Rev: SBM02103 Prod: 50026B778514A843 e: Hard Disk Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512) => btrsubvol nvme 0:1 ** No partition table - nvme 0 ** Couldn't find partition nvme 0:1 => btrsubvol nvme 0:0 ID 257 gen 153600 path /@rootfs/ ID 257 gen 153600 path /@rootfs/ ID 259 gen 153599 path /@home/ => ls nvme 0:0 /boot/ <DIR> 16 Sat Dec 06 08:32:08 2025 dtb < > 0 Sat Dec 06 08:44:38 2025 .next < > 37679616 Sat Nov 15 03:03:00 2025 Image < > 5560276 Tue Nov 11 22:48:14 202urrent-rockchip64 < > 5560445 Sat Nov 15 03:03:00 2025 System.map-6.12.58-current-rockchip64 < > 236 Sat Dec 06 08:54:54 2025 armbianEnv.txt< > 200 Sat Sep 09 08:armbianEnv.txt.old < > 0 Tue Jun 18 18:05:14 2024 armbianEnv.txt.out < > 1536 Thu Aug 31 17:25:06 2023 armbian_first_run.txt.template < > 38518 Thu Aug 31 17:25:04 2023 boot.bmp < > 3180 Thu Aug 31 17:20:00 2023 boot.cmd < > 3252 Thu Aug 31 17:26:44 20 boot.scr < > 258746 Tue Nov 11 22:48:14 2025 config-6.12.57-current-rockchip64 < > 258803 Sat Nov 15 03:03:00 2025 config-6.12.58-current-ro< > 29107600 Tue Nov 25 21:2 2025 initrd.img-6.12.57-current-rockchip64 < > 29108356 Sat Dec 06 08:44:34 2025 initrd.img-6.12.58-current-rockchip64< > 29108420 Sat Dec 06 08: So it can read BTRFS, but no booting, I tried manually based on some commands I get but no luck: => load nvme 0:0 $loadaddr /boot/boot.scr 3252 bytes read in 27 ms (117.2 KiB/s) => source ## Executing script at 00c00800 Boot script loaded from ** Bad device specification 0x9000000 armbianEnv ** ** Bad device specification 0x9000000 armbianEnv.txt ** Couldn't find partit Can't set block device ** Bad device specification 0x12180000 uInitrd ** ** Bad device specification 0x12180000 uInitrd ** Couldn't find partition 0x1218000ck device ** Bad device specification 0x02000000 Image ** ** Bad device specification 0x020000on 0x02000000 Image Can't set block device ** Bad device specification 0x12000000 dtb/rockchipspecification 0x12000000 dtb/rockchip/rk3568-rock-3a.dtb ** Couldn't find partition 0x12000000 t set block device libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configure via "fdt addr <address>" command. Aborting! ** Bad device specification 0x9000000 dtb/rockchiay/-fixup ** ** Bad device specification 0x9000000 dtb/rockchip/overlay/-fixup.scr ** Couldn'tp/overlay/-fixup.scr Can't set block device ** Bad device specification 0x9000000 fixup ** **0 fixup.scr ** Couldn't find partition 0x9000000 fixup.scr Can't set block device Applying us ## Executing script at 09000000 Wrong image format for "source" command Unknown command 'kaslRM64 Image magic! I'd like to get this worked, I can test anything you can provide me, I'm a n00b trying to learn a bit more about U-Boot. Thanks in advance.

Good that this is made default now for various boards. If a board/computer has no factory written bootloader, so only bootROM/maskROM, then this allows way more flexibility and also will get rid of endless topics and support issues that have their root cause in SD-card (failing, or worse fakes, fake brands, etc). As a scrub either done automatically or as support request on-demand/ad-hoc will tell. Also many operations can be done while the board/computer is kept running, no reboot needed. Like transferring rootfs OS from SD-card to NVME and many more great things. Like replacing an SD-card without reboot. Or rollback to know-good older snapshot after faulty update. I see I wrote some things about it here: https://forum.armbian.com/search/?q=CONFIG_CMD_BTRFS&quick=1 For boards/computers with factory written bootloader, so PCs with UEFI or BIOS or the strange Raspberries with their boot(EEP)ROM that need a 1st FAT, it is a different story. I figured out that for my computers that already use Btrfs for rootfs for years, even tiny/old RPi0/1, it is currently better alignment, so that I stick to heaving an extra boot partition still. It can be very small, I had defaulted to 40MiB some years ago for a single Linux OS VM (x86 or ARM), but just for some bootaa64.efi file that is already a lot. For RPi, 3MiB was enough, so you store only a bootcode.bin start* fixup* config.txt uboot.bin bootaa64.efi. But that extra boot partition is also easily very confusing, especially for RPi like methods where kernel+initramfs+DTB are copied. Also, I had Btrfs enabled U-Boot, an Ext4 bootpartition and Btrfs rootpartition while doing experiments (booting from Btrfs raid1 straight from U-Boot) on QEMU and AllwinnerH3. kernel+initramfs+DTB were accidentally read from Ext4 (/) instead of Btrfs (/boot) and more such confusion. So then I recompiled U-Boot without Ext4 (so only FAT,Btrfs), then fine. But generally I would keep Ext4 of course. With just 1 partition, then those issues are is avoided. Then simply 'U-Boot object' and 'rootfs object', where the latter can still be chosen Ext4. Btrfs U-Boot + rootfs also would make raw/flat images viable maybe. xz-compressed will certainly have smaller download file, but for full desktop variant images, there might be an overall advantage. If rootfs is written by Armbian build with let's say compress-force=zstd:9, only first MBR+bootloader sectors, the Btrfs metadata and some filesystem slack is not compressed. I think some statistics are needed first, maybe it is not worth the effort for mass-downloads also via torrents, mirrors, etc, but for own local builds I certainly see benefits. At least I force compress almost all newly written block-devices, so also a restore from backups. It can keep thin-provisioned volumes/images very small, also roughly halves the write-time for (slower/older) SD-cards.

Since there is a thread about adding ZFS support to the U-Boot build, I thought I'd post a similar request for btrfs. I was looking through the helios u-boot repo a few days ago and noticed that it isn't built with btrfs support. While I could make a separate ext4 /boot partition, it would be convenient to have the entire eMMC formatted as btrfs. This allows for me to make easy and fast backups using btrfs send/receive, and also allows for snapshotting prior to upgrades (via e.g. snapper), and rolling back to a different snapshot at boot. My turris onmia router uses u-boot with btrfs native root, and I've used the snapshot rollback support a couple of times. They have a fancy snapshot selection that can be done via the reset button without a serial console, but just having the ability to select previous snapshots at the u-boot menu would be quite convenient. I believe all that is needed is to enable CONFIG_CMD_BTRFS. https://github.com/u-boot/u-boot/blob/832bfad7451e2e7bd23c96edff2be050905ac3f6/cmd/Kconfig#L2047 Thanks for your consideration!

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.