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

[Sughosh Ganu <urwithsughosh@gmail.com>]

hi Heiko,

On Fri Jan 13, 2012 at 04:29:29PM +0100, Heiko Schocher wrote:
> Hello Sugosh,
> 
> Sughosh Ganu wrote:
> > hi Christian,
> > 
> > On Fri Jan 13, 2012 at 09:06:26AM +0100, Christian Riesch wrote:
> >> Hi Sughosh,
> >> I had a look at the patch and I tried to understand what's going on
> >> here (I must confess that I didn't know anything about this cache
> >> stuff).
> > 
> >   Ok, thanks for taking time off to understand this issue.
> > 
> >> On Tue, Jan 10, 2012 at 7:12 PM, Sughosh Ganu <urwithsughosh@gmail.com> wrote:
> >>> The current implementation invalidates the cache instead of flushing
> >>> it. This causes problems on platforms where the spl/u-boot is already
> >>> loaded to the RAM, with caches enabled by a first stage bootloader.
> 
> 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.

> 
> Are you sure, the RBL enables the D-Cache on your board? Nevertheless,
> I think, we must disable the D-Cache here with "cleaning" it (as your
> patch did) instead only invalidating it, as current code did.

  I am not sure, this is just my guess. By default, the caches are
  disabled on reset, so the only possible source is the rbl. But I
  don't have access to the rbl code to say for sure. Unfortunately i
  also don't have JTAG or any other debugger to dig more into
  this. But yes, like you mention, we must be cleaning the cache
  before disabling it, so this fix is correct.

-sughosh