ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Subsystems (3)
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Cortex-A9 on at least BCM4708 SoCs are not LPAE capable, booting such a kernel will result in the following:
Error: Kernel with LPAE support, but CPU does not support LPAE.
Restrict such SoCs to be built in a configuration that does not enable ARM_LPAE.
--- arch/arm/mach-bcm/Kconfig | 1 + 1 file changed, 1 insertion(+)
arch/arm/mach-bcm/Kconfig +1 -0
@@ -38,6 +38,7 @@ config ARCH_BCM_CYGNUS config ARCH_BCM_5301X bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7 select ARCH_BCM_IPROC + depends on !ARM_LPAE help Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
Signature · 1 line
2.1.0
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Quoted 10 lines · On Tuesday 14 July 2015 11:12:15 Florian Fainelli wrote:
Cortex-A9 on at least BCM4708 SoCs are not LPAE capable, booting such a kernel will result in the following:
Error: Kernel with LPAE support, but CPU does not support LPAE.
Restrict such SoCs to be built in a configuration that does not enable
ARM_LPAE.Signed-off-by Florian Fainelli <[email protected]>
This is an old problem for all platforms, I think we want a more generic solution though, instead of adding the !LPAE dependency for each Cortex-A5/8/9 platform.
Arnd
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Quoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Tuesday 14 July 2015 11:12:15 Florian Fainelli wrote:
Cortex-A9 on at least BCM4708 SoCs are not LPAE capable, booting such a kernel will result in the following:
Error: Kernel with LPAE support, but CPU does not support LPAE.
Restrict such SoCs to be built in a configuration that does not enable
ARM_LPAE.
Quoted 6 lines
Quoted 2 lines
Signed-off-by Florian Fainelli <[email protected]>This is an old problem for all platforms, I think we want a more generic solution though, instead of adding the !LPAE dependency for each Cortex-A5/8/9 platform.
Fair enough, what do you have in mind? Should we introduce something like CONFIG_V7_A9 and such, and update all platforms to select such symbols such that we can then apply a restriction on other symbols if there needs to be?
What if any of these CPUs end-up supporting LPAE, but this cannot be flagged at build time?
Signature · 1 line
Florian
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Quoted 17 lines · On Tuesday 14 July 2015 14:29:31 Florian Fainelli wrote:
Quoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Tuesday 14 July 2015 11:12:15 Florian Fainelli wrote:
Cortex-A9 on at least BCM4708 SoCs are not LPAE capable, booting such a kernel will result in the following:
Error: Kernel with LPAE support, but CPU does not support LPAE.
Restrict such SoCs to be built in a configuration that does not enable
ARM_LPAE.Quoted 6 lines
Quoted 2 lines
Signed-off-by Florian Fainelli <[email protected]>This is an old problem for all platforms, I think we want a more generic solution though, instead of adding the !LPAE dependency for each Cortex-A5/8/9 platform.
Quoted 7 lines
Fair enough, what do you have in mind? Should we introduce something like
CONFIG_V7_A9and such, and update all platforms to select such symbols such that we can then apply a restriction on other symbols if there needs to be?What if any of these CPUs end-up supporting LPAE, but this cannot be flagged at build time?
I would introduce special architecture levels for ARMv7+LPAE and/or ARMv7VE. I am not entirely sure what combinations exist and whether it's enough to add ARMv7VE.
Basically, I think ARM_LPAE should only be selectable if ARMv7VE is the lowest architecture level that is enabled, and all ARMv7VE based platforms would have to be changed to depend on ARCH_MULTI_V7VE instead of ARCH_MULTI_V7.
Also, when building an ARMv7VE kernel, we really want to build with gcc -march=armv7ve (as long as that is available, possibly falling back to -mcpu=cortex-a15), so we build with the idiv instructions. The part I'm unclear about is whether there are CPU cores that support only idiv but not LPAE or vice versa. If there are, we need an extra level.
Arnd
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Quoted 35 lines · Arnd Bergmann
Quoted 17 lines · On Tuesday 14 July 2015 14:29:31 Florian Fainelli wrote:
Quoted 9 lines · Arnd Bergmann
Quoted 8 lines · On Tuesday 14 July 2015 11:12:15 Florian Fainelli wrote:
Cortex-A9 on at least BCM4708 SoCs are not LPAE capable, booting such a kernel will result in the following:
Error: Kernel with LPAE support, but CPU does not support LPAE.
Restrict such SoCs to be built in a configuration that does not enable
ARM_LPAE.Quoted 6 lines
Quoted 2 lines
Signed-off-by Florian Fainelli <[email protected]>This is an old problem for all platforms, I think we want a more generic solution though, instead of adding the !LPAE dependency for each Cortex-A5/8/9 platform.
Quoted 7 lines
Fair enough, what do you have in mind? Should we introduce something like
CONFIG_V7_A9and such, and update all platforms to select such symbols such that we can then apply a restriction on other symbols if there needs to be?What if any of these CPUs end-up supporting LPAE, but this cannot be flagged at build time?
I would introduce special architecture levels for ARMv7+LPAE and/or ARMv7VE. I am not entirely sure what combinations exist and whether it's enough to add ARMv7VE.
Basically, I think
ARM_LPAEshould only be selectable if ARMv7VE is the lowest architecture level that is enabled, and all ARMv7VE based platforms would have to be changed to depend onARCH_MULTI_V7VEinstead ofARCH_MULTI_V7.
Quoted 6 lines
Also, when building an ARMv7VE kernel, we really want to build with gcc -march=armv7ve (as long as that is available, possibly falling back to -mcpu=cortex-a15), so we build with the idiv instructions. The part I'm unclear about is whether there are CPU cores that support only idiv but not LPAE or vice versa. If there are, we need an extra level.
I like the idea in general, but I think this is going to be a very tedious job to collect every single CR values for ARMv7 processors to determine whether they are pure v7 or v7e... Maybe we could use kernelci.org to start extracting the relevant lines in bootlogs and people can start adding their own chips one by one?
Signature · 1 line
Florian
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Quoted 6 lines · On Wednesday 15 July 2015 09:38:52 Florian Fainelli wrote:
I like the idea in general, but I think this is going to be a very tedious job to collect every single CR values for ARMv7 processors to determine whether they are pure v7 or v7e... Maybe we could use kernelci.org to start extracting the relevant lines in bootlogs and people can start adding their own chips one by one?
No, we know most of them:
Cortex-A5, A8, A9: ARMv7, no LPAE, no IDIV Cortex-A7, A15, A12, A17: ARMv7VE, no LPAE, no IDIV
Almost everyone uses the above cores unmodified.
The ones I'm not 100% sure about are:
Marvell PJ4 (almost certainly ARMv7)
Marvell PJ4B (probably ARMv7 plus IDIV without LPAE) Qualcomm Scorpion (probably ARMv7)
Qualcomm Krait (probably ARMv7 plus IDIV without LPAE) Broadcom Brahma-B15 (almost certainly ARMv7VE)
We basically just need to find out from the mach-qcom and mach-mvebu maintainers what combination of LPAE and IDIV they need to support, and you can find out about B15.
If my list above is correct, there are no CPUs that have LPAE but don't have IDIV, and we just need to decide how to represent that.
Arnd
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Quoted 14 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 15 July 2015 09:38:52 Florian Fainelli wrote:
I like the idea in general, but I think this is going to be a very tedious job to collect every single CR values for ARMv7 processors to determine whether they are pure v7 or v7e... Maybe we could use kernelci.org to start extracting the relevant lines in bootlogs and people can start adding their own chips one by one?
No, we know most of them:
Cortex-A5, A8, A9: ARMv7, no LPAE, no IDIV Cortex-A7, A15, A12, A17: ARMv7VE, no LPAE, no IDIV
Quoted 6 lines
Almost everyone uses the above cores unmodified.
The ones I'm not 100% sure about are:
[...]
Broadcom Brahma-B15 (almost certainly ARMv7VE)
Confirmed, B15 is ARMv7VE.
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
In reply to Arnd BergmannQuoted 14 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 15 July 2015 09:38:52 Florian Fainelli wrote:
I like the idea in general, but I think this is going to be a very tedious job to collect every single CR values for ARMv7 processors to determine whether they are pure v7 or v7e... Maybe we could use kernelci.org to start extracting the relevant lines in bootlogs and people can start adding their own chips one by one?
No, we know most of them:
Cortex-A5, A8, A9: ARMv7, no LPAE, no IDIV Cortex-A7, A15, A12, A17: ARMv7VE, no LPAE, no IDIV
Quoted 6 lines
Almost everyone uses the above cores unmodified.
The ones I'm not 100% sure about are:
Marvell PJ4 (almost certainly ARMv7)
Marvell PJ4B (probably ARMv7 plus IDIV without LPAE)
Dove (PJ4B iirc):
Features : half thumb fastmult vfp edsp iwmmxt thumbee vfpv3
vfpv3d16 tls idivt
So, thumb-only idiv, no LPAE.
Quoted 3 lines
If my list above is correct, there are no CPUs that have LPAE but don't have IDIV, and we just need to decide how to represent that.
GCC ARMv7VE selects ARM idiv and Thumb idiv support, so you need to check for idiva and idivt support from the CPU, otherwise we're into even more Kconfig dependency hell trying to work out the dependencies for T2 kernel builds vs ARM kernel builds.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
PATCH 1/1 ARM: BCM: Restrict Broadcom BCM470X / BCM5301X to non-LPAE
Quoted 22 lines · On Wednesday 15 July 2015 22:00:44 Russell King - ARM Linux wrote:
Quoted 14 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 15 July 2015 09:38:52 Florian Fainelli wrote:
I like the idea in general, but I think this is going to be a very tedious job to collect every single CR values for ARMv7 processors to determine whether they are pure v7 or v7e... Maybe we could use kernelci.org to start extracting the relevant lines in bootlogs and people can start adding their own chips one by one?
No, we know most of them:
Cortex-A5, A8, A9: ARMv7, no LPAE, no IDIV Cortex-A7, A15, A12, A17: ARMv7VE, no LPAE, no IDIV
Quoted 6 lines
Almost everyone uses the above cores unmodified.
The ones I'm not 100% sure about are:
Marvell PJ4 (almost certainly ARMv7)
Marvell PJ4B (probably ARMv7 plus IDIV without LPAE)
Quoted 6 lines
Dove (PJ4B iirc):
Features : half thumb fastmult vfp edsp iwmmxt thumbee vfpv3
vfpv3d16 tls idivtSo, thumb-only idiv, no LPAE.
Oh, so potentially another level.
Quoted 8 lines
Quoted 3 lines
If my list above is correct, there are no CPUs that have LPAE but don't have IDIV, and we just need to decide how to represent that.
GCC ARMv7VE selects ARM idiv and Thumb idiv support, so you need to check for idiva and idivt support from the CPU, otherwise we're into even more
Kconfigdependency hell trying to work out the dependencies for T2 kernel builds vs ARM kernel builds.
An easy way out of course would be to ignore the idivt capability of PJ4B and always treat it as ARMv7 even when building a thumb2 based kernel.
The ARCH_MULTI_V* cpu level configuration we currently have is indeed too complicated already, and I've tried to come up with a way to simplify it.
The best idea I've had so far is to just use the global setting for picking the minimum level, and working out the supported platforms and features from there. Something along the lines of
choice
prompt "Minimum CPU Architecture level"
config ARM_MIN_V4
bool "ARMv4 based platforms (FA526)"
select ARCH_MULTI_V4
select ARCH_MULTI_V4T
select ARCH_MULTI_V5
...
config ARM_MIN_V6
bool "ARMv6 based platforms (ARM1136r0)" select ARCH_MULTI_V6
select ARCH_MULTI_V6K
select ARCH_MULTI_V7
select ARCH_MULTI_V7_IDIVT
select ARCH_MULTI_V7_IDIV
select ARCH_MULTI_V7VE # for lpae
select ARCH_MULTI_V8 # for crypto, maybe same as v7ve?
...
config ARM_MIN_V7_IDIV
bool "ARMv7 based platforms with integer divide" select ARCH_MULTI_V7_IDIV
select ARCH_MULTI_V7VE
select ARCH_MULTI_V8
...
endchoice
I think this would be able to cover all cases we are interested in, including future extensions. The main problem I couldn't solve is how to convert existing defconfigs and user configuration files without relying on users to pick the right option.
Arnd