date:20160822

RE: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

2016-08-22 Thread Kirspel, Kevin

I used -O2.  Is there some standard floating point test that would be a better 
gauge?

Kevin Kirspel
Electrical Engineer - Sr. Staff
Opti Medical
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Sent: Monday, August 22, 2016 1:41 AM
To: Kirspel, Kevin ; devel@rtems.org
Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

On 19/08/16 17:18, Kirspel, Kevin wrote:
> I built GCC with the hard abi.  The software ran fine but I see a performance 
> hit with the hard abi.
>
> ABI:  Test Execution Time (ms)
> soft  1358
> softfp96
> hard  109
>
> I don't know why the hard is slower than the softfp.  Here was my test code.

Which compiler options did you use for this test? I am pretty sure that the 
compiler will reduce your test code to constants with -O2, since you only use 
constant expressions.

>
>  int ii;
>  uint32_t end_time, start_time;
>  double dvalue[8], dresult[20];
>  
>  start_time = rtems_clock_get_ticks_since_boot();
>  for( ii = 0; ii < 20; ii++ )
>  {
>dresult[ii] = 0.0;
>  }
>  dvalue[0] = 12.12;
>  dvalue[1] = 23.23;
>  dvalue[2] = 34.34;
>  dvalue[3] = 45.45;
>  dvalue[4] = 56.56;
>  dvalue[5] = 67.67;
>  dvalue[6] = 78.78;
>  dvalue[7] = 89.89;
>  for( ii = 0; ii < 1; ii++ )
>  {
>dresult[0] += (( dvalue[0] * dvalue[0] ) + ( dvalue[1] * dvalue[1] 
> ) + ( dvalue[2] * dvalue[2] ) + ( dvalue[3] * dvalue[3] ) +
>  ( dvalue[4] * dvalue[4] ) + ( dvalue[5] * dvalue[5] ) + ( 
> dvalue[6] * dvalue[6] ) + ( dvalue[7] * dvalue[7] )) /
>  (( dvalue[0] / dvalue[1] ) - ( dvalue[1] / dvalue[2] ) - ( 
> dvalue[2] / dvalue[3] ) - ( dvalue[3] / dvalue[4] ) -
>  ( dvalue[4] / dvalue[5] ) - ( dvalue[5] / dvalue[6] ) - ( 
> dvalue[6] / dvalue[7] ));
>dresult[1] += cos( dvalue[0] * PI / 180.0 );
>dresult[2] += sin( dvalue[1] * PI / 180.0 );
>dresult[3] += tan( dvalue[2] * PI / 180.0 );
>dresult[4] += acos( 1 / dvalue[3] ) * 180.0 / PI;
>dresult[5] += asin( 1 / dvalue[4] ) * 180.0 / PI;
>dresult[6] += atan( dvalue[5] ) * 180.0 / PI;
>dresult[7] += atan2( dvalue[6], dvalue[7] ) * 180.0 / PI;
>dresult[8] += cosh( 1 / dvalue[7] );
>dresult[9] += sinh( dvalue[0] );
>dresult[10] += tanh( dvalue[1] );
>dresult[11] += acosh( dvalue[2] );
>dresult[12] += asinh( dvalue[3] );
>dresult[13] += atanh( 1 / dvalue[4] );
>dresult[14] += exp(   1 / dvalue[5] );
>dresult[15] += pow( dvalue[6], 1 / dvalue[7] );
>dresult[16] += sqrt( dvalue[7] );
>dresult[17] += log( dvalue[0] );
>dresult[18] += log10( dvalue[1] );
>dresult[19] += log2( dvalue[2] );
>  }
>  end_time = rtems_clock_get_ticks_since_boot();
>  for( ii = 0; ii < 20; ii++ )
>  {
>printf( "dresult[%d] = %f\n", ii, dresult[ii] );
>  }
>  printf( "VFP Execution Time: %lu\n", end_time - start_time );
>
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Opti Medical
> 235 Hembree Park Drive
> Roswell GA 30076
> Tel: (770)-510- ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
>
> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: Friday, August 19, 2016 8:56 AM
> To: Kirspel, Kevin ; devel@rtems.org
> Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support
>
> On 19/08/16 14:39, Kirspel, Kevin wrote:
>> This goes back 5 or more years ago so my recollection might be off but I had 
>> issues with GCC 4.5.2 using -mfloat-abi=hard.  NXP recommends 
>> -mfloat-abi=softfp.  I can't find the article or forum now but I think it 
>> had to do with the fact that the LPC3250 VFP didn't support all the required 
>> instructions for -mfloat-abi=hard (something about needing a Undefined 
>> Instruction exception handler to process unsupported VFP instructions).  
>> Using -mfloat-abi=softfp eliminates the need for the Undefined Instruction 
>> exception handler to handle unsupported VFP instructions.
> The used VFP instructions should not depend on hard vs. softfp ABI since this 
> should only affect the calling conventions. In addition we use now GCC 6. 
> Could you please test with -mfloat-abi=hard. This is what all the other VFP 
> multilibs use.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist ke

Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

