Re: [Etherboot-developers] UNDI driver

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

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

> There is now a very-nearly working UNDI driver in 5.1 CVS under
> arch/i386/drivers/net.  This driver allows Etherboot to work with any NIC
> for which an UNDI option ROM is provided.
> 
> The driver does not require Etherboot to be started by chaining from PXE;  
> it will scan for an UNDI ROM and initialise it fully from scratch.  I have
> been testing by booting from floppy, which works fine.  I imagine that 
> PXE-chaining would also work, although I haven't tested it yet.
> 
> Note that you cannot yet use the Etherboot UNDI driver to actually boot a
> kernel;  although all the routines are working and the driver can get a
> DHCP lease and start downloading a file, it dies instantly because the
> downloaded file stomps right over the PXE UNDI driver.  In order to fix 
> this, I need to sort out a method for allocating base memory in Etherboot.
> 
> 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.

Losing 128K of memory will have some interesting affects on mknbi and
friends.

> 1. The PXE UNDI driver code segment (up to 64K, probably 16K)
> 2. The PXE UNDI driver data segment (up to 64K, probably 16K)
> 3. Temporary buffers that I can stick data into while calling the 
>    real-mode UNDI API (about 2-3K).

Plan on the UNDI drivers taking 64K the ones for at least
Broadcom's gigabit NIC almost certainly will.

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.

> I'm currently (as a quick "test-the-driver" method) dumping these at
> pseudo-random places in base memory, which works fine up to the point that
> a kernel image loads...  :-)
> 
> 
> 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?

> I've placed this in pcbios.S but haven't 
> yet checked it in because it seems like a bad place to put it; it would 
> end up being compiled in to every Etherboot image, not just the UNDI one.  
> Ideally, I'd like to create a file undi_wrapper.S in 
> arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
> have to edit genrules.pl to achieve this, unless anyone can suggest a 
> quick and easy method?

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.

Eric