Mark Pilant wrote:
Hi Jerry.
[snip]
Does the TLB have the "G" (Guarded) bit set? That prevents out-of-order loading (probably not an issue, but something to check).
Yes, the guarded bit is set in .../board/sbc8560/init.S.
How about hitting it with da big hammer: put a sync;isync pair in the loop. If that makes it better, remove the isync (should not be necessary). If that still works, try using a eieio instead of the sync (I'm not sure if eieio is useful for the 85xx, on the 603e core, it is a NOP).
I thought I had tried this earlier, but couldn't remember. So I tried it again. No Luck. (The generated code does the sync/isync before the register fetch. If the FLG bit is still set, the sync/isync is done again and the fetch repeated.)
According to the RM, the e500 replaces eieio with mbar. Since I had not tried that one, I just did. You guessed it... no luck.
I'm probably doing something really stupid; and probably really simple which is why I haven't spotted *my* problem.
It is also possible the WR SBC8560 we have is broken. Although I think that is not a really likely because it runs the VxWorks bootloader fine.
VERY unlikely since this is just dealing with the scc which is all internal to the 85xx.
- Mark
OK at the risk of insulting you, create the sync;isync version and load it into flash. Now figure out the start address of the the routine and disassemble it with the visionICE. Is the right stuff loaded? Set a hardware breakpoint: is it being executed?
Trivia: the visionICE is using the fsl background debug mode which, I am sure, is not exactly the same method and path as the execution of code in the processor. Having it work for the vICE doesn't say much other than the actual scc bit is working. Somebody is feeding you stale data in the path the vICE /isn't/ using.
Grasping at straws (been burned before), gvb