On Tue, Mar 11, 2008 at 1:30 PM, Eran Liberty liberty@extricom.com wrote:
Hi Andy,
I am bringing us back online as I think your insights might enlighten others who might be googleing for answers. (I know i try my best when faced with problems)
Oops, yes. I hit the wrong button. I meant to keep it on the list, too.
Notice that r27 is 0xf1030000
considering the command I did, cp.b 0xff800000 0xff000000 80000, I should have never accessed 0xf1030000.
Yes. My theory is that it's a speculative load, ie the processor ran code speculatively, and started a load to memory. However, it would only do that if there's a TLB entry for that address.
What is your INIT_RAM_ADDR?
I have used mpc8548cds as a reference so my local bus is mapped from 0xf0000000 - 0xffffffff law.c will have this line: ====================== law.c snip ====================================== /* LBC window - maps 256M 0xf0000000 -> 0xffffffff */ SET_LAW_ENTRY(8, CFG_LBC_SDRAM_BASE, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
So that's definitely why the LBC is involved. But I'm pretty sure there needs to be a TLB entry before the core will put the transaction on the bus.
/* * TLB 0: 16M Non-cacheable, guarded * 0xff000000 16M FLASH * Out of reset this entry is only 4K. */ SET_TLB_ENTRY(1, CFG_BOOT_BLOCK, CFG_BOOT_BLOCK, MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G, 0, 0, BOOKE_PAGESZ_16M, 1),
Right, look for any other entries that might be mapping the error address.
So we have local bus window mapping but not tlb mapping, which should be ok, because I should have accessed only addresses within the tlb mapped range.
so I guess my follow up questions are:
- Why does my u-boot thy to access this non flash address.?
My guess is it's a speculative load.
- Why is this a first time problem only?
The code that reports the exception doesn't actually clear the condition, so further such events can't cause this problem. Also, if it's a speculative load, the address will be fairly random, and so it just may not hit that window again.
- Flash is written ok in the end. Why does it not hurt that actual write?
Interrupts are disabled during the write. So the write will complete, then the exception fires. The speculative load shouldn't cause real problems since the code is not expecting that read to happen.
Andy