* Re: [PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
From: Matt Porter @ 2005-09-19 13:59 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200509191302.15462.sr@denx.de>
On Mon, Sep 19, 2005 at 01:02:14PM +0200, Stefan Roese wrote:
> Hi Eugene,
>
> On Friday 16 September 2005 18:27, Eugene Surovegin wrote:
> > On Fri, Sep 16, 2005 at 01:06:16PM +0200, Stefan Roese wrote:
> > > Add U-Boot support to AMCC PPC405 eval boards (bubinga, sycamore and
> > > walnut) and cleanup PPC440 eval boards (bamboo, ebony, luan and ocotea)
> > > to better support U-Boot as bootloader.
> >
> > In general, 44x pieces look OK, but 40x aren't. Notice, that we don't
> > have any #ifdef CONFIG_UBOOT in 44x sources. Let's not add them for
> > 40x, try to replicate the same boot-wrapper approach as Matt used for
> > 44x.
>
> OK. I'll split the patch in two (44x and 40x stuff) so we can get the 44x
> pieces on the way.
>
> Just to be sure: The 44x boot-wrapper approach you mention is
> "boot/simple/pibs.c"?
Yes, there's both boot/simple/pibs.c and boot/simple/openbios.c that
were created so we could have the default firmware and u-boot use the
same kernel build.
-Matt
^ permalink raw reply
* PATCH powerpc: Merge asm-ppc*/posix_types.h
From: linuxppc @ 2005-09-19 14:01 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
Merge asm-ppc/posix_types.h and asm-ppc64/posix_types.h.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
include/asm-powerpc/posix_types.h | 129 +++++++++++++++++++++++++++++++++++++
include/asm-ppc/posix_types.h | 111 --------------------------------
include/asm-ppc64/posix_types.h | 119 ----------------------------------
3 files changed, 129 insertions(+), 230 deletions(-)
diff --git a/include/asm-powerpc/posix_types.h b/include/asm-powerpc/posix_types.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/posix_types.h
@@ -0,0 +1,129 @@
+#ifndef _ASM_POWERPC_POSIX_TYPES_H
+#define _ASM_POWERPC_POSIX_TYPES_H
+
+/*
+ * This file is generally used by user-level software, so you need to
+ * be a little careful about namespace pollution etc. Also, we cannot
+ * assume GCC is being used.
+ */
+
+typedef unsigned long __kernel_ino_t;
+typedef unsigned int __kernel_mode_t;
+typedef long __kernel_off_t;
+typedef int __kernel_pid_t;
+typedef unsigned int __kernel_uid_t;
+typedef unsigned int __kernel_gid_t;
+typedef long __kernel_ptrdiff_t;
+typedef long __kernel_time_t;
+typedef long __kernel_clock_t;
+typedef int __kernel_timer_t;
+typedef int __kernel_clockid_t;
+typedef long __kernel_suseconds_t;
+typedef int __kernel_daddr_t;
+typedef char * __kernel_caddr_t;
+typedef unsigned short __kernel_uid16_t;
+typedef unsigned short __kernel_gid16_t;
+typedef unsigned int __kernel_uid32_t;
+typedef unsigned int __kernel_gid32_t;
+typedef unsigned int __kernel_old_uid_t;
+typedef unsigned int __kernel_old_gid_t;
+
+#ifdef __powerpc64__
+typedef unsigned long __kernel_nlink_t;
+typedef int __kernel_ipc_pid_t;
+typedef unsigned long __kernel_size_t;
+typedef long __kernel_ssize_t;
+typedef unsigned long __kernel_old_dev_t;
+#else
+typedef unsigned short __kernel_nlink_t;
+typedef short __kernel_ipc_pid_t;
+typedef unsigned int __kernel_size_t;
+typedef int __kernel_ssize_t;
+typedef unsigned int __kernel_old_dev_t;
+#endif
+
+#ifdef __powerpc64__
+typedef long long __kernel_loff_t;
+#else
+#ifdef __GNUC__
+typedef long long __kernel_loff_t;
+#endif
+#endif
+
+typedef struct {
+ int val[2];
+} __kernel_fsid_t;
+
+#ifndef __GNUC__
+
+#define __FD_SET(d, set) ((set)->fds_bits[__FDELT(d)] |= __FDMASK(d))
+#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
+#define __FD_ISSET(d, set) (((set)->fds_bits[__FDELT(d)] & __FDMASK(d)) != 0)
+#define __FD_ZERO(set) \
+ ((void) memset ((__ptr_t) (set), 0, sizeof (__kernel_fd_set)))
+
+#else /* __GNUC__ */
+
+#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) \
+ || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 0)
+/* With GNU C, use inline functions instead so args are evaluated only once: */
+
+#undef __FD_SET
+static __inline__ void __FD_SET(unsigned long fd, __kernel_fd_set *fdsetp)
+{
+ unsigned long _tmp = fd / __NFDBITS;
+ unsigned long _rem = fd % __NFDBITS;
+ fdsetp->fds_bits[_tmp] |= (1UL<<_rem);
+}
+
+#undef __FD_CLR
+static __inline__ void __FD_CLR(unsigned long fd, __kernel_fd_set *fdsetp)
+{
+ unsigned long _tmp = fd / __NFDBITS;
+ unsigned long _rem = fd % __NFDBITS;
+ fdsetp->fds_bits[_tmp] &= ~(1UL<<_rem);
+}
+
+#undef __FD_ISSET
+static __inline__ int __FD_ISSET(unsigned long fd, __kernel_fd_set *p)
+{
+ unsigned long _tmp = fd / __NFDBITS;
+ unsigned long _rem = fd % __NFDBITS;
+ return (p->fds_bits[_tmp] & (1UL<<_rem)) != 0;
+}
+
+/*
+ * This will unroll the loop for the normal constant case (8 ints,
+ * for a 256-bit fd_set)
+ */
+#undef __FD_ZERO
+static __inline__ void __FD_ZERO(__kernel_fd_set *p)
+{
+ unsigned long *tmp = (unsigned long *)p->fds_bits;
+ int i;
+
+ if (__builtin_constant_p(__FDSET_LONGS)) {
+ switch (__FDSET_LONGS) {
+ case 16:
+ tmp[12] = 0; tmp[13] = 0; tmp[14] = 0; tmp[15] = 0;
+ tmp[ 8] = 0; tmp[ 9] = 0; tmp[10] = 0; tmp[11] = 0;
+
+ case 8:
+ tmp[ 4] = 0; tmp[ 5] = 0; tmp[ 6] = 0; tmp[ 7] = 0;
+
+ case 4:
+ tmp[ 0] = 0; tmp[ 1] = 0; tmp[ 2] = 0; tmp[ 3] = 0;
+ return;
+ }
+ }
+ i = __FDSET_LONGS;
+ while (i) {
+ i--;
+ *tmp = 0;
+ tmp++;
+ }
+}
+
+#endif /* defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) */
+#endif /* __GNUC__ */
+#endif /* _ASM_POWERPC_POSIX_TYPES_H */
diff --git a/include/asm-ppc/posix_types.h b/include/asm-ppc/posix_types.h
deleted file mode 100644
--- a/include/asm-ppc/posix_types.h
+++ /dev/null
@@ -1,111 +0,0 @@
-#ifndef _PPC_POSIX_TYPES_H
-#define _PPC_POSIX_TYPES_H
-
-/*
- * This file is generally used by user-level software, so you need to
- * be a little careful about namespace pollution etc. Also, we cannot
- * assume GCC is being used.
- */
-
-typedef unsigned long __kernel_ino_t;
-typedef unsigned int __kernel_mode_t;
-typedef unsigned short __kernel_nlink_t;
-typedef long __kernel_off_t;
-typedef int __kernel_pid_t;
-typedef unsigned int __kernel_uid_t;
-typedef unsigned int __kernel_gid_t;
-typedef unsigned int __kernel_size_t;
-typedef int __kernel_ssize_t;
-typedef long __kernel_ptrdiff_t;
-typedef long __kernel_time_t;
-typedef long __kernel_suseconds_t;
-typedef long __kernel_clock_t;
-typedef int __kernel_timer_t;
-typedef int __kernel_clockid_t;
-typedef int __kernel_daddr_t;
-typedef char * __kernel_caddr_t;
-typedef short __kernel_ipc_pid_t;
-typedef unsigned short __kernel_uid16_t;
-typedef unsigned short __kernel_gid16_t;
-typedef unsigned int __kernel_uid32_t;
-typedef unsigned int __kernel_gid32_t;
-
-typedef unsigned int __kernel_old_uid_t;
-typedef unsigned int __kernel_old_gid_t;
-typedef unsigned int __kernel_old_dev_t;
-
-#ifdef __GNUC__
-typedef long long __kernel_loff_t;
-#endif
-
-typedef struct {
- int val[2];
-} __kernel_fsid_t;
-
-#ifndef __GNUC__
-
-#define __FD_SET(d, set) ((set)->fds_bits[__FDELT(d)] |= __FDMASK(d))
-#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
-#define __FD_ISSET(d, set) ((set)->fds_bits[__FDELT(d)] & __FDMASK(d))
-#define __FD_ZERO(set) \
- ((void) memset ((__ptr_t) (set), 0, sizeof (__kernel_fd_set)))
-
-#else /* __GNUC__ */
-
-#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) \
- || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 0)
-/* With GNU C, use inline functions instead so args are evaluated only once: */
-
-#undef __FD_SET
-static __inline__ void __FD_SET(unsigned long fd, __kernel_fd_set *fdsetp)
-{
- unsigned long _tmp = fd / __NFDBITS;
- unsigned long _rem = fd % __NFDBITS;
- fdsetp->fds_bits[_tmp] |= (1UL<<_rem);
-}
-
-#undef __FD_CLR
-static __inline__ void __FD_CLR(unsigned long fd, __kernel_fd_set *fdsetp)
-{
- unsigned long _tmp = fd / __NFDBITS;
- unsigned long _rem = fd % __NFDBITS;
- fdsetp->fds_bits[_tmp] &= ~(1UL<<_rem);
-}
-
-#undef __FD_ISSET
-static __inline__ int __FD_ISSET(unsigned long fd, __kernel_fd_set *p)
-{
- unsigned long _tmp = fd / __NFDBITS;
- unsigned long _rem = fd % __NFDBITS;
- return (p->fds_bits[_tmp] & (1UL<<_rem)) != 0;
-}
-
-/*
- * This will unroll the loop for the normal constant case (8 ints,
- * for a 256-bit fd_set)
- */
-#undef __FD_ZERO
-static __inline__ void __FD_ZERO(__kernel_fd_set *p)
-{
- unsigned int *tmp = (unsigned int *)p->fds_bits;
- int i;
-
- if (__builtin_constant_p(__FDSET_LONGS)) {
- switch (__FDSET_LONGS) {
- case 8:
- tmp[0] = 0; tmp[1] = 0; tmp[2] = 0; tmp[3] = 0;
- tmp[4] = 0; tmp[5] = 0; tmp[6] = 0; tmp[7] = 0;
- return;
- }
- }
- i = __FDSET_LONGS;
- while (i) {
- i--;
- *tmp = 0;
- tmp++;
- }
-}
-
-#endif /* defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) */
-#endif /* __GNUC__ */
-#endif /* _PPC_POSIX_TYPES_H */
diff --git a/include/asm-ppc64/posix_types.h b/include/asm-ppc64/posix_types.h
deleted file mode 100644
--- a/include/asm-ppc64/posix_types.h
+++ /dev/null
@@ -1,119 +0,0 @@
-#ifndef _PPC64_POSIX_TYPES_H
-#define _PPC64_POSIX_TYPES_H
-
-/*
- * This file is generally used by user-level software, so you need to
- * be a little careful about namespace pollution etc. Also, we cannot
- * assume GCC is being used.
- *
- * 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.
- */
-
-typedef unsigned long __kernel_ino_t;
-typedef unsigned long __kernel_nlink_t;
-typedef unsigned int __kernel_mode_t;
-typedef long __kernel_off_t;
-typedef long long __kernel_loff_t;
-typedef int __kernel_pid_t;
-typedef int __kernel_ipc_pid_t;
-typedef unsigned int __kernel_uid_t;
-typedef unsigned int __kernel_gid_t;
-typedef unsigned long __kernel_size_t;
-typedef long __kernel_ssize_t;
-typedef long __kernel_ptrdiff_t;
-typedef long __kernel_time_t;
-typedef int __kernel_timer_t;
-typedef int __kernel_clockid_t;
-typedef long __kernel_suseconds_t;
-typedef long __kernel_clock_t;
-typedef int __kernel_daddr_t;
-typedef char * __kernel_caddr_t;
-typedef unsigned short __kernel_uid16_t;
-typedef unsigned short __kernel_gid16_t;
-typedef unsigned int __kernel_uid32_t;
-typedef unsigned int __kernel_gid32_t;
-
-typedef unsigned int __kernel_old_uid_t;
-typedef unsigned int __kernel_old_gid_t;
-typedef unsigned long __kernel_old_dev_t;
-
-typedef struct {
- int val[2];
-} __kernel_fsid_t;
-
-#ifndef __GNUC__
-
-#define __FD_SET(d, set) ((set)->fds_bits[__FDELT(d)] |= __FDMASK(d))
-#define __FD_CLR(d, set) ((set)->fds_bits[__FDELT(d)] &= ~__FDMASK(d))
-#define __FD_ISSET(d, set) (((set)->fds_bits[__FDELT(d)] & __FDMASK(d)) != 0)
-#define __FD_ZERO(set) \
- ((void) memset ((__ptr_t) (set), 0, sizeof (__kernel_fd_set)))
-
-#else /* __GNUC__ */
-
-#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) \
- || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 0)
-/* With GNU C, use inline functions instead so args are evaluated only once: */
-
-#undef __FD_SET
-static __inline__ void __FD_SET(unsigned long fd, __kernel_fd_set *fdsetp)
-{
- unsigned long _tmp = fd / __NFDBITS;
- unsigned long _rem = fd % __NFDBITS;
- fdsetp->fds_bits[_tmp] |= (1UL<<_rem);
-}
-
-#undef __FD_CLR
-static __inline__ void __FD_CLR(unsigned long fd, __kernel_fd_set *fdsetp)
-{
- unsigned long _tmp = fd / __NFDBITS;
- unsigned long _rem = fd % __NFDBITS;
- fdsetp->fds_bits[_tmp] &= ~(1UL<<_rem);
-}
-
-#undef __FD_ISSET
-static __inline__ int __FD_ISSET(unsigned long fd, __kernel_fd_set *p)
-{
- unsigned long _tmp = fd / __NFDBITS;
- unsigned long _rem = fd % __NFDBITS;
- return (p->fds_bits[_tmp] & (1UL<<_rem)) != 0;
-}
-
-/*
- * This will unroll the loop for the normal constant case (8 ints,
- * for a 256-bit fd_set)
- */
-#undef __FD_ZERO
-static __inline__ void __FD_ZERO(__kernel_fd_set *p)
-{
- unsigned long *tmp = (unsigned long *)p->fds_bits;
- int i;
-
- if (__builtin_constant_p(__FDSET_LONGS)) {
- switch (__FDSET_LONGS) {
- case 16:
- tmp[12] = 0; tmp[13] = 0; tmp[14] = 0; tmp[15] = 0;
- tmp[ 8] = 0; tmp[ 9] = 0; tmp[10] = 0; tmp[11] = 0;
-
- case 8:
- tmp[ 4] = 0; tmp[ 5] = 0; tmp[ 6] = 0; tmp[ 7] = 0;
-
- case 4:
- tmp[ 0] = 0; tmp[ 1] = 0; tmp[ 2] = 0; tmp[ 3] = 0;
- return;
- }
- }
- i = __FDSET_LONGS;
- while (i) {
- i--;
- *tmp = 0;
- tmp++;
- }
-}
-
-#endif /* defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) */
-#endif /* __GNUC__ */
-#endif /* _PPC64_POSIX_TYPES_H */
^ permalink raw reply
* AW: emac driver broken in 2.6.12.2 ?
From: David Grab @ 2005-09-19 13:59 UTC (permalink / raw)
To: 'Peter Fercher', benh; +Cc: 'linux-ppc-embedded'
In-Reply-To: <004101c5bd1f$3d1b91e0$dbe5fed4@scsad.scs.ch>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
Message>> emac: IBM EMAC Ethernet driver, version 2.0
>> Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> eth0: IBM ema c, MAC 00:00:00:00:00:00
>> eth0: Found Generic MII PHY (0x00)
>> eth1: IBM emac, MAC 00:00:00:00:00:00
>> eth1: Found Generic MII PHY (0x01)
Are you sure that you?ve configured your ethernet driver? There is no MAC
address defined. And the PHY address is really located at 0x0 or 0x1? If not
you have also to configure the offset from which address the PHY routine
start in your board specific files like for OCOTEA reference board in
linux-2.6.12/arch/ppc/platforms/4xx/ocotea.c
Best regards,
David
[-- Attachment #2: Type: text/html, Size: 3801 bytes --]
^ permalink raw reply
* Re: PPC4xx cleanup
From: Matt Porter @ 2005-09-19 14:08 UTC (permalink / raw)
To: Dan Malek; +Cc: Stefan Roese, linuxppc-embedded
In-Reply-To: <732f7227a8bcc2f3115e52633a60f120@embeddededge.com>
On Thu, Sep 15, 2005 at 03:03:23PM -0400, Dan Malek wrote:
>
> On Sep 15, 2005, at 12:25 PM, Matt Porter wrote:
>
> > Sounds great to me. This will have to wait to go in mainline until
> > after 2.6.14 is out though.
>
> If you are considering this, I think you should be looking at the
> recent U-Boot discussion and patches for the "flat OF tree" and
> follow that path.
We need to fix the kernel versus the current version of U-boot's data
passing scheme for ppc32. Once the flat OF tree stuff is mainline we
can convert to it...except we have to have a wrapper for older versions
of u-boot assuming that somebody will have changed U-boot so 4xx dumps
a flat OF tree.
-Matt
^ permalink raw reply
* Re: emac driver broken in 2.6.12.2 ?
From: Josh Boyer @ 2005-09-19 13:42 UTC (permalink / raw)
To: Peter Fercher; +Cc: linux-ppc-embedded
In-Reply-To: <004101c5bd1f$3d1b91e0$dbe5fed4@scsad.scs.ch>
On Mon, 2005-09-19 at 15:37 +0200, Peter Fercher wrote:
> hi,
>
> i have problems with the IBM EMAC with 2.6.12.2 (the driver worked
> with 2.4.25)
> running on ppc405EP octobus board. Cross compiled on x86 using the
> eldk-3.1 toolchain
>
> any hints ?
I think you'd need to be more explicit about what "problems" means.
Hard to give hints with what you have here.
josh
^ permalink raw reply
* RE: emac driver broken in 2.6.12.2 ?
From: Josh Boyer @ 2005-09-19 14:23 UTC (permalink / raw)
To: Peter Fercher; +Cc: 'linux-ppc-embedded'
In-Reply-To: <004f01c5bd21$394104e0$dbe5fed4@scsad.scs.ch>
On Mon, 2005-09-19 at 15:51 +0200, Peter Fercher wrote:
> hi,
>
> when you read the output I have pasted there you can see the following (also
> in my origninal mail)
<snip>
>
>
> I think that this MAC addresses are crap (sorry if not formulated clearly
> enough for you ;)
> am I wrong ?
No, you're not wrong. My brain just didn't parse that as a problem with
the emac code itself.
Anyway, I think David and Stefan have pointed you in the right
direction.
josh
^ permalink raw reply
* Re: emac driver broken in 2.6.12.2 ?
From: Matt Porter @ 2005-09-19 14:28 UTC (permalink / raw)
To: Josh Boyer; +Cc: Peter Fercher, 'linux-ppc-embedded'
In-Reply-To: <1127139816.3211.4.camel@windu.rchland.ibm.com>
On Mon, Sep 19, 2005 at 09:23:36AM -0500, Josh Boyer wrote:
> On Mon, 2005-09-19 at 15:51 +0200, Peter Fercher wrote:
> > I think that this MAC addresses are crap (sorry if not formulated clearly
> > enough for you ;)
> > am I wrong ?
>
> No, you're not wrong. My brain just didn't parse that as a problem with
> the emac code itself.
>
> Anyway, I think David and Stefan have pointed you in the right
> direction.
Yep, he's got to configure the driver properly for his platform.
-Matt
^ permalink raw reply
* Re: Git tree for the 32/64 merge
From: Kumar Gala @ 2005-09-19 14:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17197.65270.548340.377011@cargo.ozlabs.ibm.com>
On Sep 18, 2005, at 6:57 PM, Paul Mackerras wrote:
> I have created a git tree on kernel.org as a place to accumulate the
> patches for the ppc32/ppc64 merge. It is at:
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-
> merge.g
> it
>
> It doesn't include the objects in Linus' tree; instead it has an
> objects/info/alternates file pointing to Linus' tree.
>
> This tree contains all the patches I found in a scan through my inbox
> that relate to the merge and haven't already gone to Linus. If you
> have a patch that should go in, please resend it.
Paul,
You pulled the wrong version of the Kconfig patch for prep/chrp/
pmac. There is a newer version that doesn't leave duplicated 'bool's
in the Kconfig:
http://patchwork.ozlabs.org/linuxppc/patch?id=2447
- kumar
^ permalink raw reply
* PATCH powerpc: Revised merge asm-ppc*/hardirq.h
From: linuxppc @ 2005-09-19 14:32 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
This is a revised patch to merge asm-ppc*/hardirq.h.
It removes some unnecessary #includes, but then requires
the addition of #include <asm/irq.h> in PPC32's hw_irq.h
much like ppc64 already does. Furthermore, several
unnecessary #includes were removed from some ppc32 boards
in order to break resulting bad #include cycles.
Builds pSeries_defconfig and all ppc32 platforms except
the already b0rken bseip.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
arch/ppc/platforms/83xx/mpc834x_sys.h | 1 -
arch/ppc/platforms/85xx/mpc85xx_ads_common.h | 1 -
arch/ppc/platforms/85xx/stx_gp3.h | 1 -
include/asm-powerpc/hardirq.h | 24 ++++++++++++++++++++
include/asm-ppc/hardirq.h | 31 --------------------------
include/asm-ppc/hw_irq.h | 1 +
include/asm-ppc64/hardirq.h | 27 -----------------------
7 files changed, 25 insertions(+), 61 deletions(-)
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h b/arch/ppc/platforms/83xx/mpc834x_sys.h
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -19,7 +19,6 @@
#include <linux/config.h>
#include <linux/init.h>
-#include <linux/seq_file.h>
#include <syslib/ppc83xx_setup.h>
#include <asm/ppcboot.h>
diff --git a/arch/ppc/platforms/85xx/mpc85xx_ads_common.h b/arch/ppc/platforms/85xx/mpc85xx_ads_common.h
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.h
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.h
@@ -19,7 +19,6 @@
#include <linux/config.h>
#include <linux/init.h>
-#include <linux/seq_file.h>
#include <asm/ppcboot.h>
#define BOARD_CCSRBAR ((uint)0xe0000000)
diff --git a/arch/ppc/platforms/85xx/stx_gp3.h b/arch/ppc/platforms/85xx/stx_gp3.h
--- a/arch/ppc/platforms/85xx/stx_gp3.h
+++ b/arch/ppc/platforms/85xx/stx_gp3.h
@@ -21,7 +21,6 @@
#include <linux/config.h>
#include <linux/init.h>
-#include <linux/seq_file.h>
#include <asm/ppcboot.h>
#define BOARD_CCSRBAR ((uint)0xe0000000)
diff --git a/include/asm-powerpc/hardirq.h b/include/asm-powerpc/hardirq.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/hardirq.h
@@ -0,0 +1,24 @@
+#ifndef _ASM_POWERPC_HARDIRQ_H
+#define _ASM_POWERPC_HARDIRQ_H
+
+/* The __last_jiffy_stamp field is needed to ensure that no decrementer
+ * interrupt is lost on SMP machines. Since on most CPUs it is in the same
+ * cache line as local_irq_count, it is cheap to access and is also used on UP
+ * for uniformity.
+ */
+typedef struct {
+ unsigned int __softirq_pending; /* set_bit is used on this */
+ unsigned int __last_jiffy_stamp;
+} ____cacheline_aligned irq_cpustat_t;
+
+#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
+
+#define last_jiffy_stamp(cpu) __IRQ_STAT((cpu), __last_jiffy_stamp)
+
+static inline void ack_bad_irq(int irq)
+{
+ printk(KERN_CRIT "illegal vector %d received!\n", irq);
+ BUG();
+}
+
+#endif /* _ASM_POWERPC_HARDIRQ_H */
diff --git a/include/asm-ppc/hardirq.h b/include/asm-ppc/hardirq.h
deleted file mode 100644
--- a/include/asm-ppc/hardirq.h
+++ /dev/null
@@ -1,31 +0,0 @@
-#ifdef __KERNEL__
-#ifndef __ASM_HARDIRQ_H
-#define __ASM_HARDIRQ_H
-
-#include <linux/config.h>
-#include <linux/cache.h>
-#include <linux/smp_lock.h>
-#include <asm/irq.h>
-
-/* The __last_jiffy_stamp field is needed to ensure that no decrementer
- * interrupt is lost on SMP machines. Since on most CPUs it is in the same
- * cache line as local_irq_count, it is cheap to access and is also used on UP
- * for uniformity.
- */
-typedef struct {
- unsigned long __softirq_pending; /* set_bit is used on this */
- unsigned int __last_jiffy_stamp;
-} ____cacheline_aligned irq_cpustat_t;
-
-#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
-
-#define last_jiffy_stamp(cpu) __IRQ_STAT((cpu), __last_jiffy_stamp)
-
-static inline void ack_bad_irq(int irq)
-{
- printk(KERN_CRIT "illegal vector %d received!\n", irq);
- BUG();
-}
-
-#endif /* __ASM_HARDIRQ_H */
-#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/hw_irq.h b/include/asm-ppc/hw_irq.h
--- a/include/asm-ppc/hw_irq.h
+++ b/include/asm-ppc/hw_irq.h
@@ -7,6 +7,7 @@
#include <asm/ptrace.h>
#include <asm/reg.h>
+#include <asm/irq.h>
extern void timer_interrupt(struct pt_regs *);
diff --git a/include/asm-ppc64/hardirq.h b/include/asm-ppc64/hardirq.h
deleted file mode 100644
--- a/include/asm-ppc64/hardirq.h
+++ /dev/null
@@ -1,27 +0,0 @@
-#ifndef __ASM_HARDIRQ_H
-#define __ASM_HARDIRQ_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.
- */
-
-#include <linux/config.h>
-#include <linux/cache.h>
-#include <linux/preempt.h>
-
-typedef struct {
- unsigned int __softirq_pending;
-} ____cacheline_aligned irq_cpustat_t;
-
-#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
-
-static inline void ack_bad_irq(int irq)
-{
- printk(KERN_CRIT "illegal vector %d received!\n", irq);
- BUG();
-}
-
-#endif /* __ASM_HARDIRQ_H */
^ permalink raw reply
* Re: [PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
From: Stefan Roese @ 2005-09-19 15:06 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050919065942.A25356@cox.net>
Hi Matt,
On Monday 19 September 2005 15:59, Matt Porter wrote:
> On Mon, Sep 19, 2005 at 01:02:14PM +0200, Stefan Roese wrote:
> > Just to be sure: The 44x boot-wrapper approach you mention is
> > "boot/simple/pibs.c"?
>
> Yes, there's both boot/simple/pibs.c and boot/simple/openbios.c that
> were created so we could have the default firmware and u-boot use the
> same kernel build.
Yes, that's what I thought. But Eugene mentioned, that he boots vmlinux
without any boot-wrapper on the OpenBIOS targets (except Ebony probably). You
would loose this possibility, if I add this wrapper and switch from OpenBIOS
to U-Boot bd_info struct in the kernel.
Did I miss something here? How should I proceed?
Best regards,
Stefan
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: Frank @ 2005-09-19 15:09 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
In-Reply-To: <200509191155.36540.david.jander@protonic.nl>
--- David JandJandervidaviddjandertprotonic nlote:
>
> Hi all,
>
> I am looking for a reliable way to store logflogfilesflash.
> The logflogfiles
> written by syslsyslogd The problem is that I am running on a
MPC8MPCprocessor, and
> kernel 2.6 is not
> quite there yet for that processor, so I have to stick with
> 2.4.
> Kernel of choice seems to be denxdenxulinuxppc_devedevelt I
> cannot trust the
> version of jffsjffsed in that kernel anymore. SomtSomtimescgc>
crashes with a
> BUG() in line 139, and sometimes processes are frozen for a
> looolooonge
> waiting for GC. GChave debugged that problem a little bit, and
> definitely,
> the FLASH access works ok, okd the chip is new. No CRC-CRC
> read-errors, but
> still gc.cgcrashes.
> The version of mtd/mtdsjffsivers in that kernel seem to be
> from march/2005 cvs cvs code, but when I read the following, I
get even more scared:
>
httphttpww.wwwulinux.mtdrinfradead/source.htmlhtmlnkernelversions
> So, I need something different. jffsjffs maybe ?
> This must be a very common task (to store logflogfilesflash),
> but I just can't
> seem to find the right way to do it.
>
> Any advice is highly appreciated.
>
> Sincerely,
>
> --
> David JandJanderProtProtonicland.
I'm using JFFSJFFS a 860 based board (to store log files
amonamongster things) and haven't seen any of the problems
you're expeexperiencing I were you, I would double check my
configuration settings...
> _______________________________________________
> LinuLinuxppcedded mailing list
> LinuLinuxppcedded@ozlaozlabs
> httphttpszlaozlabs/mailman/listlistinfoulinuxppcedded
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* HELLO
From: jonaris0 @ 2005-09-19 15:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
Hello,
My name is Col(Rtd) Jon Aristide,brother to the
exiled President of Haiti,(Dr.Jean Bertrand
Aristide)
Due to the evolution against the government
of my brother caused by his political opponents in
Haiti,we managed to enter a red cross airplane that
was evacuating foreigners and we are presently on
political assylum in Central African Repubilc(CAR)
I wish to invest in Real Estate and commercial
Properties and equally start a new life in your
country with your assistance and cooperation.If you
are in a good position to help my family,please send
an e-mail to my personal address below indicating your
desire to help meinvest this funds in your country and
beyond.
I urgently await your e-mail letter.
Reply to my confidential mail box: jonaris05@yahoo.com
Best Regards and hope to meet you soon.
God bless,
Col Jon(Rtd).
^ permalink raw reply
* HELLO
From: jonaris0 @ 2005-09-19 15:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
Hello,
My name is Col(Rtd) Jon Aristide,brother to the
exiled President of Haiti,(Dr.Jean Bertrand
Aristide)
Due to the evolution against the government
of my brother caused by his political opponents in
Haiti,we managed to enter a red cross airplane that
was evacuating foreigners and we are presently on
political assylum in Central African Repubilc(CAR)
I wish to invest in Real Estate and commercial
Properties and equally start a new life in your
country with your assistance and cooperation.If you
are in a good position to help my family,please send
an e-mail to my personal address below indicating your
desire to help meinvest this funds in your country and
beyond.
I urgently await your e-mail letter.
Reply to my confidential mail box: jonaris05@yahoo.com
Best Regards and hope to meet you soon.
God bless,
Col Jon(Rtd).
^ permalink raw reply
* Re: kernel 2.6.12.2, octobus ppc405EP: GUNZIP ERROR - must RESET board to recover
From: Wolfgang Denk @ 2005-09-19 15:33 UTC (permalink / raw)
To: Peter Fercher; +Cc: linux-ppc-embedded
In-Reply-To: <002e01c5bcfa$c500d860$dbe5fed4@scsad.scs.ch>
In message <002e01c5bcfa$c500d860$dbe5fed4@scsad.scs.ch> you wrote:
>
...
> TFTP from server 192.168.1.1; our IP address is 192.168.1.2
> Filename 'uImage-2.6.12.2'.
> Load address: 0x100000
...
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 919184 Bytes = 897.6 kB
...
> GUNZIP ERROR - must RESET board to recover.
Your load address is much too low for a kernel that big.
> any hints ?
Yes. RTFM. RTFAQ. See especially
http://www.denx.de/twiki/bin/view/DULG/LinuxUncompressingError
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 important thing about being a leader is not being right or wrong,
but being *certain*. - Terry Pratchett, _Truckers_
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: Wolfgang Denk @ 2005-09-19 15:37 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200509191155.36540.david.jander@protonic.nl>
In message <200509191155.36540.david.jander@protonic.nl> you wrote:
>
> Kernel of choice seems to be denx linuxppc_2_4_devel, but I cannot trust the
> version of jffs2 used in that kernel anymore. Somtimes gc.c crashes with a
> BUG() in line 139, and sometimes processes are frozen for a looong time
Can you provide a little more details? The MTD / JFFS2 code in this
kernel is not too old, andwe use it in a couple of projects without
such problems.
> waiting for GC. I have debugged that problem a little bit, and definitely,
> the FLASH access works ok, and the chip is new. No CRC- or read-errors, but
> still gc.c crashes.
Can you provide soem more information for debugging?
> The version of mtd/jffs2 drivers in that kernel seem to be from march/2005 cvs
> code, but when I read the following, I get even more scared:
> http://www.linux-mtd.infradead.org/source.html#kernelversions
Don't worry. We backported the MTD / JFFS2 code. See the history of
changes on our CVS or git server.
> This must be a very common task (to store logfiles in flash), but I just can't
> seem to find the right way to do it.
Note that log files may cause a lot of trouble when using a JFFS2
file system. Youmay want to addd a buffering layer, like pramfs in a
dedicated RAM area (SRAM ideally).
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
Never underestimate the bandwidth of a station wagon full of tapes.
-- Dr. Warren Jackson, Director, UTCS
^ permalink raw reply
* 8250 serial driver on MPC8272ADS board
From: Landau, Bracha @ 2005-09-19 15:41 UTC (permalink / raw)
To: linuxppc-embedded
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?
Thanks,
Bracha
^ permalink raw reply
* Re: [PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
From: Matt Porter @ 2005-09-19 15:21 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200509191706.24298.sr@denx.de>
On Mon, Sep 19, 2005 at 05:06:23PM +0200, Stefan Roese wrote:
> Hi Matt,
>
> On Monday 19 September 2005 15:59, Matt Porter wrote:
> > On Mon, Sep 19, 2005 at 01:02:14PM +0200, Stefan Roese wrote:
> > > Just to be sure: The 44x boot-wrapper approach you mention is
> > > "boot/simple/pibs.c"?
> >
> > Yes, there's both boot/simple/pibs.c and boot/simple/openbios.c that
> > were created so we could have the default firmware and u-boot use the
> > same kernel build.
>
> Yes, that's what I thought. But Eugene mentioned, that he boots vmlinux
> without any boot-wrapper on the OpenBIOS targets (except Ebony probably). You
> would loose this possibility, if I add this wrapper and switch from OpenBIOS
> to U-Boot bd_info struct in the kernel.
>
> Did I miss something here? How should I proceed?
I thought he was talking about booting a uImage, which from the
perspective of not having the zImage wrapper around it, is like booting
a vmlinux. He may referring to his own production firmware capabilities
too. I'll let him comment.
In any case, if you follow the model used on 44x where the board info
is the standard method of passing info into the kernel, then we'll be
alright. This means you have to add additional code in the
arch/ppc/boot/simple/openbios.c shim to generate some compatible board
info.
-Matt
^ permalink raw reply
* Re: [PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot
From: Eugene Surovegin @ 2005-09-19 17:14 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200509191706.24298.sr@denx.de>
On Mon, Sep 19, 2005 at 05:06:23PM +0200, Stefan Roese wrote:
> Hi Matt,
>
> On Monday 19 September 2005 15:59, Matt Porter wrote:
> > On Mon, Sep 19, 2005 at 01:02:14PM +0200, Stefan Roese wrote:
> > > Just to be sure: The 44x boot-wrapper approach you mention is
> > > "boot/simple/pibs.c"?
> >
> > Yes, there's both boot/simple/pibs.c and boot/simple/openbios.c that
> > were created so we could have the default firmware and u-boot use the
> > same kernel build.
>
> Yes, that's what I thought. But Eugene mentioned, that he boots vmlinux
> without any boot-wrapper on the OpenBIOS targets (except Ebony probably).
Bad phrasing on my part. What I meant was "U-Boot is different from
OpenBIOS targets already, as with U-Boot we don't use any boot-wrapper
like with OpenBIOS".
Sorry for confusion :).
--
Eugene
^ permalink raw reply
* HELLO
From: jonaris0 @ 2005-09-19 17:25 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
Hello,
My name is Col(Rtd) Jon Aristide,brother to the
exiled President of Haiti,(Dr.Jean Bertrand
Aristide)
Due to the evolution against the government
of my brother caused by his political opponents in
Haiti,we managed to enter a red cross airplane that
was evacuating foreigners and we are presently on
political assylum in Central African Repubilc(CAR)
I wish to invest in Real Estate and commercial
Properties and equally start a new life in your
country with your assistance and cooperation.If you
are in a good position to help my family,please send
an e-mail to my personal address below indicating your
desire to help meinvest this funds in your country and
beyond.
I urgently await your e-mail letter.
Reply to my confidential mail box: jonaris05@yahoo.com
Best Regards and hope to meet you soon.
God bless,
Col Jon(Rtd).
^ permalink raw reply
* HELLO
From: jonaris0 @ 2005-09-19 17:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
Hello,
My name is Col(Rtd) Jon Aristide,brother to the
exiled President of Haiti,(Dr.Jean Bertrand
Aristide)
Due to the evolution against the government
of my brother caused by his political opponents in
Haiti,we managed to enter a red cross airplane that
was evacuating foreigners and we are presently on
political assylum in Central African Repubilc(CAR)
I wish to invest in Real Estate and commercial
Properties and equally start a new life in your
country with your assistance and cooperation.If you
are in a good position to help my family,please send
an e-mail to my personal address below indicating your
desire to help meinvest this funds in your country and
beyond.
I urgently await your e-mail letter.
Reply to my confidential mail box: jonaris05@yahoo.com
Best Regards and hope to meet you soon.
God bless,
Col Jon(Rtd).
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: David Jander @ 2005-09-19 17:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050919153747.78ACC352682@atlas.denx.de>
Hi again,
Thanks for helping,
On Monday 19 September 2005 17:37, Wolfgang Denk wrote:
>[...]
> Can you provide a little more details? The MTD / JFFS2 code in this
> kernel is not too old, andwe use it in a couple of projects without
> such problems.
Ok, good you asked, because I am willing to debug the problem until I get to
the point where it fails, but I will need help, because I am not at home in
jffs2 source-code nor its CVS history.
Here are more details:
Kernel: Denx CVS from around july 2005 or something. AFAIK there are no
further modifications other than BSP-specific stuff to the MTD code since
that day, so I won't bother upgrading any further right now.
Hardware: MPC852T custom board with a 32Mbyte mirror-bit flash-chip (x16 bus)
Software: System based on ELDK-3.1.1. Intended flash-layout and use:
rootfs : 10Mb, ro, hardly ever changed
app : 6Mb, ro, changed on software-upgrade by replacing partition.
log+config : 12Mb, rw
The log+config partition is extremely oversized, because we are aware of the
inefficiency of jffs2 for such purposes, we have the available space and we
want to stay out of trouble. Syslog writes to 4 log-files which are limited
in size to 50..100kbyte each. Logs are then rotated and one rotated copy is
kept. Maximum flash use is around 800kbyte for logs + 50kbyte for config
data. On a 12Mbyte partition, that shouldn't get us into trouble AFAIK.
> > waiting for GC. I have debugged that problem a little bit, and
> > definitely, the FLASH access works ok, and the chip is new. No CRC- or
> > read-errors, but still gc.c crashes.
>
> Can you provide soem more information for debugging?
Unfortunately right now I don't have debug messages, because since I installed
a kernel with debugging turned on in the jffs2 driver, the problem hasn't
repeated. I am working on that.
What happened: System boots, all fs are mounted. The first app that writes
something to the log-partition (in this case a config file that is
overwritten) causes the GC thread for that partition to crash with a BUG() in
line 139 of gc.c, and the application freezes forever. Since GC is dead, all
further write-accesses to that partition also hang forever.
The problem seems to ocurr after a few times power-cycling the board. We never
intended it to shut-down nicely, if it is at all ever shut-down, so it must
be able to survive quite a few power-cycles without breaking.
After a few more power-cycles, the problem is gone again. Each time GC kicks
in, it does something, but it crashes before finishing the job, so each time
the numbers reported by the printk() in line 138 change, and eventually it
work again.
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?
I mean, if hardware really was a problem, then I should also get at least
CRC-errors from jffs2, shouldn't I? IMHO at least, jffs2 should be robust
enough to not crash on flash-errors, shouldn't it?
Also, I am pretty certain that the hardware is good.... but you never know...
> > The version of mtd/jffs2 drivers in that kernel seem to be from
> > march/2005 cvs code, but when I read the following, I get even more
> > scared:
> > http://www.linux-mtd.infradead.org/source.html#kernelversions
>
> Don't worry. We backported the MTD / JFFS2 code. See the history of
> changes on our CVS or git server.
I am having trouble finding the right history, but that could be due to the
fact that I am not very good at CVS (we use subversion which is slightly
different) ;-)
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).
> > This must be a very common task (to store logfiles in flash), but I just
> > can't seem to find the right way to do it.
>
> Note that log files may cause a lot of trouble when using a JFFS2
> file system. Youmay want to addd a buffering layer, like pramfs in a
> dedicated RAM area (SRAM ideally).
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.
Best Regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: Shawn Jin @ 2005-09-19 18:40 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20050919153747.78ACC352682@atlas.denx.de>
> > This must be a very common task (to store logfiles in flash), but I jus=
t can't
> > seem to find the right way to do it.
>=20
> Note that log files may cause a lot of trouble when using a JFFS2
> file system. Youmay want to addd a buffering layer, like pramfs in a
> dedicated RAM area (SRAM ideally).
What's the trouble caused by log files when using a JFFS2? I'm not
aware of that. Any pointers to where I should look into are much
appreciated.
Best regards,
-Shawn.
^ permalink raw reply
* GT64260_eth (Ethernet) Driver
From: Earl Olsen @ 2005-09-19 18:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
Dieu:
I saw that you had a problem with uncachedPages in gt64260_eth.c.
I'm having the same problem you describe. Did you ever get this
resolved?
Thanks for any help
--
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: 2178 bytes --]
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: Wolfgang Denk @ 2005-09-19 19:21 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200509191926.12736.david.jander@protonic.nl>
In message <200509191926.12736.david.jander@protonic.nl> you wrote:
>
> What happened: System boots, all fs are mounted. The first app that writes
> something to the log-partition (in this case a config file that is
> overwritten) causes the GC thread for that partition to crash with a BUG() in
> line 139 of gc.c, and the application freezes forever. Since GC is dead, all
> further write-accesses to that partition also hang forever.
Are you 100% sure your system is stable and wihout any memory errors?
Never seen any other erros or crashes?
> 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.
> I mean, if hardware really was a problem, then I should also get at least
> CRC-errors from jffs2, shouldn't I? IMHO at least, jffs2 should be robust
> enough to not crash on flash-errors, shouldn't it?
I don't think it's a flash error. If there is data corruption, then
it's more likely the SDRAM.
> 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
Make sure to use at least the version tagged as LABEL_2005_05_09_1245
or later.
> 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.
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
A dog always bit deepest on the veterinary hand.
- Terry Pratchett, _Wyrd Sisters_
^ permalink raw reply
* Re: Which way to store log in flash on mpc8xx?
From: Jörn Engel @ 2005-09-19 19:07 UTC (permalink / raw)
To: Shawn Jin; +Cc: linux-mtd, David Jander, linuxppc-embedded
In-Reply-To: <c3d0340b050919114040d0a0fe@mail.gmail.com>
On Mon, 19 September 2005 11:40:05 -0700, Shawn Jin wrote:
>
> > > This must be a very common task (to store logfiles in flash), but I just can't
> > > seem to find the right way to do it.
> >
> > Note that log files may cause a lot of trouble when using a JFFS2
> > file system. Youmay want to addd a buffering layer, like pramfs in a
> > dedicated RAM area (SRAM ideally).
>
> What's the trouble caused by log files when using a JFFS2? I'm not
> aware of that. Any pointers to where I should look into are much
> appreciated.
I guess this should become a FAQ item.
JFFS2 creates one or more nodes whenever sys_write is called.
Unbuffered log entries are usually quite small, so a single node is
written. Let's assume the worst case, just for fun, writes of a
single by.
Now, each node is prepended by a struct jffs2_raw_inode of 64 bytes.
So you're causing the first problem:
1. Up to 65x the raw file data is written to flash.
Which means you waste bus bandwidth, was flash space and waste flash
lifetime. After GC, most of those nodes should get combined to 4k
nodes (plus 64 bytes for the header). Now, JFFS2 also requires an
in-memory structure per node, the struct jffs2_raw_node_ref, weighing
in at 16 or 24 bytes, if you have a 32bit or 64bit arch. Those will
cost you precious memory:
2. Up to 24x the raw file data is required in DRAM.
Next problem is with GC accounting. JFFS2 only differentiates between
valid and obsolete data. After writing a huge logfile, all of its
nodes are still valid. Therefore GC will never try to GC such nodes,
unless they happen to sit in an erase block with a lot of obsolete
data. And even then, they could get copied as-is, with no combining.
3. JFFS2 GC is too stupid to detect miniature nodes and combine them.
So, your problem 1 and 2 will not go away if you wait long enough.
Renaming the log file also won't help. The only cure would be to
*copy* it to the new location and delete the original file afterwards.
Or - alternatively - to fix JFFS2 GC and send a patch.
Or - as already proposed - by writing in larger chunks in the first
place.
If you decide to fix JFFS2 GC, I'd be happy to review the patches and
merge them if deemed worthy.
Jörn
--
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra
^ 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