Re: [Etherboot-developers] Memory allocation

[Michael B. <mb...@fe...>]

On Wed, 28 May 2003, Eric W. Biederman wrote:
> > I didn't.  The UNDI driver (i.e. the one in the PXE ROM) plays about with
> > it whenever it gets bored and feels like causing some extra debugging
> > work.  I have a two-stage solution to this problem:
> > 1. Ensure Etherboot text is always within an even megabyte, so that 
> >    _real_call returns successfully and we make it all the way back to the 
> >    C code even if something nasty happens to A20.  (Hey, half your 
> >    memory's just disappeared?  No problem! :)
> That is a little limiting (etherboot text && stack must be in 1MB) but
> in practice this does not look like a problem.  Especially as special
> linker sections can force the issue if we exceed 1MB.

Weren't we restricted to 64KB until recently?  If we're going to exceed 
1MB in 5.2, we've got some serious code bloat!  :)

> > 2. Call gateA20_set() immediately after doing any UNDI API call.  Thanks 
> >    to (1), I can do this cleanly in C instead of assembler. 
> This is definitely a solution I like.
> On the same toon there is some outstanding gatea20 work that was don in 5.0.x
> that has never made it into 5.1.x.  Roughly it was disabling and reenabling
> gatea20 around the transitions to/from real mode.

Where is this code?  Grepping for a20/A20 in 5.0/src doesn't find it.

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

Michael