Re: [Etherboot-developers] PXELINUX on top of Etherboot?

[<ebi...@ln...>]

"H. Peter Anvin" <hp...@zy...> writes:

> [Hi all... this is a copy of a message I just sent to the SYSLINUX mailing list.
> 
> I apologize if this is a bit clueless for this list... I'm not really that
> well-informed about Etherboot.]
> 
> Question for people...
> 
> Has anyone actually tried running PXELINUX on top of Etherboot?  There
> is something in Etherboot 5.1.7 called FREEBSD_PXEEMU, which seems to be
> a PXE stack subset, in particular it seems to support the following calls:
> 
> PXENV_GET_CACHED_INFO
> PXENV_UDP_OPEN
> PXENV_UDP_WRITE
> PXENV_UDP_READ
> PXENV_UDP_CLOSE
> PXENV_UNLOAD_STACK
> PXENV_UNDI_SHUTDOWN
> 
> This happens to be pretty close to the subset used by PXELINUX, with two
> exceptions: PXELINUX will also invoke PXENV_STOP_UNDI (for version >=
> 2.00) or PXENV_UNDI_CLEANUP (for version < 2.00).  I'd be really curious
> to see how this would play out.
> 
> There are of course also other kinds of concerns, e.g. if the detection
> mechanism works properly, and if it stomps on memory it shouldn't be.
> 
> I'm sorry if this has happened to be public knowledge to everyone but
> myself for a long time.  If this happens to work, though, I'd like to
> post it on the PXELINUX web pages, and if not, I'd like to see what I
> can do to help debug it.

The short answer is that the code in at least one place was not
integrated cleanly and a working version has never made it into an
etherboot release. 

That said I surveyed the code a while ago and fixing it up does not
look too difficult.  The concept are at least clean.

With respect to stomping memory except for a small real mode
trampoline the development version of etherboot 5.1.x lives at the
high end of memory below 4GB, so the code should be safe.

It has been observed before that getting pxelinux running should not
be too difficult, and no one was opposed.  But so far no one has
volunteered to debug it into operation.

Besides the missing functions there are two significant stumbling blocks.
1) The callbacks are currently 32bit only.
2) The pxe entry points depend on freebsd headers so the does not
   currently compile on linux.

Looking through the actual pxe wrappers the code should continue to
work.  But there was at least one location where the fact that
etherboot can now live above 1MB breaks the code.  But for
the short term that can be worked around by just disabling -DRELOCATION
though etherboot stomps on to much memory in that case.

Eric