* Re: How to add user at linux 2.4.25 with eldk 3.1.1
From: Debora Liu @ 2005-09-21 2:56 UTC (permalink / raw)
To: 徐小威的EMAIL; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
Hello, ÐìСÍþµÄEMAIL
In message <2005-09-21 10:07:25 rober@opnet.com.tw> you wrote:
> How to add a new user at 2.4.25 linux. I used nfs as filesystem
email to www.linux.org
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@sinovee.com
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-09-21
^ permalink raw reply
* How to add user at linux 2.4.25 with eldk 3.1.1
From: 徐小威的EMAIL @ 2005-09-21 2:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi all:
I used 2.4.25 linux at my custom 852T board, I can telnet into
linux with root user and password is empty. But can't login ftp with
same id and password.
How to add a new user at 2.4.25 linux. I used nfs as filesystem
(/opt/eldk/ppc_8xx).
bash-2.05b# ftp 10.0.14.120
Connected to 10.0.14.120 (10.0.14.120).
220 10.0.14.120 FTP server (Version wu-2.6.1(1) Tue Jun 7 14:51:02 MEST
2005) ready.
Name (10.0.14.120:root): root
331 Password required for root.
Password:
530 Login incorrect.
Login failed.
Best Regards,
Rober Hsu
^ permalink raw reply
* [PATCH] powerpc: merge include/asm-ppc*/statfs.h into include/asm-powerpc/statfs.h
From: Kumar Gala @ 2005-09-20 21:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 1288b50c0dd4747595c5e73dbff02088d8eeefcc
tree a721d4dbd9605cacb1bf0ab601515c3e57db7330
parent cb3e61d8491f6395a007687d9908bdb20fc9a0b5
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 20 Sep 2005 16:48:42 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 20 Sep 2005 16:48:42 -0500
include/asm-powerpc/statfs.h | 60 +++++++++++++++++++++++++++++++++++++++++
include/asm-ppc/statfs.h | 8 ------
include/asm-ppc64/statfs.h | 61 ------------------------------------------
3 files changed, 60 insertions(+), 69 deletions(-)
diff --git a/include/asm-powerpc/statfs.h b/include/asm-powerpc/statfs.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/statfs.h
@@ -0,0 +1,60 @@
+#ifndef _ASM_POWERPC_STATFS_H
+#define _ASM_POWERPC_STATFS_H
+
+/* For ppc32 we just use the generic definitions, not so simple on ppc64 */
+
+#ifndef __powerpc64__
+#include <asm-generic/statfs.h>
+#else
+
+#ifndef __KERNEL_STRICT_NAMES
+#include <linux/types.h>
+typedef __kernel_fsid_t fsid_t;
+#endif
+
+/*
+ * We're already 64-bit, so duplicate the definition
+ */
+struct statfs {
+ long f_type;
+ long f_bsize;
+ long f_blocks;
+ long f_bfree;
+ long f_bavail;
+ long f_files;
+ long f_ffree;
+ __kernel_fsid_t f_fsid;
+ long f_namelen;
+ long f_frsize;
+ long f_spare[5];
+};
+
+struct statfs64 {
+ long f_type;
+ long f_bsize;
+ long f_blocks;
+ long f_bfree;
+ long f_bavail;
+ long f_files;
+ long f_ffree;
+ __kernel_fsid_t f_fsid;
+ long f_namelen;
+ long f_frsize;
+ long f_spare[5];
+};
+
+struct compat_statfs64 {
+ __u32 f_type;
+ __u32 f_bsize;
+ __u64 f_blocks;
+ __u64 f_bfree;
+ __u64 f_bavail;
+ __u64 f_files;
+ __u64 f_ffree;
+ __kernel_fsid_t f_fsid;
+ __u32 f_namelen;
+ __u32 f_frsize;
+ __u32 f_spare[5];
+};
+#endif /* ! __powerpc64__ */
+#endif
diff --git a/include/asm-ppc/statfs.h b/include/asm-ppc/statfs.h
deleted file mode 100644
--- a/include/asm-ppc/statfs.h
+++ /dev/null
@@ -1,8 +0,0 @@
-#ifndef _PPC_STATFS_H
-#define _PPC_STATFS_H
-
-#include <asm-generic/statfs.h>
-#endif
-
-
-
diff --git a/include/asm-ppc64/statfs.h b/include/asm-ppc64/statfs.h
deleted file mode 100644
--- a/include/asm-ppc64/statfs.h
+++ /dev/null
@@ -1,61 +0,0 @@
-#ifndef _PPC64_STATFS_H
-#define _PPC64_STATFS_H
-
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#ifndef __KERNEL_STRICT_NAMES
-#include <linux/types.h>
-typedef __kernel_fsid_t fsid_t;
-#endif
-
-/*
- * We're already 64-bit, so duplicate the definition
- */
-struct statfs {
- long f_type;
- long f_bsize;
- long f_blocks;
- long f_bfree;
- long f_bavail;
- long f_files;
- long f_ffree;
- __kernel_fsid_t f_fsid;
- long f_namelen;
- long f_frsize;
- long f_spare[5];
-};
-
-struct statfs64 {
- long f_type;
- long f_bsize;
- long f_blocks;
- long f_bfree;
- long f_bavail;
- long f_files;
- long f_ffree;
- __kernel_fsid_t f_fsid;
- long f_namelen;
- long f_frsize;
- long f_spare[5];
-};
-
-struct compat_statfs64 {
- __u32 f_type;
- __u32 f_bsize;
- __u64 f_blocks;
- __u64 f_bfree;
- __u64 f_bavail;
- __u64 f_files;
- __u64 f_ffree;
- __kernel_fsid_t f_fsid;
- __u32 f_namelen;
- __u32 f_frsize;
- __u32 f_spare[5];
-};
-
-#endif /* _PPC64_STATFS_H */
^ permalink raw reply
* [PATCH] powerpc: merge include/asm-ppc*/spinlock_types.h into include/asm-powerpc/spinlock_types.h[PATCH]
From: Kumar Gala @ 2005-09-20 21:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit cb3e61d8491f6395a007687d9908bdb20fc9a0b5
tree da0514335c8f2ed2a795d4bbc7db06cfa6f728d5
parent 40ec2534f42b5d38123c41858a3c85bc2eae272b
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 20 Sep 2005 16:27:51 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 20 Sep 2005 16:27:51 -0500
include/asm-powerpc/spinlock_types.h | 20 ++++++++++++++++++++
include/asm-ppc/spinlock_types.h | 20 --------------------
include/asm-ppc64/spinlock_types.h | 20 --------------------
3 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/include/asm-powerpc/spinlock_types.h b/include/asm-powerpc/spinlock_types.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/spinlock_types.h
@@ -0,0 +1,20 @@
+#ifndef _ASM_POWERPC_SPINLOCK_TYPES_H
+#define _ASM_POWERPC_SPINLOCK_TYPES_H
+
+#ifndef __LINUX_SPINLOCK_TYPES_H
+# error "please don't include this file directly"
+#endif
+
+typedef struct {
+ volatile unsigned int slock;
+} raw_spinlock_t;
+
+#define __RAW_SPIN_LOCK_UNLOCKED { 0 }
+
+typedef struct {
+ volatile signed int lock;
+} raw_rwlock_t;
+
+#define __RAW_RW_LOCK_UNLOCKED { 0 }
+
+#endif
diff --git a/include/asm-ppc/spinlock_types.h b/include/asm-ppc/spinlock_types.h
deleted file mode 100644
--- a/include/asm-ppc/spinlock_types.h
+++ /dev/null
@@ -1,20 +0,0 @@
-#ifndef __ASM_SPINLOCK_TYPES_H
-#define __ASM_SPINLOCK_TYPES_H
-
-#ifndef __LINUX_SPINLOCK_TYPES_H
-# error "please don't include this file directly"
-#endif
-
-typedef struct {
- volatile unsigned long lock;
-} raw_spinlock_t;
-
-#define __RAW_SPIN_LOCK_UNLOCKED { 0 }
-
-typedef struct {
- volatile signed int lock;
-} raw_rwlock_t;
-
-#define __RAW_RW_LOCK_UNLOCKED { 0 }
-
-#endif
diff --git a/include/asm-ppc64/spinlock_types.h b/include/asm-ppc64/spinlock_types.h
deleted file mode 100644
--- a/include/asm-ppc64/spinlock_types.h
+++ /dev/null
@@ -1,20 +0,0 @@
-#ifndef __ASM_SPINLOCK_TYPES_H
-#define __ASM_SPINLOCK_TYPES_H
-
-#ifndef __LINUX_SPINLOCK_TYPES_H
-# error "please don't include this file directly"
-#endif
-
-typedef struct {
- volatile unsigned int slock;
-} raw_spinlock_t;
-
-#define __RAW_SPIN_LOCK_UNLOCKED { 0 }
-
-typedef struct {
- volatile signed int lock;
-} raw_rwlock_t;
-
-#define __RAW_RW_LOCK_UNLOCKED { 0 }
-
-#endif
^ permalink raw reply
* [PATCH] powerpc: merge include/asm-ppc*/auxvec.h into include/asm-powerpc/auxvec.h
From: Kumar Gala @ 2005-09-20 20:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 40ec2534f42b5d38123c41858a3c85bc2eae272b
tree e13c35c52e65b3ac32a7d9bd37be9b45accb0631
parent e89b8279aafe3b896a1d1fbb4d10fbe91841d8e9
author Kumar K. Gala <kumar.gala@freescale.com> Tue, 20 Sep 2005 15:31:13 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Tue, 20 Sep 2005 15:31:13 -0500
include/asm-powerpc/auxvec.h | 19 +++++++++++++++++++
include/asm-ppc/auxvec.h | 14 --------------
include/asm-ppc64/auxvec.h | 19 -------------------
3 files changed, 19 insertions(+), 33 deletions(-)
diff --git a/include/asm-powerpc/auxvec.h b/include/asm-powerpc/auxvec.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/auxvec.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_POWERPC_AUXVEC_H
+#define _ASM_POWERPC_AUXVEC_H
+
+/*
+ * We need to put in some extra aux table entries to tell glibc what
+ * the cache block size is, so it can use the dcbz instruction safely.
+ */
+#define AT_DCACHEBSIZE 19
+#define AT_ICACHEBSIZE 20
+#define AT_UCACHEBSIZE 21
+/* A special ignored type value for PPC, for glibc compatibility. */
+#define AT_IGNOREPPC 22
+
+/* The vDSO location. We have to use the same value as x86 for glibc's
+ * sake :-)
+ */
+#define AT_SYSINFO_EHDR 33
+
+#endif
diff --git a/include/asm-ppc/auxvec.h b/include/asm-ppc/auxvec.h
deleted file mode 100644
--- a/include/asm-ppc/auxvec.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __PPC_AUXVEC_H
-#define __PPC_AUXVEC_H
-
-/*
- * We need to put in some extra aux table entries to tell glibc what
- * the cache block size is, so it can use the dcbz instruction safely.
- */
-#define AT_DCACHEBSIZE 19
-#define AT_ICACHEBSIZE 20
-#define AT_UCACHEBSIZE 21
-/* A special ignored type value for PPC, for glibc compatibility. */
-#define AT_IGNOREPPC 22
-
-#endif
diff --git a/include/asm-ppc64/auxvec.h b/include/asm-ppc64/auxvec.h
deleted file mode 100644
--- a/include/asm-ppc64/auxvec.h
+++ /dev/null
@@ -1,19 +0,0 @@
-#ifndef __PPC64_AUXVEC_H
-#define __PPC64_AUXVEC_H
-
-/*
- * We need to put in some extra aux table entries to tell glibc what
- * the cache block size is, so it can use the dcbz instruction safely.
- */
-#define AT_DCACHEBSIZE 19
-#define AT_ICACHEBSIZE 20
-#define AT_UCACHEBSIZE 21
-/* A special ignored type value for PPC, for glibc compatibility. */
-#define AT_IGNOREPPC 22
-
-/* The vDSO location. We have to use the same value as x86 for glibc's
- * sake :-)
- */
-#define AT_SYSINFO_EHDR 33
-
-#endif /* __PPC64_AUXVEC_H */
^ permalink raw reply
* Re: [PATCH 2/2] Add support for MEMEC 2VP30-FF1152 eval board with simple FPGA design
From: Grant Likely @ 2005-09-20 20:35 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <87vf0vselw.fsf@p4.48ers.dk>
On 9/20/05, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "Grant" =3D=3D Grant Likely <glikely@gmail.com> writes:
>=20
> Hi,
>=20
> Grant> Here is an example port to another V2PRO based board. This
> Grant> patch is for information only and is NOT suitable for
> Grant> submission up to mainline
>=20
> Ok, I still have a little comment though..
>=20
> Grant> diff --git a/arch/ppc/boot/simple/embed_config.c
> Grant> b/arch/ppc/boot/simple/embed_config.c
> Grant> --- a/arch/ppc/boot/simple/embed_config.c
> Grant> +++ b/arch/ppc/boot/simple/embed_config.c
> Grant> @@ -745,7 +745,7 @@ embed_config(bd_t **bdp)
> Grant> }
> Grant> #endif /* WILLOW */
> Grant>
> Grant> -#ifdef CONFIG_XILINX_ML300
> Grant> +#ifdef CONFIG_VIRTEX_II_PRO
> Grant> void
> Grant> embed_config(bd_t ** bdp)
> Grant> {
>=20
> Please don't force all V2P boards to use the same embed_config. I'm
> using RedBoot on a V2P board, which provides a ready to go bd_t that I
> can directly use.
No problem. I need to go back and review this code anyway to
determine if any of it should be split out into common routines for
all v2p boards.
Hey, do you have any drivers for the common 'stock' v2p device cores
ported to 2.6 for your board? (like Ethernet, PS/2, framebuffer, etc)
I'm about to start porting the SystemACE driver and I also need
Ethernet and PS/2 devices, but I don't want to duplicate if anyone has
already done the work.
Thanks again,
g.
^ permalink raw reply
* Re: [PATCH 2/2] Add support for MEMEC 2VP30-FF1152 eval board with simple FPGA design
From: Peter Korsgaard @ 2005-09-20 19:50 UTC (permalink / raw)
To: glikely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc05091000377417dc16@mail.gmail.com>
>>>>> "Grant" == Grant Likely <glikely@gmail.com> writes:
Hi,
Grant> Here is an example port to another V2PRO based board. This
Grant> patch is for information only and is NOT suitable for
Grant> submission up to mainline
Ok, I still have a little comment though..
Grant> diff --git a/arch/ppc/boot/simple/embed_config.c
Grant> b/arch/ppc/boot/simple/embed_config.c
Grant> --- a/arch/ppc/boot/simple/embed_config.c
Grant> +++ b/arch/ppc/boot/simple/embed_config.c
Grant> @@ -745,7 +745,7 @@ embed_config(bd_t **bdp)
Grant> }
Grant> #endif /* WILLOW */
Grant>
Grant> -#ifdef CONFIG_XILINX_ML300
Grant> +#ifdef CONFIG_VIRTEX_II_PRO
Grant> void
Grant> embed_config(bd_t ** bdp)
Grant> {
Please don't force all V2P boards to use the same embed_config. I'm
using RedBoot on a V2P board, which provides a ready to go bd_t that I
can directly use.
--
Bye, Peter Korsgaard
^ permalink raw reply
* PATCH powerpc Merge asm-ppc*/vga.h
From: linuxppc @ 2005-09-20 19:32 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
Merge asm-ppc*/vga.h
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
include/asm-powerpc/vga.h | 54 +++++++++++++++++++++++++++++++++++++++++++++
include/asm-ppc/vga.h | 46 --------------------------------------
include/asm-ppc64/vga.h | 50 ------------------------------------------
3 files changed, 54 insertions(+), 96 deletions(-)
diff --git a/include/asm-powerpc/vga.h b/include/asm-powerpc/vga.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/vga.h
@@ -0,0 +1,54 @@
+#ifndef _ASM_POWERPC_VGA_H_
+#define _ASM_POWERPC_VGA_H_
+
+#ifdef __KERNEL__
+
+/*
+ * Access to VGA videoram
+ *
+ * (c) 1998 Martin Mares <mj@ucw.cz>
+ */
+
+
+#include <asm/io.h>
+
+#include <linux/config.h>
+
+#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_MDA_CONSOLE)
+
+#define VT_BUF_HAVE_RW
+/*
+ * These are only needed for supporting VGA or MDA text mode, which use little
+ * endian byte ordering.
+ * In other cases, we can optimize by using native byte ordering and
+ * <linux/vt_buffer.h> has already done the right job for us.
+ */
+
+static inline void scr_writew(u16 val, volatile u16 *addr)
+{
+ st_le16(addr, val);
+}
+
+static inline u16 scr_readw(volatile const u16 *addr)
+{
+ return ld_le16(addr);
+}
+
+#define VT_BUF_HAVE_MEMCPYW
+#define scr_memcpyw memcpy
+
+#endif /* !CONFIG_VGA_CONSOLE && !CONFIG_MDA_CONSOLE */
+
+extern unsigned long vgacon_remap_base;
+
+#ifdef __powerpc64__
+#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
+#else
+#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#endif
+
+#define vga_readb(x) (*(x))
+#define vga_writeb(x,y) (*(y) = (x))
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_VGA_H_ */
diff --git a/include/asm-ppc/vga.h b/include/asm-ppc/vga.h
deleted file mode 100644
--- a/include/asm-ppc/vga.h
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * Access to VGA videoram
- *
- * (c) 1998 Martin Mares <mj@ucw.cz>
- */
-
-#ifdef __KERNEL__
-#ifndef _LINUX_ASM_VGA_H_
-#define _LINUX_ASM_VGA_H_
-
-#include <asm/io.h>
-
-#include <linux/config.h>
-
-#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_MDA_CONSOLE)
-
-#define VT_BUF_HAVE_RW
-/*
- * These are only needed for supporting VGA or MDA text mode, which use little
- * endian byte ordering.
- * In other cases, we can optimize by using native byte ordering and
- * <linux/vt_buffer.h> has already done the right job for us.
- */
-
-extern inline void scr_writew(u16 val, volatile u16 *addr)
-{
- st_le16(addr, val);
-}
-
-extern inline u16 scr_readw(volatile const u16 *addr)
-{
- return ld_le16(addr);
-}
-
-#define VT_BUF_HAVE_MEMCPYW
-#define scr_memcpyw memcpy
-
-#endif /* !CONFIG_VGA_CONSOLE && !CONFIG_MDA_CONSOLE */
-
-extern unsigned long vgacon_remap_base;
-#define VGA_MAP_MEM(x) (x + vgacon_remap_base)
-#define vga_readb(x) (*(x))
-#define vga_writeb(x,y) (*(y) = (x))
-
-#endif
-#endif /* __KERNEL__ */
diff --git a/include/asm-ppc64/vga.h b/include/asm-ppc64/vga.h
deleted file mode 100644
--- a/include/asm-ppc64/vga.h
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- * Access to VGA videoram
- *
- * (c) 1998 Martin Mares <mj@ucw.cz>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#ifndef _LINUX_ASM_VGA_H_
-#define _LINUX_ASM_VGA_H_
-
-#include <asm/io.h>
-
-#include <linux/config.h>
-
-#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_MDA_CONSOLE)
-
-#define VT_BUF_HAVE_RW
-/*
- * These are only needed for supporting VGA or MDA text mode, which use little
- * endian byte ordering.
- * In other cases, we can optimize by using native byte ordering and
- * <linux/vt_buffer.h> has already done the right job for us.
- */
-
-static inline void scr_writew(u16 val, volatile u16 *addr)
-{
- st_le16(addr, val);
-}
-
-static inline u16 scr_readw(volatile const u16 *addr)
-{
- return ld_le16(addr);
-}
-
-#define VT_BUF_HAVE_MEMCPYW
-#define scr_memcpyw memcpy
-
-#endif /* !CONFIG_VGA_CONSOLE && !CONFIG_MDA_CONSOLE */
-
-extern unsigned long vgacon_remap_base;
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap((x), 0))
-
-#define vga_readb(x) (*(x))
-#define vga_writeb(x,y) (*(y) = (x))
-
-#endif
^ permalink raw reply
* RE: Which way to store log in flash on mpc8xx?
From: Eli Brin @ 2005-09-20 20:25 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
Hello David,
Wolfgang wrote:
>Yes, there is. Run the system with root file system mounted over NFS,
>and then put some load on the system, like by compiling the linux
>kernel on the target.
If you want to have some fun, and stress the platform, compile and run (via
NFS) Crafty, an open source Linux chess porgram.
We did so on our 8xx target and it plays very well...
Best regards,
Eli Brin
^ permalink raw reply
* RE: wait_event and interrupts
From: Rune Torgersen @ 2005-09-20 19:14 UTC (permalink / raw)
To: jeff; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Jeff Angielski [mailto:jeff@theptrgroup.com]=20
> Sent: Tuesday, September 20, 2005 13:40
> On Tue, 2005-09-20 at 12:56 -0500, Rune Torgersen wrote:
>=20
> > Is there a better way of doing this?
>=20
> If you *must* share the variable between interrupt and non-interrupt
> context, you must mutex it in an interrupt safe way. The use of
> spin_lock_irqsave() comes to mind for you read function.
The shared variable is an int, which should be atomic to access anyways.
Someone else told me to try to set the shared variable to volatile.
> But you are going to have other problems with this approach anyways
> since you "appear" to be assuming a one-to-one relationship=20
> between your
> interrupt handler and the read function. Is that really true?
Yes. The read function starts the hardware, and the hardware responds
with an interrupt when it's done.
^ permalink raw reply
* Re: wait_event and interrupts
From: Jeff Angielski @ 2005-09-20 18:40 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859463@ismail.innsys.innovsys.com>
On Tue, 2005-09-20 at 12:56 -0500, Rune Torgersen wrote:
> Is there a better way of doing this?
If you *must* share the variable between interrupt and non-interrupt
context, you must mutex it in an interrupt safe way. The use of
spin_lock_irqsave() comes to mind for you read function.
But you are going to have other problems with this approach anyways
since you "appear" to be assuming a one-to-one relationship between your
interrupt handler and the read function. Is that really true?
Jeff Angielski
The PTR Group
^ permalink raw reply
* Re: GT64260_eth (Ethernet) Driver
From: Mark A. Greer @ 2005-09-20 18:32 UTC (permalink / raw)
To: Brian Waite; +Cc: linuxppc-embedded
In-Reply-To: <200509201313.48945.bwaite@irobot.com>
On Tue, Sep 20, 2005 at 01:13:48PM -0400, Brian Waite wrote:
> On Tuesday 20 September 2005 12:02 pm, Earl Olsen wrote:
> platform using the 64260 chip, besides the eval board, was the cpci690.c. I
> would look and see ifthis is still a working platform and base your platform
> code off of that.
The cpci690 is a working platform but it does not use the embedded enet
ctlr because there is no driver.
> > Dieu,
> >
> > You should sync up with Brian Waite (look at CC: list) who has been
> > looking at writing a new enet driver for the 2.6 kernel using the latest
> > bridge support code. You can get a look at the latest support code by
> > cloning bk://source.mvista.com/linux-2.5-marvell.
> No. Only use mainline kernel.org for latest support. Nothing else is working
> 100%. In the kernel.org tree the MPSC driver is working along with the 360
> ethernet device.
This is from a very, very old email that is no longer accurate. It
should be ignored. This is no tree except the mainline/mm tree and there
is not gt64260 enet driver in the mainline/mm tree (that I know of).
> > Note the the mpsc
> > driver that's there still isn't working correctly.
> I haven't loked at the 64260 for well over a year since we went to the 64360.
> The 260 was just too bad in too many respects. I was willing to test the 260
> code with my old hardware if there was a merged driver and even develop the
> merged driver, but it became obvious the merged driver was going to be ugly
Ditto.
Mark
^ permalink raw reply
* Re: ELDK included in which AMCC440EP Kit?
From: Wolfgang Denk @ 2005-09-20 18:10 UTC (permalink / raw)
To: KylongMu; +Cc: Linuxppc-embedded
In-Reply-To: <20050920151811.C0246E55@smtp.263.net>
In message <20050920151811.C0246E55@smtp.263.net> you wrote:
>
> I'm going to buy the AMCC440EP Evaluation Kit , there are two
> types : one is Bamboo , another is Yosemite .
> Witch of them supported by ELDK , or both of them . There are
> not clear message from web.
The ELDK is a tool chain. It is hardware independent, so any 4xx/44x
board is "supported" by the ELDK.
Both the U-Boot and the Linux source code as available on the ELDK
CDROM image is too old for the Yosemite, but you can access the
current versions from our git/CVS/FTP servers, and then both Bamboo
and Yosemite are supported.
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
"The more data I punch in this card, the lighter it becomes, and the
lower the mailing cost."
- Stan Kelly-Bootle, "The Devil's DP Dictionary"
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: Wolfgang Denk @ 2005-09-20 18:07 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200509201117.40454.david.jander@protonic.nl>
In message <200509201117.40454.david.jander@protonic.nl> you wrote:
>
> Is there something like memtest86 for linux-ppc (i.e. written in portable C)?
Yes, there is. Run the system with root file system mounted over NFS,
and then put some load on the system, like by compiling the linux
kernel on the target. Anything else which adds DMA load does not
hurt, either. In such a situation, with a lots of context switches,
stress on the memory management system and having a lots of DMA
traffic going on you may see some memory problems. Unfortunately none
of the standard memory tests will catch thse, as the tests usually
provide only plain read / write accesses, while the problems show up
only in burst mode, i. e. when filling the caches and/or doing DMA.
There is an attempt of a burst mode memory test in the U-Boot code,
but I have to admit that I didn't work to show the exact problem on
the system it was written for.
> Hmm, but.... there is no data corruption. I have not seen one file on flash
> that had other data than intended, and that inspite of the GC freaking out.
Maybe there is no corruption of the data in flash. But are you sure
that correct data are loaded to and read from RAM? We had a similar
problem on a board where data got corrupted only when doing a lot of
transfers flash->RAM.
> That commit only changed 3 files, non of them directly related to jffs2 code,
This is correct.
> and only seemed to add support for FUJITSU flash chips. What am I missing?
> MTD developers say that cvs from march-2005 _is_ broken, so there must be some
Yes, of course it's broken. Like all computer code. There are a
couple of known issues (especially with NAND flash), but I don't
think they could explain the type of problems you are seeing.
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
Einstein argued that there must be simplified explanations of nature,
because God is not capricious or arbitrary. No such faith comforts
the software engineer. - Fred Brooks, Jr.
^ permalink raw reply
* wait_event and interrupts
From: Rune Torgersen @ 2005-09-20 17:56 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I have a driver that roughly does something like:
int driver_read(int cs, int addr, void *buf, int len)
{
hw_done =3D 0;
/* init_hw */
if (!hw_done)
{
ret =3D wait_event_interruptible_timeout(inq, hw_done, TIMEOUT);
if (ret =3D=3D 0)
{
if (hw_done)
goto hw_finished;
=09
return -EIO;
}
}
hw_finished:
return len;
}
static irqreturn_t myinterrupt(int irq, void * dev_id, struct pt_regs *
regs)
{
hw_done =3D 1;
schedule_work(&tqueue);
return IRQ_HANDLED;
}
static void do_softint(void *private_)
{
wake_up_interruptible(&inq);
}
I have a problem however with this, because in about 10% of my cases,
the interrupt triggers very fast, and ends up being served between the
check for hw_done and the wait_event call. This cause the wait to
timeout instead of getting waked up.
Is there a better way of doing this?
I do not want to do a busy wait, because the hardware can take up to
several 100's of ms to return, but most often returns within 20us.
^ permalink raw reply
* RE: MPC8250 MCC operating on 2-bit channels
From: Rune Torgersen @ 2005-09-20 17:42 UTC (permalink / raw)
To: Stevan Ignjatovic, linuxppc-embedded
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org Stevan Ignjatovic
> Sent: Tuesday, September 20, 2005 10:17
> Subject: MPC8250 MCC operating on 2-bit channels
> Has anybody dealt with 2-bit channels on MCC? What can cause such
> problems (remember that everything works fine with 8-bit channels). I
> would also appreciate if somebody has the possibility to implement
> similar test.
I am using 7 bit channels without any problems (tx and rx) on MCC 1 and
2.
(on an MPC8266)
Can you send me a dump of your SIRAM settings, and I'll take a look at
them?
Be aware of one thing (at least for 826x with 2 MCC's), first channel on
MCC2 is numbered 128, not 0
Rune Torgersen
^ permalink raw reply
* Re: GT64260_eth (Ethernet) Driver
From: Brian Waite @ 2005-09-20 17:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <B8561865DB141248943E2376D0E85215014202FE@DHOST001-17.DEX001.intermedia.net>
On Tuesday 20 September 2005 12:02 pm, Earl Olsen wrote:
> Does anybody know if this issue was solved?
> I'm running into the exact same problem with 2.6.10.
>
> Thanks
>
> Dieu Morales wrote:
> >Greetings, I am working with the latest 2.6.7 kernel
> >source on a ppc radstone PPC7A board and was curious
> >if anyone was in the process or planned on porting the
> >gt64260_eth driver to support the 2.6.x kernel.
2.6.7 is a really early version. I don't know of any working Marvel 64260 o=
r=20
64360 code in this time frame. I do know that the 64360 was patched to=20
mainline at ~2.6.13. Since then all real Marvel work should have been done =
on=20
mainline. I'd reccommend moving forward.
> >
> >Not being familiar with the gt64260 Ethernet device or
> >code, I plan to take it line by line.=20
That is probably a mistake for a number of reasons. First, you will not be=
=20
able to get this into the mainline because it does not use the=20
platform_device structures like the Marvell 64360 ethernet device. Secondly=
,=20
most of the developers doing Marvell work, are using the 64360 chipset. I'd=
=20
reccommend using a newer kernel and backporting the 64360 ethernet code to=
=20
64260. I just looked at my baseline tree (2.6.12-rc1) and see the only=20
platform using the 64260 chip, besides the eval board, was the cpci690.c. I=
=20
would look and see ifthis is still a working platform and base your platfor=
m=20
code off of that.
> >I have attempted=20
> >to use the driver from the ppc.bkbits.net 2.4
> >development tree and currently have only changed the
> >dev =3D init_etherdev(dev, sizeof (gt_eth_priv));
> >to
> >dev =3D alloc_etherdev(sizeof (gt_eth_priv_struct ));
> >Shortly after, when attempting to allocate the Tx and
> >Rx page buffers, I get an exception in the
> >uncachedPages function. I have traced the problem to
> >the pmd_present=C3=B2(*pmd) function in va_to_pte(addr)
> >returning 0. I dumped td the values seemed O.K., so
> >I commented out the pmd_present=C3=B2(*pmd) check but was
> >once again stopped by the pte_present(*pte) check. I
> >have seen the driver operate under 2.4.26 dev tree
> >from ppc.bkbits.net where this problem does not occur.
> >One difference I have noticed is that during
> >initialization of the 2.6.7 kernel, I do not get the
> >following output.
> >Buffer-cache hash table entries:
> >Page-cache hash table entries:
> >The filemap.c, where the "Page-cache " printk resides
> >in 2.4, looks heavily reworked, so I don't suspect
> >this is an issue?
>
> Dieu,
>
> You should sync up with Brian Waite (look at CC: list) who has been
> looking at writing a new enet driver for the 2.6 kernel using the latest
> bridge support code. You can get a look at the latest support code by
> cloning bk://source.mvista.com/linux-2.5-marvell. =20
No. Only use mainline kernel.org for latest support. Nothing else is workin=
g=20
100%. In the kernel.org tree the MPSC driver is working along with the 360=
=20
ethernet device.=20
> Note the the mpsc=20
> driver that's there still isn't working correctly.
I haven't loked at the 64260 for well over a year since we went to the 6436=
0.=20
The 260 was just too bad in too many respects. I was willing to test the 26=
0=20
code with my old hardware if there was a merged driver and even develop the=
=20
merged driver, but it became obvious the merged driver was going to be ugly
Thanks
Brian
^ permalink raw reply
* GT64260_eth (Ethernet) Driver
From: Earl Olsen @ 2005-09-20 16:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
Does anybody know if this issue was solved?
I'm running into the exact same problem with 2.6.10.
Thanks
Dieu Morales wrote:
>Greetings, I am working with the latest 2.6.7 kernel
>source on a ppc radstone PPC7A board and was curious
>if anyone was in the process or planned on porting the
>gt64260_eth driver to support the 2.6.x kernel.
>
>Not being familiar with the gt64260 Ethernet device or
>code, I plan to take it line by line. I have attempted
>to use the driver from the ppc.bkbits.net 2.4
>development tree and currently have only changed the
>dev = init_etherdev(dev, sizeof (gt_eth_priv));
>to
>dev = alloc_etherdev(sizeof (gt_eth_priv_struct ));
>Shortly after, when attempting to allocate the Tx and
>Rx page buffers, I get an exception in the
>uncachedPages function. I have traced the problem to
>the pmd_presentò(*pmd) function in va_to_pte(addr)
>returning 0. I dumped the values of pmd, init_mm, and
>pmd in the va_to_pte() and the values seemed O.K., so
>I commented out the pmd_presentò(*pmd) check but was
>once again stopped by the pte_present(*pte) check. I
>have seen the driver operate under 2.4.26 dev tree
>from ppc.bkbits.net where this problem does not occur.
>One difference I have noticed is that during
>initialization of the 2.6.7 kernel, I do not get the
>following output.
>Buffer-cache hash table entries:
>Page-cache hash table entries:
>The filemap.c, where the "Page-cache " printk resides
>in 2.4, looks heavily reworked, so I don't suspect
>this is an issue?
>
>
Dieu,
You should sync up with Brian Waite (look at CC: list) who has been
looking at writing a new enet driver for the 2.6 kernel using the latest
bridge support code. You can get a look at the latest support code by
cloning bk://source.mvista.com/linux-2.5-marvell. Note the the mpsc
driver that's there still isn't working correctly.
Mark
--
Earl Olsen
Senior Software Engineer
Dilithium Networks, Inc.
TEL:+1 707-792-3925
earl.olsen@dilithiumnetworks.com
www.dilithiumnetworks.com
Communications for a Borderless World
This electronic message from Dilithium Networks contains information which may be privileged or confidential. It is intended to be for the use of the recipient(s) named above. If you are not the intended recipient please return the message to the sender by replying to it and then delete the message from your computer. Dilithium Networks shall not be held liable to any person resulting from the use of any information contained in this e-mail and shall not be liable to any person who acts or omits to do anything in reliance upon it. Dilithium Networks does not accept responsibility for changes made to this message after it was sent.
[-- Attachment #2: Type: text/html, Size: 4432 bytes --]
^ permalink raw reply
* MPC8250 MCC operating on 2-bit channels
From: Stevan Ignjatovic @ 2005-09-20 15:16 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
My problem is concerned with the multi channel controller MCC2 on
MPC8250. Its task is to relay messages from D channels between Local
Exchange and ISDN BRA subscribers. All active D channels (up to 128) are
aggregated into single stream tied directly to the TDMc2, ie. both
TDMc2_Rx and TDMc2_Tx are divided into 2-bit channels. 2.048MHz clock
and 8KHz frame pulse are generated externaly and are connected to
corresponding processor pins (common pins for receive and transmit
sections).
When tested with internal loopback (SI2MR[SDM2]=0b10) everything works
fine, ie. for example the message we send through channel 0 is received
correctly on channel 0. However, it doesn't work in real application.
The debugging process led me to this simple test. I connected TDMc2_Rx
and TDMc2_Tx to FPGA in which I implemented the delay of N frames (N x
125us, since the frame pulse is 8KHz), such that for N=0 I have simple
external loopback, for N=1 delay of one entire frame, and so on. I was
sending messages through channel 0 (it is the only channel I actually
started). The results I obtained were very strange. For N=0, N=4, N=8
the received message was correct, but for N=1,2,3 it was not (I was
usually reported CRC erro,r or non octet alignment error, or abort).When
I tried with 4-bit channels, the result was correct for N=0,2,4,....
Only with 8-bit channels I obtained correct result for all frame delays.
The fact that everything works fine with 8-bit channels makes me believe
that all MCC and SIRAM settings are ok. I tried many combinations of
SIRAM programming (For example, I tried to program only channel 0 as
2-bit and all others as 8-bit, or as null entries), but it didn't work
out. It is also worth to mention that I have never received GUN or GOV
errors.
Has anybody dealt with 2-bit channels on MCC? What can cause such
problems (remember that everything works fine with 8-bit channels). I
would also appreciate if somebody has the possibility to implement
similar test.
Regards,
Stevan
^ permalink raw reply
* ELDK included in which AMCC440EP Kit?
From: KylongMu @ 2005-09-20 15:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 244 bytes --]
Hi , Denk:
I'm going to buy the AMCC440EP Evaluation Kit , there are two
types : one is Bamboo , another is Yosemite .
Witch of them supported by ELDK , or both of them . There are
not clear message from web.
Thanks a lot!
KylongMu
[-- Attachment #2: Type: text/html, Size: 967 bytes --]
^ permalink raw reply
* Re: 8250 serial driver on MPC8272ADS board
From: Vitaly Bordug @ 2005-09-20 9:56 UTC (permalink / raw)
To: Landau, Bracha; +Cc: linuxppc-embedded list
In-Reply-To: <B621B955FA9FBB4C83F9724972F4DD1901CB5421@ILEX2.IL.NDS.COM>
Landau, Bracha wrote:
> I am running linux kernel 2.6.13 on a MPC8272ADS board. When I compile the kernel with the 8250 serial driver, the kernel crashes when loading it. It crashes also if compiled as a module and insmod'ed later.
> Has anyone had experience with this?
That's because this board does not have 8250 serial, you should use
CPM_UART(SCC1 and SCC4) instead (take a look at the
arch/ppc/configs/ads8272_defconfig)
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: David Jander @ 2005-09-20 9:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050919192101.C6267353BF3@atlas.denx.de>
Hi again,
On Monday 19 September 2005 21:21, Wolfgang Denk wrote:
>[...]
> Are you 100% sure your system is stable and wihout any memory errors?
> Never seen any other erros or crashes?
It has been running for several weeks without reboot processing data, and we
have never had any other strange things, nor data corruption, crashes, or
whatever.
> > My big question: Is it at all possible that gc.c comes to that BUG() in
> > line 139 because of anything other than a bug in jffs2-code?
>
> Yes, for example when your SDRAM initialization is broken and/or
> other memory corruption happens.
Then you would expect to have other symptoms too, don't you? Well, we don't
have any other symptoms of SDRAM errors. Although, I have seen PC's with
faulty SDRAM that behave as if the HD was broken, but the fine tool
"memtest86" finally revealed the truth ;-)
Is there something like memtest86 for linux-ppc (i.e. written in portable C)?
>[...]
> I don't think it's a flash error. If there is data corruption, then
> it's more likely the SDRAM.
Hmm, but.... there is no data corruption. I have not seen one file on flash
that had other data than intended, and that inspite of the GC freaking out.
> > The logs of almost all files in fs/jffs2/ which I have say that the
> > actual version corresponds to the CVS-snapshot of March 13, 2005, and
> > that the previous version of April 2004 is broken.
> > Which files were modified _after_ March 13, 2005?
> > (A hint to what command options or tools to use to browse cvs-logs more
> > easily at this point is appreciated... I am using cervisia).
>
> cvsps is really helpful, see http://www.cobite.com/cvsps/cvsps-2.1.tar.gz
>
> Also there are web interfaces to our kernel tree;
> for CVS see
> http://81.169.171.120/cgi-bin/cvsweb/
> for git see
> http://81.169.171.120/cgi-bin/gitweb.cgi
Thanks for the tips. The gitweb interface looked quite impressive!
> Make sure to use at least the version tagged as LABEL_2005_05_09_1245
> or later.
We have that version. I have been trying to figure out what changed up until
that label, but the only thing I found that looked relevant was:
"Re-implement PatchSets 260, 263 and 303"
That commit only changed 3 files, non of them directly related to jffs2 code,
and only seemed to add support for FUJITSU flash chips. What am I missing?
MTD developers say that cvs from march-2005 _is_ broken, so there must be some
evident bug-fixes in your tree since then.... otherwise it is still broken
(whatever it was).
Of course, maybe I'm just blind ;-)
> > I know about the problems jffs2 has with logfiles and alikes. I am still
> > thinking about what would be the most robust way of coping with this, and
> > until now, oversized partitions with log-rotation on size seems to do the
> > trick. I don't want to loose log-data on power-loss so I don't feel so
> > comfortable with buffering much of it in RAM.
>
> The problem with your approach is the number of erase cycles which
> will cause the flash to die sooner than you may want.
That's true, but under normal use, you'll have maybe 5..10 lines a day added
to a given logfile, maybe even less, and since the partition is relatively
huge, wear-levelling in the jffs2 driver should do the obvious I believe.
It's not optimal, but it should work reliably AFAICT.
Regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [PATCH 1/2] Move Virtex-II Pro / ML300 port over to the platform bus.
From: Peter Korsgaard @ 2005-09-20 6:26 UTC (permalink / raw)
To: glikely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc050910003630c25dca@mail.gmail.com>
>>>>> " " == Grant Likely <glikely@gmail.com> writes:
Hi,
> This is a large patch that moves the ML300 to the platform bus.
> It also isolates most of the linux tree from changes to the
> xparameters.h file. Ultimately, the goal is to move everything
> over to the flattened device tree for telling the kernel about
> devices. That way xparameters.h can go away entirely for the
> kernel proper. (Isolated to the bootloader)
Great!
> Comments are appreciated.
Here you go..
> diff --git a/arch/ppc/platforms/4xx/xilinx_ml300_devices.c
...
> +struct plat_serial8250_port serial_platform_data[] = {
> +#ifdef XPAR_OPB_UART16550_0_BASEADDR
> + {
> + .mapbase = XPAR_OPB_UART16550_0_BASEADDR + 3,
> + .irq = XPAR_DCR_INTC_0_OPB_UART16550_0_IP2INTC_IRPT_INTR,
> + .iotype = UPIO_MEM,
> + .uartclk = XPAR_XUARTNS550_CLOCK_HZ,
> + .flags = UPF_BOOT_AUTOCONF,
> + .regshift = 2,
> + },
> +#endif
> +#ifdef XPAR_OPB_UART16550_1_BASEADDR
> + {
> + .mapbase = XPAR_OPB_UART16550_1_BASEADDR + 3,
You forgot the offset of 0x1000 (did you mean
XPAR_UARTNS550_0_BASEADDR) ?
> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h
...
> + /* zImage serial port definitions */
> + #define SERIAL_PORT_DFNS { \
> + .baud_base = XPAR_XUARTNS550_CLOCK_HZ/16, \
> + .irq = XPAR_DCR_INTC_0_OPB_UART16550_0_IP2INTC_IRPT_INTR, \
> + .flags = ASYNC_BOOT_AUTOCONF, \
> + .iomem_base = (u8 *)XPAR_OPB_UART16550_0_BASEADDR + 3, \
And again.
Otherwise it looks good.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Esse Cartao foi feito para voce
From: cartoes @ 2005-09-20 3:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 3656 bytes --]
^ permalink raw reply
* [PATCH] Add support for USB to 440EP platform files
From: Wade Farnsworth @ 2005-09-19 23:55 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]
This adds support for the USB host and device interfaces on the 440EP to
the appropriate platform-specific files.
Signed off by: John Otken <jotken@softadvances.com>
Signed off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: 440ep-ppc-usb.patch --]
[-- Type: text/x-patch, Size: 2374 bytes --]
diff -uprN linux-2.6/include/asm-ppc/ibm44x.h linux-2.6-dev/include/asm-ppc/ibm44x.h
--- linux-2.6/include/asm-ppc/ibm44x.h 2005-09-12 11:18:19.000000000 -0700
+++ linux-2.6-dev/include/asm-ppc/ibm44x.h 2005-09-13 13:51:23.000000000 -0700
@@ -169,6 +169,7 @@
#ifdef CONFIG_440EP
#define DCRN_SDR_UART2 0x0122
#define DCRN_SDR_UART3 0x0123
+#define DCRN_SDR_USB0 0x0320
#define DCRN_SDR_CUST0 0x4000
#endif
Binary files linux-2.6/arch/ppc/boot/images/ramdisk.gz and linux-2.6-dev/arch/ppc/boot/images/ramdisk.gz differ
Binary files linux-2.6/arch/ppc/boot/images/ramdisk.image.gz and linux-2.6-dev/arch/ppc/boot/images/ramdisk.image.gz differ
diff -uprN linux-2.6/arch/ppc/platforms/4xx/ibm440ep.c linux-2.6-dev/arch/ppc/platforms/4xx/ibm440ep.c
--- linux-2.6/arch/ppc/platforms/4xx/ibm440ep.c 2005-09-12 11:17:54.000000000 -0700
+++ linux-2.6-dev/arch/ppc/platforms/4xx/ibm440ep.c 2005-09-13 14:00:10.000000000 -0700
@@ -182,23 +182,48 @@ struct ppc4xx_uic_settings ppc4xx_core_u
},
};
-static struct resource usb_gadget_resources[] = {
+static struct resource ohci_usb_resources[] = {
[0] = {
- .start = 0x050000100ULL,
- .end = 0x05000017FULL,
+ .start = 0x0EF601000ULL,
+ .end = 0x0EF60107FULL,
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = 55,
- .end = 55,
+ .start = 40,
+ .end = 40,
.flags = IORESOURCE_IRQ,
},
};
+static struct resource usb_gadget_resources[] = {
+ [0] = {
+ .start = 0x050000100ULL,
+ .end = 0x05000017FULL,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = 55,
+ .end = 55,
+ .flags = IORESOURCE_IRQ,
+ .name = "usb_device_irq",
+ },
+};
+
static u64 dma_mask = 0xffffffffULL;
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ }
+};
+
static struct platform_device usb_gadget_device = {
- .name = "musbhsfc",
+ .name = "musbhsfc_udc",
.id = 0,
.num_resources = ARRAY_SIZE(usb_gadget_resources),
.resource = usb_gadget_resources,
@@ -210,6 +235,7 @@ static struct platform_device usb_gadget
static struct platform_device *ibm440ep_devs[] __initdata = {
&usb_gadget_device,
+ &ohci_usb_device,
};
static int __init
^ 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