* Re: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
From: Stefan Roese @ 2008-04-24 13:06 UTC (permalink / raw)
To: jwboyer; +Cc: u-boot-users, linuxppc-embedded
In-Reply-To: <1209038406.2946.20.camel@vader.jdub.homelinux.org>
On Thursday 24 April 2008, Josh Boyer wrote:
> > This depends. When the bootwrapper version is used then yes, the kernel
> > should get changed. This is because the bootwrapper detects the SDRAM
> > size from the DDR2 controller and passes it to Linux.
> >
> > Without bootwrapper no changes are needed, since U-Boot already passes
> > the corrected memory size to Linux (totalsize-4k currently).
>
> Hm. Given that AMCC ships the boards with an older U-Boot that requires
> cuImages, I think we'll need to patch the wrapper.
Yes, this should be done too. I forgot about it since I usually don't use the
wrapper.
> Does 440GRx share
> this same errata? I would think so.
Yep. Same problem on 440GRx.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* [PATCH v5] create modalias file in sysfs for bus of_platform
From: Olaf Hering @ 2008-04-24 13:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <20080126100427.GA1162@aepfle.de>
Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
of modules. modalias files are already present for many other bus types.
This adds also a newline to the devspec files.
Also create a devspec file for mac-io devices. They were created as a side
effect. Use correct buffer size for mac-io modalias buffer.
Tested on iBook1 and Efika.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/macintosh/macio_sysfs.c | 12 +++++++++++-
drivers/of/device.c | 36 ++++++++++++++++++++----------------
drivers/of/platform.c | 3 +++
3 files changed, 34 insertions(+), 17 deletions(-)
--- a/drivers/macintosh/macio_sysfs.c
+++ b/drivers/macintosh/macio_sysfs.c
@@ -44,7 +44,7 @@ static ssize_t modalias_show (struct dev
struct of_device *ofdev = to_of_device(dev);
int len;
- len = of_device_get_modalias(ofdev, buf, PAGE_SIZE);
+ len = of_device_get_modalias(ofdev, buf, PAGE_SIZE - 2);
buf[len] = '\n';
buf[len+1] = 0;
@@ -52,6 +52,15 @@ static ssize_t modalias_show (struct dev
return len+1;
}
+static ssize_t devspec_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct of_device *ofdev;
+
+ ofdev = to_of_device(dev);
+ return sprintf(buf, "%s\n", ofdev->node->full_name);
+}
+
macio_config_of_attr (name, "%s\n");
macio_config_of_attr (type, "%s\n");
@@ -60,5 +69,6 @@ struct device_attribute macio_dev_attrs[
__ATTR_RO(type),
__ATTR_RO(compatible),
__ATTR_RO(modalias),
+ __ATTR_RO(devspec),
__ATTR_NULL
};
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -48,16 +48,32 @@ void of_dev_put(struct of_device *dev)
}
EXPORT_SYMBOL(of_dev_put);
-static ssize_t dev_show_devspec(struct device *dev,
+static ssize_t devspec_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct of_device *ofdev;
ofdev = to_of_device(dev);
- return sprintf(buf, "%s", ofdev->node->full_name);
+ return sprintf(buf, "%s\n", ofdev->node->full_name);
}
-static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
+static ssize_t modalias_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct of_device *ofdev = to_of_device(dev);
+ ssize_t len = 0;
+
+ len = of_device_get_modalias(ofdev, buf, PAGE_SIZE - 2);
+ buf[len] = '\n';
+ buf[len+1] = 0;
+ return len+1;
+}
+
+struct device_attribute of_platform_device_attrs[] = {
+ __ATTR_RO(devspec),
+ __ATTR_RO(modalias),
+ __ATTR_NULL
+};
/**
* of_release_dev - free an of device structure when all users of it are finished.
@@ -78,25 +94,13 @@ EXPORT_SYMBOL(of_release_dev);
int of_device_register(struct of_device *ofdev)
{
- int rc;
-
BUG_ON(ofdev->node == NULL);
-
- rc = device_register(&ofdev->dev);
- if (rc)
- return rc;
-
- rc = device_create_file(&ofdev->dev, &dev_attr_devspec);
- if (rc)
- device_unregister(&ofdev->dev);
-
- return rc;
+ return device_register(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_register);
void of_device_unregister(struct of_device *ofdev)
{
- device_remove_file(&ofdev->dev, &dev_attr_devspec);
device_unregister(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_unregister);
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -17,6 +17,8 @@
#include <linux/of_device.h>
#include <linux/of_platform.h>
+extern struct device_attribute of_platform_device_attrs[];
+
static int of_platform_bus_match(struct device *dev, struct device_driver *drv)
{
struct of_device *of_dev = to_of_device(dev);
@@ -103,6 +105,7 @@ int of_bus_type_init(struct bus_type *bu
bus->suspend = of_platform_device_suspend;
bus->resume = of_platform_device_resume;
bus->shutdown = of_platform_device_shutdown;
+ bus->dev_attrs = of_platform_device_attrs;
return bus_register(bus);
}
^ permalink raw reply
* [PATCH] [POWERPC] Add IRQSTACKS support on ppc32
From: Kumar Gala @ 2008-04-24 13:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
* Added allocation and initialization of the irq stacks. We limit the
stacks to be in lowmem for ppc32.
* Implemented ppc32 versions of call_do_softirq() and call_handle_irq()
to switch the stack pointers
* Reworked how we do stack overflow detection. We now keep around the
limit of the stack in the thread_struct and compare against the limit
to see if we've overflowed. We can now use this on ppc64 if desired.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/Kconfig.debug | 1 -
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/entry_32.S | 4 ++--
arch/powerpc/kernel/irq.c | 10 +++++++++-
arch/powerpc/kernel/misc_32.S | 25 +++++++++++++++++++++++++
arch/powerpc/kernel/process.c | 2 ++
arch/powerpc/kernel/setup_32.c | 21 +++++++++++++++++++++
include/asm-powerpc/processor.h | 6 ++++++
8 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index a86d8d8..2cf72d2 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -118,7 +118,6 @@ config XMON_DISASSEMBLY
config IRQSTACKS
bool "Use separate kernel stacks when processing interrupts"
- depends on PPC64
help
If you say Y here the kernel will use separate kernel stacks
for handling hard and soft interrupts. This can help avoid
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index adf1d09..0ef4d41 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -64,6 +64,7 @@ int main(void)
#endif /* CONFIG_PPC64 */
DEFINE(KSP, offsetof(struct thread_struct, ksp));
+ DEFINE(KSP_LIMIT, offsetof(struct thread_struct, ksp_limit));
DEFINE(PT_REGS, offsetof(struct thread_struct, regs));
DEFINE(THREAD_FPEXC_MODE, offsetof(struct thread_struct, fpexc_mode));
DEFINE(THREAD_FPR0, offsetof(struct thread_struct, fpr[0]));
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 84c8686..f33c1fe 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -137,8 +137,8 @@ transfer_to_handler:
2: /* if from kernel, check interrupted DOZE/NAP mode and
* check for stack overflow
*/
- lwz r9,THREAD_INFO-THREAD(r12)
- cmplw r1,r9 /* if r1 <= current->thread_info */
+ lwz r9,KSP_LIMIT(r12)
+ cmplw r1,r9 /* if r1 <= ksp_limit */
ble- stack_ovf /* then the kernel stack overflowed */
5:
#ifdef CONFIG_6xx
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 425616f..7378c98 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -307,6 +307,7 @@ void do_IRQ(struct pt_regs *regs)
if (curtp != irqtp) {
struct irq_desc *desc = irq_desc + irq;
void *handler = desc->handle_irq;
+ unsigned long saved_sp_limit = current->thread.ksp_limit;
if (handler == NULL)
handler = &__do_IRQ;
irqtp->task = curtp->task;
@@ -319,7 +320,10 @@ void do_IRQ(struct pt_regs *regs)
(irqtp->preempt_count & ~SOFTIRQ_MASK) |
(curtp->preempt_count & SOFTIRQ_MASK);
+ current->thread.ksp_limit = (unsigned long)irqtp +
+ _ALIGN_UP(sizeof(struct thread_info), 16);
call_handle_irq(irq, desc, irqtp, handler);
+ current->thread.ksp_limit = saved_sp_limit;
irqtp->task = NULL;
@@ -352,7 +356,7 @@ void __init init_IRQ(void)
{
if (ppc_md.init_IRQ)
ppc_md.init_IRQ();
-#ifdef CONFIG_PPC64
+#ifdef CONFIG_IRQSTACKS
irq_ctx_init();
#endif
}
@@ -383,11 +387,15 @@ void irq_ctx_init(void)
static inline void do_softirq_onstack(void)
{
struct thread_info *curtp, *irqtp;
+ unsigned long saved_sp_limit = current->thread.ksp_limit;
curtp = current_thread_info();
irqtp = softirq_ctx[smp_processor_id()];
irqtp->task = curtp->task;
+ current->thread.ksp_limit = (unsigned long)irqtp +
+ _ALIGN_UP(sizeof(struct thread_info), 16);
call_do_softirq(irqtp);
+ current->thread.ksp_limit = saved_sp_limit;
irqtp->task = NULL;
}
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 92ccc6f..89aaaa6 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -32,6 +32,31 @@
.text
+#ifdef CONFIG_IRQSTACKS
+_GLOBAL(call_do_softirq)
+ mflr r0
+ stw r0,4(r1)
+ stwu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
+ mr r1,r3
+ bl __do_softirq
+ lwz r1,0(r1)
+ lwz r0,4(r1)
+ mtlr r0
+ blr
+
+_GLOBAL(call_handle_irq)
+ mflr r0
+ stw r0,4(r1)
+ mtctr r6
+ stwu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r5)
+ mr r1,r5
+ bctrl
+ lwz r1,0(r1)
+ lwz r0,4(r1)
+ mtlr r0
+ blr
+#endif /* CONFIG_IRQSTACKS */
+
/*
* This returns the high 64 bits of the product of two 64-bit numbers.
*/
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 6caad17..7de41c3 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -589,6 +589,8 @@ int copy_thread(int nr, unsigned long clone_flags, unsigned long usp,
kregs = (struct pt_regs *) sp;
sp -= STACK_FRAME_OVERHEAD;
p->thread.ksp = sp;
+ p->thread.ksp_limit = (unsigned long)task_stack_page(p) +
+ _ALIGN_UP(sizeof(struct thread_info), 16);
#ifdef CONFIG_PPC64
if (cpu_has_feature(CPU_FTR_SLB)) {
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 36f6779..5112a4a 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -16,6 +16,7 @@
#include <linux/root_dev.h>
#include <linux/cpu.h>
#include <linux/console.h>
+#include <linux/lmb.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -229,6 +230,24 @@ int __init ppc_init(void)
arch_initcall(ppc_init);
+#ifdef CONFIG_IRQSTACKS
+static void __init irqstack_early_init(void)
+{
+ unsigned int i;
+
+ /* interrupt stacks must be in lowmem, we get that for free on ppc32
+ * as the lmb is limited to lowmem by LMB_REAL_LIMIT */
+ for_each_possible_cpu(i) {
+ softirq_ctx[i] = (struct thread_info *)
+ __va(lmb_alloc(THREAD_SIZE, THREAD_SIZE));
+ hardirq_ctx[i] = (struct thread_info *)
+ __va(lmb_alloc(THREAD_SIZE, THREAD_SIZE));
+ }
+}
+#else
+#define irqstack_early_init()
+#endif
+
/* Warning, IO base is not yet inited */
void __init setup_arch(char **cmdline_p)
{
@@ -286,6 +305,8 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long) _edata;
init_mm.brk = klimit;
+ irqstack_early_init();
+
/* set up the bootmem stuff with available memory */
do_init_bootmem();
if ( ppc_md.progress ) ppc_md.progress("setup_arch: bootmem", 0x3eab);
diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
index fd98ca9..cf83f2d 100644
--- a/include/asm-powerpc/processor.h
+++ b/include/asm-powerpc/processor.h
@@ -138,6 +138,8 @@ typedef struct {
struct thread_struct {
unsigned long ksp; /* Kernel stack pointer */
+ unsigned long ksp_limit; /* if ksp <= ksp_limit stack overflow */
+
#ifdef CONFIG_PPC64
unsigned long ksp_vsid;
#endif
@@ -182,11 +184,14 @@ struct thread_struct {
#define ARCH_MIN_TASKALIGN 16
#define INIT_SP (sizeof(init_stack) + (unsigned long) &init_stack)
+#define INIT_SP_LIMIT \
+ (_ALIGN_UP(sizeof(init_thread_info), 16) + (unsigned long) &init_stack)
#ifdef CONFIG_PPC32
#define INIT_THREAD { \
.ksp = INIT_SP, \
+ .ksp_limit = INIT_SP_LIMIT, \
.fs = KERNEL_DS, \
.pgdir = swapper_pg_dir, \
.fpexc_mode = MSR_FE0 | MSR_FE1, \
@@ -194,6 +199,7 @@ struct thread_struct {
#else
#define INIT_THREAD { \
.ksp = INIT_SP, \
+ .ksp_limit = INIT_SP_LIMIT, \
.regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \
.fs = KERNEL_DS, \
.fpr = {0}, \
--
1.5.4.1
^ permalink raw reply related
* EABI
From: Brian Silverman @ 2008-04-24 14:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
Is it possible to compile a Linux application using an EABI compiler
(specfically, Xilinx's EDK powerpc-eabi-gcc.exe)?
The issue at hand is that we'd like for our customers to be able to use
the Xilinx EDK toolchain (which we know they will have) to compile Linx
apps without having to install another toolchain (crosstool, ELDK, etc).
So, what I'm hoping is that the EDK toolchain can be configured to be
Linux compatible binaries, or that there is some kind of wrapper that
will handle the incompatible interfaces. Searching around, I've seen
some mention of Linux EABI compatibility (for Debian ARM releases), but
I haven't found any clear concensus...
----
Brian Silverman
Principal Engineer
iVeia
[-- Attachment #2: Type: text/html, Size: 1999 bytes --]
^ permalink raw reply
* Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32
From: Benjamin Herrenschmidt @ 2008-04-24 14:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <43F83C6F-D84B-4626-8974-9BCEDF03194E@kernel.crashing.org>
On Thu, 2008-04-24 at 07:59 -0500, Kumar Gala wrote:
> I'm going to change it to be just lmb_alloc() so it will be difficult
> to share with ppc64 (other than w/an ifdef).
Unless we change lmb_alloc to just be an lmb_alloc_base with 0 and have
the later do the right thing ?
You don't put highmem in the LMBs ? If you do, we do need to have the
max lowmem there no ?
Ben.
^ permalink raw reply
* mpc5200b custom board upstreamable?
From: Sascha Hauer @ 2008-04-24 15:12 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I had the intention to push the code for a custom mpc5200b board (freely
available, no internal project) upstream. After cleaning up the code I
realized that actually no board specific code is left and our board is
well handled by the mpc5200_simple_platform machine.
The only issue is that the machine only matches things like
"schindler,cm5200", there's no generic entry. Would it be possible to
add a "generic-mpc52xx" entry to this list?
Another question: are defconfig and dts files for custom boards acceptable
for upstream?
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* Re: mpc5200b custom board upstreamable?
From: Grant Likely @ 2008-04-24 15:13 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev
In-Reply-To: <20080424151237.GI6692@pengutronix.de>
On Thu, Apr 24, 2008 at 9:12 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> Hi all,
>
> I had the intention to push the code for a custom mpc5200b board (freely
> available, no internal project) upstream. After cleaning up the code I
> realized that actually no board specific code is left and our board is
> well handled by the mpc5200_simple_platform machine.
>
> The only issue is that the machine only matches things like
> "schindler,cm5200", there's no generic entry. Would it be possible to
> add a "generic-mpc52xx" entry to this list?
I'm being cautious about this for the time being. I'd like to have a
generic match mechanism, but I don't want to do something that isn't
easy to recover from if it turns out to be brain dead. For now, just
add your board name to the explicit match list.
>
> Another question: are defconfig and dts files for custom boards acceptable
> for upstream?
Yes, in the arch/powerpc/configs/52xx/ directory.
Cheers,
g
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Memory corruption
From: Geert Uytterhoeven @ 2008-04-24 15:31 UTC (permalink / raw)
To: Linux/PPC Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5023 bytes --]
Hi,
I saw some random lockups on my PS3, so I decided to give the current kernel a
try on the PS3 development tool. It crashes when setting up the network:
| <5>Sending DHCP requests ., OK
| IP-Config: Got DHCP answer from 192.168.106.200, my address is 192.168.106.196
| IP-Config: Complete:
| device=eth0, addr=192.168.106.196, mask=255.255.255.0, gw=192.168.106.254,
| host=192.168.106.196, domain=sonytel.be, nis-domain=(none),
| bootserver=192.168.106.200, rootserver=192.168.106.200, rootpath=/disk-02/ps3linux/debian-powerpc
| <5>Looking up port of RPC 100003/2 on 192.168.106.200
| <0>Unrecoverable FP Unavailable Exception 800 at c000000000305220
| Oops: Unrecoverable FP Unavailable Exception, sig: 6 [#1]
| SMP NR_CPUS=2 PS3
| Modules linked in:
| NIP: c000000000305220 LR: c000000000304d34 CTR: c0000000003051c0
| REGS: c00000000604aa70 TRAP: 0800 Not tainted (2.6.25-03562-g3dc5063-dirty)
| MSR: 8000000000008032 <EE,IR,DR> CR: 24004082 XER: 00000000
| TASK = c000000006046040[1] 'swapper' THREAD: c000000006048000 CPU: 0
| <6>GPR00: 0000000000000800 c00000000604acf0 c000000000603a88 c000000006262680
| <6>GPR04: 0662160400000002 0000000000004000 c0000000064a4110 c00000000062eda8
| <6>GPR08: c0000000061a6000 0000000000000001 0000000000000100 c0000000062bf880
| <6>GPR12: 0000001100000000 c000000000548300 0000000000000000 0000000000000000
| <6>GPR16: 0000000000000000 000000000000005c 0000000000000000 000000000000005c
| <6>GPR20: c0000000063a9db8 00000000c0a86ac8 0000000000000000 c0000000063a9d08
| <6>GPR24: 0000000000000040 0000000000004000 c0000000063a9b80 c000000006391e00
| <6>GPR28: c0000000064a4020 c000000006262680 c0000000005ae478 c00000000604acf0
| NIP [c000000000305220] .ip_output+0x60/0x8c
| LR [c000000000304d34] .ip_local_out+0x50/0x78
| Call Trace:
| [c00000000604acf0] [c00000000604ada0] 0xc00000000604ada0 (unreliable)
| [c00000000604ad70] [c000000000304d34] .ip_local_out+0x50/0x78
| [c00000000604ae00] [c0000000003050c0] .ip_push_pending_frames+0x364/0x410
| [c00000000604aeb0] [c000000000326a60] .udp_push_pending_frames+0x350/0x408
| [c00000000604af70] [c000000000328048] .udp_sendmsg+0x4c4/0x630
| [c00000000604b0d0] [c0000000003306e4] .inet_sendmsg+0x84/0xb0
| [c00000000604b170] [c0000000002cd430] .sock_sendmsg+0xc4/0x108
| [c00000000604b370] [c0000000002ceed8] .kernel_sendmsg+0x40/0x64
| [c00000000604b400] [c00000000038cc1c] .xs_send_kvec+0xc8/0x100
| [c00000000604b510] [c00000000038cd10] .xs_sendpages+0xbc/0x2f4
| [c00000000604b5e0] [c00000000038ed38] .xs_udp_send_request+0x60/0x148
| [c00000000604b680] [c00000000038b1b8] .xprt_transmit+0x144/0x27c
| [c00000000604b730] [c00000000038776c] .call_transmit+0x248/0x2b0
| [c00000000604b7d0] [c000000000390a68] .__rpc_execute+0xd8/0x314
| [c00000000604b870] [c000000000390d18] .rpc_execute+0x40/0x5c
| [c00000000604b900] [c000000000387fe8] .rpc_run_task+0x84/0xb0
| [c00000000604b9a0] [c00000000038814c] .rpc_call_sync+0x74/0xc0
| [c00000000604ba70] [c00000000039a568] .rpcb_getport_sync+0x110/0x178
| [c00000000604bb80] [c000000000511118] .root_nfs_getport+0x8c/0xbc
| [c00000000604bc30] [c0000000005112f0] .nfs_root_data+0x1a8/0x328
| [c00000000604bd70] [c0000000004f66a8] .mount_root+0x40/0x150
| [c00000000604be10] [c0000000004f695c] .prepare_namespace+0x1a4/0x1f4
| [c00000000604bea0] [c0000000004f5a48] .kernel_init+0x388/0x3c8
| [c00000000604bf90] [c0000000000229c8] .kernel_thread+0x4c/0x68
| Instruction dump:
| e9230028 e8fe8018 7c000026 54001ffe e9090018 78001f24 7d27002a 38000800
| 7d2948f8 7d6b482a e92b0058 39290001 <c0000000> 00546e70 f9030020 4bfff775
^^^^^^^^ ^^^^^^^^
should be f92b0058 b003007e
| <4>---[ end trace c7cf3d9b6c787395 ]---
| <0>Kernel panic - not syncing: Attempted to kill init!
| smp_call_function on cpu 0: other cpus not responding (0)
|
| System does not reboot automatically.
| Please press POWER button.
|
| <7>eth0: no IPv6 routers present
Findings:
- Disabling CONFIG_INET fixed the problem.
- I didn't manage to lock up my PS3 afterwards neither.
But... while typing this, I saw an oops accessing address
0xf000f000f0007000 somewhere in the networking code, so it looks like some
corruption is going on after all.
- Upon closer look, 8 bytes in the instruction dump above are not correct
and have been overwritten with 0xc000000000546e70, which is the address of
init_task.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · BIC GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH] add gpiolib support for mpc5200
From: Sascha Hauer @ 2008-04-24 15:36 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Feel free to comment on this.
Sascha
This patch adds gpiolib support for mpc5200 SOCs. I'm not sure
whether it's a good idea to make this optional via kconfig.
The gpt devices only support a single gpio. In the current of_gpio
implementation each chip consumes 32 GPIOs which leads to huge
gaps.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/powerpc/platforms/52xx/Kconfig | 6
arch/powerpc/platforms/52xx/Makefile | 2
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 408 +++++++++++++++++++++++++++++
3 files changed, 416 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_gpio.c
===================================================================
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -0,0 +1,408 @@
+/*
+ * MPC52xx gpio driver
+ *
+ * Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/of.h>
+#include <linux/kernel.h>
+#include <linux/of_gpio.h>
+#include <linux/io.h>
+#include <asm/of_platform.h>
+#include <asm/prom.h>
+#include <asm/gpio.h>
+#include <asm/mpc52xx.h>
+#include <sysdev/fsl_soc.h>
+
+static DEFINE_SPINLOCK(gpio_lock);
+
+/*
+ * GPIO LIB API implementation for wakeup GPIOs.
+ *
+ * There's a maximum of 8 wakeup GPIOs. Which of these are available
+ * for use depends on your board setup.
+ *
+ * 0 -> GPIO_WKUP_7
+ * 1 -> GPIO_WKUP_6
+ * 2 -> PSC6_1
+ * 3 -> PSC6_0
+ * 4 -> ETH_17
+ * 5 -> PSC3_9
+ * 6 -> PSC2_4
+ * 7 -> PSC1_4
+ *
+ */
+static int mpc52xx_wkup_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
+ unsigned int ret;
+
+ ret = (in_8(®s->wkup_ival) >> (7 - gpio)) & 1;
+
+ pr_debug("%s: gpio: %d ret: %d\n", __func__, gpio, ret);
+
+ return ret;
+}
+
+static void mpc52xx_wkup_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc->regs;
+ unsigned int tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ tmp = in_8(®s->wkup_dvo);
+ if (val)
+ tmp |= 1 << (7 - gpio);
+ else
+ tmp &= ~(1 << (7 - gpio));
+ out_8(®s->wkup_dvo, tmp);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+}
+
+static int mpc52xx_wkup_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio_wkup *regs = mm_gc->regs;
+ unsigned int tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ tmp = in_8(®s->wkup_ddr);
+ tmp &= ~(1 << (7 - gpio));
+ out_8(®s->wkup_ddr, tmp);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ return 0;
+}
+
+static int mpc52xx_wkup_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio_wkup *regs = mm_gc->regs;
+ unsigned int tmp;
+ unsigned long flags;
+
+ /* First set initial value */
+ mpc52xx_wkup_gpio_set(gc, gpio, val);
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ /* Then set direction */
+ tmp = in_8(®s->wkup_ddr);
+ tmp |= 1 << (7 - gpio);
+ out_8(®s->wkup_ddr, tmp);
+
+ /* Finally enable the pin */
+ tmp = in_8(®s->wkup_gpioe);
+ tmp |= 1 << (7 - gpio);
+ out_8(®s->wkup_gpioe, tmp);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+
+ return 0;
+}
+
+static int __devinit mpc52xx_wkup_gpiochip_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct of_mm_gpio_chip *mmchip;
+ struct of_gpio_chip *chip;
+
+ mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
+ if (!mmchip)
+ return -ENOMEM;
+
+ chip = &mmchip->of_gc;
+
+ chip->gpio_cells = 2;
+ chip->gc.ngpio = 8;
+ chip->gc.direction_input = mpc52xx_wkup_gpio_dir_in;
+ chip->gc.direction_output = mpc52xx_wkup_gpio_dir_out;
+ chip->gc.get = mpc52xx_wkup_gpio_get;
+ chip->gc.set = mpc52xx_wkup_gpio_set;
+
+ return of_mm_gpiochip_add(ofdev->node, mmchip);
+}
+
+static int mpc52xx_gpiochip_remove(struct of_device *ofdev)
+{
+ return -EBUSY;
+}
+
+static struct of_device_id mpc52xx_wkup_gpiochip_match[] = {
+ {
+ .compatible = "fsl,mpc5200-gpio-wkup",
+ },
+ {}
+};
+
+static struct of_platform_driver mpc52xx_wkup_gpiochip_driver = {
+ .name = "gpio_wkup",
+ .match_table = mpc52xx_wkup_gpiochip_match,
+ .probe = mpc52xx_wkup_gpiochip_probe,
+ .remove = mpc52xx_gpiochip_remove,
+};
+
+/*
+ * GPIO LIB API implementation for simple GPIOs
+ *
+ * There's a maximum of 32 simple GPIOs. Which of these are available
+ * for use depends on your board setup.
+ * The numbering reflects the bit numbering in the port registers:
+ *
+ * 0..1 > reserved
+ * 2..3 > IRDA
+ * 4..7 > ETHR
+ * 8..11 > reserved
+ * 12..15 > USB
+ * 16..17 > reserved
+ * 18..23 > PSC3
+ * 24..27 > PSC2
+ * 28..31 > PSC1
+ */
+static int mpc52xx_simple_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio __iomem *regs = mm_gc->regs;
+ unsigned int ret;
+
+ ret = (in_be32(®s->simple_ival) >> (31 - gpio)) & 1;
+
+ return ret;
+}
+
+static void mpc52xx_simple_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio __iomem *regs = mm_gc->regs;
+ unsigned int tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ tmp = in_be32(®s->simple_dvo);
+ if (val)
+ tmp |= 1 << (31 - gpio);
+ else
+ tmp &= ~(1 << (31 - gpio));
+ out_be32(®s->simple_dvo, tmp);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+}
+
+static int mpc52xx_simple_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio *regs = mm_gc->regs;
+ unsigned int tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ tmp = in_be32(®s->simple_ddr);
+ tmp &= ~(1 << (31 - gpio));
+ out_be32(®s->simple_ddr, tmp);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ return 0;
+}
+
+static int mpc52xx_simple_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpio *regs = mm_gc->regs;
+ unsigned int tmp;
+ unsigned long flags;
+
+ /* First set initial value */
+ mpc52xx_simple_gpio_set(gc, gpio, val);
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ /* Then set direction */
+ tmp = in_be32(®s->simple_ddr);
+ tmp |= 1 << (31 - gpio);
+ out_be32(®s->simple_ddr, tmp);
+
+ /* Finally enable the pin */
+ tmp = in_be32(®s->simple_gpioe);
+ tmp |= 1 << (31 - gpio);
+ out_be32(®s->simple_gpioe, tmp);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+
+ return 0;
+}
+
+static int __devinit mpc52xx_simple_gpiochip_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct of_mm_gpio_chip *mmchip;
+ struct of_gpio_chip *chip;
+
+ mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
+ if (!mmchip)
+ return -ENOMEM;
+
+ chip = &mmchip->of_gc;
+
+ chip->gpio_cells = 2;
+ chip->gc.ngpio = 32;
+ chip->gc.direction_input = mpc52xx_simple_gpio_dir_in;
+ chip->gc.direction_output = mpc52xx_simple_gpio_dir_out;
+ chip->gc.get = mpc52xx_simple_gpio_get;
+ chip->gc.set = mpc52xx_simple_gpio_set;
+
+ return of_mm_gpiochip_add(ofdev->node, mmchip);
+}
+
+static struct of_device_id mpc52xx_simple_gpiochip_match[] = {
+ {
+ .compatible = "fsl,mpc5200-gpio",
+ },
+ {}
+};
+
+static struct of_platform_driver mpc52xx_simple_gpiochip_driver = {
+ .name = "gpio",
+ .match_table = mpc52xx_simple_gpiochip_match,
+ .probe = mpc52xx_simple_gpiochip_probe,
+ .remove = mpc52xx_gpiochip_remove,
+};
+
+/*
+ * GPIO LIB API implementation for gpt GPIOs.
+ *
+ * Each gpt only has a single GPIO.
+ */
+static int mpc52xx_gpt_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
+ unsigned int ret;
+
+ return (in_be32(®s->status) & (1 << (31 - 23))) ? 1 : 0;
+
+ return ret;
+}
+
+static void mpc52xx_gpt_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
+
+ if (val)
+ out_be32(®s->mode, 0x34);
+ else
+ out_be32(®s->mode, 0x24);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+}
+
+static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpt *regs = mm_gc->regs;
+
+ out_be32(®s->mode, 0x04);
+
+ return 0;
+}
+
+static int mpc52xx_gpt_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ mpc52xx_gpt_gpio_set(gc, gpio, val);
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+
+ return 0;
+}
+
+static int __devinit mpc52xx_gpt_gpiochip_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct of_mm_gpio_chip *mmchip;
+ struct of_gpio_chip *chip;
+
+ mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
+ if (!mmchip)
+ return -ENOMEM;
+
+ chip = &mmchip->of_gc;
+
+ chip->gpio_cells = 2;
+ chip->gc.ngpio = 1;
+ chip->gc.direction_input = mpc52xx_gpt_gpio_dir_in;
+ chip->gc.direction_output = mpc52xx_gpt_gpio_dir_out;
+ chip->gc.get = mpc52xx_gpt_gpio_get;
+ chip->gc.set = mpc52xx_gpt_gpio_set;
+
+ return of_mm_gpiochip_add(ofdev->node, mmchip);
+}
+
+static struct of_device_id mpc52xx_gpt_gpiochip_match[] = {
+ {
+ .compatible = "fsl,mpc5200-gpt-gpio",
+ },
+ {}
+};
+
+static struct of_platform_driver mpc52xx_gpt_gpiochip_driver = {
+ .name = "gpio_gpt",
+ .match_table = mpc52xx_gpt_gpiochip_match,
+ .probe = mpc52xx_gpt_gpiochip_probe,
+ .remove = mpc52xx_gpiochip_remove,
+};
+
+static int __init mpc52xx_gpio_init(void)
+{
+ if (of_register_platform_driver(&mpc52xx_wkup_gpiochip_driver))
+ printk(KERN_ERR "Unable to register wakeup GPIO driver\n");
+
+ if (of_register_platform_driver(&mpc52xx_simple_gpiochip_driver))
+ printk(KERN_ERR "Unable to register simple GPIO driver\n");
+
+ if (of_register_platform_driver(&mpc52xx_gpt_gpiochip_driver))
+ printk(KERN_ERR "Unable to register gpt GPIO driver\n");
+
+ return 0;
+}
+
+
+/* Make sure we get initialised before anyone else tries to use us */
+subsys_initcall(mpc52xx_gpio_init);
+
+/* No exit call at the moment as we cannot unregister of gpio chips */
+
+MODULE_DESCRIPTION("Freescale MPC52xx gpio driver");
+MODULE_AUTHOR("Sascha Hauer <s.hauer@pengutronix.de");
+MODULE_LICENSE("GPL v2");
+
Index: arch/powerpc/platforms/52xx/Kconfig
===================================================================
--- a/arch/powerpc/platforms/52xx/Kconfig.orig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -44,3 +44,9 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
+config PPC_MPC5200_GPIO
+ bool "MPC5200 GPIO support"
+ depends on PPC_MPC52xx
+ select HAVE_GPIO_LIB
+ help
+ Enable gpiolib support for mpc5200 based boards
Index: arch/powerpc/platforms/52xx/Makefile
===================================================================
--- a/arch/powerpc/platforms/52xx/Makefile.orig
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -14,3 +14,5 @@ obj-$(CONFIG_PM) += mpc52xx_sleep.o mpc
ifeq ($(CONFIG_PPC_LITE5200),y)
obj-$(CONFIG_PM) += lite5200_sleep.o lite5200_pm.o
endif
+
+obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
\ No newline at end of file
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* Re: missing current-speed property prevents autoconsole on pegasos
From: Matt Sealey @ 2008-04-24 15:42 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080423152206.GA10935@aepfle.de>
Why not just have users who wish to use console serial port autodetection
add 3 lines to their nvramrc?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Olaf Hering wrote:
> Pegasos2 has no current-speed property in
> /pci@80000000/isa@C/serial@i2F8. As a result, console=ttyS0,115200 is
> still required unless the patch below is used.
>
> What is the correct way to restore console detection on pegasos2?
>
> Index: linux-2.6.25-pegasos/arch/powerpc/platforms/chrp/setup.c
> ===================================================================
> --- linux-2.6.25-pegasos.orig/arch/powerpc/platforms/chrp/setup.c
> +++ linux-2.6.25-pegasos/arch/powerpc/platforms/chrp/setup.c
> @@ -302,7 +305,7 @@ static void chrp_init_early(void)
> if (!property)
> goto out_put;
> if (!strcmp(property, "failsafe") || !strcmp(property, "serial"))
> - add_preferred_console("ttyS", 0, NULL);
> + add_preferred_console("ttyS", 0, "115200");
> out_put:
> of_node_put(node);
> }
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 00/10] powerpc: Add kexec/kdump support for ppc32
From: Dale Farnsworth @ 2008-04-24 15:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C695814A-E9D5-4C62-81DF-E49127ECD2E0@kernel.crashing.org>
On Thu, Apr 24, 2008 at 07:50:52AM -0500, Kumar Gala wrote:
> On Nov 22, 2007, at 9:42 AM, Dale Farnsworth wrote:
>> This patch series adds kexec and kdump support for ppc32 in arch/
>> powerpc.
>> It has been successfully tested on the mpc8548_cds and prpmc2800
>> platforms.
>> Mark Greer and I are preparing patches to the kexec-tools package as
>> well.
>
> Dale, can you look at updating your patchset now that we've made some
> progress on other patches.
Yes. It'll take a couple of weeks for me to fit it in though.
-Dale
^ permalink raw reply
* Re: mpc5200b custom board upstreamable?
From: Sascha Hauer @ 2008-04-24 15:53 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804240813p66889769y3bee6eb0111741f7@mail.gmail.com>
On Thu, Apr 24, 2008 at 09:13:45AM -0600, Grant Likely wrote:
> On Thu, Apr 24, 2008 at 9:12 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > Hi all,
> >
> > I had the intention to push the code for a custom mpc5200b board (freely
> > available, no internal project) upstream. After cleaning up the code I
> > realized that actually no board specific code is left and our board is
> > well handled by the mpc5200_simple_platform machine.
> >
> > The only issue is that the machine only matches things like
> > "schindler,cm5200", there's no generic entry. Would it be possible to
> > add a "generic-mpc52xx" entry to this list?
>
> I'm being cautious about this for the time being. I'd like to have a
> generic match mechanism, but I don't want to do something that isn't
> easy to recover from if it turns out to be brain dead. For now, just
> add your board name to the explicit match list.
The board is called "generic". No, just kidding ;)
>
> >
> > Another question: are defconfig and dts files for custom boards acceptable
> > for upstream?
>
> Yes, in the arch/powerpc/configs/52xx/ directory.
ok
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* Re: SecretLab 2.6.24 with USB
From: Aaron Sells @ 2008-04-24 16:04 UTC (permalink / raw)
To: Peter Korsgaard, sam.d.karp; +Cc: linuxppc-embedded
In-Reply-To: <87iqy8haf8.fsf@macbook.be.48ers.dk>
[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]
Peter Korsgaard wrote:
> I don't see anything with platform devices for the c67x00 driver.
I added the relevant struct information. The patch is attached.
> Either you do this by hand or you
> create XPAR_* macros which take the needed info out of xparameter.h
> (sorry, I don't have an xparameters.h with those defines at hand).
I generate the xparameters_ml403.h file using Xilinx's EDK base system
builder wizard. However, the wizard does not automatically enable the
Cypress device to be interrupt driven. I have manually done this as
described in the attached patch.
The resulting xparameters_ml403.h has the following defines:
sellsa@SS-SBIR-Ubuntu:~/spacesuit/linux-2.6-xlnx$ cat
arch/ppc/platforms/4xx/xparameters/xparameters_ml403.h | grep USB
/* Definitions for peripheral CYPRESS_USB */
#define XPAR_CYPRESS_USB_PRH0_BASEADDR 0x80800000
#define XPAR_CYPRESS_USB_PRH0_HIGHADDR 0x8080FFFF
#define XPAR_SYSTEM_USB_INT_PIN_MASK 0X000001
#define XPAR_XPS_INTC_0_SYSTEM_USB_INT_PIN_INTR 0
When I boot the Xilinx ML403 board up, I get the following:
[ 9.256329] ------------[ cut here ]------------
[ 9.260000] Badness at drivers/usb/c67x00/c67x00-ll-hpi.c:244
[ 9.260000] NIP: c01b5d6c LR: c01b5d60 CTR: c00170f4
[ 9.260000] REGS: c3c19d70 TRAP: 0700 Not tainted
(2.6.24-rc8-xlnx-dirty)
[ 9.260000] MSR: 00029030 <EE,ME,IR,DR> CR: 24000082 XER: 20000073
[ 9.260000] TASK = c3c178a0[1] 'swapper' THREAD: c3c18000
[ 9.260000] GPR00: 00000001 c3c19e20 c3c178a0 00000000 c032f518
c0372730 27b38fa6 00000001
[ 9.260000] GPR08: 00000000 00200200 c3d2b164 c3d2b164 24000082
ffffcd64 c02d4c5c c02d4c6c
[ 9.260000] GPR16: c02d4c90 c02d4c98 c02d4ca8 c02d4cd4 c02d4ce8
00000000 c02d7114 c0370e78
[ 9.260000] GPR24: c0360000 c02d4c54 c0330724 00000000 c3d2b148
00000000 c3d2b140 c0330708
[ 9.260000] NIP [c01b5d6c] c67x00_ll_reset+0x48/0x88
[ 9.260000] LR [c01b5d60] c67x00_ll_reset+0x3c/0x88
[ 9.260000] Call Trace:
[ 9.260000] [c3c19e20] [c01b5d60] c67x00_ll_reset+0x3c/0x88 (unreliable)
[ 9.260000] [c3c19e40] [c02885e0] c67x00_drv_probe+0x16c/0x2d8
[ 9.260000] [c3c19e70] [c01694b0] platform_drv_probe+0x20/0x30
[ 9.260000] [c3c19e80] [c01674f8] driver_probe_device+0xec/0x194
[ 9.260000] [c3c19ea0] [c0167750] __driver_attach+0x88/0xf4
[ 9.260000] [c3c19ec0] [c0166648] bus_for_each_dev+0x58/0x98
[ 9.260000] [c3c19ef0] [c01672f4] driver_attach+0x24/0x34
[ 9.260000] [c3c19f00] [c016706c] bus_add_driver+0xb4/0x218
[ 9.260000] [c3c19f20] [c0167a64] driver_register+0x78/0x10c
[ 9.260000] [c3c19f40] [c016982c] platform_driver_register+0x9c/0xac
[ 9.260000] [c3c19f50] [c035fa44] c67x00_init+0x18/0x28
[ 9.260000] [c3c19f60] [c034e200] kernel_init+0xfc/0x294
[ 9.260000] [c3c19ff0] [c00047d8] kernel_thread+0x44/0x60
[ 9.260000] Instruction dump:
[ 9.260000] 90010024 480d56c5 38800000 7fa3eb78 6084fa50 4bfff2f5
387d0020 388004e2
[ 9.260000] 480d48d9 707dffff 7c000026 54001ffe <0f000000> 3c00ffff
7fbd00d0 60000005
[ 11.316192] c67x00 c67x00.0: Device reset failed
[ 11.364172] c67x00: probe of c67x00.0 failed with error 65531
Sam, since you have this working, any help would be greatly appreciated.
What else do I need to do in order to get USB host working on this board?
[-- Attachment #2: virtex_devices.c.patch --]
[-- Type: text/plain, Size: 1551 bytes --]
--- arch/ppc/syslib/virtex_devices.c.old 2008-04-24 11:37:03.000000000 -0400
+++ arch/ppc/syslib/virtex_devices.c 2008-04-24 11:10:09.000000000 -0400
@@ -18,6 +18,7 @@
#include <syslib/virtex_devices.h>
#include <platforms/4xx/xparameters/xparameters.h>
#include <linux/xilinx_devices.h>
+#include <linux/usb/c67x00.h>
#include <asm/io.h>
/*
@@ -320,6 +321,31 @@
}, \
}
+/*
+ * Cypress USB C67x00 shortcut macro for single instance
+ */
+#define XPAR_C67x00_USB(num) { \
+ .name = "c67x00", \
+ .id = num, \
+ .num_resources = 2, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_CYPRESS_USB_PRH0_BASEADDR, \
+ .end = XPAR_CYPRESS_USB_PRH0_BASEADDR + 0xf, \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = XPAR_XPS_INTC_0_SYSTEM_USB_INT_PIN_INTR, \
+ .end = XPAR_XPS_INTC_0_SYSTEM_USB_INT_PIN_INTR, \
+ .flags = IORESOURCE_IRQ, \
+ }, \
+ }, \
+ .dev.platform_data = &(struct c67x00_platform_data) { \
+ .sie_config = C67X00_SIE1_HOST | C67X00_SIE2_PERIPHERAL, \
+ .hpi_regstep = 0x02, /* A0 not connected on 16bit bus */ \
+ }, \
+}
+
/* UART 8250 driver platform data table */
struct plat_serial8250_port virtex_serial_platform_data[] = {
#if defined(XPAR_UARTNS550_0_BASEADDR)
@@ -511,6 +537,13 @@
#if defined(XPAR_OPB_AC97_CONTROLLER_REF_1_BASEADDR)
XPAR_AC97_CONTROLLER_REFERENCE(1),
#endif
+
+#if defined(XPAR_CYPRESS_USB_PRH0_BASEADDR)
+ XPAR_C67x00_USB(0),
+#endif
+#if defined(XPAR_CYPRESS_USB_PRH1_BASEADDR)
+ XPAR_C67x00_USB(1),
+#endif
};
/* Early serial support functions */
[-- Attachment #3: XilinxEDKUSBInterrupts.patch --]
[-- Type: text/plain, Size: 1652 bytes --]
diff -Naur ml403project.old/data/system.ucf ml403project/data/system.ucf
--- ml403project.old/data/system.ucf 2008-04-24 11:29:30.000000000 -0400
+++ ml403project/data/system.ucf 2008-04-24 11:28:04.000000000 -0400
@@ -599,6 +599,10 @@
Net fpga_0_FLASH_Mem_CE_pin<0> SLEW = FAST;
Net fpga_0_FLASH_Mem_CE_pin<0> DRIVE = 8;
+###NET USB interrupt
+Net USB_INT_pin LOC=V5;
+Net USB_INT_pin IOSTANDARD = LVCMOS33;
+
#### New GMAC Coregen Derived Constraints
NET "*tx_gmii_mii_clk*" TNM_NET = "clk_phy_tx_clk0";
diff -Naur ml403project.old/system.mhs ml403project/system.mhs
--- ml403project.old/system.mhs 2008-04-24 11:29:08.000000000 -0400
+++ ml403project/system.mhs 2008-04-24 11:28:29.000000000 -0400
@@ -18,6 +18,7 @@
PARAMETER VERSION = 2.1.0
+ PORT USB_INT_pin = USB_INT, DIR = I
PORT fpga_0_RS232_Uart_RX_pin = fpga_0_RS232_Uart_RX, DIR = I
PORT fpga_0_RS232_Uart_TX_pin = fpga_0_RS232_Uart_TX, DIR = O
PORT fpga_0_LEDs_4Bit_GPIO_IO_pin = fpga_0_LEDs_4Bit_GPIO_IO, DIR = IO, VEC = [0:3]
@@ -421,6 +422,6 @@
PARAMETER C_HIGHADDR = 0x8180ffff
BUS_INTERFACE SPLB = plb
PORT Irq = EICC405EXTINPUTIRQ
- PORT Intr = RS232_Uart_Interrupt & LEDs_4Bit_IP2INTC_Irpt & LEDs_Positions_IP2INTC_Irpt & Push_Buttons_Position_IP2INTC_Irpt & IIC_EEPROM_IIC2INTC_Irpt & TriMode_MAC_GMII_TemacIntc0_Irpt & xps_timer_1_Interrupt & TriMode_MAC_GMII_fifo_IP2INTC_Irpt
+ PORT Intr = RS232_Uart_Interrupt & LEDs_4Bit_IP2INTC_Irpt & LEDs_Positions_IP2INTC_Irpt & Push_Buttons_Position_IP2INTC_Irpt & IIC_EEPROM_IIC2INTC_Irpt & TriMode_MAC_GMII_TemacIntc0_Irpt & xps_timer_1_Interrupt & TriMode_MAC_GMII_fifo_IP2INTC_Irpt & USB_INT
END
^ permalink raw reply
* Re: mpc5200b custom board upstreamable?
From: Grant Likely @ 2008-04-24 16:07 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080424155303.GK6692@pengutronix.de>
On Thu, Apr 24, 2008 at 9:53 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Thu, Apr 24, 2008 at 09:13:45AM -0600, Grant Likely wrote:
> > On Thu, Apr 24, 2008 at 9:12 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > >
> > > Hi all,
> > >
> > > I had the intention to push the code for a custom mpc5200b board (freely
> > > available, no internal project) upstream. After cleaning up the code I
> > > realized that actually no board specific code is left and our board is
> > > well handled by the mpc5200_simple_platform machine.
> > >
> > > The only issue is that the machine only matches things like
> > > "schindler,cm5200", there's no generic entry. Would it be possible to
> > > add a "generic-mpc52xx" entry to this list?
> >
> > I'm being cautious about this for the time being. I'd like to have a
> > generic match mechanism, but I don't want to do something that isn't
> > easy to recover from if it turns out to be brain dead. For now, just
> > add your board name to the explicit match list.
>
> The board is called "generic". No, just kidding ;)
/me slaps Sascha
Seriously though; I do intend to fix this, but I don't think adding a
generic entry to the compatible list is the right way to do it. For
example, what would "mpc5200-generic" really mean anyway? Convention
for usage of 'compatible' would indicate that it means the *entire
board* is compatible (obviously not true). The use-case you're
talking about is simply "the board uses a 5200 and firmware is sane".
On the other hand, I may just be overthinking things and compatible is
the most appropriate place to specify that the board is a mpc5200
based board. (please feel free to argue with my; my opinion can
probably be swayed... attaching promises of beer to your argument is
probably an effective strategy)
This is an issue that probably affects the other embedded platforms
too, so it would be nice to agree on a common method of handling it.
Regardless, whatever method is chosen, it is also important that it is
always possible for board specific fixups to override the generic
behavior.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* EABI
From: Brian Silverman @ 2008-04-24 16:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Is it possible to compile a Linux application using an EABI compiler
(specfically, Xilinx's EDK powerpc-eabi-gcc.exe)?
The issue at hand is that we'd like for our customers to be able to use
the Xilinx EDK toolchain (which we know they will have) to compile Linx
apps without having to install another toolchain (crosstool, ELDK, etc).
So, what I'm hoping is that the EDK toolchain can be configured to be
Linux compatible binaries, or that there is some kind of wrapper that
will handle the incompatible interfaces. Searching around, I've seen
some mention of Linux EABI compatibility (for Debian ARM releases), but
I haven't found any clear concensus...
P.S. My apologies if this message appears on the mailing list twice...
--
Brian Silverman
Concept X, LLC
[-- Attachment #2: Type: text/html, Size: 1347 bytes --]
^ permalink raw reply
* Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32
From: Kumar Gala @ 2008-04-24 16:25 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1209048813.9060.192.camel@pasglop>
On Apr 24, 2008, at 9:53 AM, Benjamin Herrenschmidt wrote:
>
> On Thu, 2008-04-24 at 07:59 -0500, Kumar Gala wrote:
>> I'm going to change it to be just lmb_alloc() so it will be difficult
>> to share with ppc64 (other than w/an ifdef).
>
> Unless we change lmb_alloc to just be an lmb_alloc_base with 0 and
> have
> the later do the right thing ?
don't follow. Look at the "real" patch and comment on that.
> You don't put highmem in the LMBs ? If you do, we do need to have the
> max lowmem there no ?
we restrict lmb alloc via LMB_REAL_LIMIT in include/asm-powerpc/lmb.h
- k
^ permalink raw reply
* Re: mpc5200b custom board upstreamable?
From: Sascha Hauer @ 2008-04-24 16:28 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <fa686aa40804240907w7e36b579y4d2c63f00dd30848@mail.gmail.com>
On Thu, Apr 24, 2008 at 10:07:20AM -0600, Grant Likely wrote:
> On Thu, Apr 24, 2008 at 9:53 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Thu, Apr 24, 2008 at 09:13:45AM -0600, Grant Likely wrote:
> > > On Thu, Apr 24, 2008 at 9:12 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I had the intention to push the code for a custom mpc5200b board (freely
> > > > available, no internal project) upstream. After cleaning up the code I
> > > > realized that actually no board specific code is left and our board is
> > > > well handled by the mpc5200_simple_platform machine.
> > > >
> > > > The only issue is that the machine only matches things like
> > > > "schindler,cm5200", there's no generic entry. Would it be possible to
> > > > add a "generic-mpc52xx" entry to this list?
> > >
> > > I'm being cautious about this for the time being. I'd like to have a
> > > generic match mechanism, but I don't want to do something that isn't
> > > easy to recover from if it turns out to be brain dead. For now, just
> > > add your board name to the explicit match list.
> >
> > The board is called "generic". No, just kidding ;)
>
> /me slaps Sascha
>
> Seriously though; I do intend to fix this, but I don't think adding a
> generic entry to the compatible list is the right way to do it. For
> example, what would "mpc5200-generic" really mean anyway? Convention
> for usage of 'compatible' would indicate that it means the *entire
> board* is compatible (obviously not true). The use-case you're
> talking about is simply "the board uses a 5200 and firmware is sane".
> On the other hand, I may just be overthinking things and compatible is
> the most appropriate place to specify that the board is a mpc5200
> based board. (please feel free to argue with my; my opinion can
> probably be swayed... attaching promises of beer to your argument is
> probably an effective strategy)
At the moment my compatible entry looks like this:
compatible = "phytec,pcm030","generic-mpc52xx";
What I think would be nice is that "phytec,pcm030" support is used
when available and "generic-mpc52xx" as a fallback. We do not have any
platform specific hacks at the moment, but we may have later. Having
"phytec,pcm030" in the simple machine would prevent us from doing so.
>
> This is an issue that probably affects the other embedded platforms
> too, so it would be nice to agree on a common method of handling it.
>
> Regardless, whatever method is chosen, it is also important that it is
> always possible for board specific fixups to override the generic
> behavior.
agreed
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* Re: [PATCH 00/10] powerpc: Add kexec/kdump support for ppc32
From: Kumar Gala @ 2008-04-24 16:28 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20080424154258.GA25852@farnsworth.org>
On Apr 24, 2008, at 10:42 AM, Dale Farnsworth wrote:
> On Thu, Apr 24, 2008 at 07:50:52AM -0500, Kumar Gala wrote:
>> On Nov 22, 2007, at 9:42 AM, Dale Farnsworth wrote:
>>> This patch series adds kexec and kdump support for ppc32 in arch/
>>> powerpc.
>>> It has been successfully tested on the mpc8548_cds and prpmc2800
>>> platforms.
>>> Mark Greer and I are preparing patches to the kexec-tools package as
>>> well.
>>
>> Dale, can you look at updating your patchset now that we've made some
>> progress on other patches.
>
> Yes. It'll take a couple of weeks for me to fit it in though.
no problem. I figure we are aiming for 2.6.27 for this functionality.
- k
^ permalink raw reply
* [PATCH] [POWERPC] spufs: add .gitignore for spu_save_dump.h & spu_restore_dump.h
From: Kumar Gala @ 2008-04-24 16:37 UTC (permalink / raw)
To: jk, Paul Mackerras; +Cc: linuxppc-dev
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/cell/spufs/.gitignore | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/spufs/.gitignore
diff --git a/arch/powerpc/platforms/cell/spufs/.gitignore b/arch/powerpc/platforms/cell/spufs/.gitignore
new file mode 100644
index 0000000..a09ee8d
--- /dev/null
+++ b/arch/powerpc/platforms/cell/spufs/.gitignore
@@ -0,0 +1,2 @@
+spu_save_dump.h
+spu_restore_dump.h
--
1.5.4.1
^ permalink raw reply related
* [PATCH] [POWERPC] Update .gitignore file
From: Kumar Gala @ 2008-04-24 16:39 UTC (permalink / raw)
To: linuxppc-dev
Update .gitignore for zImage.iseries
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 5ef2bdf..2347294 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -27,6 +27,7 @@ zImage.chrp
zImage.coff
zImage.coff.lds
zImage.ep*
+zImage.iseries
zImage.*lds
zImage.miboot
zImage.pmac
--
1.5.4.1
^ permalink raw reply related
* Re: EABI
From: Kumar Gala @ 2008-04-24 16:45 UTC (permalink / raw)
To: Brian Silverman; +Cc: linuxppc-embedded
In-Reply-To: <4810B196.7000300@conceptxdesign.com>
On Apr 24, 2008, at 11:13 AM, Brian Silverman wrote:
> Is it possible to compile a Linux application using an EABI compiler
> (specfically, Xilinx's EDK powerpc-eabi-gcc.exe)?
>
> The issue at hand is that we'd like for our customers to be able to
> use the Xilinx EDK toolchain (which we know they will have) to
> compile Linx apps without having to install another toolchain
> (crosstool, ELDK, etc).
>
> So, what I'm hoping is that the EDK toolchain can be configured to
> be Linux compatible binaries, or that there is some kind of wrapper
> that will handle the incompatible interfaces. Searching around,
> I've seen some mention of Linux EABI compatibility (for Debian ARM
> releases), but I haven't found any clear concensus...
>
> P.S. My apologies if this message appears on the mailing list twice...
The EABI and Linux ABI are not compatible and if you want to link with
any libraries you will need a different compiler for linux.
- k
^ permalink raw reply
* Re: EABI
From: Grant Likely @ 2008-04-24 16:50 UTC (permalink / raw)
To: Brian Silverman; +Cc: linuxppc-embedded
In-Reply-To: <4810B196.7000300@conceptxdesign.com>
On Thu, Apr 24, 2008 at 10:13 AM, Brian Silverman
<bsilverman@conceptxdesign.com> wrote:
>
>
> Is it possible to compile a Linux application using an EABI compiler
> (specfically, Xilinx's EDK powerpc-eabi-gcc.exe)?
>
> The issue at hand is that we'd like for our customers to be able to use the
> Xilinx EDK toolchain (which we know they will have) to compile Linx apps
> without having to install another toolchain (crosstool, ELDK, etc).
>
> So, what I'm hoping is that the EDK toolchain can be configured to be Linux
> compatible binaries, or that there is some kind of wrapper that will handle
> the incompatible interfaces. Searching around, I've seen some mention of
> Linux EABI compatibility (for Debian ARM releases), but I haven't found any
> clear concensus...
>
> P.S. My apologies if this message appears on the mailing list twice...
Unfortunately, no.
I recommend making use of the ELDK toolchain from Denx.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] [POWERPC] bootwrapper: fix build error on virtex405-head.S
From: Grant Likely @ 2008-04-24 17:33 UTC (permalink / raw)
To: linuxppc-dev, jwboyer, paulus
From: Grant Likely <grant.likely@secretlab.ca>
virtex405-head.S is an assembler file, not a C file; therefore BOOTAFLAGS
is the correct place to set the needed -mcpu=405 flag.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Paul, Josh;
This is a bug fix required in .26 ASAP.
Cheers,
g.
arch/powerpc/boot/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 5ba50c6..7822d25 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,7 +40,7 @@ $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
-$(obj)/virtex405-head.o: BOOTCFLAGS += -mcpu=405
+$(obj)/virtex405-head.o: BOOTAFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
^ permalink raw reply related
* [RFCv2 POWERPC] booting-without-of: bindings for FHCI USB, GPIO LEDs, MCU, and NAND on UPM
From: Anton Vorontsov @ 2008-04-24 17:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <20080422194135.GA27822@polina.dev.rtsoft.ru>
On Tue, Apr 22, 2008 at 11:41:35PM +0400, Anton Vorontsov wrote:
> Hi all,
>
> Here is purposed bindings draft for the new drivers that I would like to
> send for this or next merge window, depending on results of this RFC. ;-)
> (The new bindings needs to be in-tree or at least Acked before I could
> send the drivers.)
>
> Comments and suggestions are highly appreciated.
Much thanks for the comments on previous version. Here is the new one,
please speak up if there is anything I could improve.
Thanks in advance.
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index c350623..b560dc5 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -59,6 +59,10 @@ Table of Contents
p) Freescale Synchronous Serial Interface
q) USB EHCI controllers
r) Freescale General-purpose Timers Module
+ s) Freescale QUICC Engine USB Controller
+ t) LEDs on GPIOs
+ u) Freescale MCU with MPC8349E-mITX compatible firmware
+ v) NAND on UPM-driven Freescale Localbus
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@@ -2866,6 +2870,128 @@ platforms are moved over to use the flattened-device-tree model.
clock-frequency = <0>;
};
+ s) Freescale QUICC Engine USB Controller
+
+ Required properties:
+ - compatible : should be "fsl,<chip>-qe-usb", "fsl,mpc8323-qe-usb";
+ - reg : the first two cells should contain gtm registers location and
+ length, the next two two cells should contain PRAM location and
+ length.
+ - interrupts : should contain USB interrupt.
+ - interrupt-parent : interrupt source phandle.
+ - fsl,fullspeed-clock : specifies the full speed USB clock source in
+ "clk<num>" or "brg<num>" format.
+ - fsl,lowspeed-clock : specifies the low speed USB clock source in
+ "clk<num>" or "brg<num>" format.
+ - fsl,usb-mode : should be "host".
+ - linux,hub-power-budget : optional, USB power budget for the root hub
+ in mA.
+ - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
+ USBRN, SPEED (optional), and POWER (optional).
+
+ Example:
+
+ usb@6c0 {
+ compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb";
+ reg = <0x6c0 0x40 0x8b00 0x100>;
+ interrupts = <11>;
+ interrupt-parent = <&qeic>;
+ fsl,fullspeed-clock = "clk21";
+ fsl,usb-mode = "host";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+ &qe_pio_b 3 0 /* USBTP */
+ &qe_pio_b 8 0 /* USBTN */
+ &qe_pio_b 9 0 /* USBRP */
+ &qe_pio_b 11 0 /* USBRN */
+ &qe_pio_e 20 0 /* SPEED */
+ &qe_pio_e 21 0 /* POWER */>;
+ };
+
+ t) LEDs on GPIOs
+
+ Required properties:
+ - compatible : should be "linux,gpio-led".
+ - linux,name : LED name.
+ - linux,active-low : property should be present if LED wired as
+ active-low.
+ - linux,default-trigger : Linux default trigger for this LED.
+ - linux,brightness : default brightness.
+ - gpios : should specify LED GPIO.
+
+ Example:
+
+ led@0 {
+ compatible = "linux,gpio-led";
+ linux,name = "pwr";
+ linux,brightness = <1>;
+ linux,active-low;
+ gpios = <&mcu_pio 0>;
+ };
+
+ led@1 {
+ compatible = "linux,gpio-led";
+ linux,name = "hdd";
+ linux,default-trigger = "ide-disk";
+ linux,active-low;
+ gpios = <&mcu_pio 1>;
+ };
+
+ u) Freescale MCU with MPC8349E-mITX compatible firmware
+
+ Required properties:
+ - compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx";
+ - reg : should specify I2C address (0x0a).
+ - #address-cells : should be 0.
+ - #size-cells : should be 0.
+ - #gpio-cells : should be 2.
+ - gpio-controller : should be present;
+
+ Example:
+
+ mcu_pio: mcu@0a {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8349emitx",
+ "fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
+
+ v) Freescale Localbus UPM programmed to work with NAND flash
+
+ Required properties:
+ - #address-cells : should be 0;
+ - #size-cells : should be 0;
+ - compatible : "fsl,upm-nand".
+ - reg : should specify localbus chip select and size used for the chip.
+ - fsl,upm-addr-offset : UPM pattern offset for the address latch.
+ - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
+ - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
+
+ Example:
+
+ upm@1,0 {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ compatible = "fsl,upm-nand";
+ reg = <1 0 1>;
+ fsl,upm-addr-offset = <16>;
+ fsl,upm-cmd-offset = <8>;
+ gpios = <&qe_pio_e 18 0>;
+
+ flash {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "stmicro,NAND512W3A2BN6E";
+
+ partition@0 {
+ ...
+ };
+ };
+ };
+
VII - Marvell Discovery mv64[345]6x System Controller chips
===========================================================
^ permalink raw reply related
* Re: SecretLab 2.6.24 with USB
From: Peter Korsgaard @ 2008-04-24 18:25 UTC (permalink / raw)
To: Aaron Sells; +Cc: sam.d.karp, linuxppc-embedded
In-Reply-To: <4810AF87.80602@zin-tech.com>
>>>>> "Aaron" == Aaron Sells <aaron.sells@zin-tech.com> writes:
Hi,
Aaron> I generate the xparameters_ml403.h file using Xilinx's EDK base system
Aaron> builder wizard. However, the wizard does not automatically enable the
Aaron> Cypress device to be interrupt driven. I have manually done this as
Aaron> described in the attached patch.
Aaron> The resulting xparameters_ml403.h has the following defines:
Aaron> sellsa@SS-SBIR-Ubuntu:~/spacesuit/linux-2.6-xlnx$ cat
Aaron> arch/ppc/platforms/4xx/xparameters/xparameters_ml403.h | grep USB
Aaron> /* Definitions for peripheral CYPRESS_USB */
Aaron> #define XPAR_CYPRESS_USB_PRH0_BASEADDR 0x80800000
Aaron> #define XPAR_CYPRESS_USB_PRH0_HIGHADDR 0x8080FFFF
Aaron> #define XPAR_SYSTEM_USB_INT_PIN_MASK 0X000001
Aaron> #define XPAR_XPS_INTC_0_SYSTEM_USB_INT_PIN_INTR 0
Ok.
Aaron> When I boot the Xilinx ML403 board up, I get the following:
Aaron> [ 9.256329] ------------[ cut here ]------------
Aaron> [ 9.260000] Badness at drivers/usb/c67x00/c67x00-ll-hpi.c:244
Aaron> [ 9.260000] NIP: c01b5d6c LR: c01b5d60 CTR: c00170f4
Aaron> [ 9.260000] REGS: c3c19d70 TRAP: 0700 Not tainted
Aaron> (2.6.24-rc8-xlnx-dirty)
Aaron> [ 9.260000] MSR: 00029030 <EE,ME,IR,DR> CR: 24000082 XER: 20000073
Aaron> [ 9.260000] TASK = c3c178a0[1] 'swapper' THREAD: c3c18000
Aaron> [ 9.260000] GPR00: 00000001 c3c19e20 c3c178a0 00000000 c032f518
Aaron> c0372730 27b38fa6 00000001
Aaron> [ 9.260000] GPR08: 00000000 00200200 c3d2b164 c3d2b164 24000082
Aaron> ffffcd64 c02d4c5c c02d4c6c
Aaron> [ 9.260000] GPR16: c02d4c90 c02d4c98 c02d4ca8 c02d4cd4 c02d4ce8
Aaron> 00000000 c02d7114 c0370e78
Aaron> [ 9.260000] GPR24: c0360000 c02d4c54 c0330724 00000000 c3d2b148
Aaron> 00000000 c3d2b140 c0330708
Aaron> [ 9.260000] NIP [c01b5d6c] c67x00_ll_reset+0x48/0x88
Aaron> [ 9.260000] LR [c01b5d60] c67x00_ll_reset+0x3c/0x88
Aaron> [ 9.260000] Call Trace:
Aaron> [ 9.260000] [c3c19e20] [c01b5d60] c67x00_ll_reset+0x3c/0x88 (unreliable)
This is an interrupt timeout. It seems like the interrupt isn't
correctly connected.
Aaron> Sam, since you have this working, any help would be greatly
Aaron> appreciated. What else do I need to do in order to get USB host
Aaron> working on this board?
That should be about it.
Aaron> +/*
Aaron> + * Cypress USB C67x00 shortcut macro for single instance
Aaron> + */
Aaron> +#define XPAR_C67x00_USB(num) { \
Aaron> + .name = "c67x00", \
Aaron> + .id = num, \
Aaron> + .num_resources = 2, \
Aaron> + .resource = (struct resource[]) { \
Aaron> + { \
Aaron> + .start = XPAR_CYPRESS_USB_PRH0_BASEADDR, \
Aaron> + .end = XPAR_CYPRESS_USB_PRH0_BASEADDR + 0xf, \
Aaron> + .flags = IORESOURCE_MEM, \
Aaron> + }, \
Aaron> + { \
Aaron> + .start = XPAR_XPS_INTC_0_SYSTEM_USB_INT_PIN_INTR, \
Aaron> + .end = XPAR_XPS_INTC_0_SYSTEM_USB_INT_PIN_INTR, \
Aaron> + .flags = IORESOURCE_IRQ, \
Aaron> + }, \
Aaron> + }, \
I guess you need to add a few "num" to those defines to make it work
with multiple devices.
--
Bye, Peter Korsgaard
^ 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