QSPAN PCI wierdness

QSPAN PCI wierdness

[Steve Rossi]

Hi All,

I'm working on gettting QSPAN PCI to work using the monta vista 2.2.13
kernel. (I finally have hardware to work with.) In head.S, after
serial_init
I've added a call to qspan_init() and to
pci_scanner(). I'm printing out the Device ID/Vendor ID fields as they
are read. The problem is that they are all 0. In fact, the config
transactions
are not taking place on the PCI bus. I've verified that PCI_CSR_ADDR is
correct and my chip selects are set up correctly. I've got an analyzer
on
the PCI bus, and when I manually (i.e. using my debugger) create a
configuration cycle by writing the QSPAN's config address register
and reading the config data register I get valid data back for the
devices
that are on the PCI bus, and I see the transaction occur with the PCI
analyzer. But when pci_scanner runs, I don't even see the configuration
transactions on the PCI bus. I've stepped through the code and verified
that the config address register write instruction and config data
register
read instructions occur correctly to the right addresses and all that,
but
the data that is returned is always zero. I've also verified that the
data cache
isn't turned on. I'm waiting for access to a logic analyzer so I can see
what
is happening on the PPC bus. But in the mean time, anyone have any ideas

as to why I always get 0.

Thanks,
Steve


--
-------------------------------------------------------
Steven K. Rossi                     srossi@ccrl.mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------


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

Re: QSPAN PCI wierdness

[Gabriel Paubert]

On Thu, 20 Apr 2000, Steve Rossi wrote:

>
> Hi All,
>
> I'm working on gettting QSPAN PCI to work using the monta vista 2.2.13
> kernel. (I finally have hardware to work with.) In head.S, after
> serial_init
> I've added a call to qspan_init() and to
> pci_scanner(). I'm printing out the Device ID/Vendor ID fields as they
> are read. The problem is that they are all 0. In fact, the config
> transactions
> are not taking place on the PCI bus. I've verified that PCI_CSR_ADDR is
> correct and my chip selects are set up correctly. I've got an analyzer
> on
> the PCI bus, and when I manually (i.e. using my debugger) create a
> configuration cycle by writing the QSPAN's config address register
> and reading the config data register I get valid data back for the
> devices
> that are on the PCI bus, and I see the transaction occur with the PCI
> analyzer. But when pci_scanner runs, I don't even see the configuration
> transactions on the PCI bus. I've stepped through the code and verified
> that the config address register write instruction and config data
> register
> read instructions occur correctly to the right addresses and all that,
> but
> the data that is returned is always zero. I've also verified that the
> data cache
> isn't turned on. I'm waiting for access to a logic analyzer so I can see
> what
> is happening on the PPC bus. But in the mean time, anyone have any ideas

- is the MMU on or off (we know the dache is off) ?

- are accesses separated with at least an eieio instruction ?

 Try with a sync just in case: I had problems while debugging on a 603e
recently with dcache off and mmu off (tracking a problem in code which was
designed to run with both cache and MMU on), an eieio was not enough but a
sync worked just fine.

	Gabriel.


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

Re: QSPAN PCI wierdness

[Steve Rossi]

This is way before the kernel has even booted so MMU is still
off. There was an eieio after the config data register read.
I tried adding a sync between the config address register write
and the config data register read - but it didn't help. I also
tried replacing the eieio after the data reg read with sync - still
no go.

As a little test I added some code to the end of qspan_init that looks
like so:

        qptr[320] = 0x00000000; /* device 0 */
        puts("At PCI Device ID 0: ");
        puthex(qptr[321]);
        puts("\n");

This prints out the expected Vendor ID and Device ID.

Its when pci_scanner() calls qs_pci_read_config_dword()
that it reads 0. Can someone verified that pci_scanner() and
the qs_pci_* functions in mbxboot/pci.c and
mbxboot/qspan_pci.c work?

Thanks,
Steve


Gabriel Paubert wrote:

>
> - is the MMU on or off (we know the dache is off) ?
>
> - are accesses separated with at least an eieio instruction ?
>
>  Try with a sync just in case: I had problems while debugging on a 603e
> recently with dcache off and mmu off (tracking a problem in code which was
> designed to run with both cache and MMU on), an eieio was not enough but a
> sync worked just fine.
>
>         Gabriel.

--
-------------------------------------------------------
Steven K. Rossi                     srossi@ccrl.mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------


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

Re: QSPAN PCI wierdness

