PCI scanning and devices initialization

PCI scanning and devices initialization

[Stefano Gaiotto]

Dear colleagues,

I'm trying to use a device connected to a PCI bus, more exactly a
PCI/PCMCIA bridge
with u-boot-1.1.1 and Linux (2.4.24 and 2.6.8) in a board with MPC8270.

Both u-boot and Linux, during scanning procedure show me only the PCI
bridge [1057/18c0] but I can't see the devices connected to the bus.

I'm a novice with PCI bus and I'm not sure the board is good (is the first
prototype) and so I'd like to know if scanning procedure should tell me the
devices
connected or I have to do some device initialization before I can see them
during scanning.

I suppose I should see them during scanning and then initialise them via
PCI bus.

If my assumption is true, shall I suppose my hardware is not good? Or
anything else?

Thank you for your attention

Regards,
      Stefano


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PCI scanning and devices initialization

[Sylvain Munaut]

Stefano Gaiotto wrote:

>Dear colleagues,
>
>I'm trying to use a device connected to a PCI bus, more exactly a
>PCI/PCMCIA bridge
>with u-boot-1.1.1 and Linux (2.4.24 and 2.6.8) in a board with MPC8270.
>
>Both u-boot and Linux, during scanning procedure show me only the PCI
>bridge [1057/18c0] but I can't see the devices connected to the bus.
>
>I'm a novice with PCI bus and I'm not sure the board is good (is the first
>prototype) and so I'd like to know if scanning procedure should tell me the
>devices
>connected or I have to do some device initialization before I can see them
>during scanning.
>
>I suppose I should see them during scanning and then initialise them via
>PCI bus.
>
>If my assumption is true, shall I suppose my hardware is not good? Or
>anything else?
>
>
Hi

Yes, there may be something wrong with your hardware. I'm not familiar
with the MPC8270 PCI code but your devices should show up during scan.

At the PCI init, PCI devices don't yet have an address, so the host
detects them using configuration cycles. Theses uses a different
addressing scheme, using each address line as a kind of "chip select".
So the devices know the host is "talking" to it just by looking at it's
IDSEL line going asserted. If on your board the IDSEL isn't wired
properly then it won't work. Hopefully if that's the case, you can just
wire it by hand, it's not a high speed signal.

Also, I've come accross some simple FPGA implementation of PCI devices
that just didn't respond to config ...


Sylvain


PS: I'm not a PCI expert and that's just my understanding. There is
probably a lot of things that can go wrong.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: PCI scanning and devices initialization

[Juergen.Beisert]

Hi,

> Yes, there may be something wrong with your hardware.

This could only be _one_ reason

> At the PCI init, PCI devices don't yet have an address, so the host
> detects them using configuration cycles. Theses uses a different
> addressing scheme, using each address line as a kind of "chip select".
> So the devices know the host is "talking" to it just by
> looking at it's
> IDSEL line going asserted. If on your board the IDSEL isn't wired
> properly then it won't work. Hopefully if that's the case,
> you can just
> wire it by hand, it's not a high speed signal.

Does the U-Boot PCI setup routine handles PCI devices behind a "PCI to
anything" bridge? Sometimes simple code ignores bridges. Don't know the
current U-Boot implementation. If not, there is no chance to access any
devices behind it (even if the hardware is correct).

JB

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PCI scanning and devices initialization

[Stefano Gaiotto]

Thanks Sylvain,

