Date: Tue, 15 May 2012 11:44:37 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Eric McCorkle <eric@shadowsun.net> Subject: Re: GSoC Project: EFI on amd64/i386 Message-ID: <201205151144.38123.jhb@freebsd.org> In-Reply-To: <4FB17B85.9080701@shadowsun.net> References: <4FA95960.7090908@shadowsun.net> <BA85B7AA-FEA5-40B0-A15A-B4E000206C59@xcllnt.net> <4FB17B85.9080701@shadowsun.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205151144.38123.jhb>