* [PATCH 3/3] powerpc: Update cell_defconfig for xmon & early debugging
From: Michael Ellerman @ 2006-05-02 9:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
Update cell_defconfig for xmon & early debugging options. There's probably
no point merging this yet, there'll be lots of new stuff before 2.6.18, just
a heads up.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/configs/cell_defconfig | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
Index: cell/arch/powerpc/configs/cell_defconfig
===================================================================
--- cell.orig/arch/powerpc/configs/cell_defconfig
+++ cell/arch/powerpc/configs/cell_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.17-rc1
-# Wed Apr 12 15:40:32 2006
+# Linux kernel version: 2.6.17-rc2
+# Mon May 1 17:04:39 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
@@ -61,7 +61,7 @@ CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
-# CONFIG_KALLSYMS_ALL is not set
+CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
@@ -125,6 +125,7 @@ CONFIG_RTAS_FLASH=y
CONFIG_MMIO_NVRAM=y
CONFIG_CELL_IIC=y
# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
@@ -154,6 +155,7 @@ CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_IRQ_ALL_CPUS=y
CONFIG_NUMA=y
+CONFIG_NODES_SHIFT=4
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
@@ -823,6 +825,14 @@ CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_NEW_LEDS is not set
#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
# InfiniBand support
#
CONFIG_INFINIBAND=y
@@ -1050,11 +1060,13 @@ CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUGGER=y
-# CONFIG_XMON is not set
+CONFIG_XMON=y
+# CONFIG_XMON_DEFAULT is not set
CONFIG_IRQSTACKS=y
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG_LPAR is not set
# CONFIG_PPC_EARLY_DEBUG_G5 is not set
+# CONFIG_PPC_EARLY_DEBUG_CELL is not set
# CONFIG_PPC_EARLY_DEBUG_RTAS is not set
# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set
# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-02 10:59 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1900A234-BE31-4292-87E1-5C02F12A440D@kernel.crashing.org>
On Tuesday 02 May 2006 02:06, Segher Boessenkool wrote:
> 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
- It's not actually PCI at all, but on an internal bus that has
something close enough to a PCI config space.
Arnd <><
^ permalink raw reply
* [PATCH] Add Fujitsu CoralP 8 bits per pixel support
From: Igor Luri @ 2006-05-02 12:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
Hi all,
Denx linux kernel 2.4.25 Fujitsu CoralP driver is configured with 16
bits per pixel color depth. This patch adds support to configure it with
8 bits per pixel.
Best regards.
[-- Attachment #2: coralp.patch --]
[-- Type: text/x-patch, Size: 6497 bytes --]
--- kernel_backup/drivers/video/Config.in 2005-10-04 09:45:39.000000000 +0200
+++ kernel/drivers/video/Config.in 2006-04-25 14:26:42.000000000 +0200
@@ -11,6 +11,16 @@
define_bool CONFIG_DUMMY_CONSOLE y
bool ' Silicon Motion VOYAGER support (on TQM5200)' CONFIG_FB_VOYAGER
bool ' Fujitsu CoralP support' CONFIG_FB_MB86290
+ if [ "$CONFIG_FB_MB86290" = "y" ]; then
+ choice 'Bits per pixel' \
+ "8 CONFIG_MB86290FB_8BPP \
+ 16 CONFIG_MB86290FB_16BPP" 16
+ if [ "$CONFIG_INKA4X0" = "n" ]; then
+ choice 'Screen resolution' \
+ "1024x768 CONFIG_MB86290FB_RES_1024x768 \
+ 640x480 CONFIG_MB86290FB_RES_640x480" 1024x768
+ fi
+ fi
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
if [ "$CONFIG_PCI" = "y" ]; then
tristate ' nVidia Riva support (EXPERIMENTAL)' CONFIG_FB_RIVA
--- kernel_backup/drivers/video/mb86290/mb86290fb.c 2005-10-04 09:45:40.000000000 +0200
+++ kernel/drivers/video/mb86290/mb86290fb.c 2006-04-24 17:22:43.000000000 +0200
@@ -20,6 +20,7 @@
#include <linux/fb.h>
#include <video/fbcon.h>
+#include <video/fbcon-cfb8.h>
#include <video/fbcon-cfb16.h>
#include "mb86290fbdev.h"
@@ -54,8 +55,7 @@
/* display definition */
pdisp->screen_base = (char*)mb86290fb_pInfo->gdcsysinfo.gdcbase;
/* virtual address */
- pdisp->visual = FB_VISUAL_TRUECOLOR;
- pdisp->type = FB_TYPE_PACKED_PIXELS;
+ pdisp->type = FB_TYPE_PACKED_PIXELS;
pdisp->type_aux = 0;
pdisp->ypanstep = 0; /* no hardware support */
pdisp->ywrapstep = 0; /* no hardware support */
@@ -63,7 +63,16 @@
pdisp->line_length = MB86290FB_DFLT_SI_XRES * MB86290FB_DFLT_SI_BITS_PER_PIXEL / 8;
pdisp->can_soft_blank= 1;
pdisp->inverse = 0;
- pdisp->dispsw = &fbcon_cfb16;
+ if(MB86290FB_DFLT_SI_BITS_PER_PIXEL == 8)
+ {
+ pdisp->dispsw = &fbcon_cfb8;
+ pdisp->visual = FB_VISUAL_PSEUDOCOLOR;
+ }
+ else
+ {
+ pdisp->dispsw = &fbcon_cfb16;
+ pdisp->visual = FB_VISUAL_TRUECOLOR;
+ }
pdisp->dispsw_data = &mb86290fb_pInfo->cmap;
pdisp->fb_info = &mb86290fb_pInfo->fb_info;
pdisp->scrollmode = SCROLL_YREDRAW; /* no hardware support */
@@ -87,11 +96,14 @@
mb86290fb_pInfo->palette[regno].red = red;
mb86290fb_pInfo->palette[regno].green = green;
mb86290fb_pInfo->palette[regno].blue = blue;
-
+
if (regno<16){
mb86290fb_pInfo->cmap[regno] = ((red & 0xf8) << 7)
| ((green & 0xf8) << 2) | ((blue & 0xf8) >> 3);
}
+
+ MB86290FB_WRITE_DISP_REGISTER((GDC_DISP_REG_PALLET_0 + (regno*4)), (((red & 0xfc) << 16) | ((green & 0xfc)<< 8) | ((blue & 0xfc))));
+
return 0;
}
@@ -469,9 +481,14 @@
/* DispDimension */
MB86290FB_WRITE_DISP_REGISTER(GDC_DISP_REG_C_MODE_W_H,
- (1 << 31) |
((MB86290FB_DFLT_SI_XRES * MB86290FB_DFLT_SI_BITS_PER_PIXEL / 8 / 64) << 16) |
- (MB86290FB_DFLT_SI_YRES - 1));
+ (MB86290FB_DFLT_SI_YRES - 1));
+ if(MB86290FB_DFLT_SI_BITS_PER_PIXEL == 16)
+ {
+ reg = MB86290FB_READ_DISP_REGISTER(GDC_DISP_REG_C_MODE_W_H);
+ MB86290FB_WRITE_DISP_REGISTER(GDC_DISP_REG_C_MODE_W_H, reg | (1 << 31));
+ }
+
MB86290FB_WRITE_DISP_REGISTER(GDC_DISP_REG_C_ORG_ADR, 0);
MB86290FB_WRITE_DISP_REGISTER(GDC_DISP_REG_C_DISP_ADR, 0);
--- kernel_backup/drivers/video/mb86290/mb86290fbsys.h 2005-11-21 10:44:22.000000000 +0100
+++ kernel/drivers/video/mb86290/mb86290fbsys.h 2006-04-25 17:52:15.000000000 +0200
@@ -75,7 +75,7 @@
/* Screen information of frame buffer */
#ifndef CONFIG_INKA4X0
-#if 1
+#if CONFIG_MB86290FB_RES_640x480
#define MB86290FB_DFLT_SI_XRES 640
#define MB86290FB_DFLT_SI_YRES 480
#define MB86290FB_DFLT_SI_XRES_VIRTUAL 640
@@ -94,16 +94,28 @@
#endif
#define MB86290FB_DFLT_SI_XOFFSET 0
#define MB86290FB_DFLT_SI_YOFFSET 0
-#define MB86290FB_DFLT_SI_BITS_PER_PIXEL 16
+
+#if CONFIG_MB86290FB_8BPP
+# define MB86290FB_DFLT_SI_BITS_PER_PIXEL 8
+# define MB86290FB_DFLT_SI_RED_OFFSET 0
+# define MB86290FB_DFLT_SI_RED_LENGTH 6
+# define MB86290FB_DFLT_SI_GREEN_OFFSET 0
+# define MB86290FB_DFLT_SI_GREEN_LENGTH 6
+# define MB86290FB_DFLT_SI_BLUE_OFFSET 0
+# define MB86290FB_DFLT_SI_BLUE_LENGTH 6
+#endif
+#if CONFIG_MB86290FB_16BPP
+# define MB86290FB_DFLT_SI_BITS_PER_PIXEL 16
+# define MB86290FB_DFLT_SI_RED_OFFSET 10
+# define MB86290FB_DFLT_SI_RED_LENGTH 5
+# define MB86290FB_DFLT_SI_GREEN_OFFSET 5
+# define MB86290FB_DFLT_SI_GREEN_LENGTH 5
+# define MB86290FB_DFLT_SI_BLUE_OFFSET 0
+# define MB86290FB_DFLT_SI_BLUE_LENGTH 5
+#endif
#define MB86290FB_DFLT_SI_GRAYSCALE 0
-#define MB86290FB_DFLT_SI_RED_OFFSET 10
-#define MB86290FB_DFLT_SI_RED_LENGTH 5
#define MB86290FB_DFLT_SI_RED_RIGHT 0
-#define MB86290FB_DFLT_SI_GREEN_OFFSET 5
-#define MB86290FB_DFLT_SI_GREEN_LENGTH 5
#define MB86290FB_DFLT_SI_GREEN_RIGHT 0
-#define MB86290FB_DFLT_SI_BLUE_OFFSET 0
-#define MB86290FB_DFLT_SI_BLUE_LENGTH 5
#define MB86290FB_DFLT_SI_BLUE_RIGHT 0
#define MB86290FB_DFLT_SI_TRANSP_OFFSET 0
#define MB86290FB_DFLT_SI_TRANSP_LENGTH 1
--- kernel_backup/include/video/fbcon.h 2005-10-04 09:45:44.000000000 +0200
+++ kernel/include/video/fbcon.h 2006-04-25 14:22:54.000000000 +0200
@@ -229,11 +229,13 @@
#endif
#define fb_writeb(b,addr) (*(volatile u8 *) (addr) = (b))
#if defined(CONFIG_FB_MB86290) && defined(__BIG_ENDIAN)
-#define fb_writew(b,addr) (*(volatile u16 *) (addr) = cpu_to_le16(b))
-#define fb_writel(b,addr) (*(volatile u32 *) (addr) = cpu_to_le16((u16)b) | (cpu_to_le16(((u32)b) >> 16) << 16))
-#else
+#if CONFIG_MB86290FB_8BPP
#define fb_writew(b,addr) (*(volatile u16 *) (addr) = (b))
#define fb_writel(b,addr) (*(volatile u32 *) (addr) = (b))
+#else
+#define fb_writew(b,addr) (*(volatile u16 *) (addr) = cpu_to_le16(b))
+#define fb_writel(b,addr) (*(volatile u32 *) (addr) = cpu_to_le16((u16)b) | (cpu_to_le16(((u32)b) >> 16) << 16))
+#endif
#endif
#define fb_memset memset
--- kernel_backup/arch/ppc/configs/icecube_5200_CoralP_defconfig 2005-10-04 09:45:29.000000000 +0200
+++ kernel/arch/ppc/configs/icecube_5200_CoralP_defconfig 2006-05-02 10:30:11.000000000 +0200
@@ -509,6 +509,10 @@
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FB_VOYAGER is not set
CONFIG_FB_MB86290=y
+# CONFIG_MB86290FB_8BPP is not set
+CONFIG_MB86290FB_16BPP=y
+CONFIG_MB86290FB_RES_1024x768=y
+# CONFIG_MB86290FB_RES_640x480 is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_CLGEN is not set
# CONFIG_FB_PM2 is not set
^ permalink raw reply
* Re: [PATCH 13/16] ehca: firmware InfiniBand interface
From: Christoph Raisch @ 2006-05-02 9:30 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>
We started like that to get a clean interface between the register
intensive h_calls and the driver code.
We're in the middle of the tradeoff "nice interface" vs strict fencing=
of
data structures from one code piece to another.
Initially these functions, which only move paramaters from the stack in=
to
registers and back, were inline functions.
So the compiler collapsed the function call into "nothing", which won't=
work if you use a struct *.
Somewhen during code reviews people agreed that having this many inline=
functions leads to large header files
which isn't a good idea either.
We're about to change that interface again, so what should be the max
number of parameters in a function call?
The limit in existing kernel code is somewhere between 5-8
(just as a reminder, 8 is the max nr of parameters to be passed by regi=
ster
on ppc)
christoph raisch
Paul Mackerras <paulus@samba.org> wrote on 28.04.2006 00:42:14:
> J=F6rn Engel writes:
>
> > 25 parameters? If you tell me which drugs were involved in this co=
de,
> > I know what to stay away from.
>
> You really need to ask the firmware architects that, since this is
> basically a single firmware call.
>
> 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.=
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andy Whitcroft @ 2006-05-02 13:20 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linuxppc64-dev, linux-kernel, Martin J. Bligh
In-Reply-To: <200605012034.26763.ak@suse.de>
Andi Kleen wrote:
> On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
>
>
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000 EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>> 0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>> <ffffffff8020bba6>{do_double_fault+115}
>><ffffffff8020aa91>{double_fault+125}
>> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>
>
> That's really strange - i wonder why the backtracer can't find the original
> stack. Should probably add some printk diagnosis here.
>
> Can you send the output with this patch?
Submitted, they should show up in teh matrix forthwith. Will drop you
the output when done.
-apw
^ permalink raw reply
* Re: [PATCH 11/13] cell: split out board specific files
From: Christoph Hellwig @ 2006-05-02 13:45 UTC (permalink / raw)
To: Geoff Levand
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, paulus, cbe-oss-dev,
Arnd Bergmann
In-Reply-To: <445690F7.5050605@am.sony.com>
On Mon, May 01, 2006 at 03:51:35PM -0700, Geoff Levand wrote:
> 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) += ...
>
> I also got rid of SPUFS_PRIV1_MMIO, since SPUFS_PRIV1_MMIO
> just meant spufs with !SOME_HYPERVISOR_THING.
The Kconfig files has lots of nice operators.
Anyway, until we actually have the cell common hypervisor interface
out in the public adding any support for it in Kconfig or the
Makefile is completely pointless, and a patch like this even when
done correctly shouldn't go in.
> Split the Cell BPA support into generic and platform
> dependant parts.
>
> Creates new config variable CONFIG_PPC_IBM_CELL_BLADE.
That's wrong. Most of these files will be needed to support
the PS3 when running on bare hardware. The right option will
be CELL_SPIDER_HARDWARE, which is right now the only cell
hardware generation supported. It'll become meaningfull when
adding axon support.
^ permalink raw reply
* [PATCH] powerpc: Fix FSL SEC node in documentation
From: Kim Phillips @ 2006-05-02 16:58 UTC (permalink / raw)
To: linuxppc-dev
Documentation: correct values in MPC5848E SEC example node
---
commit 27ef8f30208ceb62c5387e834a335558e7e88c70
tree e96c74f732489115651ea00d0514e66e8050c60a
parent 1f4a90670bacbf61f2fcc19a9e0e78748c932a25
author Kim Phillips <kim.phillips@freescale.com> Tue, 02 May 2006 11:38:23 -0500
committer Kim Phillips <kim.phillips@freescale.com> Tue, 02 May 2006 11:38:23 -0500
Documentation/powerpc/booting-without-of.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 217e517..3c62e66 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1436,9 +1436,9 @@ platforms are moved over to use the flat
interrupts = <1d 3>;
interrupt-parent = <40000>;
num-channels = <4>;
- channel-fifo-len = <24>;
+ channel-fifo-len = <18>;
exec-units-mask = <000000fe>;
- descriptor-types-mask = <073f1127>;
+ descriptor-types-mask = <012b0ebf>;
};
^ permalink raw reply related
* FW: USB on MPC8349EMDS
From: Prashant Viswanathan @ 2006-05-02 17:57 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have linux kernel (2.6.11) from Freescale running on the MPC8349EMDS.
I am using the BSP from Freescale which is supposed to have USB support.
However, I seem to be having problems with USB host support.
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.
Thanks,
Prashant
^ permalink raw reply
* Re: USB on MPC8349EMDS
From: Kumar Gala @ 2006-05-02 18:19 UTC (permalink / raw)
To: Prashant Viswanathan; +Cc: linuxppc-embedded
In-Reply-To: <DDBD7B17DB2ECE48BCD94C593F7255B401551C7A@monk.echelon.echcorp.com>
On May 2, 2006, at 12:57 PM, Prashant Viswanathan wrote:
> Hi,
>
> I have linux kernel (2.6.11) from Freescale running on the
> MPC8349EMDS.
> I am using the BSP from Freescale which is supposed to have USB
> support.
>
> However, I seem to be having problems with USB host support.
>
> 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
^ permalink raw reply
* 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
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