-Original Message-
From: Scott Wood [mailto:scottw...@freescale.com]
What problems have you been having with upstream kernels on mpc8313erdb,
other than this IRQ issue? It should work, though the BSP may have extra
features that haven't been pushed upstream.
I have been working
-Original Message-
From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
Sent: Friday, October 16, 2009 9:04 PM
To: Dan Williams
Cc: Suresh Vishnu-B05022; herb...@gondor.apana.org.au;
linux-ker...@vger.kernel.org; linux-r...@vger.kernel.org;
linuxppc-...@ozlabs.org;
reading a bogus address in u-boot gives:
= md 0x8800
8800:Machine check in kernel mode.
Caused by (from msr): regs 0ff0ec28 Unknown values in msr
NIP: 111C XER: 205F LR: 0FFDB104 REGS: 0ff0ec28 TRAP: 0200 DAR:
MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00:
Scott Wood wrote:
Felix Radensky wrote:
OK, no problem. I just wanted to get an idea of what should be done.
Should the NOR code poll some eLBC register to wait for completion of
NAND special operation ? Can you tell what register is relevant ?
I was thinking you'd just share a mutex with the
On Tue, Oct 20, 2009 at 12:01:19PM +0200, Richard Cochran wrote:
-Original Message-
From: Scott Wood [mailto:scottw...@freescale.com]
What problems have you been having with upstream kernels on mpc8313erdb,
other than this IRQ issue? It should work, though the BSP may have extra
On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
BUILD_BUG_ON used to use the optimizer to do code elimination or fail
at link time; it was changed to first the size of a negative array (a
nicer compile time error), then (in
8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
On 10/20/09, Américo Wang xiyou.wangc...@gmail.com wrote:
On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
BUILD_BUG_ON used to use the optimizer to do code elimination or fail
at link time; it was changed to first the size of a negative array (a
nicer compile time error), then (in
I use a board with MPC866T and 2.6.28 Linux Kernel. Occasionally, the
unflattened device is corrupted after unflatten_device_tree() which
causes crash of kernel when device tree is traversed later on.
I looked at the fixes in lib/lmb.c, arch/powerpc/mm, arch/powerpc/kernel
etc since 2.6.28 to
On Tue, 2009-10-20 at 09:10 -0700, Lixin Yao wrote:
I use a board with MPC866T and 2.6.28 Linux Kernel. Occasionally, the
unflattened device is corrupted after “unflatten_device_tree()” which
causes crash of kernel when device tree is traversed later on.
I looked at the fixes in lib/lmb.c,
