Re: [edk2-platforms: PATCH v2 1/1] Platform/RPi3: Add Debian 10 installation in Systems.md

["Leif Lindholm" <leif.lindholm@linaro.org>]

Hi Pete,

On Wed, Aug 07, 2019 at 03:24:10PM +0100, Pete Batard wrote:
> > > +Below are steps you can follow to install Debian 10 onto an SD card:
> > > +* Partition the media as MBR and create a ~300 MB partition on it with MBR type `0x0e`.
> > > +  __Note:__ Make sure that the partition scheme is MBR (not GPT) and the type `0x0e` (not
> > > +  `0xef` for instance), as the ondie Broadcom bootloader supports neither the GPT scheme nor
> > 
> > ondie -> on-die (or on-SoC may be even more clear to civilians).
> 
> I think I'll use "on-CPU" then, as this should be even more explicit.

Works for me.

> > > +  the ESP MBR type.
> > > +* Set the partition as active/bootable. This is needed as the Debian partition manager can
> > > +  not detect it as ESP otherwise, which we need for GRUB installation. If using `fdisk` on
> > > +  Linux, you can use the `a` command to set a partition as active. On Windows, you can use
> > > +  `DISKPART` and then type `active` after selecting the relevant disk and partition.
> > > +* Format the partition as FAT. Here again you should make sure that you use FAT rather than
> > > +  FAT32 else the Debian partition manager will not detect the partition as ESP. If you
> > > +  are using Windows `DISKPART` then `format fs=fat quick` should do it. On Linux, `mkfs.vfat`
> > > +  with the default options should do the same as long as the partition isn't too large.
> > 
> > It would be preferable if we could have an actual number here - the
> > 12-bit, 16-bit and 32-bit fat size switchover points are known. I
> > assume it is the 32-bit breakpoint (2 or 4Gb?) we want to avoid?
> 
> The switchover point actually depends of the utility, since there is overlap
> between 12, 16 and 32. But that's not actually a problem with diskpart on
> Windows as 'fs=fat' does force FAT16 so you'll get an error if the partition
> is too large and can only accommodate FAT32 (which should usually occur past
> the 2 GB point).
> 
> In other words, the only potential issue here is with Linux' mkfs.vfat. But
> there too we can add a switch (-F 16) to force FAT16, so I'll alter the
> documentation to have that, plus a note that mentions that the partition
> should be under 2 GB.

Sure, this is fine.

> I'll also take this opportunity to stress out that the only reason we are
> trying to force FAT16 here is because the Debian installer's partition
> manager is very temperamental with regards to its detection of an ESP that
> doesn't have either the relevant GUID for GPT or type 0xef for MBR, none of
> which can be used on a Pi. There are actually cases where I have seen that
> utility also detect a FAT32 MBR partition without type 0xef as an ESP.

Yeah, well. This is pretty much stacking ice cubes next to a furnace,
trying to create an ABI where there is none. Which is fine, because we
do need to provide documentation for non-experts - but this is also why
it needs to be precise, so we don't mislead experts.

> However, I have found out that, in most cases, the presence of FAT32 vs
> FAT16 acts as a switch to demote the partition from ESP, which is the reason
> why the notes promote the use of FAT16 over FAT32. But as mentioned in the
> additional notes however, it's still relatively easy to fix the ESP issue if
> you use FAT32 and/or if the Debian partition manager fails to detect it as
> ESP.

Sure. May be worth adding a forward-pointer to the additional notes
from here then?

> Now, one can only wish that Broadcom had anticipated UEFI usage for their
> hardcoded boot loader, as they'd only needed to have added 0xef, alongside
> the other FAT based MBR partition types they recognize for this whole
> annoyance to be avoided...

In my most optimistic hours, I sometimes dare to hope that the EBBR
explicitly stating these requirements will at some point in the future
start to make a difference.

> I'll send a v3 when I get a chance.

Thanks!

Regards.

Leif