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 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).