RE: [UPDATED PATCH] EFI support for ia32 kernels

[Tolentino, Matthew E]

> As I have heard the story.
> 
> The guys at Intel were having problems getting a traditional
> PC style BIOS to run on the first Itaniums, realized they
> had a opportunity to come up with a cleaner firmware interface
> and came up with EFI.  Open Firmware was considered but dropped
> because it was not compatible with ACPI, and they did not want to
> dilute the momentum that had built up for ACPI.

Yes, Itanium has had EFI since the beginning.  

> And now since Intel has something moderately portable, they intend
> to back port it to x86 and start using/shipping it sometime early next
> year.

Hmmm...  It's not so much of a back port as it is the implementation of the interface on x86 boxes.  In fact, the EFI sample implementation can be used on boxes with legacy BIOSes and the interface is consistent with what is currently shipped on ia64 platforms.  The intention is to have an interface to the firmware that is portable and consistent.  For example, much of the linux loader is shared between ia64 and x86.  Assuming add-in cards have EFI compliant drivers, this also makes option ROM and even system BIOS upgrades easy with EFI utilities and without the need for DOS.    

> What I find interesting is that I don't see it addressed how the 16bit
> BIOS calls in setup.S can be bypassed on x86.  And currently while it
> works to enter at the kernels 32bit entry point if you know what you
> are doing it is still officially not supported. 
 
If one can obtain the required system configuration information from EFI before booting the kernel and pass this information to the kernel so as to enable kernel initialization, then why else might we even need the 16 bit BIOS calls in setup.S that essentially perform the same function?  I'm curious why it wouldn't be better to enter the kernel in 32 bit, protected mode?

thanks,
matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
> As I have heard the story.
> 
> The guys at Intel were having problems getting a traditional
> PC style BIOS to run on the first Itaniums, realized they
> had a opportunity to come up with a cleaner firmware interface
> and came up with EFI.  Open Firmware was considered but dropped
> because it was not compatible with ACPI, and they did not want to
> dilute the momentum that had built up for ACPI.

Yes, Itanium has had EFI since the beginning.  

> And now since Intel has something moderately portable, they intend
> to back port it to x86 and start using/shipping it sometime early next
> year.

Hmmm...  It's not so much of a back port as it is the implementation of the interface on x86 boxes.  In fact, the EFI sample implementation can be used on boxes with legacy BIOSes and the interface is consistent with what is currently shipped on ia64 platforms.  The intention is to have an interface to the firmware that is portable and consistent.  For example, much of the linux loader is shared between ia64 and x86.  Assuming add-in cards have EFI compliant drivers, this also makes option ROM and even system BIOS upgrades easy with EFI utilities and without the need for DOS.    

> What I find interesting is that I don't see it addressed how the 16bit
> BIOS calls in setup.S can be bypassed on x86.  And currently while it
> works to enter at the kernels 32bit entry point if you know what you
> are doing it is still officially not supported. 
 
If one can obtain the required system configuration information from EFI before booting the kernel and pass this information to the kernel so as to enable kernel initialization, then why else might we even need the 16 bit BIOS calls in setup.S that essentially perform the same function?  I'm curious why it wouldn't be better to enter the kernel in 32 bit, protected mode?

thanks,
matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/