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

["Bamvor Jian Zhang" <bjzhang@xxxxxxxx>]

Ian Campbell wrote:
> 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).
i will investigate it. do i have change to got other part of my patch ack
without this bootwrapper or u-boot support? 
> 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