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 at mindspring.com> -----Original Message----- From: [EMAIL PROTECTED] [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Steve Rossi Sent: Thursday, April 20, 2000 7:42 PM To: Gabriel Paubert Cc: linuxppc-embedded at 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 at ccrl.mot.com Staff Engineer Multimedia Communications Research Laboratory Motorola Labs ------------------------------------------------------- ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
