Re: [Etherboot-developers] UNDI driver

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

On Sun, 1 Jun 2003, Marty Connor wrote:
> 3Com 3C905C-TXM   5.1.8 undi.zpxe           PXE ROM            Failed
> ROM segment 0x0000 length 0x0000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [0000c240,0001bc90) to [07eb05b0,07ec0000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
> Trying to allocate 1 kB of base memory, 639 kB free
> Hunting for pixies...found !PXE at 0009d7a0...in free base memory!
> 
> WARNING: a valid !PXE structure was found in an area of memory marked  
> as free!
> Ignoring and continuing, but this may cause problems later!
> 
> none found
> Hunting for ROMs...found 55AA at 000cc000...PCI:10b7:9200...ok
> ROM contains MBA UNDI by 3Com
> Located UNDI ROM supporting revision 2.1.0
> Trying to allocate 10 kB of base memory, 638 kB free
> Trying to allocate 13 kB of base memory, 628 kB free
> Installing UNDI driver code to 9d00:0000, data at 99c0:0000
> UNDI driver created a pixie at 9d00:0060...ok
> API 9d00:00f6 St 0000:0000 UD 99c0:3284 UC 9d00:24c0 BD 0000:0000 BC  
> 0000:0000
> Initialized UNDI NIC

This has stopped in the middle of a printf() call: the line of code is

	printf ( "Initialized UNDI NIC with IO %#hx, IRQ %d, MAC %!\n",
			 undi.pxs->undi_get_information.BaseIo,
			 undi.pxs->undi_get_information.IntNumber,
			 undi.pxs->undi_get_information.CurrentNodeAddress );

in which undi.pxs is definitely non-NULL because it has already been used.

The only thing I can think of that could cause this is a corrupted 
interrupt handler.  I've taken a look at pxeprefix.S.  It performs the PXE 
API calls PXENV_UNDI_SHUTDOWN, PXENV_STOP_UNDI and PXENV_UNLOAD_STACK.  It 
doesn't check the return status of any of these calls and it then proceeds 
to forcibly free base memory, even if the API calls returned "No, you 
can't free base memory because I've got an interrupt handler installed 
that I can't unhook for some reason".

In order to get better diagnostics, I've added a config option 
-DPXELOADER_KEEP_ALL.  This will cause pxeprefix.S to skip all its 
unloading, and will cause undi.c to perform the same sequence of PXE API 
calls.  This way, we get to see any errors that occur.

Could you retry this arrangement (PXE chaining) with DEBUG_BASEMEM enabled 
in arch/i386/firmware/pcbios/basemem.c and three sets of configuration 
options in arch/i386/Config:

1.  CFLAGS+=-DPXELOADER_KEEP_ALL
2.  CFLAGS+=-DPXELOADER_KEEP_UNDI
3.  (nothing)


PXE chaining is working for me via all three routes, although I get the 
expected warning about a valid !PXE structure being found in free base 
memory with option (3).  (I haven't edited pxeprefix.S to delete the !PXE 
signature yet).

Michael