Re: [Etherboot-developers] UNDI driver

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

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

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

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

Michael