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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

And so the list goes on.

I think the one issue which Santosh is justified about is: if that is
the case, why have the errata workarounds in the kernel in the first
place.  I agree - it makes no sense when we have things like the
decompressor enabling the caches.

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.

If that means boot loader people need to update their code to deal with
errata, because they want to use CPU features which have errata associated
with them, they then get to deal with the errata updates themselves, and
also have to carry the pain of dealing with running in non-secure mode.
Or, they will have to chose to avoid using those features.

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.

So, I think we need to rip out a fair number of these errata from the
kernel itself; it's quite clear they're already being done far too late
in the system boot sequence.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux