PCI Servers Treat Bridge Devices Differently?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Hi,

We are working on developing our own PCI and CPCI cards using PLX
Technologies’ PCI chip sets. One nice feature of these devices is that they
are very configurable with regards to amount of PCI resources required. It
also allows for setting the device class, device & vendor ids, etc. This
configuration information is stored in a EEPROM for configuration at
powerup.

This EEPROM can be configured through the PCI configuration space of the
device except for the need for a couple accesses to PCI address block 0.

Now, our problem is that we have boards with blank, unprogrammed EEPROMs
that need to be programmed. The PLX chip is working and its configuration
space is accessible, but, we cannot get access to PCI address block 0. The
PCI server does not report that the device has any address blocks associated
with it, even though we know for sure (hard coded in the PLX chip) that it
does.

We think that the problem is that the PCI servers treat bridge devices
differently than other devices. Unconfigured PLX chips use the “other
bridge” class code.

We verified our findings using a PCI card for with we have a DOS program
that allows us to configure the PLX chip. We do not have this option
currently available to us on the CPCI platform. We plugged in a propperly
configured PCI card and got the following output from our driver. This
information matches with “pci -v” but this output also includes the actual
PCI configuration space registers.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x11800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
devc-csp.c:Memory bank 0 mapped to address 40100000.
devc-csp.c:Memory bank 2 mapped to address 40101000.
devc-csp.c:Memory bank 3 mapped to address 40102000.
devc-csp.c:Memory bank 4 mapped to address 40202000.
devc-csp.c:Memory bank 5 mapped to address 50202000.
Found 6 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x9050
SubsystemVendorId: 0x10B5
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x118000
Irq: 5
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciBaseAddress 0: 0x00000000F4800000
CpuBaseAddress 0: 0x00000000F4800000
BaseAddressSize 0: 128
PciBaseAddress 1: 0x000000000000B401
CpuBaseAddress 1: 0x000000000000B401
BaseAddressSize 1: 128
PciBaseAddress 2: 0x00000000F4000000
CpuBaseAddress 2: 0x00000000F4000000
BaseAddressSize 2: 4096
PciBaseAddress 3: 0x00000000F3800000
CpuBaseAddress 3: 0x00000000F3800000
BaseAddressSize 3: 1048576
PciBaseAddress 4: 0x00000000E0000000
CpuBaseAddress 4: 0x00000000E0000000
BaseAddressSize 4: 268435456
PciBaseAddress 5: 0x00000000F7000008
CpuBaseAddress 5: 0x00000000F7000008
BaseAddressSize 5: 1048576
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0

As you can see, all 6 address blocks are available and configured.

Then we changed the class code on this card to be “other bridge” to match an
unconfigured card. No other configuration information was changed. The
following is the output from the driver after this change.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x06800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
Found 0 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x0000
SubsystemVendorId: 0x0000
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x68000 Bridge-other
Irq: 255
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0
No address blocks exist on this device.

Notice that the PCI server did not report any address blocks to the driver.
Again this is verified with “pci -v”. Looking at the PCI configuration
registers, we see that the address blocks were configured though.

Without getting access to address block 0, we can’t program the EEPROM.
Without a programmed EEPROM, we can’t access address block 0. Catch-22!

Is there any reason why the PCI server does not report the address block to
the drivers for “other bridge” devices? We get the same results using
pci-bios on an x86 PC and pci-raven on a PPC board.

Can we get this fixed?

Thanks,

Wayne Fisher

2

We do not setup PCI bridge type devices in pci-bios, as there are so
many different types of bridge chips out there. Why don’t you use the
pci_write_config() function call to write a valid address into the device,
so you can then program your EEPROM?

Previously, Wayne Fisher wrote in qdn.public.qnxrtp.os:

Hi,

We are working on developing our own PCI and CPCI cards using PLX
Technologies’ PCI chip sets. One nice feature of these devices is that they
are very configurable with regards to amount of PCI resources required. It
also allows for setting the device class, device & vendor ids, etc. This
configuration information is stored in a EEPROM for configuration at
powerup.

This EEPROM can be configured through the PCI configuration space of the
device except for the need for a couple accesses to PCI address block 0.

Now, our problem is that we have boards with blank, unprogrammed EEPROMs
that need to be programmed. The PLX chip is working and its configuration
space is accessible, but, we cannot get access to PCI address block 0. The
PCI server does not report that the device has any address blocks associated
with it, even though we know for sure (hard coded in the PLX chip) that it
does.

We think that the problem is that the PCI servers treat bridge devices
differently than other devices. Unconfigured PLX chips use the “other
bridge” class code.

We verified our findings using a PCI card for with we have a DOS program
that allows us to configure the PLX chip. We do not have this option
currently available to us on the CPCI platform. We plugged in a propperly
configured PCI card and got the following output from our driver. This
information matches with “pci -v” but this output also includes the actual
PCI configuration space registers.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x11800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
devc-csp.c:Memory bank 0 mapped to address 40100000.
devc-csp.c:Memory bank 2 mapped to address 40101000.
devc-csp.c:Memory bank 3 mapped to address 40102000.
devc-csp.c:Memory bank 4 mapped to address 40202000.
devc-csp.c:Memory bank 5 mapped to address 50202000.
Found 6 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x9050
SubsystemVendorId: 0x10B5
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x118000
Irq: 5
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciBaseAddress 0: 0x00000000F4800000
CpuBaseAddress 0: 0x00000000F4800000
BaseAddressSize 0: 128
PciBaseAddress 1: 0x000000000000B401
CpuBaseAddress 1: 0x000000000000B401
BaseAddressSize 1: 128
PciBaseAddress 2: 0x00000000F4000000
CpuBaseAddress 2: 0x00000000F4000000
BaseAddressSize 2: 4096
PciBaseAddress 3: 0x00000000F3800000
CpuBaseAddress 3: 0x00000000F3800000
BaseAddressSize 3: 1048576
PciBaseAddress 4: 0x00000000E0000000
CpuBaseAddress 4: 0x00000000E0000000
BaseAddressSize 4: 268435456
PciBaseAddress 5: 0x00000000F7000008
CpuBaseAddress 5: 0x00000000F7000008
BaseAddressSize 5: 1048576
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0

As you can see, all 6 address blocks are available and configured.

Then we changed the class code on this card to be “other bridge” to match an
unconfigured card. No other configuration information was changed. The
following is the output from the driver after this change.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x06800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
Found 0 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x0000
SubsystemVendorId: 0x0000
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x68000 Bridge-other
Irq: 255
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0
No address blocks exist on this device.

Notice that the PCI server did not report any address blocks to the driver.
Again this is verified with “pci -v”. Looking at the PCI configuration
registers, we see that the address blocks were configured though.

Without getting access to address block 0, we can’t program the EEPROM.
Without a programmed EEPROM, we can’t access address block 0. Catch-22!

Is there any reason why the PCI server does not report the address block to
the drivers for “other bridge” devices? We get the same results using
pci-bios on an x86 PC and pci-raven on a PPC board.

Can we get this fixed?

Thanks,

Wayne Fisher
\

3

I was hoping that we would not have to re-invent the wheel. The PCI servers
already do everything that we need them to do, just not for this bridge
type. And we have also learned that it is not just our unprogrammed device
that has this problem.

We have a third party IP (Industry Pack) carrier board that holds four
mezzanine style IP modules that also uses the “other bridge” class. That
seems like an appropriate class for such a card. Again, all it needs for PCI
configuration is that the address blocks get configured and reported by the
PCI server. Then writing a driver for it is easy and straight forward.

Could a command line option be added to the PCI servers that would allow
them to configure and report the address blocks for the 0x068000 (“other
bridge”) class? The address blocks would need to be configured at some time
anyways, why not during the initial configuration? If it can’t be added to
pci-bios, could it be added to pci-raven?

Looking at the dump of the PCI configuration registers, it already looks
like the address blocks are being configured. There is a base address in
each of the base address registers. I would just like them to be reported.

