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/IBM@IBMUS To: [email protected] Cc: [email protected] 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 <[email protected]> To: Jarrod B Johnson/Raleigh/IBM@IBMUS Cc: [email protected] 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? On Tue, 2011-08-16 at 14:55 -0600, Jarrod B Johnson wrote: > 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) > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/elilo-discuss ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/elilo-discuss
<<inline: graycol.gif>>
elilo-ipxe.patch
Description: Binary data
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/elilo-discuss
