RE: TLB and CSSBAR problems with MPC8540 and BDI2000

RE: TLB and CSSBAR problems with MPC8540 and BDI2000

[Milliorn Gary-rxcr80]

> From: owner-linuxppc-embedded@lists.linuxppc.org
> [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Dan
> Malek
>
> Yep.  I have one now.  Make sure your u-boot image also has a TLB1
> entry for your "default" CCSRBAR.  Further, make sure your BDI init
> section doesn't move the CCSRBAR from the default value assumed by
> your u-boot image.  I had the latter correct, just didn't realize
> that a "TLB1 flash invalidate" command to the MMUCSR0 doesn't seem
> to honor the 'invalidate protect' in the TLB entry.  Everything
> works fine when you get all of the ducks in a row :-)

  The TLB1 issue is due to the MPC85x0 errata "CPU4"; there's a s/w
workaround.  It's nice if BDI fixes it for you, but seems like it would
not be necessary.

Gary Milliorn

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Dan Malek]

Milliorn Gary-rxcr80 wrote:

>   The TLB1 issue is due to the MPC85x0 errata "CPU4"; there's a s/w
> workaround.  It's nice if BDI fixes it for you, but seems like it would
> not be necessary.

The BDI doesn't fix anything.  I was just expecting the 'invalidate
protect' to actually do that. :-)  I set up several TLB1 entries during
the BDI initialization prior to debugging the boot rom.  The boot rom
then does a flash invalidate and loads up a "new" set of TLB1 entries.
I was expecting the values I set with the BDI to co-exist with the
new ones, but that doesn't seem to be the case.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: TLB and CSSBAR problems with MPC8540 and BDI2000

[Matthew S. McClintock]

On Wed, 2004-01-14 at 11:19, Milliorn Gary-rxcr80 wrote:

> >
> > Yep.  I have one now.  Make sure your u-boot image also has a TLB1
> > entry for your "default" CCSRBAR.  Further, make sure your BDI init
> > section doesn't move the CCSRBAR from the default value assumed by
> > your u-boot image.  I had the latter correct, just didn't realize
> > that a "TLB1 flash invalidate" command to the MMUCSR0 doesn't seem
> > to honor the 'invalidate protect' in the TLB entry.  Everything
> > works fine when you get all of the ducks in a row :-)
>
>   The TLB1 issue is due to the MPC85x0 errata "CPU4"; there's a s/w
> workaround.  It's nice if BDI fixes it for you, but seems like it would
> not be necessary.
>

	So I have noticed some things, maybe someone here can explain this.
When If configure everything with my bdi2000 and attempt to boot u-boot
my CPU will crash (COP freeze) when I get to the code that implements
the software workaround that was mentioned above.

	However if I do not configure anything with the bdi2000, and boot
u-boot, it will load just fine. I have even removed the code that causes
the crash in u-boot, recompiled u-boot and with those changes u-boot
will not crash the CPU. But, that same u-boot image will not boot if I
do not have the bdi2000 attached.

	So I guess the question is, what could be configured that would cause
this CPU to crash when the code for the errata was executed?

Here is the code for the workaround:

/* invalidate MMU L1/L2 */
/* Note: before invalidate MMU L1/L2, we read TLB1 Entry 0 and then
 * write it back immediately to fixup a bug(Errata CPU4)  for this
initial
 * TLB1 entry 0,otherwise the TLB1 entry 0 will be invalidated.
 */
#if defined(CONFIG_MPC85xx_REV1)
	lis	r2,0x1000
	mtspr	MAS0,r2
	tlbre
	tlbwe
	isync
	li      r2, 0x001e
	mtspr   MMUCSR0, r2
	isync
#endif

--
Matthew S. McClintock <mattsm@arlut.utexas.edu>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Kumar Gala]

Matthew,

Can you try something out.  I wondering if its the tlbre/tlbwe that's
causing problems or the MMU flash invalidate. (i'm guessing the 2nd.

Can you try adding this code back in and see what happens.  It looks to
me that the #ifdef is to generous to start with.  The invalidation of
the MMU is not really part of the work around.

#if defined(CONFIG_MPC85xx_REV1)
	lis	r2,0x1000
	mtspr	MAS0,r2
	tlbre
	tlbwe
	isync
#if 0
	li      r2, 0x001e
	mtspr   MMUCSR0, r2
	isync
#endif
#endif

- kumar

On Jan 28, 2004, at 9:57 AM, Matthew S. McClintock wrote:

>
> On Wed, 2004-01-14 at 11:19, Milliorn Gary-rxcr80 wrote:
>
>>>
>>> Yep.  I have one now.  Make sure your u-boot image also has a TLB1
>>> entry for your "default" CCSRBAR.  Further, make sure your BDI init
>>> section doesn't move the CCSRBAR from the default value assumed by
>>> your u-boot image.  I had the latter correct, just didn't realize
>>> that a "TLB1 flash invalidate" command to the MMUCSR0 doesn't seem
>>> to honor the 'invalidate protect' in the TLB entry.  Everything
>>> works fine when you get all of the ducks in a row :-)
>>
>>   The TLB1 issue is due to the MPC85x0 errata "CPU4"; there's a s/w
>> workaround.  It's nice if BDI fixes it for you, but seems like it
>> would
>> not be necessary.
>>
>
> 	So I have noticed some things, maybe someone here can explain this.
> When If configure everything with my bdi2000 and attempt to boot u-boot
> my CPU will crash (COP freeze) when I get to the code that implements
> the software workaround that was mentioned above.
>
> 	However if I do not configure anything with the bdi2000, and boot
> u-boot, it will load just fine. I have even removed the code that
> causes
> the crash in u-boot, recompiled u-boot and with those changes u-boot
> will not crash the CPU. But, that same u-boot image will not boot if I
> do not have the bdi2000 attached.
>
> 	So I guess the question is, what could be configured that would cause
> this CPU to crash when the code for the errata was executed?
>
> Here is the code for the workaround:
>
> /* invalidate MMU L1/L2 */
> /* Note: before invalidate MMU L1/L2, we read TLB1 Entry 0 and then
>  * write it back immediately to fixup a bug(Errata CPU4)  for this
> initial
>  * TLB1 entry 0,otherwise the TLB1 entry 0 will be invalidated.
>  */
> #if defined(CONFIG_MPC85xx_REV1)
> 	lis	r2,0x1000
> 	mtspr	MAS0,r2
> 	tlbre
> 	tlbwe
> 	isync
> 	li      r2, 0x001e
> 	mtspr   MMUCSR0, r2
> 	isync
> #endif
>
> --
> Matthew S. McClintock <mattsm@arlut.utexas.edu>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Matthew S. McClintock]

Now it does not freeze at that code, but it freezes later right after it
jumps to the code in ram. If I look at where u-boot should be in memory
I see the following:

