Re: [Etherboot-developers] Memory allocation

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

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

> > > 3. Etherboot real-mode stack.  This is always at the top of free base 
> > >    memory (as defined by 40:13), provided that Etherboot is the only thing 
> > >    allocating base memory.
> > >    NB. Other code may allocate base memory by changing the counter at
> > >    40:13.  We should really recalculate the real-mode stack top each time
> > >    we make a _real_call, based on the current contents of 40:13.  Is there 
> > >    any reason why we can't do this?  (I'm thinking of LinuxBIOS in 
> > >    particular; does this use the same 40:13 counter?)
> > LinuxBIOS does not use 40:13 at the present time.  In fact the only
> > interface to the outside world (Besides the simple LinuxBIOS table)
> > visible when running etherboot is etherboot itself.
> > Care needs to be take because I'm not certain 40:13 is reliable.  I
> > know there are several cases that do BIOS calls to get this
> > information.  And the linux kernel explicitly does not read it with
> > a comment about it being unreliable.
> 
> The PXE spec actually instructs you to use 40:13, so I'm comfortable doing 
> it in the case of the Etherboot UNDI driver; if 40:13 doesn't work then 
> the PXE driver would probably fail anyway.
> 
> 40:13 is used only by routines in basemem.c.  However, I did modify 
> pcbios/memsizes.c to make a call to adjust_real_mode_stack() in basemem.c 
> in order to centralise the management of the real mode stack location.  If 
> you think 40:13 might not be reliable then you may want to revert this 
> change.

It is quite possible there is a strong difference between what is reliable
by the time the OS starts, and what is reliable beforehand.  Unless we
have reason to suspect I would suggest leaving it in.
 
> > > 5. Allocated base memory, from 640K down to [40:13]k.  Includes the BIOS 
> > >    EPDA.
> > > The interaction of these five areas with prep_segment() has the following 
> > > problems:
> > > a. No checks are made for (3).  prep_segment will happily trash the 
> > >    real-mode stack and _real_call will happily walk all over an area that
> > >    prep_segment has prepared.
> > Correct.  That was an after thought.
> 
> What is the size of the real-mode stack, and shall we add it in as another 
> check in prep_segment?

At most 64K. As for a check that is a good question.  Ideally we should be
able to avoid the areas claimed by prep_segment.  But that would require
remember things.

> > > 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?
 
> > > 5. Would it take into account the BIOS PMM, if it exists?
> > Possibly.  I don't recall what that is...
> > If it is BIOS services for allocating memory above 1MB then that would
> > be a good idea.
> 
> 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.

Eric