| >> Is there any way a customer can get this patch sooner? I have one
>>that is upset that we are selling the DEFPA for AXPvms 6.1 and it will
>>not autoconfigure and does not have a driver to load. He said that he
>>would be willing to run as a test site.
Mark,
I've included a note I received from Dick Stockdale on how to manually
configure the DEFPA driver in versions of OpenVMS older than 6.2. I
don't have the actual driver, but hopefully the following information
will help.
We did have a very successful DEFPA OpenVMS driver field test site at
CERN in Europe, and they did (I believe) manually configure the driver.
Regards,
Larry
Return-Path: star::stockdale
Date: Sun, 19 Feb 95 11:25:51 -0500
From: star::stockdale (DTN 381-2751 ZK3-4/U14 OFFICE 4U22)
To: netcad::denault, netcad::paquette, yesway::stefani
Cc: STOCKDALE
Subject: DEFPA in V6.1, V6.1-1H1, V6.1-1H2 how to manually configure note
To configure the DEFPA using the SYSMAN utility:
(1) Use the IO SHOW BUS command to see what is installed on the PCI.
If your device is not recognized by OpenVMS, it will display
as "Unknown". You will need the TR# and the Node from the IO SHOW
BUS display.
For example:
$ MC SYSMAN IO SHOW BUS
%SYSMAN-I-OUTPUT, command execution on node SABL3
_Bus__________Node_TR#__Name____________Base CSR__________
KA0902 0 1 CPU FFFFFFFF81FBA000
KA0902 1 1 CPU FFFFFFFF81FBC000
KA0902 6 1 MEM FFFFFFFF81FBE000
KA0902 8 1 IO Port FFFFFFFF81FC0000
PCI 0 2 PCI/NI FFFFFFFF81FC2000
PCI 8 2 PCI/SCSI FFFFFFFF81FC4000
XBUS 0 4 System Board FFFFFFFF81FFE000
XBUS 1 4 Floppy FFFFFFFF81FFE000
XBUS 2 4 Parallel Port FFFFFFFF81FFE000
XBUS 3 4 Serial Port FFFFFFFF81FFE000
EISA 4 3 Lance NI Adapt FFFFFFFF8207E000
EISA 5 3 FDDI Adapter FFFFFFFF8209E000
EISA 8 3 VGA Adapter FFFFFFFF820FE000
+-> PCI 48 2 Unknown FFFFFFFF82262000
\ PCI 64 2 Unknown FFFFFFFF82266000
\
`- this is the DEFPA
(2) Issue the IO CONNECT command as follows. The CONNECT command
qualifiers are explained later.
SYSMAN> IO CONNECT FWA0 /ADAPTER=2 /CSR=0 /VECTOR=v /NODE=48 -
/DRIVER=SYS$FWDRIVER
/ADAPTER specifies the ADP that represents the bus to which your
device is connected. Use the TR# from the IO SHOW BUS display
that is associated with your device.
/CSR The /CSR qualifier is required by the driver loading
program. The value specified in the /CSR qualifier is copied to
IDB$Q_CSR by the driver loading program. On some buses, this
qualifier is used to tell the driver the physical address at which
the device is located. However, for PCI, the physical address
information is stored in the Configuration Space header of the
device, as explained earlier. Therefore, this qualifier is not
useful for PCI and should be specified as /CSR=0.
/NODE The /NODE qualifier identifies the PCI device to the PCI
bus support routines. The value specified in the /NODE qualifier
is copied to CRB$L_NODE by the driver loading program. Use the
Node value from the IO SHOW BUS display that is associated with
your device.
/VECTOR The /VECTOR qualifier is used by the driver loading
program to hook up your driver interrupt service routine to a
hardware interrupt vector. Unfortunately there is no vector
information in the IO SHOW BUS display. Even more unfortunately,
because of the wide latitude in system interrupt logic design for
PCI, there is no convenient rule you can use for figuring out the
interrupt vector associated with your device. You must run SDA on
a running system to find the interrupt vector for your device.
Here is a picture of how the ADP list and bus arrays are set up.
You must find the bus array entry for your PCI device. The bus
array entry contains the interrupt vector offset that should be
used as the value for the /VECTOR qualifier.
The ADP list on a platform with a PCI bus (note that there may be
intervening ADPs between the System ADP and the PCI ADP):
System ADP
+-----+
ioc$gl_adplist--->| | PCI ADP
| | adp$l_link +-----+
| |------------>| | adp$l_tr
+-----+ | |
| |-----+ adp$ps_bus_array
+-----+ |
|
V
+--------------+
|bus array |
|header |
+--------------+
| entry 0 |
| |
+--------------+
| entry 1 |
| |
+--------------+
| entry 2 |
| |
+--------------+
| etc |
| |
System global cell ioc$gl_adplist points to a list of ADPs. An
ADP is an OpenVMS/AXP data structure that represents an adapter.
The PCI interface is an example of an adapter. The System ADP is
always the first ADP in the list. Each ADP has a Bus Array,
pointed to by ADP cell adp$ps_bus_array. A Bus Array consists of
a header and a number of entries. There is an entry in the Bus
Array for each device connected to the bus.
The structure definition of the ADP is available in
[syslib]sys$lib_c.tlb, lib.r64, and lib.mlb. You can use the
Librarian utility to extract its definition if you want to see it.
Say
libr /alpha /extract=adpdef /out=adpdef.h sys$lib_c.tlb
or
libr /alpha /extract=$adpdef /out=adpdef.mar sys$lib_c.tlb
The structure definition of the Bus Array is also available in
[syslib]sys$lib_c.tlb. Say
libr /alpha /extract=busarraydef /out=busarraydef.h sys$lib_c.tlb
or
libr /alpha /extract=$busarraydef /out=busarraydef.mar sys$lib_c.tlb
You may find the .mar file easier to comprehend than the .h file.
Here is an example of how to traverse the ADP list to find the
interrupt vector offset for your PCI device. Note that you should
first go into SYSMAN and say IO SHOW BUS. Write down the TR
number associated with the display information of your device.
Then:
$ analyze/sys
SDA> read sys$loadable_images:sysdef
SDA> format @ioc$gl_adplist
This will display all of the fields of the System ADP. Find
the address in field ADP$L_LINK. Then format that address:
SDA> format addr_from_adp$l_link
This will display all of the fields of the next ADP in the
ADP list. Keep following the adp$l_link pointers until you
find the ADP with a TR number that matches the TR number you
found from SYSMAN IO SHOW BUS. The TR number is found in
field ADP$L_TR. When you find the matching TR number, you
have found the PCI ADP.
Note that the PCI ADP will usually be the second ADP in the
list.
Once you have found the PCI ADP, get the address from ADP
field ADP$PS_BUS_ARRAY.
Unfortunately, format does not work on the Bus Array
structure. Although an SDA whiz can probably make it work.
The key facts to remember about the bus array is that the
header is three quadwords and each entry is 6 quadwords. The
bus array header is shown below:
63 32 31 0
+-----------------------------------------+
| | parent ADP | 0x0
+-----------------------------------------+
| bus type |subty|type| size | 0x8
+-----------------------------------------+
| | node count | 0x10
+-----------------------------------------+
The Bus Array entries start after the bus array header. A
generic Bus Array entry is shown below:
63 32 31 0
+-----------------------------------------+
| hardware id | 0x0
+-----------------------------------------+
| CSR | 0x8
+-----------------------------------------+
| flags | node number | 0x10
+-----------------------------------------+
| ADP | CRB | 0x18
+-----------------------------------------+
| ctrlltr | autoconfig | 0x20
+-----------------------------------------+
| bus_specific_h | bus_specific_l | 0x28
+-----------------------------------------+
A PCI bus array entry looks as follows:
63 32 31 16 15 0
+-----------------------------------------+
| | deviceID | vendorID| 0x0
+-----------------------------------------+
| base VA of config space | 0x8
+-----------------------------------------+
| flags | node number | 0x10
+-----------------------------------------+
| ADP | CRB | 0x18
+-----------------------------------------+
| ctrlltr | autoconfig | 0x20
+-----------------------------------------+
| bus_specific_h | interrupt vector | 0x28
+-----------------------------------------+
In SDA, once you have found the PCI ADP and Bus Array, you
should examine the Bus Array until you find the DeviceID and
VendorID of your device. Then you have found the Bus Array
entry for your device. Note that the interrupt vector offset
is in the bus_specific_l field of the Bus Array entry for
your device. This is the value that you should use for the
/VECTOR qualifier in the SYSMAN IO CONNECT command.
Note that once you have done this once and found the
interrupt vector, the interrupt vector will not change from
boot to boot. If you move your device to a different slot,
though, you will have to find the new interrupt vector. If
you move your device to a different machine, you will have to
find the new interrupt vector.
For example, using on a Sable system with a few shortcuts:
$ ANA/SYS
SDA> read sys$loadable_images:sysdef
SDA> format @((@ioc$gl_adplist)+c)
809B8580 ADP$Q_CSR 81FFE000
809B8584 FFFFFFFF
809B8588 ADP$W_SIZE 0140
809B858A ADP$B_TYPE 01
809B858B ADP$B_NUMBER 00
809B858C ADP$L_LINK 809BCD80
809B8590 ADP$L_TR 00000002
809B8594 ADP$L_ADPTYPE 00000044
809B8598 ADP$PS_NODE_DATA 80829E18 IOC$LOAD_OPDRV_VEC+00040
809B859C ADP$L_VECTOR 809B8AC0
809B85A0 ADP$L_CRB 00000000
809B85A4 ADP$PS_MBPR 00000000
809B85A8 ADP$Q_QUEUE_TIME 05F5E100
809B85AC 00000000
809B85B0 ADP$Q_WAIT_TIME 05F5E100
809B85B4 00000000
809B85B8 ADP$PS_PARENT_ADP 809B8180
809B85BC ADP$PS_PEER_ADP 00000000
809B85C0 ADP$PS_CHILD_ADP 809BCD80
809B85C4 ADP$L_PROBE_CMD 00000002
809B85C8 ADP$PS_BUS_ARRAY 809B8780
...
Then search for the bus array entry with the matching device ID
of 000F1011:
SDA> search/step=long/len=long 809B8780;4000 000F1011
Searching from 809B8780 to 809BC780 in LONGWORD steps for 000F1011...
Match at 809B88B8
SDA> e 809B88B8;30
FFFFFFFF 82262000 00000000 000F1011 ......... &..... 809B88B8
00000000 00000000 00000000 00000030 0............... 809B88C8
809BCEC0 00000000 00000000 00000000 ............@N.. 809B88D8
^
And the vector is ---+ which is zero.
For this example, then, the connect command is:
SYSMAN> IO CONNECT FWA0 /ADAPTER=2 /CSR=0 /VECTOR=0 /NODE=48 -
/DRIVER=SYS$FWDRIVER
|
| Any helpfull hints out there??
re: .3
It doesn't seem to work like it should.
We have a A2100 firmware rev 3.9-89 or something like that,
even upgraded it to V311 releasedate 20-mar-95 and a DEFPA
installed. VMS 6.1 and tried 6.1-1H2.
The connect procedure as described in .3 work fine and makes
the device FWA0: visible with show device and online as it seems.
Using netconfig to configure our database also goes errorfree.
When we then use STARTNET to start up our network, we get messages
saying FWA0: offline and for EWA0 is says device not mounted or
not available. If however we use V311 firmware, it doesn't complain
about EWA0, but stil FWA0 behaves the same wrong way.
This same story we have on a AS1000 rev V4.0, besides that it
seems that the AS1000 behaves a bit weard in relation to the EWA0
device. Its not visible under VMS, and it looks normal under
the console prompt. Were talking about a DE435.
Ofcourse we have loaded FWDRIVER as mentioned in .3.
regards Ton Drummen
|
|
Some comments to .3
- The .MAR files cannot be extracted from sys$lib_c.tlb, they are found
in lib.mlb.
- The arrow (very close to the end of the article) pointing to the
vector, points to offset 24 instead of 28. Both these locations are
zero in the example, causing the connect command to work ok, but in my
customers system offset 24 contains 00000000, offset 28 contains
00000010, and if the customer doesn't read the text, just looks at the
arrow, the command just causes the system to hang.
- And of course, the value found by SDA is in hex, while the default for
the connect command is decimal!
After sorting out this, the driver loads ok.
|