Re: [Etherboot-developers] UNDI driver

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

On Sat, 31 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
> Is this         ^            ^
> correct?

I think that's normal when Etherboot doesn't boot from ROM.

> > Can you try enabling DEBUG_BASMEM in arch/i386/firmware/pcbios/basemem.c?
> I did. The result:
> 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,00017c80) to [076f01f0,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
> Trying to allocate 1 kB of base memory, 638 kB free

Your BIOS has a 2kB Extended BIOS Data Area, which is what is occupying 
the top 2 kB of base memory.  Nothing to worry about yet, and it shows 
that the memory allocated to the PXE driver that loaded Etherboot has been 
freed.

The 1kB allocated here is for real-mode parameter structures used by the 
Etherboot UNDI driver in making UNDI API calls.

> Hunting for pixies...found !PXE at 0009de0...ok

Whoops, this is in an area of base memory marked as free.  (This is the 
"PXE loader not trashing !PXE structure" problem.)

I've added a check to the routine that scans for !PXE structures ("hunts 
for pixies") - it will now give a warning and ignore any valid !PXE 
structures found in free base memory.

> UNDI API call 0x0000 failed with status 0x006a
> 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
> Trying to allocate 9 kB of base memory, 637 kB free
> Trying to allocate 38 kB of base memory, 628 kB free

OK, this looks like the problem.  Your UNDI driver (the one in ROM) needs 
to be given 9kB for its code segment and 38kB(!) for its data segment.  
There's no way around this; these are values hard-coded into the PXE ROM.

> 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
> 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)...
> Trying to allocate 2 kB of base memory, 590 kB free

This is the last memory allocation that takes place.  It's for the 
transmit buffer; Etherboot needs to copy the data to be transmitted into 
base memory so that it can be passed to the real-mode UNDI API call.

> ..Me: 192.168.0.3, Server: 192.168.0.1
> Loading 192.168.0.1:/tftpboot/lts/eb-5.1.8cvs-undi.nbi...(NBI)segment 
> [00093E00, 000094000) overlaps used basemem [00093000, 000A0000)
> error: not a valid image
> Unable to load file.
> <sleep>
> This was with an etherboot NBI.

The conclusion is that you have the following demands on base memory:

 2 kB BIOS data area
 1 kB Etherboot real-mode API call parameter area
 9 kB PXE UNDI driver code segment
38 kB PXE UNDI driver data segment
 2 kB Etherboot real-mode API call transmit buffer area

52 kB total

This 52kB is at the top of base memory and so occupies the addresses 
[00093000, 000A0000).  The image you are trying to load wants to be loaded 
into this area, but this is not possible.

The only solution is to create an image that doesn't want to be loaded 
into this area.  I believe it's possible for mknbi to create images that 
load elsewhere - Ken?

> > 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.
> Do you know a way to get the size of the UNDI driver?

You can see it in the line

  API 9d00:0106 St 8c40:0800 UD 9380:94b0 UC 9d00:2050 BD 0000:3930 BC 
  0000:5f86

This breaks down as:

API entry point 9d00:0106
Real-mode stack 8c40:0000 to 8c40:0800 (ignored)
UNDI driver data segment 9380:0000 to 9380:94b0
UNDI driver code segment 9d00:0000 to 9d00:2050
Base code data segment unused (0000:xxxx)
Base code code segment unused (0000:xxxx)

From this you can see the size of the UNDI driver segments: data is 0x94b0
bytes = 37.2 kB, code is 0x2050 bytes = 8.1 kB.  BIOS memory allocation 
has a granularity of 1 kB so these are rounded up to 38 kB and 9 kB.

> > > Then I tried chaining from Etherboot, and the result is:
> > 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.
> It was enabled, but not the first option. If I do PXE -> Etherboot(eepro100) 
> -> Etherboot(undi) the undi driver behaves exactly as it does when loading 
> directly from PXE.
> The BIOS of this machine is even worse: It seems that the PXE ROM is not 
> shown unless it was successfully executed.

I don't know what we can do about that; I'm not sure how Option ROMs can 
hide themselves.  Any ideas?

Michael