Possible PCI bridge chip problems (DEC 21150-AA) with QRTP

Quick Question (Ignore the rest depending on the answer):

Is there a known problem with QRTP PCI and the DEC 21150-AA bridge
chip?
Is there a known problem with PCI bridges in general?

Summary:

Card works on PCI bus 0 but not 2 or 3. May be the bridge chip, or PCI
SW problems using bridge chip.

Details:

My system consists of a Pentium CPU card plugged into a ‘passive’
backplane with 12 PCI slots. It also has ISA slots, but that is beside
th epoint here.) The CPU card has all standard PC peripherals on it. The
PCI slots on the backplane are divided among three PCI bus segments.
One, bus 0, is connected directly to the host bridge chip on the CPU
card, an Intel 440. The other two bus segments are 5-slots each conected
to the first bus (bus 0) by DEC 21150-AA bridge chips.

I have a PCI card: a Bancomm bc635pci time processor. It has two memory
areas available on the PCI bus. I have some simple code to attach and
map the two areas into process address space, and read some basic data
from them.

The code works a fine when the card is plugged into my first PCI bus
(bus 0), attached to the host-PCI Intel bridge chip. The attach works,
the mmap_device_memory() works, and I can access card resources when
I use the process addresses returned by the mmap_device_memory() calls.
However, when I plug the card into any other bus, connected to the
first with a DEC 21150-AA bridge, it works as before up until I try to
use the mapped address. The process addresses returned by the
mmap_device_memory() call return 0xffffffff when used, so the same code
does not work.

Bus 0 is connected to the processor by an Intel 440 host-PCI bridge.
However, the other off-board buses are connected to bus 0 with a
DEC21150-AA chip.

Clues:

When QRTP boots up and the board is in one of these other buses
(connected by the DEC 21150 chip), the message " Range check failed: MEM
vendor = 0x12e2, device = 0x4013" (or something like it.) is displayed
twice (I presume once for each memory area on the card.)

The base addresses in the info structure are different when the card is
plugged into different slots.

Code Fragment:

phdl = pci_attach(0);
if (phdl == -1) {
perror(“pci_attach”);
exit(EXIT_FAILURE);
}
memset(&info, 0, sizeof(info));

/* Device index: which PCI card with this vendor and device id
*/

pidx = 0;

/*

  • Look up Bancomm bc635pci by vendor and device
    */

info.VendorId = BC635PCI_VENDORID;
info.DeviceId = BC635PCI_DEVICEID;

/*

  • Do pci_attach_device() to find device, and create handle
    */

hdl = pci_attach_device(NULL, PCI_SHARE | PCI_SEARCH_VENDEV |
PCI_INIT_AL
pidx, &info);

if (hdl == NULL) {
fprintf(std err, “pci_attach_device() failed.\n”);
exit(EXIT_FAILURE);
}

register_base = mmap_device_memory(NULL,
info.BaseAddressSize[0],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[0]);

nvram_base = mmap_device_memory(NULL, info.BaseAddressSize[1],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[1]);

/* Print first some 32-bit words of card registers */

printf(“ACK Register : 0x%08x\n”, register_base[5]);
printf(“Control Register: 0x%08x\n”, register_base[4]);
printf(“Interrupt mask : 0x%08x\n”, register_base[6]);
printf(“Interrupt Status: 0x%08x\n”, register_base[7]);

/* Strobe time reguest and print time */

strobe = register_base[0];

printf(“Minor Time : 0x%08x\n”, register_base[12]);
printf(“Major Time : 0x%08x\n”, register_base[13]);


\

============================
John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

We had multiply problems of that sort with boards containing their own
PCI buses behind bridges. Every time it had to be fixed by patch for
pci-bios, which QNX did but I’m afraid that solved only our praticular
problems, not in general.

Trouble is, they don’t have explicit support for PCI chipsets in their
architecture. Some chips apparently are supported by pci-bios, but some
are not, especially bridges. To fix it in general would require
something like set of callins/callouts in pci-bios server and set of
chip-specific shared libraries, then some DDK to develop new ones… a
whole new domain of development basically.

  • igor

“John H. Zouck” wrote:

Quick Question (Ignore the rest depending on the answer):

