linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: Kexec on arm64
Date: Mon, 28 Jul 2014 16:38:12 +0100	[thread overview]
Message-ID: <20140728153812.GA2576@leverpostej> (raw)
In-Reply-To: <CAFdej014ohCFYvoUAXWiYGb4_4UmSY2G1MH-NEE_cF1cC-6Mow@mail.gmail.com>

On Mon, Jul 28, 2014 at 04:00:18PM +0100, Arun Chandran wrote:
> Hi Geoff
> 
> On Sat, Jul 26, 2014 at 5:48 AM, Geoff Levand <geoff@infradead.org> wrote:
> > Hi Arun,
> >
> > On Fri, 2014-07-25 at 17:18 +0530, Arun Chandran wrote:
> >> I got this working. As 'Mark Rutland' pointed in another mail that
> >> it could be problem with flushing the cache; I did a read of
> >> 1GB data from start of RAM to a volatile var. I assume that
> >> this will clear and invalidate all that in cache (L1=32K, L2=256 K, L3=8M)
> >
> > I wasn't flushing out all the data used by relocate_new_kernel.  I added
> > a routine that should flush all the pages in the kimage list out to PoC.
> > Please try a UP build with L3 enabled.
> >
> 
> Yes I verified this new kernel by stopping just before jumping to the
> kexeced kernel and taking the memory dump for the kernel
> and dtb.
> 
> CPU#0>dump 0x0000004000080000 0x7F2000 uImage
> CPU#0>rd
> GPR00: 0000004000880000 0000000000000000 0000000000000000 0000000000000000
> GPR04: 0000004000080004 000000000000001b 0000000000000000 ffffffffffffffff
> GPR08: 0000000000000020 ffffffffffffffff 0000000000000004 0000000000000002
> GPR12: 00000043ea439fd8 0000004000883000 00000043ea631000 ffffffffffffffff
> GPR16: ffffffc0000cc31c 0000000000435260 0000007fe9328b90 00000043eaddc002
> GPR20: 0000004000883000 00000043ea632000 0000000000000000 0000000000000000
> GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR28: 0000000000000000 0000000000000000 ffffffc000085074 ffffffc3eae53d00
> 
> And compared this image with the one taken after booting with
> my working one(The one with 1GB read of RAM). Both are Identical.
> That means kexec code now flushes data properly. Note that in both
> cases I used the same secondary kernel.
> 
> But It fails to boot kexeced kernel. If I break the target I can see
> CPU#0>h
>     Core number       : 0
>     Core state        : debug (AArch64 EL1)
>     Debug entry cause : External Debug Request
>     Current PC        : 0xffffffc000083200
>     Current CPSR      : 0x600003c5 (EL1h)
> 
> 
> So I guess there may be something wrong with
> the booting of kernel.
> 
> I have these changes to the code.
> 1)
> #########
> diff --git a/arch/arm64/kernel/machine_kexec.c
> b/arch/arm64/kernel/machine_kexec.c
> index 00cfbd6..da3672b 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -684,7 +691,7 @@ void machine_kexec(struct kimage *image)
>         /* Flush the reboot_code_buffer in preparation for its execution. */
> 
>         flush_icache_range((unsigned long)reboot_code_buffer,
> -               relocate_new_kernel_size);
> +               (unsigned long)(reboot_code_buffer + relocate_new_kernel_size));
> 
>         /*
>          * Flush any data used by relocate_new_kernel in preparation for
> #########
> Passing of second variable to flush_icache_range() is wrong
> it expects an address not length.

A simpler option would be to nuke the entire icache before branching to
the new image.

> 
> 2)
> 
> #######
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 9ed7327..e3fc8d6 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> 
> @@ -84,12 +91,17 @@ void soft_restart(unsigned long addr)
>  {
>         typedef void (*phys_reset_t)(unsigned long);
>         phys_reset_t phys_reset;
> +       unsigned long jump_addr = addr;
> +
> +       phys_reset = (phys_reset_t)virt_to_phys(cpu_reset);
> +
> +       __flush_dcache_area(&jump_addr, 8);
> +       __flush_dcache_area(&phys_reset, 8);

Are these values really not getting stashed in registers?

If the compiler is spilling, then we have absolutely no guarantee about
any part of the stack. If that's the case, then we can't use the stack
at all. These need to be rewritten in asm if the compiler is spilling.

Thanks,
Mark.

> 
>         setup_restart();
> 
>         /* Switch to the identity mapping */
> -       phys_reset = (phys_reset_t)virt_to_phys(cpu_reset);
> -       phys_reset(addr);
> +       phys_reset(jump_addr);
> 
>         /* Should never get here */
>         BUG();
> ########
> 
> Without this flushing it will jump to wrong addr.
> 
> --Arun
> 

  reply	other threads:[~2014-07-28 15:38 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFdej006OSyhgDcJ2iZdbjt+PtysN=i_+9Dr4GTmr=+t5yg4Kw@mail.gmail.com>
2014-07-15 17:04 ` Kexec on arm64 Geoff Levand
2014-07-16 17:57   ` Feng Kan
2014-07-16 23:04     ` Geoff Levand
2014-07-22  9:44       ` Arun Chandran
2014-07-22 13:25         ` Arun Chandran
2014-07-24  0:38           ` Geoff Levand
2014-07-24  9:36             ` Mark Rutland
2014-07-24 12:49               ` Arun Chandran
2014-07-25  0:17               ` Geoff Levand
2014-07-25 10:31                 ` Arun Chandran
2014-07-25 10:36                 ` Mark Rutland
2014-07-25 11:48                 ` Arun Chandran
2014-07-25 12:14                   ` Mark Rutland
2014-07-25 15:29                     ` Arun Chandran
2014-07-26  0:18                   ` Geoff Levand
2014-07-28 15:00                     ` Arun Chandran
2014-07-28 15:38                       ` Mark Rutland [this message]
2014-07-29  0:09                         ` Geoff Levand
2014-07-29  9:10                           ` Mark Rutland
2014-07-29 12:32                           ` Arun Chandran
2014-07-29 13:35                             ` Mark Rutland
2014-07-29 21:19                               ` Geoff Levand
2014-07-30  7:22                                 ` Arun Chandran
2014-08-01 11:13                                   ` Arun Chandran
2014-08-03 14:47                                     ` Mark Rutland
2014-08-04 10:16                                   ` Arun Chandran
2014-08-04 11:35                                     ` Mark Rutland
2014-08-07  0:40                                       ` Geoff Levand
2014-08-07  9:59                                         ` Mark Rutland
2014-08-07 17:09                                           ` Geoff Levand
2014-08-04 17:21                                     ` Geoff Levand
2014-08-06 13:54                                       ` Arun Chandran
2014-08-06 15:51                                         ` Arun Chandran
2014-08-07 20:07                                         ` Geoff Levand
2014-08-08  5:46                                           ` Arun Chandran
2014-08-08 10:03                                             ` Arun Chandran
2014-08-12  5:42                                               ` Arun Chandran
2014-08-13 11:09                                                 ` Arun Chandran
2014-08-26 22:32                                                   ` Geoff Levand
2014-08-27  4:56                                                     ` Arun Chandran
2014-07-30  5:46                               ` Arun Chandran
2014-07-30  9:16                                 ` Mark Rutland
2014-07-30  7:01                               ` Arun Chandran
2014-07-25 10:26               ` Arun Chandran
2014-07-25 11:29                 ` Mark Rutland
2014-07-24 11:50             ` Arun Chandran
2014-07-30  3:26           ` Feng Kan
2014-07-24  0:10         ` Geoff Levand
2014-07-24  9:13         ` Mark Rutland

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=20140728153812.GA2576@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).