Linux Kernel Issue: MPC8540 Errata (CPU29)

Linux Kernel Issue: MPC8540 Errata (CPU29)

[Chiradeep Vittal]

We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
seeing an=20
"illegal instruction"  (SIGILL) exception under some circumstances=20
(during a pthread_create call). We were wondering if this could be a
symptom of=20
CPU29 and if there is a patch available for CPU29.

"CPU29 L1 instruction cache gets multiple entries for same line after
change=20
in MSR[IS] bit "

www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf


Thanks
--
Chiradeep Vittal
Matisse Networks Inc.=20

Re: Linux Kernel Issue: MPC8540 Errata (CPU29)

[Kumar Gala]

On Apr 27, 2005, at 12:46 PM, Chiradeep Vittal wrote:

> We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
>  seeing an
> "illegal instruction"=A0 (SIGILL) exception under some circumstances
> (during a pthread_create call). We were wondering if this could be a
> symptom of
> CPU29 and if there is a patch available for CPU29.
>
> "CPU29 L1 instruction cache gets multiple entries for same line after
>  change
> in MSR[IS] bit "
>
> www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf

The way the Linux kernel manages the MMU on e500 it doesn't actually=20
ever modify MSR[IS] or MSR[DS].  They are always zero so I dont believe=20=

you are hitting this errata.

Are you running with math emulation turned on?  Do you know what the=20
instruction is that causes the SIGILL?

- kumar

How to use SPE on MPC8541

[Gérard Guével]

Hi,

I am running a Linux 2.6.9 on a MPC8541 custom board.

I would like to run a user application which contains
some SPE code extracted from a freescale library.

I compiled the kernel with the CONFIG_SPE set to yes.
The application also compiles and I can run it on the
board.

But it seems the SPE bit from the MSR register
is not set when the process runs.

I tried to use a call to the enable_kernel_spe function
to force the bit, but it is always erased by the kernel (??)
when scheduling task and never set again.

Must I compile the application with some special flags
to instruct the kernel I want to use SPE ?

Thanks for any idea
Gérard

Re: How to use SPE on MPC8541

[Andy Fleming]

On Sep 27, 2005, at 10:30, G=E9rard Gu=E9vel wrote:

>
> Hi,
>
> I am running a Linux 2.6.9 on a MPC8541 custom board.
>
> I would like to run a user application which contains
> some SPE code extracted from a freescale library.
>
> I compiled the kernel with the CONFIG_SPE set to yes.
> The application also compiles and I can run it on the
> board.
>
> But it seems the SPE bit from the MSR register
> is not set when the process runs.
>
> I tried to use a call to the enable_kernel_spe function
> to force the bit, but it is always erased by the kernel (??)
> when scheduling task and never set again.
>
> Must I compile the application with some special flags
> to instruct the kernel I want to use SPE ?


You say the application runs, right?  So what made you check the SPE =20
bit state?  The kernel keeps SPE disabled by default so it doesn't =20
have to save the upper 32 bits of the registers every context =20
switch.  When a process uses SPE for the first time, an exception is =20
triggered, the kernel enables SPE for that process, and then that =20
process should be able to use SPE every time it gets cpu time.

How are you determining that the SPE bit is not set?  Is your =20
application not executing the SPE instructions?

Andy

RE: How to use SPE on MPC8541

[Gérard Guével]

> You say the application runs, right?  So what made you check the SPE
> bit state?  The kernel keeps SPE disabled by default so it doesn't
> have to save the upper 32 bits of the registers every context
> switch.  When a process uses SPE for the first time, an exception is
> triggered, the kernel enables SPE for that process, and then that
> process should be able to use SPE every time it gets cpu time.
>
> How are you determining that the SPE bit is not set?  Is your
> application not executing the SPE instructions?
>
> Andy

Yes the application runs. I wrote a mini driver with an ioctl which
performs a mfmsr() call and  returns the value to the user application.
I called this ioctl at several times before and after executing SPE code.
I already tried to manually force the SPE bit with another ioctl which
performs a enable_kernel_spe() call. The bit SPE is right set at this time
but disappears later.

I don't know if using ioctls is a right way to check the bit.

Any idea ?
Thanks
Gérard

Re: How to use SPE on MPC8541

[Andy Fleming]

On Sep 27, 2005, at 12:36, G=E9rard Gu=E9vel wrote:

>
>
>
>> You say the application runs, right?  So what made you check the SPE
>> bit state?  The kernel keeps SPE disabled by default so it doesn't
>> have to save the upper 32 bits of the registers every context
>> switch.  When a process uses SPE for the first time, an exception is
>> triggered, the kernel enables SPE for that process, and then that
>> process should be able to use SPE every time it gets cpu time.
>>
>> How are you determining that the SPE bit is not set?  Is your
>> application not executing the SPE instructions?
>>
>> Andy
>>
>
> Yes the application runs. I wrote a mini driver with an ioctl which
> performs a mfmsr() call and  returns the value to the user =20
> application.
> I called this ioctl at several times before and after executing SPE =20=

> code.
> I already tried to manually force the SPE bit with another ioctl which
> performs a enable_kernel_spe() call. The bit SPE is right set at =20
> this time
> but disappears later.

Your driver runs in kernel space.  The kernel has the SPE bit off.  =20
The MSR state is process-specific.  If the code executes, the MSR bit =20=

is set.  Why do you want to see if the bit is set?

RE: How to use SPE on MPC8541

[Gérard Guével]

Andy,

> Your driver runs in kernel space.  The kernel has the SPE bit off.
> The MSR state is process-specific.  If the code executes, the
> MSR bit
> is set.  Why do you want to see if the bit is set?

OK, this is a bad idea to use a driver to check the msr register.

I don't especially want to see if the bit is set, I just want
to improve the board performance for a Linux application :-).

To check the performance, I used the Dhrystone 2.1 benchmark with
the standard glibc (strcpy, strcmp, ...) on one part, and with
the freescale SPE library on the other part (vstrcpy, vstrcmp, ...).

I already verified in the binary elf file that the right functions are
called.
When I run the benchmark, I get the same MIPS with and without SPE code.

I ran the same benchmark on the same board without OS,
with a personal pseudo glibc, I have the same MIPS as under Linux,
with the freescale library, I gain 40% of perf.

That's I want to retreive with the Linux OS.

Regards
Gérard

Re: How to use SPE on MPC8541

[Andy Fleming]

On Sep 28, 2005, at 03:02, G=E9rard Gu=E9vel wrote:

>
> Andy,
>
>
>> Your driver runs in kernel space.  The kernel has the SPE bit off.
>> The MSR state is process-specific.  If the code executes, the
>> MSR bit
>> is set.  Why do you want to see if the bit is set?
>>
>
> OK, this is a bad idea to use a driver to check the msr register.
>
> I don't especially want to see if the bit is set, I just want
> to improve the board performance for a Linux application :-).
>
> To check the performance, I used the Dhrystone 2.1 benchmark with
> the standard glibc (strcpy, strcmp, ...) on one part, and with
> the freescale SPE library on the other part (vstrcpy, vstrcmp, ...).
>
> I already verified in the binary elf file that the right functions are
> called.
> When I run the benchmark, I get the same MIPS with and without SPE =20
> code.

Hmm... This is very strange, because Dhrystone is exactly the =20
benchmark this was tested on.  How did you determine that the SPE =20
functions are called?


> I ran the same benchmark on the same board without OS,
> with a personal pseudo glibc, I have the same MIPS as under Linux,
> with the freescale library, I gain 40% of perf.
>
> That's I want to retreive with the Linux OS.

I'm not sure why you aren't seeing a performance gain, but I assure =20
you that, if SPE instructions weren't working, Dhrystone would =20
crash.  The only other possibility I can think of is that the SPE =20
versions of the functions aren't being called.=

RE: How to use SPE on MPC8541

[Gérard Guével]

> Hmm... This is very strange, because Dhrystone is exactly the
> benchmark this was tested on.  How did you determine that the SPE
> functions are called?

I prefix the strcpy and strcmp functions with a "v" in dhry21a.c and
dhry21b.c. Then I statically compile the c files with the freescale
assembly source S files and not with the library libcfsl_e500.a.

If I don't add the S files the ld fails else it succeeds.
I retreive the symbols vstr... in the binary dhrystone with readelf.
So I presume that it is the right code that is called.

> I'm not sure why you aren't seeing a performance gain, but I assure
> you that, if SPE instructions weren't working, Dhrystone would
> crash.

I confirm that if I try to run this binary without SPE in Linux kernel
I get an exception.

> The only other possibility I can think of is that the SPE
> versions of the functions aren't being called.

I don't understand what you say.
Perhaps have you a pre-compiled dhrystone for Linux 2.6
I can try and compare on my board

Thanks
Gérard

RE: Linux Kernel Issue: MPC8540 Errata (CPU29)

[Chiradeep Vittal]

It turns out to be a compiler issue.
We're using gcc 3.4.3 with optimization level -Os. The following program =
will generate the illegal instruction with -Os but not with -O2
	int main (int argc, char** argv)
	{=09
	  int seq[] =3D {0, 1, 2};
	  return 0;
	}
The reason is that the compiler generates code with the stswi =
instruction which is not supported by the e500. Here's our compiler =
configuration:
Configured with: =
/home/steve/perforce/sw/opt/crosstool/build/powerpc-8540-linux-gnu/gcc-3.=
4.3-glibc-2.3.2/gcc-3.4.3/configure --target=3Dpowerpc-8540-linux-gnu =
--host=3Di686-host_pc-linux-gnu =
--prefix=3D/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-linux-g=
nu/gcc-3.4.3-glibc-2.3.2 --with-cpu=3D8540 =
--enable-cxx-flags=3D-mcpu=3D8540 =
--with-headers=3D/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-l=
inux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu/include =
--with-local-prefix=3D/home/steve/perforce/sw/opt/cross-compile/powerpc-8=
540-linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu --disable-nls =
--enable-threads=3Dposix --enable-symvers=3Dgnu --enable-__cxa_atexit =
--enable-languages=3Dc,c++ --enable-shared --enable-c99 =
--enable-long-long

Any recommendations?

Thanks
--
Chiradeep

-----Original Message-----
From: Kumar Gala [mailto:kumar.gala@freescale.com]=20
Sent: Wednesday, April 27, 2005 11:37 AM
To: Chiradeep Vittal
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux Kernel Issue: MPC8540 Errata (CPU29)

On Apr 27, 2005, at 12:46 PM, Chiradeep Vittal wrote:

> We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
>  seeing an
> "illegal instruction"=A0 (SIGILL) exception under some circumstances
> (during a pthread_create call). We were wondering if this could be a
> symptom of
> CPU29 and if there is a patch available for CPU29.
>
> "CPU29 L1 instruction cache gets multiple entries for same line after
>  change
> in MSR[IS] bit "
>
> www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf

The way the Linux kernel manages the MMU on e500 it doesn't actually=20
ever modify MSR[IS] or MSR[DS].  They are always zero so I dont believe=20
you are hitting this errata.

Are you running with math emulation turned on?  Do you know what the=20
instruction is that causes the SIGILL?

- kumar

Re: Linux Kernel Issue: MPC8540 Errata (CPU29)

[Greg Weeks]

Chiradeep Vittal wrote:

>It turns out to be a compiler issue.
>We're using gcc 3.4.3 with optimization level -Os. The following program will generate the illegal instruction with -Os but not with -O2
>	int main (int argc, char** argv)
>	{	
>	  int seq[] = {0, 1, 2};
>	  return 0;
>	}
>The reason is that the compiler generates code with the stswi instruction which is not supported by the e500. Here's our compiler configuration:
>Configured with: /home/steve/perforce/sw/opt/crosstool/build/powerpc-8540-linux-gnu/gcc-3.4.3-glibc-2.3.2/gcc-3.4.3/configure --target=powerpc-8540-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-linux-gnu/gcc-3.4.3-glibc-2.3.2 --with-cpu=8540 --enable-cxx-flags=-mcpu=8540 --with-headers=/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu/include --with-local-prefix=/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
>
>Any recommendations?
>  
>
Here's the patch we use to get GCC to stop generating the invalid 
intructions.

Greg Weeks


--- gcc-orig/gcc/config/rs6000/rs6000.h    2003-12-08 20:57:45.000000000 
-0500
+++ gcc-new/gcc/config/rs6000/rs6000.h    2004-09-15 14:23:36.680978222 
-0400
@@ -550,10 +550,10 @@
 #define TARGET_LONG_DOUBLE_128 (rs6000_long_double_type_size == 128)
 #define TARGET_ALTIVEC_ABI rs6000_altivec_abi
 #define TARGET_ALTIVEC_VRSAVE rs6000_altivec_vrsave
+#define TARGET_E500 (rs6000_cpu == PROCESSOR_PPC8540)
 
 #define TARGET_SPE_ABI 0
 #define TARGET_SPE 0
-#define TARGET_E500 0
 #define TARGET_ISEL 0
 #define TARGET_FPRS 1
 

Re: Linux Kernel Issue: MPC8540 Errata (CPU29)

[Kylo Ginsberg]

Chiradeep,

I have the same issue with gcc3.4.3 and an e500 target.  You can give
gcc the -mno-string to inhibit generation of those load/store string
instructions.  I don't know if gcc can be configured such that its
default is not to generate those instructions.

Cheers,
Kylo

On 4/28/05, Chiradeep Vittal <chiradeep@matissenetworks.com> wrote:
> It turns out to be a compiler issue.
> We're using gcc 3.4.3 with optimization level -Os. The following program =
will generate the illegal instruction with -Os but not with -O2
>         int main (int argc, char** argv)
>         {
>           int seq[] =3D {0, 1, 2};
>           return 0;
>         }
> The reason is that the compiler generates code with the stswi instruction=
 which is not supported by the e500. Here's our compiler configuration:
> Configured with: /home/steve/perforce/sw/opt/crosstool/build/powerpc-8540=
-linux-gnu/gcc-3.4.3-glibc-2.3.2/gcc-3.4.3/configure --target=3Dpowerpc-854=
0-linux-gnu --host=3Di686-host_pc-linux-gnu --prefix=3D/home/steve/perforce=
/sw/opt/cross-compile/powerpc-8540-linux-gnu/gcc-3.4.3-glibc-2.3.2 --with-c=
pu=3D8540 --enable-cxx-flags=3D-mcpu=3D8540 --with-headers=3D/home/steve/pe=
rforce/sw/opt/cross-compile/powerpc-8540-linux-gnu/gcc-3.4.3-glibc-2.3.2/po=
werpc-8540-linux-gnu/include --with-local-prefix=3D/home/steve/perforce/sw/=
opt/cross-compile/powerpc-8540-linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540=
-linux-gnu --disable-nls --enable-threads=3Dposix --enable-symvers=3Dgnu --=
enable-__cxa_atexit --enable-languages=3Dc,c++ --enable-shared --enable-c99=
 --enable-long-long
>=20
> Any recommendations?
>=20
> Thanks
> --
> Chiradeep
>=20
> -----Original Message-----
> From: Kumar Gala [mailto:kumar.gala@freescale.com]
> Sent: Wednesday, April 27, 2005 11:37 AM
> To: Chiradeep Vittal
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux Kernel Issue: MPC8540 Errata (CPU29)
>=20
> On Apr 27, 2005, at 12:46 PM, Chiradeep Vittal wrote:
>=20
> > We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
> >  seeing an
> > "illegal instruction" (SIGILL) exception under some circumstances
> > (during a pthread_create call). We were wondering if this could be a
> > symptom of
> > CPU29 and if there is a patch available for CPU29.
> >
> > "CPU29 L1 instruction cache gets multiple entries for same line after
> >  change
> > in MSR[IS] bit "
> >
> > www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf
>=20
> The way the Linux kernel manages the MMU on e500 it doesn't actually
> ever modify MSR[IS] or MSR[DS].  They are always zero so I dont believe
> you are hitting this errata.
>=20
> Are you running with math emulation turned on?  Do you know what the
> instruction is that causes the SIGILL?
>=20
> - kumar
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: Linux Kernel Issue: MPC8540 Errata (CPU29)

[Kumar Gala]

All of the suggestions are good ones.. Also, in 2.6 I've recently =20
submitted patches that add emulation of these instructions in the =20
kernel.

Its odd, but I would have expected a GCC configured for e500 not to =20
generate the ld/st string instructions by default, but the -mno-string =20=

is what we do in the kernel to ensure that.

- kumar

On Apr 28, 2005, at 5:21 PM, Kylo Ginsberg wrote:

> Chiradeep,
>
> I have the same issue with gcc3.4.3 and an e500 target.=A0 You can =
give
>  gcc the -mno-string to inhibit generation of those load/store string
>  instructions.=A0 I don't know if gcc can be configured such that its
>  default is not to generate those instructions.
>
> Cheers,
>  Kylo
>
> On 4/28/05, Chiradeep Vittal <chiradeep@matissenetworks.com> wrote:
>  > It turns out to be a compiler issue.
> > We're using gcc 3.4.3 with optimization level -Os. The following =20
> program will generate the illegal instruction with -Os but not with =20=

> -O2
>
> >=A0=A0=A0=A0=A0=A0=A0=A0 int main (int argc, char** argv)
>  >=A0=A0=A0=A0=A0=A0=A0=A0 {
>  >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int seq[] =3D {0, 1, 2};
>  >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0;
>  >=A0=A0=A0=A0=A0=A0=A0=A0 }
>  > The reason is that the compiler generates code with the stswi =20
> instruction which is not supported by the e500. Here's our compiler =20=

> configuration:
>
> > Configured with: =20
> /home/steve/perforce/sw/opt/crosstool/build/powerpc-8540-linux-gnu/=20
> gcc-3.4.3-glibc-2.3.2/gcc-3.4.3/configure =20
> --target=3Dpowerpc-8540-linux-gnu --host=3Di686-host_pc-linux-gnu =20
> --prefix=3D/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-linux-=
=20
> gnu/gcc-3.4.3-glibc-2.3.2 --with-cpu=3D8540 =20
> --enable-cxx-flags=3D-mcpu=3D8540 =20
> --with-headers=3D/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-=
=20
> linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu/include =20
> --with-local-prefix=3D/home/steve/perforce/sw/opt/cross-compile/powerpc=20=

> -8540-linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu =20
> --disable-nls --enable-threads=3Dposix --enable-symvers=3Dgnu =20
> --enable-__cxa_atexit --enable-languages=3Dc,c++ --enable-shared =20
> --enable-c99 --enable-long-long
>
> >
> > Any recommendations?
> >
> > Thanks
>  > --
>  > Chiradeep
>  >
> > -----Original Message-----
>  > From: Kumar Gala [mailto:kumar.gala@freescale.com]
>  > Sent: Wednesday, April 27, 2005 11:37 AM
>  > To: Chiradeep Vittal
>  > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Linux Kernel Issue: MPC8540 Errata (CPU29)
> >
> > On Apr 27, 2005, at 12:46 PM, Chiradeep Vittal wrote:
>  >
> > > We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
>  > >=A0 seeing an
> > > "illegal instruction" (SIGILL) exception under some circumstances
>  > > (during a pthread_create call). We were wondering if this could =20=

> be a
> > > symptom of
>  > > CPU29 and if there is a patch available for CPU29.
>  > >
>  > > "CPU29 L1 instruction cache gets multiple entries for same line =20=

> after
>  > >=A0 change
>  > > in MSR[IS] bit "
>  > >
>  > > www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf
> >
> > The way the Linux kernel manages the MMU on e500 it doesn't actually
>  > ever modify MSR[IS] or MSR[DS].=A0 They are always zero so I dont =20=

> believe
>  > you are hitting this errata.
>  >
> > Are you running with math emulation turned on?=A0 Do you know what =
the
>  > instruction is that causes the SIGILL?
>  >
> > - kumar
>  >
> > _______________________________________________
> > Linuxppc-embedded mailing list
>  > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>  >

Re: Linux Kernel Issue: MPC8540 Errata (CPU29)

[Wolfgang Denk]

In message <61cc712d05042815211d84e870@mail.gmail.com> you wrote:
> 
> I have the same issue with gcc3.4.3 and an e500 target.  You can give
> gcc the -mno-string to inhibit generation of those load/store string
> instructions.  I don't know if gcc can be configured such that its
> default is not to generate those instructions.

Yes, it can. In config/rs6000/rs6000.c replace

	if (BYTES_BIG_ENDIAN && optimize_size)
	  target_flags |= MASK_MULTIPLE | MASK_STRING;
by
	if (BYTES_BIG_ENDIAN && optimize_size)
	  target_flags |= 
	    (MASK_MULTIPLE | MASK_STRING) & ~processor_target_table[j].target_disable;

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Do you suppose the reason the ends of the `Intel Inside'  logo  don't
match up is that it was drawn on a Pentium?