On Monday, May 14, 2012 5:39:17 pm Eric McCorkle wrote:
> 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.
So this means /boot/loader will be an EFI service, yes?
> 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.
Eh, not sure if we really want to do that. For example, we are probably
better off using EFI's GPT parsing code than depending on all the gunk to do
that in biosdisk.c.
Presumably the EFI boot loader wouldn't even use biosdisk.c or bioscd.c for
example, but only libstand drivers that talk to EFI. Not sure if Rui's EFI
loader already does this.
> 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.
The i386 kernel assumes it starts out with a flat 32-bit mode with the kernel
loaded into a contiguous memory region at a fixed physical address. If we
need a relocatable kernel (as Marcel hinted at I think), then that adds a fair
bit of complication.
The amd64 kernel assumes it starts in long mode (the bootinfo64.c bits in the
loader setup initial page tables, etc.). I think the amd64 kernel also has to
be loaded into contiguous memory at a fixed physical address currently.
> 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.
Nah, nothing in amd64 calls the BIOS (we don't support VM86). The only thing
I am aware of is the VESA bits but those use an emulator, they don't let the
CPU natively run BIOS routines. i386 could be adopted to do the same, but it
also doesn't make BIOS calls on modern systems outside of the VESA driver (it
used to use VM86 to probe memory, but now it uses the SMAP passed in by the
loader if it exists and only falls back to VM86 calls if it doesn't).