From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=68.230.241.215; helo=eastrmfepo103.cox.net; envelope-from=rodsmith@rodsbooks.com; receiver=edk2-devel@lists.01.org Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by ml01.01.org (Postfix) with ESMTP id 9E568210D213D for ; Fri, 15 Jun 2018 06:17:50 -0700 (PDT) Received: from eastrmimpo110.cox.net ([68.230.241.223]) by eastrmfepo103.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180615131749.YGRF15378.eastrmfepo103.cox.net@eastrmimpo110.cox.net> for ; Fri, 15 Jun 2018 09:17:49 -0400 Received: from [192.168.1.2] ([98.182.36.110]) by eastrmimpo110.cox.net with cox id z1Hp1x0012Nb5V6011Hpno; Fri, 15 Jun 2018 09:17:49 -0400 X-Authority-Analysis: v=2.2 cv=TPI1cxta c=1 sm=1 tr=0 a=fGEtHzg9pACwwgu90N25OA==:117 a=fGEtHzg9pACwwgu90N25OA==:17 a=IkcTkHD0fZMA:10 a=DfuHEfYujLMA:10 a=uelBKuKpAAAA:8 a=i3X5FwGiAAAA:8 a=28bguoTQAAAA:8 a=uYdJGRt_ej3R18NL4AcA:9 a=QEXdDO2ut3YA:10 a=W_zirroESTIA:10 a=wzKOmGq4MlHJBxn66fRI:22 a=mmqRlSCDY2ywfjPLJ4af:22 a=voRV_PY5qW-4FQMV9MBC:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (PLAIN) smtp.auth=rodericksmith2@cox.net To: edk2-devel@lists.01.org References: From: Rod Smith Openpgp: preference=signencrypt Autocrypt: addr=rodsmith@rodsbooks.com; prefer-encrypt=mutual; keydata= xsBNBFZgoQEBCADBB16LbVAopSIiVn6n8CN4soC5VVseWEQJiut4NkfPtctD4xofvDZeW0sP h3iXS55hftP9EXOTT2IeNDFI0gwZe55aSaG3hUQMMimpP7OyJHrV8J4jyKr5Qk7IYa+qGjFK InfeGSgzVkMA5x62Nm/QwmP/45LqFZN/CLDpdgGIUbTKQvoojIHoytd0EB77RfkJG95EMcBv t7xF318M8dxolE7yZVQy19id7uiM7idZHV0v6nAp80uFWlkcJqzCKvGB0eOjZ8JMzPN4UJKV 0mn6PLggBlf9+qazH+2H/5IOBDr97zd5dYcEzVrvybX1YMy5WV9CEgEnFS3epPTgN7WLABEB AAHNIlJvZCBTbWl0aCA8cm9kc21pdGhAcm9kc2Jvb2tzLmNvbT7CwHgEEwECACIFAlZgoQEC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEP5hb1BFxoQhSSoIAI2UxPSYY2dUDRFP kA4KhvmkVK08hODPrwh26Rhs8cHVOHcM9HfuDeUi8g/d3tULhRxxF3dphldRqSD0s9sBwsSD yujxp1iwWN8mYXw0cD9+g391R3G2Dwd2yr4KFZ2mab8hTUT3dmeUXUXMx/s0IY9JHQdzumbY O0Xna60WL/IgiE4ykljU8FilX6pWmdsKRB+ZO21Evski7mRxsMwovTcxUSk0Arr8a2tCP3l3 ckJeUNJzV6TPEq7rCBH+DyNgg7uqlZNXN8KL67Xw6YaT+yMbP6VHL8yCrRBaJIaDKkk809N+ TegU+ENRhz5FFBGicPaVCWtXX4Oc35WeJk0/EtHOwE0EVmChAQEIAJ6kKtOd29bBf1/xLADc 6LbLvnASrKGxbG7UiFEpFEkSGaD5bLR96RaFItrPs4ntrWIrFfN+93w5aMH8W4SlTPemaPVx YHUOw6fylWobKA3UApAnVJV5KyFdc+5jK+1SziBSIdNkp8f2H4kImuEhvzVER2abJPm61270 E0qnu0cazyZC9E3YwSAqmFFvdo7H3AF4bfShHu7QTtSWp4HmihUsdVTEYjYB0GQIYrTeX2gh TLfgmo5wfpxdQIIL19oPA9GAFl5j7x2h93Y+5skCIfP/x2oOKumscbxVdxN2feuyLsbEvPAP FUnwIfA1Biv8syE8d9LPizadtagcZCCDFf0AEQEAAcLAXwQYAQIACQUCVmChAQIbDAAKCRD+ YW9QRcaEIdK9CAC34qKJTC9gHESxqpPmnMmR39icrQ1o4u4xHE1wAax2oB/3Y0BBUgvOnykf RVIgf1r0TxTap0dFBX2TnAgb8fDG33Ef6x1E6asSoOTpUfOcwgeAkOk+FW9zdW6FTclhlKsi vsa2vlUda4dj0nirGLorX59yfABVdpTTUGh75qjyBNJGFulbDDAh3ca2Tj46Ew1VRvqDix+Y 2KPAVq7wtDSugITZS+P0kac3uIzGUPDC9nYLj1i+/ODIvNaS65Y3x7jA8k8YRekM3URJVL7B I4TiMOnwwxuXgFNaLnQ0iUOsfhv8x2Rtwnf9L/0C5ZqGc+jlteh5XLI6RCb7Sh373CZf Message-ID: <6a7f5c2c-3dfc-c0ba-6223-30b837898258@rodsbooks.com> Date: Fri, 15 Jun 2018 09:17:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: 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 13:17:51 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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] > > _______________________________________________ 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