0ffdc000 : c09566a0 45fd08eb c89576d5 01fd28eb  ..f.E.....v...(.
0ffdc010 : c0fb66d7 45fd08eb c8fb76a0 05fd28eb  ..f.E.....v...(.
0ffdc020 : c89566d5 45fd08eb c8fb66d5 45fd08eb  ..f.E.....f.E...
0ffdc030 : c0db66a0 45fd08eb c89576d5 41fd28eb  ..f.E.....v.A.(.
0ffdc040 : c8fb66d7 45fd08eb c0fb66a0 45fd08eb  ..f.E.....f.E...
0ffdc050 : c89566d5 45fd08eb c0fb66d5 45fd08eb  ..f.E.....f.E...
0ffdc060 : c8fb66a0 45fd08eb c89576d5 45fd28eb  ..f.E.....v.E.(.
0ffdc070 : c0fb76d7 45fd28eb c8fb76a0 45fd28eb  ..v.E.(...v.E.(.
0ffdc080 : c09566d5 45fd08eb c8fb66d5 45fd08eb  ..f.E.....f.E...
...
...

Something went wrong =) Any ideas?

Matthew

On Wed, 2004-01-28 at 10:10, Kumar Gala wrote:
> Matthew,
>
> Can you try something out.  I wondering if its the tlbre/tlbwe that's
> causing problems or the MMU flash invalidate. (i'm guessing the 2nd.
>
> Can you try adding this code back in and see what happens.  It looks to
> me that the #ifdef is to generous to start with.  The invalidation of
> the MMU is not really part of the work around.
>
> #if defined(CONFIG_MPC85xx_REV1)
> 	lis	r2,0x1000
> 	mtspr	MAS0,r2
> 	tlbre
> 	tlbwe
> 	isync
> #if 0
> 	li      r2, 0x001e
> 	mtspr   MMUCSR0, r2
> 	isync
> #endif
> #endif
>
> - kumar
>
> On Jan 28, 2004, at 9:57 AM, Matthew S. McClintock wrote:
>
> >
> > On Wed, 2004-01-14 at 11:19, Milliorn Gary-rxcr80 wrote:
> >
> >>>
> >>> Yep.  I have one now.  Make sure your u-boot image also has a TLB1
> >>> entry for your "default" CCSRBAR.  Further, make sure your BDI init
> >>> section doesn't move the CCSRBAR from the default value assumed by
> >>> your u-boot image.  I had the latter correct, just didn't realize
> >>> that a "TLB1 flash invalidate" command to the MMUCSR0 doesn't seem
> >>> to honor the 'invalidate protect' in the TLB entry.  Everything
> >>> works fine when you get all of the ducks in a row :-)
> >>
> >>   The TLB1 issue is due to the MPC85x0 errata "CPU4"; there's a s/w
> >> workaround.  It's nice if BDI fixes it for you, but seems like it
> >> would
> >> not be necessary.
> >>
> >
> > 	So I have noticed some things, maybe someone here can explain this.
> > When If configure everything with my bdi2000 and attempt to boot u-boot
> > my CPU will crash (COP freeze) when I get to the code that implements
> > the software workaround that was mentioned above.
> >
> > 	However if I do not configure anything with the bdi2000, and boot
> > u-boot, it will load just fine. I have even removed the code that
> > causes
> > the crash in u-boot, recompiled u-boot and with those changes u-boot
> > will not crash the CPU. But, that same u-boot image will not boot if I
> > do not have the bdi2000 attached.
> >
> > 	So I guess the question is, what could be configured that would cause
> > this CPU to crash when the code for the errata was executed?
> >
> > Here is the code for the workaround:
> >
> > /* invalidate MMU L1/L2 */
> > /* Note: before invalidate MMU L1/L2, we read TLB1 Entry 0 and then
> >  * write it back immediately to fixup a bug(Errata CPU4)  for this
> > initial
> >  * TLB1 entry 0,otherwise the TLB1 entry 0 will be invalidated.
> >  */
> > #if defined(CONFIG_MPC85xx_REV1)
> > 	lis	r2,0x1000
> > 	mtspr	MAS0,r2
> > 	tlbre
> > 	tlbwe
> > 	isync
> > 	li      r2, 0x001e
> > 	mtspr   MMUCSR0, r2
> > 	isync
> > #endif
> >
> > --
> > Matthew S. McClintock <mattsm@arlut.utexas.edu>
> >
> >
>
>
--
Matthew S. McClintock <mattsm@arlut.utexas.edu>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [Q] question about using x86 gdb to debug the remote ppc target (kgdb)

[Christopher R. Johnson]

You need to do a special "target" build of the gdb host side support.
 When you get the gdb sources, run the configure script something like this:

./configure --target=powerpc-405-linux-gnu --prefix=<locatin of cross
compile tools> --program-prefix=powerpc-405-linux-gnu-

This is what I do (obviously for the 405 processor).  --target tells gdb
that your target is embedded Linux on a 405.  --prefix is used to figure
out where the cross compilation tools are installed (like gcc, ld, etc.)
 --program-prefix creates the executables with a special prefix on the
filenames, which is quite important since you probably don't want to
replace your normal intel gdb program.  That way I end up running
something called powerpc-405-linux-gnu-gdb.

If you want gdbserver on the target machine, there's even more fun to
get that built right.

Hope this helps...

cj

kotaeji wrote:

>Hi, I have a question about using kgdb on PowerPC (8245)
>
>Is it possible that the host is x86, and the remote target
>is powerpc as following picture ?
>
>    HOST(x86)  ----------------------------- TARGET(ppc)
>      gdb              serial line           kgdb patch
>
>When I connect to target by gdb on x86 and do "info registers"
>to show target registers, it shows x86 registers.
>
>(gdb) info registers
>eax            0x2000   8192
>ecx            0xc3c6dd00       -1010377472
>edx            0xc3c6c000       -1010384896
>ebx            0xc0341540       -1070328512
>esp            0xc0341400       0xc0341400
>ebp            0xc3c6dd80       0xc3c6dd80
>esi            0xc3c6de4c       -1010377140
>edi            0x280008e8       671090920
>eip            0x0      0x0
>eflags         0x2      2
>cs             0x0      0
>ss             0xc5000000       -989855744
>ds             0xfed2a80        267201152
>es             0x10020300       268567296
>fs             0x0      0
>gs             0x0      0
>
>
>Is there any way that I can use x86 gdb to debug remote ppc target?
>Should I use powerpc gdb (like YellowDog) in order to debug
>ppc target?
>
>Any comments appreciated.
>
>
>

--
Christopher R. Johnson
Principal Software Engineer
GCC Printers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

TLB and CSSBAR problems with MPC8540 and BDI2000

[Fahd Abidi]

Hi,

I have a customer trying to get kernel debugging working with the BDI2000,
currently he is experiencing this problem:

My board is crashing on this particular piece of code:

/* invalidate MMU L1/L2 */
/* Note: before invalidate MMU L1/L2, we read TLB1 Entry 0 and then
 * write it back immediately to fixup a bug(Errata CPU4)  for this
	initial
 * TLB1 entry 0,otherwise the TLB1 entry 0 will be invalidated.
 */
#if defined(CONFIG_MPC85xx_REV1)
	lis	r2,0x1000
	mtspr	MAS0,r2
	tlbre
	tlbwe
	isync
	li      r2, 0x001e
	mtspr   MMUCSR0, r2
	isync
#endif

I think my problem is all centered around TLB's and the CCSRBAR. I don't
know if the above code is part of the problem but at reset the cpu has
the CCSRBAR at 0xff700000 and there is a TLB entry mapped to its
location. My init code is moving the CCSRBAR and mapping a TLB to its
new location. I tried just moving the CCSRBAR back to its default
location. Do I also need to remap a TLB address to default location?

Thanks,
Matthew

Does anyone know the answer to this problem?

thanks,

Fahd


begin 666 ATT00010.htm
M/"%$3T-465!%($A434P@4%5"3$E#("(M+R]7,T,O+T141"!(5$U,(#,N,B\O
M14XB/@T*/$A434P^#0H\2$5!1#X-"CQ-151!($A45% M15%5258](D-O;G1E
M;G0M5'EP92(@0T].5$5.5#TB=&5X="]H=&UL.R!C:&%R<V5T/7=I;F1O=W,M
M,3(U,B(^#0H\345402!.04U%/2)'96YE<F%T;W(B($-/3E1%3E0](DU3($5X
M8VAA;F=E(%-E<G9E<B!V97)S:6]N(#8N,"XV,C0Y+C$B/@T*/%1)5$Q%/E1,
M0B!A;F0@0U-30D%2('!R;V)L96US('=I=&@@35!#.#4T,"!A;F0@0D1),C P
M,#PO5$E43$4^#0H\+TA%040^#0H\0D]$63X-"CPA+2T@0V]N=F5R=&5D(&9R
M;VT@=&5X="]P;&%I;B!F;W)M870@+2T^#0H-"CQ0/CQ&3TY4(%-)6D4],CY(
M:2P\+T9/3E0^#0H\+U ^#0H-"CQ0/CQ&3TY4(%-)6D4],CY)(&AA=F4@82!C
M=7-T;VUE<B!T<GEI;F<@=&\@9V5T(&ME<FYE;"!D96)U9V=I;F<@=V]R:VEN
M9R!W:71H('1H92!"1$DR,# P+"!C=7)R96YT;'D@:&4@:7,@97AP97)I96YC
M:6YG('1H:7,@<')O8FQE;3H\+T9/3E0^#0H\+U ^#0H-"CQ0/CQ&3TY4(%-)
M6D4],CY->2!B;V%R9"!I<R!C<F%S:&EN9R!O;B!T:&ES('!A<G1I8W5L87(@
M<&EE8V4@;V8@8V]D93H\+T9/3E0^#0H\+U ^#0H-"CQ0/CQ&3TY4(%-)6D4]
M,CXO*B!I;G9A;&ED871E($U-52!,,2],,B J+SPO1D].5#X-"@T*/$)2/CQ&
M3TY4(%-)6D4],CXO*B!.;W1E.B!B969O<F4@:6YV86QI9&%T92!-354@3#$O
M3#(L('=E(')E860@5$Q",2!%;G1R>2 P(&%N9"!T:&5N/"]&3TY4/@T*#0H\
M0E(^/$9/3E0@4TE:13TR/B9N8G-P.RH@=W)I=&4@:70@8F%C:R!I;6UE9&EA
M=&5L>2!T;R!F:7AU<"!A(&)U9RA%<G)A=&$@0U!5-"DF;F)S<#L@9F]R('1H
M:7,\+T9/3E0^#0H-"CQ"4CXF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S
M<#LF;F)S<#LF;F)S<#L@/$9/3E0@4TE:13TR/FEN:71I86P\+T9/3E0^#0H-
M"CQ"4CX\1D].5"!325I%/3(^)FYB<W [*B!43$(Q(&5N=')Y(# L;W1H97)W
M:7-E('1H92!43$(Q(&5N=')Y(# @=VEL;"!B92!I;G9A;&ED871E9"X\+T9/
M3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^)FYB<W [*B\\+T9/3E0^#0H-"CQ"
M4CX\1D].5"!325I%/3(^(VEF(&1E9FEN960H0T].1DE'7TU00S@U>'A?4D56
M,2D\+T9/3E0^#0H-"CQ"4CXF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S
M<#LF;F)S<#LF;F)S<#L@/$9/3E0@4TE:13TR/FQI<R9N8G-P.R9N8G-P.R9N
M8G-P.R9N8G-P.R!R,BPP>#$P,# \+T9/3E0^#0H-"CQ"4CXF;F)S<#LF;F)S
M<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#L@/$9/3E0@4TE:13TR
M/FUT<W!R)FYB<W [)FYB<W [($U!4S L<C(\+T9/3E0^#0H-"CQ"4CXF;F)S
M<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#L@/$9/3E0@
M4TE:13TR/G1L8G)E/"]&3TY4/@T*#0H\0E(^)FYB<W [)FYB<W [)FYB<W [
M)FYB<W [)FYB<W [)FYB<W [)FYB<W [(#Q&3TY4(%-)6D4],CYT;&)W93PO
M1D].5#X-"@T*/$)2/B9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N8G-P.R9N
M8G-P.R9N8G-P.R \1D].5"!325I%/3(^:7-Y;F,\+T9/3E0^#0H-"CQ"4CXF
M;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#LF;F)S<#L@/$9/
M3E0@4TE:13TR/FQI)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [('(R
M+" P># P,64\+T9/3E0^#0H-"CQ"4CXF;F)S<#LF;F)S<#LF;F)S<#LF;F)S
M<#LF;F)S<#LF;F)S<#LF;F)S<#L@/$9/3E0@4TE:13TR/FUT<W!R)FYB<W [
M)FYB<W [($U-54-34C L('(R/"]&3TY4/@T*#0H\0E(^)FYB<W [)FYB<W [
M)FYB<W [)FYB<W [)FYB<W [)FYB<W [)FYB<W [(#Q&3TY4(%-)6D4],CYI
M<WEN8SPO1D].5#X-"@T*/$)2/CQ&3TY4(%-)6D4],CXC96YD:68\+T9/3E0^
M#0H\+U ^#0H-"CQ0/CQ&3TY4(%-)6D4],CY)('1H:6YK(&UY('!R;V)L96T@
M:7,@86QL(&-E;G1E<F5D(&%R;W5N9"!43$(G<R!A;F0@=&AE($-#4U)"05(N
M($D@9&]N)W0\+T9/3E0^#0H-"CQ"4CX\1D].5"!325I%/3(^:VYO=R!I9B!T
M:&4@86)O=F4@8V]D92!I<R!P87)T(&]F('1H92!P<F]B;&5M(&)U="!A="!R
M97-E="!T:&4@8W!U(&AA<SPO1D].5#X-"@T*/$)2/CQ&3TY4(%-)6D4],CYT
M:&4@0T-34D)!4B!A=" P>&9F-S P,# P(&%N9"!T:&5R92!I<R!A(%1,0B!E
M;G1R>2!M87!P960@=&\@:71S/"]&3TY4/@T*#0H\0E(^/$9/3E0@4TE:13TR
M/FQO8V%T:6]N+B!->2!I;FET(&-O9&4@:7,@;6]V:6YG('1H92!#0U-20D%2
M(&%N9"!M87!P:6YG(&$@5$Q"('1O(&ET<SPO1D].5#X-"@T*/$)2/CQ&3TY4
M(%-)6D4],CYN97<@;&]C871I;VXN($D@=')I960@:G5S="!M;W9I;F<@=&AE
M($-#4U)"05(@8F%C:R!T;R!I=',@9&5F875L=#PO1D].5#X-"@T*/$)2/CQ&
M3TY4(%-)6D4],CYL;V-A=&EO;BX@1&\@22!A;'-O(&YE960@=&\@<F5M87 @
M82!43$(@861D<F5S<R!T;R!D969A=6QT(&QO8V%T:6]N/R \+T9/3E0^#0H\
M+U ^#0H-"CQ0/CQ&3TY4(%-)6D4],CY4:&%N:W,L/"]&3TY4/@T*#0H\0E(^
M/$9/3E0@4TE:13TR/DUA='1H97<\+T9/3E0^#0H\+U ^#0H-"CQ0/CQ&3TY4
M(%-)6D4],CY$;V5S(&%N>6]N92!K;F]W('1H92!A;G-W97(@=&\@=&AI<R!P
M<F]B;&5M/SPO1D].5#X-"CPO4#X-"@T*/% ^/$9/3E0@4TE:13TR/G1H86YK
M<RP\+T9/3E0^#0H\+U ^#0H-"CQ0/CQ&3TY4(%-)6D4],CY&86AD/"]&3TY4
;/@T*/"]0/@T*#0H\+T)/1%D^#0H\+TA434P^
`
end


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Dan Malek]

Fahd Abidi wrote:

> I think my problem is all centered around TLB's and the CCSRBAR.

Yes, it is.

The debug control registers are part of the CCSRBAR space.  The
BDI2000 tracks modifications it makes if the space is moved, however,
if your software moves that space the BDI2000 doesn't know it and
can't access the registers.

If you are debugging code, like u-boot here, you have to make
several code modifications so the CCSR space isn't moved during your
debugging (among other things).


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Matthew S. McClintock]

 So more specifically, if the bdi2000 init section moves the CCSRBAR and
maps a TLB to the location the CCSRBAR was moved too you can't just
moved the CCSRBAR back to its default location? One would also need to
remap the TLB entry to CCSRBAR?

        Could anyone familiar with that workaround listed below verify
that
this could be causing the CPU to freeze/crash?

Thanks,
Matthew

On Fri, 2004-01-09 at 11:54, Dan Malek wrote:
> Fahd Abidi wrote:
>
> > I think my problem is all centered around TLB's and the CCSRBAR.
>
> Yes, it is.
>
> The debug control registers are part of the CCSRBAR space.  The
> BDI2000 tracks modifications it makes if the space is moved, however,
> if your software moves that space the BDI2000 doesn't know it and
> can't access the registers.
>
> If you are debugging code, like u-boot here, you have to make
> several code modifications so the CCSR space isn't moved during your
> debugging (among other things).
>
>
> 	-- Dan
>
>
--
Matthew S. McClintock <mattsm@arlut.utexas.edu>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Dan Malek]

Matthew S. McClintock wrote:

>  So more specifically, if the bdi2000 init section moves the CCSRBAR and
> maps a TLB to the location the CCSRBAR was moved too you can't just
> moved the CCSRBAR back to its default location?

     No, because the BDI2000 doesn't know that _you_ have done that in
     your code.  If you do it in the BDI init secion, it will know.


> .... One would also need to
> remap the TLB entry to CCSRBAR?

     Yes, but that isn't the problem.

>         Could anyone familiar with that workaround listed below verify
> that
> this could be causing the CPU to freeze/crash?

     I've been there and done it.  The CCSRBAR can't be changing while you
     are using the BDI2000 for debug.  The debug registers the BDI2000 is
     trying to access are in this space.  If you move the space without the
     BDI2000 knowing (i.e. in your code), the BDI2000 doesn't seem to be
     able to track those changes and continues to try and access the
     debug registers in the last known space.


     So, what you have to do is (simply :-) ensure the CCSRBAR isn't
     changing when you are debugging the software.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Matthew S. McClintock]

>
>      Yes, but that isn't the problem.
>
> >         Could anyone familiar with that workaround listed below verify
> > that
> > this could be causing the CPU to freeze/crash?
>
>      I've been there and done it.  The CCSRBAR can't be changing while you
>      are using the BDI2000 for debug.  The debug registers the BDI2000 is
>      trying to access are in this space.  If you move the space without the
>      BDI2000 knowing (i.e. in your code), the BDI2000 doesn't seem to be
>      able to track those changes and continues to try and access the
>      debug registers in the last known space.
>
>
>      So, what you have to do is (simply :-) ensure the CCSRBAR isn't
>      changing when you are debugging the software.

That leaves me with one question. When I don't do anything in the init
section of the bdi2000 except one command which is to remove the L2SRAM
from the initial MMU page and then I proceed with booting the board
boots fine. If I halt the board examine the CCSRBAR it has moved from
the default location.

I must be missing something, any ideas?

Thanks

--
Matthew S. McClintock <mattsm@arlut.utexas.edu>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Dan Malek]

Matthew S. McClintock wrote:

> That leaves me with one question. When I don't do anything in the init
> section of the bdi2000 except one command which is to remove the L2SRAM
> from the initial MMU page and then I proceed with booting the board
> boots fine. If I halt the board examine the CCSRBAR it has moved from
> the default location.

Hmmmmm....interesting.

> I must be missing something, any ideas?

Maybe I am :-)  I'll experiment some more and see.  I was just
describing my experince.  It could be the boot rom initializes far
enough during the BDI2000 power up delay that by the time the BDI2000
asks the cpu core for the CCSRBAR it has the new one?  I'll ask
Abatron and post the response.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Dan Malek]

Dan Malek wrote:

> ..... I'll ask
> Abatron and post the response.

I received their response.  Here it is in my words.

The BDI2000 doesn't care if the CCSRBAR is changed by software.
It uses SPRs for debug control, and if it needs to access anything
in the CCSR space, it will fetch the address from the part.

So, I guess there is something else that is incorrect when we
change the CCSRBAR.

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Matthew S. McClintock]

So that leaves us back at the original question. Why does configuring
the cpu via bdi2000 prevent me from using my u-boot image? Any other
ideas?

Thanks,
Matthew

On Mon, 2004-01-12 at 09:56, Dan Malek wrote:
> Dan Malek wrote:
>
> > ..... I'll ask
> > Abatron and post the response.
>
> I received their response.  Here it is in my words.
>
> The BDI2000 doesn't care if the CCSRBAR is changed by software.
> It uses SPRs for debug control, and if it needs to access anything
> in the CCSR space, it will fetch the address from the part.
>
> So, I guess there is something else that is incorrect when we
> change the CCSRBAR.
>
> Thanks.
>
>
> 	-- Dan
>
>
--
Matthew S. McClintock <mattsm@arlut.utexas.edu>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: TLB and CSSBAR problems with MPC8540 and BDI2000

[Dan Malek]

Matthew S. McClintock wrote:

> So that leaves us back at the original question. Why does configuring
> the cpu via bdi2000 prevent me from using my u-boot image? Any other
> ideas?

Yep.  I have one now.  Make sure your u-boot image also has a TLB1
entry for your "default" CCSRBAR.  Further, make sure your BDI init
section doesn't move the CCSRBAR from the default value assumed by
your u-boot image.  I had the latter correct, just didn't realize
that a "TLB1 flash invalidate" command to the MMUCSR0 doesn't seem
to honor the 'invalidate protect' in the TLB entry.  Everything
works fine when you get all of the ducks in a row :-)

Of course, we should be discussing this on the u-boot list,
not on this one........


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/