Will eMMC boot partitions be utilised on Librem 5?

[riabenko]

According to the Linux kernel documentation:

MMC boot partitions as supported and exposed as
/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
parent /dev/mmcblkX.

The boot partitions are present in the eMMC on a Librem 5:

$ lsblk -p /dev/mmcblk0boot[0,1]
NAME              MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
/dev/mmcblk0boot0 179:32   0   4M  1 disk 
/dev/mmcblk0boot1 179:64   0   4M  1 disk

@irvinewade

Do you have any information as to whether these are being used at all on the Librem 5?

@dos

eMMC contains two small boot partitions that can be used to hold the bootloader independently from the main storage partition and to implement a simple A/B scheme. PureOS does not use them by default;

Instead, the bootloader is written by scripts to an offset on the eMMC in the unallocated space. It is also possible doing that by hand.

There are several propositions to utilise the boot partitions:

• “Robust A/B Bootloader&Recovery Installs and Updates (to interoperable, hardware separated eMMC boot partitions)” in Librem5/OS-issues#347
• “Use dedicated boot partition for bootloader” by @dos in Librem5/librem5-flash-image#13
• “WIP: Enable boot image generation” in Librem5/image-builder!88
• “Place u-boot in the boot MMC area” by @dcz in Librem5/librem5-devkit-tools#10

They mention, among other things, the following advantages:

• A/B scheme
• generic OS installation

The A/B scheme means the bootloader is installed to a different partition during an update without overwriting the current bootloader. If the bootloader update goes wrong, the device remains bootable with the older bootloader.

Moving the bootloader and all the device-specific files to the dedicated partitions should also allow the installation of generic images of the operating system. For instance, that should simplify the installation of other distributions on Librem 5.

[irvinewade]

@riabenko

If the bootloader update goes wrong

The bootloader is updated relatively infrequently though. I don’t know that I’ve ever heard of a Librem 5 user breaking their bootloader specifically.

I would really like to see the RPMB area used so that the Librem 5 could have a trusted boot path (independent of BigTech). Maybe that can be used in conjunction with boot0/boot1 though.

[riabenko]

@irvinewade

The bootloader is updated relatively infrequently though.

The A/B scheme with eMMC boot partitions would be invoked much more often than Purism releases customised U-Boot for Librem 5 because the other device-specific components, which would also be moved to eMMC boot partitions, update more frequently. For example, devicetree files are currently installed in the same partition with kernel and update often during kernel updates.

However, I find the potential for simplifying the installation of (other) operating systems more intriguing.

@irvinewade

I would really like to see the RPMB area used so that the Librem 5 could have a trusted boot path (independent of BigTech).

The Replay Protected Memory Blocks are interesting. One is occupied by firmware, though.

$ lsblk -d /dev/mtdblock[0,1]
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mtdblock0  31:0    0  192K  1 disk 
mtdblock1  31:1    0  1,8M  1 disk /usr/share/firmware-librem5-nonfree/firmware

So, does it leave the smaller one for some part of the bootloader probably?

@irvinewade

Maybe that can be used in conjunction with boot0/boot1 though.

I guess so.

[irvinewade]

@riabenko

One is occupied by firmware, though

I was actually referring to /dev/mmcblk0rpmb

I think you may be referring to the firmware jail.