[U-Boot] Regarding MPC8640D second core initialization

[U-Boot] Regarding MPC8640D second core initialization

[Thirumalai]

Hi denx,
        I am using 2009-06 u-boot for MPC8640D based board. i just want to 
know whether the second core of MPC8640D is kicked off automatically or will 
it required by the user to kick. Also if am enabling the CONFIG_MP macro and 
CONFIG_NUM_CPUS as 2, then the reset command of the target is not 
working(means board is getting hanged). I have mentioned the value of 
CONFIG_SYS_SCRATCH_VA as 0xf5000000.

Kindly suggest me what might be the error.

Thank you,
T. 

[U-Boot] Regarding MPC8640D second core initialization

[Wolfgang Denk]

Dear "Thirumalai",

In message <37EF3A462AFE4B5090E87F6B7F3F330F@itd210> you wrote:
> Hi denx,
>         I am using 2009-06 u-boot for MPC8640D based board. i just want to 
> know whether the second core of MPC8640D is kicked off automatically or will 
> it required by the user to kick. Also if am enabling the CONFIG_MP macro and 
> CONFIG_NUM_CPUS as 2, then the reset command of the target is not 
> working(means board is getting hanged). I have mentioned the value of 
> CONFIG_SYS_SCRATCH_VA as 0xf5000000.
> 
> Kindly suggest me what might be the error.

Which "MPC8640D based board" is this exactly?

At the moment we have 3 MPC86xx boards in mainline, and the
MAINTAINERS file will tell you who is responsible for these.

If you have a custom board with an out-of-tree port you will have to
ask those who provided the port to you.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Alles Gescheite ist schon gedacht worden, man mu? nur versuchen,
es noch einmal zu denken.          -- Goethe, Maximen und Reflexionen

[U-Boot] Regarding MPC8640D second core initialization

[Thirumalai]

Thank you denx.

 Hi Jon,
        I am using 2009-06 u-boot for MPC8640D based custom board. i just 
want to  know whether the second core of MPC8640D is kicked off 
automatically or will  it required by the user to kick using cpu command 
like mpc85xx/mp.c. Also if am enabling the CONFIG_MP macro and 
CONFIG_NUM_CPUS as 2, then the reset command of the target is not 
working(means board is getting hanged). I have mentioned the value of 
CONFIG_SYS_SCRATCH_VA as 0xf5000000.

Thank you
T.

[U-Boot] Regarding MPC8640D second core initialization

[Becky Bruce]

On Dec 2, 2009, at 3:55 AM, Thirumalai wrote:

> Thank you denx.
>
> Hi Jon,

The email address you used for Jon is invalid (we need to update the  
maintainers file - Jon should weigh in here).

>
>      I am using 2009-06 u-boot for MPC8640D based custom board. i just
> want to  know whether the second core of MPC8640D is kicked off
> automatically or will  it required by the user to kick using cpu  
> command

If you have U-boot configured as you say below, and an SMP linux, then  
the second CPU will automatically come up.  You don't need to do  
anything special.

> like mpc85xx/mp.c. Also if am enabling the CONFIG_MP macro and
> CONFIG_NUM_CPUS as 2, then the reset command of the target is not
> working(means board is getting hanged). I have mentioned the value of
> CONFIG_SYS_SCRATCH_VA as 0xf5000000.

As far as your reset problem, I'm running a MPC8641D board using the  
latest u-boot, and I am able to reset it just fine when booted SMP.   
You're going to have to provide more information or look into this  
yourself.

I can't tell you if your SCRATCH_VA is valid without knowing the  
entire memory map of your system.......

Cheers,
Becky

[U-Boot] [PATCH] Jon Loeliger is not maintaining any Freescale board.

[Jon Loeliger]

From: Jon Loeliger <jdl@jdl.com>

Signed-off-by: Jon Loeliger <jdl@jdl.com>
---

