From: Tushar Behera <tushar.behera@linaro.org>
To: Julien Grall <julien.grall@linaro.org>,
HyonYoung Choi <commani@gmail.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Meng Xu <xumengpanda@gmail.com>,
Ian Campbell <ian.campbell@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, 29 Apr 2014 08:48:24 +0530 [thread overview]
Message-ID: <535F1A00.2030606@linaro.org> (raw)
In-Reply-To: <53567815.7060609@linaro.org>
On 04/22/2014 07:39 PM, Julien Grall wrote:
> 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.
>
The u-boot code was referenced from following git tree[1]. I have little
knowledge regarding Hypervisor mode support, so won't be of much help :(
[1] http://git.insignal.co.kr/insignal/arndale_octa-jb_mr1.1/u-boot
>> 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,
>
--
Tushar Behera
prev parent reply other threads:[~2014-04-29 3:18 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
2014-04-29 3:18 ` Tushar Behera
2014-04-29 3:18 ` Tushar Behera [this message]
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=535F1A00.2030606@linaro.org \
--to=tushar.behera@linaro.org \
--cc=commani@gmail.com \
--cc=ian.campbell@citrix.com \
--cc=julien.grall@linaro.org \
--cc=stefano.stabellini@eu.citrix.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.