memory corruption after MMU turned on

[Lei Sun]

I am using codewarrior and USB+TAP for debugging(didn't got BDI yet).
One problem seems like if i set a break point at some place, when the
code reach there, it did stopped, but the instruction on that location
became 0x00000000 !
Any also, the kernel is loaded at physical address 0x0, how do  i set
the break point to 0xC000XXX address? I suppose i should set the break
point at the physical address instead.
I don't have the hardware to try right now.

Thank you for your reply!

lei

On 11/16/06, Steven Blakeslee <BlakesleeS at embeddedplanet.com> wrote:
> Generally stepping over the rfi command will cause the problem.
> Instead, set a breakpoint at the address that the rfi command will jump
> to, the C000XXX address.  Then step through code from then on.
>
>
>
> > -----Original Message-----
> > From:
> linuxppc-embedded-bounces+blakeslees=embeddedplanet.com at ozlabs.org
> > [mailto:linuxppc-embedded-
> > bounces+blakeslees=embeddedplanet.com at ozlabs.org] On Behalf Of Lei Sun
> > Sent: Thursday, November 16, 2006 10:45 AM
> > To: linuxppc-embedded at ozlabs.org
> > Subject: memory corruption after MMU turned on
> >
> > Hi all:
> >    I am trying to bring up customized board based on MPC8270, the
> > kernel version is 2.4.30, it works fine on one of the Eval board
> > (PQ2FADS-VR, which use MPC8275).
> >    The kernel hangs after uncompressing is done, further debug shows
> > that it hangs right after "rfi " instruction of the turn_on_mmu:
> > function in head.S
> >
> >  turn_on_mmu:
> >     240     mfmsr   r0
> >     241     ori r0,r0,MSR_DR|MSR_IR
> >     242     mtspr   SRR1,r0
> >     243     lis r0,start_here at h
> >     244     ori r0,r0,start_here at l
> >     245     mtspr   SRR0,r0
> >     246     SYNC
> >     247     RFI             /* enables MMU */
> >
> > After i step over the RFI instruction, the PC points to C000XXX , but
> > all memory content is 0 by then.
> > my BATU0 is 0xC000FFE0  BATL0 is 0x00000002, I have 128MB RAM. The
> > u-boot works fine, without MMU turned on. We do have some hardware
> > problem, such that i have to lower the bus frequency to make the SDRAM
> > stable. What physical parameter could cause the board not working with
> > MMU on?
> >
> > Any suggestion?
> >
> > Thanks
> > lei
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>