Thanks,

Wayne

“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:Voyager.010904132208.22675B@node90.ott.qnx.com…

We do not setup PCI bridge type devices in pci-bios, as there are so
many different types of bridge chips out there. Why don’t you use the
pci_write_config() function call to write a valid address into the device,
so you can then program your EEPROM?

Previously, Wayne Fisher wrote in qdn.public.qnxrtp.os:
Hi,

We are working on developing our own PCI and CPCI cards using PLX
Technologies’ PCI chip sets. One nice feature of these devices is that
they
are very configurable with regards to amount of PCI resources required.
It
also allows for setting the device class, device & vendor ids, etc. This
configuration information is stored in a EEPROM for configuration at
powerup.

This EEPROM can be configured through the PCI configuration space of the
device except for the need for a couple accesses to PCI address block 0.

Now, our problem is that we have boards with blank, unprogrammed EEPROMs
that need to be programmed. The PLX chip is working and its
configuration
space is accessible, but, we cannot get access to PCI address block 0.
The
PCI server does not report that the device has any address blocks
associated
with it, even though we know for sure (hard coded in the PLX chip) that
it
does.

We think that the problem is that the PCI servers treat bridge devices
differently than other devices. Unconfigured PLX chips use the “other
bridge” class code.

We verified our findings using a PCI card for with we have a DOS program
that allows us to configure the PLX chip. We do not have this option
currently available to us on the CPCI platform. We plugged in a
propperly
configured PCI card and got the following output from our driver. This
information matches with “pci -v” but this output also includes the
actual
PCI configuration space registers.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x11800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
devc-csp.c:Memory bank 0 mapped to address 40100000.
devc-csp.c:Memory bank 2 mapped to address 40101000.
devc-csp.c:Memory bank 3 mapped to address 40102000.
devc-csp.c:Memory bank 4 mapped to address 40202000.
devc-csp.c:Memory bank 5 mapped to address 50202000.
Found 6 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x9050
SubsystemVendorId: 0x10B5
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x118000
Irq: 5
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciBaseAddress 0: 0x00000000F4800000
CpuBaseAddress 0: 0x00000000F4800000
BaseAddressSize 0: 128
PciBaseAddress 1: 0x000000000000B401
CpuBaseAddress 1: 0x000000000000B401
BaseAddressSize 1: 128
PciBaseAddress 2: 0x00000000F4000000
CpuBaseAddress 2: 0x00000000F4000000
BaseAddressSize 2: 4096
PciBaseAddress 3: 0x00000000F3800000
CpuBaseAddress 3: 0x00000000F3800000
BaseAddressSize 3: 1048576
PciBaseAddress 4: 0x00000000E0000000
CpuBaseAddress 4: 0x00000000E0000000
BaseAddressSize 4: 268435456
PciBaseAddress 5: 0x00000000F7000008
CpuBaseAddress 5: 0x00000000F7000008
BaseAddressSize 5: 1048576
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0

As you can see, all 6 address blocks are available and configured.

Then we changed the class code on this card to be “other bridge” to
match an
unconfigured card. No other configuration information was changed. The
following is the output from the driver after this change.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x06800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
Found 0 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x0000
SubsystemVendorId: 0x0000
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x68000 Bridge-other
Irq: 255
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0
No address blocks exist on this device.

Notice that the PCI server did not report any address blocks to the
driver.
Again this is verified with “pci -v”. Looking at the PCI configuration
registers, we see that the address blocks were configured though.

Without getting access to address block 0, we can’t program the EEPROM.
Without a programmed EEPROM, we can’t access address block 0. Catch-22!

Is there any reason why the PCI server does not report the address block
to
the drivers for “other bridge” devices? We get the same results using
pci-bios on an x86 PC and pci-raven on a PPC board.

Can we get this fixed?

Thanks,

Wayne Fisher

\

4

Hugh,

