multiple bootable partitions on a microSD card

Has anyone partitioned a microSD card such that it can be booted into different partitions on a Beaglebone Black or AI? How would I go about doing something like that? I’d like to avoid needing to physically take out the microSD card and potentially add bootable partitions over time. Would that be doable from the Beaglebone itself?

We use "/boot/uEnv.txt" as a trigger file..

Take an existing partition, shrink it to half, (dont' touch the 4mb
hole), then clone that partition to the empy space (and update it's
/etc/fstab)..

On startup, u-boot will search the first 4 partitions for
"/boot/uEnv.txt" so either rename the one on the first partition to
the boot the second/etc..

There's probably a better way, but this will just work with the
existing setup with the fewest mod's..

Regards,

Thanks Robert! I’ll give it a try. It sounds like 4 different images would be the limit using that strategy? Let’s say I had a 256GB microSD card with 10 different partitions. Any idea on what I would have to change to be able to select one besides one of the first 4?

The ultimate goal here would be to be able to essentially flash a board, but always be able to revert to a previously installed firmware. So rather than always flash the eMMC, leverage a much larger microSD card that could have several different images and instead of ever overwriting them, allocate spare space to a new partition and change whatever setting is necessary to default to booting to that partition (and provide some interface for reverting to any previous one).

Correction, first 7 partitions…

This was written before the mmc greater then 8 partitions layer came out

echo Checking for: /boot/uEnv.txt …;" \

  • "for i in 1 2 3 4 5 6 7 ; do " \
  • “setenv mmcpart ${i};” \
  • “setenv bootpart ${mmcdev}:${mmcpart};” \
  • "if test -e ${devtype} ${bootpart} /boot/uEnv.txt; then " \

I think a better way is extlinux.conf and grub efi, but that’ll take some work to implement, vs my quick hack today.

Wait, that’s btrfs snapshots, which also works today…

I like the idea of using btrfs. How difficult would it be to modify the script that generates the MachineKit images to use a btrfs filesystem rather than ext4? For starters I guess, how do you generate the MachineKit images and how might I do that myself?

It's actually been fully supported for about a year or two.

When you call "setup_sdcard.sh" just issue:

--rootfs btrfs

(default is ext4)

Regards,

Thanks Robert! It sounds like it’s straight forward, but I’m not familiar with the image creation process at all. When and where would I call setup_sdcard.sh?

For example, let's take this image:

https://rcn-ee.net/rootfs/bb.org/testing/2020-09-21/buster-iot/

if we ignore the am57xx files, there are only 2 for BBB's..

bone-debian-*.img.xz and bone-eMMC-*.img.xz

Those were both generated from inside this archive (once extracted),
setup_sdcard.sh is inside the archive:

debian-10.5-iot-armhf-2020-09-21.tar.xz

via:

sudo ./setup_sdcard.sh --img-4gb bone-debian-10.5-iot-armhf-2020-09-21
--dtb beaglebone --rootfs_label rootfs --hostname beaglebone
--enable-cape-universal --enable-uboot-pru-rproc-419ti

sudo ./setup_sdcard.sh --img-4gb
bone-eMMC-flasher-debian-10.5-iot-armhf-2020-09-21 --dtb beaglebone
--rootfs_label rootfs --hostname beaglebone --enable-cape-universal
--enable-uboot-pru-rproc-419ti --emmc-flasher

Just add "--rootfs btrfs"

Regards,

Ah, I see. And how does that debian-10.5-iot-armhf-2020-09-21.tar.xz file get generated?

Also, what about the process changes for the am57xx images?

sudo ./setup_sdcard.sh --img-4gb
am57xx-debian-10.5-iot-armhf-2020-09-21 --dtb am57xx-beagle-x15
--rootfs_label rootfs --hostname beaglebone
--enable-uboot-cape-overlays

sudo ./setup_sdcard.sh --img-4gb
am57xx-eMMC-flasher-debian-10.5-iot-armhf-2020-09-21 --dtb
am57xx-beagle-x15 --rootfs_label rootfs --hostname beaglebone
--enable-uboot-cape-overlays --emmc-flasher

Regards,

git clone https://github.com/beagleboard/image-builder
cd ./image-builder/

./RootStock-NG.sh -c bb.org-debian-buster-iot-v4.19

Regards,

Do I run this on a Beaglebone itself, or should it be done on something beefier? Maybe a docker container on my mac? Or would I need an ARM device?

An x15, or something similar.. Or any Debian based os, it'll use qemu on x86..

Regards,

I’m trying to use btrfs as the rootfs, but it doesn’t seem to work.

I created two different eMMC flasher images, one that used the --rootfs btrfs arguments and one that didn’t. The one that defaults to ext4 booted up and flashed the eMMC no problem. The btrfs one errors on boot with this:

mmc0 is current device

Partition Map for MMC device 0 – Partition Type: DOS

Part Start Sector Num Sectors UUID Type
1 8192 7364608 34e7716f-01 83 Boot
Scanning mmc device 0
Checking for: /uEnv.txt …
** Unrecognized filesystem type **
Checking for: /boot/uEnv.txt …
** Unrecognized filesystem type **
** Invalid partition 2 **
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **
switch to partitions #0, OK
mmc1(part 0) is current device

After that it booted using the eMMC rather than the microSD card. Any ideas?

Looking at the x15/bbai patch, i don't see btrfs added..

Yeap figures, i've only tested this with the BBB, i guess i didn't
enable btrfs on am57xx hardware yet..

Regards,