release: Use standard mount points for arm MBR boot images

[imp]

Summary

Traditionally, we've used /boot/msdos for the MBR mount point for the SD
images that we produce. For GPT and bsdinstall, we use
/boot/efi. Migrate to using /boot/efi here too, and add a /boot/msdos ->
/boot/efi symlink for compatibility.

We originally used /boot/msdos because originally there was no EFI
support and the FAT partition was needed for uboot.bin, ubldr, and other
SoC specific files. When we added EFI support, we transitioned to just
putting the loader files in the same partition. Later we standardized on
/boot/efi at about the same time we added GPT support to the RE produced
images, but didn't transition the /boot/msdos. Later, we dropped support
of non EFI booting, so the duality of /boot/msdos diminished even
more. Since so little secondary meaning remains, putting it all in
/boot/efi standardizes the location and reflects the RE images
better. We no longer support creating images with ubldr via this
mechanism (though we still support booting that way for legacy users).

Sponsored by: Netflix

[emaste]

Huh, we previously created both /boot/efi and /boot/msdos, but only used one or the other depending on GPT/MBR? That's unfortunate.

[gjb]

In D36635#831695, @emaste wrote:

Huh, we previously created both /boot/efi and /boot/msdos, but only used one or the other depending on GPT/MBR? That's unfortunate.

Honestly, I do not recall the history here. I *thought* everything used /boot/efi, but I am clearly wrong here.

[emaste]

Honestly, I do not recall the history here. I *thought* everything used /boot/efi, but I am clearly wrong here.

No worries, this stuff has all evolved over time. I meant this only as a "huh, it's too bad this is how it turned out."

[imp]

In D36635#831695, @emaste wrote:

Huh, we previously created both /boot/efi and /boot/msdos, but only used one or the other depending on GPT/MBR? That's unfortunate.

