[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Peter Tyser]

Previously, boot page translation was enabled while U-Boot executed.
This resulted in the address range 0xfffff000 - 0xffffffff being
translated to SDRAM which made the 0xfffffxxx address space unusable for
other peripherals.

This change disables boot page translation after the secondary CPU cores
have been initialized which allows the 0xfffffxxx address space to be
properly accessed.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
This was tested on the XPedite5370 which has flash mapped in the
0xfffffxxx adddress space.  I verified the flash was accessible
as expected and Linux properly brought up 2 cores.

I wasn't sure how the MPC8572 handled caching with respect to the boot
page translation.  I didn't add any cache flushes/invalidates, but they
may be necessary if the 0xfffffxxx range is not mapped as uncachable.
Anyone at Freescale have any comments on this?

Best,
Peter

 cpu/mpc85xx/mp.c      |   14 ++++++++++++--
 cpu/mpc85xx/release.S |   30 +++++++++++++++++++++++++-----
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index 76f02a4..0019cec 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -129,7 +129,7 @@ ulong get_spin_addr(void)
 
 	ulong addr =
 		(ulong)&__spin_table - (ulong)&__secondary_start_page;
-	addr += 0xfffff000;
+	addr += determine_mp_bootpg();
 
 	return addr;
 }
@@ -137,7 +137,8 @@ ulong get_spin_addr(void)
 static void pq3_mp_up(unsigned long bootpg)
 {
 	u32 up, cpu_up_mask, whoami;
-	u32 *table = (u32 *)get_spin_addr();
+	/* The table is at 0xfffffxxx due to boot page translation below */
+	u32 *table = (u32 *)(0xfffff000 | get_spin_addr());
 	volatile u32 bpcr;
 	volatile ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR);
 	volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
@@ -146,6 +147,8 @@ static void pq3_mp_up(unsigned long bootpg)
 	int timeout = 10;
 
 	whoami = in_be32(&pic->whoami);
+
+	/* Translate 0xfffffxxx 'bootpg' address range to SDRAM */
 	out_be32(&ecm->bptr, 0x80000000 | (bootpg >> 12));
 
 	/* disable time base at the platform */
@@ -194,6 +197,9 @@ static void pq3_mp_up(unsigned long bootpg)
 
 	devdisr &= ~(MPC85xx_DEVDISR_TB0 | MPC85xx_DEVDISR_TB1);
 	out_be32(&gur->devdisr, devdisr);
+
+	/* Disable translation of 0xfffffxxx 'bootpg' */
+	out_be32(&ecm->bptr, 0x0);
 }
 
 void cpu_mp_lmb_reserve(struct lmb *lmb)
@@ -206,9 +212,13 @@ void cpu_mp_lmb_reserve(struct lmb *lmb)
 void setup_mp(void)
 {
 	extern ulong __secondary_start_page;
+	extern ulong __bootpg_addr;
 	ulong fixup = (ulong)&__secondary_start_page;
 	u32 bootpg = determine_mp_bootpg();
 
+	/* Store the bootpg's SDRAM address for use by secondary CPU cores */
+	__bootpg_addr = bootpg;
+
 	memcpy((void *)bootpg, (void *)fixup, 4096);
 	flush_cache(bootpg, 4096);
 
diff --git a/cpu/mpc85xx/release.S b/cpu/mpc85xx/release.S
index fbefc2c..6799633 100644
--- a/cpu/mpc85xx/release.S
+++ b/cpu/mpc85xx/release.S
@@ -114,23 +114,38 @@ __secondary_start_page:
 	stw	r3,ENTRY_R6_UPPER(r10)
 	stw	r3,ENTRY_R6_LOWER(r10)
 
+	/* load r13 with the address of the 'bootpg' in SDRAM */
+	lis	r13,toreset(__bootpg_addr)@h
+	ori	r13,r13,toreset(__bootpg_addr)@l
+	lwz	r13,0(r13)
+
 	/* setup mapping for AS = 1, and jump there */
 	lis	r11,(MAS0_TLBSEL(1)|MAS0_ESEL(1))@h
 	mtspr	SPRN_MAS0,r11
 	lis	r11,(MAS1_VALID|MAS1_IPROT)@h
 	ori	r11,r11,(MAS1_TS|MAS1_TSIZE(BOOKE_PAGESZ_4K))@l
 	mtspr	SPRN_MAS1,r11
-	lis	r11,(0xfffff000|MAS2_I)@h
-	ori	r11,r11,(0xfffff000|MAS2_I)@l
+	oris	r11,r13,(MAS2_I)@h
+	ori	r11,r13,(MAS2_I)@l
 	mtspr	SPRN_MAS2,r11
-	lis	r11,(0xfffff000|MAS3_SX|MAS3_SW|MAS3_SR)@h
-	ori	r11,r11,(0xfffff000|MAS3_SX|MAS3_SW|MAS3_SR)@l
+	oris	r11,r13,(MAS3_SX|MAS3_SW|MAS3_SR)@h
+	ori	r11,r13,(MAS3_SX|MAS3_SW|MAS3_SR)@l
 	mtspr	SPRN_MAS3,r11
 	tlbwe
 
 	bl	1f
 1:	mflr	r11
-	addi	r11,r11,28
+	/*
+	 * OR in 0xfff to create a mask of the bootpg SDRAM address.  We use
+	 * this mask to fixup the cpu spin table and the address that we want
+	 * to jump to, eg change them from 0xfffffxxx to 0x7ffffxxx if the
+	 * bootpg is at 0x7ffff000 in SDRAM.
+	 */
+	ori	r13,r13,0xfff
+	and	r11, r11, r13
+	and	r10, r10, r13
+
+	addi	r11,r11,(2f-1b)
 	mfmsr	r13
 	ori	r12,r13,MSR_IS|MSR_DS at l
 
@@ -200,6 +215,11 @@ __secondary_start_page:
 	mtspr	SPRN_SRR1,r13
 	rfi
 
+	/* Allocate some space for the SDRAM address of the bootpg */
+	.globl __bootpg_addr
+__bootpg_addr:
+	.long	0
+
 	.align L1_CACHE_SHIFT
 	.globl __spin_table
 __spin_table:
-- 
1.6.2.1

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Kumar Gala]

On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:

> Previously, boot page translation was enabled while U-Boot executed.
> This resulted in the address range 0xfffff000 - 0xffffffff being
> translated to SDRAM which made the 0xfffffxxx address space unusable  
> for
> other peripherals.
>
> This change disables boot page translation after the secondary CPU  
> cores
> have been initialized which allows the 0xfffffxxx address space to be
> properly accessed.
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> This was tested on the XPedite5370 which has flash mapped in the
> 0xfffffxxx adddress space.  I verified the flash was accessible
> as expected and Linux properly brought up 2 cores.
>
> I wasn't sure how the MPC8572 handled caching with respect to the boot
> page translation.  I didn't add any cache flushes/invalidates, but  
> they
> may be necessary if the 0xfffffxxx range is not mapped as uncachable.
> Anyone at Freescale have any comments on this?
>
> Best,
> Peter

I'm concerned about this because we specifically avoid the 0xfffff000  
- 0xffffffff range since if we reset a core we want it to go through  
boot page translation.  Can you explain what you are putting at that  
address?

- k

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Peter Tyser]

On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
> On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
> 
> > Previously, boot page translation was enabled while U-Boot executed.
> > This resulted in the address range 0xfffff000 - 0xffffffff being
> > translated to SDRAM which made the 0xfffffxxx address space unusable  
> > for
> > other peripherals.
> >
> > This change disables boot page translation after the secondary CPU  
> > cores
> > have been initialized which allows the 0xfffffxxx address space to be
> > properly accessed.
> >
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > This was tested on the XPedite5370 which has flash mapped in the
> > 0xfffffxxx adddress space.  I verified the flash was accessible
> > as expected and Linux properly brought up 2 cores.
> >
> > I wasn't sure how the MPC8572 handled caching with respect to the boot
> > page translation.  I didn't add any cache flushes/invalidates, but  
> > they
> > may be necessary if the 0xfffffxxx range is not mapped as uncachable.
> > Anyone at Freescale have any comments on this?
> >
> > Best,
> > Peter
> 
> I'm concerned about this because we specifically avoid the 0xfffff000  
> - 0xffffffff range since if we reset a core we want it to go through  
> boot page translation.  Can you explain what you are putting at that  
> address?

Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB
flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 -
0xffffffff.  We've used this convention for a while, before we started
using MPC8572s.

U-Boot is always stored at in the flash at 0xfff80000 on the
MPC85xx-based boards we support.  Thus I couldn't reprogram U-Boot when
CONFIG_MP was defined since the top 4K of flash was really accessing
SDRAM because of the boot page translation.

With this patch boot page translation is still used to bring up the
secondary cores on power on.  This change just makes it so that boot
page translation is disabled after the other cores are brought up.

Best,
Peter

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Kumar Gala]

On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:

> On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
>> On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
>>
>>> Previously, boot page translation was enabled while U-Boot executed.
>>> This resulted in the address range 0xfffff000 - 0xffffffff being
>>> translated to SDRAM which made the 0xfffffxxx address space unusable
>>> for
>>> other peripherals.
>>>
>>> This change disables boot page translation after the secondary CPU
>>> cores
>>> have been initialized which allows the 0xfffffxxx address space to  
>>> be
>>> properly accessed.
>>>
>>> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
>>> ---
>>> This was tested on the XPedite5370 which has flash mapped in the
>>> 0xfffffxxx adddress space.  I verified the flash was accessible
>>> as expected and Linux properly brought up 2 cores.
>>>
>>> I wasn't sure how the MPC8572 handled caching with respect to the  
>>> boot
>>> page translation.  I didn't add any cache flushes/invalidates, but
>>> they
>>> may be necessary if the 0xfffffxxx range is not mapped as  
>>> uncachable.
>>> Anyone at Freescale have any comments on this?
>>>
>>> Best,
>>> Peter
>>
>> I'm concerned about this because we specifically avoid the 0xfffff000
>> - 0xffffffff range since if we reset a core we want it to go through
>> boot page translation.  Can you explain what you are putting at that
>> address?
>
> Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB
> flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 -
> 0xffffffff.  We've used this convention for a while, before we started
> using MPC8572s.
>
> U-Boot is always stored at in the flash at 0xfff80000 on the
> MPC85xx-based boards we support.  Thus I couldn't reprogram U-Boot  
> when
> CONFIG_MP was defined since the top 4K of flash was really accessing
> SDRAM because of the boot page translation.
>
> With this patch boot page translation is still used to bring up the
> secondary cores on power on.  This change just makes it so that boot
> page translation is disabled after the other cores are brought up.

I understand what the patch does.  It just removes the capability of  
soft-resetting a core back into the boot translation code.  I  
understand your problem I'm just not keen on solving it by completely  
disabling boot translation.

We had a similar memory map and I moved away from it because of the  
reset vector issues.  Additionally, things like >4G of memory also  
start creeping up.

- k

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Peter Tyser]

On Tue, 2009-07-07 at 17:24 -0500, Kumar Gala wrote:
> On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
> 
> > On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
> >> On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
> >>
> >>> Previously, boot page translation was enabled while U-Boot executed.
> >>> This resulted in the address range 0xfffff000 - 0xffffffff being
> >>> translated to SDRAM which made the 0xfffffxxx address space unusable
> >>> for
> >>> other peripherals.
> >>>
> >>> This change disables boot page translation after the secondary CPU
> >>> cores
> >>> have been initialized which allows the 0xfffffxxx address space to  
> >>> be
> >>> properly accessed.
> >>>
> >>> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> >>> ---
> >>> This was tested on the XPedite5370 which has flash mapped in the
> >>> 0xfffffxxx adddress space.  I verified the flash was accessible
> >>> as expected and Linux properly brought up 2 cores.
> >>>
> >>> I wasn't sure how the MPC8572 handled caching with respect to the  
> >>> boot
> >>> page translation.  I didn't add any cache flushes/invalidates, but
> >>> they
> >>> may be necessary if the 0xfffffxxx range is not mapped as  
> >>> uncachable.
> >>> Anyone at Freescale have any comments on this?
> >>>
> >>> Best,
> >>> Peter
> >>
> >> I'm concerned about this because we specifically avoid the 0xfffff000
> >> - 0xffffffff range since if we reset a core we want it to go through
> >> boot page translation.  Can you explain what you are putting at that
> >> address?
> >
> > Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB
> > flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 -
> > 0xffffffff.  We've used this convention for a while, before we started
> > using MPC8572s.
> >
> > U-Boot is always stored at in the flash at 0xfff80000 on the
> > MPC85xx-based boards we support.  Thus I couldn't reprogram U-Boot  
> > when
> > CONFIG_MP was defined since the top 4K of flash was really accessing
> > SDRAM because of the boot page translation.
> >
> > With this patch boot page translation is still used to bring up the
> > secondary cores on power on.  This change just makes it so that boot
> > page translation is disabled after the other cores are brought up.
> 
> I understand what the patch does.  It just removes the capability of  
> soft-resetting a core back into the boot translation code.  I  
> understand your problem I'm just not keen on solving it by completely  
> disabling boot translation.
> 
> We had a similar memory map and I moved away from it because of the  
> reset vector issues.  Additionally, things like >4G of memory also  
> start creeping up.

I'm not super familiar with how the MP support in U-Boot is used.  Would
you be resetting a secondary core for debug purposes?  Or is there an
example of when you'd reset one in normal operation?  I thought normal
operation was to use the "cpu release" command, or to let the OS
manually take the secondary cores out of their wait loops.

What if I spruced up cpu_reset() to temporarily re-enable boot page
translation, then disabled it again?  (And maybe re-initialized the cpus
MP table so that it could properly ack the primary core similar to in
pq3_mp_up().

It seems somewhat dirty to me to constantly keep boot page translation
enabled, even when its not needed.  Especially since it would require us
to change our memory map, environment variable scripts, documentation,
etc on all our boards:)

I'd be happy to look into an alternate workaround if you have an idea
for a cleaner implementation.

Best,
Peter

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Kumar Gala]

On Jul 7, 2009, at 5:38 PM, Peter Tyser wrote:

> On Tue, 2009-07-07 at 17:24 -0500, Kumar Gala wrote:
>> On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
>>
>>> On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
>>>> On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
>>>>
>>>>> Previously, boot page translation was enabled while U-Boot  
>>>>> executed.
>>>>> This resulted in the address range 0xfffff000 - 0xffffffff being
>>>>> translated to SDRAM which made the 0xfffffxxx address space  
>>>>> unusable
>>>>> for
>>>>> other peripherals.
>>>>>
>>>>> This change disables boot page translation after the secondary CPU
>>>>> cores
>>>>> have been initialized which allows the 0xfffffxxx address space to
>>>>> be
>>>>> properly accessed.
>>>>>
>>>>> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
>>>>> ---
>>>>> This was tested on the XPedite5370 which has flash mapped in the
>>>>> 0xfffffxxx adddress space.  I verified the flash was accessible
>>>>> as expected and Linux properly brought up 2 cores.
>>>>>
>>>>> I wasn't sure how the MPC8572 handled caching with respect to the
>>>>> boot
>>>>> page translation.  I didn't add any cache flushes/invalidates, but
>>>>> they
>>>>> may be necessary if the 0xfffffxxx range is not mapped as
>>>>> uncachable.
>>>>> Anyone at Freescale have any comments on this?
>>>>>
>>>>> Best,
>>>>> Peter
>>>>
>>>> I'm concerned about this because we specifically avoid the  
>>>> 0xfffff000
>>>> - 0xffffffff range since if we reset a core we want it to go  
>>>> through
>>>> boot page translation.  Can you explain what you are putting at  
>>>> that
>>>> address?
>>>
>>> Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB
>>> flashes - 1 from 0xf0000000-0xf7f00000 and the other from  
>>> 0xf8000000 -
>>> 0xffffffff.  We've used this convention for a while, before we  
>>> started
>>> using MPC8572s.
>>>
>>> U-Boot is always stored at in the flash at 0xfff80000 on the
>>> MPC85xx-based boards we support.  Thus I couldn't reprogram U-Boot
>>> when
>>> CONFIG_MP was defined since the top 4K of flash was really accessing
>>> SDRAM because of the boot page translation.
>>>
>>> With this patch boot page translation is still used to bring up the
>>> secondary cores on power on.  This change just makes it so that boot
>>> page translation is disabled after the other cores are brought up.
>>
>> I understand what the patch does.  It just removes the capability of
>> soft-resetting a core back into the boot translation code.  I
>> understand your problem I'm just not keen on solving it by completely
>> disabling boot translation.
>>
>> We had a similar memory map and I moved away from it because of the
>> reset vector issues.  Additionally, things like >4G of memory also
>> start creeping up.
>
> I'm not super familiar with how the MP support in U-Boot is used.   
> Would
> you be resetting a secondary core for debug purposes?  Or is there an
> example of when you'd reset one in normal operation?  I thought normal
> operation was to use the "cpu release" command, or to let the OS
> manually take the secondary cores out of their wait loops.
>
> What if I spruced up cpu_reset() to temporarily re-enable boot page
> translation, then disabled it again?  (And maybe re-initialized the  
> cpus
> MP table so that it could properly ack the primary core similar to in
> pq3_mp_up().
>
> It seems somewhat dirty to me to constantly keep boot page translation
> enabled, even when its not needed.  Especially since it would  
> require us
> to change our memory map, environment variable scripts, documentation,
> etc on all our boards:)
>
> I'd be happy to look into an alternate workaround if you have an idea
> for a cleaner implementation.

The idea is after u-boot if you soft-reset a core that it would go  
back into the spin table code.  U-boot is long gone at this point.

- k

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Peter Tyser]

On Wed, 2009-07-08 at 10:52 -0500, Kumar Gala wrote:
> On Jul 7, 2009, at 5:38 PM, Peter Tyser wrote:
> 
> > On Tue, 2009-07-07 at 17:24 -0500, Kumar Gala wrote:
> >> On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
> >>
> >>> On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
> >>>> On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
> >>>>
> >>>>> Previously, boot page translation was enabled while U-Boot  
> >>>>> executed.
> >>>>> This resulted in the address range 0xfffff000 - 0xffffffff being
> >>>>> translated to SDRAM which made the 0xfffffxxx address space  
> >>>>> unusable
> >>>>> for
> >>>>> other peripherals.
> >>>>>
> >>>>> This change disables boot page translation after the secondary CPU
> >>>>> cores
> >>>>> have been initialized which allows the 0xfffffxxx address space to
> >>>>> be
> >>>>> properly accessed.
> >>>>>
> >>>>> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> >>>>> ---
> >>>>> This was tested on the XPedite5370 which has flash mapped in the
> >>>>> 0xfffffxxx adddress space.  I verified the flash was accessible
> >>>>> as expected and Linux properly brought up 2 cores.
> >>>>>
> >>>>> I wasn't sure how the MPC8572 handled caching with respect to the
> >>>>> boot
> >>>>> page translation.  I didn't add any cache flushes/invalidates, but
> >>>>> they
> >>>>> may be necessary if the 0xfffffxxx range is not mapped as
> >>>>> uncachable.
> >>>>> Anyone at Freescale have any comments on this?
> >>>>>
> >>>>> Best,
> >>>>> Peter
> >>>>
> >>>> I'm concerned about this because we specifically avoid the  
> >>>> 0xfffff000
> >>>> - 0xffffffff range since if we reset a core we want it to go  
> >>>> through
> >>>> boot page translation.  Can you explain what you are putting at  
> >>>> that
> >>>> address?
> >>>
> >>> Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB
> >>> flashes - 1 from 0xf0000000-0xf7f00000 and the other from  
> >>> 0xf8000000 -
> >>> 0xffffffff.  We've used this convention for a while, before we  
> >>> started
> >>> using MPC8572s.
> >>>
> >>> U-Boot is always stored at in the flash at 0xfff80000 on the
> >>> MPC85xx-based boards we support.  Thus I couldn't reprogram U-Boot
> >>> when
> >>> CONFIG_MP was defined since the top 4K of flash was really accessing
> >>> SDRAM because of the boot page translation.
> >>>
> >>> With this patch boot page translation is still used to bring up the
> >>> secondary cores on power on.  This change just makes it so that boot
> >>> page translation is disabled after the other cores are brought up.
> >>
> >> I understand what the patch does.  It just removes the capability of
> >> soft-resetting a core back into the boot translation code.  I
> >> understand your problem I'm just not keen on solving it by completely
> >> disabling boot translation.
> >>
> >> We had a similar memory map and I moved away from it because of the
> >> reset vector issues.  Additionally, things like >4G of memory also
> >> start creeping up.
> >
> > I'm not super familiar with how the MP support in U-Boot is used.   
> > Would
> > you be resetting a secondary core for debug purposes?  Or is there an
> > example of when you'd reset one in normal operation?  I thought normal
> > operation was to use the "cpu release" command, or to let the OS
> > manually take the secondary cores out of their wait loops.
> >
> > What if I spruced up cpu_reset() to temporarily re-enable boot page
> > translation, then disabled it again?  (And maybe re-initialized the  
> > cpus
> > MP table so that it could properly ack the primary core similar to in
> > pq3_mp_up().
> >
> > It seems somewhat dirty to me to constantly keep boot page translation
> > enabled, even when its not needed.  Especially since it would  
> > require us
> > to change our memory map, environment variable scripts, documentation,
> > etc on all our boards:)
> >
> > I'd be happy to look into an alternate workaround if you have an idea
> > for a cleaner implementation.
> 
> The idea is after u-boot if you soft-reset a core that it would go  
> back into the spin table code.  U-boot is long gone at this point.

Are there common scenarios where a core would be reset after its already
booted an OS?  If an OS did need to soft-reset a secondary core,
shouldn't the OS be responsible for ensuring boot page translation is
enabled, its translating to the proper location, etc?  For example, I
imagine non-Linux OSes bring up secondary cores in different manners and
some wouldn't re-utilize U-Boot's boot page code located in SDRAM at
all, thus they wouldn't want the boot page translation always enabled.

It just seems less than ideal to have a chunk of memory space that
somewhat magically accesses a completely different, unintuitive address
space.  Someone else ran into the same issue already:
http://www.mail-archive.com/u-boot at lists.denx.de/msg08361.html

I realize there's a tradeoff between keeping the translation enabled vs
disabled, I'm just not familiar with how OSes utilize the secondary
cores to know what the downsides of disabling translation are...

Best,
Peter

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Peter Tyser]

Hi Kumar,

> > >> I understand what the patch does.  It just removes the capability of
> > >> soft-resetting a core back into the boot translation code.  I
> > >> understand your problem I'm just not keen on solving it by completely
> > >> disabling boot translation.
> > >>
> > >> We had a similar memory map and I moved away from it because of the
> > >> reset vector issues.  Additionally, things like >4G of memory also
> > >> start creeping up.
> > >
> > > I'm not super familiar with how the MP support in U-Boot is used.   
> > > Would
> > > you be resetting a secondary core for debug purposes?  Or is there an
> > > example of when you'd reset one in normal operation?  I thought normal
> > > operation was to use the "cpu release" command, or to let the OS
> > > manually take the secondary cores out of their wait loops.
> > >
> > > What if I spruced up cpu_reset() to temporarily re-enable boot page
> > > translation, then disabled it again?  (And maybe re-initialized the  
> > > cpus
> > > MP table so that it could properly ack the primary core similar to in
> > > pq3_mp_up().
> > >
> > > It seems somewhat dirty to me to constantly keep boot page translation
> > > enabled, even when its not needed.  Especially since it would  
> > > require us
> > > to change our memory map, environment variable scripts, documentation,
> > > etc on all our boards:)
> > >
> > > I'd be happy to look into an alternate workaround if you have an idea
> > > for a cleaner implementation.
> > 
> > The idea is after u-boot if you soft-reset a core that it would go  
> > back into the spin table code.  U-boot is long gone at this point.
> 
> Are there common scenarios where a core would be reset after its already
> booted an OS?  If an OS did need to soft-reset a secondary core,
> shouldn't the OS be responsible for ensuring boot page translation is
> enabled, its translating to the proper location, etc?  For example, I
> imagine non-Linux OSes bring up secondary cores in different manners and
> some wouldn't re-utilize U-Boot's boot page code located in SDRAM at
> all, thus they wouldn't want the boot page translation always enabled.
> 
> It just seems less than ideal to have a chunk of memory space that
> somewhat magically accesses a completely different, unintuitive address
> space.  Someone else ran into the same issue already:
> http://www.mail-archive.com/u-boot at lists.denx.de/msg08361.html
> 
> I realize there's a tradeoff between keeping the translation enabled vs
> disabled, I'm just not familiar with how OSes utilize the secondary
> cores to know what the downsides of disabling translation are...

Any feedback on my last email above, or is disabling boot page
translation just a no-go?

Or is there an more ideal alternative?  I really don't want to change up
the memory map on all our Freescale boards, documentation, dts files,
etc because of an optional 4KB chunk of memory space:)  I'm more than
willing to implement a different workaround if it means we can keep our
current memory map...

Thanks,
Peter

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Kumar Gala]

On Jul 22, 2009, at 10:47 AM, Peter Tyser wrote:

> Hi Kumar,
>
>>>>> I understand what the patch does.  It just removes the  
>>>>> capability of
>>>>> soft-resetting a core back into the boot translation code.  I
>>>>> understand your problem I'm just not keen on solving it by  
>>>>> completely
>>>>> disabling boot translation.
>>>>>
>>>>> We had a similar memory map and I moved away from it because of  
>>>>> the
>>>>> reset vector issues.  Additionally, things like >4G of memory also
>>>>> start creeping up.
>>>>
>>>> I'm not super familiar with how the MP support in U-Boot is used.
>>>> Would
>>>> you be resetting a secondary core for debug purposes?  Or is  
>>>> there an
>>>> example of when you'd reset one in normal operation?  I thought  
>>>> normal
>>>> operation was to use the "cpu release" command, or to let the OS
>>>> manually take the secondary cores out of their wait loops.
>>>>
>>>> What if I spruced up cpu_reset() to temporarily re-enable boot page
>>>> translation, then disabled it again?  (And maybe re-initialized the
>>>> cpus
>>>> MP table so that it could properly ack the primary core similar  
>>>> to in
>>>> pq3_mp_up().
>>>>
>>>> It seems somewhat dirty to me to constantly keep boot page  
>>>> translation
>>>> enabled, even when its not needed.  Especially since it would
>>>> require us
>>>> to change our memory map, environment variable scripts,  
>>>> documentation,
>>>> etc on all our boards:)
>>>>
>>>> I'd be happy to look into an alternate workaround if you have an  
>>>> idea
>>>> for a cleaner implementation.
>>>
>>> The idea is after u-boot if you soft-reset a core that it would go
>>> back into the spin table code.  U-boot is long gone at this point.
>>
>> Are there common scenarios where a core would be reset after its  
>> already
>> booted an OS?  If an OS did need to soft-reset a secondary core,
>> shouldn't the OS be responsible for ensuring boot page translation is
>> enabled, its translating to the proper location, etc?  For example, I
>> imagine non-Linux OSes bring up secondary cores in different  
>> manners and
>> some wouldn't re-utilize U-Boot's boot page code located in SDRAM at
>> all, thus they wouldn't want the boot page translation always  
>> enabled.
>>
>> It just seems less than ideal to have a chunk of memory space that
>> somewhat magically accesses a completely different, unintuitive  
>> address
>> space.  Someone else ran into the same issue already:
>> http://www.mail-archive.com/u-boot at lists.denx.de/msg08361.html
>>
>> I realize there's a tradeoff between keeping the translation  
>> enabled vs
>> disabled, I'm just not familiar with how OSes utilize the secondary
>> cores to know what the downsides of disabling translation are...
>
> Any feedback on my last email above, or is disabling boot page
> translation just a no-go?

It is at this point.

> Or is there an more ideal alternative?  I really don't want to  
> change up
> the memory map on all our Freescale boards, documentation, dts files,
> etc because of an optional 4KB chunk of memory space:)  I'm more than
> willing to implement a different workaround if it means we can keep  
> our
> current memory map...

I'd be fine if we want to add a CONFIG_ option to do the disable so  
board ports that need/want it can do it.

- k

[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Peter Tyser]

> > Any feedback on my last email above, or is disabling boot page
> > translation just a no-go?
> 
> It is at this point.
> 
> > Or is there an more ideal alternative?  I really don't want to  
> > change up
> > the memory map on all our Freescale boards, documentation, dts files,
> > etc because of an optional 4KB chunk of memory space:)  I'm more than
> > willing to implement a different workaround if it means we can keep  
> > our
> > current memory map...
> 
> I'd be fine if we want to add a CONFIG_ option to do the disable so  
> board ports that need/want it can do it.

OK, that sounds good.  I'll implement and test.  Thanks,

Peter