from:"Kirspel, Kevin"

RE: Cyclone 10 LP BSP

2023-11-28 Thread Kirspel, Kevin

Never mind, It's something to do with my debugger and stepping through code.  I 
can get the hello world message to spit out if I break after the printf 
statement.

Kevin Kirspel (he/his), R Manager Sr II, BS EE
IDEXX | One IDEXX Drive Westbrook, Maine 04092 | m. +1 770-688-1642 | idexx.com


We help pets lead fuller lives + + + + + + +


[Shape  Description automatically generated with medium confidence]

From: Kirspel, Kevin
Sent: Monday, November 27, 2023 7:19 PM
To: devel@rtems.org
Subject: Cyclone 10 LP BSP

I'm trying to create a BSP for a NIOS V/m running on a Cyclone 10 LP Eval Kit.  
The NIOS V/m is a rv32ia/ilp32 architecture so I had to patch the RSB to add 
that multilib.  I have a Hello World app compiled but I get exceptions when 
having the tick timer interrupt enabled.  So, I disabled the tick timer 
interrupt and was able to get to the Init() task.  When execution the hello 
world printf, I get another exception related to puts_r in newlib.  The 
exception is occurring when trying to load the address of _tls_stdout.  I 
traced this back to THREAD_LOCAL_STORAGE being enabled in newlib for the RISC 
V.  Does the BSP have to do anything to setup thread local storage or does this 
happen automatically when triggered?  The exception occurs after it returns 
from __sinit which I guess is initializes the thread local storage.

Kevin Kirspel (he/his), R Manager Sr II, BS EE
IDEXX | One IDEXX Drive Westbrook, Maine 04092 | m. +1 770-688-1642 | idexx.com


We help pets lead fuller lives + + + + + + +


[Shape  Description automatically generated with medium confidence]

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

Cyclone 10 LP BSP

2023-11-27 Thread Kirspel, Kevin

I'm trying to create a BSP for a NIOS V/m running on a Cyclone 10 LP Eval Kit.  
The NIOS V/m is a rv32ia/ilp32 architecture so I had to patch the RSB to add 
that multilib.  I have a Hello World app compiled but I get exceptions when 
having the tick timer interrupt enabled.  So, I disabled the tick timer 
interrupt and was able to get to the Init() task.  When execution the hello 
world printf, I get another exception related to puts_r in newlib.  The 
exception is occurring when trying to load the address of _tls_stdout.  I 
traced this back to THREAD_LOCAL_STORAGE being enabled in newlib for the RISC 
V.  Does the BSP have to do anything to setup thread local storage or does this 
happen automatically when triggered?  The exception occurs after it returns 
from __sinit which I guess is initializes the thread local storage.

Kevin Kirspel (he/his), R Manager Sr II, BS EE
IDEXX | One IDEXX Drive Westbrook, Maine 04092 | m. +1 770-688-1642 | idexx.com


We help pets lead fuller lives + + + + + + +


[Shape  Description automatically generated with medium confidence]

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

RE: parallel make failure?

2017-07-21 Thread Kirspel, Kevin

I have seen similar things as well.  In my case it fails in different places 
randomly.  Sometimes it will get all the way through. 

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Gedare Bloom
Sent: Friday, July 21, 2017 11:24 AM
To: devel@rtems.org
Subject: parallel make failure?

I'm building a clean master with current tools and observed the following using 
make -j4:

/usr/bin/install -c -m 644
../../../../../../rtems/c/src/libchip/i2c/i2c-ds1621.h
../../../erc32/lib/include/libchip/i2c-ds1621.h
/usr/bin/install: cannot create regular file
'../../../erc32/lib/include/libchip/ds1375-rtc.h': File exists
Makefile:2147: recipe for target
'../../../erc32/lib/include/libchip/ds1375-rtc.h' failed
make[5]: *** [../../../erc32/lib/include/libchip/ds1375-rtc.h] Error 1
make[5]: Leaving directory
'/home/gedare/work/rtems/builds/b-erc32/sparc-rtems4.12/c/erc32/libchip'
Makefile:916: recipe for target 'preinstall-libchip' failed
make[4]: *** [preinstall-libchip] Error 1

With just 'make' it passes this step.
___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwICAg=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=H9XvezTNiH4W-H2EFj7UpeWTK8A3pj_g9545ys--tXQ=NK5spqMDGykOoOeFKNlO88-8y9mrj6y9saEinGMqxkw=
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: LIBBSD

2017-07-03 Thread Kirspel, Kevin

The MMU is disabled right now because I am tracking down a problem (not related 
to LIBBSD).  I was going to turn it back on after I solve that issue.

I'm using a 1ms tick.  

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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, July 03, 2017 1:47 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: LIBBSD

On 30/06/17 20:08, Kirspel, Kevin wrote:

> Case #2: Enable the RTEMS callout timer but do not call "callout_process()" 
> (the timer service routine just resets the timer and quits) .
> IDLE Task CPUUSE: 93.144%
> TIME Task CPUUSE: 6.282%

In this case you have some low-level problem on your target. Is the cache 
enabled and properly set up in the MMU? How many ticks per second do you 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 keine geschäftliche Mitteilung im Sinne des EHUG.

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

RE: LIBBSD

2017-07-02 Thread Kirspel, Kevin

I have rewritten the kern_timeout.c module to use individual RTEMS timers per 
callout/timeout function.  My Idle task CPUUSE is now 99.9%. I still need to 
validate all the functionality of the kern_timeout.c module with a timeout01 
test in the testsuite.  I don't think the existing kern_timeout.c module 
currently supports all the functionality that is used in Freebsd 
(callouts/timeouts on a particular CPU core).  Right now everything is 
processed on CPU core 0 because of the way the RTEMS timer server works.  My 
version excludes all the SMP stuff and silently places all timeouts on CPU core 
0.  We could probably support the callouts/timeouts on a particular CPU core if 
we update the RTEMS timer code but I don't think it is a feature that most 
people would use.

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Kirspel, Kevin
Sent: Friday, June 30, 2017 2:08 PM
To: devel@rtems.org
Subject: RE: LIBBSD

Just some quick numbers.  LPC3250 running at 208 MHz, 64MB RAM, 512MB FLASH.

Case #1: Disable the RTEMS callout timer in LIBBSD (kern_timeout.c) IDLE Task 
CPUUSE: 99.430% TIME Task CPUUSE: <0.001%

Case #2: Enable the RTEMS callout timer but do not call "callout_process()" 
(the timer service routine just resets the timer and quits) .
IDLE Task CPUUSE: 93.144%
TIME Task CPUUSE: 6.282%

So just processing the 1 tick RTEMS timer in LIBBSD's kern_timeout.c takes up 
6% of the CPU processing time.

Case #3: Normal callout processing
IDLE Task CPUUSE: 87.116%
TIME Task CPUUSE: 12.672%

Below are the callout functions that are being executed.  The number beside 
each function is the average number of clocks it took to execute (13MHz base 
clock).

ipport_tick - 370/28us
pffasttimo -  930/72us
pfslowtimo - 5600/431us
lpe_tick - 4200/323us
_bsd_nd6_timer - 650/50us
usb_power_wdog - 1000/80us
ohci_rhsc_enable - 400/31us

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber
Sent: Friday, June 30, 2017 1:15 AM
To: devel@rtems.org
Subject: Re: LIBBSD

On 29/06/17 20:02, Kirspel, Kevin wrote:

> For those who run a RTEMS 4.12 single processor application with 
> LIBBSD, what percentage of time does your application spend in the 
> timer server task?  My NXP LPC3250 application spends about 13% of the 
> processor time processing the timer server.  Most of that time is 
> spent processing LIBBSD's kernel callouts.  I am wondering if there is 
> an advantage to only call the FreeBSD's callout_process() function 
> when we know a callout needs to be processed.  This would reduce the 
> number of RTEMS timer fires (which currently fire every tick).

Normally, the timer server should be in the range of 0.x% of CPU time. 
If you have 13%, then you have a lot of timeout processing. What is the reason 
for this?

--
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.

___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=wi6q2gTnD-FidfbEqMhvlESvqYn-Fmg-tXnNg62S3BY=8pSzson7fylkfTRzYKIMlQnFgvwpY8lpExFHqEEapbc=
___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwIFAw=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=RMQjCIXGYJE0sLPFXFT_ff4hxd0Xv4XwddHMeiJ22Dg=3xFmeotPlm109pDOuYPFrRHA4IDShM96NNS3CGwextE=

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

RE: LIBBSD TCPDUMP

2017-07-01 Thread Kirspel, Kevin

No.  I fixed that after I noticed the data was invalid during testing.  I moved 
the variable declaration outside of the if statement and now the data is 
correct.

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

-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare 
Bloom
Sent: Saturday, July 01, 2017 1:30 PM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>
Cc: j...@rtems.org; rtems-de...@rtems.org <devel@rtems.org>
Subject: Re: LIBBSD TCPDUMP

On Sat, Jul 1, 2017 at 11:49 AM, Kirspel, Kevin <kevin-kirs...@idexx.com> wrote:
> This is how I fixed it.  I did similar things for EXTRACT_32BITS and 
> EXTRACT_64BITS.
>
>
>
> static inline u_int16_t
>
> EXTRACT_16BITS(const void *p)
>
> {
>
> #if defined(__arm__) && defined(__rtems__)
>
> if(((uint32_t)p % 2) != 0) {
>
> u_int16_t value;
>
> u_int8_t *ptr = (u_int8_t *)
>
> ptr[0] = ((const u_int8_t *)p)[0];
>
> ptr[1] = ((const u_int8_t *)p)[1];
>
> p = 
>

Is it correct to assign a pointer to a block-scoped variable here? It looks 
suspect to me. I'd at least put the declaration of 'value'
before the block here.

> }
>
> #endif /* __rtems__ */
>
> return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
>
> }
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> From: Joel Sherrill [mailto:j...@rtems.org]
> Sent: Saturday, July 01, 2017 11:39 AM
> To: Gedare Bloom <ged...@rtems.org>
> Cc: rtems-de...@rtems.org <devel@rtems.org>; Kirspel, Kevin 
> <kevin-kirs...@idexx.com>
> Subject: Re: LIBBSD TCPDUMP
>
>
>
>
>
>
>
> On Jul 1, 2017 10:34 AM, "Gedare Bloom" <ged...@rtems.org> wrote:
>
> On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin 
> <kevin-kirs...@idexx.com>
> wrote:
>> I get a crash when running the tcpdump command in LIBBSD.  It is due 
>> to the following structure
>>
>>
>>
>> struct stp_bpdu_ {
>>
>> u_int8_t protocol_id[2];
>>
>> u_int8_t protocol_version;
>>
>> u_int8_t bpdu_type;
>>
>> u_int8_t flags;
>>
>> u_int8_t root_id[8];
>>
>> u_int8_t root_path_cost[4];
>>
>>u_int8_t bridge_id[8];
>>
>> u_int8_t port_id[2];
>>
>> u_int8_t message_age[2];
>>
>> u_int8_t max_age[2];
>>
>> u_int8_t hello_time[2];
>>
>> u_int8_t forward_delay[2];
>>
>> u_int8_t v1_length;
>>
>> };
>>
>>
>>
>> In the code, there is an access to the port_id field as follows:
>> EXTRACT_16BITS(_bpdu->port_id).  EXTRACT_16BITS calls ntohs() .  
>> Since the address of “_bpdu->port_id” is at an odd word (16 bit) 
>> boundary, an exception is generated.  What is the correct way to fix 
>> this?  I was going to update EXTRACT_16BITS to check for an odd 
>> boundary and fix it up before calling ntohs().
>>
>
> That would probably be a more portable fix than allowing unaligned 
> accesses. I think the alignment should be made to the CPU_ALIGNMENT 
> macro.
>
>
>
> Can't you also just pull it out a byte at a time, form the net version 
> and then ntohs()?
>
>
>
> That's what I coded recently in some marahalling code.
>
>
>
>
>
>>
>>
>> Kevin Kirspel
>>
>> Electrical Engineer - Sr. Staff
>>
>> Idexx Roswell
>>
>> 235 Hembree Park Drive
>>
>> Roswell GA 30076
>>
>> Tel: (770)-510- ext. 81642
>>
>> Direct: (770)-688-1642
>>
>> Fax: (770)-510-4445
>>
>>
>>
>>
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_m
>> ailman_listinfo_devel=DwIFaQ=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ
>> 32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rA
>> xPKDDt1ac=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw=
> ___
> devel mailing list
> devel@rtems.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_ma
> ilman_listinfo_devel=DwIFaQ=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32
> G5JGdpyUxbdebuwKHBbeiHMr3RbR74=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rAxPKDDt1ac=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw=
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

LIBBSD TCPDUMP

2017-07-01 Thread Kirspel, Kevin

I get a crash when running the tcpdump command in LIBBSD.  It is due to the 
following structure

struct stp_bpdu_ {
u_int8_t protocol_id[2];
u_int8_t protocol_version;
u_int8_t bpdu_type;
u_int8_t flags;
u_int8_t root_id[8];
u_int8_t root_path_cost[4];
   u_int8_t bridge_id[8];
u_int8_t port_id[2];
u_int8_t message_age[2];
u_int8_t max_age[2];
u_int8_t hello_time[2];
u_int8_t forward_delay[2];
u_int8_t v1_length;
};

In the code, there is an access to the port_id field as follows: 
EXTRACT_16BITS(_bpdu->port_id).  EXTRACT_16BITS calls ntohs() .  Since the 
address of "_bpdu->port_id" is at an odd word (16 bit) boundary, an 
exception is generated.  What is the correct way to fix this?  I was going to 
update EXTRACT_16BITS to check for an odd boundary and fix it up before calling 
ntohs().

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

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

RE: LIBBSD

2017-06-30 Thread Kirspel, Kevin

Just some quick numbers.  LPC3250 running at 208 MHz, 64MB RAM, 512MB FLASH.

Case #1: Disable the RTEMS callout timer in LIBBSD (kern_timeout.c)
IDLE Task CPUUSE: 99.430%
TIME Task CPUUSE: <0.001%

Case #2: Enable the RTEMS callout timer but do not call "callout_process()" 
(the timer service routine just resets the timer and quits) .
IDLE Task CPUUSE: 93.144%
TIME Task CPUUSE: 6.282%

So just processing the 1 tick RTEMS timer in LIBBSD's kern_timeout.c takes up 
6% of the CPU processing time.

Case #3: Normal callout processing
IDLE Task CPUUSE: 87.116%
TIME Task CPUUSE: 12.672%

Below are the callout functions that are being executed.  The number beside 
each function is the average number of clocks it took to execute (13MHz base 
clock).

ipport_tick - 370/28us
pffasttimo -  930/72us
pfslowtimo - 5600/431us
lpe_tick - 4200/323us
_bsd_nd6_timer - 650/50us
usb_power_wdog - 1000/80us
ohci_rhsc_enable - 400/31us

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber
Sent: Friday, June 30, 2017 1:15 AM
To: devel@rtems.org
Subject: Re: LIBBSD

On 29/06/17 20:02, Kirspel, Kevin wrote:

> For those who run a RTEMS 4.12 single processor application with 
> LIBBSD, what percentage of time does your application spend in the 
> timer server task?  My NXP LPC3250 application spends about 13% of the 
> processor time processing the timer server.  Most of that time is 
> spent processing LIBBSD's kernel callouts.  I am wondering if there is 
> an advantage to only call the FreeBSD's callout_process() function 
> when we know a callout needs to be processed.  This would reduce the 
> number of RTEMS timer fires (which currently fire every tick).

Normally, the timer server should be in the range of 0.x% of CPU time. 
If you have 13%, then you have a lot of timeout processing. What is the reason 
for this?

--
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.

___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=wi6q2gTnD-FidfbEqMhvlESvqYn-Fmg-tXnNg62S3BY=8pSzson7fylkfTRzYKIMlQnFgvwpY8lpExFHqEEapbc=

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

RE: LIBBSD

2017-06-30 Thread Kirspel, Kevin

I'm not sure but I'll look into it today.  I'll need to quantify each callout 
handler's processing time to see which one is causing the problem.  I know the 
USB and Ethernet stacks/drivers use callouts but maybe there is something else.

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber
Sent: Friday, June 30, 2017 1:15 AM
To: devel@rtems.org
Subject: Re: LIBBSD

On 29/06/17 20:02, Kirspel, Kevin wrote:

> For those who run a RTEMS 4.12 single processor application with 
> LIBBSD, what percentage of time does your application spend in the 
> timer server task?  My NXP LPC3250 application spends about 13% of the 
> processor time processing the timer server.  Most of that time is 
> spent processing LIBBSD's kernel callouts.  I am wondering if there is 
> an advantage to only call the FreeBSD's callout_process() function 
> when we know a callout needs to be processed.  This would reduce the 
> number of RTEMS timer fires (which currently fire every tick).

Normally, the timer server should be in the range of 0.x% of CPU time. 
If you have 13%, then you have a lot of timeout processing. What is the reason 
for this?

--
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.

___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=wi6q2gTnD-FidfbEqMhvlESvqYn-Fmg-tXnNg62S3BY=8pSzson7fylkfTRzYKIMlQnFgvwpY8lpExFHqEEapbc=

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

LIBBSD

2017-06-29 Thread Kirspel, Kevin

For those who run a RTEMS 4.12 single processor application with LIBBSD, what 
percentage of time does your application spend in the timer server task?  My 
NXP LPC3250 application spends about 13% of the processor time processing the 
timer server.  Most of that time is spent processing LIBBSD's kernel callouts.  
I am wondering if there is an advantage to only call the FreeBSD's 
callout_process() function when we know a callout needs to be processed.  This 
would reduce the number of RTEMS timer fires (which currently fire every tick).

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

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

LIBBSD Build Error

2017-06-21 Thread Kirspel, Kevin

I have rebased my tools via RSB to the latest and have successfully compiled 
RTEMS with a custom lpc32xx BSP.  When compiling LIBBSD, I am getting the 
following error when compiling "freebsd/lib/libc/inet/nsap_addr.c "

/tmp/ccWucPca.s: Assembler messages:
/tmp/ccWucPca.s:474: Error: symbol `inet_nsap_addr' is already defined
/tmp/ccWucPca.s:476: Error: symbol `inet_nsap_ntoa' is already defined

I assume this is related to pushing network headers into newlib.  There are 
weak aliases in the file as follows:

/*
* Weak aliases for applications that use certain private entry points,
* and fail to include .
*/
#undef inet_nsap_addr
__weak_reference(__inet_nsap_addr, inet_nsap_addr);
#undef inet_nsap_ntoa
__weak_reference(__inet_nsap_ntoa, inet_nsap_ntoa);

Before digging into this, does anyone have an explanation?

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

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

make install problems

2017-05-25 Thread Kirspel, Kevin

I am having trouble with make install today.  Nothing gets copied to the 
installation directory when invoking make install.  Did the recent parallel 
build on all sub directories changes affect the way make install works?

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

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

Linux Frame Buffer

2017-05-23 Thread Kirspel, Kevin

I would like to submit a patch to add the Linux framebuffer header file to 
RTEMS (linux/fb.h).  This is similar to what has been done for Linux i2c/spi 
compatibility.  Does anyone have an issue with this?

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

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

RE: RTEMS MAP_SHARED support expansion

2017-05-17 Thread Kirspel, Kevin

OK.  I will just stick with approach 1.

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber
Sent: Wednesday, May 17, 2017 1:32 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: RTEMS MAP_SHARED support expansion

On 16/05/17 21:28, Kirspel, Kevin wrote:
> The second approach includes the first approach but adds support for 
> RTEMS device drivers.  We would need to add a mmap handler to 
> "rtems_driver_address_table".  The "IMFS_device_handlers" would add a 
> mmap handler to device_mmap(). We would need a new
> rtems_deviceio_mmap() function to call the drivers mmap handler.  I 
> don't think any BSPs will be affected because the mmap handler of 
> "rtems_driver_address_table" should initialize to NULL.  Any BSP would 
> them be free to add a handler to process mmap calls.

I would not touch the legacy RTEMS device drivers. With the IMFS generic nodes 
we have something more flexible with lower overhead.

--
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.

___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI=LvIJSxMOfKUmtQhAsLZm_KkVvgeGT75H5TZ06fzmwiw=LB8V3jvtD878rxyGZSjR_VoEbJii-JWdjaw4a3GaFYk=
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 04/11] Add USB UGEN support for RTEMS

2017-05-17 Thread Kirspel, Kevin

I got a message that the patch was too large and held for review.  Is there a 
process for someone to review large patches and release them?  If not, I can 
send you the patch directly.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Wednesday, May 17, 2017 1:46 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 04/11] Add USB UGEN support for RTEMS

Patch 03/11 is missing. I was not able to apply the patch series.

-- 
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.

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

RTEMS MAP_SHARED support expansion

2017-05-16 Thread Kirspel, Kevin

I would like to expand support for MAP_SHARED in mmap().  I would like to run a 
few ideas by the group to see which direction to go.  I really only need to 
expand MAP_SHARED support for some LIBBSD drivers that I want to create.  There 
are two approaches I can take.

The first approach is to just add a mmap handler function in "struct 
_rtems_filesystem_file_handlers_r".  The mmap() restrictions on MAP_SHARED 
would be removed.  The mmap handler for all RTEMS file systems (except SHM) 
would get the default mmap handler (return EINVAL).  SHM would get a handler 
similar to the one found in mmap.c.  In RTEMS-LIBBSD, the RTEMS character 
device handler (devfs_devs.c) would be free to pass the mmap request on to 
FREEBSD drivers.

The second approach includes the first approach but adds support for RTEMS 
device drivers.  We would need to add a mmap handler to 
"rtems_driver_address_table".  The "IMFS_device_handlers" would add a mmap 
handler to device_mmap().  We would need a new rtems_deviceio_mmap() function 
to call the drivers mmap handler.  I don't think any BSPs will be affected 
because the mmap handler of "rtems_driver_address_table" should initialize to 
NULL.  Any BSP would them be free to add a handler to process mmap calls.

Any opposition to the two approaches?  If not, which one would you prefer?

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

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

RE: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in FREEBSDs types.h

2017-05-16 Thread Kirspel, Kevin

After doing some research, the GCC default __builtin_popcount functions are 
slower than the FREEBSD versions (roughly 3.5x slower according to some tests I 
saw online).  If someone adds the -mpopcnt compile option, then it means that 
there is a CPU instruction to perform the task.  I think we should do what 
FREEBSD has done.  Only use the built in functions if there is a CPU 
instruction to execute it.

I have posted a patch to newlib.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Tuesday, May 16, 2017 9:28 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in 
FREEBSDs types.h

On 16/05/17 15:18, Kirspel, Kevin wrote:
> Sorry.  I pulled that header file from memory which these days is losing its 
> effectiveness.  So, should we put the bitcount changes in sys/types.h like 
> FREEBSD?
>
> If so, I will submit a patch tonew...@sourceware.org.  How long does it take 
> to get the patch reviewed by the newlib mailing list?

Between one day and four weeks. If its not included this week, then we can use 
the alternative.

Please add GCC support for these operations. I think the builtins are available 
since GCC 3.4.0.

--
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.

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

RE: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in FREEBSDs types.h

2017-05-16 Thread Kirspel, Kevin

Sorry.  I pulled that header file from memory which these days is losing its 
effectiveness.  So, should we put the bitcount changes in sys/types.h like 
FREEBSD?

If so, I will submit a patch to new...@sourceware.org.  How long does it take 
to get the patch reviewed by the newlib mailing list?

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Tuesday, May 16, 2017 9:06 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in 
FREEBSDs types.h

On 16/05/17 14:56, Kirspel, Kevin wrote:
> Should we put this in cdefs.h like FREEBSD?

In FreeBSD the __bitcount*() functions are defined in .

-- 
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.

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

RE: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in FREEBSDs types.h

2017-05-16 Thread Kirspel, Kevin

Should we put this in cdefs.h like FREEBSD?

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Tuesday, May 16, 2017 8:20 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in 
FREEBSDs types.h

On 16/05/17 14:15, Kirspel, Kevin wrote:
> For now, could we just include this in rtems-libbsd until newlib gets updated?

Getting this change into Newlib shouldn't be a problem. You can use something 
like this to update the RSB if you have the Newlib Git commit:

https://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems-2Dsource-2Dbuilder_commit_-3Fid-3D8e6ba2c62552b8deba35d2a0a5b6a498ed4e8a80=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=8d4E_Tw0Wy2ZmYqiWKir4wT6w3s0zFGzE9XxGLABaZw=PhRVqXR36MDsL4Pm-6txrcPhdE3D-cfPEU8mrgrdsNY=
 

--
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.

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

RE: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in FREEBSDs types.h

2017-05-16 Thread Kirspel, Kevin

For now, could we just include this in rtems-libbsd until newlib gets updated?

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Tuesday, May 16, 2017 3:47 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 07/11] Add bitcount inlinesfor RTEMS. These are found in 
FREEBSDs types.h

Hello Kevin,

I know it is considerable more work, but this should move into Newlib.

The

#ifdef __POPCNT__
#define __bitcount64(x) __builtin_popcountll((__uint64_t)(x))

needs GCC support. This __POPCNT__ is a clang feature. I don't know which 
version of GCC supports these builtins, but it should use also a 
__GNUC_PREREQ__(X, Y).

--
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.

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

RE: GSOC 2017 RTEMS-libbsd issue

2017-04-19 Thread Kirspel, Kevin

I have recently posted patches for TTY and USB serial support for FREEBSD.  I 
was going to take a stab at supporting UGEN as well.  The USB mouse and 
keyboard drivers need it as well.  The TTY patches contain some support needed 
for UGEN but there is more required.  Let me take a look at it today to see how 
much more effort it would take to get the baseline UGEN compiling (in 
usb_dev.c).

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

From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sichen Zhao
Sent: Wednesday, April 19, 2017 7:06 AM
To: Christian Mauderer ; RTEMS 

Subject: Re: GSOC 2017 RTEMS-libbsd issue


Hi Christian Mauderer, Hi all,


I understand what you mean, i will update my RTEMS-libbsd to the newest branch.
I already pull over the host controller driver files（am335x_musb.c 
am335x_usbss.c umass.c）from freebsd and make them compilable in rtems-libbsd. 
The umass.c is driver for storage device.
And i already add the host controller and driver to 
nexus-devices.h(RTEMS_BSD_DEFINE_NEXUS_DEVICE(musbotg,0 , 
RTEMS_ARRAY_SIZE(musbotg_res), _res[0]);).

Now uhub usbus and musbotg can mount on nexus bus.
the issue is: it can not find the new device(such as U disk)
So i compare with the FreeBSD boot log info, and the only difference is FreeBSD 
enable the USB_HAVE_UGEN, so i guess if it is necessary
to enable the macro USB_HAVE_UGEN.

Thank you for your suggestions.

Best regards
Sichen Zhao



From: Christian Mauderer 
>
Sent: Wednesday, April 19, 2017 2:02 PM
To: Sichen Zhao; RTEMS
Subject: Re: GSOC 2017 RTEMS-libbsd issue


Am 19.04.2017 um 07:45 schrieb Christian Mauderer:
> Am 18.04.2017 um 17:10 schrieb Sichen Zhao:
>>
>> Hi all,
>>
>> I am working on my goal of GSOC 2017 project: Beaglebone black bsp
>> improvement.
>>
>>
>> And i have some issue about the RTEMS-libbsd:
>>
>> if i switch on the macro USB_HAVE_UGEN in the
>> /rtemsbsd/include/rtems/bsd/local/opt_usb.h,
>>
>> There are lots of errors when compile code.
>>
>>
>>
>>
>> So the macro USB_HAVE_UGEN should keep unable? I see the FreeBSD on BBB
>> enable the USB_HAVE_UGEN.
>>
>>
>> Thanks
>>
>> Sichen Zhao
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> Hello Sichen,
>
> I only read the introduction of the man page (see [1]) but as far as I
> can tell, ugen is a generic USB driver in FreeBSD. I think it would be
> useful if you want to get some generic device Information similar to the
> ones you can get with lsusb in linux. From the look of it, I would
> expect that you also would need it for a library like libusb (which is
> used for example in OpenOCD to get a direct access to the hardware
> without any special drivers).
>
> Normally you should not need it if there is a special driver for your
> USB device in the kernel. For example, if you want to attach a USB mass
> storage stick, you won't need it.
>
> Basically for porting the BBB USB support to libbsd, I would expect that
> you have to pull over the host controller driver files from freebsd and
> make them compilable in rtems-libbsd. Then you would have to add the
> host controller and device drivers to nexus-devices.h. After that, it's
> quite possible that you can already use some of the examples like
> testsuite/media01. If you need any help or details on that process, feel
> free to ask.
>
> Kind regards
>
> Christian Mauderer
>
>
> [1]
> https://www.freebsd.org/cgi/man.cgi?query=ugen=FreeBSD+11.0-RELEASE+and+Ports
>

By the way: I noted that the libbsd in your github repo is from December
2016. There have been quite some changes since then including a mayor
update to the FreeBSD head of 2016-08-23 and two smaller ones to more
recent FreeBSD head versions. Also the WLAN support has been added since
then. You might should consider an update if you still work with this
version.

--

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email:

Ticket 2897

2017-04-10 Thread Kirspel, Kevin

I will be sending a small patch for ticket 2897.  It updates the default 
initialization of the termios structure.  I know Sebastian is out on holiday so 
if someone can process the patch through the ticket I would appreciated it.

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

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

LIBBSD USB Serial Patch

2017-04-07 Thread Kirspel, Kevin

The LIBBSD USB Serial patch depends on the LIBBSD TTY patch I sent out earlier.

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

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

RE: [PATCH 5/7] Adding RTEMS support for FREEBSD TTY

2017-04-07 Thread Kirspel, Kevin

I will revert the PPP changes.  It will still uses RTEMS termios instead of 
FREEBSD.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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, April 07, 2017 5:12 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 5/7] Adding RTEMS support for FREEBSD TTY

On 06/04/17 03:11, Kevin Kirspel wrote:
> ---
>   rtemsbsd/include/machine/rtems-bsd-commands.h |   2 +
>   rtemsbsd/include/machine/rtems-bsd-kernel-space.h |   1 +
>   rtemsbsd/include/rtems/bsd/local/opt_gdb.h|   1 +
>   rtemsbsd/include/rtems/netcmds-config.h   |   2 +
>   rtemsbsd/rtems/rtems-bsd-shell-stty.c |  40 +++
>   rtemsbsd/sys/fs/devfs/devfs_devs.c|  86 +-
>   rtemsbsd/sys/fs/devfs/devfs_vnops.c   | 136 
> ++
>   rtemsbsd/sys/net/ppp_tty.c|  10 +-
>   8 files changed, 263 insertions(+), 15 deletions(-)
>   create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_gdb.h
>   create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-stty.c
>   mode change 100755 => 100644 rtemsbsd/sys/fs/devfs/devfs_devs.c
>   create mode 100644 rtemsbsd/sys/fs/devfs/devfs_vnops.c
[...]

