Hi Jerry, >> The fix will also not expose the accidental introduction >> of flash writes in the future, it'll just stop those >> writes from having any effect. > > IOW, it simply hides the bug. :-(
Yeah, I didn't like that as a solution either. >> It would be nicer to generate an exception if a write to >> flash occurs during the period before relocation, at least >> that way the introduction of an accidental flash write >> would be detected immediately. I could have a look at >> the 83xx MMU settings during that time and see if there >> was an alternative solution using that. > > Using the MMU that early is going to be some work and has risks of other > mysterious lockups when done wrong. MMUs are different for different > processors and, often, within different branches of the same family of > processors. This will add to the complexity. > > MMU == complexity == risk. :-( Yep, I agree. The 440EP solution to generate an exception looked a bit nicer, but its not portable either. > Most processors available today have debug registers. If the processor > used on a given target has a debug register set and the registers can be > set to trigger on a write to a range, that would give you an exception. > You would not necessarily have to handle the exception "properly", > simply enter a spin loop so that the processor stops in a known state > with enough information to identify the root cause. Haven't seen that type of register on the MPC8349EA, it might exist, I just didn't look :) > Pros: > * Get an exception identifying a bad bug occurrence rather than silent > pass (mostly) or failure (mysteriously). > > Cons: > * More complexity == risk > * Debug capabilities, like the MMU, are different for different > processors and families. This could be complex and could turn into an > ifdefhell. > * It may be easier and better to use a debugger (e.g. BDI-3000) to > control the hardware breakpoint registers. A debugger may get unhappy > or may simply undo our doings if we directly control the hardware > breakpoint registers. Yep, a repeatable bug can be traced using a debugger. The hard part is making the bug repeatable. > It would be nice to have a technique to trap these pre-relocation bugs. > They don't happen often, but they *do* happen and they are hard to find > (until they bite you and then they are hard to identify). > > What are the capabilities of your debugger? Can you set a hardware > breakpoint range on your flash and have it trigger on start up? If so, > we should add it to our FAQ and add the technique to our toolbox. Its a BDI2000. I don't recall seeing a trap on range feature. This is a tricky one to put in the FAQ, as it really shouldn't happen :) We managed to get pretty far with the debugger; we eventually found the address at which things died, however, the debugger wasn't able to give us an explanation. It was the logic analyzer on the flash/local-bus that showed the reason. So perhaps thats something that can be added to the FAQ. Let me know if you want something coherent, and I can write a 'logic analyzer tricks and tips' section for the FAQ. Cheers, Dave ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users