VxWorks 6.2 RTP and Floating Point problem

[MattS]

Hi all,
I'm testing an RTP that uses floating point data types. This is for
a PPC7448 processor, btw. When the RTP is spawned, it encounters a
data access error as soon as it hits the floating point code. I'm not
sure why this is happening because I'm using the VX_FP_TASK task option
for the spawned task. Also, in the kernel, I set up the MSR to enable
floating point instruction execution. When debugging the RTP, I
noticed the RTP's copy of the MSR shows that floating point is NOT
enabled. Again, I don't know why. Has anyone run into this or have an
explanation for this?

Thanks,
MattS

[PAD]

Hello Matt,

Does the exception happens in the RTP's initial task? If yes, are you
making sure that the RTP's initial task is started with the VX_FP_TASK
as well? This is done automatically when the RTP is started from the
shell but if your RTP is started programmatically you must set this
option yourself.

--
PAD

[MattS]

Hi PAD,
Thanks for responding. The exception does not happen in the initial
task.
Below, you'll find output from the shell:

rtpSpawn "/home/mstromske/bin/rtptest.vxe", 0, 0, 100, 0x10000, 0,
0x1000000
value = 26824704 = 0x1995000
->
RTP Test for KatanaQP, built Oct 6 2006, 10:56:47

Machine Status Register: 0x00009030
Data Access Register: 0xeeeeeeea
Condition Register: 0x20000844
Data storage interrupt Register: 0x40000000
Task: 0x19981c0 "tRtpTest"
0x19981c0 (tRtpTest): task 0x19981c0 has had a failure and has been
stopped.
0x19981c0 (tRtpTest): fatal kernel task-level exception!

As you can see from the above, I am supplying the VX_FP_TASK option
(0x1000000) to rtpSpawn. My RTP uses taskSpawn to spin off another
task to perform the floating point arithmetic. And yes, I am supplying
the VX_FP_TASK option to taskSpawn. The Machine Status Register above
shows floating point (bit 18) disabled as well as Altivec (bit 6)
disabled. If I go to the shell and run vxMsrGet(), it returns
0x200b030, where those two bits are set. This same thing happens when
I use Workbench to debug this RTP.

Any other suggestions?

Thanks,
MattS

[PAD]

Hello Matt,

I am not familiar with the PPC7448 processor. Are you using a custom
BSP? As far as the usage of the VX_FP_TASK option goes, yes, you seem
to use it appropriately. Out of curiosity, did you try spawning a task
doing floating point operations in the kernel environment? Does this
work?

--
PAD

[MattS]

Hi PAD,

Actually it's Freescale's processor, technically called the MPC7448
(PowerPC based with 604 core). Anyway, yes, I've tried this same test
in kernel space and it works fine. However, I did NOT spawn a task in
kernel space. I just ran the test from the shell. I will try spawning
a task in kernel space and see what results I get. Thanks for the tip.
I am the BSP developer for this product. I'm testing a driver that
needs to run in kernel space with API's available to user space, hence,
my floating point problem. Other interfaces to this driver run fine in
user space. So far, Its just the floating point case that is failing.
If the kernel taskSpawn test doesn't yield any interesting results, I'm
thinking of opening a TSR to Wind River to see if they can shed some
light on this.

Thanks Again,
Matt

[MattS]

Hi PAD,
I ran the test from the kernel: spawned a task in kernel space. The
test ran clean. At this point, I don't know what else to try. I am
going to submit a TSR to Wind River and see if they can come up with
anything.

Thanks,
MattS

[PAD]

Hello Matt,

Does the MPC7448 supports hardware floating point operations or does it
needs the emulation library (software floating point)?

May be you haven't built your application with the appropriate build
specs?

--
PAD

[MattS]

Hi PAD,
The MPC7448 does have hardware floating point support (has an
Altivec coproc). The build specs are correct. I created a small RTP
that does simple floating point instructions and it works fine. I
actually chased the problem down to where my driver does a system call
(sc). According to my PowerPC manual, when a system call is performed,
a system call exception is generated. The MSR gets saved to an SRRx
register and then specific bits in the MSR get cleared. The Floaing
Point Enable bit is one of these bits. I believe there is some context
switching going on here, and I might be running in the exception
context after the system call. I'm working with a Wind River support
engineer on this right now.

Thanks,
MattS