Re: ipAttach error - not an End device. PMC ethernet slots

On Dec 3, 6:11 am, gvarndell <gvarnd...@xxxxxxxxxxx> wrote:
On Nov 29, 4:00 pm, dandysxm <dandy...@xxxxxxxxxxx> wrote:





On Nov 29, 2:56 pm, gvarndell <gvarnd...@xxxxxxxxxxx> wrote:

On Nov 29, 2:18 pm, dandysxm <dandy...@xxxxxxxxxxx> wrote:

We are running vxWorks5.5.1 & Tornado2.2.1 on a Thales vmpc7 board. We
have added a Cyclone PMC-X 65 board with 2 additional ethernet ports.
The vmpc7 firmware recognizes all devices as shown by the following
output from sysPciShow
---------------------------------------------------------------------------------
Scanning device on PCI-32 Bus ...
---------------------------------------------------------------------------------
Bus#|Dev#|VendorId|DeviceId|RevId|IntL| Base Class | Sub
Class
---------------------------------------------------------------------------------
00 | 00 | 0x1014 | 0x0105 | 0.3 | 00 | Bridge | Host
00 | 03 | 0x10d6 | 0x0010 | 0.0 | 00 | Peripheral | Other
00 | 04 | 0x1011 | 0x0019 | 4.1 | 01 | Net Controller |
Ethernet
00 | 05 | 0x1000 | 0x000f | 2.6 | 00 | Mass Storage | SCSI
00 | 06 | 0x1014 | 0x0035 | 3.0 | 02 | Bridge | Other
00 | 07 | 0x1095 | 0x0673 | 0.5 | 14 | Serial Bus Cntlr | USB
00 | 08 | 0x8086 | 0x100e | 0.2 | 04 | Net Controller |
Ethernet
---------------------------------------------------------------------------------
Scanning device on PCI-64 Bus ...
---------------------------------------------------------------------------------
Bus#|Dev#|VendorId|DeviceId|RevId|Inter| Base Class | Sub
Class
---------------------------------------------------------------------------------
16 | 00 | 0x1014 | 0x00fc | 0.3 | 00 | Bridge | Host
16 | 01 | 0x8086 | 0x1010 | 0.1 | 06 | Net Controller |
Ethernet
--------------------------------------------------------------------------------

The controllers are Dec21143 & Intel 82540 on the vmpc7 and Intel
82546 on the Cyclone PMC.

The problem is we are getting the following ipAttach errors

0x18dc9d0 (Xinit): ipAttach: Can't attach gei (unit 1). It is not an
END device.
gei1 Interface Attach Error - PMC-3101: errno = 0x6d0002
0x18dc9d0 (Xinit): ipAttach: Can't attach gei (unit 2). It is not an
END device.
gei2 Interface Attach Error - PMC-3101: errno = 0x6d0002

The Thales BSP documentation has indicated that no modification of the
configNet.c endDevTbl would be needed to add PMC controllers. This
didn't seem to be the case and we did modify configNet.c to call
pciFindDevice for the 82546 device, which did add the gei1 & gei2 to
the endDevTbl.
This did not clear the ipAttach error and added a fail of the
muxdevLoad call for both gei1 & gei2 in usrEndLib. The error we get is

Cannot find Intel-8254x device for unit: 1
Cannot find Intel-8254x device for unit: 2

What am I missing here? I'm sure there is something really simple that
I am not doing to allow the gei ports.
Any suggestions?

Does vxWorks see the devices?
Can you configure your kernel appropriately and do pciDeviceShow?
If you don't have source for the drivers, get it from Wind River.
Make sure both drivers are built from source instead of being linked
from the libs.
I'm not sure, but I think maybe you're linking with old netif drivers
instead of END drivers.
I can't remember the details, but END drivers have to respond to some
IOCTL call a certain way to identify themselves as END drivers.

HTH,
GV- Hide quoted text -

- Show quoted text -

Yes vxworks sees the devices, the output from pciDeviceShow is:

before pciDeviceshow(0)
Scanning function 0 of each PCI device on bus 0
Using configuration mechanism 0
bus device function vendorID deviceID class
00000000 00000000 00000000 00001014 00000105 00060000
00000000 00000003 00000000 000010d6 00000010 00088000
00000000 00000004 00000000 00001011 00000019 00020000
00000000 00000005 00000000 00001000 0000000f 00010000
00000000 00000006 00000000 00001014 00000035 00068000
00000000 00000007 00000000 00001095 00000673 000c0310
00000000 00000008 00000000 00008086 0000100e 00020000
after pciDeviceshow(0)
before pciDeviceshow(16)
Scanning function 0 of each PCI device on bus 16
Using configuration mechanism 0
bus device function vendorID deviceID class
00000010 00000000 00000000 00001014 000000fc 00060000
00000010 00000001 00000000 00008086 00001010 00020000
after pciDeviceshow(16)

I will check to make sure we link to END drivers. What you said about
possibly using old netif drivers sure makes sense given the output
we're getting.

Thanks
Dan

It turns out that the message saying 'foo' is not an END driver is a
little misleading.
It's logged simply because endFindByName() fails.
This failure could occur simply because the BSP isn't looking for the
right device ID or can't handle multiple instances of the same type
device.
Usually, you would find this code in a module called sysNet.c or
sysEnd.c or some such.
Unfortunately, all bets are off when you're dealing with BSPs from
certain board vendors.
They tend to do things their own way, which puts you in the position
of needing to talk to the vendor when these kinds of problems arise.
It's still a good idea to get the latest END driver source from Wind
River though.
Too often, I've seen the case where the board vendor supplied buggy
network drivers with their BSPs -- usually only the object file too.

HTH
GV- Hide quoted text -

- Show quoted text -

Thanks GV
Yes I did check with the board vendor, they assured me it is an END
driver as part of the BSP.
You were correct about the BSP not looking for the correct device ID.
Once we modified for that we still get
the errors previously mentioned. Maybe it is a matter of the BSP not
handling the multiple instance of similar device types.
In any case we have hired a more experienced vxworks engineer and he
will be working this problem.
Thanks again for your help.
dan
.

Relevant Pages

  • Re: Some broad questions
    ... Some drivers are provided by microsoft and some are by intel. ... SDK - Generated using Platform builder after the BSP and the OS design are ...
    (microsoft.public.windowsce.embedded)
  • Re: Development environment best practices?
    ... >>> OS's interface to the hardware (the OAL is part of the BSP, ... Do most developers create a BSP based on one provided ... >>> dev board and include proprietary drivers in the BSP? ... >>> the associated SDK is generated, how often will that SDK change? ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Can not get Canon MP750 to scan
    ... I have tried un-installing all of the scanner ... drivers and reinstalling them two or three times. ... I have tried two other USB ... Scanning does work when it is connected to my ...
    (comp.periphs.scanners)
  • Re: ipAttach error - not an End device. PMC ethernet slots
    ... Scanning device on PCI-32 Bus ... ... If you don't have source for the drivers, ... bus device function vendorID deviceID class ...
    (comp.os.vxworks)
  • Re: 802.11 status and futures
    ... >>new framework for doing scanning. ... These changes affect all drivers so ... > looking at the source and searching for documentation I still lacked ... > software, which one needs what kind of hardware support, what needs to ...
    (freebsd-arch)