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

[Tom Rini]

On Mon, Jan 16, 2012 at 11:46 PM, Sughosh Ganu <urwithsughosh at gmail.com> wrote:
> On Mon Jan 16, 2012 at 10:57:05AM -0700, Tom Rini wrote:
>> On Fri, Jan 13, 2012 at 10:38 AM, Sughosh Ganu <urwithsughosh at gmail.com> wrote:
>> > 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 at 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.
>>
>> 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?

-- 
Tom