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 U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot