Regarding the PPC board bringup with Linux 2.6 kernel

Hi All,
  
I am working on bringing up a PowerPC based board
with Linux 2.6 kernel (Board supoort package).
However, I am facing some problem with respect to
debugging.
 
When I boot the board with the Linux kernel (BSP),
the board hangs after printing the following
information.
  

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Network Loading from: /dev/enet0 

Client IP Address      = 192.168.4.38 
Server IP Address      = 192.168.4.101 
Gateway IP Address     = 192.168.4.253 
Subnet IP Address Mask = 255.255.255.0 
Boot File Name         = developer.kdi 
Load Address           = 04000000 
Buffer Size = 2000000 

Network Boot File Load Start - Press <ESC> to
Bypass, <SPC> to Continue 


Bytes Received =&6141952, Bytes Loaded =&6141952 
Bytes/Second   =&511829, Elapsed Time =12 Second(s) 

Boot Device       =/dev/enet0 
Boot File         =developer.kdi 
Load Address      =04000000 
Load Size         =005DB800 
Execution Address =04000020 
Execution Offset  =00000020 

Passing control to the loaded file/image. 
loaded at:     00800000 00DD8800 
zimage at:     008058E0 009933BB 
initrd at:     00998000 00DD8800 
avail ram:     00400000 00800000 

Linux/PPC load: console=ttyS0,9600 console=tty0
root=/dev/sda2  console=ttyS0,9600 root=/dev/ram rw 
Uncompressing Linux...done. 
Now booting the kernel 
 
 

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

. 

I am going through the source code to figure out the
problem, but unable to find out what is going wrong
here.
 
Does anybody have any idea about the problem? Also,
is it possible to print some debug messages at this
point of booting? {Note that, in the early stage of
booting process the serial is initialized and all
the above mentioned messages (like Uncomressing
Linux, Now booting the kernel etc) are printed. And
immediately after printing the "now booting the
kernel message,the serial is closed. This code is in
uncompress_kernel() function in
arch/ppc/boot/simple/misc.c file).

Can somebody help me with the above problem?

Thank you,
vinay hegde.


	

	
		
__________________________________________________________ 
Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com

I am working through bringing up Linux 2.6.13.4 on a Xilinx V4 based ppc405.
with memory from 0x0 through 0x7fffffff



Right now I get:

 >Starting MonitorX.elf: V3.3.2.0.
 >
 >loaded at:     00400000 0047F13C
 >board data at: 0047D128 0047D13C
 >relocated to:  00405300 00405314
 >zimage at:     00405A95 0047CE71
 >avail ram:     00480000 08000000
 >
 >Linux/PPC load: console=ttyS0,9600 console=tty0 init=/linuxrc 
looptype=squashfs cdroot splash=silentttttt
 >Uncompressing Linux......done.
 >Now booting the kernel

I have been able to trace execution into head_4xx.S  to immediately 
before turn_on_mmu:
But immediately after this I lose the ability to trace.

I have been tracing things with a status port at 0x70000000 I can write 
to and read from the host side with code like

    lis   r14,0x7000      /* debugging port */
    li   r15,0x2305      /* value to output */
    stw   r15,4(r14)  
    eieio
 
after turn_on_mmu executes this does not seem to work.
looking at other code it appeared that I needed to add
tophy(r14,r14) prior to the stw
but that does not seem to help.

What do I need to do to be able to continue to use my debug port ?

Your problem seems to be due to the CPU_213 errata:

ftp://ftp.xilinx.com/pub/documentation/misc/ppc405f6v5_2_0.pdf, page 22

Best regards,
Andrei


David H. Lynch Jr wrote:

I am working through bringing up Linux 2.6.13.4 on a Xilinx V4 based 
ppc405.
with memory from 0x0 through 0x7fffffff



Right now I get:

 >Starting MonitorX.elf: V3.3.2.0.
 >
 >loaded at:     00400000 0047F13C
 >board data at: 0047D128 0047D13C
 >relocated to:  00405300 00405314
 >zimage at:     00405A95 0047CE71
 >avail ram:     00480000 08000000
 >
 >Linux/PPC load: console=ttyS0,9600 console=tty0 init=/linuxrc 
looptype=squashfs cdroot splash=silentttttt
 >Uncompressing Linux......done.
 >Now booting the kernel

I have been able to trace execution into head_4xx.S  to immediately 
before turn_on_mmu:
But immediately after this I lose the ability to trace.

I have been tracing things with a status port at 0x70000000 I can write 
to and read from the host side with code like

   lis   r14,0x7000      /* debugging port */
   li   r15,0x2305      /* value to output */
   stw   r15,4(r14)     eieio

after turn_on_mmu executes this does not seem to work.
looking at other code it appeared that I needed to add
tophy(r14,r14) prior to the stw
but that does not seem to help.

What do I need to do to be able to continue to use my debug port ?


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

I am working through bringing up Linux 2.6.14 on a Xilinx V4 based
ppc405. with memory from 0x0 through 0x7fffffff

I have a debugging port at XPAR_KEYHOLE, I basically copied the code to 
setup a tlb entry for the serial debugging console to get an additional 
entry for my debugging port.

I am not particularly sharp on memory management.
Can I just cut and paste that code changing the address, and the tlb 
slot as below ?

     /* Load a TLB entry for the Keyhole, We use a 4k real==virtual 
mapping. */

     lis    r3,XPAR_KEYHOLE@h
     ori    r3,r3,XPAR_KEYHOLE@l
     mr    r4,r3
     clrrwi    r4,r4,12
     ori    r4,r4,(TLB_WR|TLB_I|TLB_M|TLB_G)

     clrrwi    r3,r3,12
     ori    r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_4K))

     li    r0,1            /* TLB slot 1 */
     tlbwe    r4,r0,TLB_DATA
     tlbwe    r3,r0,TLB_TAG

David H. Lynch Jr wrote:
I am working through bringing up Linux 2.6.14 on a Xilinx V4 based 
ppc405. with memory from 0x0 through 0x7fffffff
I get to this point in head_4xx.S:

/* We now have the lower 16 Meg mapped into TLB entries, and the caches
 * ready to work.
 */
turn_on_mmu:
    lis    r0,MSR_KERNEL@h
    ori    r0,r0,MSR_KERNEL@l
    mtspr    SPRN_SRR1,r0
    lis    r0,start_here@h            // SPRN_SRR0 is where the rfi 
resumes execution
    ori    r0,r0,start_here@l
    mtspr    SPRN_SRR0,r0
    SYNC
    rfi                /* enables MMU */
    b    .            /* prevent prefetch past rfi */

The value of SPRN_SRRO is 0xffffc00000002218 and SPRN_SRR1 is 
0x0000000200001032
I have not checked the bits in SPRN_SRR1 but isn't 0xffffc00000002218 
wrong ? it looks like it was sign
extended. physical 0x2218 is start_here so that part  is corect.