> 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