ARM: various boot-time tidying

# HG changeset patch
# User Tim Deegan <[email protected]>
# Date 1338482127 -3600
# Node ID 05447f395c91029fb732142e36788cfa92374045 # Parent 25d389d891c5a2a3009258ef7261379a9ad97746
arm: Move hyp-mode entry code out of line.

This code is grottier than the rest of the start-of-day code and very specific to the software model we're developing on. Segregate it accordingly, by putting it in its own file.

Quoted 7 lines · Tim Deegan

# HG changeset patch
# User Tim Deegan <[email protected]>
# Date 1338482127 -3600
# Node ID 05447f395c91029fb732142e36788cfa92374045 # Parent 25d389d891c5a2a3009258ef7261379a9ad97746
arm: Move hyp-mode entry code out of line.

Quoted 3 lines

This code is grottier than the rest of the start-of-day code and very specific to the software model we're developing on. Segregate it accordingly, by putting it in its own file.

I've been vaguely thinking about writing a stub-bootloader to do this and provide the DTB (instead of having to link it with Xen). Is this something that would be useful?

# HG changeset patch
# User Tim Deegan <[email protected]>
# Date 1338482127 -3600
# Node ID 8656509f24ea8b17d1c2dabd67c710662f66d17f # Parent 05447f395c91029fb732142e36788cfa92374045
arm: avoid memory write in switch to Hyp mode.

Assemble the new CPSR in registers instead. It's slightly cleaner, And makes it possible to have a read-only text section.

Signed-off-by Tim Deegan <[email protected]>

diff -r 05447f395c91 -r 8656509f24ea xen/arch/arm/mode_switch.S

xen/arch/arm/mode_switch.S +0 -1

@@ -66,11 +66,7 @@ enter_hyp_mode:
 	mcr   CP32(r0, FCSEIDR)
 	mcr   CP32(r0, CONTEXTIDR)
 	/* FIXME: ought to reset some other NS control regs here */
-	adr   r1, 1f                 /* Store return address */

xen/arch/arm/mode_switch.S +1 -0

+	movs  pc, r3                 /* Exception-return into Hyp mode */

xen/arch/arm/mode_switch.S enter_hyp_mode: · line 71

Quoted 3 lines

xen/arch/arm/mode_switch.S +3 -0

+	mrs   r0, cpsr               /* Copy the CPSR */
+	add   r0, r0, #0x4           /* 0x16 (Monitor) -> 0x1a (Hyp) */
+	msr   spsr_cxsf, r0          /* into the SPSR */

Not that it matters much but I think this could have been sprs_c to just update spsr[0:7] (which is all you wanted to touch). In fact I reckon you could have just done:

	mov r0, #0x1a|SPSR_I|SPSR_F
	msr spsr_c, r0

# HG changeset patch
# User Tim Deegan <[email protected]>
# Date 1338482127 -3600
# Node ID d12d5fcf152bffda41de51f9919b3211d69f955b # Parent 9570c43c07f397d8d4a8e725698c17c10c034d80
arm: Enable VFP at boot.

xen/arch/arm/Rules.mk +0 -0

 # Require GCC v3.4+ (to avoid issues with alignment constraints in Xen headers)
 check-$(gcc) = $(call cc-ver-check,CC,0x030400,"Xen requires at least gcc-3.4")

diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/setup.c

xen/arch/arm/setup.c +3 -0

@@ -36,6 +36,7 @@
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>
+#include <asm/vfp.h>
 #include "gic.h"
 
 static __attribute_used__ void init_done(void)

@@ -192,6 +193,8 @@ void __init start_xen(unsigned long boot
 
     processor_id();
 
+    enable_vfp();
+
     softirq_init();
 
     tasklet_subsys_init();

diff -r 9570c43c07f3 -r d12d5fcf152b xen/arch/arm/smpboot.c

xen/arch/arm/smpboot.c +3 -0

@@ -26,6 +26,7 @@
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/softirq.h>
+#include <asm/vfp.h>
 #include "gic.h"
 
 cpumask_t cpu_online_map;

@@ -106,6 +107,8 @@ void __cpuinit start_secondary(unsigned 
     WRITE_CP32((uint32_t) hyp_traps_vector, HVBAR);
 
     mmu_init_secondary_cpu();
+    enable_vfp();
+
     gic_init_secondary_cpu();
     init_timer_interrupt();
     gic_route_irqs();

diff -r 9570c43c07f3 -r d12d5fcf152b xen/include/asm-arm/vfp.h

xen/include/asm-arm/vfp.h new file +35 -0

@@ -0,0 +1,35 @@
+#ifndef __ARM_VFP_H_
+#define __ARM_VFP_H_
+
+#include <xen/types.h>
+
+#define FPEXC_EN (1u << 30)
+
+/* Save and restore FP state.
+ * Ought to be using the new vmrs/vmsr names, but older binutils has a
+ * bug where it only allows them to target fpscr (and not, say, fpexc). */
+#define READ_FP(reg) ({                                 \
+    uint32_t val;                                       \
+    asm volatile ("fmrx %0, fp" #reg : "=r" (val));     \
+    val; })
+
+#define WRITE_FP(reg, val) do {                         \
+    asm volatile ("fmxr fp" #reg ", %0" : : "r" (val)); \
+} while (0)
+
+
+/* Start-of-day: Turn on VFP */
+static inline void enable_vfp(void)
+{
+    WRITE_FP(exc, READ_FP(exc) | FPEXC_EN);
+}
+
+#endif
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

xen/arch/arm/Rules.mk ifneq ($(call cc-option,$(CC),-fvisibili · line 27

Quoted 2 lines

xen/arch/arm/Rules.mk +1 -1

-CFLAGS += -march=armv7-a -mcpu=cortex-a15
+CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp

This might have been worthy of a comment...

http://wiki.debian.org/ArmHardFloatPort has some discussion, including:
* soft: Full software floating point.
* softfp: Use the FPU, but remain compatible with soft-float code.
* hard: Full hardware floating point.

and "The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4". (there's a reference to a TODO section which seems to not exist anymore...). I think Debian's armhf does actually use hard (the page seems to imply it)

Anyway softfp does seem like the right option, at least until -mfloat-abi=hard. Since this is all internal to the hypervisor (guests can do whatever they want, I'm happily running armhf binaries) I don't think this is a big deal to change as and when the compiler will let us.

Quoted 4 lines · Ian Campbell

xen/arch/arm/Rules.mk ifneq ($(call cc-option,$(CC),-fvisibili · line 27

Quoted 2 lines

xen/arch/arm/Rules.mk +1 -1

-CFLAGS += -march=armv7-a -mcpu=cortex-a15
+CFLAGS += -march=armv7-a -mcpu=cortex-a15 -mfpu=vfpv3 -mfloat-abi=softfp

This might have been worthy of a comment...

Ah, yes it might. Would you like me to add one and resubmit?

If I get time next week I'm going to look at VFP context switching; at that point I might move all the VFP code into its own .c or .S file and enable the fpu instructions just there, to be sure that gcc doesn't start using the VFP registers in normal Xen code -- it will do that for integer arithmetic with -mfpu=neon, for example. OTOH it might be OK to do that as long as there are no caller-save VFP registers; I'll have a look at the calling conventions and see what can be done.

These patches tinker with the ARM boot a little bit. They shouldn't clash with any of the other ARM work going on, since they only touch very early code.