Becky schrieb:
> On Dec 2, 2009, at 3:55 AM, Thirumalai wrote:
> 
> > Thank you denx.
> >
> > Hi Jon,
> 
> The email address you used for Jon is invalid (we need to update the  
> maintainers file - Jon should weigh in here).


 MAINTAINERS |    9 ---------
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index d70a9d2..19a866b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -277,15 +277,6 @@ Nye Liu <nyet@zumanetworks.com>
 
 	ZUMA		MPC7xx_74xx
 
-Jon Loeliger <jdl@freescale.com>
-
-	MPC8540ADS	MPC8540
-	MPC8560ADS	MPC8560
-	MPC8541CDS	MPC8541
-	MPC8555CDS	MPC8555
-
-	MPC8641HPCN	MPC8641D
-
 Ron Madrid <info@sheldoninst.com>
 
 	SIMPC8313	MPC8313
-- 
1.6.2.rc0.90.g0753

[U-Boot] [PATCH] Jon Loeliger is not maintaining any Freescale board.

[Wolfgang Denk]

Dear Jon,

In message <E1NFxJj-00088D-Tv@jdl.com> you wrote:
> 
>  MAINTAINERS |    9 ---------
>  1 files changed, 0 insertions(+), 9 deletions(-)

Thanks a lot, but I will ignore this patch as Kumar "volunteered" to
inherit this stuff.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...one of the main causes of the fall of the Roman Empire was  that,
lacking  zero,  they had no way to indicate successful termination of
their C programs."                                     - Robert Firth

[U-Boot] Regarding MPC8640D second core initialization

[Thirumalai]

>
> On Dec 2, 2009, at 3:55 AM, Thirumalai wrote:
>
>> Thank you denx.
>>
>> Hi Jon,
>
> The email address you used for Jon is invalid (we need to update the
> maintainers file - Jon should weigh in here).
>
>>
>>      I am using 2009-06 u-boot for MPC8640D based custom board. i just
>> want to  know whether the second core of MPC8640D is kicked off
>> automatically or will  it required by the user to kick using cpu  command
>
> If you have U-boot configured as you say below, and an SMP linux, then
> the second CPU will automatically come up.  You don't need to do  anything
> special.
>
>> like mpc85xx/mp.c. Also if am enabling the CONFIG_MP macro and
>> CONFIG_NUM_CPUS as 2, then the reset command of the target is not
>> working(means board is getting hanged). I have mentioned the value of
>> CONFIG_SYS_SCRATCH_VA as 0xf5000000.
>
> As far as your reset problem, I'm running a MPC8641D board using the
> latest u-boot, and I am able to reset it just fine when booted SMP.
> You're going to have to provide more information or look into this
> yourself.
>
> I can't tell you if your SCRATCH_VA is valid without knowing the  entire
> memory map of your system.......

Thank you. I will just check and tell you.

>
> Cheers,
> Becky
>

Hi Becky,
          Thank you for your reply. But when i boot smp-linux on this
configuration i got into kernel panic. The log is attached with this mail. I
am using linux-2.6.30 downloaded from kernel.org and my dts entry for cpu is
like this.

 cpus {
                #address-cells = <1>;
                #size-cells = <0>;

                PowerPC,8641 at 0 {
                        device_type = "cpu";
                        reg = <0>;
                        d-cache-line-size = <32>;
                        i-cache-line-size = <32>;
                        d-cache-size = <32768>;         // L1
                        i-cache-size = <32768>;         // L1
                        timebase-frequency = <0>;       // From uboot
                        bus-frequency = <0>;            // From uboot
                        clock-frequency = <0>;          // From uboot
                };
                PowerPC,8641 at 1 {
                        device_type = "cpu";
                        reg = <1>;
                        d-cache-line-size = <32>;
                        i-cache-line-size = <32>;
                        d-cache-size = <32768>;
                        i-cache-size = <32768>;
                        timebase-frequency = <0>;       // From uboot
                        bus-frequency = <0>;            // From uboot
                        clock-frequency = <0>;          // From uboot
                };
        };

