> From: Peter Robinson <pbrobin...@gmail.com>
> Date: Mon, 19 Feb 2024 09:12:15 +0000
>
> The EFI spec states that the ESP can be any of FAT12/16/32 but for
> compatibility doesn't necssarily require the partition to be the
> EFI partition table ID of 0xef. A number of arm devices will not
> find their firmware on a FAT partition with an ID of 0xef so also
> allow the original FAT12/16/32 partition IDs as they are also
> permissable for an ESP.
Hi Peter,
Any reason not to include 0x0c as well? That is what we use on
OpenBSD/armv7 and OpenBSD/arm64. And as far as I know all UEFI
implementations (on arm64 at least) boot from such a partition.
(And yes, we use that partition type because we want to have a
bootable image that works on the various Raspberry Pi models).
That said, what problem does this fix? And what happens if we have
both a 0xea and a 0x01/0x06/0x0b/0x0c partition? In that case U-Boot
should probably prefer the 0xea over the others as the ESP.
Oh, and while your're at it, the hex constants are a bit inconsistent
(0x1/0x6 vs. 0x0b).
Cheers,
Mark
> Signed-off-by: Peter Robinson <pbrobin...@gmail.com>
> ---
> disk/part_dos.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 567ead7511d..303eb1d13ee 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -40,6 +40,12 @@ static int get_bootable(dos_partition_t *p)
> {
> int ret = 0;
>
> + if (p->sys_ind == 0x1)
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + if (p->sys_ind == 0x6)
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + if (p->sys_ind == 0x0b)
> + ret |= PART_EFI_SYSTEM_PARTITION;
> if (p->sys_ind == 0xef)
> ret |= PART_EFI_SYSTEM_PARTITION;
> if (p->boot_ind == 0x80)
> --
> 2.43.1
>
>
