Re: [Question] Verification For arm64: suspend/resume implementation

[Leo Yan <leoy@marvell.com>]

On 09/27/2013 12:53 AM, Catalin Marinas wrote:
> On Thu, Sep 26, 2013 at 12:12:53PM +0100, Leo Yan wrote:
>> On 09/24/2013 09:00 PM, Catalin Marinas wrote:
>>> On Tue, Sep 24, 2013 at 12:49:33PM +0100, Leo Yan wrote:
>>>> On 09/24/2013 05:02 PM, Achin Gupta wrote:
>>>>> On Tue, Sep 24, 2013 at 03:00:38AM +0100, Leo Yan wrote:
>>>>>> Here have another question, ARM have the example code for boot wrapper
>>>>>> which will switch from EL3 to secure EL1 rather than non-secure's EL1?
>>>>>
>>>>> I dont' think we do but let me check. Switching to S-EL1 instead of
>>>>> NS-EL1 should be a matter of _not_ setting the SCR_EL3.NS bit before
>>>>> doing the exception level change (ERET).
>>>>
>>>> I quick try with below patch for boot wrapper, i saw foundataion model
>>>> cannot boot up successfully and there have no console output; suppose
>>>> it's hang at some boot operations, but now foundation model cannot debug
>>>> low level code, so i cannot debug further more. :-(
>>>>
>>>> diff --git a/boot.S b/boot.S
>>>> index a1f25e2..2f1b867 100644
>>>> --- a/boot.S
>>>> +++ b/boot.S
>>>> @@ -19,7 +19,6 @@ _start:
>>>>            b.ne    start_ns                        // skip EL3 initialisation
>>>>
>>>>            mov     x0, #0x30                       // RES1
>>>> -       orr     x0, x0, #(1 << 0)               // Non-secure EL1
>>>>            orr     x0, x0, #(1 << 8)               // HVC enable
>>>>            orr     x0, x0, #(1 << 10)              // 64-bit EL2
>>>>            msr     scr_el3, x0
>>>
>>> You also need to make sure the boot wrapper starts the kernel in S-EL1
>>> rather than NS-EL2.
>>
>> I tried to use below modification, but it still failed to boot up on
>> foundation model; pls help review if convienence.
>
> You probably need group 0 interrupts as well.

Thanks a lot for help. After change the IRQs to group 0, then kernel can 
work well in S-EL1. :-)

diff --git a/boot.S b/boot.S
index a1f25e2..ae14c66 100644
--- a/boot.S
+++ b/boot.S
@@ -19,7 +19,6 @@ _start:
         b.ne    start_ns                        // skip EL3 initialisation

         mov     x0, #0x30                       // RES1
-       orr     x0, x0, #(1 << 0)               // Non-secure EL1
         orr     x0, x0, #(1 << 8)               // HVC enable
         orr     x0, x0, #(1 << 10)              // 64-bit EL2
         msr     scr_el3, x0
@@ -42,7 +41,7 @@ _start:
         str     w0, [x1]

  1:     ldr     x1, =GIC_DIST_BASE + 0x80       // GICD_IGROUPR
-       mov     w0, #~0                         // Grp1 interrupts
+       mov     w0, #0                          // Grp0 interrupts
         str     w0, [x1], #4
         b.ne    2f                              // Only local 
interrupts for secondary CPUs
         str     w0, [x1], #4
@@ -62,7 +61,7 @@ _start:
          * Prepare the switch to the EL2_SP1 mode from EL3
          */
         ldr     x0, =start_ns                   // Return after mode switch
-       mov     x1, #0x3c9                      // EL2_SP1 | D | A | I | F
+       mov     x1, #0x3c5                      // EL1_SP1 | D | A | I | F
         msr     elr_el3, x0
         msr     spsr_el3, x1
         eret

>>> BTW, why do you need this? There are no virtualisation features
>>> supported on the secure side.
>>
>> So far the virtualisation is not a mandatory feature in short term due
>> now our product is mainly focusing on the mobile product, so firstly we
>> want to enable Linux kernel directly on secure world; just like we do
>> same as ARMv7.
>
> But is there other reason than just being the same as on your ARMv7
> platform?
>
> Apart from virtualisation, there are other Linux developments that
> assume Linux running in non-secure mode (SMMU, future GIC). I *strongly*
> recommend that you run AArch64 Linux in non-secure mode from start (and
> for the early bring-up, just configure your hardware to allow non-secure
> access to all your peripherals/registers).
>

I have no such whole picture as you arm guys for ARMv8 and related 
features; this is also what i have concern if here have show stopper 
issue if kernel run in S-EL1. So thanks for the reminding and more 
detailed info will always be welcomed.

After the generic firmware has been opened and we get the code, then we 
will study it carefully and estimate how to deploy it.

Thx,
Leo Yan