* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Geoff Levand @ 2006-05-02 18:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <200605020150.14152.arnd@arndb.de>
Arnd Bergmann wrote:
>> I also got rid of SPUFS_PRIV1_MMIO, since SPUFS_PRIV1_MMIO
>> just meant spufs with !SOME_HYPERVISOR_THING.
>>
>
> I guess that one should really be (SPU_FS && CELL_NATIVE),
> using the option Segher suggested now.
OK. I set it up that way. Updated patch below.
>> config PPC_SYSTEMSIM
>> bool " IBM Full System Simulator (systemsim) support"
>> - depends on PPC_CELL || PPC_PSERIES || PPC_MAPLE
>> + depends on PPC_IBM_CELL_BLADE || PPC_PSERIES || PPC_MAPLE
>> help
>> Support booting resulting image under IBMs Full System Simulator.
>> If you enable this option, you are able to select device
>
> whoops, this one should not be there at all. Note that I updated
> your previous patch as well to fit into the series for submission,
> and that did not include systemsim.
Sorry, didn't notice you changed it. Fixed now.
>> # needed only when building loadable spufs.ko
>> -spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
>> -obj-y += $(spufs-modular-m)
>> -
>> -# always needed in kernel
>> -spufs-builtin-$(CONFIG_SPU_FS) += spu_callbacks.o spu_base.o spu_priv1.o
>> -obj-y += $(spufs-builtin-y) $(spufs-builtin-m)
>> -
>> -obj-$(CONFIG_SPU_FS) += spufs/
>> +spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
>> +obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
>> + $(spufs-modular-m)
>> +ifdef CONFIG_SPU_FS
>> +obj-$(CONFIG_PPC_CELL) += spu_priv1_mmio.o
>> +endif
>
> I guess this could then become something like
>
> spu-priv1-$(CONFIG_PPC_CELL_NATIVE) += spu_priv1_mmio.o
> spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
> obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
> $(spufs-modular-m) \
> $(spu-priv1-y)
Yes, a nice way.
>> --- cell--alp--2.orig/drivers/net/Kconfig 2006-05-01 15:13:22.000000000 -0700
>> +++ cell--alp--2/drivers/net/Kconfig 2006-05-01 15:13:23.000000000 -0700
>> @@ -2179,7 +2179,7 @@
>>
>> config SPIDER_NET
>> tristate "Spider Gigabit Ethernet driver"
>> - depends on PCI && PPC_CELL
>> + depends on PCI && PPC_IBM_CELL_BLADE
>> select FW_LOADER
>> help
>> This driver supports the Gigabit Ethernet chips present on the
>
> Hmm, I'm also no longer sure if this is right. In theory, spidernet
> could be used in all sorts of products, wether they are using the
> same bridge chip or just the gigabit ethernet macro from it.
>
> For now, I guess you can just leave this one alone if you respin
> the patch another time. It's disabled by default, so the dependency
> can be updated the next time we get a user in _addition_ to PPC_CELL.
OK, based on your other mail I just left it as PCI && PPC_IBM_CELL_BLADE.
We can change it when another system uses it.
-Geoff
Split the Cell BE support into generic and platform dependent parts.
Creates new config variables PPC_CELL_NATIVE and PPC_IBM_CELL_BLADE.
The existing CONFIG_PPC_CELL is now used to denote the generic
Cell processor support.
Also renames spu_priv1.c to spu_priv1_mmio.c.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Index: cell--alp--3/arch/powerpc/Kconfig
===================================================================
--- cell--alp--3.orig/arch/powerpc/Kconfig 2006-05-02 10:10:52.000000000 -0700
+++ cell--alp--3/arch/powerpc/Kconfig 2006-05-02 10:11:42.000000000 -0700
@@ -391,8 +391,18 @@
For more informations, refer to <http://www.970eval.com>
config PPC_CELL
- bool " Cell Broadband Processor Architecture"
+ bool
+ default n
+
+config PPC_CELL_NATIVE
+ bool
+ select PPC_CELL
+ default n
+
+config PPC_IBM_CELL_BLADE
+ bool " IBM Cell Blade"
depends on PPC_MULTIPLATFORM && PPC64
+ select PPC_CELL_NATIVE
select PPC_RTAS
select MMIO_NVRAM
select PPC_UDBG_16550
@@ -439,11 +449,6 @@
depends on PPC_MAPLE
default y
-config CELL_IIC
- depends on PPC_CELL
- bool
- default y
-
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
Index: cell--alp--3/arch/powerpc/configs/cell_defconfig
===================================================================
--- cell--alp--3.orig/arch/powerpc/configs/cell_defconfig 2006-05-02 10:10:52.000000000 -0700
+++ cell--alp--3/arch/powerpc/configs/cell_defconfig 2006-05-02 10:12:22.000000000 -0700
@@ -118,13 +118,14 @@
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
CONFIG_PPC_CELL=y
+CONFIG_PPC_CELL_NATIVE=y
+CONFIG_PPC_IBM_CELL_BLADE=y
# CONFIG_U3_DART is not set
CONFIG_PPC_RTAS=y
# CONFIG_RTAS_ERROR_LOGGING is not set
CONFIG_RTAS_PROC=y
CONFIG_RTAS_FLASH=y
CONFIG_MMIO_NVRAM=y
-CONFIG_CELL_IIC=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
@@ -133,6 +134,7 @@
# Cell Broadband Engine options
#
CONFIG_SPU_FS=m
+CONFIG_SPU_BASE=y
CONFIG_SPUFS_MMAP=y
#
Index: cell--alp--3/arch/powerpc/platforms/cell/Kconfig
===================================================================
--- cell--alp--3.orig/arch/powerpc/platforms/cell/Kconfig 2006-05-02 10:10:52.000000000 -0700
+++ cell--alp--3/arch/powerpc/platforms/cell/Kconfig 2006-05-02 10:14:05.000000000 -0700
@@ -5,11 +5,16 @@
tristate "SPU file system"
default m
depends on PPC_CELL
+ select SPU_BASE
help
The SPU file system is used to access Synergistic Processing
Units on machines implementing the Broadband Processor
Architecture.
+config SPU_BASE
+ bool
+ default n
+
config SPUFS_MMAP
bool
depends on SPU_FS && SPARSEMEM && !PPC_64K_PAGES
Index: cell--alp--3/arch/powerpc/platforms/cell/Makefile
===================================================================
--- cell--alp--3.orig/arch/powerpc/platforms/cell/Makefile 2006-05-02 10:10:52.000000000 -0700
+++ cell--alp--3/arch/powerpc/platforms/cell/Makefile 2006-05-02 10:39:27.000000000 -0700
@@ -1,14 +1,14 @@
-obj-y += interrupt.o iommu.o setup.o spider-pic.o
-obj-y += pervasive.o
+obj-$(CONFIG_PPC_CELL_NATIVE) += interrupt.o iommu.o setup.o \
+ spider-pic.o pervasive.o
-obj-$(CONFIG_SMP) += smp.o
+ifeq ($(CONFIG_SMP),y)
+obj-$(CONFIG_PPC_CELL_NATIVE) += smp.o
+endif
# needed only when building loadable spufs.ko
-spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
-obj-y += $(spufs-modular-m)
+spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
+spu-priv1-$(CONFIG_PPC_CELL_NATIVE) += spu_priv1_mmio.o
-# always needed in kernel
-spufs-builtin-$(CONFIG_SPU_FS) += spu_callbacks.o spu_base.o spu_priv1.o
-obj-y += $(spufs-builtin-y) $(spufs-builtin-m)
-
-obj-$(CONFIG_SPU_FS) += spufs/
+obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
+ $(spufs-modular-m) $(spu-priv1-y)
+obj-$(CONFIG_SPU_FS) += spufs/
Index: cell--alp--3/arch/powerpc/platforms/cell/spu_priv1.c
===================================================================
--- cell--alp--3.orig/arch/powerpc/platforms/cell/spu_priv1.c 2006-05-02 10:10:52.000000000 -0700
+++ cell--alp--3/arch/powerpc/platforms/cell/spu_priv1.c 2006-05-01 17:06:59.032678000 -0700
@@ -1,133 +0,0 @@
-/*
- * access to SPU privileged registers
- */
-#include <linux/module.h>
-
-#include <asm/io.h>
-#include <asm/spu.h>
-
-void spu_int_mask_and(struct spu *spu, int class, u64 mask)
-{
- u64 old_mask;
-
- old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
- out_be64(&spu->priv1->int_mask_RW[class], old_mask & mask);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_and);
-
-void spu_int_mask_or(struct spu *spu, int class, u64 mask)
-{
- u64 old_mask;
-
- old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
- out_be64(&spu->priv1->int_mask_RW[class], old_mask | mask);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_or);
-
-void spu_int_mask_set(struct spu *spu, int class, u64 mask)
-{
- out_be64(&spu->priv1->int_mask_RW[class], mask);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_set);
-
-u64 spu_int_mask_get(struct spu *spu, int class)
-{
- return in_be64(&spu->priv1->int_mask_RW[class]);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_get);
-
-void spu_int_stat_clear(struct spu *spu, int class, u64 stat)
-{
- out_be64(&spu->priv1->int_stat_RW[class], stat);
-}
-EXPORT_SYMBOL_GPL(spu_int_stat_clear);
-
-u64 spu_int_stat_get(struct spu *spu, int class)
-{
- return in_be64(&spu->priv1->int_stat_RW[class]);
-}
-EXPORT_SYMBOL_GPL(spu_int_stat_get);
-
-void spu_int_route_set(struct spu *spu, u64 route)
-{
- out_be64(&spu->priv1->int_route_RW, route);
-}
-EXPORT_SYMBOL_GPL(spu_int_route_set);
-
-u64 spu_mfc_dar_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_dar_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_dar_get);
-
-u64 spu_mfc_dsisr_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_dsisr_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_dsisr_get);
-
-void spu_mfc_dsisr_set(struct spu *spu, u64 dsisr)
-{
- out_be64(&spu->priv1->mfc_dsisr_RW, dsisr);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_dsisr_set);
-
-void spu_mfc_sdr_set(struct spu *spu, u64 sdr)
-{
- out_be64(&spu->priv1->mfc_sdr_RW, sdr);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_sdr_set);
-
-void spu_mfc_sr1_set(struct spu *spu, u64 sr1)
-{
- out_be64(&spu->priv1->mfc_sr1_RW, sr1);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_sr1_set);
-
-u64 spu_mfc_sr1_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_sr1_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_sr1_get);
-
-void spu_mfc_tclass_id_set(struct spu *spu, u64 tclass_id)
-{
- out_be64(&spu->priv1->mfc_tclass_id_RW, tclass_id);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_set);
-
-u64 spu_mfc_tclass_id_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_tclass_id_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_get);
-
-void spu_tlb_invalidate(struct spu *spu)
-{
- out_be64(&spu->priv1->tlb_invalidate_entry_W, 0ul);
-}
-EXPORT_SYMBOL_GPL(spu_tlb_invalidate);
-
-void spu_resource_allocation_groupID_set(struct spu *spu, u64 id)
-{
- out_be64(&spu->priv1->resource_allocation_groupID_RW, id);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_set);
-
-u64 spu_resource_allocation_groupID_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->resource_allocation_groupID_RW);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_get);
-
-void spu_resource_allocation_enable_set(struct spu *spu, u64 enable)
-{
- out_be64(&spu->priv1->resource_allocation_enable_RW, enable);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_set);
-
-u64 spu_resource_allocation_enable_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->resource_allocation_enable_RW);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_get);
Index: cell--alp--3/arch/powerpc/platforms/cell/spu_priv1_mmio.c
===================================================================
--- cell--alp--3.orig/arch/powerpc/platforms/cell/spu_priv1_mmio.c 2006-05-01 17:06:59.032678000 -0700
+++ cell--alp--3/arch/powerpc/platforms/cell/spu_priv1_mmio.c 2006-05-02 10:11:42.000000000 -0700
@@ -0,0 +1,133 @@
+/*
+ * access to SPU privileged registers
+ */
+#include <linux/module.h>
+
+#include <asm/io.h>
+#include <asm/spu.h>
+
+void spu_int_mask_and(struct spu *spu, int class, u64 mask)
+{
+ u64 old_mask;
+
+ old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
+ out_be64(&spu->priv1->int_mask_RW[class], old_mask & mask);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_and);
+
+void spu_int_mask_or(struct spu *spu, int class, u64 mask)
+{
+ u64 old_mask;
+
+ old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
+ out_be64(&spu->priv1->int_mask_RW[class], old_mask | mask);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_or);
+
+void spu_int_mask_set(struct spu *spu, int class, u64 mask)
+{
+ out_be64(&spu->priv1->int_mask_RW[class], mask);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_set);
+
+u64 spu_int_mask_get(struct spu *spu, int class)
+{
+ return in_be64(&spu->priv1->int_mask_RW[class]);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_get);
+
+void spu_int_stat_clear(struct spu *spu, int class, u64 stat)
+{
+ out_be64(&spu->priv1->int_stat_RW[class], stat);
+}
+EXPORT_SYMBOL_GPL(spu_int_stat_clear);
+
+u64 spu_int_stat_get(struct spu *spu, int class)
+{
+ return in_be64(&spu->priv1->int_stat_RW[class]);
+}
+EXPORT_SYMBOL_GPL(spu_int_stat_get);
+
+void spu_int_route_set(struct spu *spu, u64 route)
+{
+ out_be64(&spu->priv1->int_route_RW, route);
+}
+EXPORT_SYMBOL_GPL(spu_int_route_set);
+
+u64 spu_mfc_dar_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_dar_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_dar_get);
+
+u64 spu_mfc_dsisr_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_dsisr_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_dsisr_get);
+
+void spu_mfc_dsisr_set(struct spu *spu, u64 dsisr)
+{
+ out_be64(&spu->priv1->mfc_dsisr_RW, dsisr);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_dsisr_set);
+
+void spu_mfc_sdr_set(struct spu *spu, u64 sdr)
+{
+ out_be64(&spu->priv1->mfc_sdr_RW, sdr);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_sdr_set);
+
+void spu_mfc_sr1_set(struct spu *spu, u64 sr1)
+{
+ out_be64(&spu->priv1->mfc_sr1_RW, sr1);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_sr1_set);
+
+u64 spu_mfc_sr1_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_sr1_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_sr1_get);
+
+void spu_mfc_tclass_id_set(struct spu *spu, u64 tclass_id)
+{
+ out_be64(&spu->priv1->mfc_tclass_id_RW, tclass_id);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_set);
+
+u64 spu_mfc_tclass_id_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_tclass_id_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_get);
+
+void spu_tlb_invalidate(struct spu *spu)
+{
+ out_be64(&spu->priv1->tlb_invalidate_entry_W, 0ul);
+}
+EXPORT_SYMBOL_GPL(spu_tlb_invalidate);
+
+void spu_resource_allocation_groupID_set(struct spu *spu, u64 id)
+{
+ out_be64(&spu->priv1->resource_allocation_groupID_RW, id);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_set);
+
+u64 spu_resource_allocation_groupID_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->resource_allocation_groupID_RW);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_get);
+
+void spu_resource_allocation_enable_set(struct spu *spu, u64 enable)
+{
+ out_be64(&spu->priv1->resource_allocation_enable_RW, enable);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_set);
+
+u64 spu_resource_allocation_enable_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->resource_allocation_enable_RW);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_get);
Index: cell--alp--3/drivers/net/Kconfig
===================================================================
--- cell--alp--3.orig/drivers/net/Kconfig 2006-05-02 10:10:52.000000000 -0700
+++ cell--alp--3/drivers/net/Kconfig 2006-05-02 10:11:42.000000000 -0700
@@ -2171,7 +2171,7 @@
config SPIDER_NET
tristate "Spider Gigabit Ethernet driver"
- depends on PCI && PPC_CELL
+ depends on PCI && PPC_IBM_CELL_BLADE
select FW_LOADER
help
This driver supports the Gigabit Ethernet chips present on the
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specificfil es
From: Geoff Levand @ 2006-05-02 18:20 UTC (permalink / raw)
To: michael
Cc: Arnd Bergmann, Levand, Geoffrey, linux-kernel, linuxppc-dev,
cbe-oss-dev, Arnd Bergmann
In-Reply-To: <1146528809.27495.21.camel@localhost.localdomain>
Michael Ellerman wrote:
> On Mon, 2006-05-01 at 15:51 -0700, Geoff Levand wrote:
>> Segher, a problem with your suggestion is that our
>> makefiles don't have as rich a set of logical ops as the
>> config files. Its easy to express 'build A if B', but not
>> so easy to do 'build A if not C'. To make this work
>> cleanly I made PPC_CELL denote !SOME_HYPERVISOR_THING,
>> so I can have constructions like this in the makefile:
>>
>> obj-$(CONFIG_PPC_CELL) += ...
>
> Hi Geoff,
>
> I've been ignoring this discussion, but now that I read it I think this
> is all kinda backwards.
>
> PPC_CELL should not denote !SOME_HYPERVISOR, it should just mean "basic
> cell support", ie. PPC_CELL gets you platforms/cell built in.
Yes, that's the way I originally made it, and I switched it back
to that in the latest patch.
> Then we can have SOME_HYPERVISOR which _adds_ support for that
> hypervisor. And PPC_CELL_BLADE which selects things which are actually
> specific to that hardware, like SPIDERNET etc.
> But SOME_HYPERVISOR should not remove support for running on bare metal,
> it should just give you the option of running on the hypervisor. Yes
> that may require testing things at runtime, that's what
> firmware_has_feature() is for.
I feel you're missing one thing though, we need PPC_CELL_NATIVE. We
don't want to build that in if we don't need it. Here's what I setup:
PPC_CELL = make descends into platforms/cell
PPC_CELL_NATIVE = add bare metal support
PPC_IBM_CELL_BLADE = add blade device drivers, etc.
> The goal should be that we have one kernel which can boot on all Cell
> implementations. In fact the ultimate goal is to have one kernel that
> can boot any platform under powerpc, that's a way off still, but we
> don't want to start going backwards.
Yes, that's the whole idea of this patch. It comes from my patch set
'cell: support multi-platform image'... But we also need to be able
to build in only the support needed. This is an important requirement
for consumer products, to reduce the image size.
In a certain class of products the kernel image and read-only parts
of the file system are stored on flash. A smaller kernel means more
space for applications. Also, a smaller kernel image loads faster.
Device startup time is very important for many consumer products.
-Geoff
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-02 18:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev, linux-kernel
In-Reply-To: <4457A2D6.4070400@am.sony.com>
Am Tuesday 02 May 2006 20:20 schrieb Geoff Levand:
> Split the Cell BE support into generic and platform dependent parts.
>
> Creates new config variables PPC_CELL_NATIVE and PPC_IBM_CELL_BLADE.
> The existing CONFIG_PPC_CELL is now used to denote the generic
> Cell processor support.
>
> Also renames spu_priv1.c to spu_priv1_mmio.c.
Ok, looks good now.
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* RE: USB on MPC8349EMDS
From: Prashant Viswanathan @ 2006-05-02 18:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
> > When I insert a USB Mass storage device (thumb drive), I get the
> > following errors
> >
> > / # usb 1-2: new high speed USB device using fsl-usb2-mph and
> > address 8
> > usb 1-2: khubd timed out on ep0in
> > usb 1-2: new high speed USB device using fsl-usb2-mph and address 9
> > usb 1-2: khubd timed out on ep0in
> >
> > It does not show up in /proc/bus/usb/devices (I do have usbfs
> > mounted).
> >
> > I also have usb-utils installed and lsusb fails to list the device.
> >
> > I have also tried other USB devices and get similar errors.
> >
> > Has anybody else experience similar problems? Any pointers/help
> > will be
> > appreciated.
>=20
> I know there are some bugs in the Freescale driver that was released
> as part of their BSP.
>=20
> Are you using a PMC2USB module or just the USB ports on the SYS card?
>=20
> - k
I am connecting to the USB port on the board using the USB adaptor. I
tried both configurations (MPH and DR).
I also tried the latest stable kernel (2.6.16.12) but that doesn't
compile for this board. Is there a later (later than 2.16.11) kernel out
there which works for this particular board?
Another possibility might be that the eval board I have is bad. I can't
seem to get my hands on the errata.
Also waiting to hear back from Freescale folks.
Prashant
^ permalink raw reply
* RE: USB on MPC8349EMDS
From: Steven Blakeslee @ 2006-05-02 19:26 UTC (permalink / raw)
To: Prashant Viswanathan, linuxppc-embedded
>=20
> / # usb 1-2: new high speed USB device using fsl-usb2-mph=20
> and address 8 usb 1-2: khubd timed out on ep0in usb 1-2: new=20
> high speed USB device using fsl-usb2-mph and address 9 usb=20
> 1-2: khubd timed out on ep0in
>=20
When I used that driver I found it only worked with Full speed devices.
Low and High speed devices did not work.
^ permalink raw reply
* Re: USB on MPC8349EMDS
From: Kumar Gala @ 2006-05-02 19:49 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: linuxppc-embedded
In-Reply-To: <1628E43D99629C46988BE46087A3FBB9546A40@ep-01.EmbeddedPlanet.local>
On May 2, 2006, at 2:26 PM, Steven Blakeslee wrote:
>>
>> / # usb 1-2: new high speed USB device using fsl-usb2-mph
>> and address 8 usb 1-2: khubd timed out on ep0in usb 1-2: new
>> high speed USB device using fsl-usb2-mph and address 9 usb
>> 1-2: khubd timed out on ep0in
>>
>
> When I used that driver I found it only worked with Full speed
> devices.
> Low and High speed devices did not work.
Yeah, that was due to the bug in the driver if my memory serves me
correctly.
- k
^ permalink raw reply
* Re: USB on MPC8349EMDS
From: Kumar Gala @ 2006-05-02 19:50 UTC (permalink / raw)
To: Prashant Viswanathan; +Cc: linuxppc-embedded ((((E-Mail))))
In-Reply-To: <DDBD7B17DB2ECE48BCD94C593F7255B401551C7C@monk.echelon.echcorp.com>
On May 2, 2006, at 1:52 PM, Prashant Viswanathan wrote:
>>> When I insert a USB Mass storage device (thumb drive), I get the
>>> following errors
>>>
>>> / # usb 1-2: new high speed USB device using fsl-usb2-mph and
>>> address 8
>>> usb 1-2: khubd timed out on ep0in
>>> usb 1-2: new high speed USB device using fsl-usb2-mph and address 9
>>> usb 1-2: khubd timed out on ep0in
>>>
>>> It does not show up in /proc/bus/usb/devices (I do have usbfs
>>> mounted).
>>>
>>> I also have usb-utils installed and lsusb fails to list the device.
>>>
>>> I have also tried other USB devices and get similar errors.
>>>
>>> Has anybody else experience similar problems? Any pointers/help
>>> will be
>>> appreciated.
>>
>> I know there are some bugs in the Freescale driver that was released
>> as part of their BSP.
>>
>> Are you using a PMC2USB module or just the USB ports on the SYS card?
>>
>> - k
>
> I am connecting to the USB port on the board using the USB adaptor. I
> tried both configurations (MPH and DR).
>
> I also tried the latest stable kernel (2.6.16.12) but that doesn't
> compile for this board. Is there a later (later than 2.16.11)
> kernel out
> there which works for this particular board?
>
> Another possibility might be that the eval board I have is bad. I
> can't
> seem to get my hands on the errata.
You'll need something like 2.6.16 plus a patch from Randy Vinson
(posted to the list a month or two ago).
- kumar
^ permalink raw reply
* cfg_lock
From: Eric Heim @ 2006-05-02 22:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]
Anybody know how the cfg_lock bit is manipulated on the MPC8349EMDS board? I know the bit is in the internal configuration registers but how is this bit flipped on boot? We are trying to boot the board as an agent in a PC. We can only do this using the hard coded option. We would like to boot the board with the reset config word in the I2C but we can't boot the board with the 'core disabled' as we would like(it only works if the core enable bit is set, otherwise the PC hangs and won't boot). We are hoping to use a pre-load command in the boot sequencer, but there is little information on how this can be done or if it can be done. We can flip the bit from u-boot or using our driver when the PC has booted up but we need some way to flip the bit during boot to allow our PC to get its proper configuration cycles. Any ideas?
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
[-- Attachment #2: Type: text/html, Size: 1094 bytes --]
^ permalink raw reply
* Configuring PCI w/ 44x
From: Stephen Winiecki @ 2006-05-02 20:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 7507 bytes --]
I have a question regarding configuring PCI with 44x. Using 2.6.17-rc3 as
a reference, PCI_CONFIG is defined for the 44x defconfigs, and Kconfig is
not enabled to reflect/change the setting for 44x. When I update
arch/ppc/Kconfig to enable configuring or not configuring PCI with 44x, and
then don't configure it, the kernel won't compile:
arch/ppc/kernel/built-in.o: In function `__dma_alloc_coherent':
arch/ppc/kernel/dma-mapping.c:231: undefined reference to `pci_dram_offset'
arch/ppc/kernel/dma-mapping.c:231: undefined reference to `pci_dram_offset'
arch/ppc/mm/built-in.o: In function `ioport_map':
arch/ppc/mm/pgtable.c:265: undefined reference to `isa_io_base'
arch/ppc/mm/pgtable.c:265: undefined reference to `isa_io_base'
arch/ppc/mm/built-in.o: In function `__ioremap':
arch/ppc/mm/pgtable.c:187: undefined reference to `isa_mem_base'
arch/ppc/mm/pgtable.c:187: undefined reference to `isa_mem_base'
arch/ppc/mm/pgtable.c:187: undefined reference to `isa_mem_base'
arch/ppc/mm/pgtable.c:187: undefined reference to `isa_mem_base'
arch/ppc/syslib/built-in.o: In function `outb':
include/asm/io.h:299: undefined reference to `isa_io_base'
arch/ppc/syslib/built-in.o: In function `todc_m48txx_write_val':
include/asm/io.h:299: undefined reference to `isa_io_base'
arch/ppc/syslib/built-in.o: In function `outb':
include/asm/io.h:299: undefined reference to `isa_io_base'
arch/ppc/syslib/built-in.o: In function `todc_mc146818_read_val':
include/asm/io.h:299: undefined reference to `isa_io_base'
arch/ppc/syslib/built-in.o: In function `outb':
include/asm/io.h:299: undefined reference to `isa_io_base'
arch/ppc/syslib/built-in.o:include/asm/io.h:299: more undefined references
to `isa_io_base' follow
arch/ppc/syslib/built-in.o: In function `pciauto_setup_bars':
arch/ppc/syslib/pci_auto.c:56: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/pci_auto.c:61: undefined reference to
`early_read_config_dword'
arch/ppc/syslib/pci_auto.c:93: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/pci_auto.c:108: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/built-in.o: In function `pciauto_prescan_setup_bridge':
arch/ppc/syslib/pci_auto.c:130: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:135: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:140: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:155: undefined reference to
`early_write_config_word'
arch/ppc/syslib/pci_auto.c:160: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:165: undefined reference to
`early_write_config_word'
arch/ppc/syslib/pci_auto.c:172: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/pci_auto.c:177: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/built-in.o: In function `pciauto_postscan_setup_bridge':
arch/ppc/syslib/pci_auto.c:194: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:208: undefined reference to
`early_write_config_word'
arch/ppc/syslib/pci_auto.c:215: undefined reference to
`early_write_config_word'
arch/ppc/syslib/pci_auto.c:223: undefined reference to
`early_write_config_word'
arch/ppc/syslib/pci_auto.c:234: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:239: undefined reference to
`early_write_config_word'
arch/ppc/syslib/pci_auto.c:246: undefined reference to
`early_read_config_dword'
arch/ppc/syslib/pci_auto.c:251: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/built-in.o: In function
`pciauto_prescan_setup_cardbus_bridge':
arch/ppc/syslib/pci_auto.c:269: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:274: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:279: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:294: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/pci_auto.c:299: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/built-in.o: In function
`pciauto_postscan_setup_cardbus_bridge':
arch/ppc/syslib/pci_auto.c:321: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:347: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/pci_auto.c:355: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/pci_auto.c:362: undefined reference to
`early_read_config_dword'
arch/ppc/syslib/pci_auto.c:367: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/built-in.o: In function `pciauto_bus_scan':
arch/ppc/syslib/pci_auto.c:403: undefined reference to
`early_read_config_byte'
arch/ppc/syslib/pci_auto.c:413: undefined reference to
`early_read_config_word'
arch/ppc/syslib/pci_auto.c:420: undefined reference to
`early_read_config_dword'
arch/ppc/syslib/pci_auto.c:493: undefined reference to
`early_read_config_dword'
arch/ppc/syslib/pci_auto.c:498: undefined reference to
`early_write_config_dword'
arch/ppc/syslib/pci_auto.c:506: undefined reference to
`early_write_config_byte'
arch/ppc/syslib/pci_auto.c:474: undefined reference to
`early_read_config_byte'
arch/ppc/platforms/4xx/built-in.o: In function `ocotea_setup_arch':
arch/ppc/platforms/4xx/ocotea.c:195: undefined reference to
`pcibios_alloc_controller'
arch/ppc/platforms/4xx/ocotea.c:205: undefined reference to
`pci_init_resource'
arch/ppc/platforms/4xx/ocotea.c:211: undefined reference to
`pci_init_resource'
arch/ppc/platforms/4xx/ocotea.c:222: undefined reference to `isa_io_base'
arch/ppc/platforms/4xx/ocotea.c:222: undefined reference to `isa_io_base'
arch/ppc/platforms/4xx/ocotea.c:224: undefined reference to
`setup_indirect_pci'
arch/ppc/platforms/4xx/ocotea.c:231: undefined reference to
`common_swizzle'
arch/ppc/platforms/4xx/ocotea.c:231: undefined reference to
`common_swizzle'
drivers/built-in.o: In function `write_port':
drivers/char/mem.c:556: undefined reference to `isa_io_base'
drivers/char/mem.c:556: undefined reference to `isa_io_base'
drivers/built-in.o: In function `inb':
include/asm/io.h:314: undefined reference to `isa_io_base'
include/asm/io.h:314: undefined reference to `isa_io_base'
drivers/built-in.o: In function `outb':
include/asm/io.h:299: undefined reference to `isa_io_base'
drivers/built-in.o:include/asm/io.h:299: more undefined references to
`isa_io_base' follow
drivers/built-in.o: In function `virt_to_bus':
include/asm/io.h:403: undefined reference to `pci_dram_offset'
include/asm/io.h:403: undefined reference to `pci_dram_offset'
drivers/built-in.o: In function `emac_resize_rx_ring':
include/asm/io.h:401: undefined reference to `pci_dram_offset'
include/asm/io.h:401: undefined reference to `pci_dram_offset'
drivers/built-in.o: In function `virt_to_bus':
include/asm/io.h:401: undefined reference to `pci_dram_offset'
drivers/built-in.o:include/asm/io.h:401: more undefined references to
`pci_dram_offset' follow
drivers/built-in.o: In function `inb':
include/asm/io.h:314: undefined reference to `isa_io_base'
include/asm/io.h:314: undefined reference to `isa_io_base'
drivers/built-in.o: In function `outb':
include/asm/io.h:299: undefined reference to `isa_io_base'
include/asm/io.h:299: undefined reference to `isa_io_base'
make: *** [.tmp_vmlinux1] Error 1
Shouldn't not configuring PCI be allowed/supported?
Thanks,
Steve
[-- Attachment #2: Type: text/html, Size: 11082 bytes --]
^ permalink raw reply
* Re: cfg_lock
From: Kumar Gala @ 2006-05-02 22:35 UTC (permalink / raw)
To: Eric Heim; +Cc: linuxppc-embedded
In-Reply-To: <20060502220242.2001.qmail@web37812.mail.mud.yahoo.com>
On May 2, 2006, at 5:02 PM, Eric Heim wrote:
> Anybody know how the cfg_lock bit is manipulated on the MPC8349EMDS
> board? I know the bit is in the internal configuration registers
> but how is this bit flipped on boot? We are trying to boot the
> board as an agent in a PC. We can only do this using the hard
> coded option. We would like to boot the board with the reset
> config word in the I2C but we can't boot the board with the 'core
> disabled' as we would like(it only works if the core enable bit is
> set, otherwise the PC hangs and won't boot). We are hoping to use
> a pre-load command in the boot sequencer, but there is little
> information on how this can be done or if it can be done. We can
> flip the bit from u-boot or using our driver when the PC has booted
> up but we need some way to flip the bit during boot to allow our PC
> to get its proper configuration cycles. Any ideas?
You have the right idea about using the I2C to handle various
register and config writes. However, the UM details how to setup
your EEPROM so that I2C boot sequencer can process it.
See section 4.4.3 in the UM.
- k
^ permalink raw reply
* U-boot1.1.4 porting problem on PPC 440GX
From: pravin @ 2006-05-02 22:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
Hi All,
I build uboot1.1.4 for ocotea_config and run on an ocotea without SPD on DIMMS (SDRAM) and It works. We manufactured another board derived from Ocotea Ref design, 440GX processor and on baord SDRAM (DIMMS) 256MB discrete parts. I use the same Uboot1.1.4 for this board. It boots upto calling the
relocate_code in cpu/ppc4xx/start.S and hangs. The same code works well on Ocotea. I run the memory tests and it passed all.
Any idea why this could hang and never finish the relocate_code function. Trying relocating Uboot to SDRAM memory to get the C environment and run from memory.
Any help would be appreciated. Any idea if i need any special code because of the discrete parts of SDRAM on our board.
Thanks,
Pravin
[-- Attachment #2: Type: text/html, Size: 919 bytes --]
^ permalink raw reply
* Re: U-boot1.1.4 porting problem on PPC 440GX
From: Eugene Surovegin @ 2006-05-02 22:55 UTC (permalink / raw)
To: pravin; +Cc: linuxppc-embedded
In-Reply-To: <20060502223259.55214.qmail@web50512.mail.yahoo.com>
On Tue, May 02, 2006 at 03:32:59PM -0700, pravin wrote:
> Hi All,
> I build uboot1.1.4 for ocotea_config and run on an ocotea without SPD on DIMMS (SDRAM) and It works. We manufactured another board derived from Ocotea Ref design, 440GX processor and on baord SDRAM (DIMMS) 256MB discrete parts. I use the same Uboot1.1.4 for this board. It boots upto calling the
>
> relocate_code in cpu/ppc4xx/start.S and hangs. The same code works well on Ocotea. I run the memory tests and it passed all.
>
> Any idea why this could hang and never finish the relocate_code function. Trying relocating Uboot to SDRAM memory to get the C environment and run from memory.
>
> Any help would be appreciated. Any idea if i need any special code because of the discrete parts of SDRAM on our board.
You can use Ocotea code (kernel and/or U-Boot) as-is for your board
only in one case - your board is _identical_ to Ocotea.
I doubt that this is the case, so you have to modify U-Boot and/or
kernel board support code to accommodate any differences between Ocotea
and your design.
Start with asking your hardware people about such differences.
--
Eugene
^ permalink raw reply
* Re: U-boot1.1.4 porting problem on PPC 440GX
From: Wolfgang Denk @ 2006-05-02 23:34 UTC (permalink / raw)
To: pravin; +Cc: linuxppc-embedded
In-Reply-To: <20060502225540.GA25045@gate.ebshome.net>
In message <20060502225540.GA25045@gate.ebshome.net> Eugene Surovegin wrote:
>
> Start with asking your hardware people about such differences.
...and then post to a mailing list (like u-boot-users) where your
questions fit. Here they are off topic.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Q: Do you know what the death rate around here is?
A: One per person.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-02 23:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <200605021259.24157.arnd@arndb.de>
>> Is there any reason the driver wouldn't build and/or run on other
>> platforms? If so, fix it. If not, just make it
>>
>> depends on PCI
>
> Well, it could run on other platforms, except:
>
> - it requires a few properties in the device tree (local-mac-address,
> firmware), so it should also depend on PPC
The portions of code that require OF should have appropriate #ifdef
guards.
> - It's not actually PCI at all, but on an internal bus that has
> something close enough to a PCI config space.
Our emulation should be good enough; if not, holler (off-list).
Segher
^ permalink raw reply
* Re: Configuring PCI w/ 44x
From: Eugene Surovegin @ 2006-05-02 23:49 UTC (permalink / raw)
To: Stephen Winiecki; +Cc: linuxppc-embedded
In-Reply-To: <OF7EB5CFE4.CBC11341-ON87257162.0071F2FC-85257162.0072FFA5@us.ibm.com>
On Tue, May 02, 2006 at 04:58:32PM -0400, Stephen Winiecki wrote:
> I have a question regarding configuring PCI with 44x. Using 2.6.17-rc3 as
> a reference, PCI_CONFIG is defined for the 44x defconfigs, and Kconfig is
> not enabled to reflect/change the setting for 44x. When I update
> arch/ppc/Kconfig to enable configuring or not configuring PCI with 44x, and
> then don't configure it, the kernel won't compile:
Hmm, you cannot disable PCI for 44x in the current 2.6. It's always
enabled.
If you changed Konfig to be able to do so, why are you complaining
here? It's not enough to just change Konfig, you have to modify Ocotea
port as well. Look for example how this is handled for 85xx.
Patches are welcome.
--
Eugene
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-03 0:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <801072F8-7701-4BD7-81FB-A8C1AA534C2E@kernel.crashing.org>
Am Wednesday 03 May 2006 01:38 schrieb Segher Boessenkool:
> > - it requires a few properties in the device tree (local-mac-address,
> > =A0 firmware), so it should also depend on PPC
>
> The portions of code that require OF should have appropriate #ifdef =A0
> guards.
Why should we? Getting the mac address and the firmware into the
chip is rather essential to make it work. When there is an #ifdef
around that code, it will only produce a non-working driver that can
be compiled everywhere instead of a driver that can only be compiled
on platforms where it has a chance of working.
If someone has the need to make it work somewhere else, it's easy
enough to change to code to whatever other method is used to set up
the chip.
Arnd <><
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Paul Mackerras @ 2006-05-03 2:46 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann, linux-kernel
In-Reply-To: <801072F8-7701-4BD7-81FB-A8C1AA534C2E@kernel.crashing.org>
Segher Boessenkool writes:
> > Well, it could run on other platforms, except:
> >
> > - it requires a few properties in the device tree (local-mac-address,
> > firmware), so it should also depend on PPC
>
> The portions of code that require OF should have appropriate #ifdef
> guards.
So you're suggesting that we change the Makefile so we can *add*
ifdefs? Usually we do it the other way around. :)
Paul.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-03 6:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann, linux-kernel
In-Reply-To: <17496.6519.733076.663815@cargo.ozlabs.ibm.com>
>>> Well, it could run on other platforms, except:
>>>
>>> - it requires a few properties in the device tree (local-mac-
>>> address,
>>> firmware), so it should also depend on PPC
>>
>> The portions of code that require OF should have appropriate #ifdef
>> guards.
>
> So you're suggesting that we change the Makefile so we can *add*
> ifdefs? Usually we do it the other way around. :)
Yeah, what was I thinking. So use some platform hook instead.
But Arnd of course is right; if the driver (currently) only works
on a certain platform, just mark it as such in the Makefile (erm,
Kconfig file).
Hey, we should probably do that with 90% of all drivers. But that
is a discussion for some other day :-)
Segher
^ permalink raw reply
* Re: question on why hvc_console calls hvc_poll() in hvc_handle_interrupt().
From: Michael Ellerman @ 2006-05-03 7:42 UTC (permalink / raw)
To: Ryan Arnold; +Cc: linuxppc-dev, cbe-oss-dev, Milton Miller
In-Reply-To: <1145564752.29313.185.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
On Thu, 2006-04-20 at 15:25 -0500, Ryan Arnold wrote:
> While on the topic of hvc_console; I think I saw a patch go through a
> while ago that added hvc_poll() to hvc_handle_interrupt(). I can't say
> I'm too pleased with that addition. I did my best to keep locking
> outside of the interrupt handler.
>
> I wonder if that change was tested on a power5 lpar system with several
> secondary VSerial Server adapters (hvc1-hvcn) being hammered with data.
> I'm pretty paranoid about deadlock, hence the reason for keeping locking
> out of the int. handler.
That was Milton's patch. No idea whether it's correct/tested.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* mpc8270 : i2c support
From: jfaslist @ 2006-05-03 12:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 1153 bytes --]
Hi,
We have designed a system using a mpc8270 cpu. The firmware we
use is u-boot and we can access all our i2c devices from u-boot.
But when we try to access i2c devices from under linux 2.6 using
the /dev/i2c-0 special file we get an ENODEV on opening that
file. I think it is because we lack an adapter driver.
If I look in the official kernel, it looks like the adapter
driver for the mpc8270 i2c system is
./drivers/i2c/busses/i2c-mpc.c. Is this correct?
Why is this driver registering as a platform driver and not as a
i2c bus driver?
In DENX ELDK there is also a i2c-mpc8260.c, but we couldn't get
that to work either.
What should I do to be able to access i2c devices using the
/dev/i2c-0 file? I feel I need to modify the i2c adapter driver
to follow the driver model, but in what ways?
Thx for any help,
-jf simon
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply
* Re: [PATCH 00/16] ehca: IBM eHCA InfiniBand Device Driver
From: Andrew Morton @ 2006-05-03 12:43 UTC (permalink / raw)
To: Jörn Engel
Cc: schickhj, linux-kernel, openib-general, linuxppc-dev, RAISCH,
HNGUYEN, MEDER
In-Reply-To: <20060427125726.GK32127@wohnheim.fh-wedel.de>
On Thu, 27 Apr 2006 14:57:26 +0200
J=F6rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> Don't expect much cheer and rejoicing over this. I suspect that akpm
> or Linus will either want the 17 patches merged into one or have a
> patchset where every single patch leaves the kernel in a working
> state, including working eHCA driver.
It doesn't matter in this case. The "don't break the build at any stage of
a series" preference exists because it's extremely irritating to hit a
won't-build in the middle of a git-bisect operation.
But anybody who is bisection searching for a bug won't want to enable a
brand-new driver in their config, so no problems.
^ permalink raw reply
* MPC5200 I2C unstable?
From: Kimmo Surakka @ 2006-05-03 13:08 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm using a MPC5200 based board (namely TQM5200) and the
linuxppc_2_4_devel-2005-10-25-1440 kernel from denx.de. To get the serial
ports more stable, I've applied the serial port patch by Achim Machura (can
be found in
http://marc.theaimsgroup.com/?l=linuxppc-embedded&m=112901824515097&w=2). The
patch needed small adjustments, but nothing too large -- mostly different
line numbers.
Also, to get the first I2C interface to work, I've had to change the file
drivers/i2c/i2c-tqm5200.c followingly:
-#define MPC5xxx_I2C1_ENABLE 0 /* Disable */
+#define MPC5xxx_I2C1_ENABLE 1 /* Enable */
The code compiles OK, but the I2C bus gets stuck after a short while. Has
anyone else experienced something similar? I tried to Google for information
but didn't find anything relevant. Maybe I just didn't know the right
keywords to search for?
Thanks in advance,
Kimmo Surakka
This message has been scanned by F-Secure Anti-Virus
### OXFORD INSTRUMENTS http://www.oxford-instruments.com/ ###
Unless stated above to be non-confidential, this E-mail and any
attachments are private and confidential and are for the addressee
only and may not be used, copied or disclosed save to the addressee.
If you have received this E-mail in error please notify us upon receipt
and delete it from your records. Internet communications are not secure
and Oxford Instruments is not responsible for their abuse by third
parties nor for any alteration or corruption in transmission.
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Christoph Raisch @ 2006-05-03 13:56 UTC (permalink / raw)
To: Paul Mackerras
Cc: linux-kernel, openib-general, linuxppc-dev, Hoang-Nam Nguyen,
Marcus Eder, Jörn Engel
In-Reply-To: <17489.18630.75412.66803@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote on 28.04.2006 00:42:14:
> Mind you, since a lot of the parameters are used to return individual
> bytes or half-words, which are then put into structures, it might be
> better to pass the pointers to the structures and let the wrapper put
> the values straight into the structures.
>
> Paul.
As Paul already mentioned we can't change the firmware interface.
...so we would propose the following solution:
For the two h_call wrappers with more than 8 parameters we'll change to the
following signature:
hipz_h_alloc_resource_cq(const struct ipz_adapter_handle adapter_handle,
struct ehca_cq *cq, /* used for input and output
parameters */
const struct ipz_eq_handle eq_handle);
hipz_h_alloc_resource_qp(const struct ipz_adapter_handle adapter_handle,
struct ehca_qp * qp, /* used for input and output
parameters */
struct ehca_alloc_qp_params * param); /*input
params not in ehca_qp*/
hipz_h_alloc_resource_mr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr,
const u64 vaddr,
const u64 length,
const u32 access_ctrl,
const struct ipz_pd pd);
u64 hipz_h_query_mr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr);
u64 hipz_h_reregister_pmr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr,
const u64 vaddr_in,
const u64 length,
const u32 access_ctrl,
const struct ipz_pd pd,
const u64 mr_addr_cb);
u64 hipz_h_register_smr(const struct ipz_adapter_handle adapter_handle,
struct ehca_mr *mr,
struct ehca_mr *orig_mr,
const u64 vaddr_in,
const u32 access_ctrl,
const struct ipz_pd pd);
What do you think about this solution?
Gruss / Regards . . . Christoph Raisch
^ permalink raw reply
* Impossible to open the root console with 2.6.15
From: Jean-Marie Teuler @ 2006-05-03 13:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi there,
I am trying to use ELDK 4.0 on my TQM860L board.
I have compiled the included 2.6.15 kernel with reasonable options, but
when I try to boot it, I do not get the prompt after the message
"Uncompressing Kernel Image ... OK"
Actually, I know that the system is not hanging because
1) I see there is network traffic between the board and the NFS server
2) There are messages written in /var/log/messages, and I see that the
initialization is completed (even my /etc/rc.local has been executed)
So I suspect that the problem comes from reading/writing on the console.
As my /etc/inittab has the line
...............................................
3:2345:respawn:/sbin/mingetty --noclear console
...............................................
I have put a wrapper around the binary "mingetty" and I have checked
that indeed it is called... only that I do not see anything on the
screen.
I am pretty sure that this problem is related to the kernel because if I
boot on a 2.4 kernel with the same root filesystem everything works
fine.
With the 2.4 kernel I had the following messages in /var/log/messages
.................................................................
Jan 22 12:16:34 tqm kernel: ttyS0 at 0x0280 is on SMC1 using BRG1
Jan 22 12:16:34 tqm kernel: ttyS1 at 0x0380 is on SMC2 using BRG2
.................................................................
and with the 2.6
......................................................................
Jan 26 20:25:26 tqm kernel: ttyCPM0 at MMIO 0xfff00a80 (irq = 20) is a
CPM UART
Jan 26 20:25:26 tqm kernel: ttyCPM1 at MMIO 0xfff00a90 (irq = 19) is a
CPM UART
......................................................................
I have tried to create these devices with the following characteristics:
......................................................................
crw-rw---- 1 root root 204, 46 mai 3 14:43 dev/ttyCPM0
crw-rw---- 1 root root 204, 47 mai 3 14:43 dev/ttyCPM1
......................................................................
but to no avail.
I have seen that there are many new options related to serial lines in
the new kernel, so I guess that I am doing something wrong.
Thanks in advance for any hint.
Jean-Marie Teuler
........................................................................
: Jean-Marie Teuler : :
: Laboratoire de Chimie Physique : Téléphone (33) (1) 69 15 42 05 :
: Université de Paris-sud : Télécopie (33) (1) 69 15 61 88 :
: Bâtiment 349 : Mél teuler@lcp.u-psud.fr :
: 91 405 Orsay Cedex : Web http://www.lcp.u-psud.fr :
........................................................................
^ permalink raw reply
* Re: MPC5200 I2C unstable?
From: Arno Geissel @ 2006-05-03 14:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200605031608.47579.kimmo.surakka@oxinst.fi>
As far as I know there are hardware problems on the MPC5200 I2C
interface. They should be solved in the revision B
Arno
> Hi,
>
> I'm using a MPC5200 based board (namely TQM5200) and the
> linuxppc_2_4_devel-2005-10-25-1440 kernel from denx.de. To get the serial
> ports more stable, I've applied the serial port patch by Achim Machura (can
> be found in
> http://marc.theaimsgroup.com/?l=linuxppc-embedded&m=112901824515097&w=2).
> The patch needed small adjustments, but nothing too large -- mostly
> different line numbers.
>
> Also, to get the first I2C interface to work, I've had to change the file
> drivers/i2c/i2c-tqm5200.c followingly:
>
> -#define MPC5xxx_I2C1_ENABLE 0 /* Disable */
> +#define MPC5xxx_I2C1_ENABLE 1 /* Enable */
>
> The code compiles OK, but the I2C bus gets stuck after a short while. Has
> anyone else experienced something similar? I tried to Google for
> information but didn't find anything relevant. Maybe I just didn't know the
> right keywords to search for?
>
> Thanks in advance,
>
> Kimmo Surakka
>
> This message has been scanned by F-Secure Anti-Virus
>
> ### OXFORD INSTRUMENTS http://www.oxford-instruments.com/ ###
>
> Unless stated above to be non-confidential, this E-mail and any
> attachments are private and confidential and are for the addressee
> only and may not be used, copied or disclosed save to the addressee.
> If you have received this E-mail in error please notify us upon receipt
> and delete it from your records. Internet communications are not secure
> and Oxford Instruments is not responsible for their abuse by third
> parties nor for any alteration or corruption in transmission.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox