On Wed, Aug 07, 2019 at 03:24:10PM +0100, Pete Batard wrote:
I think I'll use "on-CPU" then, as this should be even more explicit.
+Below are steps you can follow to install Debian 10 onto an SD card:ondie -> on-die (or on-SoC may be even more clear to civilians).
+* 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
Works for me.
The switchover point actually depends of the utility, since there is overlap
+ the ESP MBR type.It would be preferable if we could have an actual number here - the
+* 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.
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?
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
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.