Re: [Etherboot-developers] Memory allocation

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

> > > > > O.k.  One issue on my wishlist is to have a stub that loads etherboot
> > > > > into high memory (>1MB) from the rom initialization code, and then just
> > > > > leaves a very small stub in real mode.  Given that I have seen several
> > > > > BIOS's start acting erratically because of their real mode storage for
> > > > > options roms was used up.  This could make etherboot more reliable.
> > > > Could be interesting; PMM is potentially in charge of high memory at the 
> > > > time the initialisation code is called (assuming the BIOS supports PMM), 
> > > > but anything it allocates is lost before the system starts booting.  I'm 
> > > > not sure how you'd work around that problem.
> > > Me either.  The PXE spec seems to require it to some extent.  But just
> > > skimming it I don't see how.
> > 
> > It's not very clear.  PXE spec seems to state that the PXE ROM should move 
> > itself into upper memory using PMM, implying that it stays there ready for 
> > when the system boots.  However, PMM spec states that this is impossible; 
> > anything allocated by PMM is for POST-time only and will be destroyed at 
> > boot time.
> > 
> > To make it even more confusing, a disassembly of an Intel PXE ROM shows 
> > debug messages that mention PMM, but AFAICT the code never makes any PMM 
> > API calls.  (At least, the PMM signature, "$PMM", doesn't appear anywhere 
> > within the ROM and this is the only way to locate PMM services within the 
> > BIOS.)
> 
> Interesting...
> 
> Perhaps the guys who wrote the pxe spec were confused.

I have just had an interesting conversation and I now have
a reasonable explanation why BIOS code has problems with
protected mode.  The problem is that code run in vm86 mode frequently
makes use of BIOS services.  And if the BIOS services are implemented 
in protected mode vm86 mode does not work.

Which would explain why there are no BIOS interfaces for handling
this problem.  

For the case of making etherboot UMB friendly I would suggest we look
at copying the compressing image to low memory, in loader.S and
reserving that memory as appropriate.

Eric