Re: [Xen-devel] [PATCH 4/4] xen/arm: enable switch to hyper mode for sun6i

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-05-31 at 20:53 +0800, Bamvor Jian Zhang wrote:
> Signed-off-by: Bamvor Jian Zhang <bjzhang@xxxxxxxx>
> ---
>  xen/arch/arm/arm32/mode_switch.S | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/mode_switch.S 
> b/xen/arch/arm/arm32/mode_switch.S
> index c92a1cf..0fc26e0 100644
> --- a/xen/arch/arm/arm32/mode_switch.S
> +++ b/xen/arch/arm/arm32/mode_switch.S
> @@ -21,6 +21,7 @@
>  #include <asm/page.h>
>  #include <asm/platforms/vexpress.h>
>  #include <asm/platforms/exynos5.h>
> +#include <asm/platforms/sun6i.h>
>  #include <asm/asm_defns.h>
>  #include <asm/gic.h>
>  
> @@ -90,15 +91,23 @@ enter_hyp_mode:

I'd really like to avoid adding more boards here. Accepting the Arndale
stuff was a pragmatic decision for the Xen 4.3 release but for 4.4 we
need to transition to something better and delete this file completely.

The way we want to fix this is to fix the bootloader, to correctly
launch kernels in NS HYP mode (Andre has patches to u-boot which I think
are upstream already) and to setup the GIC, timers etc for the specific
platform.

Updating the bootloader would be the ideal/preferred way to fix things
but in practice there will be cases where the bootloader cannot be fixed
e.g. because upstream u-boot does not support the platform well, or
because the methods for unbricking the board when things go wrong are
unavailable/unreliable. In those cases we want to remove this code from
Xen by using a boot-wrapper style shim like [0] or [1] which would run
between the bootloader and Xen and fix up all this sort of thing such
that it appears to Xen like it was loaded by a correct bootloader.

In this way we can maintain a clean separation between the main Xen code
base and the hacks required for initialisation on a specific platform.

Of course the bootwrapper can hardcode all sorts of system specific
stuff since it will be expected to be compiled for the specific
platform.

I don't know which one applies to the sun6i platform -- it looks to me
like upstream u-boot support is well under way and the presence of FEL
mode makes unbricking the system pretty easy (I've had to use it on my
own A31 based tablet and it seems OK).

Ian.

[0] http://xenbits.xen.org/gitweb/?p=people/ianc/boot-wrapper.git;a=summary
[1] https://git.linaro.org/gitweb?p=arm/models/boot-wrapper.git;a=summary


>          bic   r0, r0, #0xe           /* Clear EA, FIQ and IRQ */
>          mcr   CP32(r0, SCR)
>  
> -        ldr   r2, =MACH_TYPE_SMDK5250   /* r4 := Arndale machine ID */
>          /* By default load Arndale defaults values */
> +        ldr   r2, =MACH_TYPE_SMDK5250   /* r4 := Arndale machine ID */
>          ldr   r0, =EXYNOS5_TIMER_FREQUENCY  /* r0 := timer's frequency */
>          ldr   r1, =EXYNOS5_GIC_BASE_ADDRESS /* r1 := GIC base address */
> -        /* If it's not the Arndale machine ID, load VE values */
>          teq   r5, r2
> +        beq   board_set_done
> +        /* If it's not the Arndale machine ID, try sun6i */
> +        ldr   r2, =MACH_TYPE_SUN6I          /* r2 := sun6i machine ID */
> +        ldr   r0, =SUN6I_TIMER_FREQUENCY    /* r0 := timer's frequency */
> +        ldr   r1, =SUN6I_GIC_BASE_ADDRESS   /* r1 := GIC base address */
> +        teq   r5, r2
> +        beq   board_set_done
> +        /* If it's not the sun6i machine ID, load VE values */
>          ldrne r0, =V2M_TIMER_FREQUENCY
>          ldrne r1, =V2M_GIC_BASE_ADDRESS
>  
> +board_set_done:
>          /* Ugly: the system timer's frequency register is only
>           * programmable in Secure state.  Since we don't know where its
>           * memory-mapped control registers live, we can't find out the



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel