* Re: MPC8641 based custom board kernel Bug
From: Ashish Khetan @ 2013-12-26 11:48 UTC (permalink / raw)
To: wyang; +Cc: scottwood, linuxppc-dev, kernelnewbies
In-Reply-To: <52BBF1CB.3070006@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13009 bytes --]
i tried to dig more inside mpic_alloc fails. the function
of_find_matching_node calls inside from mpic_alloc() should return the node
at which pic is connected but it returns NULL. but why? In device tree i am
using the following.. may be it will helpful.
/dts-v1/;
/ {
model = "MPC8641HPCN";
compatible = "fsl,mpc8641hpcn";
#address-cells = <0x1>;
#size-cells = <0x1>;
aliases {
ethernet0 = "/soc8641@f8000000/ethernet@24000";
ethernet1 = "/soc8641@f8000000/ethernet@25000";
ethernet2 = "/soc8641@f8000000/ethernet@26000";
ethernet3 = "/soc8641@f8000000/ethernet@27000";
serial0 = "/soc8641@f8000000/serial@4500";
};
cpus {
#address-cells = <0x1>;
#size-cells = <0x0>;
PowerPC,8641@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <0x20>;
i-cache-line-size = <0x20>;
d-cache-size = <0x8000>;
i-cache-size = <0x8000>;
timebase-frequency = <0x0>;
bus-frequency = <0x0>;
clock-frequency = <0x0>;
};
};
memory {
device_type = "memory";
reg = <0x0 0x20000000>;
};
localbus@f8005000 {
#address-cells = <0x2>;
#size-cells = <0x1>;
compatible = "fsl,mpc8641-localbus", "simple-bus";
reg = <0xf8005000 0x1000>;
interrupts = <0x13 0x2>;
interrupt-parent = <0x1>;
ranges = <0x0 0x0 0xff000000 0x1000000>;
flash@0,0 {
compatible = "cfi-flash";
reg = <0x0 0x0 0x800000>;
bank-width = <0x2>;
device-width = <0x2>;
#address-cells = <0x1>;
#size-cells = <0x1>;
};
};
soc8641@f8000000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
device_type = "soc";
compatible = "simple-bus";
ranges = <0x0 0xf8000000 0x100000>;
bus-frequency = <0x0>;
mcm-law@0 {
compatible = "fsl,mcm-law";
reg = <0x0 0x1000>;
fsl,num-laws = <0xa>;
};
mcm@1000 {
compatible = "fsl,mpc8641-mcm", "fsl,mcm";
reg = <0x1000 0x1000>;
interrupts = <0x11 0x2>;
interrupt-parent = <0x1>;
};
dma@21300 {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,mpc8641-dma", "fsl,eloplus-dma";
reg = <0x21300 0x4>;
ranges = <0x0 0x21100 0x200>;
cell-index = <0x0>;
dma-channel@0 {
compatible = "fsl,mpc8641-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
cell-index = <0x0>;
interrupt-parent = <0x1>;
interrupts = <0x14 0x2>;
};
dma-channel@80 {
compatible = "fsl,mpc8641-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <0x1>;
interrupt-parent = <0x1>;
interrupts = <0x15 0x2>;
};
dma-channel@100 {
compatible = "fsl,mpc8641-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <0x2>;
interrupt-parent = <0x1>;
interrupts = <0x16 0x2>;
};
dma-channel@180 {
compatible = "fsl,mpc8641-dma-channel",
"fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <0x3>;
interrupt-parent = <0x1>;
interrupts = <0x17 0x2>;
};
};
ethernet@24000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
cell-index = <0x0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
local-mac-address = [00 00 00 00 00 00];
interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
interrupt-parent = <0x1>;
tbi-handle = <0x2>;
phy-handle = <0x3>;
phy-connection-type = "rgmii-id";
mdio@520 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,gianfar-mdio";
reg = <0x520 0x20>;
ethernet-phy@0 {
interrupt-parent = <0x1>;
interrupts = <0xa 0x1>;
reg = <0x0>;
device_type = "ethernet-phy";
linux,phandle = <0x3>;
};
ethernet-phy@1 {
interrupt-parent = <0x1>;
interrupts = <0xa 0x1>;
reg = <0x1>;
device_type = "ethernet-phy";
linux,phandle = <0x5>;
};
ethernet-phy@2 {
interrupt-parent = <0x1>;
interrupts = <0xa 0x1>;
reg = <0x2>;
device_type = "ethernet-phy";
linux,phandle = <0x7>;
};
ethernet-phy@3 {
interrupt-parent = <0x1>;
interrupts = <0xa 0x1>;
reg = <0x3>;
device_type = "ethernet-phy";
linux,phandle = <0x9>;
};
tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
linux,phandle = <0x2>;
};
};
};
ethernet@25000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
cell-index = <0x1>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x25000 0x1000>;
ranges = <0x0 0x25000 0x1000>;
local-mac-address = [00 00 00 00 00 00];
interrupts = <0x23 0x2 0x24 0x2 0x28 0x2>;
interrupt-parent = <0x1>;
tbi-handle = <0x4>;
phy-handle = <0x5>;
phy-connection-type = "rgmii-id";
mdio@520 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,gianfar-tbi";
reg = <0x520 0x20>;
tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
linux,phandle = <0x4>;
};
};
};
ethernet@26000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
cell-index = <0x2>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x26000 0x1000>;
ranges = <0x0 0x26000 0x1000>;
local-mac-address = [00 00 00 00 00 00];
interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
interrupt-parent = <0x1>;
tbi-handle = <0x6>;
phy-handle = <0x7>;
phy-connection-type = "rgmii-id";
mdio@520 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,gianfar-tbi";
reg = <0x520 0x20>;
tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
linux,phandle = <0x6>;
};
};
};
ethernet@27000 {
#address-cells = <0x1>;
#size-cells = <0x1>;
cell-index = <0x3>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x27000 0x1000>;
ranges = <0x0 0x27000 0x1000>;
local-mac-address = [00 00 00 00 00 00];
interrupts = <0x25 0x2 0x26 0x2 0x27 0x2>;
interrupt-parent = <0x1>;
tbi-handle = <0x8>;
phy-handle = <0x9>;
phy-connection-type = "rgmii-id";
mdio@520 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,gianfar-tbi";
reg = <0x520 0x20>;
tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
linux,phandle = <0x8>;
};
};
};
serial@4500 {
cell-index = <0x0>;
device_type = "serial";
compatible = "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0x0>;
interrupts = <0x2a 0x2>;
interrupt-parent = <0x1>;
};
pic@40000 {
interrupt-controller;
#address-cells = <0x0>;
#interrupt-cells = <0x2>;
reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
linux,phandle = <0x1>;
phandle = <0x1>;
};
global-utilities@e0000 {
compatible = "fsl,mpc8641-guts";
reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
};
chosen {
linux,stdout-path = "/soc8641/serial0: serial@4500";
};
};
On Thu, Dec 26, 2013 at 2:37 PM, wyang <w90p710@gmail.com> wrote:
> On 12/26/2013 01:09 PM, Ashish Khetan wrote:
>
> Hi,
> I was trying to port Linux-3.12 for MPC8641 based custom designed board
> for evaluation purpose. I have been facing a kernel bug at mpic
> initialization. Is somebody have faced this kind of bugs or can give me any
> pointer for further steps how to solve kernel bugs will be really helpful.
> here is the snapshot for the bug that may be helpful to address the bug.
> Using MPC86xx HPCN machine description
> Total memory = 512MB; using 1024kB for hash table (at cff00000)
> Linux version 3.12.0 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC)
> ) #2 We
> d Dec 25 16:04:36 IST 2013
> Found initrd at 0xde975000:0xdfec428a
> bootconsole [udbg0] enabled
> setup_arch: bootmem
> mpc86xx_hpcn_setup_arch()
> MPC86xx HPCN board from Freescale Semiconductor
> arch: exit
> Zone ranges:
> DMA [mem 0x00000000-0x1fffffff]
> Normal empty
> HighMem empty
> Movable zone start for each node
> Early memory node ranges
> node 0: [mem 0x00000000-0x1fffffff]
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
> Kernel command line: root=/dev/ram0 rw rootfs console=ttyS0,115200
> PID hash table entries: 2048 (order: 1, 8192 bytes)
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Sorting __ex_table...
> Memory: 424980K/524288K available (4172K kernel code, 208K rwdata, 1304K
> rodata,
> 196K init, 149K bss, 99308K reserved, 0K highmem)
> Kernel virtual memory layout:
> * 0xfffcf000..0xfffff000 : fixmap
> * 0xff800000..0xffc00000 : highmem PTEs
> * 0xff7fe000..0xff800000 : early ioremap
> * 0xe1000000..0xff7fe000 : vmalloc & ioremap
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> NR_IRQS:512 nr_irqs:512 16
> ------------[ cut here ]------------
> kernel BUG at arch/powerpc/platforms/86xx/pic.c:42!
>
>
> It hints that mpic_alloc() fails. Maybe, you should spend some time
> investigating why it fails. :-)
>
> Thanks
> Wei
>
> Oops: Exception in kernel mode, sig: 5 [#1]
> MPC86xx HPCN
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0 #2
> task: c05903e0 ti: c05b4000 task.ti: c05b4000
> NIP: c0567438 LR: c0567430 CTR: c0567400
> REGS: c05b5ee0 TRAP: 0700 Not tainted (3.12.0)
> MSR: 00021032 <ME,IR,DR,RI> CR: 24000042 XER: 20000000
>
> GPR00: c0567430 c05b5f90 c05903e0 00000000 c04e4ff8 c051e588 0000008f
> 00000002
> GPR08: c042789c 00000001 0000006f 00000000 22000048 bebffffd 11a7b4e5
> 200c8000
> GPR16: ffbeffff ffffffff 00000000 00000024 00000000 1fec56f8 1fec59a7
> 00000000
> GPR24: 00000000 1fff97e8 40000000 1ffcc6a0 c0bff080 c05c2490 c05c2628
> c0585b60
> NIP [c0567438] mpc86xx_init_irq+0x38/0x108
> LR [c0567430] mpc86xx_init_irq+0x30/0x108
> Call Trace:
> [c05b5f90] [c0567430] mpc86xx_init_irq+0x30/0x108 (unreliable)
> [c05b5fb0] [c0562784] init_IRQ+0x24/0x38
> [c05b5fc0] [c055fde4] start_kernel+0x1bc/0x2ec
> [c05b5ff0] [00003444] 0x3444
> Instruction dump:
> 3d00c04f 38800000 38a01002 38c00000 38e00100 39088f8c 38600000 90010024
> bfa10014 4bffec35 7c690034 5529d97e <0f090000> 3fa0c04f 4bfff391 38600000
> ---[ end trace 31fd0ba7d8756001 ]---
>
> Kernel panic - not syncing: Attempted to kill the idle task!
> Rebooting in 180 seconds..
>
>
> Thanks & Regards
> Ashish Khetan
>
>
> _______________________________________________
> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 17833 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v6 4/5] dma: mpc512x: register for device tree channel lookup
From: Gerhard Sittig @ 2013-12-26 12:40 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Arnd Bergmann, Vinod Koul,
dmaengine, Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1387886789-20249-5-git-send-email-a13xp0p0v88@gmail.com>
On Tue, Dec 24, 2013 at 16:06 +0400, Alexander Popov wrote:
>
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> @@ -0,0 +1,55 @@
> +* Freescale MPC512x DMA Controller
> +
> +[ ... ]
> +
> +DMA controller node properties:
> +
> +Required properties:
> +- compatible: should be "fsl,mpc5121-dma"
> +- reg: address and size of the DMA controller's register set
> +- interrupts: interrupt spec for the DMA controller
> +
> +Optional properties:
> +- #dma-cells: must be <1>, describes the number of integer cells
> + needed to specify the 'dmas' property in client nodes,
> + strongly recommended since common client helper code
> + uses this property
Given how time has passed and that we learned something in the
meantime, I guess the device tree documentation would look
different today than what was written back then.
- I'd reference the generic interrupt bindings as well, so DTS
authors need not guess what an interrupt spec looks like
- the #dma-cells would become less confusing is it referenced the
generic DMA binding, and just say that the value is "the length
of the DMA specifier" for this provider
- the property's being recommended should not get hidden in the
description but should reflect in the group's caption
- the binding doc shold not reference implementation details of
one specific user (common client helper code)
[ device tree binding doc policy? ]
That one Linux driver handles both MPC5121 and MPC8308 hardware
and implements the same binding in both cases should get
reflected in the documentation as well. But I'm not certain
whether adding MPC8308 into an MPX5121 document is better than
duplicating MPC5121 information in another MPC8308 document. But
it might be the lesser evil.
Are there opinions, established preferences? Is an exhaustive
list of compatible strings good enough since text search will
match regardless of the document's filename in this case?
There must have been this situation before of a component being
used in one SoC and getting re-used in another SoC later, too.
What's the best document to "get inspired from", i.e. how to best
put this into binding document wording as well as filenames?
> +[ ... ]
> +Client node properties:
> +
> +Required properties:
> +- dmas: list of DMA specifiers, consisting each of a handle
> + for the DMA controller and integer cells to specify
> + the channel used within the DMA controller
> +- dma-names: list of identifier strings for the DMA specifiers,
> + client device driver code uses these strings to
> + have DMA channels looked up at the controller
This certainly is wrong (it was before, I just wasn't aware back
then). The phandle is not part of the specifier. And the
binding should not discuss what driver code does. Since the DMA
controller implements the semantics of the common DMA binding,
it's unwise to duplicate the information here.
Let me see how I can improve this document. Alex, it may be
useful to split the code update and the binding document into
separate patches. The current status already mixes the code
extension and the binding update with the introduction of the
document which was missing in the first place. That's why the
binding doc patch is that late in the series. (Yes, my RFC
"template" was rather dirty, which is why I flagged it as "RFC"
in the first place.)
I guess that I may have to introduce a binding doc reflecting the
given current status, and update it later as new features become
available.
Or -- given that the hardware remains, all the knowledge is there
already, just the implementations' capabilities change -- I might
as well introduce a binding document including OF based DMA
lookup.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH RFC v6 4/5] dma: mpc512x: register for device tree channel lookup
From: Gerhard Sittig @ 2013-12-26 12:48 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Arnd Bergmann, Vinod Koul,
dmaengine, Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1387886789-20249-5-git-send-email-a13xp0p0v88@gmail.com>
[ dropping devicetree, we're DMA specific here ]
On Tue, Dec 24, 2013 at 16:06 +0400, Alexander Popov wrote:
>
> --- a/drivers/dma/mpc512x_dma.c
> +++ b/drivers/dma/mpc512x_dma.c
> [ ... ]
> @@ -950,6 +951,7 @@ static int mpc_dma_probe(struct platform_device *op)
> INIT_LIST_HEAD(&dma->channels);
> dma_cap_set(DMA_MEMCPY, dma->cap_mask);
> dma_cap_set(DMA_SLAVE, dma->cap_mask);
> + dma_cap_set(DMA_PRIVATE, dma->cap_mask);
>
> for (i = 0; i < dma->chancnt; i++) {
> mchan = &mdma->channels[i];
What are the implications of this? Is a comment due?
I haven't found documentation about the DMA_PRIVATE flag, only
saw commit 59b5ec21446b9 "dmaengine: introduce
dma_request_channel and private channels". Alex, unless I'm
missing something this one-line change is quite a change in
semantics, and has dramatic influence on the code's behaviour
(ignores the DMA controller when looking for channels that can do
mem-to-mem transfers).
Please reason about this change some more, and explain what it
does and why it's needed. Consider the fact that this driver
handles both MPC5121 as well as MPC8308 hardware.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: MPC8641 based custom board kernel Bug
From: Sri Ram Vemulpali @ 2013-12-26 22:51 UTC (permalink / raw)
To: Ashish Khetan; +Cc: scottwood, linuxppc-dev, wyang, kernelnewbies
In-Reply-To: <CAERE9Prr_C31D96zuYbV0KQ7b_j8Te0A2DO8C+6YtetF0e6M_w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14167 bytes --]
Why do not you use deconfig from linux kernel tree. Modify only base
address of CCSR (soc node) for child nodes of root in device tree.
arch/powerpc/boot/dts/mpc8641_hpcn.dts.
Sri
On Thu, Dec 26, 2013 at 3:48 AM, Ashish Khetan <curieux.khetan@gmail.com>wrote:
> i tried to dig more inside mpic_alloc fails. the function
> of_find_matching_node calls inside from mpic_alloc() should return the node
> at which pic is connected but it returns NULL. but why? In device tree i am
> using the following.. may be it will helpful.
> /dts-v1/;
>
> / {
> model = "MPC8641HPCN";
> compatible = "fsl,mpc8641hpcn";
> #address-cells = <0x1>;
> #size-cells = <0x1>;
>
> aliases {
> ethernet0 = "/soc8641@f8000000/ethernet@24000";
> ethernet1 = "/soc8641@f8000000/ethernet@25000";
> ethernet2 = "/soc8641@f8000000/ethernet@26000";
> ethernet3 = "/soc8641@f8000000/ethernet@27000";
> serial0 = "/soc8641@f8000000/serial@4500";
> };
>
> cpus {
> #address-cells = <0x1>;
> #size-cells = <0x0>;
>
> PowerPC,8641@0 {
> device_type = "cpu";
> reg = <0x0>;
> d-cache-line-size = <0x20>;
> i-cache-line-size = <0x20>;
> d-cache-size = <0x8000>;
> i-cache-size = <0x8000>;
> timebase-frequency = <0x0>;
> bus-frequency = <0x0>;
> clock-frequency = <0x0>;
> };
> };
>
> memory {
> device_type = "memory";
> reg = <0x0 0x20000000>;
> };
>
> localbus@f8005000 {
> #address-cells = <0x2>;
> #size-cells = <0x1>;
> compatible = "fsl,mpc8641-localbus", "simple-bus";
> reg = <0xf8005000 0x1000>;
> interrupts = <0x13 0x2>;
> interrupt-parent = <0x1>;
> ranges = <0x0 0x0 0xff000000 0x1000000>;
>
> flash@0,0 {
> compatible = "cfi-flash";
> reg = <0x0 0x0 0x800000>;
> bank-width = <0x2>;
> device-width = <0x2>;
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> };
> };
>
> soc8641@f8000000 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> device_type = "soc";
> compatible = "simple-bus";
> ranges = <0x0 0xf8000000 0x100000>;
> bus-frequency = <0x0>;
>
> mcm-law@0 {
> compatible = "fsl,mcm-law";
> reg = <0x0 0x1000>;
> fsl,num-laws = <0xa>;
> };
>
> mcm@1000 {
> compatible = "fsl,mpc8641-mcm", "fsl,mcm";
> reg = <0x1000 0x1000>;
> interrupts = <0x11 0x2>;
> interrupt-parent = <0x1>;
> };
>
> dma@21300 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> compatible = "fsl,mpc8641-dma", "fsl,eloplus-dma";
> reg = <0x21300 0x4>;
> ranges = <0x0 0x21100 0x200>;
> cell-index = <0x0>;
>
> dma-channel@0 {
> compatible = "fsl,mpc8641-dma-channel",
> "fsl,eloplus-dma-channel";
> reg = <0x0 0x80>;
> cell-index = <0x0>;
> interrupt-parent = <0x1>;
> interrupts = <0x14 0x2>;
> };
>
> dma-channel@80 {
> compatible = "fsl,mpc8641-dma-channel",
> "fsl,eloplus-dma-channel";
> reg = <0x80 0x80>;
> cell-index = <0x1>;
> interrupt-parent = <0x1>;
> interrupts = <0x15 0x2>;
> };
>
> dma-channel@100 {
> compatible = "fsl,mpc8641-dma-channel",
> "fsl,eloplus-dma-channel";
> reg = <0x100 0x80>;
> cell-index = <0x2>;
> interrupt-parent = <0x1>;
> interrupts = <0x16 0x2>;
> };
>
> dma-channel@180 {
> compatible = "fsl,mpc8641-dma-channel",
> "fsl,eloplus-dma-channel";
> reg = <0x180 0x80>;
> cell-index = <0x3>;
> interrupt-parent = <0x1>;
> interrupts = <0x17 0x2>;
> };
> };
>
> ethernet@24000 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> cell-index = <0x0>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x24000 0x1000>;
> ranges = <0x0 0x24000 0x1000>;
> local-mac-address = [00 00 00 00 00 00];
> interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
> interrupt-parent = <0x1>;
> tbi-handle = <0x2>;
> phy-handle = <0x3>;
> phy-connection-type = "rgmii-id";
>
> mdio@520 {
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> compatible = "fsl,gianfar-mdio";
> reg = <0x520 0x20>;
>
> ethernet-phy@0 {
> interrupt-parent = <0x1>;
> interrupts = <0xa 0x1>;
> reg = <0x0>;
> device_type = "ethernet-phy";
> linux,phandle = <0x3>;
> };
>
> ethernet-phy@1 {
> interrupt-parent = <0x1>;
> interrupts = <0xa 0x1>;
> reg = <0x1>;
> device_type = "ethernet-phy";
> linux,phandle = <0x5>;
> };
>
> ethernet-phy@2 {
> interrupt-parent = <0x1>;
> interrupts = <0xa 0x1>;
> reg = <0x2>;
> device_type = "ethernet-phy";
> linux,phandle = <0x7>;
> };
>
> ethernet-phy@3 {
> interrupt-parent = <0x1>;
> interrupts = <0xa 0x1>;
> reg = <0x3>;
> device_type = "ethernet-phy";
> linux,phandle = <0x9>;
> };
>
> tbi-phy@11 {
> reg = <0x11>;
> device_type = "tbi-phy";
> linux,phandle = <0x2>;
> };
> };
> };
>
> ethernet@25000 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> cell-index = <0x1>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x25000 0x1000>;
> ranges = <0x0 0x25000 0x1000>;
> local-mac-address = [00 00 00 00 00 00];
> interrupts = <0x23 0x2 0x24 0x2 0x28 0x2>;
> interrupt-parent = <0x1>;
> tbi-handle = <0x4>;
> phy-handle = <0x5>;
> phy-connection-type = "rgmii-id";
>
> mdio@520 {
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> compatible = "fsl,gianfar-tbi";
> reg = <0x520 0x20>;
>
> tbi-phy@11 {
> reg = <0x11>;
> device_type = "tbi-phy";
> linux,phandle = <0x4>;
> };
> };
> };
>
> ethernet@26000 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> cell-index = <0x2>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x26000 0x1000>;
> ranges = <0x0 0x26000 0x1000>;
> local-mac-address = [00 00 00 00 00 00];
> interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
> interrupt-parent = <0x1>;
> tbi-handle = <0x6>;
> phy-handle = <0x7>;
> phy-connection-type = "rgmii-id";
>
> mdio@520 {
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> compatible = "fsl,gianfar-tbi";
> reg = <0x520 0x20>;
>
> tbi-phy@11 {
> reg = <0x11>;
> device_type = "tbi-phy";
> linux,phandle = <0x6>;
> };
> };
> };
>
> ethernet@27000 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> cell-index = <0x3>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x27000 0x1000>;
> ranges = <0x0 0x27000 0x1000>;
> local-mac-address = [00 00 00 00 00 00];
> interrupts = <0x25 0x2 0x26 0x2 0x27 0x2>;
> interrupt-parent = <0x1>;
> tbi-handle = <0x8>;
> phy-handle = <0x9>;
> phy-connection-type = "rgmii-id";
>
> mdio@520 {
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> compatible = "fsl,gianfar-tbi";
> reg = <0x520 0x20>;
>
> tbi-phy@11 {
> reg = <0x11>;
> device_type = "tbi-phy";
> linux,phandle = <0x8>;
> };
> };
> };
>
> serial@4500 {
> cell-index = <0x0>;
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x4500 0x100>;
> clock-frequency = <0x0>;
> interrupts = <0x2a 0x2>;
> interrupt-parent = <0x1>;
> };
>
> pic@40000 {
> interrupt-controller;
> #address-cells = <0x0>;
> #interrupt-cells = <0x2>;
> reg = <0x40000 0x40000>;
> compatible = "chrp,open-pic";
> device_type = "open-pic";
> linux,phandle = <0x1>;
> phandle = <0x1>;
> };
>
> global-utilities@e0000 {
> compatible = "fsl,mpc8641-guts";
> reg = <0xe0000 0x1000>;
> fsl,has-rstcr;
> };
> };
>
> chosen {
> linux,stdout-path = "/soc8641/serial0: serial@4500";
> };
> };
>
>
>
>
> On Thu, Dec 26, 2013 at 2:37 PM, wyang <w90p710@gmail.com> wrote:
>
>> On 12/26/2013 01:09 PM, Ashish Khetan wrote:
>>
>> Hi,
>> I was trying to port Linux-3.12 for MPC8641 based custom designed board
>> for evaluation purpose. I have been facing a kernel bug at mpic
>> initialization. Is somebody have faced this kind of bugs or can give me any
>> pointer for further steps how to solve kernel bugs will be really helpful.
>> here is the snapshot for the bug that may be helpful to address the bug.
>> Using MPC86xx HPCN machine description
>> Total memory = 512MB; using 1024kB for hash table (at cff00000)
>> Linux version 3.12.0 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC)
>> ) #2 We
>> d Dec 25 16:04:36 IST 2013
>> Found initrd at 0xde975000:0xdfec428a
>> bootconsole [udbg0] enabled
>> setup_arch: bootmem
>> mpc86xx_hpcn_setup_arch()
>> MPC86xx HPCN board from Freescale Semiconductor
>> arch: exit
>> Zone ranges:
>> DMA [mem 0x00000000-0x1fffffff]
>> Normal empty
>> HighMem empty
>> Movable zone start for each node
>> Early memory node ranges
>> node 0: [mem 0x00000000-0x1fffffff]
>> Built 1 zonelists in Zone order, mobility grouping on. Total pages:
>> 130048
>> Kernel command line: root=/dev/ram0 rw rootfs console=ttyS0,115200
>> PID hash table entries: 2048 (order: 1, 8192 bytes)
>> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
>> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
>> Sorting __ex_table...
>> Memory: 424980K/524288K available (4172K kernel code, 208K rwdata, 1304K
>> rodata,
>> 196K init, 149K bss, 99308K reserved, 0K highmem)
>> Kernel virtual memory layout:
>> * 0xfffcf000..0xfffff000 : fixmap
>> * 0xff800000..0xffc00000 : highmem PTEs
>> * 0xff7fe000..0xff800000 : early ioremap
>> * 0xe1000000..0xff7fe000 : vmalloc & ioremap
>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> NR_IRQS:512 nr_irqs:512 16
>> ------------[ cut here ]------------
>> kernel BUG at arch/powerpc/platforms/86xx/pic.c:42!
>>
>>
>> It hints that mpic_alloc() fails. Maybe, you should spend some time
>> investigating why it fails. :-)
>>
>> Thanks
>> Wei
>>
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> MPC86xx HPCN
>> Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0 #2
>> task: c05903e0 ti: c05b4000 task.ti: c05b4000
>> NIP: c0567438 LR: c0567430 CTR: c0567400
>> REGS: c05b5ee0 TRAP: 0700 Not tainted (3.12.0)
>> MSR: 00021032 <ME,IR,DR,RI> CR: 24000042 XER: 20000000
>>
>> GPR00: c0567430 c05b5f90 c05903e0 00000000 c04e4ff8 c051e588 0000008f
>> 00000002
>> GPR08: c042789c 00000001 0000006f 00000000 22000048 bebffffd 11a7b4e5
>> 200c8000
>> GPR16: ffbeffff ffffffff 00000000 00000024 00000000 1fec56f8 1fec59a7
>> 00000000
>> GPR24: 00000000 1fff97e8 40000000 1ffcc6a0 c0bff080 c05c2490 c05c2628
>> c0585b60
>> NIP [c0567438] mpc86xx_init_irq+0x38/0x108
>> LR [c0567430] mpc86xx_init_irq+0x30/0x108
>> Call Trace:
>> [c05b5f90] [c0567430] mpc86xx_init_irq+0x30/0x108 (unreliable)
>> [c05b5fb0] [c0562784] init_IRQ+0x24/0x38
>> [c05b5fc0] [c055fde4] start_kernel+0x1bc/0x2ec
>> [c05b5ff0] [00003444] 0x3444
>> Instruction dump:
>> 3d00c04f 38800000 38a01002 38c00000 38e00100 39088f8c 38600000 90010024
>> bfa10014 4bffec35 7c690034 5529d97e <0f090000> 3fa0c04f 4bfff391 38600000
>> ---[ end trace 31fd0ba7d8756001 ]---
>>
>> Kernel panic - not syncing: Attempted to kill the idle task!
>> Rebooting in 180 seconds..
>>
>>
>> Thanks & Regards
>> Ashish Khetan
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
--
Regards,
Sri.
[-- Attachment #2: Type: text/html, Size: 18990 bytes --]
^ permalink raw reply
* Re: MPC8641 based custom board kernel Bug
From: Ashish Khetan @ 2013-12-27 5:20 UTC (permalink / raw)
To: Sri Ram Vemulpali; +Cc: scottwood, linuxppc-dev, wyang, kernelnewbies
In-Reply-To: <CALyraeMiKQsoHV8AQ5SOz926z_YBD3LbFFNefMpRibYOt=Vo=Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 15026 bytes --]
I am using the defconfig from linux kernel tree and for CCSR in u-boot its
F8000000 so the same i am using in device tree... so my question is - is it
unable to parse device tree ? or in device tree some thing need to modify
in device tree or in kernel source...
please give some light on this...
Thanks & Regards
Ashish Khetan
On Fri, Dec 27, 2013 at 4:21 AM, Sri Ram Vemulpali
<sri.ram.gmu06@gmail.com>wrote:
> Why do not you use deconfig from linux kernel tree. Modify only base
> address of CCSR (soc node) for child nodes of root in device tree.
> arch/powerpc/boot/dts/mpc8641_hpcn.dts.
>
> Sri
>
>
> On Thu, Dec 26, 2013 at 3:48 AM, Ashish Khetan <curieux.khetan@gmail.com>wrote:
>
>> i tried to dig more inside mpic_alloc fails. the function
>> of_find_matching_node calls inside from mpic_alloc() should return the node
>> at which pic is connected but it returns NULL. but why? In device tree i am
>> using the following.. may be it will helpful.
>> /dts-v1/;
>>
>> / {
>> model = "MPC8641HPCN";
>> compatible = "fsl,mpc8641hpcn";
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>>
>> aliases {
>> ethernet0 = "/soc8641@f8000000/ethernet@24000";
>> ethernet1 = "/soc8641@f8000000/ethernet@25000";
>> ethernet2 = "/soc8641@f8000000/ethernet@26000";
>> ethernet3 = "/soc8641@f8000000/ethernet@27000";
>> serial0 = "/soc8641@f8000000/serial@4500";
>> };
>>
>> cpus {
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>>
>> PowerPC,8641@0 {
>> device_type = "cpu";
>> reg = <0x0>;
>> d-cache-line-size = <0x20>;
>> i-cache-line-size = <0x20>;
>> d-cache-size = <0x8000>;
>> i-cache-size = <0x8000>;
>> timebase-frequency = <0x0>;
>> bus-frequency = <0x0>;
>> clock-frequency = <0x0>;
>> };
>> };
>>
>> memory {
>> device_type = "memory";
>> reg = <0x0 0x20000000>;
>> };
>>
>> localbus@f8005000 {
>> #address-cells = <0x2>;
>> #size-cells = <0x1>;
>> compatible = "fsl,mpc8641-localbus", "simple-bus";
>> reg = <0xf8005000 0x1000>;
>> interrupts = <0x13 0x2>;
>> interrupt-parent = <0x1>;
>> ranges = <0x0 0x0 0xff000000 0x1000000>;
>>
>> flash@0,0 {
>> compatible = "cfi-flash";
>> reg = <0x0 0x0 0x800000>;
>> bank-width = <0x2>;
>> device-width = <0x2>;
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>> };
>> };
>>
>> soc8641@f8000000 {
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>> device_type = "soc";
>> compatible = "simple-bus";
>> ranges = <0x0 0xf8000000 0x100000>;
>> bus-frequency = <0x0>;
>>
>> mcm-law@0 {
>> compatible = "fsl,mcm-law";
>> reg = <0x0 0x1000>;
>> fsl,num-laws = <0xa>;
>> };
>>
>> mcm@1000 {
>> compatible = "fsl,mpc8641-mcm", "fsl,mcm";
>> reg = <0x1000 0x1000>;
>> interrupts = <0x11 0x2>;
>> interrupt-parent = <0x1>;
>> };
>>
>> dma@21300 {
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>> compatible = "fsl,mpc8641-dma", "fsl,eloplus-dma";
>> reg = <0x21300 0x4>;
>> ranges = <0x0 0x21100 0x200>;
>> cell-index = <0x0>;
>>
>> dma-channel@0 {
>> compatible = "fsl,mpc8641-dma-channel",
>> "fsl,eloplus-dma-channel";
>> reg = <0x0 0x80>;
>> cell-index = <0x0>;
>> interrupt-parent = <0x1>;
>> interrupts = <0x14 0x2>;
>> };
>>
>> dma-channel@80 {
>> compatible = "fsl,mpc8641-dma-channel",
>> "fsl,eloplus-dma-channel";
>> reg = <0x80 0x80>;
>> cell-index = <0x1>;
>> interrupt-parent = <0x1>;
>> interrupts = <0x15 0x2>;
>> };
>>
>> dma-channel@100 {
>> compatible = "fsl,mpc8641-dma-channel",
>> "fsl,eloplus-dma-channel";
>> reg = <0x100 0x80>;
>> cell-index = <0x2>;
>> interrupt-parent = <0x1>;
>> interrupts = <0x16 0x2>;
>> };
>>
>> dma-channel@180 {
>> compatible = "fsl,mpc8641-dma-channel",
>> "fsl,eloplus-dma-channel";
>> reg = <0x180 0x80>;
>> cell-index = <0x3>;
>> interrupt-parent = <0x1>;
>> interrupts = <0x17 0x2>;
>> };
>> };
>>
>> ethernet@24000 {
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>> cell-index = <0x0>;
>> device_type = "network";
>> model = "TSEC";
>> compatible = "gianfar";
>> reg = <0x24000 0x1000>;
>> ranges = <0x0 0x24000 0x1000>;
>> local-mac-address = [00 00 00 00 00 00];
>> interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
>> interrupt-parent = <0x1>;
>> tbi-handle = <0x2>;
>> phy-handle = <0x3>;
>> phy-connection-type = "rgmii-id";
>>
>> mdio@520 {
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>> compatible = "fsl,gianfar-mdio";
>> reg = <0x520 0x20>;
>>
>> ethernet-phy@0 {
>> interrupt-parent = <0x1>;
>> interrupts = <0xa 0x1>;
>> reg = <0x0>;
>> device_type = "ethernet-phy";
>> linux,phandle = <0x3>;
>> };
>>
>> ethernet-phy@1 {
>> interrupt-parent = <0x1>;
>> interrupts = <0xa 0x1>;
>> reg = <0x1>;
>> device_type = "ethernet-phy";
>> linux,phandle = <0x5>;
>> };
>>
>> ethernet-phy@2 {
>> interrupt-parent = <0x1>;
>> interrupts = <0xa 0x1>;
>> reg = <0x2>;
>> device_type = "ethernet-phy";
>> linux,phandle = <0x7>;
>> };
>>
>> ethernet-phy@3 {
>> interrupt-parent = <0x1>;
>> interrupts = <0xa 0x1>;
>> reg = <0x3>;
>> device_type = "ethernet-phy";
>> linux,phandle = <0x9>;
>> };
>>
>> tbi-phy@11 {
>> reg = <0x11>;
>> device_type = "tbi-phy";
>> linux,phandle = <0x2>;
>> };
>> };
>> };
>>
>> ethernet@25000 {
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>> cell-index = <0x1>;
>> device_type = "network";
>> model = "TSEC";
>> compatible = "gianfar";
>> reg = <0x25000 0x1000>;
>> ranges = <0x0 0x25000 0x1000>;
>> local-mac-address = [00 00 00 00 00 00];
>> interrupts = <0x23 0x2 0x24 0x2 0x28 0x2>;
>> interrupt-parent = <0x1>;
>> tbi-handle = <0x4>;
>> phy-handle = <0x5>;
>> phy-connection-type = "rgmii-id";
>>
>> mdio@520 {
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>> compatible = "fsl,gianfar-tbi";
>> reg = <0x520 0x20>;
>>
>> tbi-phy@11 {
>> reg = <0x11>;
>> device_type = "tbi-phy";
>> linux,phandle = <0x4>;
>> };
>> };
>> };
>>
>> ethernet@26000 {
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>> cell-index = <0x2>;
>> device_type = "network";
>> model = "TSEC";
>> compatible = "gianfar";
>> reg = <0x26000 0x1000>;
>> ranges = <0x0 0x26000 0x1000>;
>> local-mac-address = [00 00 00 00 00 00];
>> interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
>> interrupt-parent = <0x1>;
>> tbi-handle = <0x6>;
>> phy-handle = <0x7>;
>> phy-connection-type = "rgmii-id";
>>
>> mdio@520 {
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>> compatible = "fsl,gianfar-tbi";
>> reg = <0x520 0x20>;
>>
>> tbi-phy@11 {
>> reg = <0x11>;
>> device_type = "tbi-phy";
>> linux,phandle = <0x6>;
>> };
>> };
>> };
>>
>> ethernet@27000 {
>> #address-cells = <0x1>;
>> #size-cells = <0x1>;
>> cell-index = <0x3>;
>> device_type = "network";
>> model = "TSEC";
>> compatible = "gianfar";
>> reg = <0x27000 0x1000>;
>> ranges = <0x0 0x27000 0x1000>;
>> local-mac-address = [00 00 00 00 00 00];
>> interrupts = <0x25 0x2 0x26 0x2 0x27 0x2>;
>> interrupt-parent = <0x1>;
>> tbi-handle = <0x8>;
>> phy-handle = <0x9>;
>> phy-connection-type = "rgmii-id";
>>
>> mdio@520 {
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>> compatible = "fsl,gianfar-tbi";
>> reg = <0x520 0x20>;
>>
>> tbi-phy@11 {
>> reg = <0x11>;
>> device_type = "tbi-phy";
>> linux,phandle = <0x8>;
>> };
>> };
>> };
>>
>> serial@4500 {
>> cell-index = <0x0>;
>> device_type = "serial";
>> compatible = "ns16550";
>> reg = <0x4500 0x100>;
>> clock-frequency = <0x0>;
>> interrupts = <0x2a 0x2>;
>> interrupt-parent = <0x1>;
>> };
>>
>> pic@40000 {
>> interrupt-controller;
>> #address-cells = <0x0>;
>> #interrupt-cells = <0x2>;
>> reg = <0x40000 0x40000>;
>> compatible = "chrp,open-pic";
>> device_type = "open-pic";
>> linux,phandle = <0x1>;
>> phandle = <0x1>;
>> };
>>
>> global-utilities@e0000 {
>> compatible = "fsl,mpc8641-guts";
>> reg = <0xe0000 0x1000>;
>> fsl,has-rstcr;
>> };
>> };
>>
>> chosen {
>> linux,stdout-path = "/soc8641/serial0: serial@4500";
>> };
>> };
>>
>>
>>
>>
>> On Thu, Dec 26, 2013 at 2:37 PM, wyang <w90p710@gmail.com> wrote:
>>
>>> On 12/26/2013 01:09 PM, Ashish Khetan wrote:
>>>
>>> Hi,
>>> I was trying to port Linux-3.12 for MPC8641 based custom designed board
>>> for evaluation purpose. I have been facing a kernel bug at mpic
>>> initialization. Is somebody have faced this kind of bugs or can give me any
>>> pointer for further steps how to solve kernel bugs will be really helpful.
>>> here is the snapshot for the bug that may be helpful to address the bug.
>>> Using MPC86xx HPCN machine description
>>> Total memory = 512MB; using 1024kB for hash table (at cff00000)
>>> Linux version 3.12.0 (ashish@ashish-VirtualBox) (gcc version 4.7.2
>>> (GCC) ) #2 We
>>> d Dec 25 16:04:36 IST 2013
>>> Found initrd at 0xde975000:0xdfec428a
>>> bootconsole [udbg0] enabled
>>> setup_arch: bootmem
>>> mpc86xx_hpcn_setup_arch()
>>> MPC86xx HPCN board from Freescale Semiconductor
>>> arch: exit
>>> Zone ranges:
>>> DMA [mem 0x00000000-0x1fffffff]
>>> Normal empty
>>> HighMem empty
>>> Movable zone start for each node
>>> Early memory node ranges
>>> node 0: [mem 0x00000000-0x1fffffff]
>>> Built 1 zonelists in Zone order, mobility grouping on. Total pages:
>>> 130048
>>> Kernel command line: root=/dev/ram0 rw rootfs console=ttyS0,115200
>>> PID hash table entries: 2048 (order: 1, 8192 bytes)
>>> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
>>> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
>>> Sorting __ex_table...
>>> Memory: 424980K/524288K available (4172K kernel code, 208K rwdata, 1304K
>>> rodata,
>>> 196K init, 149K bss, 99308K reserved, 0K highmem)
>>> Kernel virtual memory layout:
>>> * 0xfffcf000..0xfffff000 : fixmap
>>> * 0xff800000..0xffc00000 : highmem PTEs
>>> * 0xff7fe000..0xff800000 : early ioremap
>>> * 0xe1000000..0xff7fe000 : vmalloc & ioremap
>>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>>> NR_IRQS:512 nr_irqs:512 16
>>> ------------[ cut here ]------------
>>> kernel BUG at arch/powerpc/platforms/86xx/pic.c:42!
>>>
>>>
>>> It hints that mpic_alloc() fails. Maybe, you should spend some time
>>> investigating why it fails. :-)
>>>
>>> Thanks
>>> Wei
>>>
>>> Oops: Exception in kernel mode, sig: 5 [#1]
>>> MPC86xx HPCN
>>> Modules linked in:
>>> CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0 #2
>>> task: c05903e0 ti: c05b4000 task.ti: c05b4000
>>> NIP: c0567438 LR: c0567430 CTR: c0567400
>>> REGS: c05b5ee0 TRAP: 0700 Not tainted (3.12.0)
>>> MSR: 00021032 <ME,IR,DR,RI> CR: 24000042 XER: 20000000
>>>
>>> GPR00: c0567430 c05b5f90 c05903e0 00000000 c04e4ff8 c051e588 0000008f
>>> 00000002
>>> GPR08: c042789c 00000001 0000006f 00000000 22000048 bebffffd 11a7b4e5
>>> 200c8000
>>> GPR16: ffbeffff ffffffff 00000000 00000024 00000000 1fec56f8 1fec59a7
>>> 00000000
>>> GPR24: 00000000 1fff97e8 40000000 1ffcc6a0 c0bff080 c05c2490 c05c2628
>>> c0585b60
>>> NIP [c0567438] mpc86xx_init_irq+0x38/0x108
>>> LR [c0567430] mpc86xx_init_irq+0x30/0x108
>>> Call Trace:
>>> [c05b5f90] [c0567430] mpc86xx_init_irq+0x30/0x108 (unreliable)
>>> [c05b5fb0] [c0562784] init_IRQ+0x24/0x38
>>> [c05b5fc0] [c055fde4] start_kernel+0x1bc/0x2ec
>>> [c05b5ff0] [00003444] 0x3444
>>> Instruction dump:
>>> 3d00c04f 38800000 38a01002 38c00000 38e00100 39088f8c 38600000 90010024
>>> bfa10014 4bffec35 7c690034 5529d97e <0f090000> 3fa0c04f 4bfff391 38600000
>>> ---[ end trace 31fd0ba7d8756001 ]---
>>>
>>> Kernel panic - not syncing: Attempted to kill the idle task!
>>> Rebooting in 180 seconds..
>>>
>>>
>>> Thanks & Regards
>>> Ashish Khetan
>>>
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>>
>>>
>>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
>
> --
> Regards,
> Sri.
>
[-- Attachment #2: Type: text/html, Size: 19988 bytes --]
^ permalink raw reply
* [PATCH] mtd: nand: remove pasemi_nand driver
From: Olof Johansson @ 2013-12-27 5:52 UTC (permalink / raw)
To: David Woodhouse, Brian Norris
Cc: Olof Johansson, linuxppc-dev, linux-mtd, linux-kernel
The PA Semi platform is sparsely used these days (with just a handful
of known users out there). I'm 100% sure none of them use the MTD NAND
driver -- most standard use cases include PCI-e SATA controllers for
storage instead, and boot is done from LPC NOR flash.
So, there's little reason to keep carrying a driver that's not used by
anybody and that just gets hit by some tree-wide or tools-based changes
every now and then.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
drivers/mtd/nand/pasemi_nand.c | 238 ----------------------------------------
1 file changed, 238 deletions(-)
delete mode 100644 drivers/mtd/nand/pasemi_nand.c
diff --git a/drivers/mtd/nand/pasemi_nand.c b/drivers/mtd/nand/pasemi_nand.c
deleted file mode 100644
index 90f871a..0000000
--- a/drivers/mtd/nand/pasemi_nand.c
+++ /dev/null
@@ -1,238 +0,0 @@
-/*
- * Copyright (C) 2006-2007 PA Semi, Inc
- *
- * Author: Egor Martovetsky <egor@pasemi.com>
- * Maintained by: Olof Johansson <olof@lixom.net>
- *
- * Driver for the PWRficient onchip NAND flash interface
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#undef DEBUG
-
-#include <linux/slab.h>
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/nand.h>
-#include <linux/mtd/nand_ecc.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
-#include <linux/of_platform.h>
-#include <linux/platform_device.h>
-#include <linux/pci.h>
-
-#include <asm/io.h>
-
-#define LBICTRL_LPCCTL_NR 0x00004000
-#define CLE_PIN_CTL 15
-#define ALE_PIN_CTL 14
-
-static unsigned int lpcctl;
-static struct mtd_info *pasemi_nand_mtd;
-static const char driver_name[] = "pasemi-nand";
-
-static void pasemi_read_buf(struct mtd_info *mtd, u_char *buf, int len)
-{
- struct nand_chip *chip = mtd->priv;
-
- while (len > 0x800) {
- memcpy_fromio(buf, chip->IO_ADDR_R, 0x800);
- buf += 0x800;
- len -= 0x800;
- }
- memcpy_fromio(buf, chip->IO_ADDR_R, len);
-}
-
-static void pasemi_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
-{
- struct nand_chip *chip = mtd->priv;
-
- while (len > 0x800) {
- memcpy_toio(chip->IO_ADDR_R, buf, 0x800);
- buf += 0x800;
- len -= 0x800;
- }
- memcpy_toio(chip->IO_ADDR_R, buf, len);
-}
-
-static void pasemi_hwcontrol(struct mtd_info *mtd, int cmd,
- unsigned int ctrl)
-{
- struct nand_chip *chip = mtd->priv;
-
- if (cmd == NAND_CMD_NONE)
- return;
-
- if (ctrl & NAND_CLE)
- out_8(chip->IO_ADDR_W + (1 << CLE_PIN_CTL), cmd);
- else
- out_8(chip->IO_ADDR_W + (1 << ALE_PIN_CTL), cmd);
-
- /* Push out posted writes */
- eieio();
- inl(lpcctl);
-}
-
-int pasemi_device_ready(struct mtd_info *mtd)
-{
- return !!(inl(lpcctl) & LBICTRL_LPCCTL_NR);
-}
-
-static int pasemi_nand_probe(struct platform_device *ofdev)
-{
- struct pci_dev *pdev;
- struct device_node *np = ofdev->dev.of_node;
- struct resource res;
- struct nand_chip *chip;
- int err = 0;
-
- err = of_address_to_resource(np, 0, &res);
-
- if (err)
- return -EINVAL;
-
- /* We only support one device at the moment */
- if (pasemi_nand_mtd)
- return -ENODEV;
-
- pr_debug("pasemi_nand at %pR\n", &res);
-
- /* Allocate memory for MTD device structure and private data */
- pasemi_nand_mtd = kzalloc(sizeof(struct mtd_info) +
- sizeof(struct nand_chip), GFP_KERNEL);
- if (!pasemi_nand_mtd) {
- printk(KERN_WARNING
- "Unable to allocate PASEMI NAND MTD device structure\n");
- err = -ENOMEM;
- goto out;
- }
-
- /* Get pointer to private data */
- chip = (struct nand_chip *)&pasemi_nand_mtd[1];
-
- /* Link the private data with the MTD structure */
- pasemi_nand_mtd->priv = chip;
- pasemi_nand_mtd->owner = THIS_MODULE;
-
- chip->IO_ADDR_R = of_iomap(np, 0);
- chip->IO_ADDR_W = chip->IO_ADDR_R;
-
- if (!chip->IO_ADDR_R) {
- err = -EIO;
- goto out_mtd;
- }
-
- pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa008, NULL);
- if (!pdev) {
- err = -ENODEV;
- goto out_ior;
- }
-
- lpcctl = pci_resource_start(pdev, 0);
- pci_dev_put(pdev);
-
- if (!request_region(lpcctl, 4, driver_name)) {
- err = -EBUSY;
- goto out_ior;
- }
-
- chip->cmd_ctrl = pasemi_hwcontrol;
- chip->dev_ready = pasemi_device_ready;
- chip->read_buf = pasemi_read_buf;
- chip->write_buf = pasemi_write_buf;
- chip->chip_delay = 0;
- chip->ecc.mode = NAND_ECC_SOFT;
-
- /* Enable the following for a flash based bad block table */
- chip->bbt_options = NAND_BBT_USE_FLASH;
-
- /* Scan to find existence of the device */
- if (nand_scan(pasemi_nand_mtd, 1)) {
- err = -ENXIO;
- goto out_lpc;
- }
-
- if (mtd_device_register(pasemi_nand_mtd, NULL, 0)) {
- printk(KERN_ERR "pasemi_nand: Unable to register MTD device\n");
- err = -ENODEV;
- goto out_lpc;
- }
-
- printk(KERN_INFO "PA Semi NAND flash at %08llx, control at I/O %x\n",
- res.start, lpcctl);
-
- return 0;
-
- out_lpc:
- release_region(lpcctl, 4);
- out_ior:
- iounmap(chip->IO_ADDR_R);
- out_mtd:
- kfree(pasemi_nand_mtd);
- out:
- return err;
-}
-
-static int pasemi_nand_remove(struct platform_device *ofdev)
-{
- struct nand_chip *chip;
-
- if (!pasemi_nand_mtd)
- return 0;
-
- chip = pasemi_nand_mtd->priv;
-
- /* Release resources, unregister device */
- nand_release(pasemi_nand_mtd);
-
- release_region(lpcctl, 4);
-
- iounmap(chip->IO_ADDR_R);
-
- /* Free the MTD device structure */
- kfree(pasemi_nand_mtd);
-
- pasemi_nand_mtd = NULL;
-
- return 0;
-}
-
-static const struct of_device_id pasemi_nand_match[] =
-{
- {
- .compatible = "pasemi,localbus-nand",
- },
- {},
-};
-
-MODULE_DEVICE_TABLE(of, pasemi_nand_match);
-
-static struct platform_driver pasemi_nand_driver =
-{
- .driver = {
- .name = driver_name,
- .owner = THIS_MODULE,
- .of_match_table = pasemi_nand_match,
- },
- .probe = pasemi_nand_probe,
- .remove = pasemi_nand_remove,
-};
-
-module_platform_driver(pasemi_nand_driver);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Egor Martovetsky <egor@pasemi.com>");
-MODULE_DESCRIPTION("NAND flash interface driver for PA Semi PWRficient");
--
1.7.10.4
^ permalink raw reply related
* Re: MPC8641 based custom board kernel Bug
From: Sri Ram Vemulpali @ 2013-12-27 6:40 UTC (permalink / raw)
To: Ashish Khetan; +Cc: scottwood, linuxppc-dev, wyang, kernelnewbies
In-Reply-To: <CAERE9PrX61oNtQoT1tpL_+rXfirFeMa4woD2P2TSUJ_Xj-h4rg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 15995 bytes --]
You need to modify the base address of the each node to map in to processor
address space. All device nodes in device tree are provisioned with
physical addresses in processor domain. You need to understand the device
tree structure. Check your specs regarding the I/O mapping of the processor
memory. Following link is good example
http://xillybus.com/tutorials/device-tree-zynq-1
Regards,
Sri.
On Thu, Dec 26, 2013 at 9:20 PM, Ashish Khetan <curieux.khetan@gmail.com>wrote:
> I am using the defconfig from linux kernel tree and for CCSR in u-boot its
> F8000000 so the same i am using in device tree... so my question is - is it
> unable to parse device tree ? or in device tree some thing need to modify
> in device tree or in kernel source...
> please give some light on this...
>
>
> Thanks & Regards
> Ashish Khetan
>
>
> On Fri, Dec 27, 2013 at 4:21 AM, Sri Ram Vemulpali <
> sri.ram.gmu06@gmail.com> wrote:
>
>> Why do not you use deconfig from linux kernel tree. Modify only base
>> address of CCSR (soc node) for child nodes of root in device tree.
>> arch/powerpc/boot/dts/mpc8641_hpcn.dts.
>>
>> Sri
>>
>>
>> On Thu, Dec 26, 2013 at 3:48 AM, Ashish Khetan <curieux.khetan@gmail.com>wrote:
>>
>>> i tried to dig more inside mpic_alloc fails. the function
>>> of_find_matching_node calls inside from mpic_alloc() should return the node
>>> at which pic is connected but it returns NULL. but why? In device tree i am
>>> using the following.. may be it will helpful.
>>> /dts-v1/;
>>>
>>> / {
>>> model = "MPC8641HPCN";
>>> compatible = "fsl,mpc8641hpcn";
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>>
>>> aliases {
>>> ethernet0 = "/soc8641@f8000000/ethernet@24000";
>>> ethernet1 = "/soc8641@f8000000/ethernet@25000";
>>> ethernet2 = "/soc8641@f8000000/ethernet@26000";
>>> ethernet3 = "/soc8641@f8000000/ethernet@27000";
>>> serial0 = "/soc8641@f8000000/serial@4500";
>>> };
>>>
>>> cpus {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x0>;
>>>
>>> PowerPC,8641@0 {
>>> device_type = "cpu";
>>> reg = <0x0>;
>>> d-cache-line-size = <0x20>;
>>> i-cache-line-size = <0x20>;
>>> d-cache-size = <0x8000>;
>>> i-cache-size = <0x8000>;
>>> timebase-frequency = <0x0>;
>>> bus-frequency = <0x0>;
>>> clock-frequency = <0x0>;
>>> };
>>> };
>>>
>>> memory {
>>> device_type = "memory";
>>> reg = <0x0 0x20000000>;
>>> };
>>>
>>> localbus@f8005000 {
>>> #address-cells = <0x2>;
>>> #size-cells = <0x1>;
>>> compatible = "fsl,mpc8641-localbus", "simple-bus";
>>> reg = <0xf8005000 0x1000>;
>>> interrupts = <0x13 0x2>;
>>> interrupt-parent = <0x1>;
>>> ranges = <0x0 0x0 0xff000000 0x1000000>;
>>>
>>> flash@0,0 {
>>> compatible = "cfi-flash";
>>> reg = <0x0 0x0 0x800000>;
>>> bank-width = <0x2>;
>>> device-width = <0x2>;
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>> };
>>> };
>>>
>>> soc8641@f8000000 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>> device_type = "soc";
>>> compatible = "simple-bus";
>>> ranges = <0x0 0xf8000000 0x100000>;
>>> bus-frequency = <0x0>;
>>>
>>> mcm-law@0 {
>>> compatible = "fsl,mcm-law";
>>> reg = <0x0 0x1000>;
>>> fsl,num-laws = <0xa>;
>>> };
>>>
>>> mcm@1000 {
>>> compatible = "fsl,mpc8641-mcm", "fsl,mcm";
>>> reg = <0x1000 0x1000>;
>>> interrupts = <0x11 0x2>;
>>> interrupt-parent = <0x1>;
>>> };
>>>
>>> dma@21300 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>> compatible = "fsl,mpc8641-dma", "fsl,eloplus-dma";
>>> reg = <0x21300 0x4>;
>>> ranges = <0x0 0x21100 0x200>;
>>> cell-index = <0x0>;
>>>
>>> dma-channel@0 {
>>> compatible = "fsl,mpc8641-dma-channel",
>>> "fsl,eloplus-dma-channel";
>>> reg = <0x0 0x80>;
>>> cell-index = <0x0>;
>>> interrupt-parent = <0x1>;
>>> interrupts = <0x14 0x2>;
>>> };
>>>
>>> dma-channel@80 {
>>> compatible = "fsl,mpc8641-dma-channel",
>>> "fsl,eloplus-dma-channel";
>>> reg = <0x80 0x80>;
>>> cell-index = <0x1>;
>>> interrupt-parent = <0x1>;
>>> interrupts = <0x15 0x2>;
>>> };
>>>
>>> dma-channel@100 {
>>> compatible = "fsl,mpc8641-dma-channel",
>>> "fsl,eloplus-dma-channel";
>>> reg = <0x100 0x80>;
>>> cell-index = <0x2>;
>>> interrupt-parent = <0x1>;
>>> interrupts = <0x16 0x2>;
>>> };
>>>
>>> dma-channel@180 {
>>> compatible = "fsl,mpc8641-dma-channel",
>>> "fsl,eloplus-dma-channel";
>>> reg = <0x180 0x80>;
>>> cell-index = <0x3>;
>>> interrupt-parent = <0x1>;
>>> interrupts = <0x17 0x2>;
>>> };
>>> };
>>>
>>> ethernet@24000 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>> cell-index = <0x0>;
>>> device_type = "network";
>>> model = "TSEC";
>>> compatible = "gianfar";
>>> reg = <0x24000 0x1000>;
>>> ranges = <0x0 0x24000 0x1000>;
>>> local-mac-address = [00 00 00 00 00 00];
>>> interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
>>> interrupt-parent = <0x1>;
>>> tbi-handle = <0x2>;
>>> phy-handle = <0x3>;
>>> phy-connection-type = "rgmii-id";
>>>
>>> mdio@520 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x0>;
>>> compatible = "fsl,gianfar-mdio";
>>> reg = <0x520 0x20>;
>>>
>>> ethernet-phy@0 {
>>> interrupt-parent = <0x1>;
>>> interrupts = <0xa 0x1>;
>>> reg = <0x0>;
>>> device_type = "ethernet-phy";
>>> linux,phandle = <0x3>;
>>> };
>>>
>>> ethernet-phy@1 {
>>> interrupt-parent = <0x1>;
>>> interrupts = <0xa 0x1>;
>>> reg = <0x1>;
>>> device_type = "ethernet-phy";
>>> linux,phandle = <0x5>;
>>> };
>>>
>>> ethernet-phy@2 {
>>> interrupt-parent = <0x1>;
>>> interrupts = <0xa 0x1>;
>>> reg = <0x2>;
>>> device_type = "ethernet-phy";
>>> linux,phandle = <0x7>;
>>> };
>>>
>>> ethernet-phy@3 {
>>> interrupt-parent = <0x1>;
>>> interrupts = <0xa 0x1>;
>>> reg = <0x3>;
>>> device_type = "ethernet-phy";
>>> linux,phandle = <0x9>;
>>> };
>>>
>>> tbi-phy@11 {
>>> reg = <0x11>;
>>> device_type = "tbi-phy";
>>> linux,phandle = <0x2>;
>>> };
>>> };
>>> };
>>>
>>> ethernet@25000 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>> cell-index = <0x1>;
>>> device_type = "network";
>>> model = "TSEC";
>>> compatible = "gianfar";
>>> reg = <0x25000 0x1000>;
>>> ranges = <0x0 0x25000 0x1000>;
>>> local-mac-address = [00 00 00 00 00 00];
>>> interrupts = <0x23 0x2 0x24 0x2 0x28 0x2>;
>>> interrupt-parent = <0x1>;
>>> tbi-handle = <0x4>;
>>> phy-handle = <0x5>;
>>> phy-connection-type = "rgmii-id";
>>>
>>> mdio@520 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x0>;
>>> compatible = "fsl,gianfar-tbi";
>>> reg = <0x520 0x20>;
>>>
>>> tbi-phy@11 {
>>> reg = <0x11>;
>>> device_type = "tbi-phy";
>>> linux,phandle = <0x4>;
>>> };
>>> };
>>> };
>>>
>>> ethernet@26000 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>> cell-index = <0x2>;
>>> device_type = "network";
>>> model = "TSEC";
>>> compatible = "gianfar";
>>> reg = <0x26000 0x1000>;
>>> ranges = <0x0 0x26000 0x1000>;
>>> local-mac-address = [00 00 00 00 00 00];
>>> interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
>>> interrupt-parent = <0x1>;
>>> tbi-handle = <0x6>;
>>> phy-handle = <0x7>;
>>> phy-connection-type = "rgmii-id";
>>>
>>> mdio@520 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x0>;
>>> compatible = "fsl,gianfar-tbi";
>>> reg = <0x520 0x20>;
>>>
>>> tbi-phy@11 {
>>> reg = <0x11>;
>>> device_type = "tbi-phy";
>>> linux,phandle = <0x6>;
>>> };
>>> };
>>> };
>>>
>>> ethernet@27000 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x1>;
>>> cell-index = <0x3>;
>>> device_type = "network";
>>> model = "TSEC";
>>> compatible = "gianfar";
>>> reg = <0x27000 0x1000>;
>>> ranges = <0x0 0x27000 0x1000>;
>>> local-mac-address = [00 00 00 00 00 00];
>>> interrupts = <0x25 0x2 0x26 0x2 0x27 0x2>;
>>> interrupt-parent = <0x1>;
>>> tbi-handle = <0x8>;
>>> phy-handle = <0x9>;
>>> phy-connection-type = "rgmii-id";
>>>
>>> mdio@520 {
>>> #address-cells = <0x1>;
>>> #size-cells = <0x0>;
>>> compatible = "fsl,gianfar-tbi";
>>> reg = <0x520 0x20>;
>>>
>>> tbi-phy@11 {
>>> reg = <0x11>;
>>> device_type = "tbi-phy";
>>> linux,phandle = <0x8>;
>>> };
>>> };
>>> };
>>>
>>> serial@4500 {
>>> cell-index = <0x0>;
>>> device_type = "serial";
>>> compatible = "ns16550";
>>> reg = <0x4500 0x100>;
>>> clock-frequency = <0x0>;
>>> interrupts = <0x2a 0x2>;
>>> interrupt-parent = <0x1>;
>>> };
>>>
>>> pic@40000 {
>>> interrupt-controller;
>>> #address-cells = <0x0>;
>>> #interrupt-cells = <0x2>;
>>> reg = <0x40000 0x40000>;
>>> compatible = "chrp,open-pic";
>>> device_type = "open-pic";
>>> linux,phandle = <0x1>;
>>> phandle = <0x1>;
>>> };
>>>
>>> global-utilities@e0000 {
>>> compatible = "fsl,mpc8641-guts";
>>> reg = <0xe0000 0x1000>;
>>> fsl,has-rstcr;
>>> };
>>> };
>>>
>>> chosen {
>>> linux,stdout-path = "/soc8641/serial0: serial@4500";
>>> };
>>> };
>>>
>>>
>>>
>>>
>>> On Thu, Dec 26, 2013 at 2:37 PM, wyang <w90p710@gmail.com> wrote:
>>>
>>>> On 12/26/2013 01:09 PM, Ashish Khetan wrote:
>>>>
>>>> Hi,
>>>> I was trying to port Linux-3.12 for MPC8641 based custom designed
>>>> board for evaluation purpose. I have been facing a kernel bug at mpic
>>>> initialization. Is somebody have faced this kind of bugs or can give me any
>>>> pointer for further steps how to solve kernel bugs will be really helpful.
>>>> here is the snapshot for the bug that may be helpful to address the bug.
>>>> Using MPC86xx HPCN machine description
>>>> Total memory = 512MB; using 1024kB for hash table (at cff00000)
>>>> Linux version 3.12.0 (ashish@ashish-VirtualBox) (gcc version 4.7.2
>>>> (GCC) ) #2 We
>>>> d Dec 25 16:04:36 IST 2013
>>>> Found initrd at 0xde975000:0xdfec428a
>>>> bootconsole [udbg0] enabled
>>>> setup_arch: bootmem
>>>> mpc86xx_hpcn_setup_arch()
>>>> MPC86xx HPCN board from Freescale Semiconductor
>>>> arch: exit
>>>> Zone ranges:
>>>> DMA [mem 0x00000000-0x1fffffff]
>>>> Normal empty
>>>> HighMem empty
>>>> Movable zone start for each node
>>>> Early memory node ranges
>>>> node 0: [mem 0x00000000-0x1fffffff]
>>>> Built 1 zonelists in Zone order, mobility grouping on. Total pages:
>>>> 130048
>>>> Kernel command line: root=/dev/ram0 rw rootfs console=ttyS0,115200
>>>> PID hash table entries: 2048 (order: 1, 8192 bytes)
>>>> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
>>>> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
>>>> Sorting __ex_table...
>>>> Memory: 424980K/524288K available (4172K kernel code, 208K rwdata,
>>>> 1304K rodata,
>>>> 196K init, 149K bss, 99308K reserved, 0K highmem)
>>>> Kernel virtual memory layout:
>>>> * 0xfffcf000..0xfffff000 : fixmap
>>>> * 0xff800000..0xffc00000 : highmem PTEs
>>>> * 0xff7fe000..0xff800000 : early ioremap
>>>> * 0xe1000000..0xff7fe000 : vmalloc & ioremap
>>>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>>>> NR_IRQS:512 nr_irqs:512 16
>>>> ------------[ cut here ]------------
>>>> kernel BUG at arch/powerpc/platforms/86xx/pic.c:42!
>>>>
>>>>
>>>> It hints that mpic_alloc() fails. Maybe, you should spend some time
>>>> investigating why it fails. :-)
>>>>
>>>> Thanks
>>>> Wei
>>>>
>>>> Oops: Exception in kernel mode, sig: 5 [#1]
>>>> MPC86xx HPCN
>>>> Modules linked in:
>>>> CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0 #2
>>>> task: c05903e0 ti: c05b4000 task.ti: c05b4000
>>>> NIP: c0567438 LR: c0567430 CTR: c0567400
>>>> REGS: c05b5ee0 TRAP: 0700 Not tainted (3.12.0)
>>>> MSR: 00021032 <ME,IR,DR,RI> CR: 24000042 XER: 20000000
>>>>
>>>> GPR00: c0567430 c05b5f90 c05903e0 00000000 c04e4ff8 c051e588 0000008f
>>>> 00000002
>>>> GPR08: c042789c 00000001 0000006f 00000000 22000048 bebffffd 11a7b4e5
>>>> 200c8000
>>>> GPR16: ffbeffff ffffffff 00000000 00000024 00000000 1fec56f8 1fec59a7
>>>> 00000000
>>>> GPR24: 00000000 1fff97e8 40000000 1ffcc6a0 c0bff080 c05c2490 c05c2628
>>>> c0585b60
>>>> NIP [c0567438] mpc86xx_init_irq+0x38/0x108
>>>> LR [c0567430] mpc86xx_init_irq+0x30/0x108
>>>> Call Trace:
>>>> [c05b5f90] [c0567430] mpc86xx_init_irq+0x30/0x108 (unreliable)
>>>> [c05b5fb0] [c0562784] init_IRQ+0x24/0x38
>>>> [c05b5fc0] [c055fde4] start_kernel+0x1bc/0x2ec
>>>> [c05b5ff0] [00003444] 0x3444
>>>> Instruction dump:
>>>> 3d00c04f 38800000 38a01002 38c00000 38e00100 39088f8c 38600000 90010024
>>>> bfa10014 4bffec35 7c690034 5529d97e <0f090000> 3fa0c04f 4bfff391
>>>> 38600000
>>>> ---[ end trace 31fd0ba7d8756001 ]---
>>>>
>>>> Kernel panic - not syncing: Attempted to kill the idle task!
>>>> Rebooting in 180 seconds..
>>>>
>>>>
>>>> Thanks & Regards
>>>> Ashish Khetan
>>>>
>>>>
>>>> _______________________________________________
>>>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>
>>
>> --
>> Regards,
>> Sri.
>>
>
>
--
Regards,
Sri.
[-- Attachment #2: Type: text/html, Size: 21200 bytes --]
^ permalink raw reply
* Re: [PATCH] mtd: nand: remove pasemi_nand driver
From: Paul Bolle @ 2013-12-27 9:10 UTC (permalink / raw)
To: Olof Johansson; +Cc: linux-mtd, linuxppc-dev, David Woodhouse, linux-kernel
In-Reply-To: <1388123524-9000-1-git-send-email-olof@lixom.net>
On Thu, 2013-12-26 at 21:52 -0800, Olof Johansson wrote:
> The PA Semi platform is sparsely used these days (with just a handful
> of known users out there). I'm 100% sure none of them use the MTD NAND
> driver -- most standard use cases include PCI-e SATA controllers for
> storage instead, and boot is done from LPC NOR flash.
>
> So, there's little reason to keep carrying a driver that's not used by
> anybody and that just gets hit by some tree-wide or tools-based changes
> every now and then.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> drivers/mtd/nand/pasemi_nand.c | 238 ----------------------------------------
> 1 file changed, 238 deletions(-)
> delete mode 100644 drivers/mtd/nand/pasemi_nand.c
If this gets accepted we should remove the related entry in
drivers/mtd/nand/Kconfig and the related line in
drivers/mtd/nand/Makefile too, shouldn't we?
Paul Bolle
^ permalink raw reply
* Re: [PATCH] mtd: nand: remove pasemi_nand driver
From: Olof Johansson @ 2013-12-27 21:34 UTC (permalink / raw)
To: Paul Bolle
Cc: linux-mtd@lists.infradead.org, linuxppc-dev, David Woodhouse,
linux-kernel@vger.kernel.org
In-Reply-To: <1388135456.5072.3.camel@x220>
On Fri, Dec 27, 2013 at 1:10 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Thu, 2013-12-26 at 21:52 -0800, Olof Johansson wrote:
>> The PA Semi platform is sparsely used these days (with just a handful
>> of known users out there). I'm 100% sure none of them use the MTD NAND
>> driver -- most standard use cases include PCI-e SATA controllers for
>> storage instead, and boot is done from LPC NOR flash.
>>
>> So, there's little reason to keep carrying a driver that's not used by
>> anybody and that just gets hit by some tree-wide or tools-based changes
>> every now and then.
>>
>> Signed-off-by: Olof Johansson <olof@lixom.net>
>> ---
>> drivers/mtd/nand/pasemi_nand.c | 238 ----------------------------------------
>> 1 file changed, 238 deletions(-)
>> delete mode 100644 drivers/mtd/nand/pasemi_nand.c
>
> If this gets accepted we should remove the related entry in
> drivers/mtd/nand/Kconfig and the related line in
> drivers/mtd/nand/Makefile too, shouldn't we?
D'oh. Yes, of course. v2 coming.
-Olof
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/eeh: Add restore_bars operation
From: Benjamin Herrenschmidt @ 2013-12-27 22:20 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1387961936-20451-1-git-send-email-shangw@linux.vnet.ibm.com>
On Wed, 2013-12-25 at 16:58 +0800, Gavin Shan wrote:
> After reset on the specific PE or PHB, we never configure AER
> correctly on PowerNV platform. We needn't care it on pSeries
> platform. The patch introduces additional EEH operation eeh_ops::
> restore_bars() so that we have chance to configure AER correctly
> for PowerNV platform.
Why call it "restore_bars" if it restores something else (in this case
AER) ?
I would call it "restore_config" instead... Also rather than adding
the knowledge of what AER bit works or not for the device, would it
make sense to instead have a FW call to re-init the device ?
Otherwise, you introduce duplication between Linux and Firmware with
the risk of getting out of sync...
Cheers,
Ben.
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/eeh.h | 1 +
> arch/powerpc/kernel/eeh_pe.c | 3 +++
> arch/powerpc/platforms/pseries/eeh_pseries.c | 4 +++-
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
> index d3e5e9b..4b709bf 100644
> --- a/arch/powerpc/include/asm/eeh.h
> +++ b/arch/powerpc/include/asm/eeh.h
> @@ -157,6 +157,7 @@ struct eeh_ops {
> int (*read_config)(struct device_node *dn, int where, int size, u32 *val);
> int (*write_config)(struct device_node *dn, int where, int size, u32 val);
> int (*next_error)(struct eeh_pe **pe);
> + void (*restore_bars)(struct device_node *dn);
> };
>
> extern struct eeh_ops *eeh_ops;
> diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kernel/eeh_pe.c
> index f945053..19eb95a 100644
> --- a/arch/powerpc/kernel/eeh_pe.c
> +++ b/arch/powerpc/kernel/eeh_pe.c
> @@ -737,6 +737,9 @@ static void *eeh_restore_one_device_bars(void *data, void *flag)
> else
> eeh_restore_device_bars(edev, dn);
>
> + if (eeh_ops->restore_bars)
> + eeh_ops->restore_bars(dn);
> +
> return NULL;
> }
>
> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
> index ccb633e..623adaf 100644
> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
> @@ -689,7 +689,9 @@ static struct eeh_ops pseries_eeh_ops = {
> .get_log = pseries_eeh_get_log,
> .configure_bridge = pseries_eeh_configure_bridge,
> .read_config = pseries_eeh_read_config,
> - .write_config = pseries_eeh_write_config
> + .write_config = pseries_eeh_write_config,
> + .next_error = NULL,
> + .restore_bars = NULL
> };
>
> /**
^ permalink raw reply
* Re: [PATCH 4/5] powerpc/fsl-booke: Add initial T208x QDS board support
From: Scott Wood @ 2013-12-27 22:53 UTC (permalink / raw)
To: Liu Shengzhou-B36685; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1baad106bec84b5a9f8f3298e1476330@DM2PR03MB398.namprd03.prod.outlook.com>
On Fri, 2013-12-20 at 00:42 -0600, Liu Shengzhou-B36685 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, December 18, 2013 3:57 AM
> > To: Liu Shengzhou-B36685
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH 4/5] powerpc/fsl-booke: Add initial T208x QDS board
> > support
> >
> > On Wed, 2013-12-11 at 19:19 +0800, Shengzhou Liu wrote:
> > > + boardctrl: board-control@3,0 {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + compatible = "fsl,fpga-qixis";
> > > + reg = <3 0 0x300>;
> > > + ranges = <0 3 0 0x300>;
> > > + };
> >
> > Why do you have ranges and #address-cells/#size-cells here? When would
> > there ever be a child node?
>
> [Shengzhou] There are multiple child nodes for this(in a separate DPAA-related patch, but whole DPAA module has not been upstreamed yet so far)
Those properties can be added if and when the dpaa nodes go upstream.
They don't make sense as is.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/mpic_timer: fix the time calculation is not accurate
From: Scott Wood @ 2013-12-27 23:59 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: linuxppc-dev
In-Reply-To: <1387766025-46101-1-git-send-email-dongsheng.wang@freescale.com>
On Mon, 2013-12-23 at 10:33 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> When the timer GTCCR toggle bit is inverted, we calculated the rest
> of the time is not accurate. So we need to ignore this bit.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/arch/powerpc/sysdev/mpic_timer.c b/arch/powerpc/sysdev/mpic_timer.c
> index 22d7d57..0fb70c9 100644
> --- a/arch/powerpc/sysdev/mpic_timer.c
> +++ b/arch/powerpc/sysdev/mpic_timer.c
> @@ -41,6 +41,7 @@
> #define MPIC_TIMER_TCR_ROVR_OFFSET 24
>
> #define TIMER_STOP 0x80000000
> +#define GTCCR_TOG 0x80000000
> #define TIMERS_PER_GROUP 4
> #define MAX_TICKS (~0U >> 1)
> #define MAX_TICKS_CASCADE (~0U)
> @@ -96,8 +97,15 @@ static void convert_ticks_to_time(struct timer_group_priv *priv,
> time->tv_sec = (__kernel_time_t)div_u64(ticks, priv->timerfreq);
> tmp_sec = (u64)time->tv_sec * (u64)priv->timerfreq;
>
> - time->tv_usec = (__kernel_suseconds_t)
> - div_u64((ticks - tmp_sec) * 1000000, priv->timerfreq);
> + time->tv_usec = 0;
> +
> + /*
> + * In some cases tmp_sec may be greater than ticks, because in the
> + * process of calculation ticks and tmp_sec will be rounded.
> + */
> + if (tmp_sec <= ticks)
> + time->tv_usec = (__kernel_suseconds_t)
> + div_u64((ticks - tmp_sec) * 1000000, priv->timerfreq);
I don't see how this part of the patch relates to the patch description.
-Scott
^ permalink raw reply
* 3.13-rc3: BUG: soft lockup - CPU#0 stuck for 23s!
From: Christian Kujau @ 2013-12-28 4:00 UTC (permalink / raw)
To: LKML; +Cc: linuxppc-dev, xfs
I noticed that my machine locks up quite often with 3.13.-rc3.
PowerPC G4 again, but this machine was pretty much rock solid until now:
when there's lots of disk I/O going on, the system locks up, but not
entirely: the calltrace is still written to netconsole (but not to its
local disk) and answers ping requests - but SSH login is impossible and a
reset is needed. The workload of the machine has not changed, when there's
disk I/O it means that either rsync is running or some crazy remote Java
application is scanning over this machine's NFS shares.
There's sometimes "xfs" mentioned in the call trace and the disk I/O is
all happening on the xfs mounts, that's why I Cc'ed the xfs mailing list.
More details on: http://nerdbynature.de/bits/3.13-rc3/
Any ideas?
The most recent lockup is from today below, this time it wasn't rsync or
NFS but I was experimenting with xfs on a loop device, backed by a 1GB
file, like this:
$ dd if=/dev/zero of=/usr/local/test.img bs=1M count=1k
$ losetup -f /usr/local/test.img && mkfs.xfs /dev/loop0
$ mount -t xfs /dev/loop0 /mnt/disk
$ cd /mnt/disk
$ cp -ax / /mnt/disk - which filled the disk
$ rm -rf lib/ - make some room
$ i=1; while true; do printf "$i "; dd if=/dev/zero of=f$i \
count=100 bs=100k; i=$(($i+1)); done - filling the disk again
=> and then the machine locked up.
[308783.613600] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:1:14542]
[308783.613703] Modules linked in: md5 ecb nfs i2c_powermac therm_adt746x ecryptfs arc4 b43 firewire_sbp2 usb_storage mac80211 cfg80211
[308783.613944] irq event stamp: 37770086
[308783.613980] hardirqs last enabled at (37770085): [<c0546ff0>] _raw_spin_unlock_irq+0x30/0x60
[308783.614075] hardirqs last disabled at (37770086): [<c0010700>] reenable_mmu+0x30/0x88
[308783.614156] softirqs last enabled at (37764418): [<c00354d4>] __do_softirq+0x168/0x1e8
[308783.614236] softirqs last disabled at (37764411): [<c0035990>] irq_exit+0xa4/0xc8
[308783.614312] CPU: 0 PID: 14542 Comm: kworker/u2:1 Not tainted 3.13.0-rc3-00365-gc48b660 #1
[308783.614384] Workqueue: writeback bdi_writeback_workfn (flush-7:0)
[308783.614454] task: e8d20bb0 ti: e0c5a000 task.ti: e0c5a000
[308783.614499] NIP: c0546ffc LR: c0546ff0 CTR: 00000000
[308783.614543] REGS: e0c5ba80 TRAP: 0901 Not tainted (3.13.0-rc3-00365-gc48b660)
[308783.614596] MSR: 00009032 ,ME ,IR ,DR ,RI > CR: 444c2224 XER: 20000000
[308783.614739] #012GPR00: #012GPR08:
[308783.614998] NIP [c0546ffc] _raw_spin_unlock_irq+0x3c/0x60
[308783.615047] LR [c0546ff0] _raw_spin_unlock_irq+0x30/0x60
[308783.615089] Call Trace:
[308783.615121] [e0c5bb30] [c0546ff0] _raw_spin_unlock_irq+0x30/0x60 (unreliable)
[308783.615202] [e0c5bb40] [c009f0e4] __set_page_dirty_nobuffers+0xc8/0x144
[308783.615264] [e0c5bb60] [c01bec28] xfs_vm_writepage+0x90/0x57c
[308783.615322] [e0c5bbf0] [c009e618] __writepage+0x24/0x7c
[308783.615376] [e0c5bc00] [c009ec38] write_cache_pages+0x1d0/0x380
[308783.615433] [e0c5bca0] [c009ee34] generic_writepages+0x4c/0x70
[308783.615493] [e0c5bce0] [c00f9af8] __writeback_single_inode+0x34/0x12c
[308783.615968] [e0c5bd00] [c00f9e74] writeback_sb_inodes+0x1f4/0x344
[308783.616418] [e0c5bd70] [c00fa050] __writeback_inodes_wb+0x8c/0xd0
[308783.616864] [e0c5bda0] [c00fa258] wb_writeback+0x1c4/0x1cc
[308783.617306] [e0c5bdd0] [c00fae14] bdi_writeback_workfn+0x158/0x33c
[308783.617751] [e0c5be50] [c004906c] process_one_work+0x19c/0x3f0
[308783.618193] [e0c5be80] [c0049a0c] worker_thread+0x128/0x3c0
[308783.618630] [e0c5beb0] [c004fa8c] kthread+0xbc/0xd0
[308783.619071] [e0c5bf40] [c001099c] ret_from_kernel_thread+0x5c/0x64
[308783.619501] Instruction dump:
[308783.619915] 7ca802a6
[308783.620437] 4bb1c681
--
BOFH excuse #446:
Mailer-daemon is busy burning your message in hell.
^ permalink raw reply
* [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: Gavin Hu @ 2013-12-28 5:41 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
Hi
I notice that there is a pair ppc instructions lwarx and stwcx used to
atomtic operation for instance, atomic_inc/atomic_dec.
In some ppc manuals, they more emphasize its mechanism is that lwarx can
reseve the target memory address preventing other CORE from modifying it.
I assume that there is atomtic operation executing on the CORE0 in a
multicore system. In this situation, does the CORE0 disable the local HW
interrupt?
Can the executing process from the beginning of lwarx and end of stwcx be
interrupted by HW interruptions/exceptions? Anyway, they are two assembly
instructions.
Thanks a lot!
"1: lwarx %0,0,%2 # atomic_inc\n\
addic %0,%0,1\n"
" stwcx. %0,0,%2 \n\
BR
Gavin. Hu
[-- Attachment #2: Type: text/html, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 11/39] powerpc: endian safe trampoline
From: Olof Johansson @ 2013-12-28 7:24 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Paul Mackerras, linuxppc-dev, chzigotzky
In-Reply-To: <1379901913-5945-12-git-send-email-anton@samba.org>
Nothing like some holiday powerpc early boot debugging. :-)
On Sun, Sep 22, 2013 at 7:04 PM, Anton Blanchard <anton@samba.org> wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Create a trampoline that works in either endian and flips to
> the expected endian. Use it for primary and secondary thread
> entry as well as RTAS and OF call return.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Some users reported failure with their kernel config to build and run
3.13-rc5. pasemi_defconfig boots just fine, but it seems that
ppc64_defconfig does not.
I've bisected it down to this particular patch. More below.
> diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
> index 0c51fb4..ce05bba 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -845,6 +845,35 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,946)
> #define N_SLINE 68
> #define N_SO 100
>
> -#endif /* __ASSEMBLY__ */
> +/*
> + * Create an endian fixup trampoline
> + *
> + * This starts with a "tdi 0,0,0x48" instruction which is
> + * essentially a "trap never", and thus akin to a nop.
> + *
> + * The opcode for this instruction read with the wrong endian
> + * however results in a b . + 8
> + *
> + * So essentially we use that trick to execute the following
> + * trampoline in "reverse endian" if we are running with the
> + * MSR_LE bit set the "wrong" way for whatever endianness the
> + * kernel is built for.
> + */
>
> +#ifdef CONFIG_PPC_BOOK3E
> +#define FIXUP_ENDIAN
> +#else
> +#define FIXUP_ENDIAN \
> + tdi 0,0,0x48; /* Reverse endian of b . + 8 */ \
> + b $+36; /* Skip trampoline if endian is good */ \
> + .long 0x05009f42; /* bcl 20,31,$+4 */ \
> + .long 0xa602487d; /* mflr r10 */ \
> + .long 0x1c004a39; /* addi r10,r10,28 */ \
> + .long 0xa600607d; /* mfmsr r11 */ \
> + .long 0x01006b69; /* xori r11,r11,1 */ \
> + .long 0xa6035a7d; /* mtsrr0 r10 */ \
> + .long 0xa6037b7d; /* mtsrr1 r11 */ \
> + .long 0x2400004c /* rfid */
So, the combination of this sequence and its execution at __start
seems to be what's causing problems for me. I've both commented out
and nopped out the second instruction and the handcoded LE opcodes,
and it makes no difference -- it seems to be the execution of the tdi
that traps or causes some other problem. And yeah -- it definitely
shouldn't since TO is 0. Likewise if I replace the tdi with nop and
keep the rest it runs fine.
I'm a bit baffled that there's a difference based on what config is
booted. I'm booting a raw vmlinux from a BE firmware. Initial code
sequence is largely the same for both configs.
Unfortunately I no longer have a JTAG environment such that I can
check the value of r0 at the time of tdi execution. Still, based on
docs it shouldn't matter since there are no TO bits set. I don't see a
rational reason to why the above should fail. And indeed, if I load a
known-different value and set TO=4, I still see failures. Etc.
I also tried moving the FIXUP_ENDIAN call until after the branch to
__start_initialization_multiplatform but before 64-bit enable and
there it runs just fine.
So, I'm really quite baffled right now. Any ideas would be welcome,
I'm sort of stumped. In particular since pasemi_defconfig boots fine.
-Olof
^ permalink raw reply
* Re: [PATCH 11/39] powerpc: endian safe trampoline
From: Benjamin Herrenschmidt @ 2013-12-28 7:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, chzigotzky
In-Reply-To: <CAOesGMgKjAe5VR9waKCboK+mRwVfde89x+6gew9wjiCf8mAd8A@mail.gmail.com>
On Fri, 2013-12-27 at 23:24 -0800, Olof Johansson wrote:
>
> So, I'm really quite baffled right now. Any ideas would be welcome,
> I'm sort of stumped. In particular since pasemi_defconfig boots fine.
So you are coming in with "good" endian... what if you stick an
isync in there just for fun ? I wonder if it prefetches the "bad"
instructions and somewhat gets itself confused.
Also did you try sticking a b . around 0x700 see if that's where it's
going and what condition gets set ?
Cheers,
Ben.
^ permalink raw reply
* Please pull 'merge' branch of 5xxx tree
From: Anatolij Gustschin @ 2013-12-28 12:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben !
Please pull two DTS fixes for MPC5125 tower board. Without
them the v3.13-rcX kernels do not boot.
Thanks,
Anatolij
The following changes since commit 803c2d2f84da9dc2619449994af34d27148ab20d:
powerpc/powernv: Fix OPAL LPC access in Little Endian (2013-12-13 15:55:15 +1100)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git merge
for you to fetch changes up to 11daf32be9a6041a2406c2cbf76b75a9c4a6eaaa:
powerpc/512x: dts: disable MPC5125 usb module (2013-12-20 22:12:07 +0100)
----------------------------------------------------------------
Gerhard Sittig (1):
powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125)
Matteo Facchinetti (1):
powerpc/512x: dts: disable MPC5125 usb module
arch/powerpc/boot/dts/mpc5125twr.dts | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] powerpc: Fix alignment of secondary cpu spin vars
From: Olof Johansson @ 2013-12-28 21:01 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, linuxppc-dev, linux-kernel, anton
Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
losing proper alignment of the spinlock variables used when booting
secondary CPUs, causing some quite odd issues with failing to boot on
PA Semi-based systems.
This showed itself on ppc64_defconfig, but not on pasemi_defconfig,
so it had gone unnoticed when I initially tested the LE patch set.
Fix is to add explicit alignment instead of relying on good luck. :)
Fixes: 5c0484e25ec0 ('powerpc: Endian safe trampoline')
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=67811
Signed-off-by: Olof Johansson <olof@lixom.net>
---
arch/powerpc/kernel/head_64.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 2ae41ab..4d94477 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -80,6 +80,7 @@ END_FTR_SECTION(0, 1)
* of the function that the cpu should jump to to continue
* initialization.
*/
+ .balign 8
.globl __secondary_hold_spinloop
__secondary_hold_spinloop:
.llong 0x0
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix alignment of secondary cpu spin vars
From: Olof Johansson @ 2013-12-28 21:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linuxppc-dev, linux-kernel@vger.kernel.org,
Anton Blanchard
In-Reply-To: <1388264507-5100-1-git-send-email-olof@lixom.net>
On Sat, Dec 28, 2013 at 1:01 PM, Olof Johansson <olof@lixom.net> wrote:
> Commit 5c0484e25ec0 ('powerpc: Endian safe trampoline') resulted in
> losing proper alignment of the spinlock variables used when booting
> secondary CPUs, causing some quite odd issues with failing to boot on
> PA Semi-based systems.
>
> This showed itself on ppc64_defconfig, but not on pasemi_defconfig,
> so it had gone unnoticed when I initially tested the LE patch set.
>
> Fix is to add explicit alignment instead of relying on good luck. :)
>
> Fixes: 5c0484e25ec0 ('powerpc: Endian safe trampoline')
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=67811
> Signed-off-by: Olof Johansson <olof@lixom.net>
Sigh, it's not this after all. I did a clean build with this applied
and still see failures. Something else is (also?) going on here.
-Olof
^ permalink raw reply
* Re: [PATCH 19/25] fix error return code
From: Geert Uytterhoeven @ 2013-12-29 21:58 UTC (permalink / raw)
To: Julia Lawall
Cc: cbe-oss-dev@lists.ozlabs.org, scsi, Geoff Levand,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
James E.J. Bottomley, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1388357260-4843-20-git-send-email-Julia.Lawall@lip6.fr>
On Sun, Dec 29, 2013 at 11:47 PM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Set the return variable to an error code as done elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
>
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Not tested.
>
> drivers/scsi/ps3rom.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
> index e6e2a30..04d77ce 100644
> --- a/drivers/scsi/ps3rom.c
> +++ b/drivers/scsi/ps3rom.c
> @@ -387,6 +387,7 @@ static int ps3rom_probe(struct ps3_system_bus_device *_dev)
> if (!host) {
> dev_err(&dev->sbd.core, "%s:%u: scsi_host_alloc failed\n",
> __func__, __LINE__);
> + error = -ENOMEM;
> goto fail_teardown;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 0/25] fix error return code
From: Julia Lawall @ 2013-12-29 22:47 UTC (permalink / raw)
To: linux-input
Cc: cbe-oss-dev, davinci-linux-open-source, linux-pcmcia, rtc-linux,
linux-scsi, linux-pm, linux-rdma, netdev, linux-usb,
kernel-janitors, linux-kernel, platform-driver-x86,
linux-samsung-soc, linux-mtd, dmaengine, linuxppc-dev,
linux-arm-kernel, linux-media
These patches fix cases where the return variable is not set to an error
code in an error case.
^ permalink raw reply
* [PATCH 19/25] fix error return code
From: Julia Lawall @ 2013-12-29 22:47 UTC (permalink / raw)
To: Geoff Levand
Cc: cbe-oss-dev, linux-scsi, kernel-janitors, linux-kernel,
James E.J. Bottomley, linuxppc-dev
In-Reply-To: <1388357260-4843-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Set the return variable to an error code as done elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
Not tested.
drivers/scsi/ps3rom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c
index e6e2a30..04d77ce 100644
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -387,6 +387,7 @@ static int ps3rom_probe(struct ps3_system_bus_device *_dev)
if (!host) {
dev_err(&dev->sbd.core, "%s:%u: scsi_host_alloc failed\n",
__func__, __LINE__);
+ error = -ENOMEM;
goto fail_teardown;
}
^ permalink raw reply related
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: wyang @ 2013-12-30 1:54 UTC (permalink / raw)
To: Gavin Hu, Linuxppc-dev
In-Reply-To: <CABiPGEfmEFovARBy0rwjbDpBnVeRrmvQrxgnH+32z0RLUX3Nkw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
On 12/28/2013 01:41 PM, Gavin Hu wrote:
> Hi
>
> I notice that there is a pair ppc instructions lwarx and stwcx used to
> atomtic operation for instance, atomic_inc/atomic_dec.
>
> In some ppc manuals, they more emphasize its mechanism is that lwarx
> can reseve the target memory address preventing other CORE from
> modifying it.
>
> I assume that there is atomtic operation executing on the CORE0 in a
> multicore system. In this situation, does the CORE0 disable the local
> HW interrupt?
> Can the executing process from the beginning of lwarx and end of stwcx
> be interrupted by HW interruptions/exceptions? Anyway, they are two
> assembly instructions.
It should just like other arch, the processor should response any
interrupt after the execution of a instruction, so the local HW
interrupt is not disabled.
Thanks
Wei
>
> Thanks a lot!
>
> "1: lwarx %0,0,%2 # atomic_inc\n\
> addic %0,%0,1\n"
> " stwcx. %0,0,%2 \n\
>
>
> BR
> Gavin. Hu
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 2655 bytes --]
^ permalink raw reply
* RE: [PATCH] powerpc/mpic_timer: fix the time calculation is not accurate
From: Dongsheng.Wang @ 2013-12-30 2:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1388188783.21454.27.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDI4LCAyMDEzIDg6MDAgQU0NCj4gVG86IFdh
bmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiBDYzogZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsgbGlu
dXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gcG93ZXJw
Yy9tcGljX3RpbWVyOiBmaXggdGhlIHRpbWUgY2FsY3VsYXRpb24gaXMgbm90DQo+IGFjY3VyYXRl
DQo+IA0KPiBPbiBNb24sIDIwMTMtMTItMjMgYXQgMTA6MzMgKzA4MDAsIERvbmdzaGVuZyBXYW5n
IHdyb3RlOg0KPiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nIDxkb25nc2hlbmcud2FuZ0BmcmVlc2Nh
bGUuY29tPg0KPiA+DQo+ID4gV2hlbiB0aGUgdGltZXIgR1RDQ1IgdG9nZ2xlIGJpdCBpcyBpbnZl
cnRlZCwgd2UgY2FsY3VsYXRlZCB0aGUgcmVzdCBvZg0KPiA+IHRoZSB0aW1lIGlzIG5vdCBhY2N1
cmF0ZS4gU28gd2UgbmVlZCB0byBpZ25vcmUgdGhpcyBiaXQuDQo+ID4NCj4gPiBTaWduZWQtb2Zm
LWJ5OiBXYW5nIERvbmdzaGVuZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPg0K
PiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvc3lzZGV2L21waWNfdGltZXIuYw0KPiA+IGIv
YXJjaC9wb3dlcnBjL3N5c2Rldi9tcGljX3RpbWVyLmMNCj4gPiBpbmRleCAyMmQ3ZDU3Li4wZmI3
MGM5IDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9zeXNkZXYvbXBpY190aW1lci5jDQo+
ID4gKysrIGIvYXJjaC9wb3dlcnBjL3N5c2Rldi9tcGljX3RpbWVyLmMNCj4gPiBAQCAtNDEsNiAr
NDEsNyBAQA0KPiA+ICAjZGVmaW5lIE1QSUNfVElNRVJfVENSX1JPVlJfT0ZGU0VUCTI0DQo+ID4N
Cj4gPiAgI2RlZmluZSBUSU1FUl9TVE9QCQkJMHg4MDAwMDAwMA0KPiA+ICsjZGVmaW5lIEdUQ0NS
X1RPRwkJCTB4ODAwMDAwMDANCj4gPiAgI2RlZmluZSBUSU1FUlNfUEVSX0dST1VQCQk0DQo+ID4g
ICNkZWZpbmUgTUFYX1RJQ0tTCQkJKH4wVSA+PiAxKQ0KPiA+ICAjZGVmaW5lIE1BWF9USUNLU19D
QVNDQURFCQkofjBVKQ0KPiA+IEBAIC05Niw4ICs5NywxNSBAQCBzdGF0aWMgdm9pZCBjb252ZXJ0
X3RpY2tzX3RvX3RpbWUoc3RydWN0IHRpbWVyX2dyb3VwX3ByaXYNCj4gKnByaXYsDQo+ID4gIAl0
aW1lLT50dl9zZWMgPSAoX19rZXJuZWxfdGltZV90KWRpdl91NjQodGlja3MsIHByaXYtPnRpbWVy
ZnJlcSk7DQo+ID4gIAl0bXBfc2VjID0gKHU2NCl0aW1lLT50dl9zZWMgKiAodTY0KXByaXYtPnRp
bWVyZnJlcTsNCj4gPg0KPiA+IC0JdGltZS0+dHZfdXNlYyA9IChfX2tlcm5lbF9zdXNlY29uZHNf
dCkNCj4gPiAtCQlkaXZfdTY0KCh0aWNrcyAtIHRtcF9zZWMpICogMTAwMDAwMCwgcHJpdi0+dGlt
ZXJmcmVxKTsNCj4gPiArCXRpbWUtPnR2X3VzZWMgPSAwOw0KPiA+ICsNCj4gPiArCS8qDQo+ID4g
KwkgKiBJbiBzb21lIGNhc2VzIHRtcF9zZWMgbWF5IGJlIGdyZWF0ZXIgdGhhbiB0aWNrcywgYmVj
YXVzZSBpbiB0aGUNCj4gPiArCSAqIHByb2Nlc3Mgb2YgY2FsY3VsYXRpb24gdGlja3MgYW5kIHRt
cF9zZWMgd2lsbCBiZSByb3VuZGVkLg0KPiA+ICsJICovDQo+ID4gKwlpZiAodG1wX3NlYyA8PSB0
aWNrcykNCj4gPiArCQl0aW1lLT50dl91c2VjID0gKF9fa2VybmVsX3N1c2Vjb25kc190KQ0KPiA+
ICsJCQlkaXZfdTY0KCh0aWNrcyAtIHRtcF9zZWMpICogMTAwMDAwMCwgcHJpdi0+dGltZXJmcmVx
KTsNCj4gDQo+IEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIHBhcnQgb2YgdGhlIHBhdGNoIHJlbGF0ZXMg
dG8gdGhlIHBhdGNoIGRlc2NyaXB0aW9uLg0KPiANClRoYW5rcywgSSBtaXNzIHRoaXMgZGVzY3Jp
cHRpb24sIDooLg0KSSBzaG91bGQgc3BsaXQgdGhlIHBhdGNoLg0KDQotRG9uZ3NoZW5nDQoNCj4g
LVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* RE: [PATCH v6 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
From: Dongsheng.Wang @ 2013-12-30 2:37 UTC (permalink / raw)
To: Scott Wood, Bharat.Bhushan@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <1387268222-9703-1-git-send-email-dongsheng.wang@freescale.com>
Hi Scott,
Could you apply these patches?
[v6,1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define, http://patch=
work.ozlabs.org/patch/302045/
[v6,2/4] powerpc/85xx: add hardware automatically enter altivec idle state,=
http://patchwork.ozlabs.org/patch/302046/
[v6,3/4] powerpc/85xx: add hardware automatically enter pw20 state, http://=
patchwork.ozlabs.org/patch/302047/
[v6,4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle, http://pa=
tchwork.ozlabs.org/patch/302048/
-Dongsheng
> -----Original Message-----
> From: Dongsheng Wang [mailto:dongsheng.wang@freescale.com]
> Sent: Tuesday, December 17, 2013 4:17 PM
> To: Wood Scott-B07421; Bhushan Bharat-R65777
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH v6 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 def=
ine
>=20
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>=20
> E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec
> idle patches.
>=20
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> ---
> *v3:
> Add bit definitions for PWRMGTCR0.
>=20
> arch/powerpc/include/asm/reg.h | 2 ++
> arch/powerpc/include/asm/reg_booke.h | 9 +++++++++
> 2 files changed, 11 insertions(+)
>=20
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/re=
g.h
> index 64264bf..d4160ca 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -1053,6 +1053,8 @@
> #define PVR_8560 0x80200000
> #define PVR_VER_E500V1 0x8020
> #define PVR_VER_E500V2 0x8021
> +#define PVR_VER_E6500 0x8040
> +
> /*
> * For the 8xx processors, all of them report the same PVR family for
> * the PowerPC core. The various versions of these processors must be
> diff --git a/arch/powerpc/include/asm/reg_booke.h
> b/arch/powerpc/include/asm/reg_booke.h
> index ed8f836..4a6457e 100644
> --- a/arch/powerpc/include/asm/reg_booke.h
> +++ b/arch/powerpc/include/asm/reg_booke.h
> @@ -170,6 +170,7 @@
> #define SPRN_L2CSR1 0x3FA /* L2 Data Cache Control and Status Register 1
> */
> #define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */
> #define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */
> +#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 */
> #define SPRN_SVR 0x3FF /* System Version Register */
>=20
> /*
> @@ -216,6 +217,14 @@
> #define CCR1_DPC 0x00000100 /* Disable L1 I-Cache/D-Cache parity
> checking */
> #define CCR1_TCS 0x00000080 /* Timer Clock Select */
>=20
> +/* Bit definitions for PWRMGTCR0. */
> +#define PWRMGTCR0_PW20_WAIT (1 << 14) /* PW20 state enable bit */
> +#define PWRMGTCR0_PW20_ENT_SHIFT 8
> +#define PWRMGTCR0_PW20_ENT 0x3F00
> +#define PWRMGTCR0_AV_IDLE_PD_EN (1 << 22) /* Altivec idle enable */
> +#define PWRMGTCR0_AV_IDLE_CNT_SHIFT 16
> +#define PWRMGTCR0_AV_IDLE_CNT 0x3F0000
> +
> /* Bit definitions for the MCSR. */
> #define MCSR_MCS 0x80000000 /* Machine Check Summary */
> #define MCSR_IB 0x40000000 /* Instruction PLB Error */
> --
> 1.8.0
>=20
^ 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