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. Richard _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel