diff mbox

ARM: vexpress: Remove virt and nonsec support for TC2

Message ID 1466606076.3026.30.camel@linaro.org
State New
Headers show

Commit Message

Jon Medhurst (Tixy) June 22, 2016, 2:34 p.m. UTC
When CPU's come out of reset they are in secure state supervisor mode,
so this is the state Linux kernel entry point is called in when it
brings up secondary CPU cores or the primary CPU restarts after power
management has sent it through an off/on transition.

As U-Boot starts the kernel in hypervisor mode and the kernel expects
and checks that CPUs start in the same state as initial boot this
results in a dead system. Specifically, it crashes early in boot when
the primary CPU runs the MCPM test [1] and even if power management
features are disabled it will still refuse to bring up any secondary
CPUs.

Fix this problem by removing U-Boot support for virt and nonsec
support on TC2.

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3592d7e002438980f9ce4a399f21ec94cbf071ea

Signed-off-by: Jon Medhurst <tixy@linaro.org>

---
 arch/arm/Kconfig                        |  2 --
 board/armltd/vexpress/vexpress_common.c | 15 ---------------
 2 files changed, 17 deletions(-)

-- 
2.1.4



_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Comments

Jon Medhurst (Tixy) June 22, 2016, 4:40 p.m. UTC | #1
On Wed, 2016-06-22 at 15:53 +0100, Andre Przywara wrote:
> Hi,

> 

> On 22/06/16 15:34, Jon Medhurst (Tixy) wrote:

> > When CPU's come out of reset they are in secure state supervisor mode,

> > so this is the state Linux kernel entry point is called in when it

> > brings up secondary CPU cores or the primary CPU restarts after power

> > management has sent it through an off/on transition.

> > 

> > As U-Boot starts the kernel in hypervisor mode and the kernel expects

> > and checks that CPUs start in the same state as initial boot this

> > results in a dead system. Specifically, it crashes early in boot when

> > the primary CPU runs the MCPM test [1] and even if power management

> > features are disabled it will still refuse to bring up any secondary

> > CPUs.

> > 

> > Fix this problem by removing U-Boot support for virt and nonsec

> > support on TC2.

> 

> So this disables any kind of virtualization support for TC2, which is a

> bit unfortunate.

> If I get this (and Sudeep's explanations) correctly, this new behaviour

> comes from the per-CPU-mailboxes setting in SCC 0x700, which is a

> setting in boot.txt on the uSD card.


Right, so I got the current U-Boot to boot Linux OK with all CPU's
coming up in hyp mode by:

- Clearing bits 12 and 13 in SCC 0x700 to disable per-cpu mailboxes and
  keep the secondary CPU powered up.

- Removing kernel configs
    CONFIG_ARCH_VEXPRESS_TC2_PM
    CONFIG_MCPM

I believe this works because the SCC change means that all CPU will be
running and waiting in the bootmonitor holding pen, from which they are
released when U-Boot calls smp_set_core_boot_addr. These secondary CPUs
then execute U-Boot code to switch to hypervisor mode, then enter a new
holding pen. (Running in RAM that can't get overwritten by Linux I hope!
)

Then when kernel boots and releases cores from holding pen they are in
hyp mode, like the main CPU. As we've also disabled power management in
the kernel, CPU's aren't ever powered down again and so stay in hyp
mode.

Actually, I just tried hotplugging a CPU which obviously the kernel
didn't like, so there is probably other kernel configs that need
tweaking to make things work.

> I wonder if we could make this virt/secure support a runtime decision

> then based on that register?

> So that a user can select whether she wants virtualisation or power

> management by changing the boot.txt setting and U-Boot transparently

> adapts to it, entering the kernel in either secure SVC or HYP.

>

> Does that make sense?

> I can look into a fix if this approach is fine.


Anything that gets U-Boot in it's default config working with vexpress
firmware and Linux kernel in their default config would be good
start :-)

I'm not sure that having an automatic selection in U-Boot is worth it,
given that anyone booting in hyp mode also needs to modify the firmware
and kernel configs to get things working. But I wouldn't object to such
an automatic selection either. After all, it's not like anyone really
uses or cares about this stuff, and if they are, they probably have
there own customised setup rather than using upstream defaults.

-- 
Tixy

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
diff mbox

Patch

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e9d2fc9..2e48568 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -293,8 +293,6 @@  config ARCH_BCM283X
 config TARGET_VEXPRESS_CA15_TC2
 	bool "Support vexpress_ca15_tc2"
 	select CPU_V7
-	select CPU_V7_HAS_NONSEC
-	select CPU_V7_HAS_VIRT
 
 config TARGET_VEXPRESS_CA5X2
 	bool "Support vexpress_ca5x2"
diff --git a/board/armltd/vexpress/vexpress_common.c b/board/armltd/vexpress/vexpress_common.c
index d3b3b31..fe5d163 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -180,18 +180,3 @@  void lowlevel_init(void)
 ulong get_board_rev(void){
 	return readl((u32 *)SYS_ID);
 }
-
-#ifdef CONFIG_ARMV7_NONSEC
-/* Setting the address at which secondary cores start from.
- * Versatile Express uses one address for all cores, so ignore corenr
- */
-void smp_set_core_boot_addr(unsigned long addr, int corenr)
-{
-	/* The SYSFLAGS register on VExpress needs to be cleared first
-	 * by writing to the next address, since any writes to the address
-	 * at offset 0 will only be ORed in
-	 */
-	writel(~0, CONFIG_SYSFLAGS_ADDR + 4);
-	writel(addr, CONFIG_SYSFLAGS_ADDR);
-}
-#endif