OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?

[Catalin Marinas]

On 2 February 2012 14:49, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Thu, Feb 02, 2012 at 02:32:03PM +0000, Catalin Marinas wrote:
>> We could do the same and move the bit enabling to separate repository :).
>
> We must certainly could do but that doesn't get around the errata
> issues when you have things before the kernel (or before these blobs)
> enabling things like the caches and MMU.

That was my original point - allow such code to be built into a blob
that the boot loader can execute. But I got your point that not all
boot loaders are able to execute two binary images.

> The only answer which assures complete system stability is for the
> earliest reasonable point in the booting sequence to handle the errata,
> before any of the potential errata scenarios occur.  For things like
> working around L2 cache problems, that means before the L2 cache is
> enabled for the first time.
>
> If the boot loader enables the L2 cache, then _it_ has to take care of
> the errata before it enables the L2 cache, and not some blob that it
> loads.
>
> If the boot loader enables the cache, and there are workarounds for buggy
> cache behaviour, then the boot loader has to implement those errata
> itself.

But as it was pointed out already, many of those are very rare
conditions that you can't actually trigger during the boot sequence.
There are other errata that require SMP for example and the boot
loader (or decompressor) doesn't care.

> So, I propose that we rip out all those work-arounds that are just
> 'set this bit in some register' at boot time from the kernel itself
> right now, and reconsider how these are handled.

Just don't remove them until we agree where we should *move* them.
They are still good documentation so far. I would say just disable the
workarounds in the kernel .config until we decide.

> But, having errata for things like DMB being faulty in the kernel after
> things like the boot loader will _already_ have had to issue DMB
> instructions, or for failing I-cache invalidate after we've already done
> some I-cache invalidates (eg, boot loader or the decompressor) is quite
> absurd.

As I said, most errata are really hard to trigger (but ARM cannot
guarantee that it is impossible, so they need to be published).

-- 
Catalin