Re: [Etherboot-developers] Memory allocation

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

Michael Brown <mb...@fe...> writes:

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

make bin/etherboot.img tends in this direction.
That is etherboot with all of the drivers compiled in.  
We still have a ways to go but we are not far off at the moment.

My basic point was that it is not hard to force the important
bits below 1MB if we need to.

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

I know there is something outstanding.  All I remember for certain
is that there was some a20 bug fixing in 5.0.x right at the start of
5.1.x that did get picked up in 5.1.x.

The only piece I am certain is missing are gatea20_unset calls in
5.1.x because of problems with relocation.  But it looks like you have
found the solution to that.  So we should be able to add them back in
as appropriate.

While we are thinking about it the a20 code needs to move out of
misc.c as it is highly arch dependent.

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

Eric