Date: Mon, 14 May 2012 17:39:17 -0400 From: Eric McCorkle <eric@shadowsun.net> To: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: EFI on amd64/i386 Message-ID: <4FB17B85.9080701@shadowsun.net> In-Reply-To: <BA85B7AA-FEA5-40B0-A15A-B4E000206C59@xcllnt.net> References: <4FA95960.7090908@shadowsun.net> <BA85B7AA-FEA5-40B0-A15A-B4E000206C59@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------050703030500030000060805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/10/12 07:45, Marcel Moolenaar wrote: > > On May 8, 2012, at 1:35 PM, Eric McCorkle wrote: > >> Here are some specific points to be decided: >> >> * An EFI boot service could potentially function similarly to >> [zfs]loader. Alternatively, it could function like >> gpt[zfs]boot, though this might require modifying loader(8) since >> EFI boot services run in protected/long mode, and have different >> system information table formats. It seems having the EFI boot service load the kernel directly is the way to go, based on Andrey's reply, the existing code, and my own intuition. I just wanted to ask, in case there was some compelling reason to have the EFI boot service load loader(8) instead. > Now, as for the FreeBSD boot loader: it's currently an EFI > program/image that can be run from within EFI and that uses the > boot- and runtime services to load the FreeBSD kernel from a file > system it knows about in some GPT partition. The loader is stored > in the EFI system partition so that it can be found and run. Sounds good. Also, Apple machines do things a bit differently, but it shouldn't be too much trouble to deal with. The Apple firmware looks for an HFS+ partition, and loads a specific file from it. A simple workaround is just to wrap the EFI boot program in an HFS+ filesystem. I have some half-finished code that does this on my hard drive. Also, the apple firmware starts in graphics (as opposed to text) mode. > >> * How much of what EFI provides do we want to use? There are >> advantages and disadvantages both ways. There are alot of features described in the EFI specification. It might be good to plan to use some of them, either now, or in the future. In particular, I noticed something about signing for boot services and drivers, which seems like it could be a great security feature (though not something I'd do this summer), though I haven't looked closely at it yet. On the other hand, I think it's a good idea to use libstand/libi386 whenever possible, even if it ends up calling through to EFI functions, as it keeps things standardized. >> * How much of the kernel needs to be changed to boot/run from an >> EFI boot? > > The hand-off will be different. In particular, a proper loader will > not load the kernel at some hardcoded address. Instead it will use > EFI's memory allocation routines to get available memory chunks and > load a kernel there. Since the kernel may not occupy a single > contiguous range in physical memory this way, you want the loader > to set up page tables as well. > > Put differently: the current state of affairs is that the EFI > loader we have loads a kernel, but can't boot it. Good to know. Here are some other questions/issues on my mind: If I understand things correctly, boot2 handles the switch to protected mode (as well as enabling A20), both loader(8) and the kernel begin their execution in a protected mode environment. Can I get an absolute confirmation on this? Obviously if this is not the case, then there will need to be another (protected mode) entry point into the kernel. I know some drivers rely on BIOS calls (vga, for instance, and I think some drivers for RAID cards do as well). These might (or might not) need to be modified. > You need to support both anyways. But not at the same time. The > machine either boots BIOS or EFI and depending on that will it use > the EFI loader or use the MBR to load boot code. There's nothing to > try. > > Key is to have a single kernel loadable and bootable by either the > EFI loader or using the "legacy" loader. Yes, I think it's prudent to make it possible for users to boot a given kernel with EFI or legacy BIOS, so that a bug doesn't leave early adopters "stuck" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPsXuEAAoJENSCzbQ+koZ7yaIP/1MGDIUCVN2HR9QOteKxg4U2 YeDZQ/C+s3xG5rnztfY5u5b5o9tEVoQJiBcvk+6+9JRW1cBhEUzAjgWnKDL5QMid RWql/rOPrg2jRhaRYQrh0dN9kkI0Dzdfm+N53Fmf0jat9fn11n5fYVzcA+WnFHTr eQ7IZNKGdJg7zzTC6+cDHz4wRjr+Lozp2Yk5hptsc4Xu3CkHus/7LRIoyfgEEc6r XwvjdBPYv9Jr6XirBFrZHjHNU/XvjUnD+bKyaEAhlUekLE/1J7Ge3oK0dqC3/zNh 5dP2ArQ0Xj91HzG2U8cDQs4SWp4AzIONygq5SdZeX+d78cpMJCzqzmxh3fdW2Aa9 oh40Aulqlj3BfeA7pak0Qe7SmDCi3OaZVI1z/HVbQD8utY4CxFmq7z6lnKBj6Y08 w9TyilE/px4AFy54nhjNke7eRfapu1g1Iz881oOHRtPcwecshTbjQWeBUQzc+3gV zE0L2NwUxUt5eWfw2jyC8bSK/mboMMBXpt4Zd4hBWjYKYcvbfaSSHS5Ys70Nlq30 GHjFphMz4MMpJbCO4ak/fMEJJPCDrDdoIT9QfUglyo3GjwI1BzUQF5iFoHFfqd/o hrcW+hgIVjb/qRT/Yr0qjEumoCnQLMHPcc8ylVVL1wt0qDyUL9XnjPiKRisQ4uqv lLNBhd+3V8SBV8V7sl0J =yyPA -----END PGP SIGNATURE----- --------------050703030500030000060805--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FB17B85.9080701>