Is there a known problem with QRTP PCI and the DEC 21150-AA bridge
chip?
Is there a known problem with PCI bridges in general?

Summary:

Card works on PCI bus 0 but not 2 or 3. May be the bridge chip, or PCI
SW problems using bridge chip.

Details:

My system consists of a Pentium CPU card plugged into a ‘passive’
backplane with 12 PCI slots. It also has ISA slots, but that is beside
th epoint here.) The CPU card has all standard PC peripherals on it. The
PCI slots on the backplane are divided among three PCI bus segments.
One, bus 0, is connected directly to the host bridge chip on the CPU
card, an Intel 440. The other two bus segments are 5-slots each conected
to the first bus (bus 0) by DEC 21150-AA bridge chips.

I have a PCI card: a Bancomm bc635pci time processor. It has two memory
areas available on the PCI bus. I have some simple code to attach and
map the two areas into process address space, and read some basic data
from them.

The code works a fine when the card is plugged into my first PCI bus
(bus 0), attached to the host-PCI Intel bridge chip. The attach works,
the mmap_device_memory() works, and I can access card resources when
I use the process addresses returned by the mmap_device_memory() calls.
However, when I plug the card into any other bus, connected to the
first with a DEC 21150-AA bridge, it works as before up until I try to
use the mapped address. The process addresses returned by the
mmap_device_memory() call return 0xffffffff when used, so the same code
does not work.

Bus 0 is connected to the processor by an Intel 440 host-PCI bridge.
However, the other off-board buses are connected to bus 0 with a
DEC21150-AA chip.

Clues:

When QRTP boots up and the board is in one of these other buses
(connected by the DEC 21150 chip), the message " Range check failed: MEM
vendor = 0x12e2, device = 0x4013" (or something like it.) is displayed
twice (I presume once for each memory area on the card.)

The base addresses in the info structure are different when the card is
plugged into different slots.

Code Fragment:

phdl = pci_attach(0);
if (phdl == -1) {
perror(“pci_attach”);
exit(EXIT_FAILURE);
}
memset(&info, 0, sizeof(info));

/* Device index: which PCI card with this vendor and device id
*/

pidx = 0;

/*

  • Look up Bancomm bc635pci by vendor and device
    */

info.VendorId = BC635PCI_VENDORID;
info.DeviceId = BC635PCI_DEVICEID;

/*

  • Do pci_attach_device() to find device, and create handle
    */

hdl = pci_attach_device(NULL, PCI_SHARE | PCI_SEARCH_VENDEV |
PCI_INIT_AL
pidx, &info);

if (hdl == NULL) {
fprintf(std err, “pci_attach_device() failed.\n”);
exit(EXIT_FAILURE);
}

register_base = mmap_device_memory(NULL,
info.BaseAddressSize[0],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[0]);

nvram_base = mmap_device_memory(NULL, info.BaseAddressSize[1],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[1]);

/* Print first some 32-bit words of card registers */

printf(“ACK Register : 0x%08x\n”, register_base[5]);
printf(“Control Register: 0x%08x\n”, register_base[4]);
printf(“Interrupt mask : 0x%08x\n”, register_base[6]);
printf(“Interrupt Status: 0x%08x\n”, register_base[7]);

/* Strobe time reguest and print time */

strobe = register_base[0];

printf(“Minor Time : 0x%08x\n”, register_base[12]);
printf(“Major Time : 0x%08x\n”, register_base[13]);

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

Thanks for the info. I looked at several backplanes and many seemed to use
the DEC 21150 PCI-PCI bridge chip, which business, interestingly Intel bought
from DEC. Since I really need lots of PCI slots (or some expansion board
slots, be they PCI, VME, ISA or whatever) for my project, unless there is
support for PCI bridges in QRTP, I’m at a dead end with my backplane and
QRTP. I must get support for this bridge in QRTP, choose another hardware
platform (VMR, cPCI, ISA), choose another backplane for which QRTP supports
the bridges, or choose another OS. I really like QRTP and would be reluctant
to give it up.

What PCI bridge chip did QSSL provide support for on your project? Maybe
I can get the patched pci-bios if it matches the DEC21150-AA.

Anyone know of any bridges that are supported? Maybe I can buy another
backplane.

