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

David Hawkins
2008-07-21T17:36:41Z

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