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

[Jerry Van Baren]

David Hawkins wrote:
> Hi all,
> 
> We recently debugged a problem where a Flash write on
> MPC8349E and MPC8349EA processor boards was accidentally
> occurring during board initialization.
> 
> Under the right conditions, the write appears to put
> the flash into a command-mode, rather than read-data mode,
> and further reads from the flash return invalid data
> (as far as the processor is concerned). The write was
> coming from drivers code that we had not introduced,
> and depends on the address of the flash write which
> changes depending on the section sizes, so the cause
> of the bug was not initially obvious.

Thanks for the complete write up on your findings.  That was very helpful.

[snip]

> Writes to boot Flash could be disabled early on in the
> boot sequence, and then enabled again after relocation.
> This would protect against writes to the boot flash.
> 
> The downside of this change, would be that flash writes
> would not work if you stopped the processor between the
> time writes were disabled, and then enabled.

[snip]

> 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.  :-(

> 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.  :-(

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.

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.

> The 440EP manual indicates that a protect error would
> occur if a write is attempted to a read-only bank.
> 
> I figured I'd gauge if there was any interest in adding
> this feature before looking into it further.

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.

> Cheers,
> Dave

Thanks,
gvb