Re: PCI scanning and devices initialization

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 [off-list ref] on 18/08/2004 14:54:43

To:    Stefano Gaiotto <redacted>,
       "linuxppc-embedded@lists.linuxppc.org"
       [off-list ref]
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/

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/