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

[H. P. A. <hp...@zy...>]

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.

> 
> 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.

>>>
>>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.  This would probably be a lot 
less painful than hooking INT 15h, although I'm pretty agnostic about it.

> 
> 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 :)

> 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...)

	-hpa