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

[Seth Goldberg]

Hi,

On Apr 25, 2012, at 8:59 AM, Bean wrote:

> 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.

 Just to chime in here with some data -- I've found numerous UEFI systems' 
network functionality to be buggy (what a shock, right).  Specifically, using 
the TFTP APIs allow files to be retrieved, but using GRUB 2's TFTP stack, those 
same files fail to download, with the failure lying somewhere within the 
network driver.  In other words, there is close coupling between the network 
driver and the TFTP implementation in some vendors' UEFI implementations such 
that when you try to just use SNP, you end up with random timeouts that kill 
performance or dropped packets.  So, supporting use of UEFI's TFTP APIs seems 
like a good thing to do to deal with those types of systems.

 --S