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.
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
> 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)