--------------
Kernel Log
--------------
## Current stack ends at 0x3fa91a08
## Booting kernel from Legacy Image at 00400000 ...
   Image Name:   Linux-2.6.30-dpvpx0689
   Created:      2009-12-01   4:45:09 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    2307361 Bytes =  2.2 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 04000000
   Booting using the fdt blob at 0x4000000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 007fa000, end 007ff150 ... OK
## Transferring control to Linux (at address 00000000) ...
   Booting using OF flat tree...
Using DPVPX0689 machine description
Total memory = 1024MB; using 2048kB for hash table (at afe00000)
Linux version 2.6.30-dpvpx0689 (root at localhost.localdomain) (gcc version
4.0.0 (DENX ELDK 4.0 4.0.0)) #70 SMP Tue Dec 1 10:14:07 IST 2009
Found legacy serial port 0 for /soc at f6000000/serial at 4500
  mem=f6004500, taddr=f6004500, irq=0, clk=400000000, speed=0
Found legacy serial port 1 for /soc at f6000000/serial at 4600
  mem=f6004600, taddr=f6004600, irq=0, clk=400000000, speed=0
CPU maps initialized for 1 thread per core
 (thread shift is 0)
console [udbg0] enabled
setup_arch: bootmem
dpvpx0689_setup_arch()
Found FSL PCI host bridge at 0x00000000f6008000. Firmware bus number: 0->15
PCI host bridge /pcie at f6008000  ranges:
 MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
  IO 0x00000000f8000000..0x00000000fbffffff -> 0x0000000000000000
Single Board Computers from Data Patterns
Ported & Developed By COTS DIVISION
arch: exit
Top of RAM: 0x40000000, Total RAM: 0x40000000
Memory hole size: 0MB
Zone PFN ranges:
  DMA      0x00000000 -> 0x00030000
  Normal   0x00030000 -> 0x00030000
  HighMem  0x00030000 -> 0x00040000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00040000
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat a047d1c0, node_mem_map a07fd000
  DMA zone: 1536 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 195072 pages, LIFO batch:31
  HighMem zone: 512 pages used for memmap
  HighMem zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/nfs rw nfsroot=10.5.18.3:/ppc/netfs/fc5fs/
ip=10.5.18.230:10.5.18.3:10.5.18.3:255.0.0.0:DPVPX0689:eth0:off
console=ttyS0,115200
NR_IRQS:512
mpic: Setting up MPIC " MPIC     " version 1.2 at f6040000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
PID hash table entries: 4096 (order: 12, 16384 bytes)
time_init: decrementer frequency = 100.000000 MHz
time_init: processor frequency   = 800.000000 MHz
clocksource: timebase mult[2800000] shift[22] registered
clockevent: decrementer mult[1999] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 262140k
Memory: 1031504k/1048576k available (4444k kernel code, 16252k reserved,
160k data, 169k bss, 200k init)
Kernel virtual memory layout:
  * 0xfffe0000..0xfffff000  : fixmap
  * 0xff800000..0xffc00000  : highmem PTEs
  * 0xfe7ed000..0xff800000  : early ioremap
  * 0xd1000000..0xfe7ed000  : vmalloc & ioremap
