On 07/13/2018 02:50 PM, Jason Rush wrote: > On 7/11/2018 1:54 PM, Marek Vasut wrote: >> On 07/11/2018 07:30 PM, Trent Piepho wrote: >>> 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. >> That's why we do dcache_off() icache_off() first, to make sure the >> caches are in consistent state. But a good point nonetheless, this >> should be checked. > I call dcache_off() and icache_off() after scrubbing, and I > verified the MMU control register indicated they were off. >>> 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? >> The SoCFPGA has some weird warm/cold reset hooks even in the bootrom, >> could be. But the DRAM should be torn down in either case. > Maybe there is something wrong with the reset hooks? I could try > and clear the on chip RAM after U-Boot relocates just to see what > happens. Or there is probably an enable for the hooks I could try > and disable.
Warm reset just jumps into OCRAM. Maybe the code in OCRAM is corrupted. Cold reset reloads the OCRAM content from flash/sdmmc. >>> 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. >>> > After scrubbing I first call flush_dcache_all(), then I added calls to > invalidate_icache_all() and invalidate_dcache_all(), and finally I > call dcache_off() and icache_off(). I wasn't sure about the order > I should call them, but there was no change. > -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
