Using FPU with uCLinux

[Altera_Forum]

Hello folks, 

i'am just trying to use the floating-point-unit within my uCLinux dist. I have added the corresponding custom instruction to the cpu within my sopc-builder system. After that i configured the kernel to use the fpu (CONFIG_NIOS2_FPU_SUPPORT). But when i issue cat /proc/cpuinfo it comes up with the following informations saying that there is no fpu present:   CPU: Nios II/fast MMU: present FPU: none Clocking: 107.05 MHz BogoMips: 52.73 Calibration: 26368000 loops HW:  MUL: yes  MULX: no  DIV: yes Icache: 32kB, line length: 32 Dcache: 16kB, line length: 32 TLB: 16 ways, 256 entries  Any ideas?

[Altera_Forum]

I found out, that the printout of cat /proc/cpuinfo is alway "none" for the FPU entry! See nios2-linux/linux-2.6/arch/nios2/kernel/cpuinfo.c: 

count = seq_printf(m, "CPU:\t\tNios II/%s\n" "MMU:\t\t%s\n" "FPU:\t\tnone\n" "Clocking:\t%u.%02u MHz\n" "BogoMips:\t%lu.%02lu\n" "Calibration:\t%lu loops\n", cpuinfo.cpu_impl, cpuinfo.mmu ? "present" : "none", clockfreq / 1000000, (clockfreq / 100000) % 10, (loops_per_jiffy * HZ) / 500000, ((loops_per_jiffy * HZ) / 5000) % 100, (loops_per_jiffy * HZ));    Does this mean, that FPU isn't supported on the nios2-processor when using uCLinux?

[Altera_Forum]

No, as you can see, it's just that that printout is hardcoded. 

 The config option controls a compiler flag. The kernel doesn't really know whether there is an FPU. You'll also need to add the compiler flag to your applications.  See: http://www.alterawiki.com/wiki/single-precision_-mcustom-*_options http://www.alterawiki.com/wiki/custom_instructions  Also, the option is there for the kernel just in case, but the kernel doesn't really use any floating point. You can build the kernel without that option and still use the custom instructions in your applications.

[Altera_Forum]

Is there any purpose the Kernel should use floating point instructions for?  

 If no, it does not make sense for the Kernel to detect whether there is hardware support (other than with /proc/cpuinfo .   -Michael

[Altera_Forum]

Thank you for your replys. 

I have an application, where i need to implement some floating-point operations. I have just started with uCLinux dist. I only got a little bit confused, because MUL and DIV hardware is recognized and also displayed by the cpuinfo but FPU not. So i will try to compile some benchmark applications with and without FPU to figure out the performance impact....   By the way: How do you compile your User-Space application? I would like to do this via Eclipse...Any experience about this? How can i place simple files (eg. sh-scripts) into the initial file-system?

[Altera_Forum]

You can add you application to the device tree:  

http://www.alterawiki.com/wiki/create_your_own_product http://www.alterawiki.com/wiki/compilehello  Debugging: http://www.alterawiki.com/wiki/debugapps http://www.alterawiki.com/wiki/eclipsecdt  Init file system / remote comnfiguration:  http://www.alterawiki.com/wiki/haserl  More interesting stuff:  http://www.alterawiki.com/wiki/linux_for_the_nios_ii_processor http://www.alterawiki.com/wiki/uclinux  -Michael

[Altera_Forum]

Thank you so much! 

These links are realy interesting. I managed to get a simple programm (something like Hello World) to be compiled directly from the eclipse workspace. But when is try to execute this programm on uClinux it says: sh: can't execute 'bFLT  nios2-terminal: exiting due to ^D on remote   Strange.... I follwed the steps descripted in "Compile without edding to uClinux-dist"  in http://www.alterawiki.com/wiki/compilehello (http://www.alterawiki.com/wiki/compilehello)

[Altera_Forum]

The error from 'sh' is typical when you try to execute a binary file that isn't the correct format for the kernel. 

When the kernel refuses the 'exec' the binary, the shell will try to process it as a script.  Probably meany that you haven't generated a Linux binary.

[Altera_Forum]

OK that makes sense, 

but what is missing within or wrong within the build flow? I use "nios2-linux-uclibc-gcc" within eclipse. And changed the command under "Cross GCC Compiler" and "Cross GCC Linker".

[Altera_Forum]

Might be something in the linker script. 

Compare the elf headers (objdump -p and objdump -h) between your program and something that works looking for anything different. Not sure what linux uses to decide that an ELF binary is valid - could depend on the contents of some .NOTE sections.

[Altera_Forum]

--- Quote Start ---   I managed to get a simple programm (something like Hello World) to be compiled directly from the eclipse workspace.  --- Quote End ---    That would be only possible if you manage to make Eclipse use a make file, linker script etc., that is done according to the rules the NIOS-Linux build system enforce. See the make files for user land programs generated by enabling them in "make menuconfig" within the build system.  I suggest to first create a hello world example by doing a new directory under "vendors" (as suggsted in one of the links) and adding same to the main build script. This is the correct way to do your own userspace programs (and drivers). Then you might try to make Eclipse use the appropriate scrips to compile (and debug) your C code.  -Michael

[Altera_Forum]

You might be right, that adding own programms to the uCLinux dist is the "correct way". But i want the uCLinux-dist to boot from an EPCS, then mount another device e.g. cfi-flash wich contains my user-space programms and some kernel-moduls and start everything using some scripts. --> Isn't it a good idea?

[Altera_Forum]

I do suppose this is possible and in fact might be a good idea.  

 But I would first do a "hello world" example in the "normally correct" way to learn how the make file and the linker script need to be constructed. This done, you can decide how to proceed to place the file on an external media instead of inside the distribution.   When doing my own application I in fact used a symlink for the "correct" directory under "Vendors" so that "physically" my files were outside of the distribution make tree, anyway.   In fact I would only slightly modify the "correct" makefile so that the executable after being linked is not included in (moved to ?, symlinked to ? I don't remember... ) the directory that is zipped to be the root file system that is included in or comes with the Kernel Image.   -Michael