[syslinux] Isohybrid wiki page and UEFI

[Ady]

> Hi,
> 
> Ady wrote:
> > Is this "32MiB" a limitation related to the UEFI specs in any way? Or 
> > is it relevant for BIOS (non-EFI) too?
> 
> It comes from El Torito specs which are referred to by UEFI 2.4
> specs. In EL Torito 1.0, Figures 3 and 5, "Sector Count" is a 2-byte
> "Word". So it can count up to 65535.
> Sector count gives the number of "virtual/emulated sectors".
> Paragraph 1.5. defines "Virtual Sector" as "200 byte", where
> "200" is to be read as hexadecimal number. Decimal 512.
> (It also calls CD-ROM sector size "800" which is fixly decimal 2048.)
> 
> 65535 * 512 bytes = 32 MiB - 512 bytes.
> 
> In UEFI 2.4, paragraph 12.3.2.1 "ISO-9660 and El Torito" says:
> 
>  "IS0-9660 is the industry standard low level format used on CD-ROM
>   and DVD-ROM. The CD-ROM format is completely described by the
>   “El Torito” Bootable CD-ROM Format Specification Version 1.0.
>   To boot from a CD-ROM or DVD-ROM in the boot services environment,
>   an EFI System partition is stored in a “no emulation” mode [image]
>   as defined by the “El Torito” specification. A Platform ID of 0xEF
>   indicates an EFI System Partition. [...]
>   EFI differs from “El Torito” “no emulation” mode [as of BIOS]
>   in that it does not load the “no emulation” image into memory and
>   jump to it.
>   EFI interprets the “no emulation” image as an EFI system partition.
>   EFI interprets the Sector Count in the Initial/Default Entry
>   [El Torito Figure 3] or the Section Header Entry [meant is Figure 5]
>   to be the size of the EFI system partition. If the value of
>   Sector Count is set to 0 or 1, EFI will assume the system partition
>   consumes the space from the beginning of the “no emulation” image
>   to the end of the CD-ROM.
>  "
> 
> (I added own comments in []-brackets. Hopefully a new version is
>  out meanwhile with less bugs in the wording. Especially misleading
>  is the confusion of El Torito Figure 4 "Section Header Entry",
>  which has no Sector Count, with Figure 5 "Section Entry".
>  To characterize the boot add-on El Torito as complete description
>  of "CD-ROM format" is a sign of double ignorance.)
> 
> 
> > Is this limitation related to the El Torito "emulation" methods/types 
> > (01/02/03)?
> 
> EFI expects 0 "no emulation", although 4 "hard disk" would have
> been an obvious choice, too.
> But probably they wanted to avoid the need for partition table
> interpretation inside the EFI System Partition.
> 
 
And here is the issue :-O. Or I should say, the lack of simplicity and 
clarity from 1600+ pages, containing even simple-to-spot typos -- which 
are kept from one version to the next one anyway, showing the lack of 
the most basic proof-reading -- thus generating confusion.

Please note that I asked about the 32MiB limitation, whether _it_ is 
related (or present, or relevant) for the El Torito _emulation_ types. 
So the fact that the EFI specs say that the EFI entries shall be 
considered a "no-emulation" method/type does not invalidate nor 
contradict the question. (Please don't take these words as criticizing 
your answer; I am rather using it so to show the lack of clarity in 
so-called "specs", origin of confusion).

As we know from ISOLINUX (a no-emulation boot method), the max size of 
the "Sector Count" is not always a definitive / absolute limitation, in 
the sense that there are workarounds.

The UEFI specs claim to use a "no-emulation" method (and I do 
understand the reasoning here), but the ESP is still an image, just as 
the "emulation" methods use for BIOS. So, someone could assert the 
following reasoning steps:

1_ We can workaround the Sector Count limitation of 32MiB for 
no-emulation methods.
2_ The ESP is considered a no-emulation method.
3_ From the above assertions, we could conclude that the limitation of 
32MiB is not really relevant for the ESP.

This would mean that, in spite of the UEFI specs stating that the 
Sector Count "field" determines the size of the ESP on optical media, 
this initial limitation could be overrun by means of some workaround.

To be clear, with "workaround" I don't mean the "size of 0 or 1"; I 
mean similar workarounds as for no-emulation methods under BIOS.
 
 
> 
> > Is this limitation also valid / relevant for the first/default entry in 
> > the Boot Catalog?
> 
> All entries which describe a boot image have that field of 2 bytes.
> (There are also header entries which describe catalog sections.)
> 
> 
> > Would you please clarify the meaning of your qualifier, "_soft_ size 
> > limit"?
> 
> The option to write size 0 or 1 is a fallback, which gives up
> the goal to exactly mark the end of the EFI System Partition.
> So i consider it preferrable to be able to express the true
> partition size, which is possible only with FAT images below
> 32 MiB.
> 
> Whether the "up-to-the-end" sizes 0 and 1 are properly interpreted
> by really existing firmware will have to be tested.
 
Aha! Another one of those dependencies on how real-life firmware 
implementations are actually... implementing standards and 
specifications.

I have one more of those for you (one of those few "better" 
discrepancies): The assumed size limitations for each El Torito 
"emulation" methods are not really there, as many real-life BIOSes will 
be able to boot other sizes, even bigger than 32MiB. Even VMs can boot 
such ISO images!

This latter discrepancy between standards and real-life implementations 
also slightly touches Syslinux docs, which claim that floppies have a 
max limit of 256 cylinders in MS-DOS (as oppose to the 1024 max 
cylinders of HDDs in CHS). I really wish to know the reason / origin / 
source for such claim in the Syslinux docs. One thing is clear: 
(super)floppy images with more than 256 cylinders can be used as El 
Torito no-emulation method to successfully boot optical media, at least 
in some (many) systems. Whether there are (other) problems with such 
optical media after booting, I don't know.
 
 
 
> The first user who has reason for such a large EFI System Partition
> is invited to ask for a development snapshot of GNU xorriso.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
 
Thank you and Best Regards,
Ady.
 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux