Messages in this thread | | | Date | Sat, 25 Jan 2020 18:06:13 +0000 | From | Russell King - ARM Linux admin <> | Subject | Re: [PATCH] ARM: 8936/1: decompressor: avoid CP15 barrier instructions in v7 cache setup code |
| |
On Sat, Jan 25, 2020 at 09:39:50AM -0800, Guenter Roeck wrote: > Hi, > > On Fri, Nov 08, 2019 at 01:44:32PM +0100, Ard Biesheuvel wrote: > > Commit e17b1af96b2afc38e684aa2f1033387e2ed10029 > > > > "ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache" > > > > added some explicit handling of the CP15BEN bit in the SCTLR system > > register, to ensure that CP15 barrier instructions are enabled, even > > if we enter the decompressor via the EFI stub. > > > > However, as it turns out, there are other ways in which we may end up > > using CP15 barrier instructions without them being enabled. I.e., when > > the decompressor startup code skips the cache_on() initially, we end > > up calling cache_clean_flush() with the caches and MMU off, in which > > case the CP15BEN bit in SCTLR may not be programmed either. And in > > fact, cache_on() itself issues CP15 barrier instructions before actually > > enabling them by programming the new SCTLR value (and issuing an ISB) > > > > Since all these routines are specific to v7, let's clean this up by > > using the ordinary v7 barrier instructions in the v7 specific cache > > handling routines, so that we never rely on the CP15 ones. This also > > avoids the issue where a barrier is required between programming SCTLR > > and using the CP15 barrier instructions, which would result in two > > different kinds of barriers being used in the same function. > > > > Acked-by: Marc Zyngier <maz@kernel.org> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > This patch causes all qemu emulations for ARM1176 to fail hard (stall with > no console output even with earlycon enabled). This affects witherspoon-bmc, > ast2500-evb, romulus-bmc, and swift-bmc. It does not affect emulations > for other CPU types, even with the same kernel configuration (such as > ast2600-evb).
Hmm, looks like we're going to have to drop 8936/1, 8941/1 and 8942/1 in that case.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
| |