Sorry Rod, called you Rob. I blame pre coffee emailing. My bad. Thanks,
Andrew Fish > On Jun 15, 2018, at 8:01 AM, Andrew Fish <af...@apple.com> wrote: > > > >> On Jun 15, 2018, at 6:17 AM, Rod Smith <rodsm...@rodsbooks.com >> <mailto:rodsm...@rodsbooks.com>> wrote: >> >> On 06/14/2018 08:35 PM, Robinson, Herbie wrote: >>> I have been tasked with implementing EFI boot in our VOS operating >>> system (in a panic, nobody bothered to tell us ahead of time that >>> legacy boot was being dropped from the BIOS on our latest hardware). >>> I think we have a pretty good handle on writing the bootloader, but I >>> can't find any solid information on creating an empty EFI System >>> Partition bearing the correct flavor of FAT32 to put the bootloader >>> in. >> >> The EFI spec has some quirky CYA-type wording about its filesystem, > > Rob, > > Thanks for all this info. > > The CYA is the UEFI Spec referencing the FAT spec I cross linked. Given a > specification needs to be the arbiter of truth some times it is required to > be pedantic. In this case the UEFI Spec needed a definition of FAT32, and > that is the one and only FAT spec. contributed by Microsoft. > >> but >> AFAIK, any common tool for creating a FAT32 filesystem should work. I >> generally do it with mkdosfs in Linux, but equivalent tools in macOS, >> Windows, or the BSDs also work. In practice, FAT16 and FAT12 usually >> work, too, although the EFI spec does explicitly say at one point that >> the filesystem should be FAT32, and I know of at least one >> implementation that gets a little flaky with FAT16, so I'd stick with >> FAT32. An exception is if you need a very small filesystem, as on a >> bootable optical disc, in which case FAT16 or FAT12 might be required. >> Also, I've seen reports of problems with filesystems smaller than 512MiB >> on some EFIs, so I recommend making it at least that large, at least if >> it will be on a hard disk. >> > > I seem to remember that the FAT32 spec also defined FAT16 and FAT12. it also > defines when FAT32, FAT16, or FAT12 should be used for media. > > If the edk2 FAT driver has an issue with media that conform to the FAT32 spec > we should fix that. If the issue is non conferment, then we need to decide if > the fix can be made that will follow the FAT Spec. See that CYA was useful > after all :). > > Thanks, > > Andrew Fish > >> Ideally, the EFI System Partition (ESP) should be identified by the >> correct partition table type code. On an MBR disk, this is 0xEF; and on >> a GPT disk, it's C12A7328-F81F-11D2-BA4B-00A0C93EC93B, which is >> identified in various ways depending on the partitioning software (type >> EF00 in gdisk; a "boot flag" or "esp flag" set in parted; etc.). GPT is >> preferable, particularly for installations on hard disks, since some >> OSes tie the boot mode to the partition table type. (Of course, this >> might not be an issue for you -- it depends on what you're preparing.) >> In practice, I'm not aware of any EFI that actually requires the >> partition type code to be set correctly; every one I've tried will boot >> fine even if the type code is set to something other than an official >> ESP type code. That said, I'd set the type code correctly just to be >> sure it works on an oddball system, and to avoid confusion if/when users >> look at the disk. >> >> If the boot medium is an optical disc, you'll need a particular variant >> of an El Torito boot image. If you need help with this, please say so; I >> can dig up the details, or at least point you to a sample mkisofs command. >> >>> I need to end up with a binary image file (which I can process >>> into an object module and embed into our OS code for initializing >>> disks). >> >> GPT places data structures at both the beginning and the end of the >> disk, which might create some complications, depending on your exact >> needs. If you need to write an image to a blank disk of unknown size, >> several options occur to me: >> >> * You can use MBR, which does not rely on data structures at the >> end of the disk. As noted above, though, that's a little iffy in >> some cases -- but it might be fine for your case (it's hard to >> tell without more details). >> * You can prepare a virtual image of a small disk and write it out >> to a larger disk, leaving the backup GPT data structures before >> the end of the disk; then either: >> * Leave it that way, which will effectively limit the size of the >> disk. This might be OK for a USB flash drive. >> * Use a disk partitioning tool to relocate the backup GPT data >> structures to the end of the disk. The sgdisk "-e" option will >> do this, for instance. IIRC, parted will do it automatically, >> or at least prompt that it be done, if any operation is performed >> on the disk. >> * You can create an image of the FAT32 ESP filesystem ONLY (without >> partition table), then have your wrapper tool use sgdisk, parted, >> or some other tool to prepare a disk with GPT and an ESP. You'd >> then write out the image to the ESP on the disk you've just >> partitioned. >> >> Caveat/full disclosure: I mostly use Linux, so I've referenced Linux >> commands. I'm also the author of GPT fdisk (gdisk, sgdisk, and cgdisk); >> but of course, other tools on many platforms can do what you need. >> >>> I found a thread on submitting a "GPT" EFI shell application on this >>> list, but it seems to have trailed off to nowhere about two years >>> ago. >>> >>> Did that end up somewhere that I haven't found? >>> >>> Herbie Robinson Software Architect Stratus Technologies | >>> www.stratus.com 5 Mill and Main Place, Suite 500 | Maynard, MA 01754 >>> T: +1-978-461-7531 | E: herbie.robin...@stratus.com [Stratus >>> Technologies]<http://go.stratus.com/US> >>> >>> _______________________________________________ edk2-devel mailing >>> list edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> >> >> -- >> Rod Smith >> rodsm...@rodsbooks.com <mailto:rodsm...@rodsbooks.com> >> <mailto:rodsm...@rodsbooks.com <mailto:rodsm...@rodsbooks.com>> >> http://www.rodsbooks.com <http://www.rodsbooks.com/> >> <http://www.rodsbooks.com/ <http://www.rodsbooks.com/>> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> >> <mailto:edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>> >> https://lists.01.org/mailman/listinfo/edk2-devel >> <https://lists.01.org/mailman/listinfo/edk2-devel> >> <https://lists.01.org/mailman/listinfo/edk2-devel >> <https://lists.01.org/mailman/listinfo/edk2-devel>> > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
