Re: [Etherboot-developers] Memory allocation

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

> > > > 4. How do we avoid treading on other entities?  (In particular: the 
> > > >    Intel UNDI driver seems to install something just above the 1MB mark.  
> > > >    prep_segment() then obliterates this, because it can't tell that the
> > > >    region is in use).
> > > Very good question.  It looks like we need to rescan things (at least
> > > in the UNDI driver case.
> > UNDI driver was a false alert; it turned out to be the status of the A20 
> > line.  I thought I must be treading on something UNDI-related when I 
> > loaded a segment in the [1MB,2MB) range, but actually I was simply 
> > vapourising the contents of base memory thanks to A20.  Have you ever 
> > tried doing memset ( phys_to_virt(0), '!', 1<<20 );  ?  :-)
> How did you fail to enable the a20 line?

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

2. Call gateA20_set() immediately after doing any UNDI API call.  Thanks 
   to (1), I can do this cleanly in C instead of assembler. 

> > I've looked into PMM a little more and we can, I think, ignore it; it is 
> > to do with allocating memory above 1MB but only during POST.  As soon as 
> > Int 19 happens (i.e. before we get control), any memory allocated via PMM 
> > is freed and PMM ceases to be available.
> 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.

[ Some working real mode stub code would, however, come in handy for the 
  case of PXE-on-Etherboot; we would need to provide a real-mode entry 
  point. ]

Michael