RTEMS - SPARC ut700 fp disabled exception upon RTEMS startup
Daniel Hellstrom
daniel at gaisler.com
Mon Oct 24 13:40:36 UTC 2016
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.hellstrom at 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 <jiri at gaisler.se
>> <mailto:jiri at 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 support at gaisler.com
>>> <mailto:support at 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 at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20161024/e57855cf/attachment-0002.html>
More information about the devel
mailing list