[Dan Malek]

Steve Rossi wrote:

> Its when pci_scanner() calls qs_pci_read_config_dword()
> that it reads 0. Can someone verified that pci_scanner() and
> the qs_pci_* functions in mbxboot/pci.c and
> mbxboot/qspan_pci.c work?

I know I have posted this before.......

The PCI functions in this directory are just for reference.  I checked
them in because I didn't want to lose them.  They are not complete
for one simple reason: the QSPAN generates bus time outs when you
access the config registers for devices that don't exist.  We need to
place some kind of a bus fault exception hander in the code that
exists here for proper operation.

These are examples of functions I normally put into custom 8xx boot
roms.  Someone once asked for them, I checked them into here as it
was the easiest at the time.

These functions work.  If the QSPAN is properly mapped at the time
these functions are called, currently one of three things will happen:

	1.  If no bus timeout and no PCI device, the bus will hang.
	2.  If bus timeout and no PCI device, machine check exception
	3.  If PCI device, proper config cycle will occur.

I believe they should also work for a QSPAN-II, although the
initialization function should have more "stuff" in it.


	-- Dan

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

RE: QSPAN PCI wierdness

[Jason Wohlgemuth]

Steve,

I got the Qspan going from the mpc8xx-2.2.13 distribution.  If you are
compiling the kernel with gcc 2.95.2 there is an issue with the inline
assembly assuming an important register is not used and the value is thrown
away, ... it was posted in a previous message by me, I just dug it up, here
it is.  If you are not using gcc2.95.2, then let us know and we can all
ponder this some more.

Anyone trying to build in pci support to the kernel using GCC 2.95.2 may
find this patch helpful.

It seems that in the inline-assembly in qspan_pci.c the compiler doesn't
recognize that the first argument to the assembly may be modified.  This
resulted in a register getting trashed where it shouldn't have.  To fix the
problem I modified the in-line assembly to tell the compiler that this
register has been changed.

86c86
<               : "=r"(x) : "r"(addr) : "%0")
---
>               : "=r"(x) : "r"(addr))

Jason <jwohlgem@mindspring.com>


-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Steve
Rossi
Sent: Thursday, April 20, 2000 7:42 PM
To: Gabriel Paubert
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: QSPAN PCI wierdness



This is way before the kernel has even booted so MMU is still
off. There was an eieio after the config data register read.
I tried adding a sync between the config address register write
and the config data register read - but it didn't help. I also
tried replacing the eieio after the data reg read with sync - still
no go.

As a little test I added some code to the end of qspan_init that looks
like so:

        qptr[320] = 0x00000000; /* device 0 */
        puts("At PCI Device ID 0: ");
        puthex(qptr[321]);
        puts("\n");

This prints out the expected Vendor ID and Device ID.

Its when pci_scanner() calls qs_pci_read_config_dword()
that it reads 0. Can someone verified that pci_scanner() and
the qs_pci_* functions in mbxboot/pci.c and
mbxboot/qspan_pci.c work?

Thanks,
Steve


Gabriel Paubert wrote:

>
> - is the MMU on or off (we know the dache is off) ?
>
> - are accesses separated with at least an eieio instruction ?
>
>  Try with a sync just in case: I had problems while debugging on a 603e
> recently with dcache off and mmu off (tracking a problem in code which was
> designed to run with both cache and MMU on), an eieio was not enough but a
> sync worked just fine.
>
>         Gabriel.

--
-------------------------------------------------------
Steven K. Rossi                     srossi@ccrl.mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------


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

Re: QSPAN PCI wierdness

[Steve Rossi]

That would be it. Thank you. I gues I've failed the #1 rule - always
check the archives first. In fact come to think of it, I saw your
posting the first time and I think I saved it away in a safe place so that
I could come back to it later. Duh!

Steve

Jason Wohlgemuth wrote:

>
> It seems that in the inline-assembly in qspan_pci.c the compiler doesn't
> recognize that the first argument to the assembly may be modified.  This
> resulted in a register getting trashed where it shouldn't have.  To fix the
> problem I modified the in-line assembly to tell the compiler that this
> register has been changed.
>
> 86c86
> <               : "=r"(x) : "r"(addr) : "%0")
> ---
> >               : "=r"(x) : "r"(addr))
>
> Jason <jwohlgem@mindspring.com>

--
-------------------------------------------------------
Steven K. Rossi                     srossi@ccrl.mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------


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