> 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
Hi, Ady wrote:> So, someone could assert the following reasoning steps:> 1_ We can workaround the Sector Count limitation of 32MiB for > no-emulation methods.If the EFI firmware programmers obey version 2.4, yes.> 2_ The ESP is considered a no-emulation method.>From the view of UEFI 2.4 it is a partition.Partitions may be marked by MBR partition table or by GPT on hard disk (rotating or not), and by EL Torito Boot Catalog on CD, DVD, or BD. In the El Torito catalog, only the entries with platform id 0xEF and with emulation 0 "no emulation" are candidates for EFI System Partition. (For BIOS the platform id is 0x00 and emulations may range from 0 to 4. 3 sizes of floppy and one hard disk. I assume the hard disk is supposed to have a MBR partition table telling its size.)> 3_ From the above assertions, we could conclude that the limitation of > 32MiB is not really relevant for the ESP.It needs to be tested.> 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.Not like in BIOS, because the approach is totally different. BIOS via El Torito "no emulation" loads program code and executes it. EFI via the same form finds the block range of a partition which hosts a FAT filesystem. Maybe the Sector Count is irrelevant for EFI implementations, because FAT can tell its size without a 16 bit limitation. But the small load size of isolinux.bin is not the way how to negotiate with EFI.> 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!It is not about the size of the ISO filesystem. Debian has 25 GB bootable ISOs. It is about the size of the FAT image which serves as EFI System Partition inside the ISO. And it is about an unsurpassable limit of 16 bit numbers: If i add 1 to 65535 i get 0 as result. We have two chances with real firmware: - The Sector Count is ignored and FAT filesystem size is used insteadi as partition size. - The official values 0 or 1 are interpreted correctly and the partition spans up to the end of the medium. No problem then. FAT knows what's its own range and will not read trailing data. Of course the real firmware could bail out on Sector Count 0 or if FAT size is larger than perceived partition size. We will have to test. Needed is a EFI FAT image > 32 MiB and a new xorriso (available on demand). Have a nice day :) Thomas
> Hi, > > Ady wrote: > > So, someone could assert the following reasoning steps: > > > 1_ We can workaround the Sector Count limitation of 32MiB for > > no-emulation methods. > > If the EFI firmware programmers obey version 2.4, yes. > > > 2_ The ESP is considered a no-emulation method. > > From the view of UEFI 2.4 it is a partition. > > Partitions may be marked by MBR partition table or by GPT > on hard disk (rotating or not), and by EL Torito Boot > Catalog on CD, DVD, or BD. In the El Torito catalog, only > the entries with platform id 0xEF and with emulation 0 > "no emulation" are candidates for EFI System Partition. > > (For BIOS the platform id is 0x00 and emulations may range > from 0 to 4. 3 sizes of floppy and one hard disk. > I assume the hard disk is supposed to have a MBR partition > table telling its size.) > > > > 3_ From the above assertions, we could conclude that the limitation of > > 32MiB is not really relevant for the ESP. > > It needs to be tested. > > > > 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. > > Not like in BIOS, because the approach is totally different. > BIOS via El Torito "no emulation" loads program code and executes it. > EFI via the same form finds the block range of a partition which > hosts a FAT filesystem. > > Maybe the Sector Count is irrelevant for EFI implementations, > because FAT can tell its size without a 16 bit limitation. > > But the small load size of isolinux.bin is not the way how to > negotiate with EFI. > > > > 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! > > It is not about the size of the ISO filesystem. Debian has 25 GB > bootable ISOs. > It is about the size of the FAT image which serves as EFI System > Partition inside the ISO. And it is about an unsurpassable limit > of 16 bit numbers: If i add 1 to 65535 i get 0 as result. > > We have two chances with real firmware: > - The Sector Count is ignored and FAT filesystem size is used > insteadi as partition size. > - The official values 0 or 1 are interpreted correctly and > the partition spans up to the end of the medium. No problem then. > FAT knows what's its own range and will not read trailing data. > > Of course the real firmware could bail out on Sector Count 0 > or if FAT size is larger than perceived partition size. > We will have to test. > Needed is a EFI FAT image > 32 MiB and a new xorriso (available > on demand). > > > Have a nice day :) > > Thomas > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >I have been misunderstood in several ways. Perhaps my writing was not as clear or as easy to read, but, at this moment, I'm not sure I am capable of making my prior email more clear. Considering that there has not been replies from Bruno, for now I'll leave the topic as it is. Regards, Ady.
Thomas Schmitt via Syslinux said on Sat, Oct 24, 2015 at 12:56:49AM +0200:>Needed is a EFI FAT image > 32 MiB and a new xorriso (available >on demand).My test script on RHEL 7.1 creates that even if I could make it smaller as the kernel + initrd fits in less than 32 MB. So let me make that try first ! o I changed myline in the script to dd a 30 MB image file, burt the ISO with it, and no change. Still the same 2 red screens shown in alternance. Bruno. -- Open Source Profession, Linux Community Lead WW http://opensource.hp.com HP EMEA EG Open Source Technology Strategist http://hpintelco.net FLOSS projects: http://mondorescue.org http://project-builder.org Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
Hello, Ady via Syslinux said on Sat, Oct 24, 2015 at 12:56:26AM +0300:>> 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.If you have any improvement for the Spec, please feel free to enumerate the problems you're encountering here, as I have a way to report that to the people in charge of making updates, and we could hopefully improve the status with the help of this community.>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.In order to remove that potential problem, I'm now generating 30 MB boot images. May not solve my final problem, but can help make progresses. Still the same issue. Even with 6.04 link given to me.>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.Best regards, Bruno. -- Open Source Profession, Linux Community Lead WW http://opensource.hp.com HP EMEA EG Open Source Technology Strategist http://hpintelco.net FLOSS projects: http://mondorescue.org http://project-builder.org Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
> Hello, > > Ady via Syslinux said on Sat, Oct 24, 2015 at 12:56:26AM +0300: > >> 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. > > If you have any improvement for the Spec, please feel free to enumerate > the problems you're encountering here, as I have a way to report that to > the people in charge of making updates, and we could hopefully improve > the status with the help of this community. > > >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. > > In order to remove that potential problem, I'm now generating 30 MB > boot images. May not solve my final problem, but can help make > progresses. Still the same issue. Even with 6.04 link given to me. > > >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. > > Best regards, > Bruno.Other than potentially improving the UEFI Specs (which won't "solve" the 1600+ pages-long document, of course), do you have any reply to my other comments / suggestions? [1] Please note that the size's change of the FAT image (to less than 32MiB) is not the only "suggestion" -- or, are these "conditions", "shall", "must"? -- that the UEFI Specs mention about the FAT1x image for booting optical media booting in UEFI mode. Whether (some) real-life firmware actually require only part of the UEFI Specs points regarding the FAT image on optical media, that's another matter (with pros and cons). Regards, Ady. [1]: http://www.syslinux.org/archives/2015-October/024501.html