From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.25; helo=mail-in2.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8BB51210EB12C for ; Fri, 15 Jun 2018 08:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1529075365; x=2392988965; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DCk/75UREr0Fwj6MO3NdYALBgNr37odD++RL+hpY/hc=; b=4Y1ahM8DD15EA8BLWOOty7wyELvgxCY1s9N9lXqFjxsfGAq4VDrM4RulMQuLXcSf /IbWOhK4dnM/UPsQHJGGHUKtWOWC25l1cNNP6rQxGzr0t8YGWNi7haBQO7uovQy7 j9BpoBg68jUUXj4e6SYW4x39+rEFrhadT1v8p3H2w2WJhDfPFQGa0zTB048qQCRz ZtgoYzQPh7YtckfCjk38CQMvGbN58iyO/Z8dlHQlmVnVzTPL0JfyqHJtlvoU1XUj Y8pm11pekSAYFdmSM7z6d9cS9wLC8yrveXN1a655ueHQ64bxdHfmrfjDV4t3mR1y Q0Q5TC3LXt6Ci2/5rv0NCg==; X-AuditID: 11973e11-9fbff70000003aca-b4-5b23d6a4f1ec Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 98.BE.15050.5A6D32B5; Fri, 15 Jun 2018 08:09:25 -0700 (PDT) MIME-version: 1.0 Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PAD00JM1E3ORJ40@mr2-mtap-s02.rno.apple.com>; Fri, 15 Jun 2018 08:09:24 -0700 (PDT) Received: from [17.234.137.99] (unknown [17.234.137.99]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PAD00M5EE3K0T20@ma1-mmpp-sz10.apple.com>; Fri, 15 Jun 2018 08:09:24 -0700 (PDT) X-Va-A: X-Va-T-CD: 2571ef11e0ccb9d8019a3154b59822b1 X-Va-E-CD: 09c62dd3dfd219f922cefea8b3ed1051 X-Va-R-CD: 0d09bf8811f8e9bff5ec0771e0ca6984 X-Va-CD: 0 X-Va-ID: 68f59d43-f30f-413b-b54e-d1aa4c4ce9bd X-V-A: X-V-T-CD: d047b4782af57c5dde091669e656d973 X-V-E-CD: 09c62dd3dfd219f922cefea8b3ed1051 X-V-R-CD: 0d09bf8811f8e9bff5ec0771e0ca6984 X-V-CD: 0 X-V-ID: 0365b4cf-2fb1-447b-a3a9-e754f414b71e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-15_09:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp25.corp.apple.com-10000_instance1 Sender: afish@apple.com From: Andrew Fish Message-id: <7F363685-3A8F-4099-A337-5037D98F174D@apple.com> Date: Fri, 15 Jun 2018 08:09:19 -0700 In-reply-to: <7EBBED81-A368-4878-819F-2ECB0252F9CC@apple.com> Cc: edk2-devel@lists.01.org To: Rod Smith References: <6a7f5c2c-3dfc-c0ba-6223-30b837898258@rodsbooks.com> <7EBBED81-A368-4878-819F-2ECB0252F9CC@apple.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUiuPlRm+7Sa8rRBud7OCz2HDrKbDHt+TIm ByaP7tn/WDx+PN/NHMAUxWWTkpqTWZZapG+XwJXx/Ohf1oJT7xgrpiz9wtLAuOcsYxcjB4eE gInE8/UsXYxcHEICB5gk7uz8xNzFyMnBKyAo8WPyPRaQGmaBMIlFC30hatYzSVxqvsYOUiMk MJFJou2nBogtIcAu8efXDhYIW1tizYt2Zhh745oGNhj7+N/tUDaXxIKtp1khbF2J658eMUHY bBLrTyyBsrUkJqxexgJjb9/6gBXGPj7zMtQcTonzXyayQ9g6Egve/ISqyZZo+7EFqiZAYs3l BWAzhQXEJd6d2QR2G5uAssSK+R/YIf61kXhwZzsLRI2hxOmzk8HiLAKqEnsOXwKLcwrYSjQ3 /gWLMwtISzyceBxsl4iAmkTjk5OskDA5wSixckU1xF4lif+7jjBPYJSbhRSksxBBOgtskpbE 90etUGF5iYPnZSHCmhLP7n1ih7C1JZ68u8C6gJFtFaNQbmJmjm5mnpFeYkFBTqpecn7uJkZQ mphuJ7iD8fgqq0OMAhyMSjy8AqeVo4VYE8uKK3MPMUpzsCiJ89q8V4oWEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwPj4ZLynjIT2pdNlFXd2xB3izN3a2XGwvH2X38kl1oe+CXkpee8JeSp5 R0JFfj+r0sKliivWs7W7Tt5mk/oj88ySvy/snR/LG9S3PDnkfeNgX1DcovhVWgErxA7taTDv zPre+YtT1Dvnq+3bfQUqC3OF3Do8nlw85P35yhQtszUTDLn1hCVW8iixFGckGmoxFxUnAgAr mj7s9AIAAA== X-Content-Filtered-By: Mailman/MimeDel 2.1.26 Subject: Re: Creating EFI System Partition X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 15:09:25 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT 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 wrote: > > > >> On Jun 15, 2018, at 6:17 AM, Rod Smith > 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.Robinson@stratus.com [Stratus >>> Technologies] >>> >>> _______________________________________________ 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 > >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org > >> 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