Andi Kleen <[EMAIL PROTECTED]> writes: >> The needed code changing is minimal. In fact, I can boot 32bit Linux >> kernel on my x86_64 EFI machine. With setup as follow: >> >> 1. Apply the efi-fb.patch > Just for the frame buffer, right? > >> 2. make efi fb driver not depend on EFI >> 3. configure kernel as follow: >> a. CONFIG_EFI is turned off >> b. CONFIG_FB_EFI is turned on > > Hmm, how does the 32bit kernel know where the e820 map is passed then? > With CONFIG_EFI turned off it will just ask the real mode BIOS I think > and I doubt elilo simulates that.
This is the classic skip the 16bit code and enter the kernel in 32bit mode filling in the fields that the 16bit mode code would have filled in the same way approach. It isn't clearly documented as a public interface but is the way everything without a classic x86 BIOS has been booting for quite a while. We can even reasonably handle Xen & lguest this way. Dotting the last couple of i's and crossing the last couple of t's is a pain to make it a really solid and documented interface but I haven't seen any real opposition to it. On the other side since EFI doesn't not seem to have dual mode interfaces I think this thread makes a very good case for not using efi_enter_virtual_mode. Always using a trampoline and keeping EFI at it's original physical addresses. A trampoline switching to physical mode and maybe doing a 32->64 or 64->32 bit mode switch isn't that hard and should not be noticeably slower then anything else. Plus it makes EFI much more useful. I agree with Andi that the variable services are more interesting then reboots or setting the CMOS both of which we can talk to the hardware directly to handle. Eric p.s. On future patches that update the x86 boot protocol please also copy HPA. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/