TLB Miss booting linux kernel on ppc 405

Hi All,

I'm using kernel 2.6.24 and when it comes to line 826 on the file
arch/ppc/kernel/head_4xx.S it gives a TLB Miss.

arch/ppc/kernel/head_4xx.S
823 start_here:
824
825         /* ptr to current */
826         lis    r2,init_task@h
827         ori    r2,r2,init_task@l

It seems to have a problem initializing the MMU.

What I could do to solve this?

Thanks,

-- 
Ricardo Ayres Severo [off-list ref]

On Feb 13, 2008 9:50 AM, Ricardo Ayres Severo [off-list ref] wrote:

Hi All,

I'm using kernel 2.6.24 and when it comes to line 826 on the file
arch/ppc/kernel/head_4xx.S it gives a TLB Miss.

arch/ppc/kernel/head_4xx.S
823 start_here:
824
825         /* ptr to current */
826         lis    r2,init_task@h
827         ori    r2,r2,init_task@l

I am just curious: how did you find that you have TLB miss on that
line?  Is it an Instruction TLB miss or a Data TLB miss?

Can you paste a dump of your registers (in XMD, rrd and srrd)?

I was having TLB misses awhile back due to some other problems, but
never had any on that line though.

I tracked the kernel execution using step one instruction (si) on gdb
and matching the jumps with the System.map.
It is a Data TLB Miss and this is the register dump after the miss occurs:

    r1: 00502090
    r2: 0000000f
    r3: c00003c0
    r4: c0000000
    r5: 00000000
    r6: 00000000
    r7: 74747955
    r8: 4c302c39
    r9: 00000000
    pc: 00001100
    lr: 00000018

Now I'm checking the PPC cache configurations on XPS, because when
treating the DTLB Miss Exception a Machine Check Exception occurs when
it works with L1. Does this makes sense or am I confusing things?

Thanks,

On Feb 13, 2008 3:17 PM, David Baird [off-list ref] wrote:

On Feb 13, 2008 9:50 AM, Ricardo Ayres Severo [off-list ref] wrote:

quoted

Hi All,

I'm using kernel 2.6.24 and when it comes to line 826 on the file
arch/ppc/kernel/head_4xx.S it gives a TLB Miss.

arch/ppc/kernel/head_4xx.S
823 start_here:
824
825         /* ptr to current */
826         lis    r2,init_task@h
827         ori    r2,r2,init_task@l

I am just curious: how did you find that you have TLB miss on that
line?  Is it an Instruction TLB miss or a Data TLB miss?

Can you paste a dump of your registers (in XMD, rrd and srrd)?

I was having TLB misses awhile back due to some other problems, but
never had any on that line though.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-- 
Ricardo Ayres Severo [off-list ref]

On Feb 13, 2008 10:38 AM, Ricardo Ayres Severo [off-list ref] wrote:

I tracked the kernel execution using step one instruction (si) on gdb
and matching the jumps with the System.map.
It is a Data TLB Miss and this is the register dump after the miss occurs:

    r1: 00502090
    r2: 0000000f
    r3: c00003c0
    r4: c0000000
    r5: 00000000
    r6: 00000000
    r7: 74747955
    r8: 4c302c39
    r9: 00000000
    pc: 00001100
    lr: 00000018

Can you also past the special registers (srrd in XMD)?  I am very
curious about SRR0 and SRR1 and maybe some of the others.

Now I'm checking the PPC cache configurations on XPS, because when
treating the DTLB Miss Exception a Machine Check Exception occurs when
it works with L1. Does this makes sense or am I confusing things?

Too soon for me to tell :-)

Here are the srr dump:
  srr0: c0002218
  srr1: 00021030
  srr2: 00001154
  srr3: 00000000

On Feb 13, 2008 3:51 PM, David Baird [off-list ref] wrote:

On Feb 13, 2008 10:38 AM, Ricardo Ayres Severo [off-list ref] wrote:

quoted

I tracked the kernel execution using step one instruction (si) on gdb
and matching the jumps with the System.map.
It is a Data TLB Miss and this is the register dump after the miss occurs:

    r1: 00502090
    r2: 0000000f
    r3: c00003c0
    r4: c0000000
    r5: 00000000
    r6: 00000000
    r7: 74747955
    r8: 4c302c39
    r9: 00000000
    pc: 00001100
    lr: 00000018

Can you also past the special registers (srrd in XMD)?  I am very
curious about SRR0 and SRR1 and maybe some of the others.

quoted

Now I'm checking the PPC cache configurations on XPS, because when
treating the DTLB Miss Exception a Machine Check Exception occurs when
it works with L1. Does this makes sense or am I confusing things?

Too soon for me to tell :-)

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

-- 
Ricardo Ayres Severo [off-list ref]

On Feb 13, 2008 11:03 AM, Ricardo Ayres Severo [off-list ref] wrote:

Here are the srr dump:
  srr0: c0002218
  srr1: 00021030
  srr2: 00001154
  srr3: 00000000

Okay, SRR0 tells us that you did in fact have an exception at
0xc0002218.  And I am willing to bet that is the line you mentioned
(line 826 of start_here).  You can match this up with your System.map
or an objdump -d of vmlinux.

Someone who knows more than I do can correct me on this, but I have a
suspicion.  As soon virtual (translation) mode is entered, I have had
a hard time using the normal debugging functions (e.g. single
instruction stepping and reading memory regions).  While in virtual
mode, it seemed like I had to resort to these techniques:

- Blinking some LEDs
- Spitting characters out of a uartlite
- When an exception occurs, the processor switches back into real mode
and therefore I can set breakpoints on the beginnings of various
exception handlers and be able to use normal debugging tools again

So, I have another question.  Can you set a breakpoint on 0x1100 (in
XMD: bps 0x1100 hw), then just let it run (i.e. do not single step!)
all the way until an exception happens.  When the exception happens,
can you then paste the SRR0, SRR1, and the ESR (exception syndrome
register)?

I hope I am not giving you a run-around here....

-David

Executing without single step the exception doesn't occurs. But at
__log_buf I get only trash, even after reseting the processor.
How can I send some characters to uartlite on asm code?

Thanks,

On Feb 13, 2008 4:32 PM, David Baird [off-list ref] wrote:

On Feb 13, 2008 11:03 AM, Ricardo Ayres Severo [off-list ref] wrote:

quoted

Here are the srr dump:
  srr0: c0002218
  srr1: 00021030
  srr2: 00001154
  srr3: 00000000

Okay, SRR0 tells us that you did in fact have an exception at
0xc0002218.  And I am willing to bet that is the line you mentioned
(line 826 of start_here).  You can match this up with your System.map
or an objdump -d of vmlinux.

Someone who knows more than I do can correct me on this, but I have a
suspicion.  As soon virtual (translation) mode is entered, I have had
a hard time using the normal debugging functions (e.g. single
instruction stepping and reading memory regions).  While in virtual
mode, it seemed like I had to resort to these techniques:

- Blinking some LEDs
- Spitting characters out of a uartlite
- When an exception occurs, the processor switches back into real mode
and therefore I can set breakpoints on the beginnings of various
exception handlers and be able to use normal debugging tools again

So, I have another question.  Can you set a breakpoint on 0x1100 (in
XMD: bps 0x1100 hw), then just let it run (i.e. do not single step!)
all the way until an exception happens.  When the exception happens,
can you then paste the SRR0, SRR1, and the ESR (exception syndrome
register)?

I hope I am not giving you a run-around here....

-David

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

-- 
Ricardo Ayres Severo [off-list ref]

On Feb 13, 2008 11:49 AM, Ricardo Ayres Severo [off-list ref] wrote:

Executing without single step the exception doesn't occurs. But at
__log_buf I get only trash, even after reseting the processor.
How can I send some characters to uartlite on asm code?

Great.  This confirms that I am not crazy.  You are having similar
results as I did.  But I still don't yet know why single-step and
memory read can't be used in virtual mode...

To use UARTLite, there are some patches you need.  First thing, you
have to setup your TLBs so that uartlite can be accessed in virtual
mode.  I did something like this:

