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

Joakim Tjernlund joakim.tjernlund at transmode.se
Thu Apr 26 09:01:12 CEST 2012


Scott Wood <scottwood at freescale.com> wrote on 2012/04/25 20:59:22:
>
> On 04/25/2012 01:55 PM, Joakim Tjernlund wrote:
> >
> > Scott Wood <scottwood at 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 at h
> >>>    ori   r6,r6,MSR_IS|MSR_DS at l
> >>>    lis   r7,switch_as at h
> >>>    ori   r7,r7,switch_as at 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




More information about the U-Boot mailing list