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

[Andy Fleming]

>  Ok closer look revealed this entry.
>  ========================== tlb.c snip ===============================
>         /*
>          * TLB 6:       64M     Cacheable, non-guarded
>          * 0xf000_0000  64M     LBC SDRAM
>          */
>         SET_TLB_ENTRY(1, CFG_LBC_CACHE_BASE, CFG_LBC_CACHE_BASE,
>                       MAS3_SX|MAS3_SW|MAS3_SR, 0,
>                       0, 6, BOOKE_PAGESZ_64M, 1),
>  =====================================================================
>
>  And I don't even have SDRAM :)... but in order to stay as close to my
>  reference, mpc8548cds, I thought the extra tlb entry could not hurt me.
>
>  I have remarked it and the Exception did not occur again.

Excellent!



>  my last unknown / not understood corner... is why the speculative loads
>  occur in the first time.

This is a common fact of CPUs.  In order to improve performance, the
cpu will often start executing code paths before it knows whether
those paths will be taken.  If the path is taken, the results are
committed, and you don't have to wait.  If the path isn't taken, the
results are ignored.  When the path is not taken, it's likely that the
registers aren't in a sensible state, so random addresses can end up
getting loaded.  When things aren't mapped, the loads don't happen
(speculative instructions aren't allowed to cause exceptions).  Also,
pages that are marked "guarded" don't allow speculative access
(reading from IO regions can have side-effects, so it's not allowed to
do so speculatively).

After the first speculative load, either the branch predictor starts
being right from them on, or it just isn't detected because the
subsequent errors are gated behind the LBC interrupt logic, waiting
for someone to clear it.

Andy