> 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
