Thread: Re: [Etherboot-developers] UNDI driver
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Peter L. <P.L...@sy...> - 2003-05-19 17:48:06
|
> 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 N= IC > for which an UNDI option ROM is provided. It's annoying that neither Vasil nor I will get the glory, but I'm pleased that someone has finally worked up the steam. Well done, Michael. > The driver does not require Etherboot to be started by chaining from PX= E; = > it will scan for an UNDI ROM and initialise it fully from scratch. I h= ave > been testing by booting from floppy, which works fine. = Nice.... we can have driver specific builds with a PXE "last resort" driver regardless of the mechanism. Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE initialisation (and therefore probably everyone else's, though I haven't tried) with multiple NICs that the MAC address used is that of the *last* NIC to initialise? This confuses people because it almost always means that it never uses the one that Linux calls eth0. > I imagine that PXE-chaining would also work, although I haven't tested > it yet. PXE chaining is, of course, what lots of people want so that they don't have to worry about loading the right driver. Just remember to leave PXE loaded, since by default the first act of PXE-chaining to is to unload PXE. :) Most people just pick up pxelinux as a compiled image and have no reason to build. I'll be interested to see how many people want a no-brainer PXE/UNDI image, as opposed to driver-specific, from rom-o-matic. > 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? Dumb question - does anything make UNDI fundamentally different from a nic driver? That's how people will want to treat it, so I say treat it exactly like a driver, with the possible exception that UNDI is included by default as a last resort driver for PXE images but not others. |
|
From: <prl...@sy...> - 2003-05-19 20:00:33
|
> > Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE > > initialisation (and therefore probably everyone else's, though I haven't > > tried) with multiple NICs that the MAC address used is that of the > > *last* NIC to initialise? This confuses people because it almost always > > means that it never uses the one that Linux calls eth0. > > MAC address used is the MAC address stored on the NIC EEPROM; the one > known to UNDI as the "Permanent Node Address". > > We will use PCI cards in the same order that Etherboot normally finds > them. If Etherboot uses the same scanning order as Linux, then we should > end up using the one that Linux calls eth0. This is independent of the > Etherboot UNDI driver; it's determined by pci.c. The order is "normal Etherboot order, whatever that is". Good, this is a definite win. > The UNDI driver will therefore consist of two files: undi.c and > undi_wrapper.S (plus the headers); most drivers consist only of a single > C file. The Makefile will, I think, have to be altered to allow drivers > to consist of more than just the one file. Oh, I see. I suppose you could munge the assembler into the C (if it's GNU friendly, but it's a good thing to have drivers be >1 C file. |
|
From: <prl...@sy...> - 2003-05-19 20:20:26
|
> > I like the fact we can unload and reload the PXE stack. The only dow= nside > > of this is that we don't know what NIC we booted off of. Oh well. > = > You do; when you initialise a PXE stack you have to pass in the PCI bus= , > device and function. The structure is "take this PCI device, try to > locate and initialise an UNDI driver for it", rather than "try to locat= e > and initialise an UNDI driver, let it find its own NIC". Eric, if I understand Michael right, the issue I'm griping about is more how BIOSen interacts with the PXE code. The dumb BIOS action we've seen is to initialise everything (in PCI scan order) and then try to boot off the first nic (in PCI scan order). But as there's a common context for all these initialisations, the upshot is that though we actually find nic 0, but we use the context (MAC address etc) from the LAST nic in the search order (or rather, the last nic that initialised). D'oh... where are 2 nics embedded on a mobo, this may work more sanely because the BIOS hopefully knows exactly what is in there. Our local workround was to scrunge the 3Com nic rom for all everything except the first NIC. Michael's code use the normal Etherboot search order, initialises each NIC and then immediately tries to use the NIS; only if it fails and needs to try the next nic will it go on and initialise *that*. So the context we use is always the right one for the nic. Vasil pointed out to me recently that Etherboot is a very effective way of getting round buggy BIOSen. :) Here is another example. |
|
From: Michael B. <mb...@fe...> - 2003-05-19 23:55:27
|
> But as there's a common context for all these initialisations, the > upshot is that though we actually find nic 0, but we use the context > (MAC address etc) from the LAST nic in the search order (or rather, the > last nic that initialised). This doesn't make a lot of sense; only one UNDI driver should ever get initialised (unless it fails to boot and another one is given a chance), and the BIOS should pass the PCI bus, device and function number in AX when it calls the first two initialisation routines. The UNDI driver should then use this information to locate its hardware, from which it can extract its MAC address. Not that it matters, given that Etherboot doesn't suffer from this particular problem, but it's a curiosity. Incidentally, the interaction between multiple UNDI ROMs and multiple NICs is not well defined in Etherboot at the moment. UNDI ROMs will be tried sequentially; if one fails to boot then the next will be tried the next time probe() is called. However, if we have two NICs and two UNDI ROMs, this means that they will be tried in the following combination: NIC 1, UNDI ROM A NIC 2, UNDI ROM B where there is no necessary connection between NIC 1 and UNDI ROM A other than that NIC 1 is the first NIC found in the system and UNDI ROM A is the first UNDI ROM found in the system (which won't necessarily belong to NIC 1). Theoretically, it's possible to use romaddr from the PCI device to locate the ROM, but I always seem to get a zero in romaddr, even when the ROM can be detected by scanning. What we probably want to do is try combinations in the following order: NIC 1, UNDI ROM A NIC 2, UNDI ROM A NIC 1, UNDI ROM B NIC 2, UNDI ROM B which could be achieved by judicious use of a few static variables. However, in the case when NICs 1 and 2 are of different types, we could have problems: the UNDI ROMs may not bother to check that the hardware device specified by AX is of the correct type before they start setting registers etc... Michael |
|
From: <ke...@us...> - 2003-05-31 15:22:18
|
>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? Yes, you can tell mknbi to relocate its segments to [0x80000, 0x90000). |
|
From: Michael B. <mb...@fe...> - 2003-05-31 17:12:41
|
On Sun, 1 Jun 2003, Ken Yap wrote: > >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? > Yes, you can tell mknbi to relocate its segments to [0x80000, 0x90000). Thanks; I see the option (--relocseg=0x8000) on the man page. I'm not familiar with first32.c; are there any implications for using a different load address and is there any reason (other than the need to recompile) why we can't use arbitrary load addresses in base memory? Michael |
|
From: Marty C. <md...@et...> - 2003-06-01 21:58:18
|
I've been doing some testing of the UNDI driver with 5.1.8, and have
some results that I hope will help with debugging.
EXECUTIVE SUMMARY
We're getting closer! In the table below, the undi driver worked on
both cards when booted from floppy. It failed when chained from PXE
ROM. I am hopeful that the output below will help isolate the problem.
I'd appreciate any suggestions on debugging the PXE ->
ETHERBOOT_UNDI_DRIVER case. It would be way cool if we could tell
people that they could use the undi.zpxe file to boot any of their PXE
cards. It's already way cool that we can boot the 3Com and Intel cards
from the same floppy.
I appreciate the difficulty of getting two booting strategies that both
think they own the machine to cooperate (or at least not kill each
other). I suspect there are a few ways to get them to work together.
One thought is to wipe all memory marked as free so that Etherboot's
UNDI driver doesn't get confused by stuff left over from the PXE load
of Etherboot. I'm also wondering if the Ethernet card itself might be
in an odd state since it was just used to load Etherboot. This reminds
me a bit of when we used to have problems because we didn't disable
certain cards after loading the kernel.
But I'm just guessing. Hopefully the following information will be
helpful in getting the code to explain what is happening. Maybe a few
other folks will join in the testing fun. I've included some
information on how to re-tag the kernel configure /etc/dhcpd.conf for
those that might be interested in helping get PXE UNDI chaining work.
Thanks to everyone who is working this problem. It's actually quite
nice to follow the discussions (whoever know that memory allocation
could be soooooooo exciting! :p )
Give a shout if I can test anything else.
Regards,
Marty
NIC Etherboot Version Boot Media Result
--- ----------------- ---------- ------
3Com 3C905C-TXM 5.1.8 3c905c-tpo.zfd0 Floppy OK
3Com 3C905C-TXM 5.1.8 undi.zfd0 Floppy OK
3Com 3C905C-TXM 5.1.8 3c905c-tpo.zpxe PXE ROM OK
3Com 3C905C-TXM 5.1.8 undi.zpxe PXE ROM Failed
Intel EEPRO100 5.1.8 eepro100.zfd0 Floppy OK
Intel EEPRO100 5.1.8 undi.zfd0 Floppy OK
Intel EEPRO100 5.1.8 eepro100.zpxe PXE ROM OK
Intel EEPRO100 5.1.8 undi.zpxe PXE ROM Failed
I used the CONSOLE_DUAL option of Etherboot to gather console output.
DISCUSSION
Following advice from Michael and Ken, I created a tagged kernel that
loaded at segment 0x8000, in order avoid a conflict with other code
loading in segment 0x9000.
I did this by downloading the file
http://prdownloads.sourceforge.net/ltsp/ltsp_initrd_kit-3.0.5-
i386.tgz?download
and untaring it. This gave me a copy of the untagged kernel
"bzImage-2.4.19-ltsp-1" to work with.
I also installed downloaded and installed mknbi-1.4 from:
http://prdownloads.sourceforge.net/etherboot/mknbi-1.4.0-1.noarch.rpm
This allowed me to hack a simple script to retag the kernel:
========
:
# This script tags a kernel with mknbi-linux with relocation to avoid
# problems when other software is using the 0x9000 segment.
mknbi-linux --output=`pwd`/ltsp-0x8000.nb \
--append="init=/linuxrc rw" \
--rootdir="/dev/ram0" \
--relocseg=0x8000 \
bzImage-2.4.19-ltsp-1 \
initrd-2.4.19-ltsp-1.gz
========
This created the file ltsp-0x8000.nb which I copied to /tftpboot for
later use.
Running disnbi on the image gives:
=========
$ disnbi /tftpboot/ltsp-0x8000.nb
Type: NBI
Header location: 8220:0000
Start address: 00082800 (flat)
Flags:
Vendor data: mknbi-linux-1.4.0
Segment number 1
Load address: 00082800
Image length: 4608
Memory length: 6144
Position: Absolute
Vendor tag: 16
Segment number 2
Load address: 00082400
Image length: 512
Memory length: 2048
Position: Absolute
Vendor tag: 17
Segment number 3
Load address: 00080000
Image length: 512
Memory length: 512
Position: Absolute
Vendor tag: 18
Segment number 4
Load address: 00080200
Image length: 5120
Memory length: 8192
Position: Absolute
Vendor tag: 19
Segment number 5
Load address: 00100000
Image length: 673792
Memory length: 673792
Position: Absolute
Vendor tag: 20
Segment number 6
Load address: 001a5000
Image length: 733184
Memory length: 733184
Position: Absolute
Vendor tag: 21
Vendor data: ""
Vendor data in hex: 00 00 00 00
===========
I modified my /etc/dhcpd.conf file to test two PXE cards, one 3Com and
one Intel. Here is the relevent section:
===========
# 3COM PXE Card
host ws137 {
hardware ethernet 00:01:02:59:03:d5;
fixed-address 192.168.2.137;
if substring (option vendor-class-identifier, 0, 9) =
"PXEClient" {
filename "/undi.zpxe";
# filename "/3c905c-tpo.zpxe";
} else if substring (option vendor-class-identifier, 0, 9) =
"Etherboot" {
filename "/ltsp-0x8000.nb";
# filename "/lts/vmlinuz-2.4.19-ltsp-1";
option vendor-encapsulated-options
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
}
}
# Intel PXE Card
host ws138 {
hardware ethernet 00:02:B3:25:45:56;
fixed-address 192.168.2.138;
if substring (option vendor-class-identifier, 0, 9) =
"PXEClient" {
filename "/undi.zpxe";
# filename "/eepro100.zpxe";
} else if substring (option vendor-class-identifier, 0, 9) =
"Etherboot" {
filename "/ltsp-0x8000.nb";
# filename "/lts/vmlinuz-2.4.19-ltsp-1";
option vendor-encapsulated-options
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
}
}
===========
I then ran a series of tests on each card. Here is a summary:
NIC Etherboot Version Boot Media Result
--- ----------------- ---------- ------
3Com 3C905C-TXM 5.1.8 3c905c-tpo.zfd0 Floppy Success
3Com 3C905C-TXM 5.1.8 undi.zfd0 Floppy Success
3Com 3C905C-TXM 5.1.8 3c905c-tpo.zpxe PXE ROM Success
3Com 3C905C-TXM 5.1.8 undi.zpxe PXE ROM Failed
Intel EEPRO100 5.1.8 eepro100.zfd0 Floppy Success
Intel EEPRO100 5.1.8 undi.zfd0 Floppy Success
Intel EEPRO100 5.1.8 eepro100.zpxe PXE ROM Success
Intel EEPRO100 5.1.8 undi.zpxe PXE ROM Failed
===========
I used the CONSOLE_DUAL option of Etherboot to gather console output.
Here are the outputs from the various test:
===========
3Com 3C905C-TXM 5.1.8 3c905c-tpo.zfd0 Floppy Success
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [3C90X]
Relocating _text from: [00014120,00023610) to [07eb0b10,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[3c905c-tpo]
3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc.
Portions Copyright 1999 Steve Smith
Provided with ABSOLUTELY NO WARRANTY.
------------------------------------------------------------------------
-------
MAC Address = 00:01:02:59:03:D5
Connectors present: 10Base-T / 100Base-TX.
Searching for server (DHCP)...
..Me: 192.168.2.137, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb
...(NBI)...................................
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
...done
Issuing RESET:
==============
3Com 3C905C-TXM 5.1.8 undi.zfd0 Floppy Success
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [00014440,00023e90) 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...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 with IO 0xdc00, IRQ 11, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 615 kB free
..Me: 192.168.2.137, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb
...(NBI)...................................
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
...done
Freed 2 kB base memory, 615 kB now free
Freed 13 kB base memory, 628 kB now free
Freed 10 kB base memory, 638 kB now free
Freed 1 kB base memory, 639 kB now free
============
3Com 3C905C-TXM 5.1.8 3c905c-tpo.zpxe PXE ROM Success
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [3C90X]
Relocating _text from: [0000bf20,0001b410) to [07eb0b10,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[3c905c-tpo]
3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc.
Portions Copyright 1999 Steve Smith
Provided with ABSOLUTELY NO WARRANTY.
------------------------------------------------------------------------
-------
MAC Address = 00:01:02:59:03:D5
Connectors present: 10Base-T / 100Base-TX.
Searching for server (DHCP)...
..Me: 192.168.2.137, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb
...(NBI)...................................
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
....done
Issuing RESET:
==============
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
==============
Intel EEPRO100 5.1.8 eepro100.zfd0 Floppy Success
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [EEPRO100]
Relocating _text from: [00013ed0,000234e0) to [07eb09f0,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[eepro100]Ethernet addr: 00:02:B3:25:45:56
Searching for server (DHCP)...
..Me: 192.168.2.138, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb
...(NBI)...................................
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
...done
===============
Intel EEPRO100 5.1.8 undi.zfd0 Floppy Success
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [00014440,00023e90) 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...none found
Hunting for ROMs...found 55AA at 000cc000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 638 kB free
Trying to allocate 20 kB of base memory, 630 kB free
Installing UNDI driver code to 9d80:0000, data at 9880:0000
UNDI driver created a pixie at 9d80:0070...ok
API 9d80:0106 St 9140:0800 UD 9880:4d30 UC 9d80:1e70 BD 0000:37c0 BC
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 11, MAC 00:02:B3:25:45:56
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 610 kB free
..Me: 192.168.2.138, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb
...(NBI)...................................
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
...done
Freed 2 kB base memory, 610 kB now free
Freed 20 kB base memory, 630 kB now free
Freed 8 kB base memory, 638 kB now free
Freed 1 kB base memory, 639 kB now free
===============
Intel EEPRO100 5.1.8 eepro100.zpxe PXE ROM Success
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [EEPRO100]
Relocating _text from: [0000bcd0,0001b2e0) to [07eb09f0,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[eepro100]Ethernet addr: 00:02:B3:25:45:56
Searching for server (DHCP)...
..Me: 192.168.2.138, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb
...(NBI)...................................
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
........
........................................................................
...done
==============
Intel EEPRO100 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, 638 kB free
Hunting for pixies...found !PXE at 0009dba0...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:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 637 kB free
Trying to allocate 20 kB of base memory, 629 kB free
Installing UNDI driver code to 9d40:0000, data at 9840:0000
UNDI driver created a pixie at 9d40:0070...ok
API 9d40:0106 St 9100:0800 UD 9840:4d30 UC 9d40:1e70 BD 0000:37c0 BC
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 11, MAC 00:02:B3:25:45:56
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 609 kB free
--
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
Cambridge, MA 02139; USA
Voice: (617) 491-6935; Fax: (617) 491-7046
Email: md...@et...
Web: http://www.etherboot.org/
|
|
From: <ebi...@ln...> - 2003-06-02 04:23:44
|
Marty Connor <md...@et...> writes: > I've been doing some testing of the UNDI driver with 5.1.8, and have some > results that I hope will help with debugging. A couple of quick comments. 1) The failure modes between the two cases appear to be different with the exception that etherboot looses control of the execution. 2) It looks for allocating low memory we may have an interface that is more complex than necessary. > Freed 2 kB base memory, 610 kB now free > Freed 20 kB base memory, 630 kB now free > Freed 8 kB base memory, 638 kB now free > Freed 1 kB base memory, 639 kB now free The allot primitive in etherboot while it is like malloc it is modeled on objstacks, and the forth where forget on an object frees that object and all objects allocated after it. Which tends to make the code simpler as individual allocation do not need to be tracked. 3) A very interesting test would be load unzi.zfd0 and point it at a file that is not served by the tftp server. But to point it at a valid tftp server. This would stress the initialize and clean up paths, of the driver. As etherboot loops repeatedly trying to load an absent image off of the network, initializing and shutting down the driver every couple of seconds. At the very least this would give a good clue about how stable the base UNDI driver is. And a basic question is: Is the problem the UNDI driver or are we not properly cleaning up the PXE stack. Eric |
|
From: Michael B. <mb...@fe...> - 2003-06-02 10:44:19
|
On Mon, 1 Jun 2003, Eric W. Biederman wrote: > 2) It looks for allocating low memory we may have an interface that is > more complex than necessary. > > Freed 2 kB base memory, 610 kB now free > > Freed 20 kB base memory, 630 kB now free > > Freed 8 kB base memory, 638 kB now free > > Freed 1 kB base memory, 639 kB now free > The allot primitive in etherboot while it is like malloc it is modeled > on objstacks, and the forth where forget on an object frees that object and all > objects allocated after it. Which tends to make the code simpler as individual > allocation do not need to be tracked. Our code has to interoperate with anything else that might allocate base memory. The code is remarkably simple and robust; it doesn't leak memory even when stress-tested with a dodgy PXE ROM that likes to sometimes refuse to unload. With debugging disabled it's 225 bytes of code. The long sequence of "Freed" message you see there doesn't imply that those blocks were freed in that order. You can call forget_base_memory() on blocks in any order; they will then be automatically freed as soon as it becomes possible to do so. To implement a "free this block and everything below it" strategy would cause problems in the case of an UNDI driver refusing to unload. This does happen often; my Intel PXE ROM does it every other time. The current strategy copes perfectly, a "free myself and below" strategy would have a choice of either (a) marking as free memory that was still in use, risking a crash later, or (b) leaking memory. The only part of the interface that I don't like is that it is necessary to pass the size of the block to forget_base_memory(). There's no easy way around this; we can't do the normal trick of allocating an extra four bytes and using it to store the block size, because BIOS memory allocation granularity is 1kB. > 3) A very interesting test would be load unzi.zfd0 and point it at a file that > is not served by the tftp server. But to point it at a valid tftp server. > This would stress the initialize and clean up paths, of the driver. > As etherboot loops repeatedly trying to load an absent image off of the > network, initializing and shutting down the driver every couple of seconds. > At the very least this would give a good clue about how stable the base > UNDI driver is. As part of the development, I've done this stress test a few hundred times with a floppy boot, with an unplugged cable / invalid file to prevent it booting. Initialisation and cleanup is stable, including memory allocation/deallocation. Since my PXE ROM doesn't like unloading properly, I've been involuntarily testing both the "find a loaded UNDI driver" and the "install an UNDI driver from ROM" code paths. > And a basic question is: Is the problem the UNDI driver or are we not properly > cleaning up the PXE stack. I'm fairly certain it's the latter. I *will* get around to debugging it properly, but it'll have to wait until after I get back from Norway on Thursday. Michael |
|
From: Michael B. <mb...@fe...> - 2003-06-12 14:47:59
|
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 |
|
From: Marty C. <md...@et...> - 2003-06-13 10:38:09
|
Hi Michael,
I have run the tests you requested using EEPRO100 and 3C905C NICs. I am
using CONSOLE_DUAL to capture output. I seem to lose a little output at
the end with serial port echoing. If I use regular output I sometimes
get a little more output. I suspect the Etherboot code size is a little
bigger, and there is some output latency caused by the serial output
routines waiting for the port.
> 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
I have not been able to get chaining to work yet. I hope some other
folks will give it a try so we can have more data points. Floppy load
using UNDI works fine.
I hope this is helpful. Please let me know what to try next. And big
thanks for debugging this!
Marty
On Thursday, June 12, 2003, at 10:47 AM, Michael Brown wrote:
> 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
[EEPRO100]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL)
Tagged ELF for [UNDI]
Relocating _text from: [0000c300,0001bef0) to [07eb0410,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, 574 kB free
Hunting for pixies...found !PXE at 0009dba0...ok
API 9db3:0106 St 8f80:0800 UD 98e0:4d30 UC 9db3:1e70 BD 9000:37c0 BC
937c:563a
Resetting pixie...
UNDI API call 0x0070 failed with status 0x0001
API 9db3:0106 St 8f80:0800 UD 98e0:4d30 UC 9db3:1e70 BD 9000:37c0 BC
937c:563a
UNDI API call 0x0000 failed with status 0x006a
UNDI API call 0x0076 failed with status 0x0001
UNDI API call 0x0070 failed with status 0x0001
Trying to free 7792 bytes base memory at 0x0009db30
WARNING: destructively expanding free block downwards to 0x0009d800
Trying to free 19760 bytes base memory at 0x00098e00
WARNING: destructively expanding free block downwards to 0x00098c00
Hunting for pixies...found !PXE at 0009d600...invalid checksum
...none found
Hunting for ROMs...found 55AA at 000c8000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 573 kB free
Trying to allocate 20 kB of base memory, 565 kB free
Installing UNDI driver code to 8d40:0000, data at 8840:0000
UNDI driver created a pixie at 8d40:0070...ok
API 8d40:0106 St 8100:0800 UD 8840:4d30 UC 8d40:1e70 BD 0000:37c0 BC
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 10, MAC 00:02:B3:25:45:56
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 545 kB free
(hangs)
[3C905C]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL)
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,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!
API 9d74:00f6 St 0000:0000 UD 9a4b:3284 UC 9d74:24c0 BD 0000:0000 BC
0000:0000
Ignoring and continuing, but this may cause problems later!
none found
Hunting for ROMs...found 55AA at 000c8000...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 with IO 0xdc00, IRQ 10, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 10
(hangs)
> 2. CFLAGS+=-DPXELOADER_KEEP_UNDI
[EEPRO100]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL)
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,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, 611 kB free
Hunting for pixies...found !PXE at 0009dba0...ok
API 9db3:0106 St 0000:0000 UD 98e0:4d30 UC 9db3:1e70 BD 0000:0000 BC
0000:0000
UNDI API call 0x0000 failed with status 0x006a
Trying to free 7792 bytes base memory at 0x0009db30
WARNING: destructively expanding free block downwards to 0x0009d800
Trying to free 19760 bytes base memory at 0x00098e00
WARNING: destructively expanding free block downwards to 0x00098c00
Hunting for pixies...none found
Hunting for ROMs...found 55AA at 000c8000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 610 kB free
Trying to allocate 20 kB of base memory, 602 kB free
Installing UNDI driver code to 9680:0000, data at 9180:0000
UNDI driver created a pixie at 9680:0070...ok
API 9680:0106 St 8a40:0800 UD 9180:4d30 UC 9680:1e70 BD 0000:37c0 BC
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 10, MAC 00:02:B3:25:45:56
ND
(hangs)
[3C905C]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL)
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,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, 617 kB free
Hunting for pixies...found !PXE at 0009d7a0...ok
API 9d74:00f6 St 0000:0000 UD 9a4b:3284 UC 9d74:24c0 BD 0000:0000 BC
0000:0000
Initialized UNDI NIC with IO 0xdc00, IRQ 10, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 616 kB free
...Me: 192.168.2.137, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb .....
After the last "Trying to allocate 2 kB of base memory, 616 kB free"
entry, things start moving very slowly. It takes about a minute for the
DHCP information to get received, and then the Loading line moves
glacially. It's been running for about 5 minutes, and so far I have:
Loading 192.168.2.37:/ltsp-0x8000.nb .......(NBI)......
normally this happens almost instantly. More memory contention? PXE
interrupt handlers interfering with Etherboot polling drivers?
> 3. (nothing)
[EEPRO100]
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,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, 638 kB free
Hunting for pixies...found !PXE at 0009dba0...in free base memory!
WARNING: a valid !PXE structure was found in an area of memory marked
as free!
API 9db3:0106 St 0000:0000 UD 98e0:4d30 UC 9db3:1e70 BD 0000:0000 BC
0000:0000
Ignoring and continuing, but this may cause problems later!
none found
Hunting for ROMs...found 55AA at 000c8000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 637 kB free
Trying to allocate 20 kB of base memory, 629 kB free
Installing UNDI driver code to 9d40:0000, data at 9840:0000
UNDI driver created a pixie at 9d40:0070...ok
API 9d40:0106 St 9100:0800 UD 9840:4d30 UC 9d40:1e70 BD 0000:37c0 BC
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 10, MAC 00:02:B3:25:45:56
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 609 kB free
(hangs)
[3C905C]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL)
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,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!
API 9d74:00f6 St 0000:0000 UD 9a4b:3284 UC 9d74:24c0 BD 0000:0000 BC
0000:0000
Ignoring and continuing, but this may cause problems later!
found !PXE at 0009c000...invalid checksum
...none found
Hunting for ROMs...found 55AA at 000c8000...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 with IO 0xdc00, IRQ 10, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 10
(hangs)
--
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
Cambridge, MA 02139; USA
Voice: (617) 491-6935; Fax: (617) 491-7046
Email: md...@et...
Web: http://www.etherboot.org/
|
|
From: H. P. A. <hp...@zy...> - 2003-06-24 01:05:44
|
Michael Brown wrote: > > 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". > Ouch! I'd recommend looking at the unloading code in PXELINUX. Getting unloading to work (semi-)reliably was the single hardest thing I had to deal with in PXELINUX, believe it or not. PXELINUX is quite conservative; if it detects any errors it assumes memory is not freeable; Linux doesn't care anyway. -hpa |
|
From: <ke...@us...> - 2003-05-31 23:00:12
|
>Thanks; I see the option (--relocseg=0x8000) on the man page. I'm not >familiar with first32.c; are there any implications for using a different >load address and is there any reason (other than the need to recompile) >why we can't use arbitrary load addresses in base memory? It can run from anywhere if recompiled, but as it coexists with the kernel, however briefly, any space it occupies cannot be used to load the kernel in. Personally I think that everyone should use bz kernels and load above 1 MB these days. Then all of low memory would be freed up. |
|
From: <ebi...@ln...> - 2003-06-02 04:10:58
|
ke...@us... (Ken Yap) writes: > >Thanks; I see the option (--relocseg=0x8000) on the man page. I'm not > >familiar with first32.c; are there any implications for using a different > >load address and is there any reason (other than the need to recompile) > >why we can't use arbitrary load addresses in base memory? > > It can run from anywhere if recompiled, but as it coexists with the > kernel, however briefly, any space it occupies cannot be used to load > the kernel in. Personally I think that everyone should use bz kernels > and load above 1 MB these days. Then all of low memory would be freed > up. Almost there is the little bit of 16 bit code that makes bios calls and switches to 32bit mode that must be allocated below 1MB. But with a bzImage that code can be loaded much lower in memory than 0x9000. Perhaps that should be the default except when we are dealing with an kernel that does not support it (zImage or old bzImage). Eric |
|
From: <ke...@us...> - 2003-06-02 04:25:08
|
>Almost there is the little bit of 16 bit code that makes bios calls >and switches to 32bit mode that must be allocated below 1MB. And also the floppy sector and setup segment from the kernel image. >But with a bzImage that code can be loaded much lower in memory than >0x9000. Perhaps that should be the default except when we are dealing >with an kernel that does not support it (zImage or old bzImage). There's an idea. Hmm more Perl hacking. Do you remember which setup version was the transition? Maybe the person who thought up the x86 architecture is dead now then I can libel him all I like. |
|
From: <ebi...@ln...> - 2003-06-02 04:51:29
|
ke...@us... (Ken Yap) writes: > >Almost there is the little bit of 16 bit code that makes bios calls > >and switches to 32bit mode that must be allocated below 1MB. > > And also the floppy sector and setup segment from the kernel image. > > >But with a bzImage that code can be loaded much lower in memory than > >0x9000. Perhaps that should be the default except when we are dealing > >with an kernel that does not support it (zImage or old bzImage). > > There's an idea. Hmm more Perl hacking. Do you remember which setup > version was the transition? 2.something. It is in the documentation distributed with the kernel. > Maybe the person who thought up the x86 architecture is dead now then I > can libel him all I like. When I see something better I will consider it. Rumor is the BIOS architecture was only supposed to last one generation of the product. Eric |
|
From: <ke...@et...> - 2003-10-09 22:27:48
|
>I have checked the UNDI driver from 5.1 in to 5.3 CVS. It compiles >without problems, but I haven't yet tested it. I have some new PXE NICs >with which to test it and I'm expecting to make some changes over the next >few days. > >Not sure whether to add it to 5.2 or wait until it's working with a wider >variety of cards. Great, thanks. I'd be happy to release 5.3.3 now or in a few days time so that Marty can put it on rom-o-matic for wider testing. Which would you prefer? |
|
From: Michael B. <mb...@fe...> - 2003-05-19 18:11:56
|
> Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE > initialisation (and therefore probably everyone else's, though I haven't > tried) with multiple NICs that the MAC address used is that of the > *last* NIC to initialise? This confuses people because it almost always > means that it never uses the one that Linux calls eth0. MAC address used is the MAC address stored on the NIC EEPROM; the one known to UNDI as the "Permanent Node Address". We will use PCI cards in the same order that Etherboot normally finds them. If Etherboot uses the same scanning order as Linux, then we should end up using the one that Linux calls eth0. This is independent of the Etherboot UNDI driver; it's determined by pci.c. > > I imagine that PXE-chaining would also work, although I haven't tested > > it yet. > PXE chaining is, of course, what lots of people want so that they don't > have to worry about loading the right driver. Just remember to leave PXE > loaded, since by default the first act of PXE-chaining to is to unload > PXE. :) You can happily unload the PXE stack; the UNDI driver will simply reinstall it from the UNDI ROM. It searches for a PXE stack in memory before looking for ROMs, so a loaded PXE stack should work. If the PXE stack has been left in a "running" state then it will fail to initialise, ignore the loaded stack and try to load a new one from ROM. There is *no* clean way to tell whether or not a PXE stack is running or not; the API call for "get current state" has the same number as the API call for "shutdown stack"... > > 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? > Dumb question - does anything make UNDI fundamentally different from a > nic driver? That's how people will want to treat it, so I say treat it > exactly like a driver, with the possible exception that UNDI is included > by default as a last resort driver for PXE images but not others. No; except that it requires an assembler stub because the UNDI API calls (at least some of them) have to be executed in real mode. This assembler stub should ideally be present only in the UNDI driver, which means that it shouldn't go in pcbios.S. The UNDI driver will therefore consist of two files: undi.c and undi_wrapper.S (plus the headers); most drivers consist only of a single C file. The Makefile will, I think, have to be altered to allow drivers to consist of more than just the one file. Another small difference is that the UNDI driver claims to be able to handle any NIC, whereas most drivers specify a list of PCI IDs. If the UNDI driver can't find an UNDI ROM for the card, it will give up. We may therefore need to change the core driver scanning code to try multiple drivers for a specific PCI vendor:device ID, if people are going to want to build images that contain UNDI and other drivers. Michael |
|
From: <ebi...@ln...> - 2003-05-19 19:32:52
|
Michael Brown <mb...@fe...> writes: > > Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE > > initialisation (and therefore probably everyone else's, though I haven't > > tried) with multiple NICs that the MAC address used is that of the > > *last* NIC to initialise? This confuses people because it almost always > > means that it never uses the one that Linux calls eth0. > > MAC address used is the MAC address stored on the NIC EEPROM; the one > known to UNDI as the "Permanent Node Address". > > We will use PCI cards in the same order that Etherboot normally finds > them. If Etherboot uses the same scanning order as Linux, then we should > end up using the one that Linux calls eth0. This is independent of the > Etherboot UNDI driver; it's determined by pci.c. > > > > I imagine that PXE-chaining would also work, although I haven't tested > > > it yet. > > PXE chaining is, of course, what lots of people want so that they don't > > have to worry about loading the right driver. Just remember to leave PXE > > loaded, since by default the first act of PXE-chaining to is to unload > > PXE. :) > > You can happily unload the PXE stack; the UNDI driver will simply > reinstall it from the UNDI ROM. It searches for a PXE stack in memory > before looking for ROMs, so a loaded PXE stack should work. > > If the PXE stack has been left in a "running" state then it will fail to > initialise, ignore the loaded stack and try to load a new one from ROM. > There is *no* clean way to tell whether or not a PXE stack is running or > not; the API call for "get current state" has the same number as the API > call for "shutdown stack"... I like the fact we can unload and reload the PXE stack. The only downside of this is that we don't know what NIC we booted off of. Oh well. > > > 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? > > Dumb question - does anything make UNDI fundamentally different from a > > nic driver? That's how people will want to treat it, so I say treat it > > exactly like a driver, with the possible exception that UNDI is included > > by default as a last resort driver for PXE images but not others. > > No; except that it requires an assembler stub because the UNDI API calls > (at least some of them) have to be executed in real mode. This assembler > stub should ideally be present only in the UNDI driver, which means that > it shouldn't go in pcbios.S. The UNDI driver will therefore consist of > two files: undi.c and undi_wrapper.S (plus the headers); most drivers > consist only of a single C file. The Makefile will, I think, have to be > altered to allow drivers to consist of more than just the one file. Or we can have a special case in the makefile, for the supporting code. > Another small difference is that the UNDI driver claims to be able to > handle any NIC, whereas most drivers specify a list of PCI IDs. If the > UNDI driver can't find an UNDI ROM for the card, it will give up. We may > therefore need to change the core driver scanning code to try multiple > drivers for a specific PCI vendor:device ID, if people are going to want > to build images that contain UNDI and other drivers. Actually I am pretty certain that functionality is already present. I had a few bug fixes sitting in my tree with respect to pci scanning and I have just commited them. Eric |
|
From: Michael B. <mb...@fe...> - 2003-05-19 19:41:34
|
> > You can happily unload the PXE stack; the UNDI driver will simply > > reinstall it from the UNDI ROM. It searches for a PXE stack in memory > > before looking for ROMs, so a loaded PXE stack should work. > > If the PXE stack has been left in a "running" state then it will fail to > > initialise, ignore the loaded stack and try to load a new one from ROM. > > There is *no* clean way to tell whether or not a PXE stack is running or > > not; the API call for "get current state" has the same number as the API > > call for "shutdown stack"... > I like the fact we can unload and reload the PXE stack. The only downside > of this is that we don't know what NIC we booted off of. Oh well. You do; when you initialise a PXE stack you have to pass in the PCI bus, device and function. The structure is "take this PCI device, try to locate and initialise an UNDI driver for it", rather than "try to locate and initialise an UNDI driver, let it find its own NIC". > > No; except that it requires an assembler stub because the UNDI API calls > > (at least some of them) have to be executed in real mode. This assembler > > stub should ideally be present only in the UNDI driver, which means that > > it shouldn't go in pcbios.S. The UNDI driver will therefore consist of > > two files: undi.c and undi_wrapper.S (plus the headers); most drivers > > consist only of a single C file. The Makefile will, I think, have to be > > altered to allow drivers to consist of more than just the one file. > Or we can have a special case in the makefile, for the supporting code. OK. As mentioned in another message, I'm planning on tidying up the Makefiles a bit; there are various other problems like drivers not being recompiled when the header files change. If it's easy to slot in undi_wrapper.S in a generic way then I'll do so, otherwise I'll just add a special case in arch/i386/Makefile. > > Another small difference is that the UNDI driver claims to be able to > > handle any NIC, whereas most drivers specify a list of PCI IDs. If the > > UNDI driver can't find an UNDI ROM for the card, it will give up. We may > > therefore need to change the core driver scanning code to try multiple > > drivers for a specific PCI vendor:device ID, if people are going to want > > to build images that contain UNDI and other drivers. > Actually I am pretty certain that functionality is already present. There's a comment in pci.c that says /* Assume there is only one match of the correct type */ I haven't checked the actual code, so it might be a leftover comment. > I had a few bug fixes sitting in my tree with respect to pci scanning > and I have just commited them. I'm not seeing anything appearing in CVS. Can you check that the commit worked ok? Michael |
|
From: <ebi...@ln...> - 2003-05-19 19:53:27
|
Michael Brown <mb...@fe...> writes: > > > Another small difference is that the UNDI driver claims to be able to > > > handle any NIC, whereas most drivers specify a list of PCI IDs. If the > > > UNDI driver can't find an UNDI ROM for the card, it will give up. We may > > > therefore need to change the core driver scanning code to try multiple > > > drivers for a specific PCI vendor:device ID, if people are going to want > > > to build images that contain UNDI and other drivers. > > Actually I am pretty certain that functionality is already present. > > There's a comment in pci.c that says > /* Assume there is only one match of the correct type */ > > I haven't checked the actual code, so it might be a leftover comment. It needs a close look but it appears to be a left over comment. > > I had a few bug fixes sitting in my tree with respect to pci scanning > > and I have just commited them. > > I'm not seeing anything appearing in CVS. Can you check that the commit > worked ok? I put everything in the tree and then for got the all important cvs commit . The code should show up now. The changes were very tiny but there was an obscure bug that etherboot would miss the second NIC in a multi-NIC configuration. If one nic was a subfunction. That should be cleared up now. Eric |
|
From: Marty C. <md...@et...> - 2003-05-20 12:42:54
|
On Monday, May 19, 2003, at 01:45 PM, Peter Lister wrote:
> It's annoying that neither Vasil nor I will get the glory, but I'm
> pleased that someone has finally worked up the steam. Well done,
> Michael.
Yes, Well done, Michael!
And don't worry, Peter and Vasil there's plenty of glory still to be
had! :)
Michael's work should be taken much as the code you and Vasil did - it
is an excellent facility that allows others to build other excellent
hacks on top of it.
One of my current desires is that we get PXELINUX to work with
Etherboot for LinuxWorld in August. Not because I need it personally,
but because it will help a lot of people, and will demonstrate how a
small Free Software project can create production-quality software that
is useful in many environments.
It's really a lot of fun to do this kind of thing, and to work with
people who care about the code :)
Thanks to everyone for making it so.
Marty
--
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
Cambridge, MA 02139; USA
Voice: (617) 491-6935; Fax: (617) 491-7046
Email: md...@et...
Web: http://www.etherboot.org/
|
