linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set
@ 2005-12-22 19:52 Marcelo Tosatti
  2005-12-29 20:42 ` Marcelo Tosatti
  0 siblings, 1 reply; 2+ messages in thread
From: Marcelo Tosatti @ 2005-12-22 19:52 UTC (permalink / raw)
  To: linux-ppc-embedded, Dan Malek

Hi,

The last two 8MB TLB entries are being incorrectly set by initial_mmu on 8xx. 

The first entry is written with the same virtual/physical address, which
renders it invalid:

BDI>rms 792 0x00001e00
BDI>rms 824 1
BDI>rds 824
SPR  824 : 0xc08000c0  -1065353024
BDI>rds 825
SPR  825 : 0xc0800de0  -1065349664
BDI>rds 826
SPR  826 : 0x00000000            0

And the second entry, in addition, does not have its TLB index set
correctly.

Dan, I'm afraid that, with this problem fixed, the issue you mentioned
before with relation to conflicts with the vmalloc space becomes real.

* only pin available RAM at initial_mmu, the pinned mappings pointing
beyond the end of physical RAM cause conflicts with vmalloc() space.

Is there any way to know the RAM size at this point in boot? The bd_t
structure is board-specific, so no chance at offseting bd_t to reach the
"mem_size" field.

I see no improvements with the following patch on 128MB boxen, probably
because most referenced kernel data is above 24MB (SLAB caches, etc).
But lower mem machines should benefit significantly - anyone willing to
do some testing?

diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index de09787..c67cb5c 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -733,13 +733,16 @@ initial_mmu:
 	mtspr	SPRN_MD_TWC, r9
 	li	r11, MI_BOOTINIT	/* Create RPN for address 0 */
 	addis	r11, r11, 0x0080	/* Add 8M */
-	mtspr	SPRN_MD_RPN, r8
+	mtspr	SPRN_MD_RPN, r11
+
+	addi	r10, r10, 0x0100
+	mtspr	SPRN_MD_CTR, r10
 
 	addis	r8, r8, 0x0080		/* Add 8M */
 	mtspr	SPRN_MD_EPN, r8
 	mtspr	SPRN_MD_TWC, r9
 	addis	r11, r11, 0x0080	/* Add 8M */
-	mtspr	SPRN_MD_RPN, r8
+	mtspr	SPRN_MD_RPN, r11
 #endif
 
 	/* Since the cache is enabled according to the information we

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set
  2005-12-22 19:52 [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set Marcelo Tosatti
@ 2005-12-29 20:42 ` Marcelo Tosatti
  0 siblings, 0 replies; 2+ messages in thread
From: Marcelo Tosatti @ 2005-12-29 20:42 UTC (permalink / raw)
  To: linux-ppc-embedded, Dan Malek

On Thu, Dec 22, 2005 at 05:52:21PM -0200, Marcelo Tosatti wrote:
> Hi,
> 
> The last two 8MB TLB entries are being incorrectly set by initial_mmu on 8xx. 
> 
> The first entry is written with the same virtual/physical address, which
> renders it invalid:
> 
> BDI>rms 792 0x00001e00
> BDI>rms 824 1
> BDI>rds 824
> SPR  824 : 0xc08000c0  -1065353024
> BDI>rds 825
> SPR  825 : 0xc0800de0  -1065349664
> BDI>rds 826
> SPR  826 : 0x00000000            0
> 
> And the second entry, in addition, does not have its TLB index set
> correctly.
> 
> Dan, I'm afraid that, with this problem fixed, the issue you mentioned
> before with relation to conflicts with the vmalloc space becomes real.
> 
> * only pin available RAM at initial_mmu, the pinned mappings pointing
> beyond the end of physical RAM cause conflicts with vmalloc() space.
> 
> Is there any way to know the RAM size at this point in boot? The bd_t
> structure is board-specific, so no chance at offseting bd_t to reach the
> "mem_size" field.

None of this is necessary, we only need to define VMALLOC_START such
that it won't conflict with pinned space, as the Book-E 44x port already
does.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-12-29 20:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-22 19:52 [PATCH] ppc32 8xx: last two 8MB D-TLB entries are incorrectly set Marcelo Tosatti
2005-12-29 20:42 ` Marcelo Tosatti

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).