All of lore.kernel.org
 help / color / mirror / Atom feed
From: leroy christophe <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
Date: Wed, 11 Dec 2013 00:05:21 +0100	[thread overview]
Message-ID: <52A79E31.9070304@c-s.fr> (raw)
In-Reply-To: <1386714253.10013.123.camel@snotra.buserror.net>


Le 10/12/2013 23:24, Scott Wood a écrit :
> On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
>> Today, the only way to load kernels whose size is greater than 8Mbytes is to
>> activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
>> limited to 8Mbytes. This patch adds the capability to select the size of initial
>> memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB
>> is active or not. It allows to load "big" kernels (for instance when activating
>> CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -980,6 +980,29 @@
>>   config PIN_TLB
>>   	bool "Pinned Kernel TLBs (860 ONLY)"
>>   	depends on ADVANCED_OPTIONS && 8xx
>> +
>> +choice
>> +	prompt "Initial Data Memory Mapped on 8xx"
>> +	default 8xx_MAP_8M
>> +	depends on ADVANCED_OPTIONS && 8xx
>> +
>> +config	8xx_INIT_MAP_8M
>> +	bool "8 Mbytes"
>> +
>> +config	8xx_INIT_MAP_16M
>> +	bool "16 Mbytes"
>> +
>> +config	8xx_INIT_MAP_24M
>> +	bool "24 Mbytes"
> Are you working with a loader that passes initial-mapped-area size in r7
> as per ePAPR?  If so, we could rely on that at runtime.  If you're using
> a non-ancient U-Boot, it should qualify here even if it's not fully
> ePAPR compliant (it passes the value of the bootm_mapsize variable in
> r7).
Ok, let me check that. But it means that the size of the kernel I can 
boot will depend on the initial memory mapped by uboot ? Isn't it 
limitating ?
Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a 
kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ?
I don't like the idea of having to change the bootloader just because I 
want to activate CONFIG_LOCKDEP to debug my kernel.
>
>> -#ifdef CONFIG_PIN_TLB
>> +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M)
>>   	/* Map two more 8M kernel data pages.
>>   	*/
>> +#ifdef CONFIG_PIN_TLB
>>   	addi	r10, r10, 0x0100
>>   	mtspr	SPRN_MD_CTR, r10
>> +#endif
>>   
>>   	lis	r8, KERNELBASE@h	/* Create vaddr for TLB */
>>   	addis	r8, r8, 0x0080		/* Add 8M */
>> @@ -858,15 +860,19 @@
>>   	addis	r11, r11, 0x0080	/* Add 8M */
>>   	mtspr	SPRN_MD_RPN, r11
>>   
>> +#ifdef CONFIG_8xx_INIT_MAP_24M
>> +#ifdef CONFIG_PIN_TLB
>>   	addi	r10, r10, 0x0100
>>   	mtspr	SPRN_MD_CTR, r10
>> +#endif
> Are these ifdefs for CONFIG_PIN_TLB really needed?  It shouldn't harm
> anything to use those entries even if they're not being pinned.

I'm not sure I understand your comment.
ifdef for CONFIG_PIN_TLB was already there before, but was enclosing the 
whole block, so 24 Mbytes were automatically mapped when you selected 
CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select 
CONFIG_PIN_TLB.
I reduced the scope of those ifdefs so that they now apply on the 
pinning only.

Christophe

WARNING: multiple messages have this Message-ID (diff)
From: leroy christophe <christophe.leroy@c-s.fr>
To: Scott Wood <scottwood@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
Date: Wed, 11 Dec 2013 00:05:21 +0100	[thread overview]
Message-ID: <52A79E31.9070304@c-s.fr> (raw)
In-Reply-To: <1386714253.10013.123.camel@snotra.buserror.net>


Le 10/12/2013 23:24, Scott Wood a écrit :
> On Tue, 2013-12-10 at 12:29 +0100, Christophe Leroy wrote:
>> Today, the only way to load kernels whose size is greater than 8Mbytes is to
>> activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
>> limited to 8Mbytes. This patch adds the capability to select the size of initial
>> memory between 8/16/24 Mbytes and this is regardless of whether CONFIG_PIN_TLB
>> is active or not. It allows to load "big" kernels (for instance when activating
>> CONFIG_LOCKDEP_SUPPORT) without having to activate CONFIG_PIN_TLB.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> diff -ur a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -980,6 +980,29 @@
>>   config PIN_TLB
>>   	bool "Pinned Kernel TLBs (860 ONLY)"
>>   	depends on ADVANCED_OPTIONS && 8xx
>> +
>> +choice
>> +	prompt "Initial Data Memory Mapped on 8xx"
>> +	default 8xx_MAP_8M
>> +	depends on ADVANCED_OPTIONS && 8xx
>> +
>> +config	8xx_INIT_MAP_8M
>> +	bool "8 Mbytes"
>> +
>> +config	8xx_INIT_MAP_16M
>> +	bool "16 Mbytes"
>> +
>> +config	8xx_INIT_MAP_24M
>> +	bool "24 Mbytes"
> Are you working with a loader that passes initial-mapped-area size in r7
> as per ePAPR?  If so, we could rely on that at runtime.  If you're using
> a non-ancient U-Boot, it should qualify here even if it's not fully
> ePAPR compliant (it passes the value of the bootm_mapsize variable in
> r7).
Ok, let me check that. But it means that the size of the kernel I can 
boot will depend on the initial memory mapped by uboot ? Isn't it 
limitating ?
Even if uboot only maps 8Mbytes, why couldn't I be allowed to boot a 
kernel having 10 Mbytes data if I have 32 Mbytes mem on the board ?
I don't like the idea of having to change the bootloader just because I 
want to activate CONFIG_LOCKDEP to debug my kernel.
>
>> -#ifdef CONFIG_PIN_TLB
>> +#if defined (CONFIG_8xx_INIT_MAP_16M) || defined (CONFIG_8xx_INIT_MAP_24M)
>>   	/* Map two more 8M kernel data pages.
>>   	*/
>> +#ifdef CONFIG_PIN_TLB
>>   	addi	r10, r10, 0x0100
>>   	mtspr	SPRN_MD_CTR, r10
>> +#endif
>>   
>>   	lis	r8, KERNELBASE@h	/* Create vaddr for TLB */
>>   	addis	r8, r8, 0x0080		/* Add 8M */
>> @@ -858,15 +860,19 @@
>>   	addis	r11, r11, 0x0080	/* Add 8M */
>>   	mtspr	SPRN_MD_RPN, r11
>>   
>> +#ifdef CONFIG_8xx_INIT_MAP_24M
>> +#ifdef CONFIG_PIN_TLB
>>   	addi	r10, r10, 0x0100
>>   	mtspr	SPRN_MD_CTR, r10
>> +#endif
> Are these ifdefs for CONFIG_PIN_TLB really needed?  It shouldn't harm
> anything to use those entries even if they're not being pinned.

I'm not sure I understand your comment.
ifdef for CONFIG_PIN_TLB was already there before, but was enclosing the 
whole block, so 24 Mbytes were automatically mapped when you selected 
CONFIG_PIN_TLB and only 8 Mbytes were mapped when you didn't select 
CONFIG_PIN_TLB.
I reduced the scope of those ifdefs so that they now apply on the 
pinning only.

Christophe

  reply	other threads:[~2013-12-10 23:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-10 11:29 [PATCH v2] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB Christophe Leroy
2013-12-10 11:29 ` Christophe Leroy
2013-12-10 22:24 ` Scott Wood
2013-12-10 22:24   ` Scott Wood
2013-12-10 23:05   ` leroy christophe [this message]
2013-12-10 23:05     ` leroy christophe
2013-12-10 23:18     ` Scott Wood
2013-12-10 23:18       ` Scott Wood
2013-12-10 23:36       ` leroy christophe
2013-12-10 23:36         ` leroy christophe
2013-12-16 22:57         ` Scott Wood
2013-12-16 22:57           ` Scott Wood
2013-12-17  5:54           ` leroy christophe
2013-12-17  5:54             ` leroy christophe
2013-12-17 22:38             ` Scott Wood
2013-12-17 22:38               ` Scott Wood

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=52A79E31.9070304@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=scottwood@freescale.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.