Re: Floating Point problems with Linux on the EST SBC8260

Re: Floating Point problems with Linux on the EST SBC8260

[Neil Russell]

I ported 2.2.14 to the SBC8260 myself.  I did this because the 2.3 kernel
was unstable at the time I started.  I asked Dan for his work but we was
reluctant.

Initially, the kernel panic'ed trying to run init because the C library
uses the FPU by default (this is one of the reasons for the stuff Dan
did for the 860).  This problem was solved by upgrading the CPU to rev A.1,
which has a fully functioning FPU.

The first time I brought the kernel up I just used a /bin/sh, and no init.
The shell I used was statically linked (from /bin/ash.static I think).

I'm part way getting the SCC ethernet to work and fixing the way I do
bootinfo.  I'll look to making a patch after that (hopefully within a
week).

My development environment is a G3 blue and white MAC, running Linux 1999 Q3.
I compile the kernel native on that machine.  All applications that I
use are directly from that CD.  I make a RAM disk image that I download
to the board.  This RAM disk has very little in it.


Neil.




On Wed, May 24, 2000 at 05:41:12PM -0400, diekema_jon wrote:
> From: Neil Russell <caret@c-side.com>
>
> > I'm running 2.2.14 the SBC8260 and some other hardware.
>
> I wasn't aware of a MPC8260 Linux 2.2.x port.  Where did you get this
> source code?  Is this is something that you crafted yourself?  Are
> you able to run init without the kernel panicing?  If so, is it
> possible to get this source?
>
> If you haven't figured it out yet, we are struggling with Linux 2.3.99+.
>
>

On Wed, May 24, 2000 at 05:31:18PM -0400, diekema_jon wrote:
> >From caret@c-side.com (Neil Russell)
>
> > I tried this on my board.  I'm running 2.2.14 the SBC8260 and some other
> > hardware.  I ran the code you posted and it produced exactly the results
> > that it should have.
>
> What does your development/target environment look like?
>
> - What toolset are you using?
> - What is the toolset hosted on?
> - Are you using hard or soft floating point?
> - What are you using for a root file system?
>   Or, what distribution is being used for the root
>   file system?

--
Neil Russell <caret@c-side.com>

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

Re: Floating Point problems with Linux on the EST SBC8260

[Dan Malek]

Neil Russell wrote:

> I'm part way getting the SCC ethernet to work and fixing the way I do
> bootinfo.  I'll look to making a patch after that (hopefully within a
> week).

You should be able to lift the driver from the 2.3.99 kernel and make
a couple of minor modifications.  There are just a couple of obvious
places where the kernel/driver interface changes (synchronization points),
and then add the 8260 interrupt and cache snooping changes.  It may be
easier to take the 8xx enet.c driver from 2.2.13 and apply 8260 changes.

Are you using SMC1 for the console?  Is this a custom board?

> I compile the kernel native on that machine.  All applications that I
> use are directly from that CD.

This is subtle but important.  Using a consistent set of tools,
libraries, and applications makes life much easier.

Do you want any of the work patched into 2.2.15 or 2.3.99?


	-- Dan

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

Re: Floating Point problems with Linux on the EST SBC8260

[Neil Russell]

On Wed, May 24, 2000 at 06:26:27PM -0400, Dan Malek wrote:
> You should be able to lift the driver from the 2.3.99 kernel and make
> a couple of minor modifications.  There are just a couple of obvious
> places where the kernel/driver interface changes (synchronization points),
> and then add the 8260 interrupt and cache snooping changes.  It may be
> easier to take the 8xx enet.c driver from 2.2.13 and apply 8260 changes.

I'm taking the 2.2 version and going from there, as I did with the SMC driver.

> Are you using SMC1 for the console?  Is this a custom board?

console = SMC1.  First ported to SBC8260 (EST board), then to custom h/w.
The custom h/w has an IDE interface;  I hope to get the whole linux-1999 Q3
working on it;  that should be interesting.

> Do you want any of the work patched into 2.2.15 or 2.3.99?

Sure!  It might be a few weeks though...


Neil.

--
Neil Russell <caret@c-side.com>

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

Re: Floating Point problems with Linux on the EST SBC8260

[Dan Malek]

Neil Russell wrote:

> console = SMC1.  First ported to SBC8260 (EST board), then to custom h/w.
> The custom h/w has an IDE interface;  I hope to get the whole linux-1999 Q3
> working on it;  that should be interesting.

Oh oh.....You opened the flood gates for questions now :-).  How did
you connect the IDE?


> Sure!  It might be a few weeks though...

Send patches and tell me the baseline......


Thanks.


	-- Dan

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

Re: Floating Point problems with Linux on the EST SBC8260

[Neil Russell]

We have an FPGA that implements part of the ISA spec, enough to do
programmed I/O to an IDE device.  The FPGA has its own chip select and uses
the UPM for timing.  It doesn't work correctly yet because what the 8260
documentation says and what the 8260 does are different.  When it works,
it will be slow, but we probably don't care - we are not building a
file server.

I'm not sure that we care enough to redesign the logic to make it fast,
but I do care that it doesn't slow everything else down, so at some point
I plan to look to using some form of DMA; perhaps the SDMA that the CPM
provides.  It will probably still be slow, but he CPU will no longer be
held up.

Got any better ideas?  (no PCI, no expensive chips...).


Neil.


On Wed, May 24, 2000 at 09:22:10PM -0400, Dan Malek wrote:
> > console = SMC1.  First ported to SBC8260 (EST board), then to custom h/w.
> > The custom h/w has an IDE interface;  I hope to get the whole linux-1999 Q3
> > working on it;  that should be interesting.
>
> Oh oh.....You opened the flood gates for questions now :-).  How did
> you connect the IDE?

--
Neil Russell <caret@c-side.com>

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

Re: Floating Point problems with Linux on the EST SBC8260

[Dan Malek]

Neil Russell wrote:

> We have an FPGA that implements part of the ISA spec, enough to do
> programmed I/O to an IDE device.  The FPGA has its own chip select and uses
> the UPM for timing.


Interesting....I have used an FPGA or the UPM to provide the ISA
bus timing, but not both at the same time.  I have UPM programming
for the 8xx that creates ISA bus timing, so I guess I could try that
on the 8260 as well.....I think it needs an external signal inversion,
but that is all.

> .........  When it works,
> it will be slow, but we probably don't care - we are not building a
> file server.

Hmmmm....I'll bet it can be made to work with compact flash as well....

> ....  It will probably still be slow, but he CPU will no longer be
> held up.

Depending upon the data flow, they may still share a common internal
bus....Plus you tie up the CPM.

> Got any better ideas?  (no PCI, no expensive chips...).

I just gave it away, and I have another project on the pile :-).


	-- Dan

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

Re: Floating Point problems with Linux on the EST SBC8260

[Geir Frode Raanes]

On Wed, 24 May 2000, Neil Russell wrote:


> We have an FPGA that implements part of the ISA spec, enough to do
> programmed I/O to an IDE device.  The FPGA has its own chip select and uses
> the UPM for timing.  It doesn't work correctly yet because what the 8260
> documentation says and what the 8260 does are different.  When it works,
> it will be slow, but we probably don't care - we are not building a
> file server.

You tell me your HW designers can't operate a logic analyzer?
Be nice. My guess is that they are experiencing some transmission
line failures. It is also hard to reach the /TA line timing
requirements with FPGA. Logical errors are simple to correct.
Reflected waves or responstime errors not quite so. BTW, when you
already have a full FPGA installed then why waste a UPM? A full
local bus decoder does not take that much FPGA space.
And if you do share a /CSn line and only decodes the LS address
bits, then the gates reqirement can be cut in half. This is not
even that hard to do. We do it already in both Altera and Xilinx.

> I'm not sure that we care enough to redesign the logic to make it fast,
> but I do care that it doesn't slow everything else down, so at some point
> I plan to look to using some form of DMA; perhaps the SDMA that the CPM
> provides.  It will probably still be slow, but he CPU will no longer be
> held up.
>
> Got any better ideas?  (no PCI, no expensive chips...).

HW FIFOs are always nice to have, even with HDD caches.
Concatenating 16 bit IDE PIO stobes into 32/64 bit PowerPC burst
transfers are likewise not to be foresaken. But this works best for
large datatransfers or else the overhead from "data ready"
interrupts will be expensive. Or one could hook the "data ready"
line up against an IDMA_REQ line instead.

Actually, I am about to implemet this kind of interface for the
MPC860. I have just recived a go from our management on designing
our own scalable MBX860 board. Which means it will be awhile
before I get around to the IDE interface. But to keep power
drain low I will probabely use the second PCMCIA port for it
by means of Xilinx Coolrunner and an AVR for autoconfiguration.
Then I could (but will not) expand this into a full ISA bus.

BTW, VxWorks can not easily handle more than 32 MBytes of local RAM
as the eabi specification (as a result of the PowerPC architecure)
rules for 26 bit (signed) relative addressing. Hence, I will design
in exactly 32 MBytes of soldered low power SDRAM on UPMA and assign
UPMB to a DIMM socket. How does PPC/Linux handle this addressing
problem?

One more - if anyone has the specification for Sony Memorystick
I would be interested. I am pretty certain that this flashstick
has a serial interface on it. Most probabely SPI since Sony use
SPI extensively in the Playstation among others. This would suite
a PowerQUICC just fine, thus avoiding those ATA flash disks
completely. As you should be aware of by now, I am absolutely
no fan of ATA from a HW point of view. And since struggling
with the ATA device drivers in VxWorks, neither from a SW point
of view. Thank you for your attention. But I will nevertheless
design ATA interfaces for the interested parties.

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************


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

Re: Floating Point problems with Linux on the EST SBC8260

[Dan Malek]

Geir Frode Raanes wrote:

> You tell me your HW designers can't operate a logic analyzer?

Hardware designers?  This is just software and a few wires :-).

> ...... BTW, when you
> already have a full FPGA installed then why waste a UPM?


You know, I keep hearing this question and continually find boards
with external hardware and no one using the integrated control logic.
Everyone is "saving it for something else".  Geeze, these are embedded
systems that will probably never change.  After I use up all of the
GP I/O and internal control logic, I will start looking for alternatives.
The 8260 is even better. Separate DRAM controllers so you don't even
use up the UPMs for that, more chip selects, more I/O, multiple busses.
You bought it, may as well use it.

> .... But to keep power
> drain low I will probabely use the second PCMCIA port for it
> by means of Xilinx Coolrunner and an AVR for autoconfiguration.
> Then I could (but will not) expand this into a full ISA bus.

Why bother with the Xilinx?  Just connect the IDE to the PCMCIA.
I think you could even DMA over the port.


> .... How does PPC/Linux handle this addressing
> problem?

What addressing problem?  The 860 supports 32 bits of address, so
does Linux.  No problem.  I started to add support for multiple real
memory spaces (which isn't hard, you just have to detect it), and then
realized it isn't necessary.  With the 8xx memory controller you can
make external RAM one linear space, unless you wire it up really stupid.

> One more - if anyone has the specification for Sony Memorystick
> I would be interested. I am pretty certain that this flashstick
> has a serial interface on it.

Maybe it is similar to the SanDisk MMC interface?  That is an SPI
interface, perhaps there is some access standard.


	-- Dan

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

Re: Floating Point problems with Linux on the EST SBC8260

[Adrian Cox]

Geir Frode Raanes wrote:

> BTW, VxWorks can not easily handle more than 32 MBytes of local RAM
> as the eabi specification (as a result of the PowerPC architecure)
> rules for 26 bit (signed) relative addressing. Hence, I will design
> in exactly 32 MBytes of soldered low power SDRAM on UPMA and assign
> UPMB to a DIMM socket. How does PPC/Linux handle this addressing
> problem?

The current release of VxWorks is prepared to use a long jump sequence
to jump to a 32 bit address. Tornado 2 out of the box has worked fine
for me on a 128MByte 7400.

The problem only ever occurs when your code occupies an address range
greater than 32MBytes. VxWorks doesn't support virtual addressing
without some add-ons. It always placed the kernel at the bottom of
memory and dynamically loaded code at the top, so that calls from the
dynamically loaded code into the kernel had offsets that couldn't fit in
a relative branch.

Linux, however, never had this problem. Linux uses virtual memory, which
keeps the application within a smaller address range.

- Adrian Cox, AG Electronics

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

Re: Floating Point problems with Linux on the EST SBC8260

[Geir Frode Raanes]

On Fri, 26 May 2000, Adrian Cox wrote:

>
> Geir Frode Raanes wrote:
>
> > BTW, VxWorks can not easily handle more than 32 MBytes of local RAM
> > as the eabi specification (as a result of the PowerPC architecure)
> > rules for 26 bit (signed) relative addressing. Hence, I will design
> > in exactly 32 MBytes of soldered low power SDRAM on UPMA and assign
> > UPMB to a DIMM socket. How does PPC/Linux handle this addressing
> > problem?
>
> The current release of VxWorks is prepared to use a long jump sequence
> to jump to a 32 bit address. Tornado 2 out of the box has worked fine
> for me on a 128MByte 7400.

Yes, one can always use the "-mlongcall" flag to GCC.
Or boot the kernel with only 32 MBytes in sysLib.c, load
the application (defaults to top of memory, while the kernel
sits in low memory) and then "memAddToPool(sysMemTop(),0x2000000)"
This is a FAQ issue. I have not verified the existence of the
problem myself.

> It always placed the kernel at the bottom of
> memory and dynamically loaded code at the top, so that calls from the
> dynamically loaded code into the kernel had offsets that couldn't fit
> in a relative branch.

Yeees, this will not fit into 26 bit signed relative addressing.
But are you telling me that VxWorks do use longcalls per default...
or not? (Ie. did this >32MByte separation work or not?)

> Linux, however, never had this problem. Linux uses virtual memory, which
> keeps the application within a smaller address range.

I am aware that the MMU makes the question of addressing ranges
somewhat lame. But I am scared of the dark and in this case I can
not see past the MMU and into Linux addressing modes.

Actually, I have obviousely a blind-spot in my understanding
of how API calls work on Linux. User space is 4 GBytes linear.
At the bottom is the enviroment tables copied prom the parent
process. If I remember correctly, then the stack is at the
lowest addresses above this, then comes the ELF text segment,
then BSS, then data and the rest goes into the memory heap.

API calls results in violation exceptions which the OS will
service. But to provoce an violation exception the user
application must be able to address supervisor owned space
in the first place. Meaning that some part of of the User
space must be shared with the kernel and that this space
must contain the API functions entrypoints. Correct?

--
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************


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

Re: Floating Point problems with Linux on the EST SBC8260

[Adrian Cox]

Geir Frode Raanes wrote:
> Yes, one can always use the "-mlongcall" flag to GCC.
> Or boot the kernel with only 32 MBytes in sysLib.c, load
> the application (defaults to top of memory, while the kernel
> sits in low memory) and then "memAddToPool(sysMemTop(),0x2000000)"
> This is a FAQ issue. I have not verified the existence of the
> problem myself.
> [...]
I've just performed a test, and what happens is that VxWorks dynamic
loading now starts in low memory rather than high memory. You may still
need to specify longcall in development, but as deployed applications
don't use dynamic loading, the problem has pretty well gone away.

> Actually, I have obviousely a blind-spot in my understanding
> of how API calls work on Linux. User space is 4 GBytes linear.
> At the bottom is the enviroment tables copied prom the parent
> process. If I remember correctly, then the stack is at the
> lowest addresses above this, then comes the ELF text segment,
> then BSS, then data and the rest goes into the memory heap.

The user space on PowerPC is only 3GB at the moment. This means that
only 1GB of RAM is supported, as all RAM must be mapped into the
remaining address space (0xc0000000 to 0xffffffff). This image of all
physical RAM is only accessible in supervisor mode. We'll soon need
somebody to come up with a trick comparable to the way large memory x86
systems work, so that we can have 2GB PPC systems.

(In a perfect world, a follow up message would tell me that I've not
been paying attention, and this has already happened.)

> API calls results in violation exceptions which the OS will
> service. But to provoce an violation exception the user
> application must be able to address supervisor owned space
> in the first place. Meaning that some part of of the User
> space must be shared with the kernel and that this space
> must contain the API functions entrypoints. Correct?

>From a brief examination of head.S, system calls work by an application
performing the sc instruction, which starts execution from physical
address 0xc00 in supervisor mode. Once address translation is turned
back on the kernel sees kernel address space starting at virtual address
0xc0000000, and user space starting at virtual address 0x0.

- Adrian Cox, AG Electronics

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

Re: Floating Point problems with Linux on the EST SBC8260

[diekema_jon]

From: Neil Russell <caret@c-side.com>

> My development environment is a G3 blue and white MAC, running Linux 1999 Q3.
> I compile the kernel native on that machine.  All applications that I
> use are directly from that CD.  I make a RAM disk image that I download
> to the board.  This RAM disk has very little in it.

What files are contained in the RAM disk image, and how big is it?  Do
you statically link your application to avoid packaging the libraries?


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

RE: Floating Point problems with Linux on the EST SBC8260

[Gessner, Matt]

All the docs I have from Moto say that the FPU is disabled.
My ESTSBC8260 has CPU's with the following info on them:

	XPC8260ZU166A
	166/133/66 MHZ
	1K22A CRECH0005 HKG

and

	XPC8260ZU200A
	200/133/66 MHZ
	1K22A CRETK0010 HKG

Are these FPU capable?

Thx

> -----Original Message-----
> From: Neil Russell [mailto:caret@c-side.com]
> Sent: Wednesday, May 24, 2000 4:44 PM
> To: diekema_jon
> Cc: all@cideas.com; linuxppc-embedded@lists.linuxppc.org
> Subject: Re: Floating Point problems with Linux on the EST SBC8260
>
>
>
> On Wed, May 24, 2000 at 03:47:10PM -0400, diekema_jon wrote:
> >
> > Floating Point problems with Linux on the EST SBC8260:
> >
> >
> > Questions:
> >
> > - What is the state of floating point support with Linux on the
> >   MPC8260?
> >
> > - Does anybody have hard-float applications running on the MPC8260?
> >
> > - I am looking for a floating point validation test suite written in
> >   C.  The test suite should start with the fundamentals and work out
> >   from there.
> >
> >   Does anybody have any leads?  This is what I have found so far:
> >
> > 1) TestFloat-2a
> >
> > Package Overview for TestFloat Release 2a
> >
> > John R. Hauser
> > 1998 December 16
> >
> >
> > TestFloat is a program for testing that a floating-point
> implementation
> > conforms to the IEC/IEEE Standard for Binary Floating-Point
> Arithmetic.
> > TestFloat is distributed in the form of C source code.  The
> TestFloat
> > package actually provides two related programs:
> >
> > -- The `testfloat' program tests a system's floating-point
> for conformance
> >    to the IEC/IEEE Standard.  This program uses the
> SoftFloat software
> >    floating-point implementation as a basis for comparison.
> >
> > -- The `testsoftfloat' program tests SoftFloat itself for
> conformance to
> >    the IEC/IEEE Standard.  These tests are performed by
> comparing against a
> >    separate, slower software floating-point that is
> included in the TestFloat
> >    package.
> >
> > 2) UCBTEST
> >
> >      UCBTEST is a suite of programs for testing certain
> difficult cases of
> > IEEE 754 floating-point arithmetic.  Some of the difficult
> test cases are
> > obtained from number-theoretic algorithms developed by
> Turing Award winner
> > Prof. W. Kahan, Department of Electrical Engineering and
> Computer Science,
> > University of California, Berkeley, as part of ongoing
> research into test
> > methods for computer arithmetic.
> >
> >
> > Either TestFloat or UCBTEST will require some porting effort to run
> > on the PPC.  I would like to work smarter rather than
> harder. I can't
> > even get the rights answers from printf, *, or /.
> >
> >
> > Environment:
> >
> > Platform: EST SBC8260 w/ MPC8260 Rev A.1 running at 166 Mhz
> > Ethernet: 10 Mbs (SCC)
> > Linux kernel: 2.3.99-pre9
> > root filesystem (NFS mounted): MontaVista Hard Hat Linux version 1.1
> > Toolset: Denx Software CDK recompiled with gcc configured for
> >          --with-cpu=603e and hard-float (i.e. no --nfp)
> >
> >
> > Application:
> >
> > Note: The executable was statically linked to pull in the hard-float
> >       C runtime libraries.
> >
> > dell 403} cat z.c
> > #include "stdio.h"
> >
> > double x, y, z;
> >
> > main ()
> >
> > {
> >   x = 1234.33;
> >   printf("x %lf (1234.33) 0x%08lX\n", x , x);
> >
> >   y = 4444.2;
> >   printf("y %lf (4444.2)  0x%08lX\n", y , y);
> >
> >   z = x * y;
> >   printf("z = x * y, %lf %lf %lf\n", x , y, z);
> >
> >   z = x / y;
> >   printf("z = x / y, %lf %lf %lf\n", x , y, z);
> > }
> >
> > dell 404} cat z.s
> > 	.file	"z.c"
> > gcc2_compiled.:
> > 	.section	".rodata"
> > 	.align 2
> > .LC1:
> > 	.string	"x %lf (1234.33) 0x%08lX\n"
> > 	.align 2
> > .LC3:
> > 	.string	"y %lf (4444.2)  0x%08lX\n"
> > 	.align 2
> > .LC4:
> > 	.string	"z = x * y, %lf %lf %lf\n"
> > 	.align 2
> > .LC5:
> > 	.string	"z = x / y, %lf %lf %lf\n"
> > 	.align 3
> > .LC0:
> > 	.long 0x40934951
> > 	.long 0xeb851eb8
> > 	.align 3
> > .LC2:
> > 	.long 0x40b15c33
> > 	.long 0x33333333
> > 	.section	".text"
> > 	.align 2
> > 	.globl main
> > 	.type	 main,@function
> > main:
> > 	stwu 1,-16(1)
> > 	mflr 0
> > 	stw 31,12(1)
> > 	stw 0,20(1)
> > 	mr 31,1
> > 	lis 9,x@ha
> > 	lis 11,.LC0@ha
> > 	lfd 0,.LC0@l(11)
> > 	stfd 0,x@l(9)
> > 	lis 9,x@ha
> > 	lis 11,x@ha
> > 	lis 10,.LC1@ha
> > 	la 3,.LC1@l(10)
> > 	lfd 1,x@l(9)
> > 	lfd 2,x@l(11)
> > 	creqv 6,6,6
> > 	bl printf
> > 	lis 9,y@ha
> > 	lis 11,.LC2@ha
> > 	lfd 0,.LC2@l(11)
> > 	stfd 0,y@l(9)
> > 	lis 9,y@ha
> > 	lis 11,y@ha
> > 	lis 10,.LC3@ha
> > 	la 3,.LC3@l(10)
> > 	lfd 1,y@l(9)
> > 	lfd 2,y@l(11)
> > 	creqv 6,6,6
> > 	bl printf
> > 	lis 9,z@ha
> > 	lis 11,x@ha
> > 	lis 10,y@ha
> > 	lfd 0,x@l(11)
> > 	lfd 13,y@l(10)
> > 	fmul 0,0,13
> > 	stfd 0,z@l(9)
> > 	lis 9,x@ha
> > 	lis 11,y@ha
> > 	lis 10,z@ha
> > 	lis 8,.LC4@ha
> > 	la 3,.LC4@l(8)
> > 	lfd 1,x@l(9)
> > 	lfd 2,y@l(11)
> > 	lfd 3,z@l(10)
> > 	creqv 6,6,6
> > 	bl printf
> > 	lis 9,z@ha
> > 	lis 11,x@ha
> > 	lis 10,y@ha
> > 	lfd 0,x@l(11)
> > 	lfd 13,y@l(10)
> > 	fdiv 0,0,13
> > 	stfd 0,z@l(9)
> > 	lis 9,x@ha
> > 	lis 11,y@ha
> > 	lis 10,z@ha
> > 	lis 8,.LC5@ha
> > 	la 3,.LC5@l(8)
> > 	lfd 1,x@l(9)
> > 	lfd 2,y@l(11)
> > 	lfd 3,z@l(10)
> > 	creqv 6,6,6
> > 	bl printf
> > .L2:
> > 	lwz 11,0(1)
> > 	lwz 0,4(11)
> > 	mtlr 0
> > 	lwz 31,-4(11)
> > 	mr 1,11
> > 	blr
> > .Lfe1:
> > 	.size	 main,.Lfe1-main
> > 	.comm	x,8,8
> > 	.comm	y,8,8
> > 	.comm	z,8,8
> > 	.ident	"GCC: (GNU) 2.95.2 19991024 (release)"
> >
> >
> > On the target:
> >
> > > ./a.out
> > x nan (1234.33) 0x00000000
> > y 0.000000 (4444.2)  0x1003FBCC
> > z = x * y, 0.000000 0.000000 0.000000
> > z = x / y, 0.000000 0.000000 0.000000
> >
> >
> > The expected results should look something like:
> >
> > dell 420} ./a.out
> > x 1234.330000 (1234.33) 0xEB851EB8
> > y 4444.200000 (4444.2)  0x33333333
> > z = x * y, 1234.330000 4444.200000 5485609.386000
> > z = x / y, 1234.330000 4444.200000 0.277740
> >
> > We aren't even close to reasonable answers yet.
> >
>
> --
> Neil Russell <caret@c-side.com>
>

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

Re: Floating Point problems with Linux on the EST SBC8260

[Dan Malek]

"Gessner, Matt" wrote:
>
> All the docs I have from Moto say that the FPU is disabled.

Get new documentation or the documentation updates......

> Are these FPU capable?

Yes.


	-- Dan

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

Floating Point problems with Linux on the EST SBC8260

[diekema_jon]

Floating Point problems with Linux on the EST SBC8260:


Questions:

- What is the state of floating point support with Linux on the
  MPC8260?

- Does anybody have hard-float applications running on the MPC8260?

- I am looking for a floating point validation test suite written in
  C.  The test suite should start with the fundamentals and work out
  from there.

  Does anybody have any leads?  This is what I have found so far:

1) TestFloat-2a

Package Overview for TestFloat Release 2a

John R. Hauser
1998 December 16


TestFloat is a program for testing that a floating-point implementation
conforms to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
TestFloat is distributed in the form of C source code.  The TestFloat
package actually provides two related programs:

-- The `testfloat' program tests a system's floating-point for conformance
   to the IEC/IEEE Standard.  This program uses the SoftFloat software
   floating-point implementation as a basis for comparison.

-- The `testsoftfloat' program tests SoftFloat itself for conformance to
   the IEC/IEEE Standard.  These tests are performed by comparing against a
   separate, slower software floating-point that is included in the TestFloat
   package.

2) UCBTEST

     UCBTEST is a suite of programs for testing certain difficult cases of
IEEE 754 floating-point arithmetic.  Some of the difficult test cases are
obtained from number-theoretic algorithms developed by Turing Award winner
Prof. W. Kahan, Department of Electrical Engineering and Computer Science,
University of California, Berkeley, as part of ongoing research into test
methods for computer arithmetic.


Either TestFloat or UCBTEST will require some porting effort to run
on the PPC.  I would like to work smarter rather than harder. I can't
even get the rights answers from printf, *, or /.


Environment:

Platform: EST SBC8260 w/ MPC8260 Rev A.1 running at 166 Mhz
Ethernet: 10 Mbs (SCC)
Linux kernel: 2.3.99-pre9
root filesystem (NFS mounted): MontaVista Hard Hat Linux version 1.1
Toolset: Denx Software CDK recompiled with gcc configured for
         --with-cpu=603e and hard-float (i.e. no --nfp)


Application:

Note: The executable was statically linked to pull in the hard-float
      C runtime libraries.

dell 403} cat z.c
#include "stdio.h"

double x, y, z;

main ()

{
  x = 1234.33;
  printf("x %lf (1234.33) 0x%08lX\n", x , x);

  y = 4444.2;
  printf("y %lf (4444.2)  0x%08lX\n", y , y);

  z = x * y;
  printf("z = x * y, %lf %lf %lf\n", x , y, z);

  z = x / y;
  printf("z = x / y, %lf %lf %lf\n", x , y, z);
}

dell 404} cat z.s
	.file	"z.c"
gcc2_compiled.:
	.section	".rodata"
	.align 2
.LC1:
	.string	"x %lf (1234.33) 0x%08lX\n"
	.align 2
.LC3:
	.string	"y %lf (4444.2)  0x%08lX\n"
	.align 2
.LC4:
	.string	"z = x * y, %lf %lf %lf\n"
	.align 2
.LC5:
	.string	"z = x / y, %lf %lf %lf\n"
	.align 3
.LC0:
	.long 0x40934951
	.long 0xeb851eb8
	.align 3
.LC2:
	.long 0x40b15c33
	.long 0x33333333
	.section	".text"
	.align 2
	.globl main
	.type	 main,@function
main:
	stwu 1,-16(1)
	mflr 0
	stw 31,12(1)
	stw 0,20(1)
	mr 31,1
	lis 9,x@ha
	lis 11,.LC0@ha
	lfd 0,.LC0@l(11)
	stfd 0,x@l(9)
	lis 9,x@ha
	lis 11,x@ha
	lis 10,.LC1@ha
	la 3,.LC1@l(10)
	lfd 1,x@l(9)
	lfd 2,x@l(11)
	creqv 6,6,6
	bl printf
	lis 9,y@ha
	lis 11,.LC2@ha
	lfd 0,.LC2@l(11)
	stfd 0,y@l(9)
	lis 9,y@ha
	lis 11,y@ha
	lis 10,.LC3@ha
	la 3,.LC3@l(10)
	lfd 1,y@l(9)
	lfd 2,y@l(11)
	creqv 6,6,6
	bl printf
	lis 9,z@ha
	lis 11,x@ha
	lis 10,y@ha
	lfd 0,x@l(11)
	lfd 13,y@l(10)
	fmul 0,0,13
	stfd 0,z@l(9)
	lis 9,x@ha
	lis 11,y@ha
	lis 10,z@ha
	lis 8,.LC4@ha
	la 3,.LC4@l(8)
	lfd 1,x@l(9)
	lfd 2,y@l(11)
	lfd 3,z@l(10)
	creqv 6,6,6
	bl printf
	lis 9,z@ha
	lis 11,x@ha
	lis 10,y@ha
	lfd 0,x@l(11)
	lfd 13,y@l(10)
	fdiv 0,0,13
	stfd 0,z@l(9)
	lis 9,x@ha
	lis 11,y@ha
	lis 10,z@ha
	lis 8,.LC5@ha
	la 3,.LC5@l(8)
	lfd 1,x@l(9)
	lfd 2,y@l(11)
	lfd 3,z@l(10)
	creqv 6,6,6
	bl printf
.L2:
	lwz 11,0(1)
	lwz 0,4(11)
	mtlr 0
	lwz 31,-4(11)
	mr 1,11
	blr
.Lfe1:
	.size	 main,.Lfe1-main
	.comm	x,8,8
	.comm	y,8,8
	.comm	z,8,8
	.ident	"GCC: (GNU) 2.95.2 19991024 (release)"


On the target:

> ./a.out
x nan (1234.33) 0x00000000
y 0.000000 (4444.2)  0x1003FBCC
z = x * y, 0.000000 0.000000 0.000000
z = x / y, 0.000000 0.000000 0.000000


The expected results should look something like:

dell 420} ./a.out
x 1234.330000 (1234.33) 0xEB851EB8
y 4444.200000 (4444.2)  0x33333333
z = x * y, 1234.330000 4444.200000 5485609.386000
z = x / y, 1234.330000 4444.200000 0.277740

We aren't even close to reasonable answers yet.

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

Re: Floating Point problems with Linux on the EST SBC8260

[Bill Roman]

diekema_jon wrote:

> - I am looking for a floating point validation test suite written in
>   C.  The test suite should start with the fundamentals and work out
>   from there.

Try paranoia.c. A web search should turn up multiple copies, I found one at

    http://www.enseeiht.fr/NetLib/paranoia/index.html

A while back I had the floating point emulator from kernel 2.3 patched into
kernel 2.2.13 running on an MBX, and it did reasonably well on this test as I
recall.

>From the comments in paranoia.c:

        A C version of Kahan's Floating Point Test "Paranoia"

                        Thos Sumner, UCSF, Feb. 1985
                        David Gay, BTL, Jan. 1986

        This is a rewrite from the Pascal version by

                        B. A. Wichmann, 18 Jan. 1985

        (and does NOT exhibit good C programming style).
    .
    .
    .

You may copy this program freely if you acknowledge its source.

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

Re: Floating Point problems with Linux on the EST SBC8260

[diekema_jon]

> Date: Wed, 24 May 2000 13:42:56 -0700
> From: Bill Roman <roman@alerton.com>

> diekema_jon wrote:

> > - I am looking for a floating point validation test suite written in
> >   C.  The test suite should start with the fundamentals and work out
> >   from there.

> Try paranoia.c. A web search should turn up multiple copies, I found one at

>     http://www.enseeiht.fr/NetLib/paranoia/index.html

> A while back I had the floating point emulator from kernel 2.3
> patched into kernel 2.2.13 running on an MBX, and it did reasonably
> well on this test as I recall.

paranoia.c was quite helpful in verifying the floating point operation
on the EST SBC8260 board with a MPC8260 Rev A.1.  I statically compiled
this program under Yellow Dog Linux champion server 1.2, and ran it
on the SBC8260.  paranoia.c didn't find anything to complain about. :)


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

Re: Floating Point problems with Linux on the EST SBC8260

[Neil Russell]

On Wed, May 24, 2000 at 03:47:10PM -0400, diekema_jon wrote:
>
> Floating Point problems with Linux on the EST SBC8260:
>
>
> Questions:
>
> - What is the state of floating point support with Linux on the
>   MPC8260?
>
> - Does anybody have hard-float applications running on the MPC8260?
>
> - I am looking for a floating point validation test suite written in
>   C.  The test suite should start with the fundamentals and work out
>   from there.
>
>   Does anybody have any leads?  This is what I have found so far:
>
> 1) TestFloat-2a
>
> Package Overview for TestFloat Release 2a
>
> John R. Hauser
> 1998 December 16
>
>
> TestFloat is a program for testing that a floating-point implementation
> conforms to the IEC/IEEE Standard for Binary Floating-Point Arithmetic.
> TestFloat is distributed in the form of C source code.  The TestFloat
> package actually provides two related programs:
>
> -- The `testfloat' program tests a system's floating-point for conformance
>    to the IEC/IEEE Standard.  This program uses the SoftFloat software
>    floating-point implementation as a basis for comparison.
>
> -- The `testsoftfloat' program tests SoftFloat itself for conformance to
>    the IEC/IEEE Standard.  These tests are performed by comparing against a
>    separate, slower software floating-point that is included in the TestFloat
>    package.
>
> 2) UCBTEST
>
>      UCBTEST is a suite of programs for testing certain difficult cases of
> IEEE 754 floating-point arithmetic.  Some of the difficult test cases are
> obtained from number-theoretic algorithms developed by Turing Award winner
> Prof. W. Kahan, Department of Electrical Engineering and Computer Science,
> University of California, Berkeley, as part of ongoing research into test
> methods for computer arithmetic.
>
>
> Either TestFloat or UCBTEST will require some porting effort to run
> on the PPC.  I would like to work smarter rather than harder. I can't
> even get the rights answers from printf, *, or /.
>
>
> Environment:
>
> Platform: EST SBC8260 w/ MPC8260 Rev A.1 running at 166 Mhz
> Ethernet: 10 Mbs (SCC)
> Linux kernel: 2.3.99-pre9
> root filesystem (NFS mounted): MontaVista Hard Hat Linux version 1.1
> Toolset: Denx Software CDK recompiled with gcc configured for
>          --with-cpu=603e and hard-float (i.e. no --nfp)
>
>
> Application:
>
> Note: The executable was statically linked to pull in the hard-float
>       C runtime libraries.
>
> dell 403} cat z.c
> #include "stdio.h"
>
> double x, y, z;
>
> main ()
>
> {
>   x = 1234.33;
>   printf("x %lf (1234.33) 0x%08lX\n", x , x);
>
>   y = 4444.2;
>   printf("y %lf (4444.2)  0x%08lX\n", y , y);
>
>   z = x * y;
>   printf("z = x * y, %lf %lf %lf\n", x , y, z);
>
>   z = x / y;
>   printf("z = x / y, %lf %lf %lf\n", x , y, z);
> }
>
> dell 404} cat z.s
> 	.file	"z.c"
> gcc2_compiled.:
> 	.section	".rodata"
> 	.align 2
> .LC1:
> 	.string	"x %lf (1234.33) 0x%08lX\n"
> 	.align 2
> .LC3:
> 	.string	"y %lf (4444.2)  0x%08lX\n"
> 	.align 2
> .LC4:
> 	.string	"z = x * y, %lf %lf %lf\n"
> 	.align 2
> .LC5:
> 	.string	"z = x / y, %lf %lf %lf\n"
> 	.align 3
> .LC0:
> 	.long 0x40934951
> 	.long 0xeb851eb8
> 	.align 3
> .LC2:
> 	.long 0x40b15c33
> 	.long 0x33333333
> 	.section	".text"
> 	.align 2
> 	.globl main
> 	.type	 main,@function
> main:
> 	stwu 1,-16(1)
> 	mflr 0
> 	stw 31,12(1)
> 	stw 0,20(1)
> 	mr 31,1
> 	lis 9,x@ha
> 	lis 11,.LC0@ha
> 	lfd 0,.LC0@l(11)
> 	stfd 0,x@l(9)
> 	lis 9,x@ha
> 	lis 11,x@ha
> 	lis 10,.LC1@ha
> 	la 3,.LC1@l(10)
> 	lfd 1,x@l(9)
> 	lfd 2,x@l(11)
> 	creqv 6,6,6
> 	bl printf
> 	lis 9,y@ha
> 	lis 11,.LC2@ha
> 	lfd 0,.LC2@l(11)
> 	stfd 0,y@l(9)
> 	lis 9,y@ha
> 	lis 11,y@ha
> 	lis 10,.LC3@ha
> 	la 3,.LC3@l(10)
> 	lfd 1,y@l(9)
> 	lfd 2,y@l(11)
> 	creqv 6,6,6
> 	bl printf
> 	lis 9,z@ha
> 	lis 11,x@ha
> 	lis 10,y@ha
> 	lfd 0,x@l(11)
> 	lfd 13,y@l(10)
> 	fmul 0,0,13
> 	stfd 0,z@l(9)
> 	lis 9,x@ha
> 	lis 11,y@ha
> 	lis 10,z@ha
> 	lis 8,.LC4@ha
> 	la 3,.LC4@l(8)
> 	lfd 1,x@l(9)
> 	lfd 2,y@l(11)
> 	lfd 3,z@l(10)
> 	creqv 6,6,6
> 	bl printf
> 	lis 9,z@ha
> 	lis 11,x@ha
> 	lis 10,y@ha
> 	lfd 0,x@l(11)
> 	lfd 13,y@l(10)
> 	fdiv 0,0,13
> 	stfd 0,z@l(9)
> 	lis 9,x@ha
> 	lis 11,y@ha
> 	lis 10,z@ha
> 	lis 8,.LC5@ha
> 	la 3,.LC5@l(8)
> 	lfd 1,x@l(9)
> 	lfd 2,y@l(11)
> 	lfd 3,z@l(10)
> 	creqv 6,6,6
> 	bl printf
> .L2:
> 	lwz 11,0(1)
> 	lwz 0,4(11)
> 	mtlr 0
> 	lwz 31,-4(11)
> 	mr 1,11
> 	blr
> .Lfe1:
> 	.size	 main,.Lfe1-main
> 	.comm	x,8,8
> 	.comm	y,8,8
> 	.comm	z,8,8
> 	.ident	"GCC: (GNU) 2.95.2 19991024 (release)"
>
>
> On the target:
>
> > ./a.out
> x nan (1234.33) 0x00000000
> y 0.000000 (4444.2)  0x1003FBCC
> z = x * y, 0.000000 0.000000 0.000000
> z = x / y, 0.000000 0.000000 0.000000
>
>
> The expected results should look something like:
>
> dell 420} ./a.out
> x 1234.330000 (1234.33) 0xEB851EB8
> y 4444.200000 (4444.2)  0x33333333
> z = x * y, 1234.330000 4444.200000 5485609.386000
> z = x / y, 1234.330000 4444.200000 0.277740
>
> We aren't even close to reasonable answers yet.
>

--
Neil Russell <caret@c-side.com>

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

Re: Floating Point problems with Linux on the EST SBC8260

[Neil Russell]

Oops, let's try that again...

I tried this on my board.  I'm running 2.2.14 the SBC8260 and some other
hardware.  I ran the code you posted and it produced exactly the results
that it should have.

The word I have from Motorola is that rev A.1 8260's have a full FPU,
whereas prior version do not.  My experiences confirm this.

Also, I don't cross compile;  I use a G3 MAC running linux.  I wonder if
this makes a difference?


Neil.




On Wed, May 24, 2000 at 03:47:10PM -0400, diekema_jon wrote:
> Floating Point problems with Linux on the EST SBC8260:
>
>
>
>
> The expected results should look something like:
>
> dell 420} ./a.out
> x 1234.330000 (1234.33) 0xEB851EB8
> y 4444.200000 (4444.2)  0x33333333
> z = x * y, 1234.330000 4444.200000 5485609.386000
> z = x / y, 1234.330000 4444.200000 0.277740
>
> We aren't even close to reasonable answers yet.
>

--
Neil Russell <caret@c-side.com>

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

Re: Floating Point problems with Linux on the EST SBC8260

[Dan Malek]

diekema_jon wrote:

> - What is the state of floating point support with Linux on the
>   MPC8260?

Same as any 603 with FPU.


> Platform: EST SBC8260 w/ MPC8260 Rev A.1 running at 166 Mhz
> Ethernet: 10 Mbs (SCC)
> Linux kernel: 2.3.99-pre9
> root filesystem (NFS mounted): MontaVista Hard Hat Linux version 1.1
> Toolset: Denx Software CDK recompiled with gcc configured for
>          --with-cpu=603e and hard-float (i.e. no --nfp)


You can't be mixing stuff like this.  If you would read the documentation
provided with the MontaVista CDK, you would have discovered that you
need to use the tools, libraries, applications, and file systems with
the kit.  Further, you would have discovered the 1.1 CDK is for an 8xx
and the libraries are compiled for soft (in-line) floating point.  You
are mixing floating point instructions with library and compiler support
that assumes otherwise.......The CDK 1.1 is an update to CDK 1.0.  The
documentation is found in the 1.0 directory.


	-- Dan

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

Re: Floating Point problems with Linux on the EST SBC8260

[diekema_jon]

>From Dan Malek:

> Further, you would have discovered the 1.1 CDK is for an 8xx and the
> libraries are compiled for soft (in-line) floating point.  You are
> mixing floating point instructions with library and compiler support
> that assumes otherwise.

My application was statically linked against the Denx CDK that was
compiled for hard float.  The static application already has all the
libraries routines that it needs, hence it won't pull in the Hard Hat
Linux 1.1 libraries (soft float) from the root filesystem.


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