this approach plain sucks. They aren’t the only one who needs bridges to
be handled more intelligently. And there aren’t all that many types of
bridges, probably not more than video/audio/network devices. Why don’t
you say “we don’t support video cards because there’s so many of them” ?
Doesn’t QNX claim to be ‘leading realtime OS’ anymore?

Lack of this functionality practically makes QNX unsuitable for any cPCI
hot-swap system which you seem to be targeting, since may hot-pluggable
boards will have bridges and devices behind them. We were talking about
this for over a year I believe and nothing changed. What does it take to
support bunch of most popular bridges? I don’t believe it is more
complicated than other drivers.

  • igor

Hugh Brown wrote:

We do not setup PCI bridge type devices in pci-bios, as there are so
many different types of bridge chips out there. Why don’t you use the
pci_write_config() function call to write a valid address into the device,
so you can then program your EEPROM?

Previously, Wayne Fisher wrote in qdn.public.qnxrtp.os:
Hi,

We are working on developing our own PCI and CPCI cards using PLX
Technologies’ PCI chip sets. One nice feature of these devices is that they
are very configurable with regards to amount of PCI resources required. It
also allows for setting the device class, device & vendor ids, etc. This
configuration information is stored in a EEPROM for configuration at
powerup.

This EEPROM can be configured through the PCI configuration space of the
device except for the need for a couple accesses to PCI address block 0.

Now, our problem is that we have boards with blank, unprogrammed EEPROMs
that need to be programmed. The PLX chip is working and its configuration
space is accessible, but, we cannot get access to PCI address block 0. The
PCI server does not report that the device has any address blocks associated
with it, even though we know for sure (hard coded in the PLX chip) that it
does.

We think that the problem is that the PCI servers treat bridge devices
differently than other devices. Unconfigured PLX chips use the “other
bridge” class code.

We verified our findings using a PCI card for with we have a DOS program
that allows us to configure the PLX chip. We do not have this option
currently available to us on the CPCI platform. We plugged in a propperly
configured PCI card and got the following output from our driver. This
information matches with “pci -v” but this output also includes the actual
PCI configuration space registers.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x11800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
devc-csp.c:Memory bank 0 mapped to address 40100000.
devc-csp.c:Memory bank 2 mapped to address 40101000.
devc-csp.c:Memory bank 3 mapped to address 40102000.
devc-csp.c:Memory bank 4 mapped to address 40202000.
devc-csp.c:Memory bank 5 mapped to address 50202000.
Found 6 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x9050
SubsystemVendorId: 0x10B5
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x118000
Irq: 5
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciBaseAddress 0: 0x00000000F4800000
CpuBaseAddress 0: 0x00000000F4800000
BaseAddressSize 0: 128
PciBaseAddress 1: 0x000000000000B401
CpuBaseAddress 1: 0x000000000000B401
BaseAddressSize 1: 128
PciBaseAddress 2: 0x00000000F4000000
CpuBaseAddress 2: 0x00000000F4000000
BaseAddressSize 2: 4096
PciBaseAddress 3: 0x00000000F3800000
CpuBaseAddress 3: 0x00000000F3800000
BaseAddressSize 3: 1048576
PciBaseAddress 4: 0x00000000E0000000
CpuBaseAddress 4: 0x00000000E0000000
BaseAddressSize 4: 268435456
PciBaseAddress 5: 0x00000000F7000008
CpuBaseAddress 5: 0x00000000F7000008
BaseAddressSize 5: 1048576
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0

As you can see, all 6 address blocks are available and configured.

Then we changed the class code on this card to be “other bridge” to match an
unconfigured card. No other configuration information was changed. The
following is the output from the driver after this change.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x06800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
Found 0 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x0000
SubsystemVendorId: 0x0000
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x68000 Bridge-other
Irq: 255
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0
No address blocks exist on this device.

Notice that the PCI server did not report any address blocks to the driver.
Again this is verified with “pci -v”. Looking at the PCI configuration
registers, we see that the address blocks were configured though.

Without getting access to address block 0, we can’t program the EEPROM.
Without a programmed EEPROM, we can’t access address block 0. Catch-22!

Is there any reason why the PCI server does not report the address block to
the drivers for “other bridge” devices? We get the same results using
pci-bios on an x86 PC and pci-raven on a PPC board.

Can we get this fixed?

Thanks,

Wayne Fisher
\

5

Hi Hugh…

I wonder if you or someone at QNX could put together an article or a
this-is-an-example-on-PCI-bridges? We are also developing drivers for
cPCI, and I am also having problems in this area.

Thanks…

Miguel.


Hugh Brown wrote:

We do not setup PCI bridge type devices in pci-bios, as there are so
many different types of bridge chips out there. Why don’t you use the
pci_write_config() function call to write a valid address into the device,
so you can then program your EEPROM?

Previously, Wayne Fisher wrote in qdn.public.qnxrtp.os:
Hi,

We are working on developing our own PCI and CPCI cards using PLX
Technologies’ PCI chip sets. One nice feature of these devices is that they
are very configurable with regards to amount of PCI resources required. It
also allows for setting the device class, device & vendor ids, etc. This
configuration information is stored in a EEPROM for configuration at
powerup.

This EEPROM can be configured through the PCI configuration space of the
device except for the need for a couple accesses to PCI address block 0.

Now, our problem is that we have boards with blank, unprogrammed EEPROMs
that need to be programmed. The PLX chip is working and its configuration
space is accessible, but, we cannot get access to PCI address block 0. The
PCI server does not report that the device has any address blocks associated
with it, even though we know for sure (hard coded in the PLX chip) that it
does.

We think that the problem is that the PCI servers treat bridge devices
differently than other devices. Unconfigured PLX chips use the “other
bridge” class code.

We verified our findings using a PCI card for with we have a DOS program
that allows us to configure the PLX chip. We do not have this option
currently available to us on the CPCI platform. We plugged in a propperly
configured PCI card and got the following output from our driver. This
information matches with “pci -v” but this output also includes the actual
PCI configuration space registers.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x11800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
devc-csp.c:Memory bank 0 mapped to address 40100000.
devc-csp.c:Memory bank 2 mapped to address 40101000.
devc-csp.c:Memory bank 3 mapped to address 40102000.
devc-csp.c:Memory bank 4 mapped to address 40202000.
devc-csp.c:Memory bank 5 mapped to address 50202000.
Found 6 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x9050
SubsystemVendorId: 0x10B5
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x118000
Irq: 5
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciBaseAddress 0: 0x00000000F4800000
CpuBaseAddress 0: 0x00000000F4800000
BaseAddressSize 0: 128
PciBaseAddress 1: 0x000000000000B401
CpuBaseAddress 1: 0x000000000000B401
BaseAddressSize 1: 128
PciBaseAddress 2: 0x00000000F4000000
CpuBaseAddress 2: 0x00000000F4000000
BaseAddressSize 2: 4096
PciBaseAddress 3: 0x00000000F3800000
CpuBaseAddress 3: 0x00000000F3800000
BaseAddressSize 3: 1048576
PciBaseAddress 4: 0x00000000E0000000
CpuBaseAddress 4: 0x00000000E0000000
BaseAddressSize 4: 268435456
PciBaseAddress 5: 0x00000000F7000008
CpuBaseAddress 5: 0x00000000F7000008
BaseAddressSize 5: 1048576
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0

As you can see, all 6 address blocks are available and configured.

Then we changed the class code on this card to be “other bridge” to match an
unconfigured card. No other configuration information was changed. The
following is the output from the driver after this change.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x06800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
Found 0 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x0000
SubsystemVendorId: 0x0000
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x68000 Bridge-other
Irq: 255
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0
No address blocks exist on this device.

Notice that the PCI server did not report any address blocks to the driver.
Again this is verified with “pci -v”. Looking at the PCI configuration
registers, we see that the address blocks were configured though.

Without getting access to address block 0, we can’t program the EEPROM.
Without a programmed EEPROM, we can’t access address block 0. Catch-22!

