elilo patch for iPXE download protocol

Discussion:

Jarrod B Johnson

2011-08-16 20:55:46 UTC

Ok, after learning about the wonderful world of UEFI calling conventions, I
have a workable copy of my patch. It probably only compiles right under
gcc on x864_64 under linux (mainly due to the hackish approach to calling
convention coping). I presume there is some gcc magic I need to put in the
code or on the commandline to handle the calling convention change for me,
but I will put it out there as-is instead of waiting to figure it out
(really hoping someone else out there knows all this stuff).

In 'legacy' world, you can build ipxe and the syslinux pxelinux.0 and have
the latter detect and make use of the former (they go a step further and
actually bundle both in a single binary). This gives pxelinux.0 the iPXE
protocol support without having to change much.

This is the analogous capability for elilo. It comes in two halves. iPXE
needed to have capabilities exposed in a UEFI protocol in much the same way
it exports it in real mode. VMware largely did the work for their own boot
loader, so that was just ported in. Those patches to ipxe are:
https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/d748ebf72206dcde1379b063fd9b533f7572caa5
https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/e7b41890bc67350a9f5bcf7291ec859fa2174e26
https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/45a51f99fd51b231a388b1db00dfc4b18a5e9e4f
https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/23aea6c209965546c39569a770823eabf1358a71

Apply those and 'make bin-x86_64-efi/snponly.efi and you have something
much like undionly.kkpxe, but for UEFI.

My (admittedly shoddy) patch is attached.

The fruit of my labor:
88879.550706 192.168.121.208 -> 192.168.127.253 TFTP Read Request, File:
snponly.efi\000, Transfer type: octet\000
88879.551387 192.168.121.208 -> 192.168.127.253 TFTP Read Request, File:
snponly.efi\000, Transfer type: octet\000
88879.864373 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/xcat/xnba/nodes/fr1 HTTP/1.1
88879.865929 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/elilo-x64.efi HTTP/1.1
88879.872902 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/C0A879D0.conf HTTP/1.1
88880.466286 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/xcat/rhels6/x86_64/vmlinuz HTTP/1.1
88880.561916 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/xcat/rhels6/x86_64/initrd.img HTTP/1.1

(See attached file: elilo-ipxe.patch)

Jarrod B Johnson

2011-08-16 22:49:54 UTC

Permalink

Being lazy, I took the distro provided one, "gnu-efi-3.0g-2.el6.x86_64". I
also submitted to iPXE list in case someone has a clean answer to ipxe
calling elilo code with mismatched callee-caller conventions. I keep
getting the impression there should be some gcc magic but I haven't quite
discerned what the magic would be.

