[U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it

Albert ARIBAUD
2013-07-10T12:30:30Z

Hi Sughosh,

On Wed, 10 Jul 2013 15:35:10 +0530, Sughosh Ganu
<urwithsughosh@gmail.com> wrote:

> hi Albert,
>
> On Tue Jul 09, 2013 at 10:28:13AM +0200, Albert ARIBAUD wrote:
>
> > > > The arm926ej-s data cache does not have a single fixed policy, and
> > > > does not have a bypass-on-write policy, only write-through and
> > > > copy-back.
> > > >
> > > > Other, more complex, policies may be defined, but at the MMU, not cache,
> > > > level, and those are not constant for all arm926ej-s based SoCs; not
> > > > even constant for a given SoC as they are configurable at run-time to
> > > > fit the chosen system addressing map.
> > >
> > > Can you please elucidate on these policies. Based on my reading of the
> > > arm developers manual and the arm926ejs trm, the mmu makes a
> > > particular region cacheable and/or write bufferable. I did not find
> > > mention of any other policies. Maybe pointers or links to the
> > > documents would help.
> >
> > You are correct re the other policies of the DDI0198E (ARM926EJ-S
> > TRM) MMU -- page 3-11, bits 3-2 of the section descriptor. Note however
> > that you may have to refer to your specific SoC's TRM or equivalent, as
> > the SoC designer may have defined its own system-level cache and MMU
> > architecture.
> >
> > Note in any case that none of the policies mentioned in DDI0198E is
> > described as read-allocate (let alone "read-allocate only" where writes
> > would bypass the enabled cache); on the contrary, the only cache
> > policies mentioned are write-through and write-back, both of which
> > contradict cache bypass on write.
>
> I was referring to the cache allocation policy mentioned in section
> 4.1 in the DDI0198E document -- this is also mentioned in table 12.1
> in chapter 12 of the arm developers guide.

Can you please quote the exact part of 4.1 which describes the cache
policy and then explain what you think it means exactly?

> -sughosh

Amicalement,
--
Albert.