> diff --git a/rtemsbsd/sys/fs/devfs/devfs_vnops.c 
> b/rtemsbsd/sys/fs/devfs/devfs_vnops.c
> new file mode 100644
> index 000..8c4a786
> --- /dev/null
> +++ b/rtemsbsd/sys/fs/devfs/devfs_vnops.c
> @@ -0,0 +1,136 @@
> +/*
> + * Copyright (c) 2016 embedded brains GmbH.  All rights reserved.
> + *
> + *  embedded brains GmbH
> + *  Dornierstr. 4
> + *  82178 Puchheim
> + *  Germany
> + *  <rt...@embedded-brains.de>

This should probably be your copyright (please check other files too).

> diff --git a/rtemsbsd/sys/net/ppp_tty.c b/rtemsbsd/sys/net/ppp_tty.c 
> index 9d416ea..718b146 100644
> --- a/rtemsbsd/sys/net/ppp_tty.c
> +++ b/rtemsbsd/sys/net/ppp_tty.c
> @@ -426,16 +426,8 @@ ppptioctl(struct rtems_termios_tty *tty, 
> rtems_libio_ioctl_args_t *args)
>   struct ppp_softc   *sc= tty->t_sc;
>   
>   switch (cmd) {
> -case RTEMS_IO_RCVWAKEUP:
>   case RTEMS_IO_SNDWAKEUP:
> -case TIOCDRAIN:
> -case TIOCFLUSH:
> -case TIOCGETA:
> -case TIOCGETD:
> -case TIOCSETA:
> -case TIOCSETAF:
> -case TIOCSETAW:
> -case TIOCSETD:
> +case RTEMS_IO_RCVWAKEUP:
>   error = rtems_termios_ioctl(args);
>   break;
>   

Are you sure of this change? The PPP driver is a standard Termios driver ported 
from the old network stack. It would be nice to get rid of it eventually.

--
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.

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

RE: [PATCH 1/7] Adding stty command files from FREEBSD tree

2017-04-06 Thread Kirspel, Kevin

Yes.  I rebased last night.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Thursday, April 06, 2017 1:26 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 1/7] Adding stty command files from FREEBSD tree

I updated the FreeBSD baseline two days ago. Is this patch series based on this 
version?

--
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.

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

RE: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

2017-03-21 Thread Kirspel, Kevin

I have compiled all BSPs for the following toolsets:

arm, bfin, sh, i386, m68k, lm32, powerpc, and sparc

All BSPs for these toolsets build without error.  I had to fix some arm and sh 
code so I will send version 3 of the patch soon.  These toolsets were chosen 
due to the fact that a BSP within the toolset was updated to accommodate the 
termios changes.

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber
Sent: Tuesday, March 21, 2017 2:35 AM
To: devel@rtems.org
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

On 21/03/17 00:25, Joel Sherrill wrote:
> Agreed a BSP or user space code should not use the same name as 
> anything that is included in POSIX. :)
>
> How did my build sweep miss this?

You didn't apply Kevin's patches?

--
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.

___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI=gviw10QRteGCnfEYiKuWi1Y2f1ukuTJ7WvP9wjxNeXQ=HvhAZ_Ioa2oUSpcVqSrkqer5oyBw1CQys4XBb7XcgOg=

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

RE: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

2017-03-20 Thread Kirspel, Kevin

Actually the best thing to do is change the structure member name and fix up 
any access to that member.

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

From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Kirspel, Kevin
Sent: Monday, March 20, 2017 1:50 PM
To: devel@rtems.org
Subject: RE: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

I tracked the arm failure down to a header file (s3c2410.h) that contains a 
structure that has a member with the same name as a termios #define. 
Re-ordering the include file declarations in each affected C file will fix the 
problem (I’m not sure that’s the best solution but it will do for now).  I am 
going to build all the tool chains so I can check the rest of the BSPs.  
Sebastian found another issue with a SH BSP.

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

From: Joel Sherrill [mailto:j...@rtems.org]
Sent: Monday, March 20, 2017 1:33 PM
To: Kirspel, Kevin <kevin-kirs...@idexx.com<mailto:kevin-kirs...@idexx.com>>
Cc: devel@rtems.org<mailto:devel@rtems.org>
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

I just built all BSPs and didn't see any failures.

Sebastian.. what was going on with the build you saw fail?

--joel

On Mon, Mar 20, 2017 at 9:19 AM, Joel Sherrill 
<j...@rtems.org<mailto:j...@rtems.org>> wrote:


On Tue, Mar 14, 2017 at 8:54 AM, Kirspel, Kevin 
<kevin-kirs...@idexx.com<mailto:kevin-kirs...@idexx.com>> wrote:
I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if there 
is a way to compile the patch against every (or most) BSP then we could ensure 
no BSP is broken.

There are scripts in rtems-testing/rtems to ease testing of a single 
configuation
on all BSPs. Or a variety of configurations on a single BSP. I use them to
generate the warnings reports that I periodically announce.

I am seeing if all BSPs build now. Give me a few hours.

--joel

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642<tel:%28770%29-510-%20ext.%2081642>
Direct: (770)-688-1642<tel:%28770%29-688-1642>
Fax: (770)-510-4445<tel:%28770%29-510-4445>

-Original Message-
From: Sebastian Huber 
[mailto:sebastian.hu...@embedded-brains.de<mailto:sebastian.hu...@embedded-brains.de>]
Sent: Tuesday, March 14, 2017 9:42 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com<mailto:kevin-kirs...@idexx.com>>; 
devel@rtems.org<mailto:devel@rtems.org>
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

The patch set looks good after a rough review. I will check this in in two or 
three days if nobody objects.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16<tel:%2B49%2089%20189%2047%2041-16>
Fax : +49 89 189 47 41-09<tel:%2B49%2089%20189%2047%2041-09>
E-Mail  : 
sebastian.hu...@embedded-brains.de<mailto:sebastian.hu...@embedded-brains.de>
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org<mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwMFaQ=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=Rh9qB1wyRTbNNWuecoD2ZnxQG4zzUt_g-GM295-SibA=DM2kkkY3t3lj7LgOPBCejJ85dfSKMbJxO7971XSRMJI=>


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

RE: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

2017-03-20 Thread Kirspel, Kevin

I tracked the arm failure down to a header file (s3c2410.h) that contains a 
structure that has a member with the same name as a termios #define. 
Re-ordering the include file declarations in each affected C file will fix the 
problem (I’m not sure that’s the best solution but it will do for now).  I am 
going to build all the tool chains so I can check the rest of the BSPs.  
Sebastian found another issue with a SH BSP.

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

From: Joel Sherrill [mailto:j...@rtems.org]
Sent: Monday, March 20, 2017 1:33 PM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>
Cc: devel@rtems.org
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

I just built all BSPs and didn't see any failures.

Sebastian.. what was going on with the build you saw fail?

--joel

On Mon, Mar 20, 2017 at 9:19 AM, Joel Sherrill 
<j...@rtems.org<mailto:j...@rtems.org>> wrote:


On Tue, Mar 14, 2017 at 8:54 AM, Kirspel, Kevin 
<kevin-kirs...@idexx.com<mailto:kevin-kirs...@idexx.com>> wrote:
I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if there 
is a way to compile the patch against every (or most) BSP then we could ensure 
no BSP is broken.

There are scripts in rtems-testing/rtems to ease testing of a single 
configuation
on all BSPs. Or a variety of configurations on a single BSP. I use them to
generate the warnings reports that I periodically announce.

I am seeing if all BSPs build now. Give me a few hours.

--joel

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642<tel:%28770%29-510-%20ext.%2081642>
Direct: (770)-688-1642<tel:%28770%29-688-1642>
Fax: (770)-510-4445<tel:%28770%29-510-4445>

-Original Message-
From: Sebastian Huber 
[mailto:sebastian.hu...@embedded-brains.de<mailto:sebastian.hu...@embedded-brains.de>]
Sent: Tuesday, March 14, 2017 9:42 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com<mailto:kevin-kirs...@idexx.com>>; 
devel@rtems.org<mailto:devel@rtems.org>
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

The patch set looks good after a rough review. I will check this in in two or 
three days if nobody objects.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16<tel:%2B49%2089%20189%2047%2041-16>
Fax : +49 89 189 47 41-09<tel:%2B49%2089%20189%2047%2041-09>
E-Mail  : 
sebastian.hu...@embedded-brains.de<mailto:sebastian.hu...@embedded-brains.de>
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org<mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwMFaQ=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=Rh9qB1wyRTbNNWuecoD2ZnxQG4zzUt_g-GM295-SibA=DM2kkkY3t3lj7LgOPBCejJ85dfSKMbJxO7971XSRMJI=>


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

RE: [PATCH 2/5] Modify termios to support dedicated input and output baud rates for termios structure

2017-03-14 Thread Kirspel, Kevin

I'll send new patches without the name change.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Tuesday, March 14, 2017 2:35 AM
To: devel@rtems.org
Cc: Kirspel, Kevin <kevin-kirs...@idexx.com>
Subject: Re: [PATCH 2/5] Modify termios to support dedicated input and output 
baud rates for termios structure

On 13/03/17 17:00, Kevin Kirspel wrote:
> -  case RTEMS_IO_SNDWAKEUP:
> +  case TIOCSNDWU:
>   tty->tty_snd = *wakeup;
>   break;
>   
> -  case RTEMS_IO_RCVWAKEUP:
> +  case TIOCRCVWU:
>   tty->tty_rcv = *wakeup;
>   break;

Since they are RTEMS-specific and probably a (undocumented) part of the user 
API, could you please not change the IO control name.

--
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.

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

RE: [PATCH 8/9] Patching USB serial drivers and Termios for use in RTEMS

2017-02-14 Thread Kirspel, Kevin

OK.  I want to update my RTEMS termios patch anyway to include a couple of 
changes that fell out of the FREEBSD USB serial test cases.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Tuesday, February 14, 2017 3:23 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 8/9] Patching USB serial drivers and Termios for use in 
RTEMS

We should first make the Termios API provided by RTEMS more FreeBSD
compatible:

https://urldefense.proofpoint.com/v2/url?u=https-3A__devel.rtems.org_ticket_2897=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=b-FtaO1HmjucZKZlsvK6tIij6oZHXcLVEQDsr-_9vzo=Lk4w_YapbZ_YpYJxpoNWtTLXIafXLa4ORXwi8DNZykw=
 

Would you mind sending the relevant patches of this ticket to the mailing list?

Since  is a POSIX header file, it should go into Newlib from my 
point of view.

https://urldefense.proofpoint.com/v2/url?u=https-3A__devel.rtems.org_ticket_2833=DwIF-g=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=b-FtaO1HmjucZKZlsvK6tIij6oZHXcLVEQDsr-_9vzo=QKAQ8SOYH7JdglpgNU1JgKrjx0pkXnYxgmhzNuY6mEs=
 

--
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.

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

RE: [PATCH 7/9] Patching STTY command for use in RTEMS

2017-02-10 Thread Kirspel, Kevin

I can include the libbsd.txt updates in my updated patches.

If you want getopt_r() to match FREEBSD, it needs to be updated so that it 
works correctly when optind is initialized to 1 or 0. 

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

-Original Message-
From: Christian Mauderer [mailto:christian.maude...@embedded-brains.de] 
Sent: Friday, February 10, 2017 6:04 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>
Cc: RTEMS Devel <devel@rtems.org>
Subject: Re: [PATCH 7/9] Patching STTY command for use in RTEMS

Hello Kevin,

Am 09.02.2017 um 22:51 schrieb Kirspel, Kevin:
> Before or after the "Build the libbsd without optimization." step, I would 
> add a statement about fixing up any compilation errors.  Maybe most commands 
> will compile after making the changes listed previously but I had to fixup 
> errors related to termios differences between RTEMS and FREEBSD.  Besides 
> that, the instructions were fine and I got the suspected output. 

OK. So in general it worked. That is good to know. Do you want to add this 
information to the documentation or should I create a patch?

> 
> I didn't realize the files were being changed to executables.  I edit the 
> files from a windows application running over a Samba share.  I'll check and 
> see if samba is making the change on save.

I assumed such a problem. Also it's just a detail.

> 
> I will fix the tabs.  Sometimes I forget to change my editor settings for the 
> different files I am working on.

Thanks.

> 
> There is an issue with the getopt_r() function.  Even if you initialize the 
> optind value to 1 the getopt_r() function returns '?'.  So you get past the 
> strspn() check but fail the getopt_r() call.  If you initialize the optind 
> value to 0, you get the right return value but the optind is wrong for the 
> strspn() call.  If you change the original code to the following, then it 
> will also work:
> 
> if (strspn(argv[optind == 0 ? 1 : optind], "-aefg") == 
> strlen(argv[optind == 0 ? 1 : optind])

OK. So if I understand you correctly, only the first value is really wrong but 
the optind will have the correct value for the further processing farther 
below. That was my main concern.

> 
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Idexx Roswell
> 235 Hembree Park Drive
> Roswell GA 30076
> Tel: (770)-510- ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
> 
> -Original Message-----
> From: Christian Mauderer 
> [mailto:christian.maude...@embedded-brains.de]
> Sent: Thursday, February 09, 2017 3:36 PM
> To: Kirspel, Kevin <kevin-kirs...@idexx.com>
> Cc: RTEMS Devel <devel@rtems.org>
> Subject: Re: [PATCH 7/9] Patching STTY command for use in RTEMS
> 
> Hello Kevin,
> 
> thanks for your work.
> 
> Out of curiosity: It seems that you are one of the first users of the new 
> porting process for user space applications (beneath Sebastian and me). Did 
> you encounter any problems that might be worth adding to the guide in 
> libbsd.txt?
> 
> Beneath that please see my remarks below.
> 
> Kind regards
> 
> Christian
> 
> - Ursprüngliche Mail -
>> Von: "Kevin Kirspel" <kevin-kirs...@idexx.com>
>> An: "RTEMS Devel" <devel@rtems.org>
>> Gesendet: Donnerstag, 9. Februar 2017 04:21:38
>> Betreff: [PATCH 7/9] Patching STTY command for use in RTEMS
> 
> [...]
>> diff --git a/freebsd/bin/stty/stty.c b/freebsd/bin/stty/stty.c old 
>> mode 100644 new mode 100755
> 
> You made the files executable. It would be better, if you could avoid that. 
> Please note that this is also true for a lot of other sources in your patches.
> 
>> index 54c63f6..3999a7f
>> --- a/freebsd/bin/stty/stty.c
>> +++ b/freebsd/bin/stty/stty.c
>> @@ -1,5 +1,8 @@
>> #include 
>>
>> +#ifdef __rtems__
>> +#include "rtems-bsd-stty-namespace.h"
>> +#endif /* __rtems__ */
>> /*-
>>  * Copyright (c) 1989, 1991, 1993, 1994
>>  *   The Regents of the University of California.  All rights reserved.
>> @@ -43,6 +46,12 @@ static char sccsid[] = "@(#)stty.c8.3 (Berkeley) 
>> 4/2/94";
>> #include 
>> __FBSDID("$FreeBSD$");
>>
>> +#ifdef __rtems__
>> +#define __need_getopt_newlib
>> +#include 
>> +#include  #include 
>> + #endif /* __rtems__ */
>> #include 
>>
>> #include 
>> @@ -57,20 +66,56 @@ __FBSDID("$FreeBSD$");
>>
>> #include "stty.h"
>> #include "extern.h"
>> +#ifdef __rtems__
>>

