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
