Why does one "stw" fail with address translation disabled in PPC405EP?

[Zhou Rui]

在 2008-08-22五的 14:42 -0400，Josh Boyer写道：
> On Fri, Aug 22, 2008 at 08:27:15PM +0200, Zhou Rui wrote:
> >Hi, all:
> >    I think I meet an odd problem with PPC405EP (PPChameleonEVB Board).
> 
> What kernel version are you using?
> 
> >    I am running a kernel module which will execute a user space
> >application. The entry point of the application is 0x100000a0. At the
> 
> That should be the first clue that you are doing it wrong.  Don't do
> stuff like that in modules...
> 
> >moment when the processor tries to execute the application, 0x100000a0
> >is not in TLB (this can be seen from BDI by printing out TLB entries),
> >so DTLBMiss is called automatically and then finish_tlb_load. However,
> >InstructionAccess is followed and the problem arises here.
> >InstructionAccess starts from 0x400, and after instruction "0xc0000434
> ><InstructionAccess+52>:      stw     r12,64(r11)", machine check occurs.
> >This instruction will store the value of r12, which is 0x0 at this
> >moment, to address 0x03072de0. I am puzzled why this action leads to
> >machine check. Is it illegal to store 0x0 in a memory address? Or is
> >there some other cause of the machine check here?
> 
> I have no idea if you're using physical or virtual addresses here, so
> there isn't much we can do to help you.
> 
> Do you have enough DRAM to cover that?  Some of those boards only come
> with 32MiB of DRAM.

Oh, I think I just now realized that for 32MB DRAM, the physical address
should be between 0x0 and 0x1FFFFFF, but the address 0x03072da0 was out
of this range ...
To enlarge the memory size is one solution but I do not think it is
feasible for my board. Is there any solution from software side? I hope
there is.
Thank you very much!!!

Best Wishes

Zhou Rui
2008-08-23

> 
> josh

__________________________________________________
¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
http://cn.mail.yahoo.com