Hi Steve,
Is the float context enabled with networkDaemon task (see
rtems_task_create RTEMS_FLOATING_POINT parameter)? See
rtems_bsdnet_newproc() creating net tasks. The sprintf()/sprintf_r are
probably using floating point variables even that no floats are in the
end printed. When double/float is initialized to 0.0 for example it may
use FPU. Please see newlib/libc/stdio/vfprintf.c for details, maybe the
optimizations done has effects in these cases.
Basically rtems_bsdnet_newproc() should enable floating point context if
newlib functions that are using FPU is called. One alternative could be
to enable FPU context always on net tasks (or only when SOFT_FLOAT is
not used), another to make sure to call functions not using floats.
Best Regards,
Daniel Hellstrom
Software Section Head
Cobham Gaisler
T : +46 (0) 31 775 8657
F : +46 (0) 31 421407
daniel.hellst...@gaisler.com
Cobham Gaisler AB, Kungsgatan 12, SE-411 19, GÖTEBORG, Sweden.
+46 (0) 31 775 8650, www.cobham.com/gaisler
Please consider the environment before printing this email
This e-mail and any files transmitted with it ("E-mail") is intended solely for
the addressee(s) and may contain confidential and/or legally privileged information. If
you are not the addressee(s), any disclosure,
reproduction, copying, distribution or other use of the E-mail is prohibited.
If you have received this E-mail in error, please delete it and notify the
sender immediately via our switchboard or return e-mail.
Neither the company nor any subsidiary or affiliate or associated company nor
any individual sending this Email accepts any liability in respect of the
content (including errors and omissions) nor shall this e-mail be deemed to
enter the company or any subsidiary or affiliate or associated company into a
contract or to create any legally binding obligations unless expressly agreed
to in writing under separate cover and timeliness of the E-mail which arise as
a result of transmission. If verification is required, please request a hard
copy version from the sender.
On 2016-10-23 21:27, Duran, Steve (JSC-ER611) wrote:
I would prefer not to compile with soft float as the processors that
we are using have hardware FPUs. Is there a recommended rtems and
rtems source builder branch rev that should be used?
I am running CentOS
CentOS Linux release 7.2.1511 (Core)
Linux spartan117 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
It has gcc:
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
But, if I understand the RTEMS builder correctly, it downloads a
version of tools and libs to build itself. It looks like it used gcc
4.9.3.
$ sparc-rtems4.11-gcc -v
Using built-in specs.
COLLECT_GCC=sparc-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/gfe/RTEMS/development/rtems/4.11/libexec/gcc/sparc-rtems4.11/4.9.3/lto-wrapper
Target: sparc-rtems4.11
Configured with: ../gcc-4.9.3/configure
--prefix=/gfe/RTEMS/development/rtems/4.11
--bindir=/gfe/RTEMS/development/rtems/4.11/bin
--exec_prefix=/gfe/RTEMS/development/rtems/4.11
--includedir=/gfe/RTEMS/development/rtems/4.11/include
--libdir=/gfe/RTEMS/development/rtems/4.11/lib
--libexecdir=/gfe/RTEMS/development/rtems/4.11/libexec
--mandir=/gfe/RTEMS/development/rtems/4.11/share/man
--infodir=/gfe/RTEMS/development/rtems/4.11/share/info
--datadir=/gfe/RTEMS/development/rtems/4.11/share
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=sparc-rtems4.11 --disable-libstdcxx-pch --with-gnu-as
--with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-libgomp
--enable-languages=c,c++
Thread model: rtems
gcc version 4.9.3 20150626 (RTEMS 4.11, RSB
1675a733536d1aec2020011e5e522497a442561a, Newlib 2.2.0.20150423) (GCC)
On Oct 22, 2016, at 9:48 AM, Jiri Gaisler <j...@gaisler.se
<mailto:j...@gaisler.se>> wrote:
It seems that you have compiled RTEMS with a gcc version that can use
%fpu registers to move integer data. The work-around could be to
compile the kernel with -msoft-float, or to move to a (later) version
of gcc that does not do this anymore. Which gcc version do you use?
Jiri.
On 22/10/16 01:22, Duran, Steve (JSC-ER611) wrote:
I am trying to get and RTEMS kernel to boot on the SPARC ut700
development board. There appears to be an issue in the RTEMS
networking code that must use floating point, but for some reason
the FPU has been disabled.
Details below. Any insights into how to resolve this issue would be
appreciated.
Development environment setup on:
Setup on:
CentOS Linux release 7.2.1511 (Core)
Linux spartan117 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23
17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ git clone git://git.rtems.org/rtems.git
<git://git.rtems.org/rtems.git> rtems
$ git checkout -b rtems411 origin/4.11
Loading through grmon2, starting to run, error messages, and some
debug info:
GRMON2 LEON debug monitor v2.0.74 32-bit pro version
Copyright (C) 2016 Cobham Gaisler - All rights reserved.
For latest updates, go to http://www.gaisler.com/
<http://www.gaisler.com/>
Comments or bug-reports to supp...@gaisler.com
<mailto:supp...@gaisler.com>
using port /dev/ttyUSB4 @ 460800 baud
Device ID: 0x699
GRLIB build version: 4110
Detected system: UT699E/UT700
Detected frequency: 125 MHz
Component Vendor
LEON3-FT SPARC V8 Processor Cobham Gaisler
AHB Debug UART Cobham Gaisler
JTAG Debug Link Cobham Gaisler
Fast 32-bit PCI Bridge Cobham Gaisler
PCI/AHB DMA controller Cobham Gaisler
GR Ethernet MAC Cobham Gaisler
GRSPW2 SpaceWire Serial Link Cobham Gaisler
GRSPW2 SpaceWire Serial Link Cobham Gaisler
GRSPW2 SpaceWire Serial Link Cobham Gaisler
GRSPW2 SpaceWire Serial Link Cobham Gaisler
MIL-STD-1553B Interface Cobham Gaisler
Memory controller with EDAC Cobham Gaisler
AHB/APB Bridge Cobham Gaisler
LEON3 Debug Support Unit Cobham Gaisler
AHB/APB Bridge Cobham Gaisler
OC CAN AHB interface Cobham Gaisler
Generic UART Cobham Gaisler
Multi-processor Interrupt Ctrl. Cobham Gaisler
Modular Timer Unit Cobham Gaisler
Clock gating unit Cobham Gaisler
PCI Arbiter European Space Agency
General Purpose I/O port Cobham Gaisler
AHB Status Register Cobham Gaisler
SPI Controller Cobham Gaisler
General Purpose Register Cobham Gaisler
Use command 'info sys' to print a detailed report of attached cores
40085000 .eefs_ram 512.0kB / 512.0kB
[===============>] 100%
40000000 .tarfs_ram 530.0kB / 530.0kB
[===============>] 100%
40405000 .text 815.8kB / 815.8kB
[===============>] 100%
404D0F20 .rtemsroset 304B [===============>]
100%
404D1050 .data 13.3kB / 13.3kB
[===============>] 100%
404D4560 .jcr 4B [===============>]
100%
Total size: 1.83MB (362.50kbit/s)
Entry point 0x40405000
Image
/home/sduran/sparc_leon3/SPARC_LEON3_Workspace/ut700/rtems4.11-kernel/rki.elf
loaded
RTEMS Kernel Image Booting
*** RTEMS Info ***
COPYRIGHT (c) 1989-2008.
On-Line Applications Research Corporation (OAR).
rtems-4.10.99.0(SPARC/w/FPU/leon3)
BSP Ticks Per Second = 100
*** End RTEMS info ***
Populating Root file system from TAR file.
Starting RTEMS network configuration
RTEMS network config: All structures filled out, now calling init
functions
Convert ethernet address
Converting: 00:00:7a:cc:00:16
Calling rtems_bsdnet_initialize_network
greth: driver attached
**** PHY ****
Vendor: 80017 Device: 9 Revision: 0
Current Operating Mode: 100 Mbit Full Duplex
Autonegotiation Time: 1739ms
RTEMS bsdnet_initialize_network returned OK
Hostname is gfe02.local
Device gr_eth1, netmask 255.255.255.0, address 139.169.132.128
gateway 139.169.132.1, dns1 139.169.132.1, dns2 (null)
Starting the FTP Server.
syslog: ftpd: FTP daemon started (1 session max)
Setting up filesystems.
Initializing Local Commands.
Running /shell-init.
1: mkdir ram0
2: mkdir ram
3: mkrfs /dev/rd0
4: mount -t rfs /dev/rd0 /ram0
mounted /dev/rd0 -> /ram0
5: hello
Hello RTEMS!
Create your own command here!
Starting shell....
RTEMS Shell on /dev/console. Use 'help' to list commands.
[/] # Unexpected trap (0x04) at address 0x404A6764
fp disabled
Program exited normally.
From UT700_LEON_Functional_Manual.pdf
Trap table on page 18:
TRAP TT PRI Description
fp_disabled 0x04 6 FP instruction while FPU disabled
grmon2> dis 0x404A6764
0x404a6764: d11861b0 ldd [%g1 + 0x1B0], %f8
<_svfprintf_r+100>
0x404a6768: a410a250 or %g2, 0x250, %l2
<_svfprintf_r+104>
0x404a676c: 39101341 sethi %hi(0x404D0400), %i4
<_svfprintf_r+108>
grmon2> bt
Inside trap/irq
%pc %sp
#0 0x40417e40 0x404e6158 <syscall+0>
#1 0x404ba880 0x404e61b8 <_CPU_Fatal_halt+0x8>
#2 0x40442d68 0x404e6218 <_Terminate+0x48>
#3 0x40441720 0x404e6288 <rtems_fatal+0xc>
#4 0x40416044 0x404e62e8 <bsp_spurious_handler+0xc>
#5 0x404bae24 0x404e6350
#6 0x404a6710 0x40528180 <_svfprintf_r+0x10>
#7 0x404a20b4 0x40528428 <sprintf+0x50>
#8 0x4046eb68 0x40528500 <inet_ntop4+0x1c>
#9 0x4046ee90 0x40528570 <inet_ntop+0x2e8>
#10 0x4046eb3c 0x40528628 <inet_ntoa+0x54>
#11 0x40474a90 0x40528690 <arplookup+0xb8>
#12 0x404754c0 0x405286f8 <arpintr+0x1d4>
#13 0x40434048 0x40528788 <networkDaemon+0xa8>
#14 0x40433db4 0x405287f0 <taskEntry+0x1c>
#15 0x40499058 0x40528850 <_Thread_Handler+0xb8>
#16 0x40498fa0 0x405288b0 <_Thread_Handler+0>
So it would appear that RTEMS is in networking code, calling
sprintf, trying to perform a floating point operation but for some
reason the FPU has been disabled.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
