grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour


From: Bean
Subject: Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour
Date: Wed, 25 Apr 2012 23:59:39 +0800

On Wed, Apr 25, 2012 at 8:16 AM, Richard Chan <address@hidden> wrote:
> I am interested in getting UEFI/PXE working using the EFI IP/TFTP
> stack as hacked versions of grub-legacy (e,g., Fedora 17). Is there
> any wisdom that the list would like to shed?
>
> 1. ON EFI platforms grub-legacy directly uses the  EFI TFTP stack and
> not its own i386-pc/TFTP stack.
> Network tftp-able files are referred to using the device (nd)
>
> It has a (nd) "network device" and pulls, for it's configuration file,
> (nd)/<UUID>
> (nd)/<mac address)
> (nd)/<IP address> reducing by the LS-Byte each time until finally
> (nd)/efidefault
>
> Subsequently, network tftp-able files, e.g. kernel, initrd are
> referred to using the (nd) device.
>
> 2. GRUB refers to TFTP-able files using the (pxe:<server>) device;
> these use the TFTP protocol which is implemented to the i386-pc TFTP
> stack.
>
> 3. Some questions: would it be better to have a totally new device
> name and protocol e.g. "(nd)" and "efitftp" so as not to clash with
> the i386-pc infrastructure?
>
> 4. File system behaviour:  grub-legacy (with #ifdef for EFI) creates a
> separate filesystem structure for EFI.
> * mounting the device always succeeds if the PXE stack is started
> * dir_open the files check using TFTP for the file size
> * read, for the first read (offset 0), the whole file is downloaded
> into to memory buffer
> subsequent reads read from memory
> Would these file  system semantics work for GRUB?
>
> 5. I have looked at the existing GRUB net+efinet stack. During my
> simple testing I have to be unaable to trigger the code path where
> grub populates the grub_net_structure from the UEFI PXE code. This
> occurs in grub_efi_net_config_real()  in
> grub-core/net/drivers/efi/efinet.c.
>
> When I do
> grub> insmod efinet
> grub> net_ls_cards
> grub> net_ls_addr
> I cannot see any information from the PXE boot (i.e. I have booted
> grub using UEFI PXE and I expected the efinet structures - at least
> one of the cards - to be populated from PXE).
>
> Nevertheless, since the UEFI/PXE stack works independently of Grub,
> would it be ok to bypass the whole grub/net/drivers infrastructure and
> use UEFI directly, as what grub-legacy currently does?
>
> Thanks in advance for any comments and advice.

Hi,

You should know that most UEFI implementation does not ship with
network drivers. Only some server machine and apple's efi have network
support. Although apple's firmware has snp driver, it doesn't have
tftp driver. So grub-legacy's method of relying on existing network
stack doesn't work very well in reality.

However, if you have an intel card, then you're in luck since intel
provides uefi driver download from their website, no other vendor
provides it as far as I know.

First, download intel driver from here:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=19186%20

Then, you need to start efi shell first, and use load command like this:

load E4404X3.efi (The latest version may have a different name)
load snp

Then load grub2 from efi shell, net_ls_cards should work now.

If you want the whole tftp stack, you need to load bc from efi shell as well.

load bc

snp and bc are compiled from edk source code, I can send you binary
copy if you don't know how to do it.

-- 
Best wishes
Bean



reply via email to

[Prev in Thread] Current Thread [Next in Thread]