Re: [Etherboot-developers] UNDI driver

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

On Thu, 29 May 2003, Georg Baum wrote:
> I did, but it did not work (cvs from today). The PXE implementation is Intel 
> Boot Agent Version 4.0.22, the NIC is an onboard eepro100. Here are the 
> messages:
> PXE loader for etherboot
> 0x27EK low memory
>  PXE    unloaded
> ROM segment 0x000 length 0x000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [00007e70,00017b80) to [076f02f0,07700000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
> Hunting for pixies...found !PXE at 0009de0...ok
> UNDI API call 0x0000 failed with status 0x006a

PXE chaining is failing.  I will try to sort out the pxeloader code so
that it leaves the !PXE structure in a valid state (unless one of Peter or
Vasil has already done this).  This looks like the same problem Marty was 
experiencing.

> Hunting for pixies...none found
> Hunting for ROMs...found 55AA at 000e0000...PCI:8086:1031...ok
> ROM contains IBA 4.0.22 Slot 0140 by Intel Corporation
> Located UNDI ROM supporting revision 2.1.0
> Installing UNDI driver code to 9d00:0000, data at 9380:0000
> UNDI driver created a pixie at 9d00:0070...ok
> API 9d00:0106 St 8c40:0800 UD 9380:94b0 UC 9d00:2050 BD 0000:3930 BC 
> 0000:5f86

And here we see one of the nice features of the driver at work: even 
though it failed to PXE-chain, it's trying to reload the PXE driver from 
ROM as a fallback strategy.  :)

> Initialized UNDI NIC with IO 0x7000, IRQ 11, MAC 00:00:E2:8C:5F:43
> NDIS type DIX+802.3 interface at 100 Mbps
> Searching for server (DHCP)...
> ..Me: 192.168.0.3, Server: 192.168.0.1
> Loading 
> 192.168.0.1:/tftpboot/lts/vmlinuz-2.4.19-ltsp-1-mknbi-1.2.7-10...(NBI)segment 
> [00092800, 000093A00) overlaps used basemem [00093000, 000A0000)
> error: not a valid image
> Unable to load file.
> <sleep>
> Note that the kernel image _is_ valid. After the sleep, it tries again with 
> different results and finally hangs after printing the "API 9d00:0106..." 
> line, but I think this is only a side-effect and the real error occurs 
> earlier.

The "not a valid image" message is misleading: the real error is the 
previous line talking about a segment overlap.  The image you are trying 
to load wants to be loaded at a location that would tread on the UNDI 
driver code.

Can you try enabling DEBUG_BASMEM in arch/i386/firmware/pcbios/basemem.c?  
This should print out diagnostic messages about base memory allocation, 
which will help us see what is going on.  It's possible (likely) that the 
!PXE structure from the first attempt is not being freed properly and so 
the second time round it loads it much lower in base memory than it would 
normally.  The alternative is that your UNDI driver is huge, in which case 
you will need to create an image that doesn't need to tread on that area 
of memory.

> Then I tried chaining from Etherboot, and the result is:
> ROM segment 0x1000 length 0x8000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [0000241b0,00033ec0) to [076f02f0,07700000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
> Hunting for pixies...none found
> Hunting for ROMs...found 55AA at 000e0000...PCI:8086:3577...not me 
> (8086:1031)
> ...none found
> Probing isa nic...
> <sleep>

It's not seeing the PXE ROM.  Do you have LAN enabled as part of the BIOS 
boot sequence?  I have found that some BIOSes (or possibly some PXE ROMs) 
will hide the PXE ROM if LAN is not listed as a BIOS boot device.

Michael