xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: HyonYoung Choi <commani@gmail.com>
Cc: Tushar Behera <tushar.behera@linaro.org>,
	Meng Xu <xumengpanda@gmail.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: undefined instruction error during HYP mode switch for arndale-octa board
Date: Tue, 22 Apr 2014 15:09:25 +0100	[thread overview]
Message-ID: <53567815.7060609@linaro.org> (raw)
In-Reply-To: <CAFpecnSnsjvPZ-HKh=TE8tPjC9ZXpkX_B0SvRNt=ki0qggXDoA@mail.gmail.com>

On 04/22/2014 12:11 AM, HyonYoung Choi wrote:
> Hello Julien,

Hello HyonYoung,

> At first, I want to know who is the maintainer for this U-Boot or
> Hypervisor mode support section.

I'm not sure who is the maintainer of this U-boot. I've cced Tushar
which seems to be in most of the commit related to the octa.

> From previous email, I found that U-boot is running already in
> non-secure mode.
> 
> From the comment of the erroneous code in arch/arm/cpu/armv7/nonsec_vert.S, 
> it is guessed that it tries to switch non-secure mode assuming the CPU
> is in secure mode.
> ========================================
> /*
>  * Switch a core to non-secure state.
>  *
>  *  1. initialize the GIC per-core interface
>  *  2. allow coprocessor access in non-secure modes
>  *  3. switch the cpu mode (by calling "smc #0")
>  *
>  * Called from smp_pen by secondary cores and directly by the BSP.
>  * Do not assume that the stack is available and only use registers
>  * r0-r3 and r12.
>  *
>  * PERIPHBASE is used to get the GIC address. This could be 40 bits long,
>  * though, but we check this in C before calling this function.
>  */
> ENTRY(_nonsec_init)
> =========================================
> 
> But I have known CPU is already in non-secure mode, 
> so, we commented out the calling _nonsec_init() and
> just call hypervisor mode switch function only as below:
> 
> =========================================
> static void do_nonsec_virt_switch(void)
> {
> #if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
> //      if (armv7_switch_nonsec() == 0)
> #ifdef CONFIG_ARMV7_VIRT
>                 if (armv7_switch_hyp() == 0)
>                         debug("entered HYP mode\n");
> #else
>                 debug("entered non-secure state\n");
> #endif
> #endif
> }
> =========================================
> 
> The code of function armv7_switch_hyp() is simple:
> =========================================
> ENTRY(_switch_to_hyp)
>         mov     r0, lr
>         mov     r1, sp                          @ save SVC copy of LR and SP
>         isb
>         hvc #0                   @ for older asm: .byte 0x70, 0x00,
> 0x40, 0xe1
>         mov     sp, r1
>         mov     lr, r0                          @ restore SVC copy of LR
> and SP
>         bx      lr
> ENDPROC(_switch_to_hyp)
> ===========================================
> 
> But it hangs while booting in "hvc #0" instruction.
> 
> ----------------------------------------------------------------------
> ## Booting kernel from Legacy Image at 20007000 ...
>    Image Name:   
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    656144 Bytes = 640.8 KiB
>    Load Address: 20008000
>    Entry Point:  20008000
>    Verifying Checksum ... OK
> ## Flattened Device Tree blob at 21f00000
>    Booting using the fdt blob at 0x21f00000
>    Loading Kernel Image ... OK
> OK
>    reserving fdt memory region: addr=21f00000 size=8000
>    Using Device Tree in place at 21f00000, end 21f0afff
>   switch_hyp: CPU supports virt ext
> ----------------------------------------------------------------------
> 
> From the original sequence of function calls,
> nonsec_init() is for turning to non-secure mode,
> then it calls switch_to_hyp () in non-secure mode.
> 
> Is there any preparation for executing "hvc" instruction or any
> privilege to be executed?

You've commented the function armv7_switch_nonsec that set up the
monitors traps (and therefore the hyp trap). The "hvc #0" instruction
will jump to an unknown memory.

Regards,

-- 
Julien Grall

  reply	other threads:[~2014-04-22 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-18 21:26 undefined instruction error during HYP mode switch for arndale-octa board HyonYoung Choi
2014-04-21 12:39 ` Julien Grall
2014-04-21 23:11   ` HyonYoung Choi
2014-04-22 14:09     ` Julien Grall [this message]
2014-04-29  3:18       ` Tushar Behera
2014-04-29  3:18       ` Tushar Behera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53567815.7060609@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=commani@gmail.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tushar.behera@linaro.org \
    --cc=xen-devel@lists.xen.org \
    --cc=xumengpanda@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).