On Wed, 2018-07-11 at 08:56 -0500, Jason Rush wrote:
> On 7/11/2018 8:48 AM, Marek Vasut wrote:
> > On 07/11/2018 03:49 PM, Jason Rush wrote:
> > > 
> > > My mistake.  I did disable the dcache after scrubbing too.  The
> > > code is almost identical to the Arria10 code where after
> > > scrubbing it flushes the dcache, then turns it off.
> > > 
> > > The weird reset problems happens if I scrub the area where
> > > u-boot relocates to with the dcache on, then turn dcache off.
> > > 
> > > I tried to also tried turning the MMU off, but that didn't help.
> > 
> > Maybe there are some data used by the SPL there ? I think the SPL has
> > malloc area in RAM at some point.
> > 
> I thought something similar, so I narrowed it down to clearing
> just from where U-Boot relocates to the end of DRAM.  If I'm
> correct, that includes where U-Boot relocates and where the
> MMU tables are normally stored.

I wonder if the reset does not properly reset the CPU caches?  The idea
being that the CPU cache has stale data from before the reset, or maybe
just stale tag bits, and the hang is due to using this bad data from
the cache.

Or perhaps there is always something done incorrectly, but it is only
the state of DRAM after a reset, vs a power cycle, that consistently
triggers a hang?

If possible, try to add code before the hang point to invalidate both
the i-cache and d-cache for the problem region above.  Perhaps the SPL
is doing something wrong w.r.t. cache invalidation, e.g. moving code
around and not updating the i-cache, because it assumes nothing has yet
used the caches, which is now no longer the case since you turn them on
for scrubbing.
U-Boot mailing list

Reply via email to