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

Sughosh Ganu
2012-01-13T17:38:21Z

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