2016-08-22 Thread Sebastian Huber




On 22/08/16 13:23, Kirspel, Kevin wrote:

I used -O2.


Did you look at the generated code? I guess you find no calls to the 
standard math library functions. Which timing numbers do you get if you 
use "-O2 -fno-builtin" instead?



Is there some standard floating point test that would be a better gauge?

Kevin Kirspel
Electrical Engineer - Sr. Staff
Opti Medical
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
Sent: Monday, August 22, 2016 1:41 AM
To: Kirspel, Kevin ; devel@rtems.org
Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

On 19/08/16 17:18, Kirspel, Kevin wrote:

I built GCC with the hard abi.  The software ran fine but I see a performance 
hit with the hard abi.

ABI:Test Execution Time (ms)
soft1358
softfp  96
hard109

I don't know why the hard is slower than the softfp.  Here was my test code.

Which compiler options did you use for this test? I am pretty sure that the 
compiler will reduce your test code to constants with -O2, since you only use 
constant expressions.


  int ii;
  uint32_t end_time, start_time;
  double dvalue[8], dresult[20];
  
  start_time = rtems_clock_get_ticks_since_boot();

  for( ii = 0; ii < 20; ii++ )
  {
dresult[ii] = 0.0;
  }
  dvalue[0] = 12.12;
  dvalue[1] = 23.23;
  dvalue[2] = 34.34;
  dvalue[3] = 45.45;
  dvalue[4] = 56.56;
  dvalue[5] = 67.67;
  dvalue[6] = 78.78;
  dvalue[7] = 89.89;
  for( ii = 0; ii < 1; ii++ )
  {
dresult[0] += (( dvalue[0] * dvalue[0] ) + ( dvalue[1] * dvalue[1] 
) + ( dvalue[2] * dvalue[2] ) + ( dvalue[3] * dvalue[3] ) +
  ( dvalue[4] * dvalue[4] ) + ( dvalue[5] * dvalue[5] ) + ( 
dvalue[6] * dvalue[6] ) + ( dvalue[7] * dvalue[7] )) /
  (( dvalue[0] / dvalue[1] ) - ( dvalue[1] / dvalue[2] ) - ( 
dvalue[2] / dvalue[3] ) - ( dvalue[3] / dvalue[4] ) -
  ( dvalue[4] / dvalue[5] ) - ( dvalue[5] / dvalue[6] ) - ( 
dvalue[6] / dvalue[7] ));
dresult[1] += cos( dvalue[0] * PI / 180.0 );
dresult[2] += sin( dvalue[1] * PI / 180.0 );
dresult[3] += tan( dvalue[2] * PI / 180.0 );
dresult[4] += acos( 1 / dvalue[3] ) * 180.0 / PI;
dresult[5] += asin( 1 / dvalue[4] ) * 180.0 / PI;
dresult[6] += atan( dvalue[5] ) * 180.0 / PI;
dresult[7] += atan2( dvalue[6], dvalue[7] ) * 180.0 / PI;
dresult[8] += cosh( 1 / dvalue[7] );
dresult[9] += sinh( dvalue[0] );
dresult[10] += tanh( dvalue[1] );
dresult[11] += acosh( dvalue[2] );
dresult[12] += asinh( dvalue[3] );
dresult[13] += atanh( 1 / dvalue[4] );
dresult[14] += exp(   1 / dvalue[5] );
dresult[15] += pow( dvalue[6], 1 / dvalue[7] );
dresult[16] += sqrt( dvalue[7] );
dresult[17] += log( dvalue[0] );
dresult[18] += log10( dvalue[1] );
dresult[19] += log2( dvalue[2] );
  }
  end_time = rtems_clock_get_ticks_since_boot();
  for( ii = 0; ii < 20; ii++ )
  {
printf( "dresult[%d] = %f\n", ii, dresult[ii] );
  }
  printf( "VFP Execution Time: %lu\n", end_time - start_time );

Kevin Kirspel
Electrical Engineer - Sr. Staff
Opti Medical
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
Sent: Friday, August 19, 2016 8:56 AM
To: Kirspel, Kevin ; devel@rtems.org
Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

On 19/08/16 14:39, Kirspel, Kevin wrote:

This goes back 5 or more years ago so my recollection might be off but I had 
issues with GCC 4.5.2 using -mfloat-abi=hard.  NXP recommends 
-mfloat-abi=softfp.  I can't find the article or forum now but I think it had 
to do with the fact that the LPC3250 VFP didn't support all the required 
instructions for -mfloat-abi=hard (something about needing a Undefined 
Instruction exception handler to process unsupported VFP instructions).  Using 
-mfloat-abi=softfp eliminates the need for the Undefined Instruction exception 
handler to handle unsupported VFP instructions.

The used VFP instructions should not depend on hard vs. softfp ABI since this 
should only affect the calling conventions. In addition we use now GCC 6. Could 
you please test with -mfloat-abi=hard. This is what all the other VFP multilibs 
use.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains

Re: [PATCH v2 1/6] Imported files for driver: bcm283x_dwcotg

2016-08-22 Thread Deval Shah

On Mon, Aug 22, 2016 at 11:25 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Sorry, for being so pedantic, but it will be probably me who updates the
> libbsd with about 800 files to next FreeBSD versions. Please go through
> your complete patch series again and fix all places that don't follow the
> guidelines and my mail comments. It looks better now, but there are still
> some spots left.
>

I totally understand. I would work on the patches till they become perfect
and mergable to the master. Its just that I could not find the mistakes.
Maybe I am still getting trained for finding them. You can always point
that out to me and I would definately correct them. At the end pushing the
clean, understandable and usable code is my goal, too.

> If you think the guidelines could be more clear, need an explanation or
> examples, then we should address this first.

I could use some examples on the last rule " Do not disable option header
includes via guards.  Instead, add an empty option header, e.g.
`rtemsbsd/include/rtems/bsd/local/opt_xyz.h`.  In general, provide empty
header files and do not guard includes. "

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>

-- 
Deval Shah
Graduate Student,
B.E. (Hons.) Electrical and Electronics Engineering
BITS Pilani Hyderabad Campus 

Github Profile 
ᐧ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

2016-08-22 Thread Kirspel, Kevin

Here is the updated metrics with -fno-builtin.  You are right in the sense that 
the generated code did not call the underlying math functions.  I will generate 
a patch for the hard implementation.

softp - 4493 ms
hard - 4263 ms

Kevin Kirspel
Electrical Engineer - Sr. Staff
Opti Medical
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Sent: Monday, August 22, 2016 7:34 AM
To: Kirspel, Kevin ; devel@rtems.org
Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support



On 22/08/16 13:23, Kirspel, Kevin wrote:
> I used -O2.

Did you look at the generated code? I guess you find no calls to the standard 
math library functions. Which timing numbers do you get if you use "-O2 
-fno-builtin" instead?

> Is there some standard floating point test that would be a better gauge?
>
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Opti Medical
> 235 Hembree Park Drive
> Roswell GA 30076
> Tel: (770)-510- ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
>
> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: Monday, August 22, 2016 1:41 AM
> To: Kirspel, Kevin ; devel@rtems.org
> Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP 
> support
>
> On 19/08/16 17:18, Kirspel, Kevin wrote:
>> I built GCC with the hard abi.  The software ran fine but I see a 
>> performance hit with the hard abi.
>>
>> ABI: Test Execution Time (ms)
>> soft 1358
>> softfp   96
>> hard 109
>>
>> I don't know why the hard is slower than the softfp.  Here was my test code.
> Which compiler options did you use for this test? I am pretty sure that the 
> compiler will reduce your test code to constants with -O2, since you only use 
> constant expressions.
>
>>   int ii;
>>   uint32_t end_time, start_time;
>>   double dvalue[8], dresult[20];
>>   
>>   start_time = rtems_clock_get_ticks_since_boot();
>>   for( ii = 0; ii < 20; ii++ )
>>   {
>> dresult[ii] = 0.0;
>>   }
>>   dvalue[0] = 12.12;
>>   dvalue[1] = 23.23;
>>   dvalue[2] = 34.34;
>>   dvalue[3] = 45.45;
>>   dvalue[4] = 56.56;
>>   dvalue[5] = 67.67;
>>   dvalue[6] = 78.78;
>>   dvalue[7] = 89.89;
>>   for( ii = 0; ii < 1; ii++ )
>>   {
>> dresult[0] += (( dvalue[0] * dvalue[0] ) + ( dvalue[1] * 
>> dvalue[1] ) + ( dvalue[2] * dvalue[2] ) + ( dvalue[3] * dvalue[3] ) +
>>   ( dvalue[4] * dvalue[4] ) + ( dvalue[5] * dvalue[5] ) + ( 
>> dvalue[6] * dvalue[6] ) + ( dvalue[7] * dvalue[7] )) /
>>   (( dvalue[0] / dvalue[1] ) - ( dvalue[1] / dvalue[2] ) - ( 
>> dvalue[2] / dvalue[3] ) - ( dvalue[3] / dvalue[4] ) -
>>   ( dvalue[4] / dvalue[5] ) - ( dvalue[5] / dvalue[6] ) - ( 
>> dvalue[6] / dvalue[7] ));
>> dresult[1] += cos( dvalue[0] * PI / 180.0 );
>> dresult[2] += sin( dvalue[1] * PI / 180.0 );
>> dresult[3] += tan( dvalue[2] * PI / 180.0 );
>> dresult[4] += acos( 1 / dvalue[3] ) * 180.0 / PI;
>> dresult[5] += asin( 1 / dvalue[4] ) * 180.0 / PI;
>> dresult[6] += atan( dvalue[5] ) * 180.0 / PI;
>> dresult[7] += atan2( dvalue[6], dvalue[7] ) * 180.0 / PI;
>> dresult[8] += cosh( 1 / dvalue[7] );
>> dresult[9] += sinh( dvalue[0] );
>> dresult[10] += tanh( dvalue[1] );
>> dresult[11] += acosh( dvalue[2] );
>> dresult[12] += asinh( dvalue[3] );
>> dresult[13] += atanh( 1 / dvalue[4] );
>> dresult[14] += exp(   1 / dvalue[5] );
>> dresult[15] += pow( dvalue[6], 1 / dvalue[7] );
>> dresult[16] += sqrt( dvalue[7] );
>> dresult[17] += log( dvalue[0] );
>> dresult[18] += log10( dvalue[1] );
>> dresult[19] += log2( dvalue[2] );
>>   }
>>   end_time = rtems_clock_get_ticks_since_boot();
>>   for( ii = 0; ii < 20; ii++ )
>>   {
>> printf( "dresult[%d] = %f\n", ii, dresult[ii] );
>>   }
>>   printf( "VFP Execution Time: %lu\n", end_time - start_time 
>> );
>>
>> Kevin Kirspel
>> Electrical Engineer - Sr. Staff
>> Opti Medical
>> 235 Hembree Park Drive
>> Roswell GA 30076
>> Tel: (770)-510- ext. 81642
>> Direct: (770)-688-1642
>> Fax: (770)-510-4445
>>
>> -Original Message-
>> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
>> Sent: Friday, August 19, 2016 8:56 AM
>> To: Kirspel, Kevin ; devel@rtems.org
>> Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP 
>> support
>>
>> On 19/08/16 14:39, Kirspel, Kevin wrote:
>>> This goes back 5 or more years ago so my recollection might be off but I 
>>> had issue

[PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

2016-08-22 Thread Kirspel, Kevin

diff --git 
a/rtems/config/tools/rtems-gcc-6-20160609-newlib-2.4.0.20160527-1.cfg 
b/rtems/config/tools/rtems-gcc-6-20160609-newlib-2.4.0.20160527-1.cfg
old mode 100644
new mode 100755
index 66c83b9..8639083
--- a/rtems/config/tools/rtems-gcc-6-20160609-newlib-2.4.0.20160527-1.cfg
+++ b/rtems/config/tools/rtems-gcc-6-20160609-newlib-2.4.0.20160527-1.cfg
@@ -7,12 +7,14 @@
%define mpc_version0.8.1
%define gmp_version4.3.2
+%patch add gcc file://gcc-6.1.1-arm-eabi-multilib-20160816.diff
 %hash sha512 gcc-6-20160609.tar.bz2 
f9ea9034c0456d350e418a7263cdd02596fdd553f40e9741907436f0df7dbbc5b025ea421c2aece2769ade8e356985c104a37fe6c1bdc51eb61d52257206e0f1
%hash sha512 newlib-2.4.0.20160527.tar.gz 
09d0c8ac2a657e910eebfeeb7e5fcc6956591223fe499ed4717b5e719287148fc35e80835821fb5b6b586e371100737a7765a03c43f0c194cf67892484132d3f
%hash sha512 mpfr-2.4.2.tar.bz2 
c004b3dbf86c04960e4a1f8db37a409a7cc4cb76135e76e98dcc5ad93aaa8deb62334ee13ff84447a7c12a5e8cb57f25c62ac908c24920f1fb1a38d79d4a4c5e
%hash sha512 mpc-0.8.1.tar.gz 
14cb9ae3d33caed24d5ae648eed28b2e00ad047a8baeff25981129af88245b4def2948573d7a00d65c5bd34e53524aa6a7351b76703c9f888b41830c1a1daae2
%hash sha512 gmp-4.3.2.tar.bz2 
2e0b0fd23e6f10742a5517981e5171c6e88b0a93c83da701b296f5c0861d72c19782daab589a7eac3f9032152a0fc7eff7f5362db8fccc4859564a9aa82329cf
+%hash sha512 gcc-6.1.1-arm-eabi-multilib-20160816.diff 
ef46fcb1e4e7770cb4e6310d2f8649da7387e2979123add5801e54ac62f33d5fa2d1f87f3f44af73322296ebec138d52ad08c4f26245d04dbfa259a42af03ef6
 %define with_threads 1
%define with_plugin  0
diff --git a/source-builder/patches/gcc-6.1.1-arm-eabi-multilib-20160816.diff 
b/source-builder/patches/gcc-6.1.1-arm-eabi-multilib-20160816.diff
index e69de29..b062130 100755
--- a/source-builder/patches/gcc-6.1.1-arm-eabi-multilib-20160816.diff
+++ b/source-builder/patches/gcc-6.1.1-arm-eabi-multilib-20160816.diff
@@ -0,0 +1,18 @@
+diff -ruN gcc-6-20160609.orig/gcc/config/arm/t-rtems 
gcc-6-20160609/gcc/config/arm/t-rtems
+--- gcc-6-20160609.orig/gcc/config/arm/t-rtems  2016-01-15 
03:29:12.0 -0800
 gcc-6-20160609/gcc/config/arm/t-rtems2016-08-19 06:48:02.500993983 
-0700
+@@ -1,7 +1,7 @@
+ # Custom RTEMS multilibs for ARM
+
+-MULTILIB_OPTIONS  = mbig-endian mthumb 
march=armv6-m/march=armv7-a/march=armv7-r/march=armv7-m/mcpu=cortex-m7 
mfpu=neon/mfpu=vfpv3-d16/mfpu=fpv4-sp-d16/mfpu=fpv5-d16 mfloat-abi=hard
+-MULTILIB_DIRNAMES = eb thumb armv6-m armv7-a armv7-r armv7-m cortex-m7 neon 
vfpv3-d16 fpv4-sp-d16 fpv5-d16 hard
++MULTILIB_OPTIONS  = mbig-endian mthumb 
march=armv6-m/march=armv7-a/march=armv7-r/march=armv7-m/mcpu=cortex-m7 
mfpu=neon/mfpu=vfp/mfpu=vfpv3-d16/mfpu=fpv4-sp-d16/mfpu=fpv5-d16 mfloat-abi=hard
++MULTILIB_DIRNAMES = eb thumb armv6-m armv7-a armv7-r armv7-m cortex-m7 neon 
vfp vfpv3-d16 fpv4-sp-d16 fpv5-d16 hard
+
+ # Enumeration of multilibs
+
+@@ -19,3 +19,4 @@
+ MULTILIB_REQUIRED += mthumb/mcpu=cortex-m7/mfpu=fpv5-d16/mfloat-abi=hard
+ MULTILIB_REQUIRED += mthumb/march=armv7-m
+ MULTILIB_REQUIRED += mthumb
++MULTILIB_REQUIRED += mfpu=vfp/mfloat-abi=hard
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] RTEMS changes for lpc32xx VFP support

2016-08-22 Thread Kirspel, Kevin

diff --git a/c/src/lib/libbsp/arm/lpc32xx/make/custom/lpc32xx.inc 
b/c/src/lib/libbsp/arm/lpc32xx/make/custom/lpc32xx.inc
old mode 100644
new mode 100755
index f184741..441976d
--- a/c/src/lib/libbsp/arm/lpc32xx/make/custom/lpc32xx.inc
+++ b/c/src/lib/libbsp/arm/lpc32xx/make/custom/lpc32xx.inc
@@ -6,7 +6,8 @@ include $(RTEMS_ROOT)/make/custom/default.cfg

RTEMS_CPU = arm

-CPU_CFLAGS = -mcpu=arm926ej-s -mthumb
+#CPU_CFLAGS = -mcpu=arm926ej-s -mthumb
+CPU_CFLAGS = -mcpu=arm926ej-s -mfpu=vfp -mfloat-abi=hard

CFLAGS_OPTIMIZE_V ?= -O2 -g
CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections
diff --git a/c/src/lib/libbsp/arm/shared/start/start.S 
b/c/src/lib/libbsp/arm/shared/start/start.S
old mode 100644
new mode 100755
index 30501be..f95a9d3
--- a/c/src/lib/libbsp/arm/shared/start/start.S
+++ b/c/src/lib/libbsp/arm/shared/start/start.S
@@ -19,9 +19,9 @@
  */

#include 
-#include 
+#include 
#include 
-
+
#include 
#include 
#include 
@@ -265,6 +265,7 @@ bsp_start_skip_hyp_svc_switch:
   /* Stay in SVC mode */

#ifdef ARM_MULTILIB_VFP
+#ifdef ARM_MULTILIB_HAS_CPACR
   /* Read CPACR */
   mrc p15, 0, r0, c1, c0, 2

@@ -280,11 +281,18 @@ bsp_start_skip_hyp_svc_switch:
   /* Write CPACR */
   mcr p15, 0, r0, c1, c0, 2
   isb
+#endif

   /* Enable FPU */
   mov r0, #(1 << 30)
   vmsr FPEXC, r0

+#ifdef __FAST_MATH__
+  /* Enable Fast FPU options */
+  mov r0, #(3 << 24)
+  vmsr FPSCR, r0
+#endif
+
#ifdef BSP_START_NEEDS_REGISTER_INITIALIZATION
   bl bsp_start_init_registers_vfp
#endif
@@ -399,6 +407,7 @@ _start:
#endif

#ifdef ARM_MULTILIB_VFP
+#ifdef ARM_MULTILIB_HAS_CPACR
   /*
* Enable CP10 and CP11 coprocessors for privileged and user 
mode in
* CPACR (bits 20-23).  Ensure that write to register completes.
@@ -409,6 +418,7 @@ _start:
   str   r1, [r0]
   dsb
   isb
+#endif

#ifdef BSP_START_NEEDS_REGISTER_INITIALIZATION
   bl bsp_start_init_registers_vfp
diff --git a/cpukit/score/cpu/arm/rtems/score/arm.h 
b/cpukit/score/cpu/arm/rtems/score/arm.h
old mode 100644
new mode 100755
index 666ee54..7e511ac
--- a/cpukit/score/cpu/arm/rtems/score/arm.h
+++ b/cpukit/score/cpu/arm/rtems/score/arm.h
@@ -57,6 +57,13 @@ extern "C" {
#if defined(__ARM_ARCH_7A__)
   #define ARM_MULTILIB_CACHE_LINE_MAX_64
#endif
+
+#if defined(__ARM_ARCH_7A__) \
+  || defined(__ARM_ARCH_7M__) \
+  || defined(__ARM_ARCH_7EM__)
+  #define ARM_MULTILIB_HAS_CPACR
+#endif
+

#if !defined(__SOFTFP__)
   #if defined(__ARM_NEON__)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

Re: [PATCH v2 1/6] Imported files for driver: bcm283x_dwcotg

RE: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

[PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support

[PATCH 2/2] RTEMS changes for lpc32xx VFP support

6 matches

Site Navigation

Mail list logo

Footer information