#define MY_UART_LITE_BASE 0x40000000

 lis r3,MY_UART_LITE_BASE@h
 ori r3,r3,MY_UART_LITE_BASE@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_16M))

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

Then, you need to add some C code somewhere.  I chose "setup.c" (in
same directory as head_4xx.S) for this purpose:

// Try to get value for XPAR_RS232_UART_BASEADDR:
#include <platforms/4xx/xparameters/xparameters.h>
#include <platforms/4xx/xparameters/xparameters_ml403.h>

void
serial_putc(unsigned char c)
{
 while (((*(volatile uint32_t*)(XPAR_RS232_UART_BASEADDR + 0x8)) & 0x08) != 0);
 *(volatile uint32_t*)(XPAR_RS232_UART_BASEADDR + 0x4) = c;
}

void
print_A()
{
 serial_putc('A');
}

void
print_B()
{
 serial_putc('B');
}


Now, from assembly, things are easy.  Just do this, I think:

 blr print_A
 blr print_B

If this gives you any trouble, try it first from real mode so that you
can easily debug it.

-David

Have you solved your problem??

I'm having the *EXACT* same problem on a Virtex4FX60.
The device is configured with PLBv46/MPMC3/LL_TEMAC.

I'm under the suspicion that the PLB is issuing an error when switching
to virtual mode and that there is either a timing/synthesis error or a
fundamental error with the way the FPGA is getting synthesized with the
PLB. 


RJW.




On Wed, 2008-02-13 at 12:02 -0700, David Baird wrote:

On Feb 13, 2008 11:49 AM, Ricardo Ayres Severo [off-list ref] wrote:

quoted

Executing without single step the exception doesn't occurs. But at
__log_buf I get only trash, even after reseting the processor.
How can I send some characters to uartlite on asm code?

Great.  This confirms that I am not crazy.  You are having similar
results as I did.  But I still don't yet know why single-step and
memory read can't be used in virtual mode...

Hi Robert,

I didn't solve the problem yet. I'm having problems with the memset_io
in early_init and am studying if the SDRAM is initializing right.
Any progress I'll send to the list.

Good luck,

On Wed, Feb 20, 2008 at 7:24 PM, Robert Woodworth
[off-list ref] wrote:

Have you solved your problem??

 I'm having the *EXACT* same problem on a Virtex4FX60.
 The device is configured with PLBv46/MPMC3/LL_TEMAC.

 I'm under the suspicion that the PLB is issuing an error when switching
 to virtual mode and that there is either a timing/synthesis error or a
 fundamental error with the way the FPGA is getting synthesized with the
 PLB.


 RJW.





 On Wed, 2008-02-13 at 12:02 -0700, David Baird wrote:
 > On Feb 13, 2008 11:49 AM, Ricardo Ayres Severo [off-list ref] wrote:
 > > Executing without single step the exception doesn't occurs. But at
 > > __log_buf I get only trash, even after reseting the processor.
 > > How can I send some characters to uartlite on asm code?
 >
 > Great.  This confirms that I am not crazy.  You are having similar
 > results as I did.  But I still don't yet know why single-step and
 > memory read can't be used in virtual mode...
 >




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

-- 
Ricardo Ayres Severo [off-list ref]

Hi Ricardo,

On Feb 20, 2008 2:29 PM, Ricardo Ayres Severo [off-list ref] wrote:

I didn't solve the problem yet. I'm having problems with the memset_io
in early_init and am studying if the SDRAM is initializing right.
Any progress I'll send to the list.

It sounds suspiciously like you might be having this problem:

    http://www.nabble.com/Problem-booting-Linux-2.6-on-Virtex-4-td14795525.html
    "Things start to go obviously wrong after early_init calls memset to
    clear the .bss section."

I don't know what the cause of the problem was, but the symptom is
that different memory regions were aliased onto each other (it was
like an address bit wasn't working or something funny was happening
with the cache ... but only in virtual mode).  The problem was fixed
after rebuilding the design in EDK 9.2i.  I don't know what caused the
problem originally though.

Let us know if you get this resolved or have more questions...  I
might not be able answer, but hopefully someone can help.

-David

Hi David,

