Re: [Etherboot-developers] Memory allocation

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

> > 2. Etherboot protected-mode stack.  I think this is within the Etherboot 
> >    text, somebody please confirm/correct me on this.
> Actually a better way of looking at Etherboot text and the stack is:
> Etherboot text+data+bss  They are all of a predetermined fixed size,
> and the protected mode stack is allocated in the bss.  The bss is important
> because it takes no space in the etherboot image but it is allocated
> statically at build time.
> static char buf[255];  or any other static variable without an initializer
> will be allocated in the bss.

Thanks, that's handy to know.

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

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

> > 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 );  ?  :-)

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

Michael