Re: [Etherboot-developers] UNDI driver

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

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

> > > Question 1: Is there currently any method for allocating base memory?  I
> > > need space for three structures:
> > Memory should be taken off of the TOP of the 640K chunk of memory.
> > That is the only way ancient DOS memory reporting APIs can cope.
> > And in etherboot that should not be hard to report.  We might want to
> > think of bounce buffers to hold data that will eventually go there.
> 
> OK, but am I right in thinking that there is currently no mechanism for 
> doing this in Etherboot?  I remember HPA mentioning code in MEMDISK that 
> could be ripped out for this purpose.

There are 2 cases of interest.
1) Code using etherboot as a library
2) Etherboot using an UNDI driver.

Unless an UNDI driver is allowed to allocate memory for itself
we don't need the code in MEMDISK.  That code is only needed
if we are not going to sever as a library.

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.

As for bounce buffers it would simply take a specialized memcpy to
use in osloader.c  

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.

> > Losing 128K of memory will have some interesting affects on mknbi and
> > friends.
> 
> It won't always be 128K; the UNDI driver specifies how much space it needs 
> for its code and data segments, so we can allocate only what's necessary.

Agreed.  I am just thinking we will need to make certain it works when
we allocate 128K.

The important point is that low addresses especially those below
1M are precious because the loaded image can count on them being
available.
 
> > For the temporary can you just use real_call and a buffer allocated on
> > the stack?  It has provisions for coping with data left on the return
> > stack.   This does not solve the issue but it means we only need the
> > temporary stack.
> 
> The largest chunk of data I need is the whole transmit buffer; I need to 
> make this available to the real-mode UNDI API transmit call, which AFAIK 
> means copying it into base memory.  Is there enough room for this on the 
> stack and, if so, can you give me some pointers on how it works? 

Ok.  I have something that works for returning data in real_call
but I don't have a parameter for passing extra data on the stack.
That probably would not be too hard but I can certainly see the
value in just allocating a buffer from the top of low memory.

Since we are already allocating relatively fixed buffers it should
not be hard to allocate one more.

> I'll 
> need to know the addresses of the structures before going into the 
> assembler code, otherwise my assembler wrappers will have to be 
> significantly more complex.
> 
> > > Question 2: I have an assembly routine _undi_call that is a wrapper around 
> > > the real-mode UNDI API calls.  
> > Does _undi_call use real_call?
> 
> Yes.  I've checked in the code to pcbios.S temporarily, so that (a) people 
> can build and test the driver and (b) you can see exactly what the wrapper 
> currently does.
> 
> Please note that I've basically learnt x86 assembler over the past four 
> days, so there's bound to be a much simpler way of doing it.
> 
> > The big question is how small is undi_call?  If it is small enough
> > placing it pcbios.S may make sense.  As it could be packed into some
> > of the space usually used for alignment or what not.  But I do see
> > the point, if it has size putting it in every driver is probably
> > worse.
> 
> 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.

Hopefully I have pointed you enough in the correct direction for
a while.

Eric