Re: [edk2] Creating EFI System Partition
On 06/15/2018 11:01 AM, Andrew Fish wrote: > >> On Jun 15, 2018, at 6:17 AM, Rod Smith > <mailto:rodsm...@rodsbooks.com>> wrote: >> >> 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. >> > > 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 :). No, I didn't mean to imply that the EDK2 FAT driver gets flaky with 12- or 16-bit FAT filesystems. The EFI in question was an early EFI-over-BIOS implementation on a Gigabyte motherboard from 2011 or 2012. That thing was a horror, and I wrote up my experiences at the time: http://www.rodsbooks.com/gb-hybrid-efi/ I no longer have that motherboard, so I can't do any more tests with it or double-check my findings from 2012. From that page, though: : A FAT-16 ESP, on the other hand, seems problematic. Ubuntu 11.04 (and : 11.10) in EFI mode creates a dinky FAT-16 ESP, and after my test : install of Ubuntu 11.04, the board hung on reboot until I reworked : the ESP as FAT-32. Thus, if you plan to install Ubuntu, or any other : OS that creates a FAT-16 ESP, be prepared to fix it, preferably : before the system reboots! Note that Ubuntu no longer creates a "dinky FAT-16 ESP;" it now creates a 512MiB FAT-32 ESP. The experience remains a relevant cautionary tale, though, for anybody who's trying to write an OS installer, particularly if the system must be installable on some random computer -- systems from that period are still in use today, so a FAT-16 ESP could cause problems in the real world. That said, I've not encountered this problem on any modern (say, 2014 or later) EFI. -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Creating EFI System Partition
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.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 http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] What Bios data is sent to the Bootloader/OS ?
On Aug 11, 2017, at 6:00 AM, Rafael Machado <rafaelrodrigues.mach...@gmail.com> wrote: >> >> Hi everyone >> >> I have a question that probably some guys here can help. >> The scenario I have, is that I need to create a OS image that must be able >> to boot at a UEFI system (with no csm module), and at a legacy bios system. >> My fist thought is that this is not possible. If I understand you correctly, it most definitely IS possible. Most major Linux distributions provide installation media that can boot in either BIOS/CSM/legacy mode or in EFI/UEFI mode. Replicating what those media do might not be the best way to go, though, since they are also typically designed to boot when written to optical media or when written to USB flash drives. To do this, they use a sort of "Frankenstein's Monster" disk format, so unless you need this cross-media compatibility, too, using the tools and procedures used to create these installation media would be overkill and would create something that's overly complex. These media do illustrate the practicality of what you're suggesting -- or at least, what I *BELIEVE* you're suggesting. If I've misinterpreted, please clarify your needs. >> The OS in this case is Linux, and the bootloader is Grub or Syslinux. A single GRUB (or SYSLINUX) binary will not do the job; however, there are both BIOS and EFI builds of both GRUB and SYSLINUX. The details of what you'd do would depend on the boot medium (hard disk, USB flash drive, optical disc, etc.); however, broadly speaking you need to write both BIOS-mode and EFI-mode versions of your chosen boot loader to the boot medium, with suitable configuration files in appropriate locations. Both GRUB and SYSLINUX are boot loaders that can load a Linux kernel into memory. The Linux kernel, in turn, does not need to be built for either BIOS or EFI environments; the same kernel binary will work in either environment. (One partial exception is that there's a feature known as the EFI stub loader that turns the Linux kernel into its own EFI boot loader. If you wanted to use this feature, it would obviously need to be compiled into the kernel. GRUB does not require this feature, though, and its presence will not interfere with the kernel being booted on a BIOS-based computer. Thus, you probably don't need to worry about it for your purposes. I mention it simply so you don't think it's an issue if you read something about it elsewhere.) -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] writing EDK compatible application.
On 07/04/2017 04:10 PM, Laszlo Ersek wrote: > On 07/04/17 19:20, Amit kumar wrote: >> >> HI, >> >> I have written a code (say helloworld program ) using edk2 framework, named >> the output efi file as BOOTx64.efi and placed it on a removable media in >> EFI/BOOT/ directory so that the application is listed in one time boot menu. >> When selected from boot menu it prints "Hello World". >> Which works as expected when tested on UEFI 2.3 and above platforms. >> But the same code fails to execute on EFI 1.10 platforms. Which i suppose is >> the problem with application entry point. >> Can somebody suggest me a way so that the application entry function can be >> compatible to both the platform. Even when written according to UEFI 2.5+ >> Spec ? > > I don't think you can develop for EFI 1 using edk2 -- unless you use > EdkCompatibilityPkg I guess. But, I don't know how much > EdkCompatibilityPkg is maintained. Actually, I think it is possible -- or at the very least, it's possible to write something that works on both UEFI-based PCs and EFI 1.1-based Macs. My rEFInd (https://sourceforge.net/projects/refind/) does this. I've used it with Macs as early as a first-generation 32-bit Mac Mini. I have NOT tested it with any non-Apple EFI 1.x implementations, though. I recall I had to fiddle with the .inf file to get it to work with Macs. Comparing my refind.inf to other .inf files included in EDK2, I think the relevant line(s) were one or both of the following: EDK_RELEASE_VERSION = 0x0002 EFI_SPECIFICATION_VERSION = 0x0001 This is in the [Defines] section. Note that, if you want to look more closely at the rEFInd code or configuration files, I've made some significant improvements to the compilation procedures under EDK2 (vs. GNU-EFI) since the latest 0.10.8 release. Thus, you should pull down the latest unreleased code via git, rather than download the source code tarball. -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] How can we identify an ISO file is an EFI bootable ISO image?
On 06/20/2017 12:47 PM, Laszlo Ersek wrote: > On 06/20/17 14:34, Heyi Guo wrote: > >> Several tools like mount in Linux will show all files together >> including EFI/BOOT directory, > > That directory, displayed as part of the ISO9660 filesystem that was > written to the ISO image / CD-ROM, is entirely irrelevant when it comes > to UEFI-bootability. I doesn't even need to exist, and if it does, it's > likely there only for convenience reasons (so that people don't have to > run "dumpet" or similar tools to extract the FAT image first, and then > the EFI binaries second, if they want to investigate the EFI binaries). > > For UEFI boot, only the ElTorito image matters. MOSTLY, yes; however, some EFI implementations include ISO-9660 drivers. This is definitely true of the EFI used by VirtualBox. I think I've seen this feature on one or two UEFI-based PCs, too, but I don't recall the details and I can't say I'm 100% certain of this. There are also ISO-9660 drivers floating around that can be loaded from a FAT partition. In either of these cases, the files on the ISO-9660 filesystem can be used to boot from an optical disc, even if it lacks the El Torito image. This is admittedly a corner case at best; but IMHO it's worth keeping in mind, since non-matching El Torito and ISO-9660 files could lead to user (or developer) confusion. -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EXT FS support
On 11/22/2016 01:25 PM, Pete Batard wrote: > On 2016.11.22 17:16, Marcin Wojtas wrote: >> There's no GRUB, platform simply boots to the Shell. > > I think there may be some confusion. > > All the drivers we linked you to are pure UEFI drivers. It doesn't > matter if they were a port from GRUB or something else, the code was > converted to work as a standalone UEFI driver. Especially you don't need > to have GRUB running or anything. You can just use the "load" command in > the shell to load the driver, and then access the file system. > > I believe you should be able to download any of the ext binary drivers > mentioned and use them in your shell right away to access your file > system from it. Yes, but it sounds like Marcin may want to embed the ext4fs driver in a custom EFI build. AFAIK, none of the drivers in question were designed with that in mind; however, the VirtualBox project has incorporated ISO-9660 and HFS+ drivers, both of which are built on the same framework (rEFIt's) as rEFInd's drivers, into its own firmware. Thus, Marcin might be able to look at the VirtualBox code and use whatever techniques or glue it uses to incorporate something else. (I can't point to specific files, though.) The rEFInd drivers might be easiest to build in this way, but that's just a guess. Note, however, that all of the drivers referenced so far in this thread are licensed under the GPL. Thus, building an EFI in this way would cause the EFI as a whole to be GPL-licensed. This might or might not be an issue, depending on what the point of the exercise is. Of course, a standalone driver might be perfectly acceptable, too. I've seen options in some EFIs to load drivers at start time, but I've never gotten them to work. (I haven't tried very hard.) If nothing else, a small driver-loading program could be written and set as the first boot option. Marcin wrote: > I also found this: > https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/FileSystems/VBoxFsDxe/ FWIW, that's a fork of the rEFInd code. I'd not seen it before now; the Clover developers haven't bothered to upstream their changes. (I maintain rEFInd.) It's still not clear to me why you want this driver, Marcin. If you want to load a Linux kernel directly, without using GRUB, rEFInd, or some other tool, you can simply put the kernel(s) on a FAT filesystem. This is a common approach among Arch Linux users; they mount the ESP at /boot and it works pretty well. Some distributions assume that /boot supports links or other features that aren't available with FAT, though, so maybe this wouldn't work as well for you, but it's worth considering. -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Gentoo Linux
On 04/16/2016 02:31 AM, Stéphane Veyret wrote: > Hello, > > (For information) > I worked again on “Installing UDK on Gentoo Linux”, this time with > version 2015. ... > My next steps are : > 1. try to execute the samples and > 2. try to compile and execute last version of rEFInd. > > Please feel free to give my any remarks about my work. You will find it here : > https://github.com/sveyret/sveyret-overlay/tree/master/sys-boot/udk FWIW, I'm interested in producing a Debian package for similar reasons, and to make it easy to produce EFI binaries of shells, etc., for easy installation via an Ubuntu PPA. I'm not prepared to start on this immediately, but I'd be interested in collaborating in the future -- I'm sure I'll be able to adapt much of what you did, and perhaps whatever I learn in the Debian and Ubuntu environments will be helpful to you on Gentoo, as well. Also, concerning rEFInd, I tried compiling rEFInd with UDK2015 a while ago and ran into some serious problems because of changes from UDK2014 to UDK2015. I haven't yet had a chance to revisit that issue, so I expect you'll have problems. You can either wait for me to update rEFInd or patch rEFInd yourself. Please submit patches if you do the latter. (In the past, I've done "hard breaks" from one UDK201* release to another, and I'll consider doing the same for UDK2015.) -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Is there any exiting way in edk2 to format a partition with FAT file system?
On 03/18/2016 10:08 AM, Tian, Feng wrote: > http://www.intel.com/technology/efi/agree_diskutil.htm The .zip file that I eventually got from this is password-protected. What's up with that? I can get a list of files, but most of them can't be extracted. (Well, maybe with a zip file password-cracking program) blib...@gmail.com wrote: > Why the EULA for these Intel tools? Why aren't they BSD-licensed and > part of the UEFI Forum's EDK-II? Some IP of Microsoft FAT? Hasn't the > Microsoft FAT on-disk format IP since been published years ago, after > the second monopoly hint, is this EULA still needed? IANAL, but as I understand it, Microsoft's patents apply to VFAT long filename extensions, not to the core of FAT. Based on the filenames, I don't think any of these tools are VFAT-specific. It looks like the package includes three programs: - efifmt.efi -- Presumably this creates a FAT filesystem. There are open source alternatives, but they'd need to be ported to EFI. - efichk.efi -- Presumably this is a CHKDSK/fsck-type tool. Again, there are open source alternatives, but they'd need to be ported. - diskpart.efi -- Presumably this is a disk-partitioning tool. At least one EFI alternative already exists: My own GPT fdisk (gdisk; https://sourceforge.net/projects/gptfdisk/). It directly supports Linux, FreeBSD, OS X, and Windows, but the UEFI GPT fdisk library (https://sourceforge.net/projects/uefigptfdisk/), which I did NOT write, enables building gdisk for EFI. (This big issue is that gdisk was written in C++; UEFI GPT fdisk is essentially an incomplete set of C++ libraries for EFI.) Note that both GPT fdisk and UEFI GPT fdisk are licensed under the GPLv2, so there are licensing obstacles to incorporating them into the mainline BSD-licensed EDK2. I know there was talk a while ago of creating a fenced-off GPL area for GPLed code related to EDK2, and I'd be happy to work with anybody who wanted to get gdisk into such an area. -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Reboot directly to UEFI firmware settings
On 01/05/2016 05:23 PM, Stephen Polkowski wrote: > Hi all, > > I've noticed recently that Windows 10 has an method that allows the > user to reboot directly to the UEFI bios settings without having holding > the "DEL" key at power up. This is a useful feature for tablets, etc. > Here is an article that describes the steps: > > http://www.tenforums.com/tutorials/5831-uefi-firmware-settings-boot-inside-windows-10-a.html > > > How is this achieved from a edk2 programmer's point of view. Does > the Windows OS return EFI_SUCCESS to the boot manager? Or, perhaps the > OS changes the BootNext variable to something and then reboots? > > How does this process work? I want to write an edk2 shell > application that does the same thing. For a working code sample in an EFI application, check the RebootIntoFirmware() function in rEFInd's refind/main.c file: https://sourceforge.net/p/refind/code/ci/master/tree/refind/main.c This function is borrowed from gummiboot (now systemd-boot), but I don't have an exact URL handy for the latter. I'm pretty sure that GRUB 2 has this functionality, too, but I've not checked to see how it implements the feature. -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Can I determine from Linux if Secure Boot is supported?
Hi, I'm wondering under what conditions the SecureBoot EFI variable (with GUID 8be4df61-93ca-11d2-aa0d-00e098032b8c) created. In particular, is it necessarily present on computers that support Secure Boot but on which that feature is disabled? I realize that it will normally exist in this case (I've seen it many times myself), but I'm wondering if a newly-minted computer (without a Windows installation) might end up without a SecureBoot variable even though the firmware supports this feature? Basically, I'm looking for a reliable way to determine, from within Linux, whether or not a computer supports Secure Boot, even if it's currently disabled. If the SecureBoot variable can't provide this, is there some other way to do it? -- Rod Smith rodsm...@rodsbooks.com http://www.rodsbooks.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