RE: [PATCH 7/9] Patching STTY command for use in RTEMS

2017-02-09 Thread Kirspel, Kevin

Before or after the "Build the libbsd without optimization." step, I would add 
a statement about fixing up any compilation errors.  Maybe most commands will 
compile after making the changes listed previously but I had to fixup errors 
related to termios differences between RTEMS and FREEBSD.  Besides that, the 
instructions were fine and I got the suspected output. 

I didn't realize the files were being changed to executables.  I edit the files 
from a windows application running over a Samba share.  I'll check and see if 
samba is making the change on save.

I will fix the tabs.  Sometimes I forget to change my editor settings for the 
different files I am working on.

There is an issue with the getopt_r() function.  Even if you initialize the 
optind value to 1 the getopt_r() function returns '?'.  So you get past the 
strspn() check but fail the getopt_r() call.  If you initialize the optind 
value to 0, you get the right return value but the optind is wrong for the 
strspn() call.  If you change the original code to the following, then it will 
also work:

if (strspn(argv[optind == 0 ? 1 : optind], "-aefg") == strlen(argv[optind == 0 
? 1 : optind])

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

-Original Message-
From: Christian Mauderer [mailto:christian.maude...@embedded-brains.de] 
Sent: Thursday, February 09, 2017 3:36 PM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>
Cc: RTEMS Devel <devel@rtems.org>
Subject: Re: [PATCH 7/9] Patching STTY command for use in RTEMS

Hello Kevin,

thanks for your work.

Out of curiosity: It seems that you are one of the first users of the new 
porting process for user space applications (beneath Sebastian and me). Did you 
encounter any problems that might be worth adding to the guide in libbsd.txt?

Beneath that please see my remarks below.

Kind regards

Christian

- Ursprüngliche Mail -----
> Von: "Kevin Kirspel" <kevin-kirs...@idexx.com>
> An: "RTEMS Devel" <devel@rtems.org>
> Gesendet: Donnerstag, 9. Februar 2017 04:21:38
> Betreff: [PATCH 7/9] Patching STTY command for use in RTEMS

[...]
> diff --git a/freebsd/bin/stty/stty.c b/freebsd/bin/stty/stty.c old 
> mode 100644 new mode 100755

You made the files executable. It would be better, if you could avoid that. 
Please note that this is also true for a lot of other sources in your patches.

> index 54c63f6..3999a7f
> --- a/freebsd/bin/stty/stty.c
> +++ b/freebsd/bin/stty/stty.c
> @@ -1,5 +1,8 @@
> #include 
> 
> +#ifdef __rtems__
> +#include "rtems-bsd-stty-namespace.h"
> +#endif /* __rtems__ */
> /*-
>  * Copyright (c) 1989, 1991, 1993, 1994
>  *The Regents of the University of California.  All rights reserved.
> @@ -43,6 +46,12 @@ static char sccsid[] = "@(#)stty.c 8.3 (Berkeley) 4/2/94";
> #include 
> __FBSDID("$FreeBSD$");
> 
> +#ifdef __rtems__
> +#define __need_getopt_newlib
> +#include 
> +#include  #include 
> + #endif /* __rtems__ */
> #include 
> 
> #include 
> @@ -57,20 +66,56 @@ __FBSDID("$FreeBSD$");
> 
> #include "stty.h"
> #include "extern.h"
> +#ifdef __rtems__
> +#include "rtems-bsd-stty-stty-data.h"
> +#endif /* __rtems__ */
> +
> +#ifdef __rtems__
> +static int main(int argc, char *argv[]);
> +
> +RTEMS_LINKER_RWSET(bsd_prog_stty, char);
> 
> int
> +rtems_bsd_command_stty(int argc, char *argv[]) {
> +  int exit_code;
> +  void *data_begin;
> +  size_t data_size;
> +
> +  data_begin = RTEMS_LINKER_SET_BEGIN(bsd_prog_stty);
> +  data_size = RTEMS_LINKER_SET_SIZE(bsd_prog_stty);
> +
> +  rtems_bsd_program_lock();
> +  exit_code = rtems_bsd_program_call_main_with_data_restore("stty",
> +  main, argc, argv, data_begin, data_size);  
> + rtems_bsd_program_unlock();
> +
> +  return exit_code;
> +}

In most (all?) places the libbsd uses BSD coding style. This is especially true 
for code that is inserted into existing BSD code. In this case that means one 
tab instead of two spaces. I also noted that on some of the other patches in 
the patch set.

> +#endif /* __rtems__ */
> +int
> main(int argc, char *argv[])
> {
>   struct info i;
>   enum FMT fmt;
>   int ch;
>   const char *file, *errstr = NULL;
> +#ifdef __rtems__
> + struct getopt_data getopt_data;
> + memset(_data, 0, sizeof(getopt_data)); #define optind 
> +getopt_data.optind #define optarg getopt_data.optarg #define opterr 
> +getopt_data.opterr #define optopt getopt_data.optopt #define 
> +getopt(argc, argv, opt) getopt_r(argc, argv, "+" opt, _data) 
> +#endif /* __rtems__ */
> 
>

RE: [PATCH 6/9] Adding USB serial driver test cases

2017-02-09 Thread Kirspel, Kevin

We could probably create a tty test driver and convert usbserialXX test cases 
into termiosXX test cases.  This would delink the two and we would only have 
the one usbserial test case.  

As far as the copyright, I can change it to whatever you want.  I based the 
test cases off Sebastian's test structure but I can make a generic RTEMs 
copyright if needed.

Has anyone had a chance to review the patches in ticket #2897?  A lot of the 
FREEBSD driver porting related to the tty kernel drivers could be made easier 
with those patches.  There was one other termios difference that I encountered 
during testing.  In the RTEMS tcflush() function,  the following call is made

ioctl( fd, RTEMS_IO_TCFLUSH, (intptr_t) queue );

The queue integer is cast to a point instead of being passed by reference.  
FREEBSD termios expects this variable to be passed by reference.

One other area that would reduce the porting is support for IO_NDELAY.  If we 
added "#define IO_NDELAY O_NONBLOCK" somewhere (maybe vnode.h) then all checks 
for IO_NDELAY would default to O_NONBLOCK which is what RTEMS uses.

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Chris Johns
Sent: Wednesday, February 08, 2017 10:35 PM
To: devel@rtems.org
Subject: Re: [PATCH 6/9] Adding USB serial driver test cases

On 09/02/2017 14:21, Kevin Kirspel wrote:
> ---
>  .../include/rtems/bsd/test/default-usb-init.h  | 158 +
>  testsuite/usbserial/init.c | 373 
>  testsuite/usbserial01/test_main.c  | 666 
> +
>  testsuite/usbserial02/test_main.c  | 252 
>  testsuite/usbserial03/test_main.c  | 240 
>  testsuite/usbserial04/test_main.c  | 226 +++
>  testsuite/usbserial05/test_main.c  | 303 ++
>  testsuite/usbserial06/test_main.c  | 218 +++
>  8 files changed, 2436 insertions(+)
>  create mode 100755 
> testsuite/include/rtems/bsd/test/default-usb-init.h
>  create mode 100755 testsuite/usbserial/init.c  create mode 100755 
> testsuite/usbserial01/test_main.c  create mode 100755 
> testsuite/usbserial02/test_main.c  create mode 100755 
> testsuite/usbserial03/test_main.c  create mode 100755 
> testsuite/usbserial04/test_main.c  create mode 100755 
> testsuite/usbserial05/test_main.c  create mode 100755 
> testsuite/usbserial06/test_main.c

Can the new termios support in FreeBSD be tested without needing USB serial 
support? In other words, is a separate test for termios possible and does it 
make sense?

My concern is the basic termios functionality being added is not tested without 
having USB serial support which links both parts.

> +++ b/testsuite/usbserial/init.c
> @@ -0,0 +1,373 @@
> +/*
> + * Copyright (c) 2010, 2016 embedded brains GmbH.  All rights reserved.
> + *
> + *  embedded brains GmbH
> + *  Dornierstr. 4
> + *  82178 Puchheim
> + *  Germany
> + *  

Is this copyright ok?

I see other places in other patches where this is happening.

Chris
___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwICAg=2do6VJGs3LvEOe4OFFM1bA=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI=cUXCUWnjZb0licBQJbKQXcG2j908Ybve96No5C9F9VE=AmSikyKf2BohEKOK8W8d2L2j3NCkav0ECII8hlLwTSQ=

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

RE: Regarding running one test

2017-02-04 Thread Kirspel, Kevin

I use the rtems tester.  
ftp://ftp.rtems.org/pub/rtems/people/chrisj/rtems-tester/rtems-tester.html

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Tanu Hari Dixit
Sent: Saturday, February 04, 2017 12:23 AM
To: rtems-de...@rtems.org 
Subject: Regarding running one test

Hello all,

How do I run a single test from the testsuites? I want to run one test from the 
rtems/testsuites/fstests. How do I go about doing that?

Regards,
Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DwICAg=2do6VJGs3LvEOe4OFFM1bA=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74=zH4W9XS8-wD5iyDXdo5SEtjZwr3gbIp9TJjx8-z2cS8=mU8IyO6GG8v94eNhQoI76FuuhiadOCFEoiJ3HdxyrrQ=
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Ticket #2897

2017-02-02 Thread Kirspel, Kevin

I have created a ticket to update TERMIOS to include support for LIBBSD.  The 
changes will allow the TTY driver in LIBBSD to work with few modifications.  I 
am almost done with a LIBBSD port for the USB serial driver stack.  This port 
requires the use of LIBBSD's TTY kernel driver and the current port has a lot 
of "#ifndef __rtems__" guards for fixing up difference between RTEMS termios 
and LIBBSD termios.  All the legacy RTEMS termios features are present except 
for the storage of the input and output baud rates (thus the need to fixup a 
lot of BSPs).  Please review the patch and test it on as many BSPs as possible.

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

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

Build error on rtems master

2017-02-02 Thread Kirspel, Kevin

I'm getting a build error with the latest master due to the changes removing 
CONFIGURE_SMP_APPLICATION.  The default-configuration.c file sets 
CONFIGURE_SMP_MAXIMUM_PROCESSORS to 32 thus enabling the internal 
_CONFIGURE_SMP_APPLICATION define on targets without SMP.  I had to add a

#if defined(RTEMS_SMP)

guard around

#if CONFIGURE_SMP_MAXIMUM_PROCESSORS > 1
  #define _CONFIGURE_SMP_APPLICATION
#endif

to get it to compile.  I was building for the xilinx_zynq_a9_qemu BSP.

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

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

RE: [PATCH 2/8] Adding LPC32XX USB OHCI support

2017-01-30 Thread Kirspel, Kevin

It probably does but here is my reasoning for a new file.

1. The latest FREEBSD master has support for the lpc32xx where the 9.2 branch 
did not.  It's easy to port the already existing code (i.e. MAC driver, OHCI, 
MMC, etc...).
2. The ohci_lpc.c driver was not using FREEBSD's bus resources which was 
different from other drivers.
3. The logic to probe, attach, detach, suspend, and resume was taken from the 
ohci_lpc.c driver but used the hardware access functions provided by the latest 
FREEBSD.  

Logically the drivers are the same but the lpc_ohci.c driver uses the FREEBSD 
LPC interface (with the caveat of the "struct usb_otg_transceiver" interface).  

Ideally the LPC USB OTG I2C code should be moved to an I2C driver.  An USB OTG 
transceiver driver should be created to probe for the ISP1301/STOTG04E devices. 
 However, I did not go to this level. 

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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, January 30, 2017 1:49 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 2/8] Adding LPC32XX USB OHCI support

We already have an

rtemsbsd/sys/dev/usb/controller/ohci_lpc.c

it used to work with the LPC3200.

On 27/01/17 06:32, Kevin Kirspel wrote:
> ---
>   rtemsbsd/sys/dev/usb/controller/lpc_ohci.c | 495 
> +
>   1 file changed, 495 insertions(+)
>   create mode 100755 rtemsbsd/sys/dev/usb/controller/lpc_ohci.c

-- 
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.

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

RE: [PATCH 1/2] Adding ARM VFP V2 support

2017-01-24 Thread Kirspel, Kevin

I can create a new patch without this.  It was just there to fully support the 
capabilities of the VFP.  I don't enable the fast math option in my BSP but I 
didn't know if it was useful for someone else.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Tuesday, January 24, 2017 1:16 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 1/2] Adding ARM VFP V2 support

In this case the FPU is no longer in full-compliance with EEE 754. I don't 
think this should be set by the startup code depending on some BSP optimization 
options. I guess the paranoia test fails if you enable this.

On 23/01/17 15:43, Kirspel, Kevin wrote:
> Yes
>
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Idexx Roswell
> 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, January 23, 2017 9:37 AM
> To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
> Subject: Re: [PATCH 1/2] Adding ARM VFP V2 support
>
>
>
> On 23/01/17 14:51, Kevin Kirspel wrote:
>> +#ifdef __FAST_MATH__
>> +/* Enable Fast FPU options */
>> +mov r0, #(3 << 24)
>> +vmsr FPSCR, r0
>> +#endif
> This define is related to the GCC fast-math optimization option.
>

--
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.

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

RE: [PATCH 1/2] Adding ARM VFP V2 support

2017-01-23 Thread Kirspel, Kevin

Yes

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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, January 23, 2017 9:37 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 1/2] Adding ARM VFP V2 support



On 23/01/17 14:51, Kevin Kirspel wrote:
> +#ifdef __FAST_MATH__
> + /* Enable Fast FPU options */
> + mov r0, #(3 << 24)
> + vmsr FPSCR, r0
> +#endif

This define is related to the GCC fast-math optimization option.

-- 
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.

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

RE: [PATCH 1/7] Adding pipe support

2016-12-20 Thread Kirspel, Kevin

I finally got back to this.  I complied the Xilinx BSP, compiled the latest 
LIBBSD with the patch, and installed QEMU.  I got the output below.  After you 
applied the patch, did you run "./freebsd-to-rtems.py -R" and " 
./freebsd-to-rtems.py".  If not, then the test will use the RTEMS pipe 
implementation instead of LIBBSD.  This is because the libbsd_waf.py file is 
not updated until after the " ./freebsd-to-rtems.py" script.  Maybe I 
misinterpreted the instructions in libbsd.txt, but it states not to commit 
changes from libbsd_waf.py so they were not in the patch files.

qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic 
-M xilinx-zynq-a9 -m 256M -kernel 
build/arm-rtems4.12-xilinx_zynq_a9_qemu/selectpollkqueue01.exe
Warning: nic cadence_gem.0 has no peer
Warning: nic cadence_gem.1 has no peer
*** LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST ***
nexus0: 
test select timeout
test select connect
worker: create new connect socket
worker: connect
test select read
worker: write
test select write
worker: read
test select close
worker: close
test poll timeout
test poll connect
worker: create new connect socket
worker: connect
test poll read
worker: write
test poll write
worker: read
test poll close
worker: close
test kqueue timer
test kqueue timer
test kqueue connect
worker: create new connect socket
worker: connect
test kqueue read
worker: write
test kqueue write
worker: read
test kqueue close
worker: shutdown
test kqueue user
test pipe timeout
test pipe read
worker: write
test pipe write
worker: read
test pipe close
worker: close pipe
Stack usage by thread
ID  NAMELOW  HIGH CURRENT AVAILABLE USED
0x09010001  IDLE 0x124250 - 0x12524f 0x125108  4080444
0x0a010001  UI1  0x1254b0 - 0x12d4af 0x12d138 32752   4224
0x0a010002  TIME 0x12dc08 - 0x135c07 0x135b00 32752564
0x0a010003  IRQS 0x135c10 - 0x13dc0f 0x13db10 32752556
0x0a010004  _BSD 0x1501c8 - 0x1581c7 0x1580d0 32752   1284
0x0a010005  _BSD 0x158318 - 0x160317 0x160220 32752700
0x0a010006  _BSD 0x161430 - 0x16942f 0x169338 32752548
0x0a010007  _BSD 0x1694f0 - 0x1714ef 0x171418 32752516
0x0a010008  _BSD 0x171688 - 0x179687 0x179590 32752548
0x0a010009  _BSD 0x179748 - 0x181747 0x181670 32752516
0x0a01000a  WORK 0x1a06c8 - 0x1a16c7 0x1a1568  4080   1020
*** END OF TEST LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 ***

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Thursday, December 15, 2016 3:52 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 1/7] Adding pipe support

