From: Rod Smith <rodsmith@rodsbooks.com>
To: edk2-devel@lists.01.org
Subject: Re: Creating EFI System Partition
Date: Fri, 15 Jun 2018 09:17:48 -0400 [thread overview]
Message-ID: <6a7f5c2c-3dfc-c0ba-6223-30b837898258@rodsbooks.com> (raw)
In-Reply-To: <CY1PR08MB1487204C64F2F0CD2445FBAAE67C0@CY1PR08MB1487.namprd08.prod.outlook.com>
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, 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.
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.Robinson@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
rodsmith@rodsbooks.com
http://www.rodsbooks.com
next prev parent reply other threads:[~2018-06-15 13:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 0:35 Creating EFI System Partition Robinson, Herbie
2018-06-15 0:41 ` Andrew Fish
2018-06-15 13:17 ` Rod Smith [this message]
2018-06-15 15:01 ` Andrew Fish
2018-06-15 15:09 ` Andrew Fish
2018-06-15 20:11 ` Rod Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a7f5c2c-3dfc-c0ba-6223-30b837898258@rodsbooks.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox