diff mbox

hw/arm/boot: Set PC correctly when loading AArch64 ELF files

Message ID 1406301817-20766-1-git-send-email-peter.maydell@linaro.org
State New
Headers show

Commit Message

Peter Maydell July 25, 2014, 3:23 p.m. UTC
The code in do_cpu_reset() correctly handled AArch64 CPUs
when running Linux kernels, but was missing code in the
branch of the if() that deals with loading ELF files.
Correctly jump to the ELF entry point on reset rather than
leaving the reset PC at zero.

Reported-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-stable@nongnu.org
---
 hw/arm/boot.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Comments

Christopher Covington July 25, 2014, 4:09 p.m. UTC | #1
On 07/25/2014 11:23 AM, Peter Maydell wrote:
> The code in do_cpu_reset() correctly handled AArch64 CPUs
> when running Linux kernels, but was missing code in the
> branch of the if() that deals with loading ELF files.
> Correctly jump to the ELF entry point on reset rather than
> leaving the reset PC at zero.

Thanks Peter! With this patch I can see the first few instructions being executed.

Tested-by: Christopher Covington <cov@codeaurora.org>

(The default Newlib/libgloss wants to touch EL3 registers that QEMU doesn't
yet have, but I can probably make my test case work with -nostdlib.)

Thanks,
Christopher
Richard Henderson July 29, 2014, 7:25 p.m. UTC | #2
On 07/25/2014 05:23 AM, Peter Maydell wrote:
> +                env->regs[15] = info->entry & 0xfffffffe;

You'd do well to use a U suffix here, otherwise c89 makes this -2 while c99
does what you want.  Which makes a tiny difference on a 64-bit host.


r~
Peter Maydell July 29, 2014, 7:31 p.m. UTC | #3
On 29 July 2014 20:25, Richard Henderson <rth@twiddle.net> wrote:
> On 07/25/2014 05:23 AM, Peter Maydell wrote:
>> +                env->regs[15] = info->entry & 0xfffffffe;
>
> You'd do well to use a U suffix here, otherwise c89 makes this -2 while c99
> does what you want.  Which makes a tiny difference on a 64-bit host.

Given that env->regs[] is uint32_t, does it actually change the final
result? I agree that a U suffix would be a good idea, but given that
the code has been that way since 2009 it seems unlikely that we've
actually got breakage from it...

thanks
-- PMM
Richard Henderson July 29, 2014, 7:57 p.m. UTC | #4
On 07/29/2014 09:31 AM, Peter Maydell wrote:
> Given that env->regs[] is uint32_t, does it actually change the final
> result? 

Ah, no.  I mis-remembered regs and xregs being shared.


r~
diff mbox

Patch

diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 3d1f4a2..1241761 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -417,8 +417,12 @@  static void do_cpu_reset(void *opaque)
     if (info) {
         if (!info->is_linux) {
             /* Jump to the entry point.  */
-            env->regs[15] = info->entry & 0xfffffffe;
-            env->thumb = info->entry & 1;
+            if (env->aarch64) {
+                env->pc = info->entry;
+            } else {
+                env->regs[15] = info->entry & 0xfffffffe;
+                env->thumb = info->entry & 1;
+            }
         } else {
             if (CPU(cpu) == first_cpu) {
                 if (env->aarch64) {