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

[Jerry Van Baren <gerald.vanbaren@ge.com>]

David Hawkins wrote:
> Hi Jerry,

[snip]

>> 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 :)

"e300 Power Architecture Core Family Reference Manual, Rev. 2" Chapter 
10 "Debug Features" Section 10.1.3 "Data Address Breakpoint Registers 
(DABR, DABR2)"

Unfortunately, it looks like it only handles exact address matches, not 
a range.

The e500 core appears to be able to do ranges.  Unfortunately, this is 
of limited value since it is an unusual capability.  (Chapter "8.4 Book 
E Debug Events" section 8.4.2.4 "Data Address Compare (DAC) Mode")

[snip]

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

Nope, looks like it is beyond the capability of the e300 core.  The BDI 
hardware breakpoints are just playing with the core's debug registers, 
so it isn't going to do any better than the core (and the software 
breakpoints require software assist, so they don't work when running in 
flash).

> 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

One really good trick is how to hook a logic analyzer to those 
itty-bitty balls on the processor.  Back when I was a boy, processors 
had 40 legs and no balls.  :-D  You must have a board with a logic 
analyzer connector.

Thanks,
gvb