Skip to contentSkip to conversation

ppc/85xx: Fix bug in setup_mp code

PATCH New Kumar Gala 3 participants 6 messages Sep 3, 2009 – Jan 21, 2010

lore
Share & tools
lore

Kumar Gala

author
#0 lore raw

PATCH 1/1 ppc/85xx: Fix bug in setup_mp code

Its possible that we try and copy the boot page code out of flash into a DDR location that doesn't have a TLB cover it. For example, if we have 3G of DDR we typically only map the first 2G. In the cases of 4G+ this wasn't an issue since the reset page TLB mapping covered the last page of memory which we wanted to copy to.

We now change the physical address of the reset page TLB to map to the true physical location of the boot page code, copy and than set the TLB back to its 1:1 mapping of the reset page.

---
 cpu/mpc85xx/mp.c |   32 +++++++++++++++++++++++++++++---
 1 files changed, 29 insertions(+), 3 deletions(-)
cpu/mpc85xx/mp.c +29 -3
index 2df55c7..fa65bed 100644
@@ -25,6 +25,7 @@
 #include <ioports.h>
 #include <lmb.h>
 #include <asm/io.h>
+#include <asm/mmu.h>
 #include "mp.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -209,8 +210,33 @@ void setup_mp(void)
 	ulong fixup = (ulong)&__secondary_start_page;
 	u32 bootpg = determine_mp_bootpg();
 
-	memcpy((void *)bootpg, (void *)fixup, 4096);
-	flush_cache(bootpg, 4096);
+	/* look for the tlb covering the reset page, there better be one */
+	int i = find_tlb_idx((void *)0xfffff000, 1);
 
-	pq3_mp_up(bootpg);
+	/* we found a match */
+	if (i != -1) {
+		/* map reset page to bootpg so we can copy code there */
+		disable_tlb(i);
+	
+		set_tlb(1, 0xfffff000, bootpg, /* tlb, epn, rpn */
+			MAS3_SX|MAS3_SW|MAS3_SR, MAS2_M, /* perms, wimge */
+			0, i, BOOKE_PAGESZ_4K, 1); /* ts, esel, tsize, iprot */
+
+		memcpy((void *)0xfffff000, (void *)fixup, 4096);
+		flush_cache(0xfffff000, 4096);
+
+		disable_tlb(i);
+
+		/* setup reset page back to 1:1, we'll use HW boot translation
+		 * to map this where we want
+		 */
+		set_tlb(1, 0xfffff000, 0xfffff000, /* tlb, epn, rpn */
+			MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I, /* perms, wimge */
+			0, i, BOOKE_PAGESZ_4K, 1); /* ts, esel, tsize, iprot */
+
+		pq3_mp_up(bootpg);
+	} else {
+		puts("WARNING: No reset page TLB. "
+			"Skipping secondary core setup\n");
+	}
 }
Signature · 1 line
1.6.0.6
#1 lore raw

PATCH 1/1 ppc/85xx: Fix bug in setup_mp code

Quoted 47 lines · Kumar Gala

Its possible that we try and copy the boot page code out of flash into a DDR location that doesn't have a TLB cover it. For example, if we have 3G of DDR we typically only map the first 2G. In the cases of 4G+ this wasn't an issue since the reset page TLB mapping covered the last page of memory which we wanted to copy to.

We now change the physical address of the reset page TLB to map to the true physical location of the boot page code, copy and than set the TLB back to its 1:1 mapping of the reset page.

---
 cpu/mpc85xx/mp.c |   32 +++++++++++++++++++++++++++++---
 1 files changed, 29 insertions(+), 3 deletions(-)
cpu/mpc85xx/mp.c +13 -3
index 2df55c7..fa65bed 100644
@@ -25,6 +25,7 @@
 #include <ioports.h>
 #include <lmb.h>
 #include <asm/io.h>
+#include <asm/mmu.h>
 #include "mp.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -209,8 +210,33 @@ void setup_mp(void)
 	ulong fixup = (ulong)&__secondary_start_page;
 	u32 bootpg = determine_mp_bootpg();
 
-	memcpy((void *)bootpg, (void *)fixup, 4096);
-	flush_cache(bootpg, 4096);
+	/* look for the tlb covering the reset page, there better be one */
+	int i = find_tlb_idx((void *)0xfffff000, 1);
 
-	pq3_mp_up(bootpg);
+	/* we found a match */
+	if (i != -1) {
+		/* map reset page to bootpg so we can copy code there */
+		disable_tlb(i);
+	
+		set_tlb(1, 0xfffff000, bootpg, /* tlb, epn, rpn */
+			MAS3_SX|MAS3_SW|MAS3_SR, MAS2_M, /* perms, wimge */
+			0, i, BOOKE_PAGESZ_4K, 1); /* ts, esel, tsize, iprot */
+
+		memcpy((void *)0xfffff000, (void *)fixup, 4096);

cpu/mpc85xx/mp.c void setup_mp(void) · line 235

Quoted 10 lines
cpu/mpc85xx/mp.c +10 -0
+		flush_cache(0xfffff000, 4096);
+
+		disable_tlb(i);
+
+		/* setup reset page back to 1:1, we'll use HW boot translation
+		 * to map this where we want
+		 */
+		set_tlb(1, 0xfffff000, 0xfffff000, /* tlb, epn, rpn */
+			MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I, /* perms, wimge */
+			0, i, BOOKE_PAGESZ_4K, 1); /* ts, esel, tsize, iprot */

X-ES's mpc8572/8561 boards don't currently use 1 TLB to just map the 0xfffff000 region, we use same TLB that is used for flash (covering 0xf0000000-0xffffffff).

It looks like a fair number of other mpc85xx non-MP boards currently use the 0xfffff000 region for flash too. This patch wouldn't affect them, but I assume when those vendors produce a board with MP support, they'd like to keep the same memory map, in which case they'd run into the same issue as I'm having with not reserving the 0xfffffxxx region for BPTR use.

In any case, I was wondering if you'd be up for changing this patch to save/restore the TLB you're disabling instead of hardcoding the "restore". I could send a follow-up patch if you're OK with the concept too.

I feel like our use of the 0xfffff000 memory region is starting to make us the red headed stepchild of the mpc85xx MP family:)

Thanks,
Peter

author
#2 lore raw

PATCH 1/1 ppc/85xx: Fix bug in setup_mp code

Quoted 78 lines · Peter Tyser
Quoted 52 lines · Kumar Gala

Its possible that we try and copy the boot page code out of flash into a
DDR location that doesn't have a TLB cover it. For example, if we have
3G of DDR we typically only map the first 2G. In the cases of 4G+ this
wasn't an issue since the reset page TLB mapping covered the last page
of memory which we wanted to copy to.

We now change the physical address of the reset page TLB to map to the
true physical location of the boot page code, copy and than set the TLB back to its 1:1 mapping of the reset page.

---
cpu/mpc85xx/mp.c | 32 +++++++++++++++++++++++++++++---

1 files changed, 29 insertions(+), 3 deletions(-)
cpu/mpc85xx/mp.c +13 -3
index 2df55c7..fa65bed 100644
@@ -25,6 +25,7 @@
 #include <ioports.h>
 #include <lmb.h>
 #include <asm/io.h>
+#include <asm/mmu.h>
 #include "mp.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -209,8 +210,33 @@ void setup_mp(void)
 	ulong fixup = (ulong)&__secondary_start_page;
 	u32 bootpg = determine_mp_bootpg();
 
-	memcpy((void *)bootpg, (void *)fixup, 4096);
-	flush_cache(bootpg, 4096);
+	/* look for the tlb covering the reset page, there better be one */
+	int i = find_tlb_idx((void *)0xfffff000, 1);
 
-	pq3_mp_up(bootpg);
+	/* we found a match */
+	if (i != -1) {
+		/* map reset page to bootpg so we can copy code there */
+		disable_tlb(i);
+	
+		set_tlb(1, 0xfffff000, bootpg, /* tlb, epn, rpn */
+			MAS3_SX|MAS3_SW|MAS3_SR, MAS2_M, /* perms, wimge */
+			0, i, BOOKE_PAGESZ_4K, 1); /* ts, esel, tsize, iprot */
+
+		memcpy((void *)0xfffff000, (void *)fixup, 4096);

cpu/mpc85xx/mp.c void setup_mp(void) · line 235

Quoted 10 lines
cpu/mpc85xx/mp.c +10 -0
+		flush_cache(0xfffff000, 4096);
+
+		disable_tlb(i);
+
+		/* setup reset page back to 1:1, we'll use HW boot translation
+		 * to map this where we want
+		 */
+		set_tlb(1, 0xfffff000, 0xfffff000, /* tlb, epn, rpn */
+			MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I, /* perms, wimge */
+			0, i, BOOKE_PAGESZ_4K, 1); /* ts, esel, tsize, iprot */

X-ES's mpc8572/8561 boards don't currently use 1 TLB to just map the 0xfffff000 region, we use same TLB that is used for flash (covering 0xf0000000-0xffffffff).

It looks like a fair number of other mpc85xx non-MP boards currently use
the 0xfffff000 region for flash too. This patch wouldn't affect them, but I assume when those vendors produce a board with MP support, they'd
like to keep the same memory map, in which case they'd run into the same
issue as I'm having with not reserving the 0xfffffxxx region for BPTR use.

Quoted 5 lines

In any case, I was wondering if you'd be up for changing this patch to save/restore the TLB you're disabling instead of hardcoding the "restore". I could send a follow-up patch if you're OK with the concept
too.

I'm fine w/the concept. I'm cleaning up some PCI code at this point so feel free to send me a patch to do this.

Quoted 3 lines

I feel like our use of the 0xfffff000 memory region is starting to make
us the red headed stepchild of the mpc85xx MP family:)

:)

- k

#3 lore raw

PATCH 1/1 ppc/85xx: Fix bug in setup_mp code

In reply to Peter Tyser

From: Kumar Gala

Quoted 11 lines

Its possible that we try and copy the boot page code out of flash into

a DDR location that doesn't have a TLB cover it. For example, if we have 3G of DDR we typically only map the first 2G. In the cases of 4G+ this wasn't an issue since the reset page TLB mapping covered the last page of memory which we wanted to copy to.

We now change the physical address of the reset page TLB to map to the

true physical location of the boot page code, copy and than set the TLB back to its 1:1 mapping of the reset page.

Why should a boot page TLB still exist? And if it does exist, it may be serving a good purpose and shouldn't be touched.

Why not just pick an unused virtual address and map it to bootpg?

This TLB grabbing is giving me problems on my board where I have the original 1M bootpage mapped to CPC sram and I want to keep active.

-Ed

#4 lore raw

PATCH 1/1 ppc/85xx: Fix bug in setup_mp code

Hi Ed,

Quoted 9 lines · Swarthout Edward L-SWARTHOU

From: Kumar Gala

Quoted 7 lines

Its possible that we try and copy the boot page code out of flash into

a DDR location that doesn't have a TLB cover it. For example, if we have 3G of DDR we typically only map the first 2G. In the cases of 4G+ this wasn't an issue since the reset page TLB mapping covered the last page of memory which we wanted to copy to.

Quoted 7 lines
Quoted 4 lines

We now change the physical address of the reset page TLB to map to the

true physical location of the boot page code, copy and than set the TLB back to its 1:1 mapping of the reset page.

Why should a boot page TLB still exist? And if it does exist, it may be serving a good purpose and shouldn't be touched.

I imagine Kumar assumed the bootpage was only used for its "intended" purpose? Our boards have a large flash mapped on top of the original bootpage, which caused problems for me too.

Quoted 1 line

Why not just pick an unused virtual address and map it to bootpg?

You can actually do what you describe since commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb. The CONFIG_BPTR_VIRT_ADDR feature is enabled for the XPedite5370 in commit 48618126f78f05042dae428811809b594f747eb9.

Quoted 2 lines

This TLB grabbing is giving me problems on my board where I have the original 1M bootpage mapped to CPC sram and I want to keep active.

I believe reproducing 48618126f78f05042dae428811809b594f747eb9 for your board should be a workaround.

Best,
Peter

author Applied
#5 lore raw

PATCH 1/1 ppc/85xx: Fix bug in setup_mp code

In reply to Kumar Gala
Quoted 9 lines · Kumar Gala

Its possible that we try and copy the boot page code out of flash into a
DDR location that doesn't have a TLB cover it. For example, if we have
3G of DDR we typically only map the first 2G. In the cases of 4G+ this
wasn't an issue since the reset page TLB mapping covered the last page of memory which we wanted to copy to.

Quoted 8 lines

We now change the physical address of the reset page TLB to map to the true physical location of the boot page code, copy and than set the TLB back to its 1:1 mapping of the reset page.

---
cpu/mpc85xx/mp.c | 32 +++++++++++++++++++++++++++++---

1 files changed, 29 insertions(+), 3 deletions(-)

applied to 85xx

- k