This is a historical accident. IIRC, Ian created his images with /boot/msdos before we started talking about standardizing the location, let alone standardizing it.
IIRC, there was some short-lived thing that preceded the RE creating these images, and it was used there (I don't think it was crochet, nor was it nanobsd per-se, though I know there was a prototype done with nanobsd).
The first version then inherited this, since they were MBR only (back when 95% of ARM didn't know anything about GPT, or people hadn't realized that it didn't matter since it didn't know about MBR either: that was u-boot)
git blame isn't helpful (since my memories are from things in 2005-2010 time frame), but does show that we added GPT support only in 2020, and that added the right thing.
The original arm.subr from 2015 does have /boot/msdos, but that pre-dates when we added /boot/efi to hier.8.

There's no doubt some docs that need updating, but I can't find them (since we don't have our wiki in git)

[imp]

release/tools/arm.subr

192–193

Anybody have an opinion won whether we need this? I added it in a fit of 'think about compatibility' but don't have strong feelings beyond that.

[emaste]

release/tools/arm.subr

192–193

I was going to comment on this in fact, and ask if it's needed. I'd say at least add a comment that it's a legacy symlink.

[gjb]

release/tools/arm.subr

192–193

I am inclined to agree.

[allanjude]

LGTM

[imp]

release/tools/arm.subr

192–193

I'll add a comment.

[jrtc27]

Isn't the point that it's not just EFI, because all the MBR images are ones that have RPI firmware files?

The label should be consistent with the mount point, regardless.

[imp]

In D36635#831766, @jrtc27 wrote:

Isn't the point that it's not just EFI, because all the MBR images are ones that have RPI firmware files?

The label should be consistent with the mount point, regardless.

Yes. The pre-EFI days we had to have a number of files on a FAT partition (or in the first 2MB of the drive) that were used to get u-boot loaded... and that loaded ubldr in days of yore, but now loads the /efi/boot/bootxxx.efi file. This has transitioned from fixed areas in the first part of the disk to GPT partitions (which coincidentally cover the same space) since the early boot files now understand GPT these days. The ROMs in the old arm (esp armv4/armv5) SoCs were definitely limited in what they could do (and I did over-state that u-boot is the only one that cares about partitioning... some of them loaded off fixed areas, others loaded fixed files in the first FAT partition they found).

I'm less confident in changing the label itself. But I can't come up with a good reason to keep the old other than 'I worry that it may be encoded someplace else'...

[gjb]

In D36635#831778, @imp wrote:

In D36635#831766, @jrtc27 wrote:

Isn't the point that it's not just EFI, because all the MBR images are ones that have RPI firmware files?

The label should be consistent with the mount point, regardless.

Yes. The pre-EFI days we had to have a number of files on a FAT partition (or in the first 2MB of the drive) that were used to get u-boot loaded... and that loaded ubldr in days of yore, but now loads the /efi/boot/bootxxx.efi file. This has transitioned from fixed areas in the first part of the disk to GPT partitions (which coincidentally cover the same space) since the early boot files now understand GPT these days. The ROMs in the old arm (esp armv4/armv5) SoCs were definitely limited in what they could do (and I did over-state that u-boot is the only one that cares about partitioning... some of them loaded off fixed areas, others loaded fixed files in the first FAT partition they found).

I'm less confident in changing the label itself. But I can't come up with a good reason to keep the old other than 'I worry that it may be encoded someplace else'...

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

[manu]

In D36635#831783, @gjb wrote:

In D36635#831778, @imp wrote:

In D36635#831766, @jrtc27 wrote:

Isn't the point that it's not just EFI, because all the MBR images are ones that have RPI firmware files?

The label should be consistent with the mount point, regardless.

Yes. The pre-EFI days we had to have a number of files on a FAT partition (or in the first 2MB of the drive) that were used to get u-boot loaded... and that loaded ubldr in days of yore, but now loads the /efi/boot/bootxxx.efi file. This has transitioned from fixed areas in the first part of the disk to GPT partitions (which coincidentally cover the same space) since the early boot files now understand GPT these days. The ROMs in the old arm (esp armv4/armv5) SoCs were definitely limited in what they could do (and I did over-state that u-boot is the only one that cares about partitioning... some of them loaded off fixed areas, others loaded fixed files in the first FAT partition they found).

I'm less confident in changing the label itself. But I can't come up with a good reason to keep the old other than 'I worry that it may be encoded someplace else'...

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

DTS are loaded only from u-boot and overlays from the /boot/dtb/ directory (so on UFS in the image), so no worries here.

[gjb]

In D36635#831784, @manu wrote:

In D36635#831783, @gjb wrote:

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

DTS are loaded only from u-boot and overlays from the /boot/dtb/ directory (so on UFS in the image), so no worries here.

Excellent, thank you for confirming.

[imp]

In D36635#831793, @gjb wrote:

In D36635#831784, @manu wrote:

In D36635#831783, @gjb wrote:

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

DTS are loaded only from u-boot and overlays from the /boot/dtb/ directory (so on UFS in the image), so no worries here.

Excellent, thank you for confirming.

So should I also change the label to EFI always?

[manu]

In D36635#831806, @imp wrote:

In D36635#831793, @gjb wrote:

In D36635#831784, @manu wrote:

In D36635#831783, @gjb wrote:

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

DTS are loaded only from u-boot and overlays from the /boot/dtb/ directory (so on UFS in the image), so no worries here.

Excellent, thank you for confirming.

So should I also change the label to EFI always?

We've been mounting the partition automatically on the image based on the label so if someone was relying on this label they were wrong, you can change it too.

[gjb]

In D36635#831806, @imp wrote:

In D36635#831793, @gjb wrote:

In D36635#831784, @manu wrote:

In D36635#831783, @gjb wrote:

I cannot think of any place off-hand (in the build process) where it is explictly encoded/hard-coded. However, I cannot speak to things like DTS files or the like.

DTS are loaded only from u-boot and overlays from the /boot/dtb/ directory (so on UFS in the image), so no worries here.

Excellent, thank you for confirming.

So should I also change the label to EFI always?

I think so. We do not support binary upgrades, however consumers of pkgbase may be bitten by this. So, I am a bit conflicted. I think, maybe change it only in main, and do not MFC it to stable branches. Does that seem like a reasonable compromise?