[syslinux] Changes to get CD to boot on EFI System.

[Didier Spaier]

Hi,

On 02/04/2016 21:16, Thomas Schmitt via Syslinux wrote:
✀---
> Question to Didier: 
> 
> Is the plain Linux kernel booted via EFI_LOAD_FILE_PROTOCOL 
> after the Boot manager failed with the attempt to apply
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL ?
> (UEFI 2.4, 3.4 "Boot Mechanisms")
✀---
I just have UEFI 2.6 at hand.

The ISO is built this way
(of course /tmp/BOOTX64.EFI is the EFI stub):
✀---
dd if=/dev/zero of=efi.img bs=1 count=0 seek=62M
mkfs -t vfat efi.img
MOUNTPOINT=$(mktemp -d)
mount -o loop efi.img $MOUNTPOINT
mkdir -p $MOUNTPOINT/EFI/BOOT
cp /tmp/BOOTX64.EFI $MOUNTPOINT/EFI/BOOT
umount $MOUNTPOINT
rmdir $MOUNTPOINT
mv efi.img $TMP
( cd $TMP
xorriso -as mkisofs \
-isohybrid-mbr /usr/share/syslinux/isohdpfx.bin \
-U \
-V "SLINT_INSTALLER64_CURRENT" \
-J -joliet-long \
-r \
-v \
-o $PATHTOISO \
-b isolinux.bin \
-no-emul-boot \
-e efi.img \
-isohybrid-gpt-basdat \
-no-emul-boot . \
)
✀---
If I mount it as /mnt, df -h reports
✀---
/dev/loop1 63M 63M 0 100% /mnt
✀---
blkid reports:
✀---
/dev/loop1: LABEL="SLINT_INSTALLER64_CURRENT" TYPE="iso9660"
✀---
fdisk -l /dev/loop1 reports:
✀---
bash-4.2# fdisk -l /dev/loop1

Attention : identifiant de table de partitions GPT (GUID) détecté sur « /dev/loop1 » ! L'utilitaire sfdisk ne prend pas GPT en charge. Utilisez GNU Parted.


Disque /dev/loop1 : 66 Mo, 66060288 octets
255 têtes, 63 secteurs/piste, 8 cylindres, total 129024 secteurs
Unités = secteur de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x44533712

Périphérique Amorce Début Fin Blocs Id Système
/dev/loop1p1 * 0 129023 64512 0 Vide
/dev/loop1p2 136 127111 63488 ef EFI (FAT-12/16/32)
bash-4.2#
✀---
I no nothing about the ISO9660 spec, but I assume that the firmware
should see the EFI partition. Is that right?

I also assume that the firmware can "see" the content of the EFI
partition as if I mount efi.img. Right? let's mount it:
✀---
bash-4.2# mount /mnt/efi.img /media
bash-4.2# tree /media/
/media/
`-- EFI
    `-- BOOT
        `-- BOOTX64.EFI

2 directories, 1 file
bash-4.2# 
✀---
So if my assumptions are correct and according to § 3.5.1.1 Removable
Media Boot Behavior all conditions are met so that the firmware can find
and boot BOOTX64.EFI using the Simple File Protocol.

Under ̣§ 3.5 I read:
✀---
A device that supports the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL must
materialize a file system protocol for that device to be bootable. If a
device does not wish to support a complete file system it may produce an
EFI_LOAD_FILE_PROTOCOL which allows it to materialize an image directly.
The Boot Manager will attempt to boot using the
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL first. If that fails, then the
EFI_LOAD_FILE_PROTOCOL will be used.
✀---

So if I understand well as the Boot Manager should succeed using the Simple Protocol
an does not need to try the Load File protocol.

Sorry if my lucubration make no sense to knowledgeable people but then
please correct me so that I learn something.

Best regards,
Didier

PS If there is a way to *know* (not assume) what protocol is really used
I will be glad to learn it.