Calibrating delay loop... 199.68 BogoMIPS (lpj=99840)
Mount-cache hash table entries: 512
mpic: requesting IPIs ...
Processor 1 found.
clockevent: decrementer mult[1999] shift[16] cpu[1]
Brought up 2 CPUs
Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xa0023e10
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 DPVPX0689
Modules linked in:
NIP: a0023e10 LR: a0023dd0 CTR: 00000000
REGS: cf841e90 TRAP: 0300   Not tainted  (2.6.30-dpvpx0689)
MSR: 00009032 <EE,ME,IR,DR>  CR: 24004028  XER: 20000000
DAR: 00000004, DSISR: 40000000
TASK = cf83f930[1] 'swapper' THREAD: cf840000 CPU: 0
GPR00: 00000000 cf841f40 cf83f930 00000000 00000000 00000000 cf841f50
00000000
GPR08: 00000000 00000000 00000002 a10018f4 22004082 ffffffff 3fee6c00
3ff94000
GPR16: ffffffbf ffbf7bff 00000000 00000000 00000000 cf83a800 a10018e8
a0491224
GPR24: a0490000 a04558f8 00000000 cf801f20 a1006070 a10018e8 a10018f8
00000000
NIP [a0023e10] __build_sched_domains+0x354/0x464
LR [a0023dd0] __build_sched_domains+0x314/0x464
Call Trace:
[cf841f40] [a0023b98] __build_sched_domains+0xdc/0x464 (unreliable)
[cf841f90] [a04326ec] sched_init_smp+0x88/0x1e8
[cf841fc0] [a0425a40] kernel_init+0x148/0x1f0
[cf841ff0] [a00131f8] kernel_thread+0x4c/0x68
Instruction dump:
813e0008 2f9c0000 90090004 419e00d4 801e0034 70090100 40820010 801c0034
70090280 408200bc 83fc0008 83be0008 <807f0004> 801d0004 7c630214 907d0004
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..

[U-Boot] Regarding MPC8640D second core initialization

[Becky Bruce]

On Dec 2, 2009, at 10:36 PM, Thirumalai wrote:
>
>         Thank you for your reply. But when i boot smp-linux on this
> configuration i got into kernel panic. The log is attached with this  
> mail. I
> am using linux-2.6.30 downloaded from kernel.org and my dts entry  
> for cpu is
> like this.


<snip>

>
> Calibrating delay loop... 199.68 BogoMIPS (lpj=99840)
> Mount-cache hash table entries: 512
> mpic: requesting IPIs ...
> Processor 1 found.
> clockevent: decrementer mult[1999] shift[16] cpu[1]
> Brought up 2 CPUs
> Unable to handle kernel paging request for data at address 0x00000004
> Faulting instruction address: 0xa0023e10
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=2 DPVPX0689
> Modules linked in:
> NIP: a0023e10 LR: a0023dd0 CTR: 00000000
> REGS: cf841e90 TRAP: 0300   Not tainted  (2.6.30-dpvpx0689)
> MSR: 00009032 <EE,ME,IR,DR>  CR: 24004028  XER: 20000000
> DAR: 00000004, DSISR: 40000000
> TASK = cf83f930[1] 'swapper' THREAD: cf840000 CPU: 0
> GPR00: 00000000 cf841f40 cf83f930 00000000 00000000 00000000 cf841f50
> 00000000
> GPR08: 00000000 00000000 00000002 a10018f4 22004082 ffffffff 3fee6c00
> 3ff94000
> GPR16: ffffffbf ffbf7bff 00000000 00000000 00000000 cf83a800 a10018e8
> a0491224
> GPR24: a0490000 a04558f8 00000000 cf801f20 a1006070 a10018e8 a10018f8
> 00000000
> NIP [a0023e10] __build_sched_domains+0x354/0x464
> LR [a0023dd0] __build_sched_domains+0x314/0x464
> Call Trace:
> [cf841f40] [a0023b98] __build_sched_domains+0xdc/0x464 (unreliable)
> [cf841f90] [a04326ec] sched_init_smp+0x88/0x1e8
> [cf841fc0] [a0425a40] kernel_init+0x148/0x1f0
> [cf841ff0] [a00131f8] kernel_thread+0x4c/0x68
> Instruction dump:
> 813e0008 2f9c0000 90090004 419e00d4 801e0034 70090100 40820010  
> 801c0034
> 70090280 408200bc 83fc0008 83be0008 <807f0004> 801d0004 7c630214  
> 907d0004

You took this panic because you tried to access 0x00000004, which is  
probably not correct.  I would also not generally expect to be seeing  
all these 0xaxxxxxxx addresses in your panic.  Can you explain exactly  
what you've done to this kernel, and send a copy of the entire .dts  
and the .config?

FYI, 2.6.30 boots SMP just fine on my 8641HPCN board.

Cheers,
Becky

> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill init!
> Rebooting in 180 seconds..