* MPC8641 based custom board kernel Bug
@ 2013-12-26 5:09 Ashish Khetan
2013-12-26 9:07 ` wyang
0 siblings, 1 reply; 12+ messages in thread
From: Ashish Khetan @ 2013-12-26 5:09 UTC (permalink / raw)
To: kernelnewbies, linuxppc-dev; +Cc: scottwood
[-- Attachment #1: Type: text/plain, Size: 3020 bytes --]
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!
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
[-- Attachment #2: Type: text/html, Size: 3321 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board kernel Bug
2013-12-26 5:09 MPC8641 based custom board kernel Bug Ashish Khetan
@ 2013-12-26 9:07 ` wyang
2013-12-26 11:48 ` Ashish Khetan
0 siblings, 1 reply; 12+ messages in thread
From: wyang @ 2013-12-26 9:07 UTC (permalink / raw)
To: Ashish Khetan, kernelnewbies, linuxppc-dev; +Cc: scottwood
[-- Attachment #1: Type: text/plain, Size: 3504 bytes --]
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 list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 5970 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board kernel Bug
2013-12-26 9:07 ` wyang
@ 2013-12-26 11:48 ` Ashish Khetan
2013-12-26 22:51 ` Sri Ram Vemulpali
0 siblings, 1 reply; 12+ messages in thread
From: Ashish Khetan @ 2013-12-26 11:48 UTC (permalink / raw)
To: wyang; +Cc: scottwood, linuxppc-dev, kernelnewbies
[-- 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 [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board kernel Bug
2013-12-26 11:48 ` Ashish Khetan
@ 2013-12-26 22:51 ` Sri Ram Vemulpali
2013-12-27 5:20 ` Ashish Khetan
0 siblings, 1 reply; 12+ messages in thread
From: Sri Ram Vemulpali @ 2013-12-26 22:51 UTC (permalink / raw)
To: Ashish Khetan; +Cc: scottwood, linuxppc-dev, wyang, kernelnewbies
[-- 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 [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board kernel Bug
2013-12-26 22:51 ` Sri Ram Vemulpali
@ 2013-12-27 5:20 ` Ashish Khetan
2013-12-27 6:40 ` Sri Ram Vemulpali
2014-03-27 10:34 ` MPC8641 based custom board Kernel stuck at 1000Mhz core clock Ashish
0 siblings, 2 replies; 12+ messages in thread
From: Ashish Khetan @ 2013-12-27 5:20 UTC (permalink / raw)
To: Sri Ram Vemulpali; +Cc: scottwood, linuxppc-dev, wyang, kernelnewbies
[-- 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 [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board kernel Bug
2013-12-27 5:20 ` Ashish Khetan
@ 2013-12-27 6:40 ` Sri Ram Vemulpali
2014-03-27 10:34 ` MPC8641 based custom board Kernel stuck at 1000Mhz core clock Ashish
1 sibling, 0 replies; 12+ messages in thread
From: Sri Ram Vemulpali @ 2013-12-27 6:40 UTC (permalink / raw)
To: Ashish Khetan; +Cc: scottwood, linuxppc-dev, wyang, kernelnewbies
[-- 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 [flat|nested] 12+ messages in thread
* MPC8641 based custom board Kernel stuck at 1000Mhz core clock
2013-12-27 5:20 ` Ashish Khetan
2013-12-27 6:40 ` Sri Ram Vemulpali
@ 2014-03-27 10:34 ` Ashish
2014-03-27 16:31 ` Valdis.Kletnieks
1 sibling, 1 reply; 12+ messages in thread
From: Ashish @ 2014-03-27 10:34 UTC (permalink / raw)
To: kernelnewbies; +Cc: scottwood, linuxppc-dev
Hi,
I am using MPC8641-HPCN based custom board and able to boot linux at
MPX clock 400Mhz and core clock 800mhz. When I am increasing core
frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck. Does
any body have faced this kind of issue ? Or any idea how to resolve this?
Thanks & Regards
A$hi$h
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
2014-03-27 10:34 ` MPC8641 based custom board Kernel stuck at 1000Mhz core clock Ashish
@ 2014-03-27 16:31 ` Valdis.Kletnieks
2014-04-03 3:25 ` sanjeev sharma
0 siblings, 1 reply; 12+ messages in thread
From: Valdis.Kletnieks @ 2014-03-27 16:31 UTC (permalink / raw)
To: Ashish; +Cc: scottwood, linuxppc-dev, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 556 bytes --]
On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
> Hi,
>
> I am using MPC8641-HPCN based custom board and able to boot linux at
> MPX clock 400Mhz and core clock 800mhz. When I am increasing core
> frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
Step 0: Prove to us that your core actually runs reliable and stably at 1Ghz.
Step 1: Figure out *where* it gets stuck. If you have earlyprintk working on
your board, adding 'initcall_debug ignore_loglevel' to the kernel cmdline often
helps track down where a kernel hangs during boot.
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
2014-03-27 16:31 ` Valdis.Kletnieks
@ 2014-04-03 3:25 ` sanjeev sharma
2014-04-04 7:42 ` Ashish
0 siblings, 1 reply; 12+ messages in thread
From: sanjeev sharma @ 2014-04-03 3:25 UTC (permalink / raw)
To: Valdis Kletnieks; +Cc: scottwood, Ashish, linuxppc-dev, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
Are you able to capture kernel logs ?
Regards
Sanjeev Sharma
On Thu, Mar 27, 2014 at 10:01 PM, <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
> > Hi,
> >
> > I am using MPC8641-HPCN based custom board and able to boot linux at
> > MPX clock 400Mhz and core clock 800mhz. When I am increasing core
> > frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
>
> Step 0: Prove to us that your core actually runs reliable and stably at
> 1Ghz.
>
> Step 1: Figure out *where* it gets stuck. If you have earlyprintk working
> on
> your board, adding 'initcall_debug ignore_loglevel' to the kernel cmdline
> often
> helps track down where a kernel hangs during boot.
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
[-- Attachment #2: Type: text/html, Size: 1466 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
2014-04-03 3:25 ` sanjeev sharma
@ 2014-04-04 7:42 ` Ashish
2014-05-02 3:52 ` sanjeev sharma
0 siblings, 1 reply; 12+ messages in thread
From: Ashish @ 2014-04-04 7:42 UTC (permalink / raw)
To: sanjeev sharma; +Cc: scottwood, linuxppc-dev, Valdis Kletnieks, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 5874 bytes --]
On Thursday 03 April 2014 08:55 AM, sanjeev sharma wrote:
> Are you able to capture kernel logs ?
>
> Regards
> Sanjeev Sharma
>
>
> On Thu, Mar 27, 2014 at 10:01 PM, <Valdis.Kletnieks@vt.edu
> <mailto:Valdis.Kletnieks@vt.edu>> wrote:
>
> On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
> > Hi,
> >
> > I am using MPC8641-HPCN based custom board and able to boot
> linux at
> > MPX clock 400Mhz and core clock 800mhz. When I am increasing core
> > frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
>
> Step 0: Prove to us that your core actually runs reliable and
> stably at 1Ghz.
>
> Step 1: Figure out *where* it gets stuck. If you have earlyprintk
> working on
> your board, adding 'initcall_debug ignore_loglevel' to the kernel
> cmdline often
> helps track down where a kernel hangs during boot.
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> <mailto:Kernelnewbies@kernelnewbies.org>
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
Hi,
Does kernel logs means debugging information that kernel prints while
booting using printk or it is something else?
Here is kernel boot logs that kernel printed while booting...
U-Boot 2013.04 (Jan 27 2014 - 11:21:21)
Unicore software on multiprocessor system!!
To enable mutlticore build define CONFIG_MP
CPU: 8641, Version: 2.1, (0x80900021)
Core: E600 Core 0, Version: 2.2, (0x80040202)
Clock Configuration:
CPU:1000 MHz, MPX:400 MHz
DDR:200 MHz (400 MT/s data rate), LBC:25 MHz
L1: D-cache 32 KB enabled
I-cache 32 KB enabled
L2: 512 KB enabled
Board: MPC8641-HPCN
I2C: ready
DRAM: 512 MiB
SDRAM test phase 1:
SDRAM test phase 2:
SDRAM test passed.
Flash: 16 MiB
EEPROM: NXID v1
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 [PRIME]
Hit any key to stop autoboot:
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uRamdisk'.
Load address: 0x600000
Loading:
*\b#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
13.1 MiB/s
done
Bytes transferred = 22680188 (15a127c hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uImage'.
Load address: 0x16000000
Loading:
*\b#################################################################
#################################################################
#######################################
14 MiB/s
done
Bytes transferred = 2476304 (25c910 hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'mpc8641_hpcn.dtb'.
Load address: 0x14000000
Loading: *\b#
2.6 MiB/s
done
Bytes transferred = 5540 (15a4 hex)
## Booting kernel from Legacy Image at 16000000 ...
Image Name: Linux-3.13.6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2476240 Bytes = 2.4 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00600000 ...
Image Name: rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 22680124 Bytes = 21.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 14000000
Booting using the fdt blob at 0x14000000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 1e923000, end 1fec423c ... OK
Loading Device Tree to 007fb000, end 007ff5a3 ... OK /_*(some times
it stucking here) *_/
Using MPC86xx HPCN machine description
Total memory = 512MB; using 1024kB for hash table (at cff00000)
Linux version 3.13.6 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC)
) #8 Sat Mar 29 10:31:58 IST 2014
Found initrd at 0xde923000:0xdfec423c
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] /_*(some times here) *_/
[-- Attachment #2: Type: text/html, Size: 9651 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
2014-04-04 7:42 ` Ashish
@ 2014-05-02 3:52 ` sanjeev sharma
0 siblings, 0 replies; 12+ messages in thread
From: sanjeev sharma @ 2014-05-02 3:52 UTC (permalink / raw)
To: Ashish; +Cc: scottwood, linuxppc-dev, Valdis Kletnieks, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 6284 bytes --]
Hello Ashish,
is this issue resolved and is this always happening when you are changing
core to 1Ghz because i am confused here with sometime Keyword.
Regards
Sanjeev Sharma
On Fri, Apr 4, 2014 at 1:12 PM, Ashish <curieux.khetan@gmail.com> wrote:
> On Thursday 03 April 2014 08:55 AM, sanjeev sharma wrote:
>
> Are you able to capture kernel logs ?
>
> Regards
> Sanjeev Sharma
>
>
> On Thu, Mar 27, 2014 at 10:01 PM, <Valdis.Kletnieks@vt.edu> wrote:
>
>> On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
>> > Hi,
>> >
>> > I am using MPC8641-HPCN based custom board and able to boot linux at
>> > MPX clock 400Mhz and core clock 800mhz. When I am increasing core
>> > frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
>>
>> Step 0: Prove to us that your core actually runs reliable and stably at
>> 1Ghz.
>>
>> Step 1: Figure out *where* it gets stuck. If you have earlyprintk
>> working on
>> your board, adding 'initcall_debug ignore_loglevel' to the kernel cmdline
>> often
>> helps track down where a kernel hangs during boot.
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
> Hi,
> Does kernel logs means debugging information that kernel prints while
> booting using printk or it is something else?
> Here is kernel boot logs that kernel printed while booting...
>
> U-Boot 2013.04 (Jan 27 2014 - 11:21:21)
>
> Unicore software on multiprocessor system!!
> To enable mutlticore build define CONFIG_MP
> CPU: 8641, Version: 2.1, (0x80900021)
> Core: E600 Core 0, Version: 2.2, (0x80040202)
> Clock Configuration:
> CPU:1000 MHz, MPX:400 MHz
> DDR:200 MHz (400 MT/s data rate), LBC:25 MHz
> L1: D-cache 32 KB enabled
> I-cache 32 KB enabled
> L2: 512 KB enabled
> Board: MPC8641-HPCN
> I2C: ready
> DRAM: 512 MiB
> SDRAM test phase 1:
> SDRAM test phase 2:
> SDRAM test passed.
> Flash: 16 MiB
> EEPROM: NXID v1
> In: serial
> Out: serial
> Err: serial
> Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 [PRIME]
> Hit any key to stop autoboot:
> Speed: 1000, full duplex
> Using eTSEC4 device
> TFTP from server 192.168.10.1; our IP address is 192.168.10.2
> Filename 'uRamdisk'.
> Load address: 0x600000
> Loading: *
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> #################################################################
> ##################################################
> 13.1 MiB/s
> done
> Bytes transferred = 22680188 (15a127c hex)
> Speed: 1000, full duplex
> Using eTSEC4 device
> TFTP from server 192.168.10.1; our IP address is 192.168.10.2
> Filename 'uImage'.
> Load address: 0x16000000
> Loading: *
> #################################################################
> #################################################################
> #######################################
> 14 MiB/s
> done
> Bytes transferred = 2476304 (25c910 hex)
> Speed: 1000, full duplex
> Using eTSEC4 device
> TFTP from server 192.168.10.1; our IP address is 192.168.10.2
> Filename 'mpc8641_hpcn.dtb'.
> Load address: 0x14000000
> Loading: * #
> 2.6 MiB/s
> done
> Bytes transferred = 5540 (15a4 hex)
> ## Booting kernel from Legacy Image at 16000000 ...
> Image Name: Linux-3.13.6
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2476240 Bytes = 2.4 MiB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 00600000 ...
> Image Name: rootfs
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 22680124 Bytes = 21.6 MiB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 14000000
> Booting using the fdt blob at 0x14000000
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 1e923000, end 1fec423c ... OK
> Loading Device Tree to 007fb000, end 007ff5a3 ... OK *(some times
> it stucking here) *
> Using MPC86xx HPCN machine description
> Total memory = 512MB; using 1024kB for hash table (at cff00000)
> Linux version 3.13.6 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC)
> ) #8 Sat Mar 29 10:31:58 IST 2014
> Found initrd at 0xde923000:0xdfec423c
> 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] *(some times here) *
>
>
>
[-- Attachment #2: Type: text/html, Size: 9351 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
@ 2014-05-03 16:40 curieux.khetan
0 siblings, 0 replies; 12+ messages in thread
From: curieux.khetan @ 2014-05-03 16:40 UTC (permalink / raw)
To: sanjeev sharma
Cc: scottwood@freescale.com, linuxppc-dev@lists.ozlabs.org,
Valdis Kletnieks, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 6685 bytes --]
hi thanks for your reply. the problem is still there. At 800MHZ core its working fine but for 1Ghz its still happening.
Any suggestion or check point I can monitor.
From: sanjeev sharma
Sent: 02 May 2014 09:22
To: Ashish
CC: Valdis Kletnieks; scottwood@freescale.com; linuxppc-dev@lists.ozlabs.org; kernelnewbies
Subject: Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
Hello Ashish,
is this issue resolved and is this always happening when you are changing core to 1Ghz because i am confused here with sometime Keyword.
Regards
Sanjeev Sharma
On Fri, Apr 4, 2014 at 1:12 PM, Ashish <curieux.khetan@gmail.com> wrote:
On Thursday 03 April 2014 08:55 AM, sanjeev sharma wrote:
Are you able to capture kernel logs ?
Regards
Sanjeev Sharma
On Thu, Mar 27, 2014 at 10:01 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
> Hi,
>
> I am using MPC8641-HPCN based custom board and able to boot linux at
> MPX clock 400Mhz and core clock 800mhz. When I am increasing core
> frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
Step 0: Prove to us that your core actually runs reliable and stably at 1Ghz.
Step 1: Figure out *where* it gets stuck. If you have earlyprintk working on
your board, adding 'initcall_debug ignore_loglevel' to the kernel cmdline often
helps track down where a kernel hangs during boot.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi,
Does kernel logs means debugging information that kernel prints while booting using printk or it is something else?
Here is kernel boot logs that kernel printed while booting...
U-Boot 2013.04 (Jan 27 2014 - 11:21:21)
Unicore software on multiprocessor system!!
To enable mutlticore build define CONFIG_MP
CPU: 8641, Version: 2.1, (0x80900021)
Core: E600 Core 0, Version: 2.2, (0x80040202)
Clock Configuration:
CPU:1000 MHz, MPX:400 MHz
DDR:200 MHz (400 MT/s data rate), LBC:25 MHz
L1: D-cache 32 KB enabled
I-cache 32 KB enabled
L2: 512 KB enabled
Board: MPC8641-HPCN
I2C: ready
DRAM: 512 MiB
SDRAM test phase 1:
SDRAM test phase 2:
SDRAM test passed.
Flash: 16 MiB
EEPROM: NXID v1
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 [PRIME]
Hit any key to stop autoboot:
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uRamdisk'.
Load address: 0x600000
Loading: * #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
13.1 MiB/s
done
Bytes transferred = 22680188 (15a127c hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uImage'.
Load address: 0x16000000
Loading: * #################################################################
#################################################################
#######################################
14 MiB/s
done
Bytes transferred = 2476304 (25c910 hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'mpc8641_hpcn.dtb'.
Load address: 0x14000000
Loading: * #
2.6 MiB/s
done
Bytes transferred = 5540 (15a4 hex)
## Booting kernel from Legacy Image at 16000000 ...
Image Name: Linux-3.13.6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2476240 Bytes = 2.4 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00600000 ...
Image Name: rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 22680124 Bytes = 21.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 14000000
Booting using the fdt blob at 0x14000000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 1e923000, end 1fec423c ... OK
Loading Device Tree to 007fb000, end 007ff5a3 ... OK (some times it stucking here)
Using MPC86xx HPCN machine description
Total memory = 512MB; using 1024kB for hash table (at cff00000)
Linux version 3.13.6 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC) ) #8 Sat Mar 29 10:31:58 IST 2014
Found initrd at 0xde923000:0xdfec423c
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] (some times here)
[-- Attachment #2: Type: text/html, Size: 10983 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-05-03 16:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-26 5:09 MPC8641 based custom board kernel Bug Ashish Khetan
2013-12-26 9:07 ` wyang
2013-12-26 11:48 ` Ashish Khetan
2013-12-26 22:51 ` Sri Ram Vemulpali
2013-12-27 5:20 ` Ashish Khetan
2013-12-27 6:40 ` Sri Ram Vemulpali
2014-03-27 10:34 ` MPC8641 based custom board Kernel stuck at 1000Mhz core clock Ashish
2014-03-27 16:31 ` Valdis.Kletnieks
2014-04-03 3:25 ` sanjeev sharma
2014-04-04 7:42 ` Ashish
2014-05-02 3:52 ` sanjeev sharma
-- strict thread matches above, loose matches on Subject: below --
2014-05-03 16:40 curieux.khetan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).