Is there any reason why the PCI server does not report the address block to
the drivers for “other bridge” devices? We get the same results using
pci-bios on an x86 PC and pci-raven on a PPC board.

Can we get this fixed?

Thanks,

Wayne Fisher

\

–

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

6

We are looking into this, but it won’t be a quick fix.

Previously, Wayne Fisher wrote in qdn.public.qnxrtp.os:

I was hoping that we would not have to re-invent the wheel. The PCI servers
already do everything that we need them to do, just not for this bridge
type. And we have also learned that it is not just our unprogrammed device
that has this problem.

We have a third party IP (Industry Pack) carrier board that holds four
mezzanine style IP modules that also uses the “other bridge” class. That
seems like an appropriate class for such a card. Again, all it needs for PCI
configuration is that the address blocks get configured and reported by the
PCI server. Then writing a driver for it is easy and straight forward.

Could a command line option be added to the PCI servers that would allow
them to configure and report the address blocks for the 0x068000 (“other
bridge”) class? The address blocks would need to be configured at some time
anyways, why not during the initial configuration? If it can’t be added to
pci-bios, could it be added to pci-raven?

Looking at the dump of the PCI configuration registers, it already looks
like the address blocks are being configured. There is a base address in
each of the base address registers. I would just like them to be reported.

Thanks,

Wayne

“Hugh Brown” <> hsbrown@qnx.com> > wrote in message
news:> Voyager.010904132208.22675B@node90.ott.qnx.com> …
We do not setup PCI bridge type devices in pci-bios, as there are so
many different types of bridge chips out there. Why don’t you use the
pci_write_config() function call to write a valid address into the device,
so you can then program your EEPROM?

Previously, Wayne Fisher wrote in qdn.public.qnxrtp.os:
Hi,

We are working on developing our own PCI and CPCI cards using PLX
Technologies’ PCI chip sets. One nice feature of these devices is that
they
are very configurable with regards to amount of PCI resources required.
It
also allows for setting the device class, device & vendor ids, etc. This
configuration information is stored in a EEPROM for configuration at
powerup.

This EEPROM can be configured through the PCI configuration space of the
device except for the need for a couple accesses to PCI address block 0.

Now, our problem is that we have boards with blank, unprogrammed EEPROMs
that need to be programmed. The PLX chip is working and its
configuration
space is accessible, but, we cannot get access to PCI address block 0.
The
PCI server does not report that the device has any address blocks
associated
with it, even though we know for sure (hard coded in the PLX chip) that
it
does.

We think that the problem is that the PCI servers treat bridge devices
differently than other devices. Unconfigured PLX chips use the “other
bridge” class code.

We verified our findings using a PCI card for with we have a DOS program
that allows us to configure the PLX chip. We do not have this option
currently available to us on the CPCI platform. We plugged in a
propperly
configured PCI card and got the following output from our driver. This
information matches with “pci -v” but this output also includes the
actual
PCI configuration space registers.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x11800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
devc-csp.c:Memory bank 0 mapped to address 40100000.
devc-csp.c:Memory bank 2 mapped to address 40101000.
devc-csp.c:Memory bank 3 mapped to address 40102000.
devc-csp.c:Memory bank 4 mapped to address 40202000.
devc-csp.c:Memory bank 5 mapped to address 50202000.
Found 6 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x9050
SubsystemVendorId: 0x10B5
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x118000
Irq: 5
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciBaseAddress 0: 0x00000000F4800000
CpuBaseAddress 0: 0x00000000F4800000
BaseAddressSize 0: 128
PciBaseAddress 1: 0x000000000000B401
CpuBaseAddress 1: 0x000000000000B401
BaseAddressSize 1: 128
PciBaseAddress 2: 0x00000000F4000000
CpuBaseAddress 2: 0x00000000F4000000
BaseAddressSize 2: 4096
PciBaseAddress 3: 0x00000000F3800000
CpuBaseAddress 3: 0x00000000F3800000
BaseAddressSize 3: 1048576
PciBaseAddress 4: 0x00000000E0000000
CpuBaseAddress 4: 0x00000000E0000000
BaseAddressSize 4: 268435456
PciBaseAddress 5: 0x00000000F7000008
CpuBaseAddress 5: 0x00000000F7000008
BaseAddressSize 5: 1048576
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0

