headers
mike zheng | 4 Feb 2009 19:36
Picon

Kernel Oops when load MTD NOR driver

Hi All,

I have kernel Oops when load MTD NOR driver on 2.6.13.7. The flash I
have is 29LV160, physical address is 0xbf80,0000. Any idea on this
issue?

Thanks,

Mike

# insmod ./gen_probe.ko
# insmod ./cfi_util.ko
# insmod ./cfi_probe.ko
# insmod ./cfi_cmdset_0002.ko
# insmod ./1140e-mtd-nor.ko
Data bus error, epc == c0092204, ra == c00926a4
Oops[#1]:
Cpu 0
$ 0   : 00000000 00000000 c0480020 00000020
$ 4   : c0136550 00000000 00000002 00000002
$ 8   : 00000001 00000001 00000002 00020000
$12   : 80442e60 00000001 00200200 00100100
$16   : c0136550 00000002 80637de8 00000000
$20   : 00000016 00000000 00000016 c0136550
$24   : 00000008 c0095150
$28   : 80634000 80637d88 00000029 c00926a4
Hi    : 00000000
Lo    : 00000002
epc   : c0092204 qry_present+0x204/0x32c [cfi_probe]     Tainted: P
ra    : c00926a4 cfi_probe_chip+0x364/0x1450 [cfi_probe]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 22 Feb 2009 23:42

Re: Lock-up on PPC64

On Sun, 2009-02-22 at 11:35 +0300, malc wrote:
> After writing valgrind tool that was simulating Cell XER.SO syscall
> (mis)behaviour (pre ab598b6680f1e74c267d1547ee352f3e1e530f89 that is)
> and banging my had against the wall for a while trying to figure out
> which of the failing syscalls was responsible, i've tried to be simple
> and after only ~30 minutes came up with this, rather short, piece of
> code that knocks pre XER.SO patched kernels out cold:
> 
> gcc -o xer -x assembler /dev/stdin -nostdlib <<eof
> .globl _start
> _start:
>          addis 0,0,0x8000
>          mtxer 0
>          addi 0,0,1
>          sc

Allright, but the XER patch fixes it... interesting. Oh well, I'll try
to figure out at some stage where we get something wrong in those old
kernels.

Cheers,
Ben.
Permalink | Reply | 0 comments |
headers
Eric Cottrell | 23 Feb 2009 00:23
Favicon

Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image

Hello,

This is getting frustrating and I am beginning to think someone messed this board up and returned it.  I would
think it would boot up the default flash image out of the box with very little trouble.

Board is a MPC8313e-RDB Rev A4.  I set the dip switches per the instructions, S4 all off and S3 all on.
Uboot comes up but I can not boot either the default images in the flash or images I built with ltib and tftped. 
I did not touch the flash.  I get WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND and ERROR:
/chosen node create failed - must RESET the board to recover.  The board resets.

A friend has the same board but his U-Boot is Version 1.3.0 (Jun 19 2008 - 13:41:53) MPC83XX and some
environment variables are different.  I do not have the BOOTCMD variable but entered it manually.

I tried searching for on a solution but it is confusing because if aliases are needed why does the default dtb
in the flash omit them?

This is what happens:

U-Boot 1.3.3 (Dec  8 2008 - 09:51:15) MPC83XX

Reset Status:

CPU:   e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
Board: Freescale MPC8313ERDB
I2C:   ready
DRAM:  128 MB
FLASH:  8 MB
In:    serial
Out:   serial
Err:   serial
(Continue reading)

Permalink | Reply | 12 comments |
headers
Benjamin Herrenschmidt | 23 Feb 2009 03:19

[PATCH] powerpc: Wire up /proc/vmallocinfo to our ioremap()

This adds the necessary bits and pieces to powerpc implementation of
ioremap to benefit from caller tracking in /proc/vmallocinfo, at least
for ioremap's done after mem init as the older ones aren't tracked.

Signed-off-by: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
---

 
 arch/powerpc/include/asm/io.h                |    6 ++++++
 arch/powerpc/include/asm/machdep.h           |    2 +-
 arch/powerpc/mm/pgtable_32.c                 |   14 +++++++++++---
 arch/powerpc/mm/pgtable_64.c                 |   25 +++++++++++++++++--------
 arch/powerpc/platforms/cell/io-workarounds.c |    4 ++--
 arch/powerpc/platforms/iseries/setup.c       |    2 +-
 6 files changed, 38 insertions(+), 15 deletions(-)

--- linux-work.orig/arch/powerpc/include/asm/io.h	2009-02-04 15:37:43.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/io.h	2009-02-04 15:38:30.000000000 +1100
 <at>  <at>  -632,6 +632,9  <at>  <at>  static inline void iosync(void)
  *   ioremap_flags and cannot be hooked (but can be used by a hook on one
  *   of the previous ones)
  *
+ * * __ioremap_caller is the same as above but takes an explicit caller
+ *   reference rather than using __builtin_return_address(0)
+ *
  * * __iounmap, is the low level implementation used by iounmap and cannot
  *   be hooked (but can be used by a hook on iounmap)
  *
 <at>  <at>  -646,6 +649,9  <at>  <at>  extern void iounmap(volatile void __iome
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Ellerman | 23 Feb 2009 03:25
Picon
Gravatar

[PATCH 1/2] Deindentify identify_cpu()

The for-loop body of identify_cpu() has gotten a little big, so move the
loop body logic into a separate function. No other changes.

Signed-off-by: Michael Ellerman <michael <at> ellerman.id.au>
---
 arch/powerpc/kernel/cputable.c |  122 +++++++++++++++++++++-------------------
 1 files changed, 64 insertions(+), 58 deletions(-)

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..944bd01 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
 <at>  <at>  -1762,74 +1762,80  <at>  <at>  static struct cpu_spec __initdata cpu_specs[] = {

 static struct cpu_spec the_cpu_spec;

-struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
+static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
 {
-	struct cpu_spec *s = cpu_specs;
 	struct cpu_spec *t = &the_cpu_spec;
-	int i;
-
-	s = PTRRELOC(s);
 	t = PTRRELOC(t);

-	for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++)
-		if ((pvr & s->pvr_mask) == s->pvr_value) {
-			/*
-			 * If we are overriding a previous value derived
(Continue reading)

Permalink | Reply | 6 comments |
headers
Michael Ellerman | 23 Feb 2009 03:25
Picon
Gravatar

[PATCH 2/2] Make sure we copy all cpu_spec features except PMC related ones

When identify_cpu() is called a second time with a logical PVR, it
only copies a subset of the cpu_spec fields so as to avoid overwriting
the performance monitor fields that were initialized based on the
real PVR.

However some of the other, non performance monitor related fields are
also not copied:
 * pvr_mask
 * pvr_value
 * mmu_features
 * machine_check

The fact that pvr_mask is not copied can result in show_cpuinfo()
showing the cpu as "unknown", if we override an unknown PVR with a
logical one - as reported by Shaggy.

So change the logic to copy all fields, and then put back the PMC
related ones in the case that we're overwriting a real PVR with a
logical one.

Signed-off-by: Michael Ellerman <michael <at> ellerman.id.au>
---
 arch/powerpc/kernel/cputable.c |   28 ++++++++++++++++------------
 1 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 944bd01..77febd3 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
 <at>  <at>  -1765,22 +1765,27  <at>  <at>  static struct cpu_spec the_cpu_spec;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ben Dooks | 23 Feb 2009 02:56

Re: [PATCH 01/13] sdhci: Add quirk for controllers with no end-of-busy IRQ

On Sat, Feb 21, 2009 at 05:05:04PM +0100, Pierre Ossman wrote:
> On Fri, 20 Feb 2009 20:33:08 +0300
> Anton Vorontsov <avorontsov <at> ru.mvista.com> wrote:
> 
> > From: Ben Dooks <ben-linux <at> fluff.org>
> > 
> > The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
> > to generate an INT_DATA_END after the transfer has completed and
> > the bus busy state finished.
> > 
> > Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the
> > new busy method are the cause of the behaviour change.
> > 
> > Signed-off-by: Ben Dooks <ben-linux <at> fluff.org>
> > Signed-off-by: Anton Vorontsov <avorontsov <at> ru.mvista.com>
> > ---
> 
> Any objections to me merging this right away? It is needed for another
> controller.

none from me.

sorry about the delay, moving servers.

--

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 23 Feb 2009 03:43

Re: [PATCH] powerpc: Add support for using doorbells for SMP IPI

On Thu, 2009-02-12 at 17:54 -0600, Kumar Gala wrote:
> The e500mc supports the new msgsnd/doorbell mechanisms that were added in
> the Power ISA 2.05 architecture.  We use the normal level doorbell for
> doing SMP IPIs at this point.

Any reason why you don't use the tag ? I'm not too familiar with the
doorbell stuff just yet but can't you use that instead of doing those
atomics ?

On thing we also need to look at is change our low level msg send to
take a CPU mask.

This will be better generically and we need a good cpu mask based IPI
for the TLB stuff anyway. Volunteer ? :-)

Cheers,
Ben.

> Signed-off-by: Kumar Gala <galak <at> kernel.crashing.org>
> ---
>  arch/powerpc/include/asm/cputable.h  |    4 ++-
>  arch/powerpc/include/asm/dbell.h     |   43 +++++++++++++++++++++++++++++++++
>  arch/powerpc/kernel/Makefile         |    2 +-
>  arch/powerpc/kernel/dbell.c          |   44 ++++++++++++++++++++++++++++++++++
>  arch/powerpc/kernel/head_fsl_booke.S |    6 ++++-
>  arch/powerpc/kernel/traps.c          |   21 ++++++++++++++++
>  6 files changed, 117 insertions(+), 3 deletions(-)
>  create mode 100644 arch/powerpc/include/asm/dbell.h
>  create mode 100644 arch/powerpc/kernel/dbell.c
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Soohyung Cho | 23 Feb 2009 03:38
Picon

powerpc 4xx power-management feature

I have a AMCC Kilauea board and I want to use linux power-management
feature on it.
 
But it seems that there's no power-management codes for the powerpc 4xx series.
 
I think the device-tree source for the Kilauea should be modified first.
 
Is there anyone who has tried it before?
 
Please help me.
 
 
 
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev <at> ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 23 Feb 2009 04:51

Re: [RFC/PATCH] powerpc: provide APIs for validating and updating DABR


> +/* for reprogramming DABR/DAC during restart of a checkpointed task */
> +extern bool debugreg_valid(unsigned long val);
> +extern void debugreg_update(struct task_struct *task, unsigned long val);
> +

Please keep the "index" here. We may want to add support for IABR, and
there is some WIP to add support for multiple DACs and IACs on BookE
processors.

Cheers,
Ben.
Permalink | Reply | 0 comments |

Gmane