All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: "Suzuki K. Poulose" <suzuki@in.ibm.com>
Cc: Matthew McClintock <msm@freescale.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] kexec/ppc: Fix kernel program entry point while changing the load addr
Date: Tue, 5 Mar 2013 10:40:44 +0900	[thread overview]
Message-ID: <20130305014043.GD16128@verge.net.au> (raw)
In-Reply-To: <51343788.7070503@in.ibm.com>

On Mon, Mar 04, 2013 at 11:26:24AM +0530, Suzuki K. Poulose wrote:
> On 03/04/2013 07:11 AM, Simon Horman wrote:
> >[ Cc: linuxppc-dev@lists.ozlabs.org ]
> >
> >On Sun, Mar 03, 2013 at 01:06:00PM +0530, Suzuki K. Poulose wrote:
> >>From: Suzuki K. Poulose <suzuki@in.ibm.com>
> >>
> >>uImage probe fills the entry point (ep) based on the load_addr
> >>from the uImage headers. If we change the load_addr, we should
> >>accordingly update the entry point.
> >>
> >>For ELF, calculate the offset of e_entry from the virtual start
> >>address and add it to the physical start address to find the
> >>physical address of kernel entry.
> >>
> >>i.e,
> >>   pa (e_entry) = pa(phdr[0].p_vaddr) + (e_entry - phdr[0].p_vaddr)
> >>                = kernel_addr + (e_entry - phdr[0].p_vaddr)
> >
> >Would it be possible for someone to provide a review of this change?
> To make it bit more clear :
> 
> The entry point of the kernel is usually at 0 offset from the first
> PT_LOAD section. The current code makes this assumption and uses the
> pa(phdr[0].p_vaddr) as the kernel entry.
> 
> But this *may* not be true always, in such a case the kexec would fail.
> While I fixed the uImage case, I thought it would be better to
> handle the same case in ELF.
> 
> Btw, this calculation is not specific to ppc32.

Thanks, I have applied the patch.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@verge.net.au>
To: "Suzuki K. Poulose" <suzuki@in.ibm.com>
Cc: Matthew McClintock <msm@freescale.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] kexec/ppc: Fix kernel program entry point while changing the load addr
Date: Tue, 5 Mar 2013 10:40:44 +0900	[thread overview]
Message-ID: <20130305014043.GD16128@verge.net.au> (raw)
In-Reply-To: <51343788.7070503@in.ibm.com>

On Mon, Mar 04, 2013 at 11:26:24AM +0530, Suzuki K. Poulose wrote:
> On 03/04/2013 07:11 AM, Simon Horman wrote:
> >[ Cc: linuxppc-dev@lists.ozlabs.org ]
> >
> >On Sun, Mar 03, 2013 at 01:06:00PM +0530, Suzuki K. Poulose wrote:
> >>From: Suzuki K. Poulose <suzuki@in.ibm.com>
> >>
> >>uImage probe fills the entry point (ep) based on the load_addr
> >>from the uImage headers. If we change the load_addr, we should
> >>accordingly update the entry point.
> >>
> >>For ELF, calculate the offset of e_entry from the virtual start
> >>address and add it to the physical start address to find the
> >>physical address of kernel entry.
> >>
> >>i.e,
> >>   pa (e_entry) = pa(phdr[0].p_vaddr) + (e_entry - phdr[0].p_vaddr)
> >>                = kernel_addr + (e_entry - phdr[0].p_vaddr)
> >
> >Would it be possible for someone to provide a review of this change?
> To make it bit more clear :
> 
> The entry point of the kernel is usually at 0 offset from the first
> PT_LOAD section. The current code makes this assumption and uses the
> pa(phdr[0].p_vaddr) as the kernel entry.
> 
> But this *may* not be true always, in such a case the kexec would fail.
> While I fixed the uImage case, I thought it would be better to
> handle the same case in ELF.
> 
> Btw, this calculation is not specific to ppc32.

Thanks, I have applied the patch.

  reply	other threads:[~2013-03-05  1:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-03  7:36 [PATCH] kexec/ppc: Fix kernel program entry point while changing the load addr Suzuki K. Poulose
2013-03-04  1:41 ` Simon Horman
2013-03-04  1:41   ` Simon Horman
2013-03-04  5:56   ` Suzuki K. Poulose
2013-03-04  5:56     ` Suzuki K. Poulose
2013-03-05  1:40     ` Simon Horman [this message]
2013-03-05  1:40       ` Simon Horman

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=20130305014043.GD16128@verge.net.au \
    --to=horms@verge.net.au \
    --cc=bigeasy@linutronix.de \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=msm@freescale.com \
    --cc=suzuki@in.ibm.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.