Problems of using APU/FPU under linux

Problems of using APU/FPU under linux

[Shanyuan Gao]

Hi,

Recently I was trying to make APU/FPU working under Linux on Xilinx  
ML410. The standalone programs work perfectly. However under Linux,  
when I try to use a floating point operation, like *fmuls*, it will  
give me a *trap*.

By studying the user guide from Xilinx and dumping the object files,  
I know I need to change the corresponding bits (APU enable, FP  
enable, maybe APU Exception enable) in Machine State Register. I  
guess I need to enable the bits whenever before the kernel uses  
*mtmsr*. However, it doesn't work. I got the same trap with the same  
MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc  
tree, but it doesn't work either.

The questions are
1. I guess there might be some place that changed MSR after all my  
changes. But I don't know where. And can I write a kernel module to  
change the MSR after booting in Linux? (well, it's hard for me though)

2. Does it have any exception/interrupt mechanism to direct FP  
operation to APU/FPU? Or after enabling APU/FPU it will mask the  
exception/interrupt and decode FP operation by itself?


Any ideas are appreciated. Thank you very much!


Shan

RE: Problems of using APU/FPU under linux

[Stephen Neuendorffer]

I'm not sure exactly what's going on here.  Generally speaking, if you
have the FPU instantiated in the design and enable the APU in the msr,
then the processor should decode FP instructions and send them directly
to the APU with no trap.  I haven't done this myself, or I could
probably give you some better help...

One thing you should be aware of is that the there are gcc compiler
patches which are necessary to get the FPU working properly.  However, I
don't think the failure mode that these patches workaround would cause a
trap, so my guess is that there is still something else wrong.

Steve

> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
Gao
> Sent: Monday, April 14, 2008 9:18 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Problems of using APU/FPU under linux
>=20
> Hi,
>=20
> Recently I was trying to make APU/FPU working under Linux on Xilinx
> ML410. The standalone programs work perfectly. However under Linux,
> when I try to use a floating point operation, like *fmuls*, it will
> give me a *trap*.
>=20
> By studying the user guide from Xilinx and dumping the object files,
> I know I need to change the corresponding bits (APU enable, FP
> enable, maybe APU Exception enable) in Machine State Register. I
> guess I need to enable the bits whenever before the kernel uses
> *mtmsr*. However, it doesn't work. I got the same trap with the same
> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc
> tree, but it doesn't work either.
>=20
> The questions are
> 1. I guess there might be some place that changed MSR after all my
> changes. But I don't know where. And can I write a kernel module to
> change the MSR after booting in Linux? (well, it's hard for me though)
>=20
> 2. Does it have any exception/interrupt mechanism to direct FP
> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> exception/interrupt and decode FP operation by itself?
>=20
>=20
> Any ideas are appreciated. Thank you very much!
>=20
>=20
> Shan
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Problems of using APU/FPU under linux

[John Bonesio]

Hi,

The Linux kernel itself doesn't issue floating point instructions other than to save and restore the fpu state when necessary.

In Linux, the way it saves and restores the fpu state is to make use of the trap. When the trap (fpu unavailable) occurs, it loads the fpu state for the current task, sets up the MSR, and returns to re-try the instruction.

So, getting the trap is normal. If the FPU is not being set up correctly, then there may be a problem with the restoring of the state.

When you guild the Linux kernel, you need to have CONFIG_PPC_FPU enabled. Otherwise the kernel does not setup the fpu exception handling.

- John


On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
> 
> I'm not sure exactly what's going on here.  Generally speaking, if you
> have the FPU instantiated in the design and enable the APU in the msr,
> then the processor should decode FP instructions and send them directly
> to the APU with no trap.  I haven't done this myself, or I could
> probably give you some better help...
> 
> One thing you should be aware of is that the there are gcc compiler
> patches which are necessary to get the FPU working properly.  However, I
> don't think the failure mode that these patches workaround would cause a
> trap, so my guess is that there is still something else wrong.
> 
> Steve
> 
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
> > bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
> Gao
> > Sent: Monday, April 14, 2008 9:18 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: Problems of using APU/FPU under linux
> > 
> > Hi,
> > 
> > Recently I was trying to make APU/FPU working under Linux on Xilinx
> > ML410. The standalone programs work perfectly. However under Linux,
> > when I try to use a floating point operation, like *fmuls*, it will
> > give me a *trap*.
> > 
> > By studying the user guide from Xilinx and dumping the object files,
> > I know I need to change the corresponding bits (APU enable, FP
> > enable, maybe APU Exception enable) in Machine State Register. I
> > guess I need to enable the bits whenever before the kernel uses
> > *mtmsr*. However, it doesn't work. I got the same trap with the same
> > MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc
> > tree, but it doesn't work either.
> > 
> > The questions are
> > 1. I guess there might be some place that changed MSR after all my
> > changes. But I don't know where. And can I write a kernel module to
> > change the MSR after booting in Linux? (well, it's hard for me though)
> > 
> > 2. Does it have any exception/interrupt mechanism to direct FP
> > operation to APU/FPU? Or after enabling APU/FPU it will mask the
> > exception/interrupt and decode FP operation by itself?
> > 
> > 
> > Any ideas are appreciated. Thank you very much!
> > 
> > 
> > Shan
> > 
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

Re: Problems of using APU/FPU under linux

[Shanyuan Gao]

[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]

Thank you very much, Steve and John!

My advisor and I discussed how Linux works with APU/FPU a few days  
ago. And he had the same thoughts with John. My naive guess was it  
would automatically decode FP operations and mask the trap. Now it  
answers my second question. I will try it later.

But for my first question, I searched all (almost all) the files,  
such as head.S, entry.S, head_4xx.S, etc. And added following three  
lines before mtmsr or MTMSRD  are used

ori        r10, r10, 1<<13  /* enable fpu */
oris      r10, r10, 1<<9    /* enable apu */
oris      r10, r10, 1<<3    /* enable apu exception */

However the MSR in trap prompts keeps the same (2d030) before and  
after I added those lines.

[   31.819079] Bad trap at PC: 10000458, MSR: 2d030, vector=800     
Not tainted
[   31.887027]   Signal: 5
[   31.887042]   Code:   0
[   31.887058]   Addr:   0
Trace/breakpoint trap

I guess there must be some places, like some interrupts that changed  
the MSR that I didn't know.

And for FP exceptions, it has two bits (two modes) in MSR. I think  
they are for such exceptions like divided by zero. Do I need to set  
them also?

In my previous build, I also added PPC_FPU under config 40x in arch/ 
ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't  
help. I will try CONFIG_PPC_FPU later.


Shan

On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:

> Hi,
>
> The Linux kernel itself doesn't issue floating point instructions  
> other than to save and restore the fpu state when necessary.
>
> In Linux, the way it saves and restores the fpu state is to make  
> use of the trap. When the trap (fpu unavailable) occurs, it loads  
> the fpu state for the current task, sets up the MSR, and returns to  
> re-try the instruction.
>
> So, getting the trap is normal. If the FPU is not being set up  
> correctly, then there may be a problem with the restoring of the  
> state.
>
> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU  
> enabled. Otherwise the kernel does not setup the fpu exception  
> handling.
>
> - John
>
>
> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
>>
>> I'm not sure exactly what's going on here.  Generally speaking, if  
>> you
>> have the FPU instantiated in the design and enable the APU in the  
>> msr,
>> then the processor should decode FP instructions and send them  
>> directly
>> to the APU with no trap.  I haven't done this myself, or I could
>> probably give you some better help...
>>
>> One thing you should be aware of is that the there are gcc compiler
>> patches which are necessary to get the FPU working properly.   
>> However, I
>> don't think the failure mode that these patches workaround would  
>> cause a
>> trap, so my guess is that there is still something else wrong.
>>
>> Steve
>>
>>> -----Original Message-----
>>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
>> [mailto:linuxppc-embedded-
>>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
>> Gao
>>> Sent: Monday, April 14, 2008 9:18 AM
>>> To: linuxppc-embedded@ozlabs.org
>>> Subject: Problems of using APU/FPU under linux
>>>
>>> Hi,
>>>
>>> Recently I was trying to make APU/FPU working under Linux on Xilinx
>>> ML410. The standalone programs work perfectly. However under Linux,
>>> when I try to use a floating point operation, like *fmuls*, it will
>>> give me a *trap*.
>>>
>>> By studying the user guide from Xilinx and dumping the object files,
>>> I know I need to change the corresponding bits (APU enable, FP
>>> enable, maybe APU Exception enable) in Machine State Register. I
>>> guess I need to enable the bits whenever before the kernel uses
>>> *mtmsr*. However, it doesn't work. I got the same trap with the same
>>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to  
>>> ppc
>>> tree, but it doesn't work either.
>>>
>>> The questions are
>>> 1. I guess there might be some place that changed MSR after all my
>>> changes. But I don't know where. And can I write a kernel module to
>>> change the MSR after booting in Linux? (well, it's hard for me  
>>> though)
>>>
>>> 2. Does it have any exception/interrupt mechanism to direct FP
>>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
>>> exception/interrupt and decode FP operation by itself?
>>>
>>>
>>> Any ideas are appreciated. Thank you very much!
>>>
>>>
>>> Shan
>>>
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>


[-- Attachment #2: Type: text/html, Size: 13603 bytes --]

Re: Problems of using APU/FPU under linux

[John Bonesio]

Hi Shan,

It's not clear exactly what you are experiencing. What do you see in your user application, "Illegal instruction" ?

In arch/powerpc/kernel/head_booke.h, there's #define FP_UNAVAILABLE_EXCEPTION. This defines the FPU unavailable exception. Is the code getting there? You should see the call to load_up_fpu in there, which is defined in arch/powerpc/kernel/fpu.S

What exception is being generated? It looks like you're getting SIGTRAP in your application which is the debug exception, which doesn't seem related to how the kernel sets up the fpu.

I believe the 2 bits you mentioned just have to do with with how the fpu behaves. The kernel code doesn't use those for the fpu context switching. It uses the Floating-Point Available bit in the MSR.

Definitely check the errata and other information about the FPU you are using. As Steve mentioned, you should use the Xilinx gcc tools with the Xilinx FPU.

- John

On Monday 14 April 2008 13:46, Shanyuan Gao wrote:
> Thank you very much, Steve and John!
> 
> My advisor and I discussed how Linux works with APU/FPU a few days  
> ago. And he had the same thoughts with John. My naive guess was it  
> would automatically decode FP operations and mask the trap. Now it  
> answers my second question. I will try it later.
> 
> But for my first question, I searched all (almost all) the files,  
> such as head.S, entry.S, head_4xx.S, etc. And added following three  
> lines before mtmsr or MTMSRD  are used
> 
> ori        r10, r10, 1<<13  /* enable fpu */
> oris      r10, r10, 1<<9    /* enable apu */
> oris      r10, r10, 1<<3    /* enable apu exception */
> 
> However the MSR in trap prompts keeps the same (2d030) before and  
> after I added those lines.
> 
> [   31.819079] Bad trap at PC: 10000458, MSR: 2d030, vector=800     
> Not tainted
> [   31.887027]   Signal: 5
> [   31.887042]   Code:   0
> [   31.887058]   Addr:   0
> Trace/breakpoint trap
> 
> I guess there must be some places, like some interrupts that changed  
> the MSR that I didn't know.
> 
> And for FP exceptions, it has two bits (two modes) in MSR. I think  
> they are for such exceptions like divided by zero. Do I need to set  
> them also?
> 
> In my previous build, I also added PPC_FPU under config 40x in arch/ 
> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't  
> help. I will try CONFIG_PPC_FPU later.
> 
> 
> Shan
> 
> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
> 
> > Hi,
> >
> > The Linux kernel itself doesn't issue floating point instructions  
> > other than to save and restore the fpu state when necessary.
> >
> > In Linux, the way it saves and restores the fpu state is to make  
> > use of the trap. When the trap (fpu unavailable) occurs, it loads  
> > the fpu state for the current task, sets up the MSR, and returns to  
> > re-try the instruction.
> >
> > So, getting the trap is normal. If the FPU is not being set up  
> > correctly, then there may be a problem with the restoring of the  
> > state.
> >
> > When you guild the Linux kernel, you need to have CONFIG_PPC_FPU  
> > enabled. Otherwise the kernel does not setup the fpu exception  
> > handling.
> >
> > - John
> >
> >
> > On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
> >>
> >> I'm not sure exactly what's going on here.  Generally speaking, if  
> >> you
> >> have the FPU instantiated in the design and enable the APU in the  
> >> msr,
> >> then the processor should decode FP instructions and send them  
> >> directly
> >> to the APU with no trap.  I haven't done this myself, or I could
> >> probably give you some better help...
> >>
> >> One thing you should be aware of is that the there are gcc compiler
> >> patches which are necessary to get the FPU working properly.   
> >> However, I
> >> don't think the failure mode that these patches workaround would  
> >> cause a
> >> trap, so my guess is that there is still something else wrong.
> >>
> >> Steve
> >>
> >>> -----Original Message-----
> >>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> >> [mailto:linuxppc-embedded-
> >>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
> >> Gao
> >>> Sent: Monday, April 14, 2008 9:18 AM
> >>> To: linuxppc-embedded@ozlabs.org
> >>> Subject: Problems of using APU/FPU under linux
> >>>
> >>> Hi,
> >>>
> >>> Recently I was trying to make APU/FPU working under Linux on Xilinx
> >>> ML410. The standalone programs work perfectly. However under Linux,
> >>> when I try to use a floating point operation, like *fmuls*, it will
> >>> give me a *trap*.
> >>>
> >>> By studying the user guide from Xilinx and dumping the object files,
> >>> I know I need to change the corresponding bits (APU enable, FP
> >>> enable, maybe APU Exception enable) in Machine State Register. I
> >>> guess I need to enable the bits whenever before the kernel uses
> >>> *mtmsr*. However, it doesn't work. I got the same trap with the same
> >>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to  
> >>> ppc
> >>> tree, but it doesn't work either.
> >>>
> >>> The questions are
> >>> 1. I guess there might be some place that changed MSR after all my
> >>> changes. But I don't know where. And can I write a kernel module to
> >>> change the MSR after booting in Linux? (well, it's hard for me  
> >>> though)
> >>>
> >>> 2. Does it have any exception/interrupt mechanism to direct FP
> >>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> >>> exception/interrupt and decode FP operation by itself?
> >>>
> >>>
> >>> Any ideas are appreciated. Thank you very much!
> >>>
> >>>
> >>> Shan
> >>>
> >>> _______________________________________________
> >>> Linuxppc-embedded mailing list
> >>> Linuxppc-embedded@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >
> 
> 

Re: Problems of using APU/FPU under linux

[John Bonesio]

Hi Shan,

Someone here reminded me that the ppc405 is not BookE. One of your problems maybe in getting the kernel to set up an FPU unavilable handler.

- John


On Monday 14 April 2008 13:46, Shanyuan Gao wrote:
> Thank you very much, Steve and John!
> 
> My advisor and I discussed how Linux works with APU/FPU a few days  
> ago. And he had the same thoughts with John. My naive guess was it  
> would automatically decode FP operations and mask the trap. Now it  
> answers my second question. I will try it later.
> 
> But for my first question, I searched all (almost all) the files,  
> such as head.S, entry.S, head_4xx.S, etc. And added following three  
> lines before mtmsr or MTMSRD  are used
> 
> ori        r10, r10, 1<<13  /* enable fpu */
> oris      r10, r10, 1<<9    /* enable apu */
> oris      r10, r10, 1<<3    /* enable apu exception */
> 
> However the MSR in trap prompts keeps the same (2d030) before and  
> after I added those lines.
> 
> [   31.819079] Bad trap at PC: 10000458, MSR: 2d030, vector=800     
> Not tainted
> [   31.887027]   Signal: 5
> [   31.887042]   Code:   0
> [   31.887058]   Addr:   0
> Trace/breakpoint trap
> 
> I guess there must be some places, like some interrupts that changed  
> the MSR that I didn't know.
> 
> And for FP exceptions, it has two bits (two modes) in MSR. I think  
> they are for such exceptions like divided by zero. Do I need to set  
> them also?
> 
> In my previous build, I also added PPC_FPU under config 40x in arch/ 
> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't  
> help. I will try CONFIG_PPC_FPU later.
> 
> 
> Shan
> 
> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
> 
> > Hi,
> >
> > The Linux kernel itself doesn't issue floating point instructions  
> > other than to save and restore the fpu state when necessary.
> >
> > In Linux, the way it saves and restores the fpu state is to make  
> > use of the trap. When the trap (fpu unavailable) occurs, it loads  
> > the fpu state for the current task, sets up the MSR, and returns to  
> > re-try the instruction.
> >
> > So, getting the trap is normal. If the FPU is not being set up  
> > correctly, then there may be a problem with the restoring of the  
> > state.
> >
> > When you guild the Linux kernel, you need to have CONFIG_PPC_FPU  
> > enabled. Otherwise the kernel does not setup the fpu exception  
> > handling.
> >
> > - John
> >
> >
> > On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
> >>
> >> I'm not sure exactly what's going on here.  Generally speaking, if  
> >> you
> >> have the FPU instantiated in the design and enable the APU in the  
> >> msr,
> >> then the processor should decode FP instructions and send them  
> >> directly
> >> to the APU with no trap.  I haven't done this myself, or I could
> >> probably give you some better help...
> >>
> >> One thing you should be aware of is that the there are gcc compiler
> >> patches which are necessary to get the FPU working properly.   
> >> However, I
> >> don't think the failure mode that these patches workaround would  
> >> cause a
> >> trap, so my guess is that there is still something else wrong.
> >>
> >> Steve
> >>
> >>> -----Original Message-----
> >>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> >> [mailto:linuxppc-embedded-
> >>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
> >> Gao
> >>> Sent: Monday, April 14, 2008 9:18 AM
> >>> To: linuxppc-embedded@ozlabs.org
> >>> Subject: Problems of using APU/FPU under linux
> >>>
> >>> Hi,
> >>>
> >>> Recently I was trying to make APU/FPU working under Linux on Xilinx
> >>> ML410. The standalone programs work perfectly. However under Linux,
> >>> when I try to use a floating point operation, like *fmuls*, it will
> >>> give me a *trap*.
> >>>
> >>> By studying the user guide from Xilinx and dumping the object files,
> >>> I know I need to change the corresponding bits (APU enable, FP
> >>> enable, maybe APU Exception enable) in Machine State Register. I
> >>> guess I need to enable the bits whenever before the kernel uses
> >>> *mtmsr*. However, it doesn't work. I got the same trap with the same
> >>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to  
> >>> ppc
> >>> tree, but it doesn't work either.
> >>>
> >>> The questions are
> >>> 1. I guess there might be some place that changed MSR after all my
> >>> changes. But I don't know where. And can I write a kernel module to
> >>> change the MSR after booting in Linux? (well, it's hard for me  
> >>> though)
> >>>
> >>> 2. Does it have any exception/interrupt mechanism to direct FP
> >>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> >>> exception/interrupt and decode FP operation by itself?
> >>>
> >>>
> >>> Any ideas are appreciated. Thank you very much!
> >>>
> >>>
> >>> Shan
> >>>
> >>> _______________________________________________
> >>> Linuxppc-embedded mailing list
> >>> Linuxppc-embedded@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >
> 
> 

Re: Problems of using APU/FPU under linux

[Yoshio Kashiwagi]

Hi,

The following modification is required if you use APU in user space.

in include/asm-powerpc/reg.h

-#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
+#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)

Yoshio Kashiwagi - Nissin Systems

> Thank you very much, Steve and John!
> 
> My advisor and I discussed how Linux works with APU/FPU a few days ago.
 And he had the same thoughts with John. My naive guess was it would 
automatically decode FP operations and mask the trap. Now it answers my 
second question. I will try it later.
> 
> But for my first question, I searched all (almost all) the files, such 
as head.S, entry.S, head_4xx.S, etc. And added following three lines 
before mtmsr or MTMSRD 

Re: Problems of using APU/FPU under linux

[Shanyuan Gao]

Thank you, Yoshio!!

I just applied the change, seems it works! But it doesn't work =20
correctly. I mean it won't give me traps any more, but the answer is =20
not correctly. I just tried to multiply two float numbers. But it =20
gives me 0.

The first time I change the reg.h was to enable apu enable, apu =20
exception enable and fpu enable. It gives me answer 0.
The second try I did was enabling apu enable and apu exception, =20
because I notice that inside /arch/powerpc/kernel/fpu.S, it will =20
enable FPU in load_up_fpu. So I guess I cannot enable FPU all the =20
time. However, this time it gave me trap again, well, with a =20
different MSR.

Now my guess is load_up_fpu is not working correctly. I am working on =20=

that.


Shan



On Apr 15, 2008, at 2:20 PM, Yoshio Kashiwagi wrote:

> Hi,
>
> The following modification is required if you use APU in user space.
>
> in include/asm-powerpc/reg.h
>
> -#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
> +#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)
>
> Yoshio Kashiwagi - Nissin Systems
>
>> Thank you very much, Steve and John!
>>
>> My advisor and I discussed how Linux works with APU/FPU a few days =20=

>> ago.
>  And he had the same thoughts with John. My naive guess was it would
> automatically decode FP operations and mask the trap. Now it =20
> answers my
> second question. I will try it later.
>>
>> But for my first question, I searched all (almost all) the files, =20
>> such
> as head.S, entry.S, head_4xx.S, etc. And added following three lines
> before mtmsr or MTMSRD =EF=BF=BDare used
>>
>> ori =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<13 =EF=BF=BD/* =
enable fpu */
>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<9 =EF=BF=BD =EF=BF=BD/* =
enable apu */
>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<3 =EF=BF=BD =EF=BF=BD/* =
enable apu exception */
>>
>> However the MSR in trap prompts keeps the same (2d030) before and
> after I added those lines.=EF=BF=BD
>>
>> [=EF=BF=BD=EF=BF=BD 31.819079] Bad trap at PC: 10000458, MSR: 2d030, =20=

>> vector=3D800=EF=BF=BD=EF=BF=BD=EF=BF=BD Not
> tainted
>> [=EF=BF=BD=EF=BF=BD 31.887027]=EF=BF=BD=EF=BF=BD Signal: 5
>> [=EF=BF=BD=EF=BF=BD 31.887042]=EF=BF=BD=EF=BF=BD Code:=EF=BF=BD=EF=BF=BD=
 0
>> [=EF=BF=BD=EF=BF=BD 31.887058]=EF=BF=BD=EF=BF=BD Addr:=EF=BF=BD=EF=BF=BD=
 0
>> Trace/breakpoint trap
>>
>> I guess there must be some places, like some interrupts that changed
> the MSR that I didn't know. =EF=BF=BD
>>
>> And for FP exceptions, it has two bits (two modes) in MSR. I think
> they are for such exceptions like divided by zero. Do I need to set =20=

> them
> also?
>>
>> In my previous build, I also added PPC_FPU under config 40x in arch/
> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't =20
> help.
> I will try CONFIG_PPC_FPU later.
>>
>>
>> Shan
>>
>> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
>>
>> Hi,
>>
>> The Linux kernel itself doesn't issue floating point instructions
> other than to save and restore the fpu state when necessary.
>>
>> In Linux, the way it saves and restores the fpu state is to make use
> of the trap. When the trap (fpu unavailable) occurs, it loads the fpu
> state for the current task, sets up the MSR, and returns to re-try the
> instruction.
>>
>> So, getting the trap is normal. If the FPU is not being set up
> correctly, then there may be a problem with the restoring of the =20
> state.
>>
>> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
> enabled. Otherwise the kernel does not setup the fpu exception =20
> handling.
>>
>> - John
>>
>>
>> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
>>
>> I'm not sure exactly what's going on here.=EF=BF=BD Generally =
speaking, =20
>> if you
>> have the FPU instantiated in the design and enable the APU in the =20
>> msr,
>> then the processor should decode FP instructions and send them
> directly
>> to the APU with no trap.=EF=BF=BD I haven't done this myself, or I =
could
>> probably give you some better help...
>>
>> One thing you should be aware of is that the there are gcc compiler
>> patches which are necessary to get the FPU working properly.=EF=BF=BD =
=20
>> However,
> I
>> don't think the failure mode that these patches workaround would =20
>> cause
> a
>> trap, so my guess is that there is still something else wrong.
>>
>> Steve
>>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
>> [mailto:linuxppc-embedded-
>> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
>> Gao
>> Sent: Monday, April 14, 2008 9:18 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: Problems of using APU/FPU under linux
>>
>> Hi,
>>
>> Recently I was trying to make APU/FPU working under Linux on Xilinx
>> ML410. The standalone programs work perfectly. However under Linux,
>> when I try to use a floating point operation, like *fmuls*, it will
>> give me a *trap*.
>>
>> By studying the user guide from Xilinx and dumping the object files,
>> I know I need to change the corresponding bits (APU enable, FP
>> enable, maybe APU Exception enable) in Machine State Register. I
>> guess I need to enable the bits whenever before the kernel uses
>> *mtmsr*. However, it doesn't work. I got the same trap with the same
>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S to ppc
>> tree, but it doesn't work either.
>>
>> The questions are
>> 1. I guess there might be some place that changed MSR after all my
>> changes. But I don't know where. And can I write a kernel module to
>> change the MSR after booting in Linux? (well, it's hard for me =20
>> though)
>>
>> 2. Does it have any exception/interrupt mechanism to direct FP
>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
>> exception/interrupt and decode FP operation by itself?
>>
>>
>> Any ideas are appreciated. Thank you very much!
>>
>>
>> Shan
>

RE: Problems of using APU/FPU under linux

[Stephen Neuendorffer]

U2hhbnl1YW4sDQoNCkRpZCB5b3UgaW5zdGFsbCB0aGUgRlBVX1VOQVZBSUxBQkxFIHRyYXAgaW4g
aGVhZF80MHguUz8NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNo
YW55dWFuIEdhbyBbbWFpbHRvOnN5Z2FvLnJlc2VhcmNoQGdtYWlsLmNvbV0NCj4gU2VudDogVHVl
c2RheSwgQXByaWwgMTUsIDIwMDggMTE6MzQgQU0NCj4gVG86IFlvc2hpbyBLYXNoaXdhZ2k7IGxp
bnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcNCj4gQ2M6IFN0ZXBoZW4gTmV1ZW5kb3JmZmVyOyBK
b2huIEJvbmVzaW8NCj4gU3ViamVjdDogUmU6IFByb2JsZW1zIG9mIHVzaW5nIEFQVS9GUFUgdW5k
ZXIgbGludXgNCj4gDQo+IFRoYW5rIHlvdSwgWW9zaGlvISENCj4gDQo+IEkganVzdCBhcHBsaWVk
IHRoZSBjaGFuZ2UsIHNlZW1zIGl0IHdvcmtzISBCdXQgaXQgZG9lc24ndCB3b3JrDQo+IGNvcnJl
Y3RseS4gSSBtZWFuIGl0IHdvbid0IGdpdmUgbWUgdHJhcHMgYW55IG1vcmUsIGJ1dCB0aGUgYW5z
d2VyIGlzDQo+IG5vdCBjb3JyZWN0bHkuIEkganVzdCB0cmllZCB0byBtdWx0aXBseSB0d28gZmxv
YXQgbnVtYmVycy4gQnV0IGl0DQo+IGdpdmVzIG1lIDAuDQo+IA0KPiBUaGUgZmlyc3QgdGltZSBJ
IGNoYW5nZSB0aGUgcmVnLmggd2FzIHRvIGVuYWJsZSBhcHUgZW5hYmxlLCBhcHUNCj4gZXhjZXB0
aW9uIGVuYWJsZSBhbmQgZnB1IGVuYWJsZS4gSXQgZ2l2ZXMgbWUgYW5zd2VyIDAuDQo+IFRoZSBz
ZWNvbmQgdHJ5IEkgZGlkIHdhcyBlbmFibGluZyBhcHUgZW5hYmxlIGFuZCBhcHUgZXhjZXB0aW9u
LA0KPiBiZWNhdXNlIEkgbm90aWNlIHRoYXQgaW5zaWRlIC9hcmNoL3Bvd2VycGMva2VybmVsL2Zw
dS5TLCBpdCB3aWxsDQo+IGVuYWJsZSBGUFUgaW4gbG9hZF91cF9mcHUuIFNvIEkgZ3Vlc3MgSSBj
YW5ub3QgZW5hYmxlIEZQVSBhbGwgdGhlDQo+IHRpbWUuIEhvd2V2ZXIsIHRoaXMgdGltZSBpdCBn
YXZlIG1lIHRyYXAgYWdhaW4sIHdlbGwsIHdpdGggYQ0KPiBkaWZmZXJlbnQgTVNSLg0KPiANCj4g
Tm93IG15IGd1ZXNzIGlzIGxvYWRfdXBfZnB1IGlzIG5vdCB3b3JraW5nIGNvcnJlY3RseS4gSSBh
bSB3b3JraW5nIG9uDQo+IHRoYXQuDQo+IA0KPiANCj4gU2hhbg0KPiANCj4gDQo+IA0KPiBPbiBB
cHIgMTUsIDIwMDgsIGF0IDI6MjAgUE0sIFlvc2hpbyBLYXNoaXdhZ2kgd3JvdGU6DQo+IA0KPiA+
IEhpLA0KPiA+DQo+ID4gVGhlIGZvbGxvd2luZyBtb2RpZmljYXRpb24gaXMgcmVxdWlyZWQgaWYg
eW91IHVzZSBBUFUgaW4gdXNlciBzcGFjZS4NCj4gPg0KPiA+IGluIGluY2x1ZGUvYXNtLXBvd2Vy
cGMvcmVnLmgNCj4gPg0KPiA+IC0jZGVmaW5lIE1TUl9VU0VSICAgKE1TUl9LRVJORUx8TVNSX1BS
fE1TUl9FRSkNCj4gPiArI2RlZmluZSBNU1JfVVNFUiAgIChNU1JfS0VSTkVMfE1TUl9QUnxNU1Jf
RUV8TVNSX1ZFQykNCj4gPg0KPiA+IFlvc2hpbyBLYXNoaXdhZ2kgLSBOaXNzaW4gU3lzdGVtcw0K
PiA+DQo+ID4+IFRoYW5rIHlvdSB2ZXJ5IG11Y2gsIFN0ZXZlIGFuZCBKb2huIQ0KPiA+Pg0KPiA+
PiBNeSBhZHZpc29yIGFuZCBJIGRpc2N1c3NlZCBob3cgTGludXggd29ya3Mgd2l0aCBBUFUvRlBV
IGEgZmV3IGRheXMNCj4gPj4gYWdvLg0KPiA+ICBBbmQgaGUgaGFkIHRoZSBzYW1lIHRob3VnaHRz
IHdpdGggSm9obi4gTXkgbmFpdmUgZ3Vlc3Mgd2FzIGl0IHdvdWxkDQo+ID4gYXV0b21hdGljYWxs
eSBkZWNvZGUgRlAgb3BlcmF0aW9ucyBhbmQgbWFzayB0aGUgdHJhcC4gTm93IGl0DQo+ID4gYW5z
d2VycyBteQ0KPiA+IHNlY29uZCBxdWVzdGlvbi4gSSB3aWxsIHRyeSBpdCBsYXRlci4NCj4gPj4N
Cj4gPj4gQnV0IGZvciBteSBmaXJzdCBxdWVzdGlvbiwgSSBzZWFyY2hlZCBhbGwgKGFsbW9zdCBh
bGwpIHRoZSBmaWxlcywNCj4gPj4gc3VjaA0KPiA+IGFzIGhlYWQuUywgZW50cnkuUywgaGVhZF80
eHguUywgZXRjLiBBbmQgYWRkZWQgZm9sbG93aW5nIHRocmVlIGxpbmVzDQo+ID4gYmVmb3JlIG10
bXNyIG9yIE1UTVNSRCDvv71hcmUgdXNlZA0KPiA+Pg0KPiA+PiBvcmkg77+9IO+/vSDvv70g77+9
cjEwLCByMTAsIDE8PDEzIO+/vS8qIGVuYWJsZSBmcHUgKi8NCj4gPj4gb3JpcyDvv70g77+9IO+/
vXIxMCwgcjEwLCAxPDw5IO+/vSDvv70vKiBlbmFibGUgYXB1ICovDQo+ID4+IG9yaXMg77+9IO+/
vSDvv71yMTAsIHIxMCwgMTw8MyDvv70g77+9LyogZW5hYmxlIGFwdSBleGNlcHRpb24gKi8NCj4g
Pj4NCj4gPj4gSG93ZXZlciB0aGUgTVNSIGluIHRyYXAgcHJvbXB0cyBrZWVwcyB0aGUgc2FtZSAo
MmQwMzApIGJlZm9yZSBhbmQNCj4gPiBhZnRlciBJIGFkZGVkIHRob3NlIGxpbmVzLu+/vQ0KPiA+
Pg0KPiA+PiBb77+977+9IDMxLjgxOTA3OV0gQmFkIHRyYXAgYXQgUEM6IDEwMDAwNDU4LCBNU1I6
IDJkMDMwLA0KPiA+PiB2ZWN0b3I9ODAw77+977+977+9IE5vdA0KPiA+IHRhaW50ZWQNCj4gPj4g
W++/ve+/vSAzMS44ODcwMjdd77+977+9IFNpZ25hbDogNQ0KPiA+PiBb77+977+9IDMxLjg4NzA0
Ml3vv73vv70gQ29kZTrvv73vv70gMA0KPiA+PiBb77+977+9IDMxLjg4NzA1OF3vv73vv70gQWRk
cjrvv73vv70gMA0KPiA+PiBUcmFjZS9icmVha3BvaW50IHRyYXANCj4gPj4NCj4gPj4gSSBndWVz
cyB0aGVyZSBtdXN0IGJlIHNvbWUgcGxhY2VzLCBsaWtlIHNvbWUgaW50ZXJydXB0cyB0aGF0IGNo
YW5nZWQNCj4gPiB0aGUgTVNSIHRoYXQgSSBkaWRuJ3Qga25vdy4g77+9DQo+ID4+DQo+ID4+IEFu
ZCBmb3IgRlAgZXhjZXB0aW9ucywgaXQgaGFzIHR3byBiaXRzICh0d28gbW9kZXMpIGluIE1TUi4g
SSB0aGluaw0KPiA+IHRoZXkgYXJlIGZvciBzdWNoIGV4Y2VwdGlvbnMgbGlrZSBkaXZpZGVkIGJ5
IHplcm8uIERvIEkgbmVlZCB0byBzZXQNCj4gPiB0aGVtDQo+ID4gYWxzbz8NCj4gPj4NCj4gPj4g
SW4gbXkgcHJldmlvdXMgYnVpbGQsIEkgYWxzbyBhZGRlZCBQUENfRlBVIHVuZGVyIGNvbmZpZyA0
MHggaW4gYXJjaC8NCj4gPiBwcGMvS2NvbmZpZy4gSXQgY29tcGlsZWQgYXJjaC9wb3dlcnBjL2tl
cm5lbC9mcHUuUyBpbiwgYnV0IGRpZG4ndA0KPiA+IGhlbHAuDQo+ID4gSSB3aWxsIHRyeSBDT05G
SUdfUFBDX0ZQVSBsYXRlci4NCj4gPj4NCj4gPj4NCj4gPj4gU2hhbg0KPiA+Pg0KPiA+PiBPbiBB
cHIgMTQsIDIwMDgsIGF0IDI6MzIgUE0sIEpvaG4gQm9uZXNpbyB3cm90ZToNCj4gPj4NCj4gPj4g
SGksDQo+ID4+DQo+ID4+IFRoZSBMaW51eCBrZXJuZWwgaXRzZWxmIGRvZXNuJ3QgaXNzdWUgZmxv
YXRpbmcgcG9pbnQgaW5zdHJ1Y3Rpb25zDQo+ID4gb3RoZXIgdGhhbiB0byBzYXZlIGFuZCByZXN0
b3JlIHRoZSBmcHUgc3RhdGUgd2hlbiBuZWNlc3NhcnkuDQo+ID4+DQo+ID4+IEluIExpbnV4LCB0
aGUgd2F5IGl0IHNhdmVzIGFuZCByZXN0b3JlcyB0aGUgZnB1IHN0YXRlIGlzIHRvIG1ha2UgdXNl
DQo+ID4gb2YgdGhlIHRyYXAuIFdoZW4gdGhlIHRyYXAgKGZwdSB1bmF2YWlsYWJsZSkgb2NjdXJz
LCBpdCBsb2FkcyB0aGUgZnB1DQo+ID4gc3RhdGUgZm9yIHRoZSBjdXJyZW50IHRhc2ssIHNldHMg
dXAgdGhlIE1TUiwgYW5kIHJldHVybnMgdG8gcmUtdHJ5IHRoZQ0KPiA+IGluc3RydWN0aW9uLg0K
PiA+Pg0KPiA+PiBTbywgZ2V0dGluZyB0aGUgdHJhcCBpcyBub3JtYWwuIElmIHRoZSBGUFUgaXMg
bm90IGJlaW5nIHNldCB1cA0KPiA+IGNvcnJlY3RseSwgdGhlbiB0aGVyZSBtYXkgYmUgYSBwcm9i
bGVtIHdpdGggdGhlIHJlc3RvcmluZyBvZiB0aGUNCj4gPiBzdGF0ZS4NCj4gPj4NCj4gPj4gV2hl
biB5b3UgZ3VpbGQgdGhlIExpbnV4IGtlcm5lbCwgeW91IG5lZWQgdG8gaGF2ZSBDT05GSUdfUFBD
X0ZQVQ0KPiA+IGVuYWJsZWQuIE90aGVyd2lzZSB0aGUga2VybmVsIGRvZXMgbm90IHNldHVwIHRo
ZSBmcHUgZXhjZXB0aW9uDQo+ID4gaGFuZGxpbmcuDQo+ID4+DQo+ID4+IC0gSm9obg0KPiA+Pg0K
PiA+Pg0KPiA+PiBPbiBNb25kYXkgMTQgQXByaWwgMjAwOCAxMDozNSwgU3RlcGhlbiBOZXVlbmRv
cmZmZXIgd3JvdGU6DQo+ID4+DQo+ID4+IEknbSBub3Qgc3VyZSBleGFjdGx5IHdoYXQncyBnb2lu
ZyBvbiBoZXJlLu+/vSBHZW5lcmFsbHkgc3BlYWtpbmcsDQo+ID4+IGlmIHlvdQ0KPiA+PiBoYXZl
IHRoZSBGUFUgaW5zdGFudGlhdGVkIGluIHRoZSBkZXNpZ24gYW5kIGVuYWJsZSB0aGUgQVBVIGlu
IHRoZQ0KPiA+PiBtc3IsDQo+ID4+IHRoZW4gdGhlIHByb2Nlc3NvciBzaG91bGQgZGVjb2RlIEZQ
IGluc3RydWN0aW9ucyBhbmQgc2VuZCB0aGVtDQo+ID4gZGlyZWN0bHkNCj4gPj4gdG8gdGhlIEFQ
VSB3aXRoIG5vIHRyYXAu77+9IEkgaGF2ZW4ndCBkb25lIHRoaXMgbXlzZWxmLCBvciBJIGNvdWxk
DQo+ID4+IHByb2JhYmx5IGdpdmUgeW91IHNvbWUgYmV0dGVyIGhlbHAuLi4NCj4gPj4NCj4gPj4g
T25lIHRoaW5nIHlvdSBzaG91bGQgYmUgYXdhcmUgb2YgaXMgdGhhdCB0aGUgdGhlcmUgYXJlIGdj
YyBjb21waWxlcg0KPiA+PiBwYXRjaGVzIHdoaWNoIGFyZSBuZWNlc3NhcnkgdG8gZ2V0IHRoZSBG
UFUgd29ya2luZyBwcm9wZXJseS7vv70NCj4gPj4gSG93ZXZlciwNCj4gPiBJDQo+ID4+IGRvbid0
IHRoaW5rIHRoZSBmYWlsdXJlIG1vZGUgdGhhdCB0aGVzZSBwYXRjaGVzIHdvcmthcm91bmQgd291
bGQNCj4gPj4gY2F1c2UNCj4gPiBhDQo+ID4+IHRyYXAsIHNvIG15IGd1ZXNzIGlzIHRoYXQgdGhl
cmUgaXMgc3RpbGwgc29tZXRoaW5nIGVsc2Ugd3JvbmcuDQo+ID4+DQo+ID4+IFN0ZXZlDQo+ID4+
DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGxpbnV4cHBjLWVt
YmVkZGVkLWJvdW5jZXMrc3RlcGhlbj1uZXVlbmRvcmZmZXIubmFtZUBvemxhYnMub3JnDQo+ID4+
IFttYWlsdG86bGludXhwcGMtZW1iZWRkZWQtDQo+ID4+IGJvdW5jZXMrc3RlcGhlbj1uZXVlbmRv
cmZmZXIubmFtZUBvemxhYnMub3JnXSBPbiBCZWhhbGYgT2YgU2hhbnl1YW4NCj4gPj4gR2FvDQo+
ID4+IFNlbnQ6IE1vbmRheSwgQXByaWwgMTQsIDIwMDggOToxOCBBTQ0KPiA+PiBUbzogbGludXhw
cGMtZW1iZWRkZWRAb3psYWJzLm9yZw0KPiA+PiBTdWJqZWN0OiBQcm9ibGVtcyBvZiB1c2luZyBB
UFUvRlBVIHVuZGVyIGxpbnV4DQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBSZWNlbnRseSBJ
IHdhcyB0cnlpbmcgdG8gbWFrZSBBUFUvRlBVIHdvcmtpbmcgdW5kZXIgTGludXggb24gWGlsaW54
DQo+ID4+IE1MNDEwLiBUaGUgc3RhbmRhbG9uZSBwcm9ncmFtcyB3b3JrIHBlcmZlY3RseS4gSG93
ZXZlciB1bmRlciBMaW51eCwNCj4gPj4gd2hlbiBJIHRyeSB0byB1c2UgYSBmbG9hdGluZyBwb2lu
dCBvcGVyYXRpb24sIGxpa2UgKmZtdWxzKiwgaXQgd2lsbA0KPiA+PiBnaXZlIG1lIGEgKnRyYXAq
Lg0KPiA+Pg0KPiA+PiBCeSBzdHVkeWluZyB0aGUgdXNlciBndWlkZSBmcm9tIFhpbGlueCBhbmQg
ZHVtcGluZyB0aGUgb2JqZWN0IGZpbGVzLA0KPiA+PiBJIGtub3cgSSBuZWVkIHRvIGNoYW5nZSB0
aGUgY29ycmVzcG9uZGluZyBiaXRzIChBUFUgZW5hYmxlLCBGUA0KPiA+PiBlbmFibGUsIG1heWJl
IEFQVSBFeGNlcHRpb24gZW5hYmxlKSBpbiBNYWNoaW5lIFN0YXRlIFJlZ2lzdGVyLiBJDQo+ID4+
IGd1ZXNzIEkgbmVlZCB0byBlbmFibGUgdGhlIGJpdHMgd2hlbmV2ZXIgYmVmb3JlIHRoZSBrZXJu
ZWwgdXNlcw0KPiA+PiAqbXRtc3IqLiBIb3dldmVyLCBpdCBkb2Vzbid0IHdvcmsuIEkgZ290IHRo
ZSBzYW1lIHRyYXAgd2l0aCB0aGUgc2FtZQ0KPiA+PiBNU1IsIGFzIEkgaGFkIG5vIEFQVS9GUFUg
YmVmb3JlLiBJIGFsc28gdHJpZWQgdG8gYWRkIHRoZSBGUFUuUyB0byBwcGMNCj4gPj4gdHJlZSwg
YnV0IGl0IGRvZXNuJ3Qgd29yayBlaXRoZXIuDQo+ID4+DQo+ID4+IFRoZSBxdWVzdGlvbnMgYXJl
DQo+ID4+IDEuIEkgZ3Vlc3MgdGhlcmUgbWlnaHQgYmUgc29tZSBwbGFjZSB0aGF0IGNoYW5nZWQg
TVNSIGFmdGVyIGFsbCBteQ0KPiA+PiBjaGFuZ2VzLiBCdXQgSSBkb24ndCBrbm93IHdoZXJlLiBB
bmQgY2FuIEkgd3JpdGUgYSBrZXJuZWwgbW9kdWxlIHRvDQo+ID4+IGNoYW5nZSB0aGUgTVNSIGFm
dGVyIGJvb3RpbmcgaW4gTGludXg/ICh3ZWxsLCBpdCdzIGhhcmQgZm9yIG1lDQo+ID4+IHRob3Vn
aCkNCj4gPj4NCj4gPj4gMi4gRG9lcyBpdCBoYXZlIGFueSBleGNlcHRpb24vaW50ZXJydXB0IG1l
Y2hhbmlzbSB0byBkaXJlY3QgRlANCj4gPj4gb3BlcmF0aW9uIHRvIEFQVS9GUFU/IE9yIGFmdGVy
IGVuYWJsaW5nIEFQVS9GUFUgaXQgd2lsbCBtYXNrIHRoZQ0KPiA+PiBleGNlcHRpb24vaW50ZXJy
dXB0IGFuZCBkZWNvZGUgRlAgb3BlcmF0aW9uIGJ5IGl0c2VsZj8NCj4gPj4NCj4gPj4NCj4gPj4g
QW55IGlkZWFzIGFyZSBhcHByZWNpYXRlZC4gVGhhbmsgeW91IHZlcnkgbXVjaCENCj4gPj4NCj4g
Pj4NCj4gPj4gU2hhbg0KPiA+DQo+IA0KDQo=

Re: Problems of using APU/FPU under linux

[Shanyuan Gao]

No, actually I am using head_4xx.S and I cannot find FPU_UNAVAILABLE =20
in there. Do I need to set it?

And I commented out the _GLOBAL(giveup_fpu) in head_4xx.S because it =20
has conflicts with fpu.S



Shan


On Apr 15, 2008, at 2:37 PM, Stephen Neuendorffer wrote:

> Shanyuan,
>
> Did you install the FPU_UNAVAILABLE trap in head_40x.S?
>
>
>> -----Original Message-----
>> From: Shanyuan Gao [mailto:sygao.research@gmail.com]
>> Sent: Tuesday, April 15, 2008 11:34 AM
>> To: Yoshio Kashiwagi; linuxppc-embedded@ozlabs.org
>> Cc: Stephen Neuendorffer; John Bonesio
>> Subject: Re: Problems of using APU/FPU under linux
>>
>> Thank you, Yoshio!!
>>
>> I just applied the change, seems it works! But it doesn't work
>> correctly. I mean it won't give me traps any more, but the answer is
>> not correctly. I just tried to multiply two float numbers. But it
>> gives me 0.
>>
>> The first time I change the reg.h was to enable apu enable, apu
>> exception enable and fpu enable. It gives me answer 0.
>> The second try I did was enabling apu enable and apu exception,
>> because I notice that inside /arch/powerpc/kernel/fpu.S, it will
>> enable FPU in load_up_fpu. So I guess I cannot enable FPU all the
>> time. However, this time it gave me trap again, well, with a
>> different MSR.
>>
>> Now my guess is load_up_fpu is not working correctly. I am working on
>> that.
>>
>>
>> Shan
>>
>>
>>
>> On Apr 15, 2008, at 2:20 PM, Yoshio Kashiwagi wrote:
>>
>>> Hi,
>>>
>>> The following modification is required if you use APU in user space.
>>>
>>> in include/asm-powerpc/reg.h
>>>
>>> -#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
>>> +#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)
>>>
>>> Yoshio Kashiwagi - Nissin Systems
>>>
>>>> Thank you very much, Steve and John!
>>>>
>>>> My advisor and I discussed how Linux works with APU/FPU a few days
>>>> ago.
>>>  And he had the same thoughts with John. My naive guess was it would
>>> automatically decode FP operations and mask the trap. Now it
>>> answers my
>>> second question. I will try it later.
>>>>
>>>> But for my first question, I searched all (almost all) the files,
>>>> such
>>> as head.S, entry.S, head_4xx.S, etc. And added following three lines
>>> before mtmsr or MTMSRD =EF=BF=BDare used
>>>>
>>>> ori =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<13 =EF=BF=BD/=
* enable fpu */
>>>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<9 =EF=BF=BD =EF=BF=BD/=
* enable apu */
>>>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<3 =EF=BF=BD =EF=BF=BD/=
* enable apu exception */
>>>>
>>>> However the MSR in trap prompts keeps the same (2d030) before and
>>> after I added those lines.=EF=BF=BD
>>>>
>>>> [=EF=BF=BD=EF=BF=BD 31.819079] Bad trap at PC: 10000458, MSR: =
2d030,
>>>> vector=3D800=EF=BF=BD=EF=BF=BD=EF=BF=BD Not
>>> tainted
>>>> [=EF=BF=BD=EF=BF=BD 31.887027]=EF=BF=BD=EF=BF=BD Signal: 5
>>>> [=EF=BF=BD=EF=BF=BD 31.887042]=EF=BF=BD=EF=BF=BD Code:=EF=BF=BD=EF=BF=
=BD 0
>>>> [=EF=BF=BD=EF=BF=BD 31.887058]=EF=BF=BD=EF=BF=BD Addr:=EF=BF=BD=EF=BF=
=BD 0
>>>> Trace/breakpoint trap
>>>>
>>>> I guess there must be some places, like some interrupts that =20
>>>> changed
>>> the MSR that I didn't know. =EF=BF=BD
>>>>
>>>> And for FP exceptions, it has two bits (two modes) in MSR. I think
>>> they are for such exceptions like divided by zero. Do I need to set
>>> them
>>> also?
>>>>
>>>> In my previous build, I also added PPC_FPU under config 40x in =20
>>>> arch/
>>> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't
>>> help.
>>> I will try CONFIG_PPC_FPU later.
>>>>
>>>>
>>>> Shan
>>>>
>>>> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
>>>>
>>>> Hi,
>>>>
>>>> The Linux kernel itself doesn't issue floating point instructions
>>> other than to save and restore the fpu state when necessary.
>>>>
>>>> In Linux, the way it saves and restores the fpu state is to make =20=

>>>> use
>>> of the trap. When the trap (fpu unavailable) occurs, it loads the =20=

>>> fpu
>>> state for the current task, sets up the MSR, and returns to re-=20
>>> try the
>>> instruction.
>>>>
>>>> So, getting the trap is normal. If the FPU is not being set up
>>> correctly, then there may be a problem with the restoring of the
>>> state.
>>>>
>>>> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
>>> enabled. Otherwise the kernel does not setup the fpu exception
>>> handling.
>>>>
>>>> - John
>>>>
>>>>
>>>> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
>>>>
>>>> I'm not sure exactly what's going on here.=EF=BF=BD Generally =
speaking,
>>>> if you
>>>> have the FPU instantiated in the design and enable the APU in the
>>>> msr,
>>>> then the processor should decode FP instructions and send them
>>> directly
>>>> to the APU with no trap.=EF=BF=BD I haven't done this myself, or I =
could
>>>> probably give you some better help...
>>>>
>>>> One thing you should be aware of is that the there are gcc compiler
>>>> patches which are necessary to get the FPU working properly.=EF=BF=BD=

>>>> However,
>>> I
>>>> don't think the failure mode that these patches workaround would
>>>> cause
>>> a
>>>> trap, so my guess is that there is still something else wrong.
>>>>
>>>> Steve
>>>>
>>>> -----Original Message-----
>>>> From: linuxppc-embedded-bounces=20
>>>> +stephen=3Dneuendorffer.name@ozlabs.org
>>>> [mailto:linuxppc-embedded-
>>>> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of =
Shanyuan
>>>> Gao
>>>> Sent: Monday, April 14, 2008 9:18 AM
>>>> To: linuxppc-embedded@ozlabs.org
>>>> Subject: Problems of using APU/FPU under linux
>>>>
>>>> Hi,
>>>>
>>>> Recently I was trying to make APU/FPU working under Linux on Xilinx
>>>> ML410. The standalone programs work perfectly. However under Linux,
>>>> when I try to use a floating point operation, like *fmuls*, it will
>>>> give me a *trap*.
>>>>
>>>> By studying the user guide from Xilinx and dumping the object =20
>>>> files,
>>>> I know I need to change the corresponding bits (APU enable, FP
>>>> enable, maybe APU Exception enable) in Machine State Register. I
>>>> guess I need to enable the bits whenever before the kernel uses
>>>> *mtmsr*. However, it doesn't work. I got the same trap with the =20
>>>> same
>>>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S =20
>>>> to ppc
>>>> tree, but it doesn't work either.
>>>>
>>>> The questions are
>>>> 1. I guess there might be some place that changed MSR after all my
>>>> changes. But I don't know where. And can I write a kernel module to
>>>> change the MSR after booting in Linux? (well, it's hard for me
>>>> though)
>>>>
>>>> 2. Does it have any exception/interrupt mechanism to direct FP
>>>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
>>>> exception/interrupt and decode FP operation by itself?
>>>>
>>>>
>>>> Any ideas are appreciated. Thank you very much!
>>>>
>>>>
>>>> Shan
>>>
>>
>

RE: Problems of using APU/FPU under linux

[Stephen Neuendorffer]

> -----Original Message-----
> From: Shanyuan Gao [mailto:sygao.research@gmail.com]
> Sent: Tuesday, April 15, 2008 11:47 AM
> To: Stephen Neuendorffer; linuxppc-embedded@ozlabs.org
> Cc: John Bonesio; Yoshio Kashiwagi
> Subject: Re: Problems of using APU/FPU under linux
>=20
> No, actually I am using head_4xx.S and I cannot find FPU_UNAVAILABLE
> in there. Do I need to set it?

Yes, I think this is why you are getting the unknown trap.  It appears
that 405's usually don't have FPU and so the code was never put there.

Steve

Re: Problems of using APU/FPU under linux

[John Bonesio]

Hi Shan,

It's not clear what you're trying to do. If you have only one application u=
sing the FPU, and you're setting up the APU and FPU from that user applicat=
ion, I'm not sure if you need the FPU unavailable handler.

If you're going to have multiple applications use the FPU, then you should =
use the FPU unavailable handler. In this case, you'll need to look in head_=
44x.S to see how the FPU unavailable handler is set up, and do something si=
milar in head_4xx.S

If you're going to do all FPU from one user application, you just need to m=
ake sure the kernel doesn't ever clear the FP Available bit in the MSR.

Is this making sense?

model #1: One user app owns/uses FPU: Use Yoshio's suggesting on getting ac=
cess to the MSR to setup the fpu from the user application. Don't use FPU u=
navailable handler, Don't use load_up_fpu(). Check kernel code to make sure=
 it doesn't clear FPU available bit on a context switch.
model #2: Kernel owns FPU, user apps use FPU: Set up the MSR for fpu access=
 in kernel startup code. Set up FPU unavailable handler in kernel. Use load=
_up_fpu(). Make sure the kernel clears the FPU available bit in the MSR on =
context switches.

Hope this helps,

=2D John

On Tuesday 15 April 2008 11:47, Shanyuan Gao wrote:
> No, actually I am using head_4xx.S and I cannot find FPU_UNAVAILABLE =20
> in there. Do I need to set it?
>=20
> And I commented out the _GLOBAL(giveup_fpu) in head_4xx.S because it =20
> has conflicts with fpu.S
>=20
>=20
>=20
> Shan
>=20
>=20
> On Apr 15, 2008, at 2:37 PM, Stephen Neuendorffer wrote:
>=20
> > Shanyuan,
> >
> > Did you install the FPU_UNAVAILABLE trap in head_40x.S?
> >
> >
> >> -----Original Message-----
> >> From: Shanyuan Gao [mailto:sygao.research@gmail.com]
> >> Sent: Tuesday, April 15, 2008 11:34 AM
> >> To: Yoshio Kashiwagi; linuxppc-embedded@ozlabs.org
> >> Cc: Stephen Neuendorffer; John Bonesio
> >> Subject: Re: Problems of using APU/FPU under linux
> >>
> >> Thank you, Yoshio!!
> >>
> >> I just applied the change, seems it works! But it doesn't work
> >> correctly. I mean it won't give me traps any more, but the answer is
> >> not correctly. I just tried to multiply two float numbers. But it
> >> gives me 0.
> >>
> >> The first time I change the reg.h was to enable apu enable, apu
> >> exception enable and fpu enable. It gives me answer 0.
> >> The second try I did was enabling apu enable and apu exception,
> >> because I notice that inside /arch/powerpc/kernel/fpu.S, it will
> >> enable FPU in load_up_fpu. So I guess I cannot enable FPU all the
> >> time. However, this time it gave me trap again, well, with a
> >> different MSR.
> >>
> >> Now my guess is load_up_fpu is not working correctly. I am working on
> >> that.
> >>
> >>
> >> Shan
> >>
> >>
> >>
> >> On Apr 15, 2008, at 2:20 PM, Yoshio Kashiwagi wrote:
> >>
> >>> Hi,
> >>>
> >>> The following modification is required if you use APU in user space.
> >>>
> >>> in include/asm-powerpc/reg.h
> >>>
> >>> -#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
> >>> +#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)
> >>>
> >>> Yoshio Kashiwagi - Nissin Systems
> >>>
> >>>> Thank you very much, Steve and John!
> >>>>
> >>>> My advisor and I discussed how Linux works with APU/FPU a few days
> >>>> ago.
> >>>  And he had the same thoughts with John. My naive guess was it would
> >>> automatically decode FP operations and mask the trap. Now it
> >>> answers my
> >>> second question. I will try it later.
> >>>>
> >>>> But for my first question, I searched all (almost all) the files,
> >>>> such
> >>> as head.S, entry.S, head_4xx.S, etc. And added following three lines
> >>> before mtmsr or MTMSRD =EF=BF=BDare used
> >>>>
> >>>> ori =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<13 =EF=BF=BD=
/* enable fpu */
> >>>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<9 =EF=BF=BD =EF=BF=BD=
/* enable apu */
> >>>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<3 =EF=BF=BD =EF=BF=BD=
/* enable apu exception */
> >>>>
> >>>> However the MSR in trap prompts keeps the same (2d030) before and
> >>> after I added those lines.=EF=BF=BD
> >>>>
> >>>> [=EF=BF=BD=EF=BF=BD 31.819079] Bad trap at PC: 10000458, MSR: 2d030,
> >>>> vector=3D800=EF=BF=BD=EF=BF=BD=EF=BF=BD Not
> >>> tainted
> >>>> [=EF=BF=BD=EF=BF=BD 31.887027]=EF=BF=BD=EF=BF=BD Signal: 5
> >>>> [=EF=BF=BD=EF=BF=BD 31.887042]=EF=BF=BD=EF=BF=BD Code:=EF=BF=BD=EF=
=BF=BD 0
> >>>> [=EF=BF=BD=EF=BF=BD 31.887058]=EF=BF=BD=EF=BF=BD Addr:=EF=BF=BD=EF=
=BF=BD 0
> >>>> Trace/breakpoint trap
> >>>>
> >>>> I guess there must be some places, like some interrupts that =20
> >>>> changed
> >>> the MSR that I didn't know. =EF=BF=BD
> >>>>
> >>>> And for FP exceptions, it has two bits (two modes) in MSR. I think
> >>> they are for such exceptions like divided by zero. Do I need to set
> >>> them
> >>> also?
> >>>>
> >>>> In my previous build, I also added PPC_FPU under config 40x in =20
> >>>> arch/
> >>> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't
> >>> help.
> >>> I will try CONFIG_PPC_FPU later.
> >>>>
> >>>>
> >>>> Shan
> >>>>
> >>>> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> The Linux kernel itself doesn't issue floating point instructions
> >>> other than to save and restore the fpu state when necessary.
> >>>>
> >>>> In Linux, the way it saves and restores the fpu state is to make =20
> >>>> use
> >>> of the trap. When the trap (fpu unavailable) occurs, it loads the =20
> >>> fpu
> >>> state for the current task, sets up the MSR, and returns to re-=20
> >>> try the
> >>> instruction.
> >>>>
> >>>> So, getting the trap is normal. If the FPU is not being set up
> >>> correctly, then there may be a problem with the restoring of the
> >>> state.
> >>>>
> >>>> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
> >>> enabled. Otherwise the kernel does not setup the fpu exception
> >>> handling.
> >>>>
> >>>> - John
> >>>>
> >>>>
> >>>> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
> >>>>
> >>>> I'm not sure exactly what's going on here.=EF=BF=BD Generally speaki=
ng,
> >>>> if you
> >>>> have the FPU instantiated in the design and enable the APU in the
> >>>> msr,
> >>>> then the processor should decode FP instructions and send them
> >>> directly
> >>>> to the APU with no trap.=EF=BF=BD I haven't done this myself, or I c=
ould
> >>>> probably give you some better help...
> >>>>
> >>>> One thing you should be aware of is that the there are gcc compiler
> >>>> patches which are necessary to get the FPU working properly.=EF=BF=BD
> >>>> However,
> >>> I
> >>>> don't think the failure mode that these patches workaround would
> >>>> cause
> >>> a
> >>>> trap, so my guess is that there is still something else wrong.
> >>>>
> >>>> Steve
> >>>>
> >>>> -----Original Message-----
> >>>> From: linuxppc-embedded-bounces=20
> >>>> +stephen=3Dneuendorffer.name@ozlabs.org
> >>>> [mailto:linuxppc-embedded-
> >>>> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Shanyuan
> >>>> Gao
> >>>> Sent: Monday, April 14, 2008 9:18 AM
> >>>> To: linuxppc-embedded@ozlabs.org
> >>>> Subject: Problems of using APU/FPU under linux
> >>>>
> >>>> Hi,
> >>>>
> >>>> Recently I was trying to make APU/FPU working under Linux on Xilinx
> >>>> ML410. The standalone programs work perfectly. However under Linux,
> >>>> when I try to use a floating point operation, like *fmuls*, it will
> >>>> give me a *trap*.
> >>>>
> >>>> By studying the user guide from Xilinx and dumping the object =20
> >>>> files,
> >>>> I know I need to change the corresponding bits (APU enable, FP
> >>>> enable, maybe APU Exception enable) in Machine State Register. I
> >>>> guess I need to enable the bits whenever before the kernel uses
> >>>> *mtmsr*. However, it doesn't work. I got the same trap with the =20
> >>>> same
> >>>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S =20
> >>>> to ppc
> >>>> tree, but it doesn't work either.
> >>>>
> >>>> The questions are
> >>>> 1. I guess there might be some place that changed MSR after all my
> >>>> changes. But I don't know where. And can I write a kernel module to
> >>>> change the MSR after booting in Linux? (well, it's hard for me
> >>>> though)
> >>>>
> >>>> 2. Does it have any exception/interrupt mechanism to direct FP
> >>>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
> >>>> exception/interrupt and decode FP operation by itself?
> >>>>
> >>>>
> >>>> Any ideas are appreciated. Thank you very much!
> >>>>
> >>>>
> >>>> Shan
> >>>
> >>
> >
>=20
>=20
>=20

Re: Problems of using APU/FPU under linux

[Shanyuan Gao]

Sorry I didn't make myself clear. I just want to use FPU as a normal =20
co-processor under Linux. I mean different programs and maybe =20
multiple users, well, for single precision. So I think the exception =20
handler really helps!

Thank you Steve and John, I added the exception handler. It solved =20
the trap problem. However, I still got the answer 0 for 1.25f * =20
3.75f. I am working on it :)


Shan



On Apr 15, 2008, at 2:59 PM, John Bonesio wrote:

> Hi Shan,
>
> It's not clear what you're trying to do. If you have only one =20
> application using the FPU, and you're setting up the APU and FPU =20
> from that user application, I'm not sure if you need the FPU =20
> unavailable handler.
>
> If you're going to have multiple applications use the FPU, then you =20=

> should use the FPU unavailable handler. In this case, you'll need =20
> to look in head_44x.S to see how the FPU unavailable handler is set =20=

> up, and do something similar in head_4xx.S
>
> If you're going to do all FPU from one user application, you just =20
> need to make sure the kernel doesn't ever clear the FP Available =20
> bit in the MSR.
>
> Is this making sense?
>
> model #1: One user app owns/uses FPU: Use Yoshio's suggesting on =20
> getting access to the MSR to setup the fpu from the user =20
> application. Don't use FPU unavailable handler, Don't use =20
> load_up_fpu(). Check kernel code to make sure it doesn't clear FPU =20
> available bit on a context switch.
> model #2: Kernel owns FPU, user apps use FPU: Set up the MSR for =20
> fpu access in kernel startup code. Set up FPU unavailable handler =20
> in kernel. Use load_up_fpu(). Make sure the kernel clears the FPU =20
> available bit in the MSR on context switches.
>
> Hope this helps,
>
> - John
>
> On Tuesday 15 April 2008 11:47, Shanyuan Gao wrote:
>> No, actually I am using head_4xx.S and I cannot find FPU_UNAVAILABLE
>> in there. Do I need to set it?
>>
>> And I commented out the _GLOBAL(giveup_fpu) in head_4xx.S because it
>> has conflicts with fpu.S
>>
>>
>>
>> Shan
>>
>>
>> On Apr 15, 2008, at 2:37 PM, Stephen Neuendorffer wrote:
>>
>>> Shanyuan,
>>>
>>> Did you install the FPU_UNAVAILABLE trap in head_40x.S?
>>>
>>>
>>>> -----Original Message-----
>>>> From: Shanyuan Gao [mailto:sygao.research@gmail.com]
>>>> Sent: Tuesday, April 15, 2008 11:34 AM
>>>> To: Yoshio Kashiwagi; linuxppc-embedded@ozlabs.org
>>>> Cc: Stephen Neuendorffer; John Bonesio
>>>> Subject: Re: Problems of using APU/FPU under linux
>>>>
>>>> Thank you, Yoshio!!
>>>>
>>>> I just applied the change, seems it works! But it doesn't work
>>>> correctly. I mean it won't give me traps any more, but the =20
>>>> answer is
>>>> not correctly. I just tried to multiply two float numbers. But it
>>>> gives me 0.
>>>>
>>>> The first time I change the reg.h was to enable apu enable, apu
>>>> exception enable and fpu enable. It gives me answer 0.
>>>> The second try I did was enabling apu enable and apu exception,
>>>> because I notice that inside /arch/powerpc/kernel/fpu.S, it will
>>>> enable FPU in load_up_fpu. So I guess I cannot enable FPU all the
>>>> time. However, this time it gave me trap again, well, with a
>>>> different MSR.
>>>>
>>>> Now my guess is load_up_fpu is not working correctly. I am =20
>>>> working on
>>>> that.
>>>>
>>>>
>>>> Shan
>>>>
>>>>
>>>>
>>>> On Apr 15, 2008, at 2:20 PM, Yoshio Kashiwagi wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The following modification is required if you use APU in user =20
>>>>> space.
>>>>>
>>>>> in include/asm-powerpc/reg.h
>>>>>
>>>>> -#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
>>>>> +#define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE|MSR_VEC)
>>>>>
>>>>> Yoshio Kashiwagi - Nissin Systems
>>>>>
>>>>>> Thank you very much, Steve and John!
>>>>>>
>>>>>> My advisor and I discussed how Linux works with APU/FPU a few =20
>>>>>> days
>>>>>> ago.
>>>>>  And he had the same thoughts with John. My naive guess was it =20
>>>>> would
>>>>> automatically decode FP operations and mask the trap. Now it
>>>>> answers my
>>>>> second question. I will try it later.
>>>>>>
>>>>>> But for my first question, I searched all (almost all) the files,
>>>>>> such
>>>>> as head.S, entry.S, head_4xx.S, etc. And added following three =20
>>>>> lines
>>>>> before mtmsr or MTMSRD =EF=BF=BDare used
>>>>>>
>>>>>> ori =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<13 =EF=BF=BD=
/* enable fpu */
>>>>>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<9 =EF=BF=BD =EF=BF=BD=
/* enable apu */
>>>>>> oris =EF=BF=BD =EF=BF=BD =EF=BF=BDr10, r10, 1<<3 =EF=BF=BD =EF=BF=BD=
/* enable apu exception */
>>>>>>
>>>>>> However the MSR in trap prompts keeps the same (2d030) before and
>>>>> after I added those lines.=EF=BF=BD
>>>>>>
>>>>>> [=EF=BF=BD=EF=BF=BD 31.819079] Bad trap at PC: 10000458, MSR: =
2d030,
>>>>>> vector=3D800=EF=BF=BD=EF=BF=BD=EF=BF=BD Not
>>>>> tainted
>>>>>> [=EF=BF=BD=EF=BF=BD 31.887027]=EF=BF=BD=EF=BF=BD Signal: 5
>>>>>> [=EF=BF=BD=EF=BF=BD 31.887042]=EF=BF=BD=EF=BF=BD Code:=EF=BF=BD=EF=BF=
=BD 0
>>>>>> [=EF=BF=BD=EF=BF=BD 31.887058]=EF=BF=BD=EF=BF=BD Addr:=EF=BF=BD=EF=BF=
=BD 0
>>>>>> Trace/breakpoint trap
>>>>>>
>>>>>> I guess there must be some places, like some interrupts that
>>>>>> changed
>>>>> the MSR that I didn't know. =EF=BF=BD
>>>>>>
>>>>>> And for FP exceptions, it has two bits (two modes) in MSR. I =20
>>>>>> think
>>>>> they are for such exceptions like divided by zero. Do I need to =20=

>>>>> set
>>>>> them
>>>>> also?
>>>>>>
>>>>>> In my previous build, I also added PPC_FPU under config 40x in
>>>>>> arch/
>>>>> ppc/Kconfig. It compiled arch/powerpc/kernel/fpu.S in, but didn't
>>>>> help.
>>>>> I will try CONFIG_PPC_FPU later.
>>>>>>
>>>>>>
>>>>>> Shan
>>>>>>
>>>>>> On Apr 14, 2008, at 2:32 PM, John Bonesio wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The Linux kernel itself doesn't issue floating point instructions
>>>>> other than to save and restore the fpu state when necessary.
>>>>>>
>>>>>> In Linux, the way it saves and restores the fpu state is to make
>>>>>> use
>>>>> of the trap. When the trap (fpu unavailable) occurs, it loads the
>>>>> fpu
>>>>> state for the current task, sets up the MSR, and returns to re-
>>>>> try the
>>>>> instruction.
>>>>>>
>>>>>> So, getting the trap is normal. If the FPU is not being set up
>>>>> correctly, then there may be a problem with the restoring of the
>>>>> state.
>>>>>>
>>>>>> When you guild the Linux kernel, you need to have CONFIG_PPC_FPU
>>>>> enabled. Otherwise the kernel does not setup the fpu exception
>>>>> handling.
>>>>>>
>>>>>> - John
>>>>>>
>>>>>>
>>>>>> On Monday 14 April 2008 10:35, Stephen Neuendorffer wrote:
>>>>>>
>>>>>> I'm not sure exactly what's going on here.=EF=BF=BD Generally =
speaking,
>>>>>> if you
>>>>>> have the FPU instantiated in the design and enable the APU in the
>>>>>> msr,
>>>>>> then the processor should decode FP instructions and send them
>>>>> directly
>>>>>> to the APU with no trap.=EF=BF=BD I haven't done this myself, or =
I =20
>>>>>> could
>>>>>> probably give you some better help...
>>>>>>
>>>>>> One thing you should be aware of is that the there are gcc =20
>>>>>> compiler
>>>>>> patches which are necessary to get the FPU working properly.=EF=BF=BD=

>>>>>> However,
>>>>> I
>>>>>> don't think the failure mode that these patches workaround would
>>>>>> cause
>>>>> a
>>>>>> trap, so my guess is that there is still something else wrong.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: linuxppc-embedded-bounces
>>>>>> +stephen=3Dneuendorffer.name@ozlabs.org
>>>>>> [mailto:linuxppc-embedded-
>>>>>> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of =20
>>>>>> Shanyuan
>>>>>> Gao
>>>>>> Sent: Monday, April 14, 2008 9:18 AM
>>>>>> To: linuxppc-embedded@ozlabs.org
>>>>>> Subject: Problems of using APU/FPU under linux
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Recently I was trying to make APU/FPU working under Linux on =20
>>>>>> Xilinx
>>>>>> ML410. The standalone programs work perfectly. However under =20
>>>>>> Linux,
>>>>>> when I try to use a floating point operation, like *fmuls*, it =20=

>>>>>> will
>>>>>> give me a *trap*.
>>>>>>
>>>>>> By studying the user guide from Xilinx and dumping the object
>>>>>> files,
>>>>>> I know I need to change the corresponding bits (APU enable, FP
>>>>>> enable, maybe APU Exception enable) in Machine State Register. I
>>>>>> guess I need to enable the bits whenever before the kernel uses
>>>>>> *mtmsr*. However, it doesn't work. I got the same trap with the
>>>>>> same
>>>>>> MSR, as I had no APU/FPU before. I also tried to add the FPU.S
>>>>>> to ppc
>>>>>> tree, but it doesn't work either.
>>>>>>
>>>>>> The questions are
>>>>>> 1. I guess there might be some place that changed MSR after =20
>>>>>> all my
>>>>>> changes. But I don't know where. And can I write a kernel =20
>>>>>> module to
>>>>>> change the MSR after booting in Linux? (well, it's hard for me
>>>>>> though)
>>>>>>
>>>>>> 2. Does it have any exception/interrupt mechanism to direct FP
>>>>>> operation to APU/FPU? Or after enabling APU/FPU it will mask the
>>>>>> exception/interrupt and decode FP operation by itself?
>>>>>>
>>>>>>
>>>>>> Any ideas are appreciated. Thank you very much!
>>>>>>
>>>>>>
>>>>>> Shan
>>>>>
>>>>
>>>
>>
>>
>>
>