Re: [Etherboot-developers] Memory allocation

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

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

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

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

Me either.  The PXE spec seems to require it to some extent.  But just
skimming it I don't see how.
 
> [ 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. ]

There are 2 cases of real mode stubs.
Callbacks PXE-on-Etherboot.
The initial boot, and transitioning from a compressed image in an
    UMB to wherever we will finally land.

I can multiplex them all through the standard entry point in main
easily.  But I don't currently see how to reduce the UMB footprint.
And the trend for new NICs  (tg3 e1000) is that they require larger
drivers.

Eric