cPCI to my knowledge has a great advantage in that it does not require
PCI-PCI bridges.

As an aside, I went into this knowing little about PCI, and made a stupid
assumption that bridges were part of the PCI standard and were therefore most
likely to be transparent to SW, thus no problem to QRTP. As I’m finding out
reading the PCI System Architecture book, PCi-PCI bridges have plenty of
non-standard aspects requiring custom SW. In retrospect I now see that since
it is not, large numbers of boards (slots) are not the best area for PCI.
Thus cPCI.

Igor Kovalenko wrote:

We had multiply problems of that sort with boards containing their own
PCI buses behind bridges. Every time it had to be fixed by patch for
pci-bios, which QNX did but I’m afraid that solved only our praticular
problems, not in general.

Trouble is, they don’t have explicit support for PCI chipsets in their
architecture. Some chips apparently are supported by pci-bios, but some
are not, especially bridges. To fix it in general would require
something like set of callins/callouts in pci-bios server and set of
chip-specific shared libraries, then some DDK to develop new ones… a
whole new domain of development basically.

  • igor

“John H. Zouck” wrote:

Quick Question (Ignore the rest depending on the answer):

Is there a known problem with QRTP PCI and the DEC 21150-AA bridge
chip?
Is there a known problem with PCI bridges in general?

Summary:

Card works on PCI bus 0 but not 2 or 3. May be the bridge chip, or PCI
SW problems using bridge chip.

Details:

My system consists of a Pentium CPU card plugged into a ‘passive’
backplane with 12 PCI slots. It also has ISA slots, but that is beside
th epoint here.) The CPU card has all standard PC peripherals on it. The
PCI slots on the backplane are divided among three PCI bus segments.
One, bus 0, is connected directly to the host bridge chip on the CPU
card, an Intel 440. The other two bus segments are 5-slots each conected
to the first bus (bus 0) by DEC 21150-AA bridge chips.

I have a PCI card: a Bancomm bc635pci time processor. It has two memory
areas available on the PCI bus. I have some simple code to attach and
map the two areas into process address space, and read some basic data
from them.

The code works a fine when the card is plugged into my first PCI bus
(bus 0), attached to the host-PCI Intel bridge chip. The attach works,
the mmap_device_memory() works, and I can access card resources when
I use the process addresses returned by the mmap_device_memory() calls.
However, when I plug the card into any other bus, connected to the
first with a DEC 21150-AA bridge, it works as before up until I try to
use the mapped address. The process addresses returned by the
mmap_device_memory() call return 0xffffffff when used, so the same code
does not work.

Bus 0 is connected to the processor by an Intel 440 host-PCI bridge.
However, the other off-board buses are connected to bus 0 with a
DEC21150-AA chip.

Clues:

When QRTP boots up and the board is in one of these other buses
(connected by the DEC 21150 chip), the message " Range check failed: MEM
vendor = 0x12e2, device = 0x4013" (or something like it.) is displayed
twice (I presume once for each memory area on the card.)

The base addresses in the info structure are different when the card is
plugged into different slots.

Code Fragment:

phdl = pci_attach(0);
if (phdl == -1) {
perror(“pci_attach”);
exit(EXIT_FAILURE);
}
memset(&info, 0, sizeof(info));

/* Device index: which PCI card with this vendor and device id
*/

pidx = 0;

/*

  • Look up Bancomm bc635pci by vendor and device
    */

info.VendorId = BC635PCI_VENDORID;
info.DeviceId = BC635PCI_DEVICEID;

/*

  • Do pci_attach_device() to find device, and create handle
    */

hdl = pci_attach_device(NULL, PCI_SHARE | PCI_SEARCH_VENDEV |
PCI_INIT_AL
pidx, &info);

if (hdl == NULL) {
fprintf(std err, “pci_attach_device() failed.\n”);
exit(EXIT_FAILURE);
}

register_base = mmap_device_memory(NULL,
info.BaseAddressSize[0],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[0]);

nvram_base = mmap_device_memory(NULL, info.BaseAddressSize[1],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[1]);

/* Print first some 32-bit words of card registers */

printf(“ACK Register : 0x%08x\n”, register_base[5]);
printf(“Control Register: 0x%08x\n”, register_base[4]);
printf(“Interrupt mask : 0x%08x\n”, register_base[6]);
printf(“Interrupt Status: 0x%08x\n”, register_base[7]);