I rebuilt the design in EDK 9.2i and problem persisted. The only
difference is the registers are not zeroing anymore. No exception is
thrown, and the system still hangs at memset_io. I'm running out of
options.
It is possible to boot Linux on Virtex-II, isn't?

Thanks,

On Wed, Feb 20, 2008 at 7:47 PM, David Baird [off-list ref] wrote:

Hi Ricardo,


 On Feb 20, 2008 2:29 PM, Ricardo Ayres Severo [off-list ref] wrote:
 > I didn't solve the problem yet. I'm having problems with the memset_io
 > in early_init and am studying if the SDRAM is initializing right.
 > Any progress I'll send to the list.

 It sounds suspiciously like you might be having this problem:

    http://www.nabble.com/Problem-booting-Linux-2.6-on-Virtex-4-td14795525.html
    "Things start to go obviously wrong after early_init calls memset to
    clear the .bss section."

 I don't know what the cause of the problem was, but the symptom is
 that different memory regions were aliased onto each other (it was
 like an address bit wasn't working or something funny was happening
 with the cache ... but only in virtual mode).  The problem was fixed
 after rebuilding the design in EDK 9.2i.  I don't know what caused the
 problem originally though.

 Let us know if you get this resolved or have more questions...  I
 might not be able answer, but hopefully someone can help.

 -David

-- 
Ricardo Ayres Severo [off-list ref]

On Thu, Feb 21, 2008 at 10:50 AM, Ricardo Ayres Severo
[off-list ref] wrote:

 I rebuilt the design in EDK 9.2i and problem persisted. The only
 difference is the registers are not zeroing anymore. No exception is
 thrown, and the system still hangs at memset_io. I'm running out of
 options.
 It is possible to boot Linux on Virtex-II, isn't?

Yes, it is possible.  I have a Virtex-II Pro with Linux running on it
although I didn't configure it myself (it is one of those Black Dog
computers).  I work with Virtex-4s right now.

Can you try a reference design for the Virtex-II perhaps?

Can you comment out memset_io and write your own version of it (which
you can insert debug statements into)?

When/where in memset are things breaking?  What is the nature of the
breaking?  Can you get your serial terminal to print out hex values
(for memory locations, memory values, etc.)?

Hi Robert,

On Wed, Feb 20, 2008 at 2:24 PM, Robert Woodworth
[off-list ref] wrote:

 I'm under the suspicion that the PLB is issuing an error when switching
 to virtual mode and that there is either a timing/synthesis error or a
 fundamental error with the way the FPGA is getting synthesized with the
 PLB.

Can you offer a suggestion how I can check to see if the PLB is
issuing an error (a good application note for me to read or anything)?
 I was having a similar problem in virtual mode on one of my systems,
and I might be able to see also if I am having a problem with the PLB
bus.

-David

I'm no expert but....

I did configure my device with the DCR enabled and connected the PLBv46
DCR to the PPC.  In the TLB miss ISR I read the PLB registers and the
MCSR I *DID* notice that the PLB error registers were set.

I added some asm code to read MCSR (see Xilinx UG011.pdf, page 213) and
I also added the asm code to read the DCR of the PLB.  Sure enough, the
MCSR and PLB-DCR registers showed a DPLBError.

It's only a couple of asm statements:

mfspr   r30, 0x23c



Question to Xilinx experts:
What would cause the PLB to issue the DPLBError?????




<note to Xilinx>

Hey Xilinx guys!
Can you hack the gdb included with EDK such that it will recognize the
MCSR when gdb reads registers!

</note to Xilinx>

 


On Thu, 2008-02-21 at 11:04 -0700, David Baird wrote:

Hi Robert,

On Wed, Feb 20, 2008 at 2:24 PM, Robert Woodworth
[off-list ref] wrote:

quoted

 I'm under the suspicion that the PLB is issuing an error when switching
 to virtual mode and that there is either a timing/synthesis error or a
 fundamental error with the way the FPGA is getting synthesized with the
 PLB.

Can you offer a suggestion how I can check to see if the PLB is
issuing an error (a good application note for me to read or anything)?
 I was having a similar problem in virtual mode on one of my systems,
and I might be able to see also if I am having a problem with the PLB
bus.

-David