* Problems of using APU/FPU under linux
@ 2008-04-14 16:18 Shanyuan Gao
2008-04-14 17:35 ` Stephen Neuendorffer
[not found] ` <977C41F842E66D4CB2E41332313B615005CB0A39@XSJ-EXCHVS1.xlnx.xilinx.com>
0 siblings, 2 replies; 13+ messages in thread
From: Shanyuan Gao @ 2008-04-14 16:18 UTC (permalink / raw)
To: linuxppc-embedded
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
^ permalink raw reply [flat|nested] 13+ messages in thread* RE: Problems of using APU/FPU under linux 2008-04-14 16:18 Problems of using APU/FPU under linux Shanyuan Gao @ 2008-04-14 17:35 ` Stephen Neuendorffer [not found] ` <977C41F842E66D4CB2E41332313B615005CB0A39@XSJ-EXCHVS1.xlnx.xilinx.com> 1 sibling, 0 replies; 13+ messages in thread From: Stephen Neuendorffer @ 2008-04-14 17:35 UTC (permalink / raw) To: Shanyuan Gao, linuxppc-embedded, git 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <977C41F842E66D4CB2E41332313B615005CB0A39@XSJ-EXCHVS1.xlnx.xilinx.com>]
* Re: Problems of using APU/FPU under linux [not found] ` <977C41F842E66D4CB2E41332313B615005CB0A39@XSJ-EXCHVS1.xlnx.xilinx.com> @ 2008-04-14 18:32 ` John Bonesio 2008-04-14 20:46 ` Shanyuan Gao 0 siblings, 1 reply; 13+ messages in thread From: John Bonesio @ 2008-04-14 18:32 UTC (permalink / raw) To: Stephen Neuendorffer; +Cc: Shanyuan Gao, git, linuxppc-embedded 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 > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-14 18:32 ` John Bonesio @ 2008-04-14 20:46 ` Shanyuan Gao 2008-04-14 21:56 ` John Bonesio ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Shanyuan Gao @ 2008-04-14 20:46 UTC (permalink / raw) To: John Bonesio, Stephen Neuendorffer, linuxppc-embedded [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-14 20:46 ` Shanyuan Gao @ 2008-04-14 21:56 ` John Bonesio 2008-04-14 22:20 ` John Bonesio 2008-04-15 18:20 ` Yoshio Kashiwagi 2 siblings, 0 replies; 13+ messages in thread From: John Bonesio @ 2008-04-14 21:56 UTC (permalink / raw) To: Shanyuan Gao; +Cc: John Bonesio, Stephen Neuendorffer, linuxppc-embedded 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 > >> > >> > > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-14 20:46 ` Shanyuan Gao 2008-04-14 21:56 ` John Bonesio @ 2008-04-14 22:20 ` John Bonesio 2008-04-15 18:20 ` Yoshio Kashiwagi 2 siblings, 0 replies; 13+ messages in thread From: John Bonesio @ 2008-04-14 22:20 UTC (permalink / raw) To: Shanyuan Gao; +Cc: John Bonesio, Stephen Neuendorffer, linuxppc-embedded 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 > >> > >> > > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-14 20:46 ` Shanyuan Gao 2008-04-14 21:56 ` John Bonesio 2008-04-14 22:20 ` John Bonesio @ 2008-04-15 18:20 ` Yoshio Kashiwagi 2008-04-15 18:34 ` Shanyuan Gao 2 siblings, 1 reply; 13+ messages in thread From: Yoshio Kashiwagi @ 2008-04-15 18:20 UTC (permalink / raw) To: Shanyuan Gao, John Bonesio, Stephen Neuendorffer, linuxppc-embedded 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-15 18:20 ` Yoshio Kashiwagi @ 2008-04-15 18:34 ` Shanyuan Gao 2008-04-15 18:37 ` Stephen Neuendorffer 0 siblings, 1 reply; 13+ messages in thread From: Shanyuan Gao @ 2008-04-15 18:34 UTC (permalink / raw) To: Yoshio Kashiwagi, linuxppc-embedded; +Cc: John Bonesio, Stephen Neuendorffer 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Problems of using APU/FPU under linux 2008-04-15 18:34 ` Shanyuan Gao @ 2008-04-15 18:37 ` Stephen Neuendorffer 2008-04-15 18:47 ` Shanyuan Gao 0 siblings, 1 reply; 13+ messages in thread From: Stephen Neuendorffer @ 2008-04-15 18:37 UTC (permalink / raw) To: Shanyuan Gao, Yoshio Kashiwagi, linuxppc-embedded 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= ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-15 18:37 ` Stephen Neuendorffer @ 2008-04-15 18:47 ` Shanyuan Gao 2008-04-15 18:50 ` Stephen Neuendorffer 2008-04-15 18:59 ` John Bonesio 0 siblings, 2 replies; 13+ messages in thread From: Shanyuan Gao @ 2008-04-15 18:47 UTC (permalink / raw) To: Stephen Neuendorffer, linuxppc-embedded 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 >>> >> > ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Problems of using APU/FPU under linux 2008-04-15 18:47 ` Shanyuan Gao @ 2008-04-15 18:50 ` Stephen Neuendorffer 2008-04-15 18:59 ` John Bonesio 1 sibling, 0 replies; 13+ messages in thread From: Stephen Neuendorffer @ 2008-04-15 18:50 UTC (permalink / raw) To: Shanyuan Gao, linuxppc-embedded > -----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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-15 18:47 ` Shanyuan Gao 2008-04-15 18:50 ` Stephen Neuendorffer @ 2008-04-15 18:59 ` John Bonesio 2008-04-15 19:26 ` Shanyuan Gao 1 sibling, 1 reply; 13+ messages in thread From: John Bonesio @ 2008-04-15 18:59 UTC (permalink / raw) To: Shanyuan Gao; +Cc: Stephen Neuendorffer, linuxppc-embedded 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems of using APU/FPU under linux 2008-04-15 18:59 ` John Bonesio @ 2008-04-15 19:26 ` Shanyuan Gao 0 siblings, 0 replies; 13+ messages in thread From: Shanyuan Gao @ 2008-04-15 19:26 UTC (permalink / raw) To: John Bonesio, Stephen Neuendorffer, linuxppc-embedded 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 >>>>> >>>> >>> >> >> >> > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-04-15 19:26 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-14 16:18 Problems of using APU/FPU under linux Shanyuan Gao
2008-04-14 17:35 ` Stephen Neuendorffer
[not found] ` <977C41F842E66D4CB2E41332313B615005CB0A39@XSJ-EXCHVS1.xlnx.xilinx.com>
2008-04-14 18:32 ` John Bonesio
2008-04-14 20:46 ` Shanyuan Gao
2008-04-14 21:56 ` John Bonesio
2008-04-14 22:20 ` John Bonesio
2008-04-15 18:20 ` Yoshio Kashiwagi
2008-04-15 18:34 ` Shanyuan Gao
2008-04-15 18:37 ` Stephen Neuendorffer
2008-04-15 18:47 ` Shanyuan Gao
2008-04-15 18:50 ` Stephen Neuendorffer
2008-04-15 18:59 ` John Bonesio
2008-04-15 19:26 ` Shanyuan Gao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).