* 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).