> 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