/* Strobe time reguest and print time */

strobe = register_base[0];

printf(“Minor Time : 0x%08x\n”, register_base[12]);
printf(“Major Time : 0x%08x\n”, register_base[13]);

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

“John H. Zouck” wrote:

Thanks for the info. I looked at several backplanes and many seemed to use
the DEC 21150 PCI-PCI bridge chip, which business, interestingly Intel bought
from DEC. Since I really need lots of PCI slots (or some expansion board
slots, be they PCI, VME, ISA or whatever) for my project, unless there is
support for PCI bridges in QRTP, I’m at a dead end with my backplane and
QRTP. I must get support for this bridge in QRTP, choose another hardware
platform (VMR, cPCI, ISA), choose another backplane for which QRTP supports
the bridges, or choose another OS. I really like QRTP and would be reluctant
to give it up.

What PCI bridge chip did QSSL provide support for on your project? Maybe
I can get the patched pci-bios if it matches the DEC21150-AA.

Motorola CPX8216 cPCI chassis. But that’s not the whole story.

Anyone know of any bridges that are supported? Maybe I can buy another
backplane.

21154 apparently.

cPCI to my knowledge has a great advantage in that it does not require
PCI-PCI bridges.

Many cPCI boards however have a bridge or two and buses behind them :wink:
In our case most of bridges are 21154 or 21152. Your boards may have
different ones, so it makes little sense to choose the chassis in hope
for support.

Our chassis is not a bad choice however. It has hot-swap support and QNX
is developing drivers for it.

As an aside, I went into this knowing little about PCI, and made a stupid
assumption that bridges were part of the PCI standard and were therefore most
likely to be transparent to SW, thus no problem to QRTP. As I’m finding out
reading the PCI System Architecture book, PCi-PCI bridges have plenty of
non-standard aspects requiring custom SW. In retrospect I now see that since
it is not, large numbers of boards (slots) are not the best area for PCI.
Thus cPCI.

I suppose that earlier or later Intel will come up with specs. They did
not buy DEC business for no reason, did they?

Igor Kovalenko wrote:

We had multiply problems of that sort with boards containing their own
PCI buses behind bridges. Every time it had to be fixed by patch for
pci-bios, which QNX did but I’m afraid that solved only our praticular
problems, not in general.

Trouble is, they don’t have explicit support for PCI chipsets in their
architecture. Some chips apparently are supported by pci-bios, but some
are not, especially bridges. To fix it in general would require
something like set of callins/callouts in pci-bios server and set of
chip-specific shared libraries, then some DDK to develop new ones… a
whole new domain of development basically.

  • igor

“John H. Zouck” wrote:

Quick Question (Ignore the rest depending on the answer):

Is there a known problem with QRTP PCI and the DEC 21150-AA bridge
chip?
Is there a known problem with PCI bridges in general?

Summary:

Card works on PCI bus 0 but not 2 or 3. May be the bridge chip, or PCI
SW problems using bridge chip.

Details:

My system consists of a Pentium CPU card plugged into a ‘passive’
backplane with 12 PCI slots. It also has ISA slots, but that is beside
th epoint here.) The CPU card has all standard PC peripherals on it. The
PCI slots on the backplane are divided among three PCI bus segments.
One, bus 0, is connected directly to the host bridge chip on the CPU
card, an Intel 440. The other two bus segments are 5-slots each conected
to the first bus (bus 0) by DEC 21150-AA bridge chips.

I have a PCI card: a Bancomm bc635pci time processor. It has two memory
areas available on the PCI bus. I have some simple code to attach and
map the two areas into process address space, and read some basic data
from them.

The code works a fine when the card is plugged into my first PCI bus
(bus 0), attached to the host-PCI Intel bridge chip. The attach works,
the mmap_device_memory() works, and I can access card resources when
I use the process addresses returned by the mmap_device_memory() calls.
However, when I plug the card into any other bus, connected to the
first with a DEC 21150-AA bridge, it works as before up until I try to
use the mapped address. The process addresses returned by the
mmap_device_memory() call return 0xffffffff when used, so the same code
does not work.

