From: Jeroen Dekkers <jeroen@vrijschrift.org>
To: "xiongyi" <xiongyi04@gmail.com>
Cc: grub-devel@gnu.org, summer-of-code@gnu.org
Subject: Re: Question about the GNU Grub ideas
Date: Thu, 22 Mar 2007 23:49:55 +0100 [thread overview]
Message-ID: <873b3wlwq4.wl@dekkers.cx> (raw)
In-Reply-To: <4600d7ad.0fbdf68c.519b.057c@mx.google.com>
At Wed, 21 Mar 2007 14:58:54 -0800,
xiongyi wrote:
> I am a potential student applicant for the "Google-summer -of -code"
> program. And I am strongly interested in the GNU Grub project, especially
> for the porting grubs to the EFI-based PC platform idea. But there are few
> messages or information about EFI porting for grub2. So I have some
> questions about this idea.
I don't have any experience with EFI, but as far as I know GRUB2
already boots on intel macs and other EFI-based x86 machines. Although
it probably still needs a lot of work, that isn't going to be enough
for a Summer of Code project.
> 1. Though the source codes of current grub2 have some features about
> EFI, I feel that the building for EFI platform support of grub2 is based on
> an EFI implementation. That means we need an EFI implementation to build the
> source code for EFI of grub2. For example, the building for the elilo is
> based on the gnu-efi project. Is that right? Or whether the current grub2
> includes an EFI implementation, similar to the gnu-efi project.
No, the grub EFI implementation is stand-alone, it doesn't need any
external project.
> 2. The goal of grub2 for efi support is the same as the one of elilo,
> namely an efi OS Loader (also an efi application, for example elilo.efi file
> in the elilo project). Is that right?
Yes, the purpose is to load GRUB on EFI hardware so that GRUB can do
all the things it normally does when you load it from standard x86
BIOS.
> 3. There is a real EFI platform in my lab, but I will graduate and
> leave that lab in this June. Accordingly, I have some considerations about
> the development platform and environment. If the efi feature of grub2 is
> only an efi OS loader, whether the EDK open source project can serve as the
> development and debug platform.
My experience is that while you can develop and test on such things,
real hardware has subtle differences most of the time and you always
need hardware to test whether it really works.
Jeroen Dekkers
next parent reply other threads:[~2007-03-22 22:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4600d7ad.0fbdf68c.519b.057c@mx.google.com>
2007-03-22 22:49 ` Jeroen Dekkers [this message]
2007-03-22 23:32 ` Question about the GNU Grub ideas Tristan Gingold
2007-03-22 23:44 ` Yoshinori K. Okuji
2007-03-23 0:22 ` Jeroen Dekkers
2007-03-23 0:34 ` Yoshinori K. Okuji
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=873b3wlwq4.wl@dekkers.cx \
--to=jeroen@vrijschrift.org \
--cc=grub-devel@gnu.org \
--cc=summer-of-code@gnu.org \
--cc=xiongyi04@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.