From: Steve Rossi <hidden> Date: 2000-03-20 15:57:08
I'm using the Monta Vista CDK - linux-2.2.13 kernel + tools on custom
hardware with Tundra's QSPAN II PCI bridge. I've noticed
that there are two occurances of qspan_pci.c and pci.c - one in
arch/ppc/kernel
and another in /arch/ppc/mbxboot. The functions in the two pci.c files
are
different, but the qspan_pci.c functions are essentially the same - with
the
exception of CONFIG_RPXCLASSIC support in the version in /arch/ppc/
kernel (seemingly indicating that its an updated version) and the lack
of
qspan_init in that same version. When I include the QSPAN PCI support
in the kernel configuration - it appears that during the PCI bus scan at
boot time the version of qspan_pcibios_read_config_byte() in
arch/ppc/kernel/qspan_pci.c is called.
So here are my questions:
1. Why doesn't qspan_init ever get called before the PCI bus is scanned?
Where should it get called from? Should any of the functions in
arch/ppc/
mbxboot/qspan_pci.c get used or is it superceded by
arch/ppc/kernel/qspan_pci.c?
2. Should the pci_scanner function in arch/ppc/mbxboot/pci.c be called
in
place of the normal pci_scan_bus() function in drivers/pci/pci.c? If not
where would the pci_scanner() and other functions in
arch/ppc/mbxboot/pci.c be used?
3. Does Linux have a table of valid memory areas for peripheral devices
-
I've seen this in other embedded OS's. The kernel is crashing on the
first
qspan_pcibios_read_config_byte() with "kernel accss of bad area" - even
though chip selects are set up correctly for the area its accessing and
I
don't get machine check interrupts when I manually access that
particular
location through a debugger. But when the kernel does that access it
never even makes it out on the bus. Do I need to set something up so
the kernel knows that's a valid area? If so where do I do that? Is this
something that is supposed to happen automatically?
Thanks in advance for all of your help!
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/
From: Dan Malek <hidden> Date: 2000-03-20 17:31:21
Steve Rossi wrote:
........ I've noticed
that there are two occurances of qspan_pci.c and pci.c - one in
arch/ppc/kernel
and another in /arch/ppc/mbxboot.
The PCI functions in arch/ppc/mbxboot are used by boards that don't
have a 'bios' function for the initialization and mapping of the
PCI bus (which are nearly all PowerPC boards I have ever seen, and
those that attempt it don't do it correctly). The qspan_init function
is just the basic, minimal initialization of the QSpan to get slave
mode PCI access. These functions may not be complete for your
environment. You are likely to add more functions for the mapping.
The PCI functions in arch/ppc/kernel are Linux generic functions for
supporting PCI devices.
......the
exception of CONFIG_RPXCLASSIC support in the version in /arch/ppc/
kernel (seemingly indicating that its an updated version) and the lack
of
qspan_init in that same version.
The Embedded Planet RPX Classic just went through a major design
change, and I am updating the functions to support that now.
The qspan_init function isn't needed in the Linux kernel because that
should have been done long before the kernel was started.
...... When I include the QSPAN PCI support
in the kernel configuration - it appears that during the PCI bus scan at
boot time the version of qspan_pcibios_read_config_byte() in
arch/ppc/kernel/qspan_pci.c is called.
That is correct.
So here are my questions:
1. Why doesn't qspan_init ever get called before the PCI bus is scanned?
That is the job of something during the boot process before the Linux
kernel is started.
2. Should the pci_scanner function in arch/ppc/mbxboot/pci.c be called
in
place of the normal pci_scan_bus() function in drivers/pci/pci.c?
No, those functions are very different. The functions in 'mbxboot'
are used to initialize and map the PCI bus. The functions in the
Linux kernel are discovery functions.
3. Does Linux have a table of valid memory areas for peripheral devices
-
I've seen this in other embedded OS's.
Take a look at one of the board configuration files in include/asm-ppc,
like 'mbx.h' or 'rpxclassic.h'. Then look at arch/ppc/mm/init.c.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Steve Rossi <hidden> Date: 2000-03-20 19:44:35
Dan Malek wrote:
quoted
So here are my questions:
1. Why doesn't qspan_init ever get called before the PCI bus is scanned?
That is the job of something during the boot process before the Linux
kernel is started.
quoted
2. Should the pci_scanner function in arch/ppc/mbxboot/pci.c be called
in
place of the normal pci_scan_bus() function in drivers/pci/pci.c?
No, those functions are very different. The functions in 'mbxboot'
are used to initialize and map the PCI bus. The functions in the
Linux kernel are discovery functions.
Ok, now this is making a whole lot more sense to me, so where would
be an appropriate place to call qspan_init and pci_scanner from? I
understand it should happen before the kernel loads, is it something
that would make sense to put in embed_config.c? Is there a more
appropriate place to put it? I can't find where (or if) it happens for
the mbx board.
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/
From: Dan Malek <hidden> Date: 2000-03-20 20:03:54
Steve Rossi wrote:
Ok, now this is making a whole lot more sense to me, so where would
be an appropriate place to call qspan_init and pci_scanner from?
I do it after the serial initialization so you can print the messages.
I am changing some of this code right now so it will either call an
initialization function prior to decompress_kernel or as part of
decompress_kernel. I don't know why I put so much stuff in the
assember code.....It is changing now.
......I can't find where (or if) it happens for
the mbx board.
You don't have to do the qspan_init for the MBX board. PPC-Bug already
does this. It also attempts some mapping, but it doesn't get it right.
I just realized there is a big piece of code missing that will prevent
this from working properly. Configuration register access to devices
that don't exist will result in a machine check exception. There isn't
anything in this boot code at the moment that will trap this exception
and properly return to the qspan_pci functions........I guess I dropped
the PCI functions here so I wouldn't lose them, and didn't finish the
development. Another thing for the list.....
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Jason Wohlgemuth <hidden> Date: 2000-03-21 02:07:52
Dan and Steve,
The way we got the qspan up and running was to check a GPIO pin to see
whether or not the Qspan was present, inside pci_init or pcibios_init (I did
this a while ago), and if it was present we intialized the qspan and scanned
the bus then, this prevented the majority of the problems of running the
pci_scanner code from the bootrom since the linux exception vectors are
there. I am glad to hear that people are using the Qspan II, since we
intend to shift to that chip soon, so any issues that you all run into I
would love to hear about or assist you.
Jason
-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Dan
Malek
Sent: Monday, March 20, 2000 3:04 PM
To: Steve Rossi
Cc: Dan Malek; Embedded Linux PPC List
Subject: Re: Question on QSPAN Driver
Steve Rossi wrote:
Ok, now this is making a whole lot more sense to me, so where would
be an appropriate place to call qspan_init and pci_scanner from?
I do it after the serial initialization so you can print the messages.
I am changing some of this code right now so it will either call an
initialization function prior to decompress_kernel or as part of
decompress_kernel. I don't know why I put so much stuff in the
assember code.....It is changing now.
......I can't find where (or if) it happens for
the mbx board.
You don't have to do the qspan_init for the MBX board. PPC-Bug already
does this. It also attempts some mapping, but it doesn't get it right.
I just realized there is a big piece of code missing that will prevent
this from working properly. Configuration register access to devices
that don't exist will result in a machine check exception. There isn't
anything in this boot code at the moment that will trap this exception
and properly return to the qspan_pci functions........I guess I dropped
the PCI functions here so I wouldn't lose them, and didn't finish the
development. Another thing for the list.....
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-03-21 03:07:45
Jason Wohlgemuth wrote:
The way we got the qspan up and running was to check a GPIO pin to see
whether or not the Qspan was present, inside pci_init or pcibios_init (I did
this a while ago), and if it was present we intialized the qspan and scanned
the bus then,
We could (should) probably investigate some other options. The 8240
Sandpoint had the same challenge, and I followed Cort's example from
the Gemini.....Just do everything in the xxx_pci.c functions.
It used to be the Linux kernel relied heavily on the PCI already
initialized (which is normally OK in a desktop world). With the number
of "patches" due to desktops not even doing this correctly, I wonder
if we shouldn't find some place to perform this initialization. The
current "fixup" functions are too late for embedded systems that don't
do anything prior to kernel boot.
I'll experiment with the new Embedded Planet Classic and QSpan II. If
someone with real PCI knowledge has some suggestions, that would
really help.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hi,
I have a question as the subject asks:
Notes that I disable "pci support" and "Qscan pci" in both cases which I
describe below.
If I compile the kernel without "Enable loadable module support" , then it
works successfully. But if I do again with "Enable loadable module support", then
some errors occur:
Does someone know why?
##################################################
powerpc-linux-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic
arch/ppc/kernel/head.o init/main.o init/version.o \
--start-group \
arch/ppc/kernel/kernel.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/char/char.a drivers/misc/misc.a drivers/net/net.a
drivers/macintosh/macintosh.a arch/ppc/8xx_io/8xx_io.a drivers/net/net.a \
/usr/src/linux/lib/lib.a \
--end-group \
-o vmlinux
drivers/macintosh/macintosh.a(adb.o): In function `adbdev_init':
adb.o(.text+0xfa8): multiple definition of `adbdev_init'
arch/ppc/kernel/kernel.o(.text.init+0x31c): first defined here
powerpc-linux-ld: Warning: size of symbol `adbdev_init' changed from 4 to 116 in
adb.o
arch/ppc/kernel/kernel.o(__ksymtab+0x90): undefined reference to `isa_io_base'
arch/ppc/kernel/kernel.o(__ksymtab+0x98): undefined reference to `isa_mem_base'
arch/ppc/kernel/kernel.o(__ksymtab+0xa0): undefined reference to `pci_dram_offset'
arch/ppc/kernel/kernel.o(__ksymtab+0xc0): undefined reference to `_prep_type'
arch/ppc/kernel/kernel.o(__ksymtab+0xc8): undefined reference to `ucSystemType'
arch/ppc/kernel/kernel.o(__ksymtab+0x308): undefined reference to `find_devices'
arch/ppc/kernel/kernel.o(__ksymtab+0x310): undefined reference to
`find_type_devices'
arch/ppc/kernel/kernel.o(__ksymtab+0x318): undefined reference to
`find_compatible_devices'
arch/ppc/kernel/kernel.o(__ksymtab+0x320): undefined reference to
`find_path_device'
arch/ppc/kernel/kernel.o(__ksymtab+0x328): undefined reference to `find_phandle'
arch/ppc/kernel/kernel.o(__ksymtab+0x330): undefined reference to `get_property'
arch/ppc/kernel/kernel.o(__ksymtab+0x338): undefined reference to `pci_io_base'
arch/ppc/kernel/kernel.o(__ksymtab+0x340): undefined reference to `pci_device_loc'
arch/ppc/kernel/kernel.o(__ksymtab+0x348): undefined reference to `feature_set'
arch/ppc/kernel/kernel.o(__ksymtab+0x350): undefined reference to `feature_clear'
arch/ppc/kernel/kernel.o(__ksymtab+0x358): undefined reference to `feature_test'
arch/ppc/kernel/kernel.o(__ksymtab+0x370): undefined reference to
`device_is_compatible'
make: *** [vmlinux] Error 1
#############################
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Joe Green <hidden> Date: 2000-03-22 01:54:30
On Tue, 21 Mar 2000, dony wrote:
If I compile the kernel without "Enable loadable module support" , then it
works successfully. But if I do again with "Enable loadable module support", then
some errors occur:
Does someone know why?
Here's a patch I believe should fix these problems. Let me know if you
have any problems with it. This is based on the Hard Hat Linux kernel
we ship, so there may be some differences from the tree you have (hope
not).
--- linux.old/arch/ppc/kernel/ppc8xx_pic.c Tue Mar 21 02:03:06 2000+++ linux/arch/ppc/kernel/ppc8xx_pic.c Tue Mar 21 17:42:58 2000
Thank you Joe, your patch works great :-)
Joe Green wrote:
quoted hunk
On Tue, 21 Mar 2000, dony wrote:
quoted
If I compile the kernel without "Enable loadable module support" , then it
works successfully. But if I do again with "Enable loadable module support", then
some errors occur:
Does someone know why?
Here's a patch I believe should fix these problems. Let me know if you
have any problems with it. This is based on the Hard Hat Linux kernel
we ship, so there may be some differences from the tree you have (hope
not).
--- linux.old/arch/ppc/kernel/ppc8xx_pic.c Tue Mar 21 02:03:06 2000+++ linux/arch/ppc/kernel/ppc8xx_pic.c Tue Mar 21 17:42:58 2000