[U-Boot-Users] Flash write crash on MPC8548CDS

[Andy Fleming]

On Tue, Mar 11, 2008 at 1:30 PM, Eran Liberty <liberty at 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