[U-Boot-Users] RFQ: disable flash writes until after relocation?

[David Hawkins <dwh@ovro.caltech.edu>]

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