From: "Huang, Ying" <ying.huang@intel.com>
To: Andi Kleen <ak@suse.de>,
akpm@linux-foundation.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Chandramouli Narayanan <mouli@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] x86_64 EFI boot support
Date: Thu, 09 Aug 2007 16:20:30 +0800 [thread overview]
Message-ID: <1186647630.15539.14.camel@caritas-dev.intel.com> (raw)
Because supporting booting Linux kernel and supporting UEFI runtime
service on x86_64 UEFI platform are two separate steps. I decide to
push the booting support patches firstly, so that, the essential part
of UEFI64 support can go into mainstream kernel firstly.
---
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) boot support to x86_64 architecture. The EFI runtime
service support is not added by the patches. The patches have been
tested against 2.6.23-rc2 kernel on Intel platforms with EFI1.10 and
UEFI2.0 firmware. With this set of patches applied, the 64bit and
32bit x86 kernel can be booted on x86_64 machine with UEFI64 firmware.
Because the EFI memory map is converted to E820 map in bootloader, now
the only needed code for booting Linux kernel on x86_64 UEFI platform
is the framebuffer driver.
UEFI specification can be found here: http://www.uefi.org
For booting the UEFI x86_64 enabled kernel, the machine with EFI/UEFI
firmware and the support of bootloader is required. Detailed usage
guide can be found in Documentation/x86_64/uefi.txt, which is added in
the patch: EFI boot document
Known issues:
- Boot protocol: because the real mode BIOS call can not be used in
EFI platform, the standard boot protocol defined in
Documentation/i386/boot.txt can not be used by EFI based
bootloader. So, a internal boot protocol defined in
Documentation/i386/zero-page.txt is used instead. Since this
internal boot protocol is also used by many other bootloaders, such
as kexec, LinuxBIOS and Gujin etc, maybe it is better to make this
internal boot protocol become a public 32bit boot protocol for Linux
kernel.
- Firmware information, such as ACPI root pointer, smbios pointer,
etc. In orignal EFI supporting code, various firmware information is
gotten through EFI configuration tables. But, I think the
corresponding firmware support code need not depend on the EFI
support. So, I think maybe it is a better idea to add these firmware
information to 32bit boot protocol proposed previously, and they can
be filled by bootloader if available.
Looking forward to your comments,
Best Regards,
Huang Ying
reply other threads:[~2007-08-09 8:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1186647630.15539.14.camel@caritas-dev.intel.com \
--to=ying.huang@intel.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mouli@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®