As you can see, all 6 address blocks are available and configured.

Then we changed the class code on this card to be “other bridge” to
match an
unconfigured card. No other configuration information was changed. The
following is the output from the driver after this change.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x06800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
Found 0 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x0000
SubsystemVendorId: 0x0000
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x68000 Bridge-other
Irq: 255
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0
No address blocks exist on this device.

Notice that the PCI server did not report any address blocks to the
driver.
Again this is verified with “pci -v”. Looking at the PCI configuration
registers, we see that the address blocks were configured though.

Without getting access to address block 0, we can’t program the EEPROM.
Without a programmed EEPROM, we can’t access address block 0. Catch-22!

Is there any reason why the PCI server does not report the address block
to
the drivers for “other bridge” devices? We get the same results using
pci-bios on an x86 PC and pci-raven on a PPC board.

Can we get this fixed?

Thanks,

Wayne Fisher




\

7

I’ll see what I can do.

Previously, Miguel Simon wrote in qdn.public.qnxrtp.os:

Hi Hugh…

I wonder if you or someone at QNX could put together an article or a
this-is-an-example-on-PCI-bridges? We are also developing drivers for
cPCI, and I am also having problems in this area.

Thanks…

Miguel.


Hugh Brown wrote:

We do not setup PCI bridge type devices in pci-bios, as there are so
many different types of bridge chips out there. Why don’t you use the
pci_write_config() function call to write a valid address into the device,
so you can then program your EEPROM?

Previously, Wayne Fisher wrote in qdn.public.qnxrtp.os:
Hi,

We are working on developing our own PCI and CPCI cards using PLX
Technologies’ PCI chip sets. One nice feature of these devices is that they
are very configurable with regards to amount of PCI resources required. It
also allows for setting the device class, device & vendor ids, etc. This
configuration information is stored in a EEPROM for configuration at
powerup.

This EEPROM can be configured through the PCI configuration space of the
device except for the need for a couple accesses to PCI address block 0.

Now, our problem is that we have boards with blank, unprogrammed EEPROMs
that need to be programmed. The PLX chip is working and its configuration
space is accessible, but, we cannot get access to PCI address block 0. The
PCI server does not report that the device has any address blocks associated
with it, even though we know for sure (hard coded in the PLX chip) that it
does.

We think that the problem is that the PCI servers treat bridge devices
differently than other devices. Unconfigured PLX chips use the “other
bridge” class code.

We verified our findings using a PCI card for with we have a DOS program
that allows us to configure the PLX chip. We do not have this option
currently available to us on the CPCI platform. We plugged in a propperly
configured PCI card and got the following output from our driver. This
information matches with “pci -v” but this output also includes the actual
PCI configuration space registers.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x11800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
devc-csp.c:Memory bank 0 mapped to address 40100000.
devc-csp.c:Memory bank 2 mapped to address 40101000.
devc-csp.c:Memory bank 3 mapped to address 40102000.
devc-csp.c:Memory bank 4 mapped to address 40202000.
devc-csp.c:Memory bank 5 mapped to address 50202000.
Found 6 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x9050
SubsystemVendorId: 0x10B5
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x118000
Irq: 5
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciBaseAddress 0: 0x00000000F4800000
CpuBaseAddress 0: 0x00000000F4800000
BaseAddressSize 0: 128
PciBaseAddress 1: 0x000000000000B401
CpuBaseAddress 1: 0x000000000000B401
BaseAddressSize 1: 128
PciBaseAddress 2: 0x00000000F4000000
CpuBaseAddress 2: 0x00000000F4000000
BaseAddressSize 2: 4096
PciBaseAddress 3: 0x00000000F3800000
CpuBaseAddress 3: 0x00000000F3800000
BaseAddressSize 3: 1048576
PciBaseAddress 4: 0x00000000E0000000
CpuBaseAddress 4: 0x00000000E0000000
BaseAddressSize 4: 268435456
PciBaseAddress 5: 0x00000000F7000008
CpuBaseAddress 5: 0x00000000F7000008
BaseAddressSize 5: 1048576
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0

