[U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before disabling it.

[Sughosh Ganu]

On Tue Jan 17, 2012 at 08:27:58AM -0700, Tom Rini wrote:
> On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganu <urwithsughosh at gmail.com> wrote:

> >> >> Hmm.. how did u-boot work on such boards? How can u-boot work with D-Cache
> >> >> enabled, if u-boot is not initializing it? (And I think, on davinci SoC
> >> >> we have a none working uboot ethernet driver if d-cache is enabled too).
> >> >> There must be a page_table in DRAM for using D-Cache in U-Boot, if u-boot
> >> >> don't initialize it, it maybe overrides it ... or miss I something?
> >> >
> >> >  Well, there is some data in the cache, which if not flushed creates
> >> >  problems on my board. I get the board to boot just by commenting out
> >> >  cpu_init_crit call. My hypothesis that the D-cache is enabled is
> >> >  simply because cache invalidation followed by cache disabling breaks
> >> >  the board, while flushing it prior to disabling gets it to boot
> >> >  fine. This(invalidation) would not have been a problem if the cache
> >> >  was in the disabled state.
> >>
> >> Putting my TI hat on, I've confirmed with the RBL folks that they
> >> aren't turning on ICACHE/DCACHE.
> >
> >  Well, i'm not sure then why does the cache invalidation cause a
> >  problem on my platform. Btw, will this patch be
> >  accepted. Irrespective of the cache state on my board, it is not a
> >  wrong fix, and moreover results in the booting of my board.
> >
> >  I haven't yet tried out reading the cache bit state in the spl. Will
> >  try out this experiment in a day or two, and share the results.
> 
> I think someone needs to look over this init code very carefully.  If
> I can summarize from memory quickly, when we enable the
> CP_CRITICAL_INITS code for everyone that exposed a problem on the
> hawkboard that _looks_like_ DCACHE is enabled by RBL as changing the
> code from doing an invalidate to a flush+invalidate fixes a problem.
> But the manual says we should be doing flush+invalidate anyhow and the
> RBL code is not turning on DCACHE.  Maybe we've got something else
> being done not as the manual says and that's tickling another issue?
  
  Tried a few things on my end.
  * Read the D-cache value in the spl, and confirmed that the data
    cache is indeed not enabled.
    
  * Enabled the data cache explicitly in cpu_init_crit, and booted
    u-boot. u-boot comes up fine, and trying a ping switches off the
    data cache with the warning message.

  So it definitely looks like the cache is not enabled. But still not
  able to figure out as to why does the flushing operation
  help. Really need to get a debugger :)

-sughosh