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

[Scott Wood <scottwood@freescale.com>]

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.
>=20
> 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?),
>=20
> No. The memstart_addr does be affected. For example, for a boot kernel
> with the command line with "crashkernel=3D32M@64M", the device tree =20
> passed
> the kdump kernel will have a memory node like this:
>     memory {
>             reg =3D <0x0 0x4000000 0x0 0x2000000>;
>             device_type =3D "memory";
>     }
>=20
> 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 =20
that indicated somewhere else in the device tree?

-Scott=