As you can see, all 6 address blocks are available and configured.

Then we changed the class code on this card to be “other bridge” to match an
unconfigured card. No other configuration information was changed. The
following is the output from the driver after this change.

Attaching to the PCI server.
devc-csp.c:PCI Interface: VERSION 528
devc-csp.c: PCI Bus: 0-3
devc-csp.c: HW Support: 0x0
Looking for PCI card: Vendor 0x10B5, device 0x9050.
devc-csp.c:PCI Configuration
devc-csp.c:=================
devc-csp.c:0x905010B5 0x02800003 0x06800002 0x00000008
devc-csp.c:0xF4800000 0x0000B401 0xF4000000 0xF3800000
devc-csp.c:0xE0000000 0xF7000008 0x00000000 0x905010B5
devc-csp.c:0x00000000 0x00000000 0x00000000 0x00000105
Found 0 address blocks.
DeviceId: 0x9050
VendorId: 0x10B5
SubsystemId: 0x0000
SubsystemVendorId: 0x0000
BusNumber: 2
DevFunc: 88
Revision: 2
Class: 0x68000 Bridge-other
Irq: 255
CpuIoTranslation: 0x0000000000000000
CpuMemTranslation: 0x0000000000000000
CpuISaTranslation: 0x0000000000000000
CpuBmstrTranslation: 0x0000000000000000
PciRom: 0x0000000000000000
CpuRom: 0x0000000000000000
RomSize: 0
No address blocks exist on this device.

Notice that the PCI server did not report any address blocks to the driver.
Again this is verified with “pci -v”. Looking at the PCI configuration
registers, we see that the address blocks were configured though.

Without getting access to address block 0, we can’t program the EEPROM.
Without a programmed EEPROM, we can’t access address block 0. Catch-22!

Is there any reason why the PCI server does not report the address block to
the drivers for “other bridge” devices? We get the same results using
pci-bios on an x86 PC and pci-raven on a PPC board.

Can we get this fixed?

Thanks,

Wayne Fisher




\

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

8

It would help if we could just get a more complete set of documentation for
dealing with the PCI configuration issues. Sure there are man pages for
each of the function calls, but what the QNX community needs is a big
picture view of how all the pieces fit together.
For instance, the system programming manual has an appendix that deals with
converting to and from x86 platforms, but doesn’t mention say hardly
anything about PCI function calls. The majority of the PCI function calls
don’t have an example of how to use them, and very little explanation of how
they work. They also don’t mention what tasks have to be running to support
them.
I needed to find a unallocated block of PCI memory, I looked at the PCI
calls for weeks, what I didn’t know was that there was another set of
function calls named “rsrcdbmgr_*” that also manage PCI resources. There
needs to be links in the “See also” section of the PCI calls to these, and
examples of how to use both the PCI and rsrcdbmgr command together, so we
can program our own bridges and other PCI device that don’t get
automatically configured.

Don’t get me wrong I like QNX, it has wonderful facilities for things that
would be next to impossible in Windows, or DOS. I just want to be able to
find the tools that QNX provides in a more concise manner. It’s very
frustrating to know that the OS can do what you need, but not to be able to
find the information on how to do it.

Pete

9

“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:Voyager.010905075228.22675E@node90.ott.qnx.com…

We are looking into this, but it won’t be a quick fix.

Thanks, Hugh.

Just to clarify my present needs, I would like the ability to have the
“other bridge” class of PCI devices to NOT be treated specially. Just assign
some PCI address space to each address block and report it back to my
driver. The same as for any other generic PCI card. I don’t need nor want
the OS to try create any type of transparent or semi-transparent access
through this bridge.

Thanks,

Wayne