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

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

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

> Eric W. Biederman wrote:
> > 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.
> >
> 
> OK; it really should hook INT 15h (and move the low DOS memory ceiling BIOS
> variable at physical address 0x413) to make itself invisible --

Yep.  One of the little things that has not happened yet.
 
> PXELINUX will actually avoid touching the top 128K of memory just in
> case a PXE stack doesn't do that, but that's the "right thing" to do.
> 
> When you get the cleanup command (unload stack) then you remove the
> hooks, of course.

Yep...

> > 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.
> 
> OK... not sure what you mean with callbacks here.  Are you referring
> to the 32-bit PXE entrypoint, or the 32-bit PXE status callback?

I was thinking of anything call back into etherboot as a callback.
Sorry it was confusing terminology for the context.

> PXELINUX doesn't use the status callbacks, but it does use the 16-bit
> PXENV+ or !PXE entrypoints.

Right and that is what I meant to say that is not currently
implemented, the 16bit entry point.   But I think wrappers that
call the 32bit entry point should be possible.

> > 2) The pxe entry points depend on freebsd headers so the does not
> >    currently compile on linux.
> 
> <nod> that doesn't sound too hard to fix.
> 
> > 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.
> 
> How much memory is "too much"?  As far as I know, some actual PXE
> stacks will hog memory down to near the 448K mark.  PXELINUX only
> requires 384K of conventional (low 1M) memory, although I might move
> that mark up to 448K in a future version in order to allow the use of
> large blocks through the TFTP blksize option.

Then with a little bit of care you can probably make it work without
-DRELOCATION.   And then fix it up to handle etherboot living about
1MB.  Before 5.1.x all of the code+data would fit in 48K.  In 5.1.x
things are not quite as tight because they don't need to be.
 
> I'll see if I have a chance to look at this.  If the learning curve
> isn't too steep I might be able to make it work.

The code is all C and gas assembly.  Probably the worst part are the
gymnastics etherboot currently uses to make bios calls while keeping
all of it's code above 1MB.  Basically it sets up a temporary stack
pushes the code does the BIOS call, returns to it's normal stack
and copies return arguments between the stacks, and forgets the
temporary stack. 

If things look a too confusing you could start with 5.0.9 on the
stable branch.  The code is not quite as capable but the learning
curve is not as steep.  Though that is practically the same as
compiling 5.1.x without -DRELOCATION.

Eric