On 12/11/11 01:32, Segher Boessenkool wrote:
Hi Suzuki,
Looks quite good, a few comments...
+get_type:
+ /* r4 holds the relocation type */
+ extrwi r4, r4, 8, 24 /* r4 = ((char*)r4)[3] */
This comment is confusing (only makes sense together with the
lwz a long way up).
Agree, will fix the
On 12/09/11 17:13, Suzuki K. Poulose wrote:
The following series implements:
* Generic framework for relocatable kernel on PPC32, based on processing
the dynamic relocation entries.
* Relocatable kernel support for 44x
* Kdump support for 44x. Doesn't support 47x yet, as the kexec
On 12/09/11 19:10, Josh Boyer wrote:
On Fri, Dec 9, 2011 at 6:47 AM, Suzuki K. Poulose wrote:
Signed-off-by: Suzuki K. Poulose
Signed-off-by: Josh Poimboeuf
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: Alan Modra
Cc: Kumar Gala
Cc: linuxppc-dev
---
arch/powerpc/Kconfig |
On 11/30/11 20:11, Josh Boyer wrote:
On Mon, Nov 28, 2011 at 5:59 PM, Scott Wood wrote:
On 11/23/2011 10:47 AM, Josh Boyer wrote:
On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose wrote:
The current implementation of CONFIG_RELOCATABLE in BookE is based
on mapping the page aligned kernel l
On 11/15/11 04:00, Paul Bolle wrote:
Commit 674bfa4855 ("powerpc/44x: Kexec support for PPC440X chipsets")
used the Kconfig symbol '47x', and the macro 'CONFIG_47x'. Neither
exist. These should have been 'PPC_47x' and 'CONFIG_PPC_47x'. Fix these
typos.
Thanks for catching this. I have already s
[ Don't know what happened to the Cover message. Resending this again ]
The following series implements:
* Generic framework for relocatable kernel on PPC32, based on processing
the dynamic relocation entries.
* Relocatable kernel support for 44x
* Kdump support for 44x. Doesn't support 47
On 11/09/11 20:23, Josh Poimboeuf wrote:
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in
relocate(), lets do
On 11/09/11 12:03, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in
relocate(), lets do it like:
for e.g, on 440x, (in head_44x.S :)
#ifdef
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf wrote:
> On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
> > What I was suggesting is, instead of flushing the cache in
> > relocate(), lets do it like:
> >
> > for e.g, on 440x, (in head_44x.S :)
> &g
On 11/07/11 20:43, Josh Poimboeuf wrote:
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
@@ -137,6 +137,9 @@ get_type:
lwz r0, 8(r9) /* r_addend */
add r0
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
the kernel image to the same.
Hi Suzuki,
Thanks
On 10/27/11 21:11, Scott Wood wrote:
On 10/27/2011 03:43 AM, Suzuki Poulose wrote:
On 10/27/11 00:46, Scott Wood wrote:
On 10/26/2011 02:12 PM, Suzuki Poulose wrote:
I have renamed the new type of relocation to RELOCATABLE_PPC32_PIE. The
patches
were posted yesterday. Please let me know your
On 10/27/11 00:46, Scott Wood wrote:
On 10/26/2011 02:12 PM, Suzuki Poulose wrote:
On 10/25/11 21:04, Scott Wood wrote:
On 10/12/2011 09:15 AM, Dave Hansen wrote:
This is not the place to enforce that kind of thing. If
CONFIG_RELOCATABLE is only supported on one platform, then do
On 10/25/11 21:04, Scott Wood wrote:
On 10/12/2011 09:15 AM, Dave Hansen wrote:
On Tue, 2011-10-11 at 18:24 +0530, Suzuki Poulose wrote:
On 10/10/11 23:30, Scott Wood wrote:
On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
#if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
#def
On 10/24/11 18:05, radha krishna wrote:
Hi Team,
I am using Linux-3.0 on mpc8379 RDB. I have downloaded kexec-tools-2.0.2
package from open source and cross compiled for ppc_6xx.
But, the kexec is not booting with kernel loaded with "kexec -l".
I am not familiar with mcp8379 RDB. AFAIK, the p
On 10/10/11 23:30, Scott Wood wrote:
On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
#if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) - PHYSICAL_START +
(KERNELBASE + RELOC_OFFSET)))
#define __pa(x) ((unsigned long)(x) + PHYSICAL_
On 10/10/11 20:45, Scott Wood wrote:
On 10/10/2011 04:55 AM, Suzuki K. Poulose wrote:
The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
the kernel image to the same.
How much overhead is involved in
Hi Kumar,
I have been working on the CONFIG_RELOCATABLE support for PPC44x, trying to
process
the relocations generated by the compiler. Since the TLB size is 256M, we cannot
enforce a page aligned kernel load address.
I came across some issues with the __va() / __pa() translations, while the
On 09/29/11 04:33, Benjamin Herrenschmidt wrote:
On Tue, 2011-09-27 at 17:54 +0530, Suzuki Poulose wrote:
Hi,
I am working on enabling CONFIG_RELOCATABLE for PPC44x Embedded PowerPC
boards as a foundation to enable CONFIG_CRASH_DUMP. After a discussion
on the linux-ppcdev we decided that we
[Resending - Missed a few key people on the Cc list + Some more comments]
Hi,
I am working on enabling CONFIG_RELOCATABLE for PPC44x Embedded PowerPC
boards as a foundation to enable CONFIG_CRASH_DUMP. After a discussion
on the linux-ppcdev , we decided that we will follow the 'processing
relo
Hi,
I am working on enabling CONFIG_RELOCATABLE for PPC44x Embedded PowerPC
boards as a foundation to enable CONFIG_CRASH_DUMP. After a discussion
on the linux-ppcdev we decided that we will follow the 'processing
relocation entries' approach for running the kernel from a different
address.
On 08/30/11 11:51, Benjamin Herrenschmidt wrote:
On Tue, 2011-08-30 at 16:19 +1000, Benjamin Herrenschmidt wrote:
On Tue, 2011-08-30 at 11:47 +0530, Suzuki Poulose wrote:
The flash operation is performed in the reboot path at the very end.
So, even if we restart the event scan, the thread
On 08/30/11 11:33, Benjamin Herrenschmidt wrote:
On Wed, 2011-07-27 at 17:39 +0530, Ravi K. Nittala wrote:
The firmware flash update is conducted using an RTAS call, that is serialized
by lock_rtas() which uses spin_lock. rtasd keeps scanning for the RTAS events
generated on the machine. This is
ed.
Ben,
Could you please let us know your thoughts about the following patch ?
Thanks
Suzuki
Signed-off-by: Suzuki Poulose
Signed-off-by: Ravi Nittala
---
arch/powerpc/include/asm/rtas.h |2 ++
arch/powerpc/kernel/rtas_flash.c |6 ++
arch/powerpc/kernel/rtasd.c
On 07/12/11 12:14, Suzuki K. Poulose wrote:
Changes from V1: Uses a tmp mapping in the other address space to setup
the 1:1 mapping (suggested by Sebastian Andrzej Siewior).
Note: Should we do the same for kernel entry code for PPC44x ?
This patch adds kexec support for PPC440
boards and Virtex on QEMU.
It would be great if somebody could test this on the other boards.
Signed-off-by: Suzuki Poulose
Cc: Sebastian Andrzej Siewior
---
arch/powerpc/Kconfig |2
arch/powerpc/include/asm/kexec.h |2
arch/powerpc/kernel/misc_32.S| 170
On 07/12/11 18:57, Josh Boyer wrote:
On Tue, Jul 5, 2011 at 2:18 AM, Suzuki Poulose wrote:
On 07/05/11 10:06, Tony Breeds wrote:
From: Dave Kleikamp
The 44x code (which is shared by 47x) assumes the available physical
memory
begins at 0x. This is not necessarily the case in an AMP
On 06/16/11 19:44, Michal Simek wrote:
Changes:
- Find out address where kernel runs
- Create the first 256MB TLB from online detected address
Limitations:
- Kernel must be aligned to 256MB
Backport:
- Changes in page.h are backported from newer kernel version
mmu_mapin_ram function has to ref
On 07/05/11 10:06, Tony Breeds wrote:
From: Dave Kleikamp
The 44x code (which is shared by 47x) assumes the available physical memory
begins at 0x. This is not necessarily the case in an AMP
environment.
Support CONFIG_RELOCATABLE for 476 in order to allow the kernel to be
loaded into
On 06/03/11 19:23, Sebastian Andrzej Siewior wrote:
Suzuki Poulose wrote:
The way you setup the 1:1 mapping should be close to what you are doing on
kernel entry.Isn't it possible to include the file here and in the entry
code?
I will make this change and resend the patch.
I took a lo
On 06/15/11 15:41, Benjamin Herrenschmidt wrote:
On Wed, 2011-06-15 at 11:43 +0530, Suzuki Poulose wrote:
On 06/14/11 17:34, Michal Simek wrote:
Hi,
have someone tried to support RELOCATABLE kernel on ppc44x?
As Josh, mentioned, I will be working on this. In fact I was trying a couple of
On 06/14/11 17:34, Michal Simek wrote:
Hi,
have someone tried to support RELOCATABLE kernel on ppc44x?
As Josh, mentioned, I will be working on this. In fact I was trying a couple of
patches towards this on PPC440x. But, I am stuck in debugging the hang that I am
experiencing with the changes.
Hi,
This is version 2 of the patch
Changes from Version 1 :
: Changed the interface for read_memory_region_limits to use 'int fd'
instead of FILE*.
: Use sizeof(variable) for read(, instead of sizeof(type).
---
Fix parsing of the memory region information from the device-tree.
The
On 06/06/11 14:30, David Laight wrote:
Changed the add_usable_mem_property() to accept FILE* fp instead of
int fd,
as most of the other users of read_memory_region_limits() deals with
FILE*.
Signed-off-by: Suzuki K. Poulose
Could you please let me know your thoughts/comments about this pat
On 06/06/11 14:21, Sebastian Andrzej Siewior wrote:
Suzuki Poulose wrote:
Could you please let me know your thoughts/comments about this patch ?
I'm mostly fine with it.
Maaxim copied fs2dt.c from ppc64 to ppc. So I guess ppc64 has the same
problem.
Yes, you are right. Porting this
On 05/30/11 12:00, Suzuki Poulose wrote:
Use the #address-cells, #size-cells information to parse the memory/reg info
from device tree.
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg v
On 06/02/11 12:04, Suzuki Poulose wrote:
On 05/31/11 20:45, Sebastian Andrzej Siewior wrote:
Suzuki Poulose wrote:
Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
===
--- /dev/null
+++ powerpc/arch/powerpc/kernel
On 06/02/11 12:55, Benjamin Herrenschmidt wrote:
On Tue, 2011-05-31 at 17:15 +0200, Sebastian Andrzej Siewior wrote:
Suzuki Poulose wrote:
Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
===
--- /dev/null
+++ powerpc/arch
On 05/31/11 20:45, Sebastian Andrzej Siewior wrote:
Suzuki Poulose wrote:
Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
===
--- /dev/null
+++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S
+ *
+ */
+ bl nxtins
KEXEC Support for ppc440X
The patch adds kexec support for PPC440x based boards. This work is based
on the KEXEC patches for FSL BookE.
The FSL BookE patch and the code flow could be found at the link below:
http://patchwork.ozlabs.org/patch/49359/
We invalidate all the TLB entries except the
Use the #address-cells, #size-cells information to parse the memory/reg info
from device tree.
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where
41 matches
Mail list logo
