Re: [Etherboot-developers] UNDI driver

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

> In etherboot we currently keep track of which memory is available for
> allocation.  See the e820 structure and it's kin.  We refuse
> to step on any memory that is listed as used.
> <snip>
> We currently have routines to allocate memory in a general fashion
> but the heap is placed above 1M.   So we call allocate bounce
> buffers but the below 1M case still needs to be handled.  It should
> be relatively straight forward however.
> <snip>
> The important point is that low addresses especially those below
> 1M are precious because the loaded image can count on them being
> available.

An image loading via PXE would not be able to count on them being
available; PXE drivers expect to be placed at the top of base memory.  By
using up base memory in the case of the Etherboot UNDI driver, we're doing
no worse than PXE does.  We don't have a choice about loading the UNDI
driver under 1M; some of the API calls have to be made in real mode.

I'm proposing the following solution, based on discussion thus far:

1. Add arch/i386/firmware/pcbios/basemem.c, #ifdeffed with PCBIOS, 
   containing routines to allocate base memory in the BIOS-expected way 
   (i.e. by simply updating the value at 40:13).

2. Add a check in prep_segment() in core/osloader.c, also #ifdeffed with
   PCBIOS, that will check that the segment being prepared doesn't overlap 
   the BIOS allocated low memory area.

3. The Etherboot UNDI driver will allocate space for the UNDI driver's 
   code and data segments in base memory, which is where it expects to be 
   put.  These have to go under 1M anyway; they are used in real mode.

4. The Etherboot UNDI driver will also allocate ETH_FRAME_LEN bytes of 
   base memory for the real-mode transmit buffer, plus a few tens of bytes 
   for structures like the UNDI API call parameter structure and the UNDI 
   transmit buffer descriptor.

Total base memory usage will be around 2K + UNDI driver data segment + 
UNDI driver code segment.

> > It's tiny; just a small wrapper around real_call.  I pass in a structure
> > that contains the address of the UNDI API routine and 3 words to push onto
> > the stack before making the API call.  _undi_call just switches to real 
> > mode, pushes the parameters onto the stack, jumps to the specified 
> > address, cleans up the stack and returns.  It's not far away from being a 
> > generic "call any real-mode routine" wrapper.  (It might be handy to have 
> > one of these, thinking about it.)
> 1) A generic "call any real-mode routine" wrappers suffers from 2
> things.  That handling the segment:offset addressing is a pain.
> That there are different calling conventions in the dos world.
> 2) real_call is as close to fully generic as you can get and not
> address those issues.
> 3) a generic interface for the calling convention used in the undi
> code would be fine.  Then you can make cute little stubs for the
> undi entry points in your driver.

(3) is what we've got at the moment.  For the sake of elegance, I'm 
proposing to split the tiny _undi_call routine into a separate 
undi_wrapper.S file and modify the Makefiles in some way to accommodate 
this.

Final comments / suggestions welcome; coding will probably happen this 
evening (UK time).

Michael