On Fri, Dec 09, 2022 at 07:20:00PM +0100, Sebastian Reichel wrote:
> All the erratas for more recent CPUs (Cortex A15/A12/A17) do not
> require !ARCH_MULTIPLATFORM, since there is runtime detection of
> effected CPUs in arch/arm/mm/proc-v7.S.
>
> Errata config options for the older Cortex A8/A9 CPUs have the
> !ARCH_MULTIPLATFORM dependency, but the CPUs are also runtime
> detected. Since there is runtime detection, it should be fine
> to enable the erratas for a multi platform kernel.
>
> Signed-off-by: Sebastian Reichel <[email protected]>
> ---
> For me the most likely explanation that this has not yet happened is
> me missing an important detail, so I sent it as RFC. If you point it
> out I will try to document the reason.
IIRC, the reason these are marked with !ARCH_MULTIPLATFORM is for when
the kernel is running in the non-secure world - the accessed registers
may prevent platforms booting. However, it was a long time ago and I
don't remember clearly now.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, Dec 9, 2022, at 19:45, Russell King (Oracle) wrote:
> On Fri, Dec 09, 2022 at 07:20:00PM +0100, Sebastian Reichel wrote:
>> All the erratas for more recent CPUs (Cortex A15/A12/A17) do not
>> require !ARCH_MULTIPLATFORM, since there is runtime detection of
>> effected CPUs in arch/arm/mm/proc-v7.S.
>>
>> Errata config options for the older Cortex A8/A9 CPUs have the
>> !ARCH_MULTIPLATFORM dependency, but the CPUs are also runtime
>> detected. Since there is runtime detection, it should be fine
>> to enable the erratas for a multi platform kernel.
>>
>> Signed-off-by: Sebastian Reichel <[email protected]>
>> ---
>> For me the most likely explanation that this has not yet happened is
>> me missing an important detail, so I sent it as RFC. If you point it
>> out I will try to document the reason.
>
> IIRC, the reason these are marked with !ARCH_MULTIPLATFORM is for when
> the kernel is running in the non-secure world - the accessed registers
> may prevent platforms booting. However, it was a long time ago and I
> don't remember clearly now.
The git log confirms your memory, this is the description of
commit 62e4d357aae0 ("ARM: 7609/1: disable errata work-arounds
which access secure registers"):
In order to support secure and non-secure platforms in multi-platform
kernels, errata work-arounds that access secure only registers need to
be disabled. Make all the errata options that fit in this category
depend on !CONFIG_ARCH_MULTIPLATFORM.
This will effectively remove the errata options as platforms are
converted over to multi-platform.
Signed-off-by: Rob Herring <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Russell King <[email protected]>
As far as I understand, these are all boot time chicken bits that
should already be set up by the boot loader before entering the
kernel. Sebastian, are you aware of any particular machines that
ship without the workaround code in the bootloader or in secure
world?
Arnd
Hi,
On Fri, Dec 09, 2022 at 10:36:17PM +0100, Arnd Bergmann wrote:
> On Fri, Dec 9, 2022, at 19:45, Russell King (Oracle) wrote:
> > On Fri, Dec 09, 2022 at 07:20:00PM +0100, Sebastian Reichel wrote:
> >> All the erratas for more recent CPUs (Cortex A15/A12/A17) do not
> >> require !ARCH_MULTIPLATFORM, since there is runtime detection of
> >> effected CPUs in arch/arm/mm/proc-v7.S.
> >>
> >> Errata config options for the older Cortex A8/A9 CPUs have the
> >> !ARCH_MULTIPLATFORM dependency, but the CPUs are also runtime
> >> detected. Since there is runtime detection, it should be fine
> >> to enable the erratas for a multi platform kernel.
> >>
> >> Signed-off-by: Sebastian Reichel <[email protected]>
> >> ---
> >> For me the most likely explanation that this has not yet happened is
> >> me missing an important detail, so I sent it as RFC. If you point it
> >> out I will try to document the reason.
> >
> > IIRC, the reason these are marked with !ARCH_MULTIPLATFORM is for when
> > the kernel is running in the non-secure world - the accessed registers
> > may prevent platforms booting. However, it was a long time ago and I
> > don't remember clearly now.
>
> The git log confirms your memory, this is the description of
> commit 62e4d357aae0 ("ARM: 7609/1: disable errata work-arounds
> which access secure registers"):
>
> In order to support secure and non-secure platforms in multi-platform
> kernels, errata work-arounds that access secure only registers need to
> be disabled. Make all the errata options that fit in this category
> depend on !CONFIG_ARCH_MULTIPLATFORM.
>
> This will effectively remove the errata options as platforms are
> converted over to multi-platform.
>
> Signed-off-by: Rob Herring <[email protected]>
> Acked-by: Tony Lindgren <[email protected]>
> Signed-off-by: Russell King <[email protected]>
>
> As far as I understand, these are all boot time chicken bits that
> should already be set up by the boot loader before entering the
> kernel.
Ah, I should have spent more time in the git history instead of
trying to search the mailing list :( I will propose a patch adding
a sentence to the config option helptexts, so that one does not need
to go through the git history to understand the requirement and
correct solution:
This errata workaround requires access to secure registers and thus
is not available on multiplatform kernels. The workaround should be
applied by the bootloader instead.
> Sebastian, are you aware of any particular machines that ship
> without the workaround code in the bootloader or in secure world?
No. I'm investigating sporadic GPU hungs on i.MX6QP on a customer
device and just noticed a couple of erratas missing in the .config.
They might already be enabled in the bootloader (and otherwise
definitely can be enabled there).
Thanks for the fast feedback!
-- Sebastian