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

[Scott Wood <scottwood@freescale.com>]

On 06/26/2013 09:00:34 PM, Kevin Hao wrote:
> diff --git a/arch/powerpc/include/asm/mmu-book3e.h =20
> 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
>=20
> +#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.

> @@ -177,11 +178,34 @@ unsigned long map_mem_in_cams(unsigned long =20
> ram, int max_cam_idx)
>  	unsigned long virt =3D PAGE_OFFSET;
>  	phys_addr_t phys =3D memstart_addr;
>  	unsigned long amount_mapped =3D 0;
> -
> +	unsigned long cam_sz;
> +
> +#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_PPC32)
> +	/*
> +	 * For a relocatable kernel, we would not map from =20
> memstart_addr.
> +	 * We first align to PPC_PIN_SIZE (256M), then map the =20
> PAGE_OFFSET
> +	 * from there.
> +	 */
> +	phys &=3D ~(PPC_PIN_SIZE - 1);
> +	ram +=3D memstart_addr & (PPC_PIN_SIZE - 1);

You should not map anything before memstart_addr.  If memstart_addr =20
isn't 256M-aligned, you'll have to either use smaller pages or consider =20
that region to be "high"mem (assuming Linux supports highmem existing =20
below lowmem -- I'm skeptical).

> +	/*
> +	 * For a kdump kernel, we may use a memory area reserved by the =20
> boot
> +	 * kernel by using a kernel option like this =20
> 'crashkernel=3D32M@64M'.
> +	 * In this case, the ram is 96M. The kernel will try to map the =20
> first
> +	 * 64M in the first tlb entry. The kernel will definitely get =20
> stuck,
> +	 * since the kernel is running above the 64M. So we have to =20
> make sure
> +	 * that the first tlb cover the current kernel running address =20
> at least.
> +	 */

Maybe we should be running from AS1 when we set this up, to avoid =20
problems replacing an entry while it's in use?

Pardon my ignorance about how kdump/kexec works, but I'm a bit confused =20
by exactly what the situation is with crashkernel.  How do we know that =20
we are the crash kernel, and that we should limit our RAM usage to that =20
area?  I'm wondering if this code is assuming that the crashkernel area =20
is from where the kernel starts to the end of RAM.

> +	while (1) {
> +		cam_sz =3D calc_cam_sz(ram, virt, phys);
> +		if (cam_sz + phys > PHYSICAL_START + _end - _stext)
> +			break;
> +		ram =3D 1 << (ilog2(ram) + 1);
> +	}

The ram that was passed in is as much as you have.  Don't map more.

What happens if (e.g.) memstart_addr is 512M, with a size of 512M, and =20
the kernel starts at 768M?  Increasing the size will never get you a =20
mapping that covers kernstart, because calc_cam_sz will never return =20
more than 256M.

When does memory below the rounded-down kernel start get mapped?

-Scott=