Bus 0 is connected to the processor by an Intel 440 host-PCI bridge.
However, the other off-board buses are connected to bus 0 with a
DEC21150-AA chip.

Clues:

When QRTP boots up and the board is in one of these other buses
(connected by the DEC 21150 chip), the message " Range check failed: MEM
vendor = 0x12e2, device = 0x4013" (or something like it.) is displayed
twice (I presume once for each memory area on the card.)

The base addresses in the info structure are different when the card is
plugged into different slots.

Code Fragment:

phdl = pci_attach(0);
if (phdl == -1) {
perror(“pci_attach”);
exit(EXIT_FAILURE);
}
memset(&info, 0, sizeof(info));

/* Device index: which PCI card with this vendor and device id
*/

pidx = 0;

/*

  • Look up Bancomm bc635pci by vendor and device
    */

info.VendorId = BC635PCI_VENDORID;
info.DeviceId = BC635PCI_DEVICEID;

/*

  • Do pci_attach_device() to find device, and create handle
    */

hdl = pci_attach_device(NULL, PCI_SHARE | PCI_SEARCH_VENDEV |
PCI_INIT_AL
pidx, &info);

if (hdl == NULL) {
fprintf(std err, “pci_attach_device() failed.\n”);
exit(EXIT_FAILURE);
}

register_base = mmap_device_memory(NULL,
info.BaseAddressSize[0],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[0]);

nvram_base = mmap_device_memory(NULL, info.BaseAddressSize[1],
PROT_WRITE | PROT_READ | PROT_NOCACHE,
MAP_TYPE,
info.CpuBaseAddress[1]);

/* Print first some 32-bit words of card registers */

printf(“ACK Register : 0x%08x\n”, register_base[5]);
printf(“Control Register: 0x%08x\n”, register_base[4]);
printf(“Interrupt mask : 0x%08x\n”, register_base[6]);
printf(“Interrupt Status: 0x%08x\n”, register_base[7]);

/* Strobe time reguest and print time */

strobe = register_base[0];

printf(“Minor Time : 0x%08x\n”, register_base[12]);
printf(“Major Time : 0x%08x\n”, register_base[13]);

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

Our approach for now is to use the 7 ISA slots on my backplane and buy new ISA
IP carrier cards.
We should have no problems with this, since ISA seems to be used already, but who
knows?. When the bridge chip problem gets solved, then we will try again…

Igor Kovalenko wrote:

“John H. Zouck” wrote:

Thanks for the info. I looked at several backplanes and many seemed to use
the DEC 21150 PCI-PCI bridge chip, which business, interestingly Intel bought
from DEC. Since I really need lots of PCI slots (or some expansion board
slots, be they PCI, VME, ISA or whatever) for my project, unless there is
support for PCI bridges in QRTP, I’m at a dead end with my backplane and
QRTP. I must get support for this bridge in QRTP, choose another hardware
platform (VMR, cPCI, ISA), choose another backplane for which QRTP supports
the bridges, or choose another OS. I really like QRTP and would be reluctant
to give it up.

What PCI bridge chip did QSSL provide support for on your project? Maybe
I can get the patched pci-bios if it matches the DEC21150-AA.


Motorola CPX8216 cPCI chassis. But that’s not the whole story.

Anyone know of any bridges that are supported? Maybe I can buy another
backplane.


21154 apparently.

cPCI to my knowledge has a great advantage in that it does not require
PCI-PCI bridges.


Many cPCI boards however have a bridge or two and buses behind them > :wink:
In our case most of bridges are 21154 or 21152. Your boards may have
different ones, so it makes little sense to choose the chassis in hope
for support.

Our chassis is not a bad choice however. It has hot-swap support and QNX
is developing drivers for it.

As an aside, I went into this knowing little about PCI, and made a stupid
assumption that bridges were part of the PCI standard and were therefore most
likely to be transparent to SW, thus no problem to QRTP. As I’m finding out
reading the PCI System Architecture book, PCi-PCI bridges have plenty of
non-standard aspects requiring custom SW. In retrospect I now see that since
it is not, large numbers of boards (slots) are not the best area for PCI.
Thus cPCI.


I suppose that earlier or later Intel will come up with specs. They did
not buy DEC business for no reason, did they?

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory