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

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

Eric W. Biederman wrote:
> 
> 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.
> 

Right.  Shouldn't be too difficult.

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

True, although SYSLINUX deals with this by always loading high, and if 
the image is a zImage it copies it to low memory immediately before 
invoking the kernel.

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

That's pretty much the only sane way to do it (and is, indeed, that 
MEMDISK does.)  The pain is actually getting the e820 map routines to 
work sanely.  The C files memdisk/msetup.c and memdisk/e820func.c are 
the interesting ones within MEMDISK; once you have that you can just 
call insertrange() to mark memory as a particular type.  parse_mem() 
then produces the non-e820 memory map types.

The tricky part was realizing

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

Remember, the SYSLINUX program itself needs to fit on floppies and take 
minimum amounts of space.  It's 7828 bytes in size at the moment, and 
the COM32 loader is just "load this file into memory at this address" -- 
no parsing whatsoever.

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

Why not just run a 32-bit LinuxBIOS on Opteron?  Or do you mean to the 
K8 memory controller and stuff?

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

Gotta love recursion...

	-hpa