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

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

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

> Eric W. Biederman wrote:
> >>
> >>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.
> >
> 
> This is actually something that's surprisingly painful, mostly because of the
> sheer number of calls, and the complexity of the E820 memory map. MEMDISK (part
> of the SYSLINUX package, but actually a standalone program) does it, so you
> might be able to snarf some code.  The code is currently GPL; if that's not OK
> with you and you want to snarf pieces check with me first.

All of etherboot is GPL'd so we should not have a problem there.

> > 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.
> >
> 
> I think that's actually how most PXE stacks operate.

Just to get the thought recorded what looks to be needed is to
build a pxe_stub.S that has the PXEENV structure and the 16bit stubs
that call the 32bit code.  And something to copy that down to low
memory.

> >>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.
> >
> 
> If you're occupying less than 128K of conventional then you're actually better
> than most commercial PXE stacks. 

Etherboot can still load zImages, so it has been a requirement.

> This would probably be a lot less painful than
> hooking INT 15h, although I'm pretty agnostic about it.

Actually I suspect if INT 15h is just replaced for the memory
functions the code should not be very difficult to write.  Which
should build the corrected map once in C before proceeding.

> > 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.
> 
> <nod> I have some pretty similar code in SYSLINUX, to support COM32 programs, in
> 
> MEMDISK (because I wanted to write the MEMDISK installer in C), as well as in
> the never-completed Genesis project... so I'm familar with the
> concept :)

I still chuckle at the COM32 concept as it looks like going quite a
ways to avoid 300 bytes of overhead for an ELF header...  Though I can
see how it can be useful if space is at a very high premium.

> > 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.
> 
> Cool.  Don't know if/when I would have time to look at it, but I've put it on my
> list.  (If someone else is interested in working on it, though, please do go
> ahead...)

Well we will see how it goes.

Currently I am busy porting LinuxBIOS to the Opteron so I won't be able to get
at very much stuff for a while.

Though once it works it should be possible to test the code by pxe booting
etherboot :)

Eric