From: jfly <fleischli-Rn4VEauK+AKRv+***@public.gmane.org>
To: Jarrod B Johnson/Raleigh/***@IBMUS
Cc: elilo-discuss-5NWGOfrQmneRv+***@public.gmane.org
Date: 08/16/2011 05:15 PM
Subject: Re: [elilo-discuss] elilo patch for iPXE download protocol

what gnu-efi version are you compiling against for this?

Post by Jarrod B Johnson
Ok, after learning about the wonderful world of UEFI calling
conventions, I have a workable copy of my patch. It probably only
compiles right under gcc on x864_64 under linux (mainly due to the
hackish approach to calling convention coping). I presume there is
some gcc magic I need to put in the code or on the commandline to
handle the calling convention change for me, but I will put it out
there as-is instead of waiting to figure it out (really hoping someone
else out there knows all this stuff).
In 'legacy' world, you can build ipxe and the syslinux pxelinux.0 and
have the latter detect and make use of the former (they go a step
further and actually bundle both in a single binary). This gives
pxelinux.0 the iPXE protocol support without having to change much.
This is the analogous capability for elilo. It comes in two halves.
iPXE needed to have capabilities exposed in a UEFI protocol in much
the same way it exports it in real mode. VMware largely did the work
for their own boot loader, so that was just ported in. Those patches

https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/d748ebf72206dcde1379b063fd9b533f7572caa5
https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/e7b41890bc67350a9f5bcf7291ec859fa2174e26
https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/45a51f99fd51b231a388b1db00dfc4b18a5e9e4f
https://git.ipxe.org/people/jbjohnso/ipxe.git/commit/23aea6c209965546c39569a770823eabf1358a71

Post by Jarrod B Johnson
Apply those and 'make bin-x86_64-efi/snponly.efi and you have
something much like undionly.kkpxe, but for UEFI.
My (admittedly shoddy) patch is attached.
88879.550706 192.168.121.208 -> 192.168.127.253 TFTP Read Request,
File: snponly.efi\000, Transfer type: octet\000
88879.551387 192.168.121.208 -> 192.168.127.253 TFTP Read Request,
File: snponly.efi\000, Transfer type: octet\000
88879.864373 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/xcat/xnba/nodes/fr1 HTTP/1.1
88879.865929 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/elilo-x64.efi HTTP/1.1
88879.872902 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/C0A879D0.conf HTTP/1.1
88880.466286 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/xcat/rhels6/x86_64/vmlinuz HTTP/1.1
88880.561916 192.168.121.13 -> 192.168.127.253 HTTP
GET /tftpboot/xcat/rhels6/x86_64/initrd.img HTTP/1.1
(See attached file: elilo-ipxe.patch)

------------------------------------------------------------------------------

Post by Jarrod B Johnson
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
elilo-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/elilo-discuss

Jarrod B Johnson

2011-08-17 13:14:42 UTC

Permalink

Ok, I've attached a revised patch where the function looks sane and has
some chance at working in more build envs. Michael Brown from iPXE
suggested something like:
#ifdef __GNUC__
#if __x86_64__
#define EFIAPI __attribute__((ms_abi))
#elif __i386__
#define EFIAPI __attribute__((cdecl,regparm(0)))
#endif
#endif

Which I put into netfs.h. I would think gnu-efi would want to change to
this and then get to change uefi_call_wrapper to be a whole lot more
straightforward for existing code and not necessary at all for new code.
In theory, that would mean that probably a lot of elilo functions might
consider changing to add that prefix, though it doesn't really matter
except for functions called from outside of elilo itself (which could get
complicated for the likes of efi_main, considering crt0 current
assumptions).

(See attached file: elilo-ipxe.patch)

From: Jarrod B Johnson/Raleigh/***@IBMUS
To: fleischli-Rn4VEauK+AKRv+***@public.gmane.org
Cc: elilo-discuss-5NWGOfrQmneRv+***@public.gmane.org
Date: 08/16/2011 06:50 PM
Subject: Re: [elilo-discuss] elilo patch for iPXE download protocol

Being lazy, I took the distro provided one, "gnu-efi-3.0g-2.el6.x86_64". I
also submitted to iPXE list in case someone has a clean answer to ipxe
calling elilo code with mismatched callee-caller conventions. I keep
getting the impression there should be some gcc magic but I haven't quite
discerned what the magic would be.
Inactive hide details for jfly ---08/16/2011 05:15:31 PM---what gnu-efi
version are you compiling against for this? On Tue, 201jfly ---08/16/2011
05:15:31 PM---what gnu-efi version are you compiling against for this? On
Tue, 2011-08-16 at 14:55 -0600, Jarrod B

From: jfly <fleischli-Rn4VEauK+AKRv+***@public.gmane.org>
To: Jarrod B Johnson/Raleigh/***@IBMUS
Cc: elilo-discuss-5NWGOfrQmneRv+***@public.gmane.org
Date: 08/16/2011 05:15 PM
Subject: Re: [elilo-discuss] elilo patch for iPXE download protocol

what gnu-efi version are you compiling against for this?

------------------------------------------------------------------------------

Jarrod B Johnson

2011-09-07 18:24:48 UTC

Permalink

1) The demand is a bit suppressed due to good-old bios boot. Evolving
non-tftp transfer happened in x86 BIOS land driven by need not addressed in
standards bodies, and thus far that audience has mostly ignored UEFI out of
practical concerns and no urgent need to ditch BIOS. I'm content with
keeping it in my tree, just thought I'd share if someone else had interest.
We are starting to see real problems where UEFI boot on x86 becomes
imperative as opposed to not providing much practical benefit, so I needed
something today.

2) GRUB2 may be the correct long term place, but at the moment I don't see
any UEFI netboot support there (maybe I don't know where to look?) and I'm
not particularly excited about starting from scratch given my time
limitations. Historically, Grub hasn't done much to be a good network boot
loader and in legacy world, pxelinux has persisted to compensate for that
gap. For me, elilo is serving the analogous role as it's design is
significantly easier for me to follow and modify. Hopefully things are
better in grub world, last time I saw the topic broached (admittedly year
(s) ago), there seemed to be a fairly 'anti-firmware' sentiment on netboot,
saying the only right way was to compile in whatever drivers you want.
Judging from the non-UEFI PXE code, it looks like that has changed in BIOS
land, but UEFI land hasn't seen any implementation....

From: Jason Fleischli <fleischli-Rn4VEauK+AKRv+***@public.gmane.org>
To: Jarrod B Johnson/Raleigh/***@IBMUS
Date: 09/07/2011 12:38 PM
Subject: Re: [elilo-discuss] elilo patch for iPXE download protocol

Hey Jarrod,

Following up with you on this since the ball was left in my court last.
came in at a really busy time as elilo is a spare time deal... anyway,
I wanted to ask a couple of things.
1.) Sell me ;), why should we care to add this into elilo which is
pretty much in legacy support mode from my perspective especially
once the "GRand Unified Bootloader" is fully up to speed on
EFI/UEFI support. I havent had any inquiries or requests for iPxe
support. Whats the community benefit at this stage?
2.) along those lines, why not put it into grub? even UEFI systems
are bootable via (nonefi)grub which has supported chain loading
for a long time unlike elilo.

cheers,
-jason

Post by Jarrod B Johnson
Ok, I've attached a revised patch where the function looks sane and
has some chance at working in more build envs. Michael Brown from iPXE
#ifdef __GNUC__
#if __x86_64__
#define EFIAPI __attribute__((ms_abi))
#elif __i386__
#define EFIAPI __attribute__((cdecl,regparm(0)))
#endif
#endif
Which I put into netfs.h. I would think gnu-efi would want to change
to this and then get to change uefi_call_wrapper to be a whole lot
more straightforward for existing code and not necessary at all for
new code. In theory, that would mean that probably a lot of elilo
functions might consider changing to add that prefix, though it
doesn't really matter except for functions called from outside of
elilo itself (which could get complicated for the likes of efi_main,
considering crt0 current assumptions).
(See attached file: elilo-ipxe.patch)
Inactive hide details for Jarrod B Johnson---08/16/2011 06:50:25
PM---Being lazy, I took the distro provided one, gnu-efi-3.0g>Jarrod B
Johnson---08/16/2011 06:50:25 PM---Being lazy, I took the distro
provided one, "gnu-efi-3.0g-2.el6.x86_64". I also submitted to iPXE l