Hello Kevin,

looks good so far (except one white space change, which I will fix for you, 
white space changes may lead to merge conflicts during a FreeBSD update). 
However, the "LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST" fails:

qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic 
-M xilinx-zynq-a9 -m 256M -kernel 
build/arm-rtems4.12-xilinx_zynq_a9_qemu/selectpollkqueue01.exe
Warning: nic cadence_gem.0 has no peer
Warning: nic cadence_gem.1 has no peer
*** LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST ***
nexus0: 
test select timeout
test select connect
worker: create new connect socket
worker: connect
test select read
worker: write
test select write
worker: read
test select close
worker: close
test poll timeout
test poll connect
worker: create new connect socket
worker: connect
test poll read
worker: write
test poll write
worker: read
test poll close
worker: close
test kqueue timer
test kqueue timer
test kqueue connect
worker: create new connect socket
worker: connect
test kqueue read
worker: write
test kqueue write
worker: read
test kqueue close
worker: shutdown
test kqueue user
test pipe timeout
assertion "rv == 0" failed: file
"../../testsuite/selectpollkqueue01/test_main.c", line 1057, function: 
test_pipe_timeout

--
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.

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

RE: [PATCH 1/7] Adding pipe support

2016-12-15 Thread Kirspel, Kevin

Let me take a look when running it with QEMU.  I ran it against my custom 
LPC3250 BSP on real hardware.  Perhaps there is something else that needs to be 
done to support pipe than just the patches I submitted.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
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: Thursday, December 15, 2016 3:52 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 1/7] Adding pipe support

Hello Kevin,

looks good so far (except one white space change, which I will fix for you, 
white space changes may lead to merge conflicts during a FreeBSD update). 
However, the "LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST" fails:

qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic 
-M xilinx-zynq-a9 -m 256M -kernel 
build/arm-rtems4.12-xilinx_zynq_a9_qemu/selectpollkqueue01.exe
Warning: nic cadence_gem.0 has no peer
Warning: nic cadence_gem.1 has no peer
*** LIBBSD SELECT AND POLL AND KQUEUE AND PIPE 1 TEST ***
nexus0: 
test select timeout
test select connect
worker: create new connect socket
worker: connect
test select read
worker: write
test select write
worker: read
test select close
worker: close
test poll timeout
test poll connect
worker: create new connect socket
worker: connect
test poll read
worker: write
test poll write
worker: read
test poll close
worker: close
test kqueue timer
test kqueue timer
test kqueue connect
worker: create new connect socket
worker: connect
test kqueue read
worker: write
test kqueue write
worker: read
test kqueue close
worker: shutdown
test kqueue user
test pipe timeout
assertion "rv == 0" failed: file
"../../testsuite/selectpollkqueue01/test_main.c", line 1057, function: 
test_pipe_timeout

--
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.

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

RE: QT 5.8 Port

2016-12-09 Thread Kirspel, Kevin

LIBBSD has the poll() functionality.  In order for the pipe to be polled then 
it needs functionality that is only found in LIBBSD.  I started off using the 
pipe in the RTEMS tree.  I even added the poll handler to return the correct 
revents.  The problem was that the RTEMS pipe poll handler needs to call a 
function in LIBBSD (selrecord) so that it can work with poll().

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

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber
Sent: Friday, December 09, 2016 3:44 AM
To: devel@rtems.org
Subject: Re: QT 5.8 Port

Hello Kevin,

we already have a (broken) pipe support in RTEMS

https://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems_tree_cpukit_libcsupport_src_pipe.c=DgIF-g=2do6VJGs3LvEOe4OFFM1bA=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI=JsBiBqByZuuh7FFKuLujX-9gC7BaNG4-3Xa1ytmRgcA=kS0AINMLfVS4Eoot_vf4iYhQwj3ENj3xMIyrqerJfIc=
 

What is the befit of using the FreeBSD pipe implementation?

On 07/12/16 19:49, Kirspel, Kevin wrote:
>
> I'm porting QT 5.8 to RTEMS 4.12 and rtems-libbsd.  I had to add pipe 
> support to rtems-libbsd.  I would like to submit the pipe patch but 
> the "git diff" is long due to the fact that the diff includes the 
> entire file contents of the modified sys_pipe.c and pipe.h files.  How 
> do you usually submit patches for review for rtems-libbsd?
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_ma
> ilman_listinfo_devel=DgIF-g=2do6VJGs3LvEOe4OFFM1bA=dbavT-WIJ4nBf
> QFKYnKdAD52Vyq3ZXSzrL9TAm21lZI=JsBiBqByZuuh7FFKuLujX-9gC7BaNG4-3Xa1y
> tmRgcA=DmB5g2XWSfm8YAS-McegW2BaDcYR_4LLkQkY5liYzKI=

--
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.

___
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel=DgIF-g=2do6VJGs3LvEOe4OFFM1bA=dbavT-WIJ4nBfQFKYnKdAD52Vyq3ZXSzrL9TAm21lZI=JsBiBqByZuuh7FFKuLujX-9gC7BaNG4-3Xa1ytmRgcA=DmB5g2XWSfm8YAS-McegW2BaDcYR_4LLkQkY5liYzKI=
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS LIBBSD Pipe Support

2016-12-09 Thread Kirspel, Kevin

The attached patch pulls in FreeBSDs pipe functionality into RTEMS LIBBSD.

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



rtems-libbsd-pipe-submit.diff
Description: rtems-libbsd-pipe-submit.diff
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: QT 5.8 Port

2016-12-07 Thread Kirspel, Kevin

It's because it is a new file as far as the rtems-libbsd/freebsd/ git tree is 
concerned. I did a "git add" on the new pipe files.

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

From: Jennifer Averett [mailto:jennifer.aver...@oarcorp.com]
Sent: Wednesday, December 07, 2016 1:56 PM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>
Subject: RE: QT 5.8 Port

Just a guess but you have probably converted the file to dos format thus the 
entire file looks different
run dos2unix on the file then try the diff.

Jennifer Averett
On-Line Applications Research


From: devel [devel-boun...@rtems.org] On Behalf Of Kirspel, Kevin 
[kevin-kirs...@idexx.com]
Sent: Wednesday, December 07, 2016 12:49 PM
To: devel@rtems.org<mailto:devel@rtems.org>
Subject: QT 5.8 Port
I'm porting QT 5.8 to RTEMS 4.12 and rtems-libbsd.  I had to add pipe support 
to rtems-libbsd.  I would like to submit the pipe patch but the "git diff" is 
long due to the fact that the diff includes the entire file contents of the 
modified sys_pipe.c and pipe.h files.  How do you usually submit patches for 
review for rtems-libbsd?

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

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

QT 5.8 Port

2016-12-07 Thread Kirspel, Kevin

I'm porting QT 5.8 to RTEMS 4.12 and rtems-libbsd.  I had to add pipe support 
to rtems-libbsd.  I would like to submit the pipe patch but the "git diff" is 
long due to the fact that the diff includes the entire file contents of the 
modified sys_pipe.c and pipe.h files.  How do you usually submit patches for 
review for rtems-libbsd?

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

___
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

[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

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 <kevin-kirs...@idexx.com>; 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 <kevin-kirs...@idexx.com>; 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

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 <kevin-kirs...@idexx.com>; 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 <kevin-kirs...@idexx.com>; 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

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

2016-08-19 Thread Kirspel, Kevin

The Coprocessor access control register is not VFP dependent.  Processors 
either have one or not (V5TEJ does not).  The VFP run fast option in the FPSCR 
may be unique to each VFP version (I'm not sure).  For now, we could introduce 
defines such as the following to distinguish between the different VFP versions 
and features.

ARM_MULTILIB_VFPV2_D16
ARM_MULTILIB_VFPV3_D16
ARM_MULTILIB_VFPV3_D32
ARM_MULTILIB_VFPV4_D16
ARM_MULTILIB_VFPV4_D32
ARM_MULTILIB_VFPV5_D16
ARM_MULTILIB_NEON

#if defined(ARM_MULTILIB_VFPV2_D16) \
  || defined(ARM_MULTILIB_VFPV3_D16) \
  || defined(ARM_MULTILIB_VFPV3_D32) \
  || defined(ARM_MULTILIB_VFPV4_D16) \
  || defined(ARM_MULTILIB_VFPV4_D32) \
  || defined(ARM_MULTILIB_VFPV5_D16) \
  || defined(ARM_MULTILIB_ NEON)
  #define ARM_MULTILIB_VFP
#endif

#if defined(ARM_MULTILIB_VFPV2_D16)
  #define ARM_MULTILIB_VFP_RUN_FAST
#endif

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 1:42 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 2/2] RTEMS changes for lpc32xx VFP support



On 19/08/16 02:16, Kirspel, Kevin wrote:
>
> 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..1d478ce
>
> --- 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=softfp
>
>  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..cb3bff7
>
> --- 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
>
> +#ifndef ARM_MULTILIB_ARCH_V5TEJ
>

I think a multilib define reflecting the VFP feature set would be better 
instead of this ARM_MULTILIB_ARCH_V5TEJ.

>/* 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 ARM_MULTILIB_ARCH_V5TEJ
>
> + /* Enable FPU Run Fast*/
>
> + 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
>
> +#ifndef ARM_MULTILIB_ARCH_V5TEJ
>
>/*
>
> * 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/arm-context-validate.S
> b/cpukit/score/cpu/arm/arm-context-validate.S
>
> old mode 100644
>
> new mode 100755
>
> index fdfb6c1..6485993
>
> --- a/cpukit/score/cpu/arm/arm-context-validate.S
>
> +++ b/cpukit/score/cpu/arm/arm-context-validate.S
>
> @@ -46,7 +46,11 @@
>
> .section .text
>
> +#ifdef __thumb__
>
> FUNCTION_THUMB_ENTRY(_CPU_Context_validate)
>
> +#else
>
> +FUNCTION_ENTRY(_CPU_Context_validate)
>
> +#endif
>

I checked in a slightly modified version for the VFP context validation.

--
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.

___
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-19 Thread Kirspel, Kevin

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.

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 1:22 AM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; devel@rtems.org
Subject: Re: [PATCH 1/2] RTEMS Source Builder changes for lpc32xx VFP support



On 19/08/16 02:11, Kirspel, Kevin wrote:
>
> 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..d2f0bfd 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-16 
> 11:42:02.727219302 -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/mfloat-abi=softfp
>
> ++MULTILIB_DIRNAMES = eb thumb armv6-m armv7-a armv7-r armv7-m 
> cortex-m7 neon vfp vfpv3-d16 fpv4-sp-d16 fpv5-d16 hard softfp
>
> +
>
> + # 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=softfp
>

Why do you want to use the softfp ABI?

-- 
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.

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

lpc32xx and rtems-libbsd

2016-08-18 Thread Kirspel, Kevin

I have created a libbsd port for a modified version of the lpc32xx BSP.  The 
lpc code from FREEBSD 10 was backported to FREEBSD 9.3 because FREEBSD 9.3 did 
not support ARM LPC processors.  I ran into some issues that I would like to 
run by the group.

Issue 1 - the order of declared modules in nexus-devices.h does not guarantee 
that they will come up in that order on boot up.

a.   The lpc code consists of multiple modules that need to be instantiated 
in a particular order.  When running the libbsd testsuite (mainly dhcp01 and 
usb01), the boot up order of the modules was different for each test.  In one 
case it was OK but the other was not.

b.   To have some control over the ordering, I added order support to 
RTEMS_BSD_DEFINE_NEXUS_DEVICE (RTEMS_BSD_DEFINE_NEXUS_DEVICE_ORDERED). This is 
modeled off of what FREEBSD does for DRIVER_MODULE (DRIVER_MODULE_ORDERED).   A 
small change to rtems-kernel-nexus.c was needed to support this.

Issue 2 - rtems_bsd_get_mac_address() , rtems_bsd_get_task_priority(), and 
rtems_bsd_get_task_stack_size() are application dependent.  Are we against 
creating a configuration structure to initialize these things before 
rtems_bsd_initialize() is called?  At a bare minimum, the RTEMS BSP could set 
some variables used by libbsd.

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2016-08-18 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..1d478ce
--- 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=softfp
 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..cb3bff7
--- 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
+#ifndef ARM_MULTILIB_ARCH_V5TEJ
   /* 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 ARM_MULTILIB_ARCH_V5TEJ
+ /* Enable FPU Run Fast*/
+ 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
+#ifndef ARM_MULTILIB_ARCH_V5TEJ
   /*
* 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/arm-context-validate.S 
b/cpukit/score/cpu/arm/arm-context-validate.S
old mode 100644
new mode 100755
index fdfb6c1..6485993
--- a/cpukit/score/cpu/arm/arm-context-validate.S
+++ b/cpukit/score/cpu/arm/arm-context-validate.S
@@ -46,7 +46,11 @@
.section .text
+#ifdef __thumb__
FUNCTION_THUMB_ENTRY(_CPU_Context_validate)
+#else
+FUNCTION_ENTRY(_CPU_Context_validate)
+#endif
/* Save */
@@ -99,12 +103,16 @@ FUNCTION_THUMB_ENTRY(_CPU_Context_validate)
#ifdef ARM_MULTILIB_VFP
   /* R3 contains the FPSCR */
   vmrs  r3, FPSCR
+#ifdef ARM_MULTILIB_ARCH_V5TEJ
+ ldr  r4, =0xf01f
+#else
   movs r4, #0x001f
#ifdef ARM_MULTILIB_ARCH_V7M
   movt r4, #0xf000
#else
   movt r4, #0xf800
#endif
+#endif
   bic  r3, r3, r4
   andr4, r4, r0
   orr  r3, r3, r4
diff --git a/cpukit/score/cpu/arm/arm-context-volatile-clobber.S 
b/cpukit/score/cpu/arm/arm-context-volatile-clobber.S
old mode 100644
new mode 100755
index 7970b8e..cf3f428
--- a/cpukit/score/cpu/arm/arm-context-volatile-clobber.S
+++ b/cpukit/score/cpu/arm/arm-context-volatile-clobber.S
@@ -20,7 +20,11 @@
.section .text
+#ifdef __thumb__
FUNCTION_THUMB_ENTRY(_CPU_Context_volatile_clobber)
+#else
+FUNCTION_ENTRY(_CPU_Context_volatile_clobber)
+#endif
 .macro clobber_register reg
   sub r0, r0, #1
@@ -29,8 +33,12 @@ FUNCTION_THUMB_ENTRY(_CPU_Context_volatile_clobber)
 #ifdef ARM_MULTILIB_VFP
   vmrs  r1, FPSCR
+#ifdef ARM_MULTILIB_ARCH_V5TEJ
+ ldr  r2, =0xf81f
+#else
   movs r2, #0x001f
   movt r2, #0xf800
+#endif
   bic  r1, r1, r2
   andr2, r2, r0
   orr  r1, r1, r2
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..929585e
--- a/cpukit/score/cpu/arm/rtems/score/arm.h
+++ b/cpukit/score/cpu/arm/rtems/score/arm.h
@@ -35,6 +35,10 @@ extern "C" {
#elif defined(__ARM_ARCH_6M__)
   #define CPU_MODEL_NAME "ARMv6M"
   #define ARM_MULTILIB_ARCH_V6M
+#elif defined(__ARM_ARCH_5TEJ__)
+  #define CPU_MODEL_NAME "ARMv5TEJ"
+  #define ARM_MULTILIB_ARCH_V5TEJ
+  #define ARM_MULTILIB_ARCH_V4
#else
   #define CPU_MODEL_NAME "ARMv4"
   #define ARM_MULTILIB_ARCH_V4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2016-08-18 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..6c553e6
--- 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 
cd47a1e44351d63dd848b2170f1fdd1106a1fb1ed4d0680fd86ef599f81aa421635030c5235d6b044143286207fc34094245fdb4a85d78db83e3a5f965f735a3
 %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..d2f0bfd 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-16 11:42:02.727219302 
-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/mfloat-abi=softfp
++MULTILIB_DIRNAMES = eb thumb armv6-m armv7-a armv7-r armv7-m cortex-m7 neon 
vfp vfpv3-d16 fpv4-sp-d16 fpv5-d16 hard softfp
+
+ # 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=softfp
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: VFP support for lpc32xx

2016-08-18 Thread Kirspel, Kevin

After some finagling, I was successful using the RTEMS tester, GDB, and an ARM 
Jlink JTAG cable to run the sptests under the testsuite.  I passed all but 8.  
3 of the tests actually passed but have some issues with the test cases or 
output parser.  The 5 remaining failures should have nothing to do with the VFP 
additions so I’m pretty confident it is fine.  I’ll post the patches for 
review.  They are pretty minor.

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

From: Joel Sherrill [mailto:joel.sherr...@gmail.com]
Sent: Wednesday, August 17, 2016 3:06 PM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; Chris Johns <chr...@rtems.org>
Cc: devel@rtems.org
Subject: Re: VFP support for lpc32xx



On Wed, Aug 17, 2016 at 2:04 PM, Kirspel, Kevin 
<kevin-kirs...@idexx.com<mailto:kevin-kirs...@idexx.com>> wrote:
I have a patch for the RTEMS source builder as well as RTEMS itself to support 
the VFP on the lpc32xx.  I don’t have hardware the matches the lpc32xx BSP but 
I do have some custom hardware that I can run the test suite on.  Can you point 
me to some documentation that tells you how to automate the running of the test 
suite?


If you have JTAG on your HW, the rtems-tester in rtems-tools has setup to run
tests on Zynq automated using gdb and JTAG.

Chris Johns should speak up.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Opti Medical
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642<tel:%28770%29-510-%20ext.%2081642>
Direct: (770)-688-1642<tel:%28770%29-688-1642>
Fax: (770)-510-4445<tel:%28770%29-510-4445>


___
devel mailing list
devel@rtems.org<mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel

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

RE: VFP support for lpc32xx

2016-08-17 Thread Kirspel, Kevin

I do.  I’ll try it out.

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

From: Joel Sherrill [mailto:joel.sherr...@gmail.com]
Sent: Wednesday, August 17, 2016 3:06 PM
To: Kirspel, Kevin <kevin-kirs...@idexx.com>; Chris Johns <chr...@rtems.org>
Cc: devel@rtems.org
Subject: Re: VFP support for lpc32xx



On Wed, Aug 17, 2016 at 2:04 PM, Kirspel, Kevin 
<kevin-kirs...@idexx.com<mailto:kevin-kirs...@idexx.com>> wrote:
I have a patch for the RTEMS source builder as well as RTEMS itself to support 
the VFP on the lpc32xx.  I don’t have hardware the matches the lpc32xx BSP but 
I do have some custom hardware that I can run the test suite on.  Can you point 
me to some documentation that tells you how to automate the running of the test 
suite?


If you have JTAG on your HW, the rtems-tester in rtems-tools has setup to run
tests on Zynq automated using gdb and JTAG.

Chris Johns should speak up.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Opti Medical
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642<tel:%28770%29-510-%20ext.%2081642>
Direct: (770)-688-1642<tel:%28770%29-688-1642>
Fax: (770)-510-4445<tel:%28770%29-510-4445>


___
devel mailing list
devel@rtems.org<mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel

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

VFP support for lpc32xx

2016-08-17 Thread Kirspel, Kevin

I have a patch for the RTEMS source builder as well as RTEMS itself to support 
the VFP on the lpc32xx.  I don't have hardware the matches the lpc32xx BSP but 
I do have some custom hardware that I can run the test suite on.  Can you point 
me to some documentation that tells you how to automate the running of the test 
suite?

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

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

57 matches

Mail list logo