Kernel 2.6 hangs at m82xx_board_init

Kernel 2.6 hangs at m82xx_board_init

[alebas]

Hi all,

I was trying to get kernel 2.6.10-rc1 running in mpc8272ads board,
but i have some problems.

Debugging with BDI2000 + gdb i have arrived to m82xx_board_init call,
which is coded in arch/ppc/platforms/pq2ads.c as:

void __init
m82xx_board_init(void)
{
        /* Enable the 2nd UART port */
        *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
}

When this code is executed, the kernel jumps directly to another
address, 0xc000984c, which is inside the __delay function, and
execution stays here in an infinite loop.

I get the following disassemble from objdump:

c01bf908 <m82xx_board_init>:
c01bf908:       3d 20 f4 50     lis     r9,-2992
c01bf90c:       61 29 00 04     ori     r9,r9,4
c01bf910:       80 09 00 00     lwz     r0,0(r9)      <=======
c01bf914:       54 00 02 0c     rlwinm  r0,r0,0,8,6
c01bf918:       90 09 00 00     stw     r0,0(r9)
c01bf91c:       4e 80 00 20     blr

and the marked instruction is the last one executed before the jump.

Any idea? Why this instruction is braching without control?

As bootloader i am using uboot-1.1.2.

Thanks.

Alex

Re: Kernel 2.6 hangs at m82xx_board_init

[Dan Malek]

On Nov 23, 2004, at 2:06 PM, alebas@televes.com wrote:

> When this code is executed, the kernel jumps directly to another
> address, 0xc000984c,

I suspect the MMU isn't yet set up to map the address of the BCSR.
Access the address causes a fault, and the "jump" you see is the
result of executing a bunch of exception handler instructions that
you won't single step due to the exception priorities.



	-- Dan

Kernel 2.6.10-rc1 yet not running on ads8272

[alebas]

Hi all,

After commenting out the BCSR lines on m82xx_board_init as Dan
suggested, some problem still prevents kernel 2.6.10-rc1 from
running in ads8272 board.

After running MMU_init, next step in head.S is this

/*
 * Go back to running unmapped so we can load up new values
 * for SDR1 (hash table pointer) and the segment registers
 * and change to using our exception vectors.
 */
        lis     r4,2f@h
        ori     r4,r4,2f@l
        tophys(r4,r4)
        li      r3,MSR_KERNEL & ~(MSR_IR|MSR_DR)
        FIX_SRR1(r3,r5)
        mtspr   SRR0,r4
        mtspr   SRR1,r3
        SYNC
        RFI
/* Load up the kernel context */
2:      bl      load_up_mmu

which is not clear for me. Here, the execution flow breaks
in RFI and never arrives to "bl load_up_mmu". The value of
SRR0 and SRR1 before RFI is:

8272>rd srr0
srr0: 0x000035f8  13816

8272>rd srr1
srr1: 0x00001002  4098

SRR0=0x35f8 is the EA where "bl load_up_mmu" instruction is
supposed to be.

So now I have no idea about what or why this is not working.
Any help would be very valuable. My knowledge about this
stuff is actually very limited.


Thanks,

Alex Bastos


Dan Malek <dan@embeddededge.com> wrote

> > When this code is executed, the kernel jumps directly to another
> > address, 0xc000984c,
>
> I suspect the MMU isn't yet set up to map the address of the BCSR.
> Access the address causes a fault, and the "jump" you see is the
> result of executing a bunch of exception handler instructions that
> you won't single step due to the exception priorities.
>
> 	-- Dan

Re: Kernel 2.6.10-rc1 yet not running on ads8272

[Mark Chambers]

> Hi all,
> 
> After commenting out the BCSR lines on m82xx_board_init as Dan
> suggested, some problem still prevents kernel 2.6.10-rc1 from
> running in ads8272 board.
> 
> After running MMU_init, next step in head.S is this
> 
> /*
>  * Go back to running unmapped so we can load up new values
>  * for SDR1 (hash table pointer) and the segment registers
>  * and change to using our exception vectors.
>  */
>         lis     r4,2f@h
>         ori     r4,r4,2f@l
>         tophys(r4,r4)
>         li      r3,MSR_KERNEL & ~(MSR_IR|MSR_DR)
>         FIX_SRR1(r3,r5)
>         mtspr   SRR0,r4
>         mtspr   SRR1,r3
>         SYNC
>         RFI
> /* Load up the kernel context */
> 2:      bl      load_up_mmu
> 
> which is not clear for me. Here, the execution flow breaks
> in RFI and never arrives to "bl load_up_mmu". The value of
> SRR0 and SRR1 before RFI is:
> 

RFI = Return From Interrupt.  In normal usage the current
address is copied into SRR0 when an exception occurs so
the processor will return to that point with an RFI.  So this
code is 'faking out' the RFI instruction to return to 2:

Are you maybe trying to trace through this code?  If so,
and depending on your debugger, you may not be able to.
If your debugger uses trace or some other exception to do
single step, once you get past mtspr SRR0,r4 the single
step exception will overwrite the correct SRR0.  You
can see if this is the case by only tracing to mtspr SRR0,r4
and then putting a breakpoint at 2:

Good luck,
Mark Chambers

Re: Kernel 2.6.10-rc1 yet not running on ads8272

[alebas]

Mark,

I have tried this before and this doesn't work.
Execution flow never arrives to "2:".

All the other values are extra info I have collected.
But problem was isolated using breakpoints to avoid
stepping influence.

Best regards,

Alex

Citando Mark Chambers <markc@mail.com>:


> RFI = Return From Interrupt.  In normal usage the current
> address is copied into SRR0 when an exception occurs so
> the processor will return to that point with an RFI.  So this
> code is 'faking out' the RFI instruction to return to 2:
>
> Are you maybe trying to trace through this code?  If so,
> and depending on your debugger, you may not be able to.
> If your debugger uses trace or some other exception to do
> single step, once you get past mtspr SRR0,r4 the single
> step exception will overwrite the correct SRR0.  You
> can see if this is the case by only tracing to mtspr SRR0,r4
> and then putting a breakpoint at 2:
>
> Good luck,
> Mark Chambers
>

Re: Kernel 2.6.10-rc1 yet not running on ads8272

[alebas]

Dan,

I have finally found what I was doing wrong.
Checking mem as you suggested I found that
the breakpoint I was setting to virtual
address 0xc00035f8 has to be set to physical
0x000035f8, otherwise it doesn't stop.

So problem was here with BDI2000 debugging,
MMU and me. Sorry about my misknowledge.

Nevertheless kernel is still hanging.
Now I have continued debugging and I have
arrived to start_kernel ... and go on till
do_basic_setup. But still seeing nothing in
the serial console before kernel hanging.

I think I have some problem with serial
console I have to solve before going on.

Thanks

Alex

Citando Mark Chambers <markc@mail.com>:

> So it's not the simple stuff.  Never is.
>
> I probably shouldn't jump in here, I'm over my head,
> but in the spirit of brainstorming:  Is there any chance
> the bl load_up_mmu instruction isn't in memory at
> physical address 35f8?  It looks like this code is
> bouncing back to physical addressing after having
> the mmu enabled - maybe look at physical
> memory at 35f8 and see if there's a problem?
>
> Mark
>