Using the dc0 device doesn't seem to make any difference at all. Using the "@" command instead of the "l" command makes no difference at all either.

Ahh, looking at the Beta4 version of the BSP, I see that they are now shipping two drivers with the OS (and presumably with the boot rom). (Check BoardSupport/VxWorks/IXP1200EB/configNet.h). So if your NIC has digital parts on it, go with dc, if it has intel parts, go with eeV (did you try eeV or eeE? Make sure you try eeV0 and eeE0. eeVconfig.h would seem to indicate that it uses eeE0, but I can't be sure).. I am still in the past with the dc NIC so I cannot attest to how things work with the intel part. hopefully the driver for the intel nic has been compiled into the bootrom. I wonder if anyone else out there can verify this(?) I don't know of a symbol table lookup command from the boot loader (i.e., like lkup() does once you get the full version of vxworks loaded). I tried to do an nm on the vxWorks_rom and vxWorks image in the bin/vb directory and vxWorks turns up hits for both eeVEndLoad and dec21x4xEndLoad (the dc driver). The vxWorks_rom image must be partly stripped because it does not turn up hits for either.

Regarding FTP: I set the boot flags for TFTP, so I believe no username/password should be needed. Also, we never saw the box generate a single packet, so I doubt this is it. To be sure, we tried with real FTP and no luck there either (with a username & passwd). Yes scout-7 is running a TFTP server.

Ahhh, perhaps that explains your flags being set to 0x80. I just checked our settings and our flags are 0, which may explain why we are using ftp rather than tftp (if I read sysLib.h correctly, 0x80 is for tftp). One simple test would be to change the flags to 0, but I doub't this will help.

Is the boot prompt "n" command really supposed to fail?

I would assume that it fails because both the dc and eeV are END drivers and the n command (if I read code correctly) is dealing with BSD-style drivers. (I am looking at configNet.h and bootConfig.c. In bootConfig.c I assume bootCmdLoop is producing the prompt you are getting. This calls netifAdrsPrint in response to the 'n' command). Following these calls through, I don't see the code calling muxDevLoad, rather it calls the attach routine in the device structure, which, correct me if I am wrong, is the older BSD-style interface. Anyway, it would not surprise me if it fails because of this (BTW, it fails on our "working" system). You could fix the n command to do the right thing (say call muxShow() instead of netifAdrsPrint), but of course since you can't boot vxworks you can't overwrite the boot rom and you are stuck. sorry for not being any help, I guess the best I can do is point you back to the person who shipped you the system and have them verify the version of your bootrom, and then, maybe replace your NIC. erk