* Question on QSPAN Driver
@ 2000-03-20 15:57 Steve Rossi
2000-03-20 17:31 ` Dan Malek
0 siblings, 1 reply; 9+ messages in thread
From: Steve Rossi @ 2000-03-20 15:57 UTC (permalink / raw)
To: Embedded Linux PPC List
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question on QSPAN Driver
2000-03-20 15:57 Question on QSPAN Driver Steve Rossi
@ 2000-03-20 17:31 ` Dan Malek
2000-03-20 19:44 ` Steve Rossi
0 siblings, 1 reply; 9+ messages in thread
From: Dan Malek @ 2000-03-20 17:31 UTC (permalink / raw)
To: Steve Rossi; +Cc: Embedded Linux PPC List
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question on QSPAN Driver
2000-03-20 17:31 ` Dan Malek
@ 2000-03-20 19:44 ` Steve Rossi
2000-03-20 20:03 ` Dan Malek
0 siblings, 1 reply; 9+ messages in thread
From: Steve Rossi @ 2000-03-20 19:44 UTC (permalink / raw)
To: Dan Malek; +Cc: Embedded Linux PPC List
Dan Malek wrote:
>
> > 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.
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question on QSPAN Driver
2000-03-20 19:44 ` Steve Rossi
@ 2000-03-20 20:03 ` Dan Malek
2000-03-21 2:07 ` Jason Wohlgemuth
0 siblings, 1 reply; 9+ messages in thread
From: Dan Malek @ 2000-03-20 20:03 UTC (permalink / raw)
To: Steve Rossi; +Cc: Dan Malek, Embedded Linux PPC List
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Question on QSPAN Driver
2000-03-20 20:03 ` Dan Malek
@ 2000-03-21 2:07 ` Jason Wohlgemuth
2000-03-21 3:07 ` Dan Malek
0 siblings, 1 reply; 9+ messages in thread
From: Jason Wohlgemuth @ 2000-03-21 2:07 UTC (permalink / raw)
To: Dan Malek, Steve Rossi; +Cc: Embedded Linux PPC List
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Question on QSPAN Driver
2000-03-21 2:07 ` Jason Wohlgemuth
@ 2000-03-21 3:07 ` Dan Malek
2000-03-22 1:35 ` Does mpc8xx-2.2.13 support "Enable loadable module support"? dony
0 siblings, 1 reply; 9+ messages in thread
From: Dan Malek @ 2000-03-21 3:07 UTC (permalink / raw)
To: Jason Wohlgemuth; +Cc: Steve Rossi, Embedded Linux PPC List
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Does mpc8xx-2.2.13 support "Enable loadable module support"?
2000-03-21 3:07 ` Dan Malek
@ 2000-03-22 1:35 ` dony
2000-03-22 1:54 ` Joe Green
0 siblings, 1 reply; 9+ messages in thread
From: dony @ 2000-03-22 1:35 UTC (permalink / raw)
To: Dan Malek, linuxppc-embed
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Does mpc8xx-2.2.13 support "Enable loadable module support"?
2000-03-22 1:35 ` Does mpc8xx-2.2.13 support "Enable loadable module support"? dony
@ 2000-03-22 1:54 ` Joe Green
2000-03-22 3:10 ` dony
0 siblings, 1 reply; 9+ messages in thread
From: Joe Green @ 2000-03-22 1:54 UTC (permalink / raw)
To: dony, Dan Malek, linuxppc-embed
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
@@ -148,4 +148,15 @@
irq += i8259_pic.irq_offset;
return (request_8xxirq(irq, handler, irqflags, devname, dev_id));
}
-#endif
+#else /* CONFIG_MBX */
+int request_irq(
+ unsigned int irq,
+ void (*handler)(int, void *, struct pt_regs *),
+ unsigned long irqflags,
+ const char * devname,
+ void *dev_id
+)
+{
+ return -EINVAL;
+}
+#endif /* CONFIG_MBX */
--- linux.old/arch/ppc/kernel/ppc_ksyms.c Wed Oct 20 00:14:00 1999
+++ linux/arch/ppc/kernel/ppc_ksyms.c Tue Mar 21 18:31:02 2000
@@ -69,14 +69,18 @@
EXPORT_SYMBOL(ppc_local_irq_count);
EXPORT_SYMBOL(ppc_local_bh_count);
+#ifdef CONFIG_PCI
EXPORT_SYMBOL(isa_io_base);
EXPORT_SYMBOL(isa_mem_base);
EXPORT_SYMBOL(pci_dram_offset);
+#endif /* CONFIG_PCI */
EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
+#ifndef CONFIG_8xx
EXPORT_SYMBOL(_prep_type);
EXPORT_SYMBOL(ucSystemType);
+#endif /* CONFIG_8xx */
EXPORT_SYMBOL(atomic_add);
EXPORT_SYMBOL(atomic_sub);
@@ -181,18 +185,21 @@
EXPORT_SYMBOL(_machine);
EXPORT_SYMBOL(ppc_md);
+#ifndef CONFIG_8xx
EXPORT_SYMBOL(adb_request);
EXPORT_SYMBOL(adb_register);
EXPORT_SYMBOL(cuda_request);
EXPORT_SYMBOL(cuda_poll);
EXPORT_SYMBOL(pmu_request);
EXPORT_SYMBOL(pmu_poll);
+#endif /* CONFIG_8xx */
#ifdef CONFIG_PMAC_PBOOK
EXPORT_SYMBOL(pmu_register_sleep_notifier);
EXPORT_SYMBOL(pmu_unregister_sleep_notifier);
EXPORT_SYMBOL(pmu_enable_irled);
#endif CONFIG_PMAC_PBOOK
EXPORT_SYMBOL(abort);
+#ifndef CONFIG_8xx
EXPORT_SYMBOL(find_devices);
EXPORT_SYMBOL(find_type_devices);
EXPORT_SYMBOL(find_compatible_devices);
@@ -204,6 +211,7 @@
EXPORT_SYMBOL(feature_set);
EXPORT_SYMBOL(feature_clear);
EXPORT_SYMBOL(feature_test);
+#endif /* CONFIG_8xx */
#ifdef CONFIG_SCSI
EXPORT_SYMBOL(note_scsi_host);
#endif
@@ -214,7 +222,9 @@
#endif /* CONFIG_PMAC */
EXPORT_SYMBOL(abs);
+#ifndef CONFIG_8xx
EXPORT_SYMBOL(device_is_compatible);
+#endif /* CONFIG_8xx */
EXPORT_SYMBOL_NOVERS(__ashrdi3);
EXPORT_SYMBOL_NOVERS(__lshrdi3);
--- linux.old/drivers/macintosh/Makefile Thu Apr 29 19:53:48 1999
+++ linux/drivers/macintosh/Makefile Tue Mar 21 18:21:04 2000
@@ -15,7 +15,7 @@
L_TARGET := macintosh.a
M_OBJS :=
-ifndef CONFIG_MBX
+ifndef CONFIG_8xx
L_OBJS := via-cuda.o macio-adb.o via-pmu.o mediabay.o
LX_OBJS := adb.o
endif
--
Joe Green <jgreen@mvista.com>
MontaVista Software, Inc.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Does mpc8xx-2.2.13 support "Enable loadable module support"?
2000-03-22 1:54 ` Joe Green
@ 2000-03-22 3:10 ` dony
0 siblings, 0 replies; 9+ messages in thread
From: dony @ 2000-03-22 3:10 UTC (permalink / raw)
To: Joe Green; +Cc: Dan Malek, linuxppc-embed
Thank you Joe, your patch works great :-)
Joe Green wrote:
> 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
> @@ -148,4 +148,15 @@
> irq += i8259_pic.irq_offset;
> return (request_8xxirq(irq, handler, irqflags, devname, dev_id));
> }
> -#endif
> +#else /* CONFIG_MBX */
> +int request_irq(
> + unsigned int irq,
> + void (*handler)(int, void *, struct pt_regs *),
> + unsigned long irqflags,
> + const char * devname,
> + void *dev_id
> +)
> +{
> + return -EINVAL;
> +}
> +#endif /* CONFIG_MBX */
> --- linux.old/arch/ppc/kernel/ppc_ksyms.c Wed Oct 20 00:14:00 1999
> +++ linux/arch/ppc/kernel/ppc_ksyms.c Tue Mar 21 18:31:02 2000
> @@ -69,14 +69,18 @@
> EXPORT_SYMBOL(ppc_local_irq_count);
> EXPORT_SYMBOL(ppc_local_bh_count);
>
> +#ifdef CONFIG_PCI
> EXPORT_SYMBOL(isa_io_base);
> EXPORT_SYMBOL(isa_mem_base);
> EXPORT_SYMBOL(pci_dram_offset);
> +#endif /* CONFIG_PCI */
> EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
> EXPORT_SYMBOL(DMA_MODE_READ);
> EXPORT_SYMBOL(DMA_MODE_WRITE);
> +#ifndef CONFIG_8xx
> EXPORT_SYMBOL(_prep_type);
> EXPORT_SYMBOL(ucSystemType);
> +#endif /* CONFIG_8xx */
>
> EXPORT_SYMBOL(atomic_add);
> EXPORT_SYMBOL(atomic_sub);
> @@ -181,18 +185,21 @@
> EXPORT_SYMBOL(_machine);
> EXPORT_SYMBOL(ppc_md);
>
> +#ifndef CONFIG_8xx
> EXPORT_SYMBOL(adb_request);
> EXPORT_SYMBOL(adb_register);
> EXPORT_SYMBOL(cuda_request);
> EXPORT_SYMBOL(cuda_poll);
> EXPORT_SYMBOL(pmu_request);
> EXPORT_SYMBOL(pmu_poll);
> +#endif /* CONFIG_8xx */
> #ifdef CONFIG_PMAC_PBOOK
> EXPORT_SYMBOL(pmu_register_sleep_notifier);
> EXPORT_SYMBOL(pmu_unregister_sleep_notifier);
> EXPORT_SYMBOL(pmu_enable_irled);
> #endif CONFIG_PMAC_PBOOK
> EXPORT_SYMBOL(abort);
> +#ifndef CONFIG_8xx
> EXPORT_SYMBOL(find_devices);
> EXPORT_SYMBOL(find_type_devices);
> EXPORT_SYMBOL(find_compatible_devices);
> @@ -204,6 +211,7 @@
> EXPORT_SYMBOL(feature_set);
> EXPORT_SYMBOL(feature_clear);
> EXPORT_SYMBOL(feature_test);
> +#endif /* CONFIG_8xx */
> #ifdef CONFIG_SCSI
> EXPORT_SYMBOL(note_scsi_host);
> #endif
> @@ -214,7 +222,9 @@
> #endif /* CONFIG_PMAC */
>
> EXPORT_SYMBOL(abs);
> +#ifndef CONFIG_8xx
> EXPORT_SYMBOL(device_is_compatible);
> +#endif /* CONFIG_8xx */
>
> EXPORT_SYMBOL_NOVERS(__ashrdi3);
> EXPORT_SYMBOL_NOVERS(__lshrdi3);
> --- linux.old/drivers/macintosh/Makefile Thu Apr 29 19:53:48 1999
> +++ linux/drivers/macintosh/Makefile Tue Mar 21 18:21:04 2000
> @@ -15,7 +15,7 @@
> L_TARGET := macintosh.a
> M_OBJS :=
>
> -ifndef CONFIG_MBX
> +ifndef CONFIG_8xx
> L_OBJS := via-cuda.o macio-adb.o via-pmu.o mediabay.o
> LX_OBJS := adb.o
> endif
>
> --
> Joe Green <jgreen@mvista.com>
> MontaVista Software, Inc.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-03-22 3:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-03-20 15:57 Question on QSPAN Driver Steve Rossi
2000-03-20 17:31 ` Dan Malek
2000-03-20 19:44 ` Steve Rossi
2000-03-20 20:03 ` Dan Malek
2000-03-21 2:07 ` Jason Wohlgemuth
2000-03-21 3:07 ` Dan Malek
2000-03-22 1:35 ` Does mpc8xx-2.2.13 support "Enable loadable module support"? dony
2000-03-22 1:54 ` Joe Green
2000-03-22 3:10 ` dony
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).