[PATCH 2/2] powerpc/fsl_booke: enable the relocatable for the kdump kernel

Scott Wood scottwood at freescale.com
Wed Jul 3 08:41:05 EST 2013


On 07/01/2013 10:45:14 PM, Kevin Hao wrote:
> On Mon, Jul 01, 2013 at 08:00:06PM -0500, Scott Wood wrote:
> > On 06/30/2013 02:35:21 AM, Kevin Hao wrote:
> > >On Thu, Jun 27, 2013 at 09:19:06PM -0500, Scott Wood wrote:
> > >> On 06/26/2013 09:00:34 PM, Kevin Hao wrote:
> > >> >diff --git a/arch/powerpc/include/asm/mmu-book3e.h
> > >> >b/arch/powerpc/include/asm/mmu-book3e.h
> > >> >index 936db36..bf422db 100644
> > >> >--- a/arch/powerpc/include/asm/mmu-book3e.h
> > >> >+++ b/arch/powerpc/include/asm/mmu-book3e.h
> > >> >@@ -214,6 +214,11 @@
> > >> > #define TLBILX_T_CLASS2			6
> > >> > #define TLBILX_T_CLASS3			7
> > >> >
> > >> >+#ifdef CONFIG_PPC32
> > >> >+/* The max size that one tlb can map in a 32bit kernel. */
> > >> >+#define PPC_PIN_SIZE	(1 << 28)	/* 256M */
> > >> >+#endif
> > >>
> > >> That comment is not true for all chips.
> > >
> > >This is not for the hardware limitation.
> >
> > It's not for a general software limitation, either.  We can use 1G
> > mappings for user hugetlb (if the default mmap address is moved out
> > of the way) or for the kernel lowmem mapping (if the address is
> > moved to 0x80000000 instead of 0xc0000000).
> >
> > It's also possible (although unlikely at this point) that someone
> > could make a 32-bit booke chip that cannot handle 256M mappings.
> 
> Then I have to agree with you. :-)
> Wish I can find a way to drop it.

At least give it a comment that describes how it's actually used.

> > Assuming memstart_addr isn't affected by the crashkernel reservation
> > (if it is, could you point out where?),
> 
> No. The memstart_addr does be affected. For example, for a boot kernel
> with the command line with "crashkernel=32M at 64M", the device tree  
> passed
> the kdump kernel will have a memory node like this:
>     memory {
>             reg = <0x0 0x4000000 0x0 0x2000000>;
>             device_type = "memory";
>     }
> 
> Then the memstart_addr will be set to 0x4000000 in the kdump kernel.

OK, so then how does the crash kernel know which regions to dump?  Is  
that indicated somewhere else in the device tree?

-Scott


More information about the Linuxppc-dev mailing list