I examinated board schematics and I found that pin "IDSEL" of the bridge
PCI/PCMCIA (PCI1410) in wired (at least in the schematics...) to line AD12
of data/address bus. (What's device address? 12? or 2? or 16?)

With the help of the hardware boys I want now to chek signal integrity

Regards,
      Stefano





Sylvain Munaut <tnt@246tnt.com> on 18/08/2004 14:54:43

To:    Stefano Gaiotto <Stefano.Gaiotto@marconi.com>,
       "linuxppc-embedded@lists.linuxppc.org"
       <linuxppc-embedded@lists.linuxppc.org>
cc:

Subject:    Re: PCI scanning and devices initialization


Stefano Gaiotto wrote:

>Dear colleagues,
>
>I'm trying to use a device connected to a PCI bus, more exactly a
>PCI/PCMCIA bridge
>with u-boot-1.1.1 and Linux (2.4.24 and 2.6.8) in a board with MPC8270.
>
>Both u-boot and Linux, during scanning procedure show me only the PCI
>bridge [1057/18c0] but I can't see the devices connected to the bus.
>
>I'm a novice with PCI bus and I'm not sure the board is good (is the first
>prototype) and so I'd like to know if scanning procedure should tell me
the
>devices
>connected or I have to do some device initialization before I can see them
>during scanning.
>
>I suppose I should see them during scanning and then initialise them via
>PCI bus.
>
>If my assumption is true, shall I suppose my hardware is not good? Or
>anything else?
>
>
Hi

Yes, there may be something wrong with your hardware. I'm not familiar
with the MPC8270 PCI code but your devices should show up during scan.

At the PCI init, PCI devices don't yet have an address, so the host
detects them using configuration cycles. Theses uses a different
addressing scheme, using each address line as a kind of "chip select".
So the devices know the host is "talking" to it just by looking at it's
IDSEL line going asserted. If on your board the IDSEL isn't wired
properly then it won't work. Hopefully if that's the case, you can just
wire it by hand, it's not a high speed signal.

Also, I've come accross some simple FPGA implementation of PCI devices
that just didn't respond to config ...


Sylvain


PS: I'm not a PCI expert and that's just my understanding. There is
probably a lot of things that can go wrong.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: PCI scanning and devices initialization

[Stefano Gaiotto]

Thanks Juergen,

I don't know exactly what is a "PCI to anything" bridge, anyway u-boot
bridge (60x/PCI) initilaization code seems to be almost identical to that
in Linux.
Anyway, I get the same result both in u-boot and Linux...


Linux:

# cat iomem
80000000-9fffffff : PCI prefetchable memory
a0000000-afffffff : PCI memory
#
# cat ioports
00000000-00ffffff : PCI I/O
#
# cat pci
PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Motorola MPC8265A/MPC8266 (rev 32).
      Master Capable.  Latency=248.
      Non-prefetchable 32 bit memory at 0x0 [0x1ffff].
      Prefetchable 32 bit memory at 0x0 [0x3ffffff].
#


u-boot:

...
PCI Autoconfig: Memory region: [80000000-8fffffff]
PCI Autoconfig: I/O region: [a0000000-afffffff]
...



=> pci
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
00.00.00   0x1057     0x18c0     Bridge device           0x00
00.00.01   0x1057     0x18c0     Bridge device           0x00
00.00.02   0x1057     0x18c0     Bridge device           0x00
00.00.03   0x1057     0x18c0     Bridge device           0x00
00.00.04   0x1057     0x18c0     Bridge device           0x00
00.00.05   0x1057     0x18c0     Bridge device           0x00
00.00.06   0x1057     0x18c0     Bridge device           0x00
00.00.07   0x1057     0x18c0     Bridge device           0x00
=>


Regards,
      Stefano Gaiotto





Juergen.Beisert@windriver.com on 18/08/2004 15:28:11

To:    tnt@246tnt.com, Stefano.Gaiotto@marconi.com
cc:    linuxppc-embedded@lists.linuxppc.org

Subject:    RE: PCI scanning and devices initialization


Hi,

> Yes, there may be something wrong with your hardware.

This could only be _one_ reason

> At the PCI init, PCI devices don't yet have an address, so the host
> detects them using configuration cycles. Theses uses a different
> addressing scheme, using each address line as a kind of "chip select".
> So the devices know the host is "talking" to it just by
> looking at it's
> IDSEL line going asserted. If on your board the IDSEL isn't wired
> properly then it won't work. Hopefully if that's the case,
> you can just
> wire it by hand, it's not a high speed signal.

Does the U-Boot PCI setup routine handles PCI devices behind a "PCI to
anything" bridge? Sometimes simple code ignores bridges. Don't know the
current U-Boot implementation. If not, there is no chance to access any
devices behind it (even if the hardware is correct).

JB


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PCI scanning and devices initialization

[Steve Boorman]

Stefano,

> I examinated board schematics and I found that pin "IDSEL" of the bridge
> PCI/PCMCIA (PCI1410) in wired (at least in the schematics...) to line AD12
> of data/address bus. (What's device address? 12? or 2? or 16?)

You need to look up how the configuration mechanism works for your
processor type.

When configuration type 1 cycles are performed, the device is
targeted by a configuration address written to a hardware register
(configuration_address register) in the HOST PCI bridge (contained
within your CPU) then a read or write is performed via the
configuration_data register. The configuration address is defined as
follows:-

bits 31-24 are reserved
bits 23-16 are the bus no
bits 15-11 are the device Number (using a single idsel line)
bits 10-8 are the function (for a multifunction device)
bits 7-2 is addr of the config register to read/write
bits 1 is a zero
bits 0 is a one.

The processor defines how it maps the possible 32 device numbers
(bits 15-11) as AD lines driven during a config cycle. As an example,
I use a PPC440GP and this maps device 0 by driving AD17, device 1 as
AD18 etc. So in your instance if I had connected AD12 up as an IDSEL
line I would not be able to see any devices.

If you are sure that your CPU will drive AD12 correctly then check
how the IDSEL line is coupled to the AD line. The usual method is
simply to connect a resistor from the AD line to the IDSEL line on
each PCI device (or socket) this reduces the loading on the AD line
but does restrict the IDSEL timing for fast (66 MHz and beyond) bus
speeds. This is done like this on our IBM demo board with the PPC440
and they use 2K2, which will not guarantee correct setup of IDSEL to
the PCI clock, causing device detection failures.

>
> With the help of the hardware boys I want now to chek signal
>integrity
>

If you are sure that all the above is correct then modify the pci
scan code so that it loops indefinately scanning for all 32 possible
devices. Then get a hardware guy to scope the bus. It is very simple
to look at the timing of the IDSEL lines by triggering off frameN
being asserted.

Sorry for rambling on as this is not very embedded PPC linux
specific.

Hope this helps

Regards,

Steve Boorman
-------------
steveb@baydel.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PCI scanning and devices initialization

[Stefano Gaiotto]

Steve,

thanks for your good advice.


> You need to look up how the configuration mechanism works for your
> processor type.

from "MPC8280 PowerQUICC II" Family Reference Manual" I had confirmation
about association
between field "Device number" (bit 11-15) in CONFIG_ADDR register and PCI
address line.

>From manual: "All 21 IDSEL bits are decoded starting with bit AD[11]" so
AD[12] corrisponds to device number 0b01100.
(special case: AD[31] is selected with 0b010101)

Now I'm sure that connecting IDSEL to AD[12] my device number is 12.



> If you are sure that your CPU will drive AD12 correctly then check
> how the IDSEL line is coupled to the AD line. The usual method is
> simply to connect a resistor from the AD line to the IDSEL line on
> each PCI device (or socket) this reduces the loading on the AD line
> but does restrict the IDSEL timing for fast (66 MHz and beyond) bus
> speeds. This is done like this on our IBM demo board with the PPC440
> and they use 2K2, which will not guarantee correct setup of IDSEL to
> the PCI clock, causing device detection failures.

Connection is done by a 68 ohm resistor, I hope is a good value...


> If you are sure that all the above is correct then modify the pci
> scan code so that it loops indefinately scanning for all 32 possible
> devices. Then get a hardware guy to scope the bus. It is very simple
> to look at the timing of the IDSEL lines by triggering off frameN
> being asserted.

As soon as possible I will do this test, is a foundamental step to know
if the devise is correctly selected.


Best regards,
      Stefano Gaiotto












"Steve Boorman" <steveb@baydel.com> on 20/08/2004 15:55:17

Please respond to Steve Boorman <steveb@baydel.com>

To:    "Stefano Gaiotto" <Stefano.Gaiotto@marconi.com>
cc:    linuxppc-embedded@lists.linuxppc.org

Subject:    Re: PCI scanning and devices initialization


Stefano,

> I examinated board schematics and I found that pin "IDSEL" of the bridge
> PCI/PCMCIA (PCI1410) in wired (at least in the schematics...) to line
AD12
> of data/address bus. (What's device address? 12? or 2? or 16?)

You need to look up how the configuration mechanism works for your
processor type.

When configuration type 1 cycles are performed, the device is
targeted by a configuration address written to a hardware register
(configuration_address register) in the HOST PCI bridge (contained
within your CPU) then a read or write is performed via the
configuration_data register. The configuration address is defined as
follows:-
bits 31-24 are reserved
bits 23-16 are the bus no
bits 15-11 are the device Number (using a single idsel line)
bits 10-8 are the function (for a multifunction device)
bits 7-2 is addr of the config register to read/write
bits 1 is a zero
bits 0 is a one.

The processor defines how it maps the possible 32 device numbers
(bits 15-11) as AD lines driven during a config cycle. As an example,
I use a PPC440GP and this maps device 0 by driving AD17, device 1 as
AD18 etc. So in your instance if I had connected AD12 up as an IDSEL
line I would not be able to see any devices.

If you are sure that your CPU will drive AD12 correctly then check
how the IDSEL line is coupled to the AD line. The usual method is
simply to connect a resistor from the AD line to the IDSEL line on
each PCI device (or socket) this reduces the loading on the AD line
but does restrict the IDSEL timing for fast (66 MHz and beyond) bus
speeds. This is done like this on our IBM demo board with the PPC440
and they use 2K2, which will not guarantee correct setup of IDSEL to
the PCI clock, causing device detection failures.

>
> With the help of the hardware boys I want now to chek signal
>integrity
>

If you are sure that all the above is correct then modify the pci
scan code so that it loops indefinately scanning for all 32 possible
devices. Then get a hardware guy to scope the bus. It is very simple
to look at the timing of the IDSEL lines by triggering off frameN
being asserted.

Sorry for rambling on as this is not very embedded PPC linux
specific.

Hope this helps

Regards,

Steve Boorman
-------------
steveb@baydel.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/