Subject: Re: UNDI driver - msg#00032

Previous Message by Date:

Re: UNDI driver

> 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 ------------------------------------------------------- This SF.net email is sponsored by: If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge

Next Message by Date:

Re: UNDI driver

> > 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 ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge

Previous Message by Thread:

Re: UNDI driver

> 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 ------------------------------------------------------- This SF.net email is sponsored by: If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge

Next Message by Thread:

Re: UNDI driver

> > 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 ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge