Patchwork [U-Boot,2/4,v2] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger

login
register
mail settings
Submitter Prabhakar Kushwaha
Date April 25, 2012, 8:25 a.m.
Message ID <1335342343-28501-1-git-send-email-prabhakar@freescale.com>
Download mbox | patch
Permalink /patch/154828/
State Superseded
Delegated to: Andy Fleming
Headers show

Comments

Prabhakar Kushwaha - April 25, 2012, 8:25 a.m.
Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always.
Where MSR = Machine State register

Make sure of MSR[DE] bit is set uniformaly across the different execution
address space i.e. AS0 and AS1.

Signed-off-by: Radu Lazarescu <radu.lazarescu@freescale.com>
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
Signed-off-by: Marius Grigoras <marius.grigoras@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
  Based upon git://git.denx.de/u-boot.git branch master

 Changes for v2: 
	- Avoid MSR_DE negation in arch_preboot
	- Made MSR_DE set code independent of any #define

No change, Resending again

 Tested on
  - SoC having E500 Family processor (P1010RDB, BSC9131RDB)
  - SoC having E500MC Family processor (P4080DS, P3041DS)

 arch/powerpc/cpu/mpc85xx/cpu_init.c |    2 +-
 arch/powerpc/cpu/mpc85xx/start.S    |    7 +++++--
 2 files changed, 6 insertions(+), 3 deletions(-)
Joakim Tjernlund - April 25, 2012, 10:57 a.m.
>
> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always.
> Where MSR = Machine State register
>
> Make sure of MSR[DE] bit is set uniformaly across the different execution
> address space i.e. AS0 and AS1.

Hi

We are trying to bring up our custom P2010 RDB based board. boot is NOR
based and we cannot get past the rfi below.
	lis	r6,MSR_IS|MSR_DS@h
	ori	r6,r6,MSR_IS|MSR_DS@l
	lis	r7,switch_as@h
	ori	r7,r7,switch_as@l

	mtspr	SPRN_SRR0,r7
	mtspr	SPRN_SRR1,r6
	rfi

switch_as:

We end up with a TLB exception no matter what we do, even after applying this patch.
Using a Abatron BDI3000 emluator

Any pointers as what to look for would be greatly appreciated.
Have anyone on the list managed to get past this rfi instruction using BDI3000?
What emulator config did you use?

 Jocke
>
> Signed-off-by: Radu Lazarescu <radu.lazarescu@freescale.com>
> Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
> Signed-off-by: Marius Grigoras <marius.grigoras@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
>   Based upon git://git.denx.de/u-boot.git branch master
>
>  Changes for v2:
>    - Avoid MSR_DE negation in arch_preboot
>    - Made MSR_DE set code independent of any #define
>
> No change, Resending again
>
>  Tested on
>   - SoC having E500 Family processor (P1010RDB, BSC9131RDB)
>   - SoC having E500MC Family processor (P4080DS, P3041DS)
>
>  arch/powerpc/cpu/mpc85xx/cpu_init.c |    2 +-
>  arch/powerpc/cpu/mpc85xx/start.S    |    7 +++++--
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> index 2e4a06c..3bcbffa 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> @@ -532,7 +532,7 @@ void arch_preboot_os(void)
>      * disabled by the time we get called.
>      */
>     msr = mfmsr();
> -   msr &= ~(MSR_ME|MSR_CE|MSR_DE);
> +   msr &= ~(MSR_ME|MSR_CE);
>     mtmsr(msr);
>
>     setup_ivors();
> diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
> index 7bfa2d5..597151b 100644
> --- a/arch/powerpc/cpu/mpc85xx/start.S
> +++ b/arch/powerpc/cpu/mpc85xx/start.S
> @@ -82,6 +82,9 @@
>     .globl _start_e500
>
>  _start_e500:
> +/* Enable debug exception */
> +   li   r1,MSR_DE
> +   mtmsr    r1
>
>  #if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC)
>     /* ISBC uses L2 as stack.
> @@ -729,8 +732,8 @@ create_init_ram_area:
>     msync
>     tlbwe
>
> -   lis   r6,MSR_IS|MSR_DS@h
> -   ori   r6,r6,MSR_IS|MSR_DS@l
> +   lis   r6,MSR_IS|MSR_DS|MSR_DE@h
> +   ori   r6,r6,MSR_IS|MSR_DS|MSR_DE@l
>     lis   r7,switch_as@h
>     ori   r7,r7,switch_as@l
>
> --
> 1.7.5.4
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Scott Wood - April 25, 2012, 6:43 p.m.
On 04/25/2012 05:57 AM, Joakim Tjernlund wrote:
>>
>> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always.
>> Where MSR = Machine State register
>>
>> Make sure of MSR[DE] bit is set uniformaly across the different execution
>> address space i.e. AS0 and AS1.
> 
> Hi
> 
> We are trying to bring up our custom P2010 RDB based board. boot is NOR
> based and we cannot get past the rfi below.
> 	lis	r6,MSR_IS|MSR_DS@h
> 	ori	r6,r6,MSR_IS|MSR_DS@l
> 	lis	r7,switch_as@h
> 	ori	r7,r7,switch_as@l
> 
> 	mtspr	SPRN_SRR0,r7
> 	mtspr	SPRN_SRR1,r6
> 	rfi
> 
> switch_as:
> 
> We end up with a TLB exception no matter what we do, even after applying this patch.

Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB?

-Scott
Joakim Tjernlund - April 25, 2012, 6:55 p.m.
Scott Wood <scottwood@freescale.com> wrote on 2012/04/25 20:43:22:
>
> On 04/25/2012 05:57 AM, Joakim Tjernlund wrote:
> >>
> >> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always.
> >> Where MSR = Machine State register
> >>
> >> Make sure of MSR[DE] bit is set uniformaly across the different execution
> >> address space i.e. AS0 and AS1.
> >
> > Hi
> >
> > We are trying to bring up our custom P2010 RDB based board. boot is NOR
> > based and we cannot get past the rfi below.
> >    lis   r6,MSR_IS|MSR_DS@h
> >    ori   r6,r6,MSR_IS|MSR_DS@l
> >    lis   r7,switch_as@h
> >    ori   r7,r7,switch_as@l
> >
> >    mtspr   SPRN_SRR0,r7
> >    mtspr   SPRN_SRR1,r6
> >    rfi
> >
> > switch_as:
> >
> > We end up with a TLB exception no matter what we do, even after applying this patch.
>
> Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB?

No, but this code is executed before any of the other parts of the patch. Anyhow, I just
found the problem(really obvious once I found it).
During bring up we had to load uboot in the middle of the flash instead of
the end because we have a flash burn problem in the end of the flash that we do not
understand yet. We think it may be related to DDR3 being misconfigured by the emulator(BDI3000).
I do not understand why this emulator can not use the L2SRAM instead? Is there something
magic behind the L2SRAM so it is impossible to use it as a work area for
flash burning?

 Jocke
Scott Wood - April 25, 2012, 6:59 p.m.
On 04/25/2012 01:55 PM, Joakim Tjernlund wrote:
> 
> Scott Wood <scottwood@freescale.com> wrote on 2012/04/25 20:43:22:
>>
>> On 04/25/2012 05:57 AM, Joakim Tjernlund wrote:
>>>>
>>>> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always.
>>>> Where MSR = Machine State register
>>>>
>>>> Make sure of MSR[DE] bit is set uniformaly across the different execution
>>>> address space i.e. AS0 and AS1.
>>>
>>> Hi
>>>
>>> We are trying to bring up our custom P2010 RDB based board. boot is NOR
>>> based and we cannot get past the rfi below.
>>>    lis   r6,MSR_IS|MSR_DS@h
>>>    ori   r6,r6,MSR_IS|MSR_DS@l
>>>    lis   r7,switch_as@h
>>>    ori   r7,r7,switch_as@l
>>>
>>>    mtspr   SPRN_SRR0,r7
>>>    mtspr   SPRN_SRR1,r6
>>>    rfi
>>>
>>> switch_as:
>>>
>>> We end up with a TLB exception no matter what we do, even after applying this patch.
>>
>> Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB?
> 
> No, but this code is executed before any of the other parts of the patch. Anyhow, I just
> found the problem(really obvious once I found it).
> During bring up we had to load uboot in the middle of the flash instead of
> the end because we have a flash burn problem in the end of the flash that we do not
> understand yet. We think it may be related to DDR3 being misconfigured by the emulator(BDI3000).
> I do not understand why this emulator can not use the L2SRAM instead? Is there something
> magic behind the L2SRAM so it is impossible to use it as a work area for
> flash burning?

I don't know of any reason L2SRAM couldn't be used for this.  My guess
is they just don't want to have to support more than one way of creating
RAM.

-Scott
Joakim Tjernlund - April 26, 2012, 7:01 a.m.
Scott Wood <scottwood@freescale.com> wrote on 2012/04/25 20:59:22:
>
> On 04/25/2012 01:55 PM, Joakim Tjernlund wrote:
> >
> > Scott Wood <scottwood@freescale.com> wrote on 2012/04/25 20:43:22:
> >>
> >> On 04/25/2012 05:57 AM, Joakim Tjernlund wrote:
> >>>>
> >>>> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always.
> >>>> Where MSR = Machine State register
> >>>>
> >>>> Make sure of MSR[DE] bit is set uniformaly across the different execution
> >>>> address space i.e. AS0 and AS1.
> >>>
> >>> Hi
> >>>
> >>> We are trying to bring up our custom P2010 RDB based board. boot is NOR
> >>> based and we cannot get past the rfi below.
> >>>    lis   r6,MSR_IS|MSR_DS@h
> >>>    ori   r6,r6,MSR_IS|MSR_DS@l
> >>>    lis   r7,switch_as@h
> >>>    ori   r7,r7,switch_as@l
> >>>
> >>>    mtspr   SPRN_SRR0,r7
> >>>    mtspr   SPRN_SRR1,r6
> >>>    rfi
> >>>
> >>> switch_as:
> >>>
> >>> We end up with a TLB exception no matter what we do, even after applying this patch.
> >>
> >> Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB?
> >
> > No, but this code is executed before any of the other parts of the patch. Anyhow, I just
> > found the problem(really obvious once I found it).
> > During bring up we had to load uboot in the middle of the flash instead of
> > the end because we have a flash burn problem in the end of the flash that we do not
> > understand yet. We think it may be related to DDR3 being misconfigured by the emulator(BDI3000).
> > I do not understand why this emulator can not use the L2SRAM instead? Is there something
> > magic behind the L2SRAM so it is impossible to use it as a work area for
> > flash burning?
>
> I don't know of any reason L2SRAM couldn't be used for this.  My guess
> is they just don't want to have to support more than one way of creating
> RAM.

Right, we will look into this some more then.

Back to our rfi problem. I think there is an bug in u-boot start.S.

This part is what you land in for NOR based boot:
#if !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SECURE_BOOT)
	/* create a temp mapping in AS=1 to the 4M boot window */
	lis     r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@h
	ori     r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@l

	lis     r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE & 0xffc00000, (MAS2_I|MAS2_G))@h
	ori     r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE & 0xffc00000, (MAS2_I|MAS2_G))@l

	/* The 85xx has the default boot window 0xff800000 - 0xffffffff */
	lis     r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h
	ori     r9,r9,FSL_BOOKE_MAS3(0xffc00000, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
Here r9 is fixed to 0xffc00000, this will only work for
CONFIG_SYS_MONITOR_BASE >= 0xffc00000 (we had a lower value)
I don't know how this should be changed so it works for all boards, we just copied
the values from the r8 settings to move on.

 Jocke

Patch

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 2e4a06c..3bcbffa 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -532,7 +532,7 @@  void arch_preboot_os(void)
 	 * disabled by the time we get called.
 	 */
 	msr = mfmsr();
-	msr &= ~(MSR_ME|MSR_CE|MSR_DE);
+	msr &= ~(MSR_ME|MSR_CE);
 	mtmsr(msr);
 
 	setup_ivors();
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 7bfa2d5..597151b 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -82,6 +82,9 @@ 
 	.globl _start_e500
 
 _start_e500:
+/* Enable debug exception */
+	li	r1,MSR_DE
+	mtmsr 	r1
 
 #if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC)
 	/* ISBC uses L2 as stack.
@@ -729,8 +732,8 @@  create_init_ram_area:
 	msync
 	tlbwe
 
-	lis	r6,MSR_IS|MSR_DS@h
-	ori	r6,r6,MSR_IS|MSR_DS@l
+	lis	r6,MSR_IS|MSR_DS|MSR_DE@h
+	ori	r6,r6,MSR_IS|MSR_DS|MSR_DE@l
 	lis	r7,switch_as@h
 	ori	r7,r7,switch_as@l