date:20200312

Thanks. Pushed.

On Thu, Mar 12, 2020 at 6:46 PM Chris Johns  wrote:

> Looks good to me. Please push. Thank you for stepping up to this task.
>
> Chris
>
> On 13/3/20 8:00 am, Joel Sherrill wrote:
> > ---
> >  bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
> b/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
> > index 849c5ec..ce6136a 100644
> > --- a/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
> > +++ b/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
> > @@ -43,4 +43,5 @@ exclude: spstkalloc02
> >  exclude: sptls02
> >  exclude: syscall01
> >  exclude: telnetd01
> > +exclude: ttest01
> >  exclude: utf8proc01
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] lm3s3749-testsuite.tcfg: Add ttest01

2020-03-12 Thread Chris Johns

Looks good to me. Please push. Thank you for stepping up to this task.

Chris

On 13/3/20 8:00 am, Joel Sherrill wrote:
> ---
>  bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg 
> b/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
> index 849c5ec..ce6136a 100644
> --- a/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
> +++ b/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
> @@ -43,4 +43,5 @@ exclude: spstkalloc02
>  exclude: sptls02
>  exclude: syscall01
>  exclude: telnetd01
> +exclude: ttest01
>  exclude: utf8proc01
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 5/5] mrm332-testsuite.tcfg: Add dl01

---
 bsps/m68k/mrm332/config/mrm332-testsuite.tcfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/m68k/mrm332/config/mrm332-testsuite.tcfg 
b/bsps/m68k/mrm332/config/mrm332-testsuite.tcfg
index 624b1d9..936f926 100644
--- a/bsps/m68k/mrm332/config/mrm332-testsuite.tcfg
+++ b/bsps/m68k/mrm332/config/mrm332-testsuite.tcfg
@@ -7,6 +7,7 @@
 include: testdata/disable-iconv-tests.tcfg
 exclude: cdtest
 exclude: dl05
+exclude: dl10
 exclude: fileio
 exclude: fsdosfsname01
 exclude: iostream
-- 
1.8.3.1

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

[PATCH 2/5] lpc2362-testsuite.tcfg: Add ttest01

---
 bsps/arm/lpc24xx/config/lpc2362-testsuite.tcfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/arm/lpc24xx/config/lpc2362-testsuite.tcfg 
b/bsps/arm/lpc24xx/config/lpc2362-testsuite.tcfg
index 294e1ff..bd972f9 100644
--- a/bsps/arm/lpc24xx/config/lpc2362-testsuite.tcfg
+++ b/bsps/arm/lpc24xx/config/lpc2362-testsuite.tcfg
@@ -54,6 +54,7 @@ exclude: telnetd01
 exclude: tmcontext01
 exclude: tmfine01
 exclude: top
+exclude: ttest01
 exclude: utf8proc01
 
 
-- 
1.8.3.1

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

[PATCH 1/5] lm3s3749-testsuite.tcfg: Add ttest01

---
 bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg 
b/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
index 849c5ec..ce6136a 100644
--- a/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
+++ b/bsps/arm/lm3s69xx/config/lm3s3749-testsuite.tcfg
@@ -43,4 +43,5 @@ exclude: spstkalloc02
 exclude: sptls02
 exclude: syscall01
 exclude: telnetd01
+exclude: ttest01
 exclude: utf8proc01
-- 
1.8.3.1

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

[PATCH 4/5] rtl22xx-testsuite.tcfg: Add dl10 and ttest01

---
 bsps/arm/rtl22xx/config/rtl22xx-testsuite.tcfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bsps/arm/rtl22xx/config/rtl22xx-testsuite.tcfg 
b/bsps/arm/rtl22xx/config/rtl22xx-testsuite.tcfg
index 6c25615..f1f16e6 100644
--- a/bsps/arm/rtl22xx/config/rtl22xx-testsuite.tcfg
+++ b/bsps/arm/rtl22xx/config/rtl22xx-testsuite.tcfg
@@ -5,9 +5,11 @@
 #
 
 include: testdata/disable-iconv-tests.tcfg
+exclude: dl10
 exclude: fileio
 exclude: fsdosfsname01
 exclude: linpack
 exclude: iostream
 exclude: rtems++
+exclude: ttest01
 exclude: utf8proc01
-- 
1.8.3.1

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

[PATCH 3/5] lpc23xx_tli800-testsuite.tcfg: Add ttest01

---
 bsps/arm/lpc24xx/config/lpc23xx_tli800-testsuite.tcfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/arm/lpc24xx/config/lpc23xx_tli800-testsuite.tcfg 
b/bsps/arm/lpc24xx/config/lpc23xx_tli800-testsuite.tcfg
index 42630c5..d75ad36 100644
--- a/bsps/arm/lpc24xx/config/lpc23xx_tli800-testsuite.tcfg
+++ b/bsps/arm/lpc24xx/config/lpc23xx_tli800-testsuite.tcfg
@@ -65,5 +65,6 @@ exclude: termios
 exclude: tmcontext01
 exclude: tmfine01
 exclude: top
+exclude: ttest01
 exclude: utf8proc01
 
-- 
1.8.3.1

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

Issues when adding a multi-port PCI serial card

2020-03-12 Thread Peter Dufault

I've added an 8-port RS232 PCI Mezzanine Card to the "beatnik" BSP.  The 
console (aka serial port) code is confusing.

I decided I should use what is in "bsp/console-termios.h"  as opposed to the 
"legacy console" approach, *even though* "legacy console" is used in many 
recent BSPS.

* Is that correct?

That approach went well, I created a replacement shared PowerPC console in 
"bsps/powerpc/shared/console/console-config.c" with only 129 lines of code and 
half of it comments.

Where does the driver go:  Next I had to add the PCI multi-port serial card 
driver.  I put it in "bsps/shared/dev/pci/mp_serial.c".  The other directory 
choice was "bsps/shared/dev/serial".  I didn't like either, the "dev/pci" is 
very associated with PCI discovery and the "dev/serial" is very associated with 
the generic low-level serial driver support, even thought it has the 
"legacy-console" cruft in it.

* Where should it go?

Difficulty in assigning common TTY names: Since my new shared PowerPC 
"console-config.c" created "/dev/ttyS0" and "/dev/ttyS1" I wanted to name the 
new serial devices with a number that started at 2, i.e., "/dev/ttyS2".

* Is there a way in the "console-termios" framework to know what the highest 
"minor number" for a serial port is?  I searched, gave up, and made it a 
configuration item.

Next I had to figure out the best way to probe and discover the board.

* I wanted to add an RTEMS_SYSINIT_ITEM that would call a probe routine to 
discover the multiport cards at the appropriate time, after "/dev/console" was 
discovered but before I wanted to spawn my shell.  I had trouble figuring out 
what level and order I should use for the probe routine.  I never got this 
working, my probe routine kept getting called much later then I expected it to. 
 I need a pointer to the documentation to RTEMS_SYSINIT_ITEM ordering.

Finally, after initial successful loop-back testing, I tried to start an RTEMS 
shell on one of the new ports.

*Here I'm trying hard to avoid all-caps because this took the most time of all 
(it should have been easiest), and I gave up!*

* HOW (sorry) do you spawn a shell on a serial port?  The documentation, at 
https://docs.rtems.org/branches/master/shell/configuration_and_init.html that 
suggests just setting the shell device name to "/dev/console", or in my case 
"/dev/ttyS9", is incorrect.  The shell startup is intent on using "stdin" and 
"stdout".
~   





   

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

Re: [PATCH v1] include sys/types.h to include defination of clockid_t

Got it, thanks
pthread.h has time.h included in it
didn't knew that
so I included it

On Fri, Mar 13, 2020 at 1:36 AM Joel Sherrill  wrote:

> I still don't see why you need the includes. I just posted (
> https://lists.rtems.org/pipermail/devel/2020-March/058176.html )  what I
> think is a complete implementation of this method. It assumes that the
> thread Id does not overlap the valid clockid's which I am pretty sure is
> true. Then clock_gettime just needs to (1) treat CLOCK_THREAD_CPUTIME_ID as
> a get execution time of executing thread. And (2) if it is a valid thread
> id, then return the executing time of that thread.
>
> There is an example program in the Linux man page for
> pthread_getcpuclockid() which should work based on what I am describing
> plus the code I posted.
>
> On Thu, Mar 12, 2020 at 2:58 PM Eshan Dhawan 
> wrote:
>
>> Link to the new patch :
>> https://lists.rtems.org/pipermail/devel/2020-March/058174.html
>>
>> On Fri, Mar 13, 2020 at 1:19 AM Eshan Dhawan 
>> wrote:
>>
>>>
>>>
>>> On Fri, Mar 13, 2020 at 12:57 AM Joel Sherrill  wrote:
>>>
 Why did you need to add the include? Per
 https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_getcpuclockid.html,
 you should only have to include pthread.h and time.h to have access to the
 types needed.

>>> I tried to access clockid_t but it wasn't included in the file so then I
>>> looked for the clockid_t definition it was in sys/types.h so I included
>>> that though the file also has no inclusion of time.h as well
>>> I should include that and send a Patch
>>>
>>> --eshan
>>>
>>>
 --joel

 On Thu, Mar 12, 2020 at 1:22 PM Eshan Dhawan 
 wrote:

> Hello
> I sent this patch a few days ago but no one reviewed it.
> If someone could look into it and give feedback.
>
> patch link:
> https://lists.rtems.org/pipermail/devel/2020-March/058044.html
>
> On Fri, Mar 6, 2020 at 7:50 PM Eshan dhawan 
> wrote:
>
>> ---
>>  cpukit/posix/src/pthreadgetcpuclockid.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c
>> b/cpukit/posix/src/pthreadgetcpuclockid.c
>> index cd7814b1a6..159a3f9791 100644
>> --- a/cpukit/posix/src/pthreadgetcpuclockid.c
>> +++ b/cpukit/posix/src/pthreadgetcpuclockid.c
>> @@ -22,7 +22,7 @@
>>
>>  #include 
>>  #include 
>> -
>> +#include 
>>  #include 
>>
>>  int pthread_getcpuclockid(
>> --
>> 2.17.1
>>
>> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


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

[PATCH 1/2] Update newlib to c56f53a

This is primarily to pick up the bug fix to have i386 fenv methods.
---
 rtems/config/5/rtems-default.bset  |  2 +-
 rtems/config/5/rtems-epiphany.bset |  2 +-
 rtems/config/5/rtems-or1k.bset |  2 +-
 rtems/config/5/rtems-riscv.bset|  2 +-
 rtems/config/5/rtems-x86_64.bset   |  2 +-
 .../tools/rtems-gcc-7.5.0-newlib-c56f53a.cfg   | 42 ++
 .../tools/rtems-gcc-9.2.0-newlib-c56f53a.cfg   | 28 +++
 7 files changed, 75 insertions(+), 5 deletions(-)
 create mode 100644 rtems/config/tools/rtems-gcc-7.5.0-newlib-c56f53a.cfg
 create mode 100644 rtems/config/tools/rtems-gcc-9.2.0-newlib-c56f53a.cfg

diff --git a/rtems/config/5/rtems-default.bset 
b/rtems/config/5/rtems-default.bset
index 0b67b9e..bdf4715 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -18,5 +18,5 @@ devel/expat-2.1.0-1
 tools/rtems-gdb-9.1-1
 
 tools/rtems-binutils-2.34
-tools/rtems-gcc-7.5.0-newlib-fbaa096
+tools/rtems-gcc-7.5.0-newlib-c56f53a
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-epiphany.bset 
b/rtems/config/5/rtems-epiphany.bset
index 58f81ef..3f599a0 100644
--- a/rtems/config/5/rtems-epiphany.bset
+++ b/rtems/config/5/rtems-epiphany.bset
@@ -34,6 +34,6 @@
 5/rtems-autotools
 devel/expat-2.1.0-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-7.5.0-newlib-fbaa096
+tools/rtems-gcc-7.5.0-newlib-c56f53a
 tools/rtems-gdb-7.8.1-1
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-or1k.bset b/rtems/config/5/rtems-or1k.bset
index d2f659d..b157742 100644
--- a/rtems/config/5/rtems-or1k.bset
+++ b/rtems/config/5/rtems-or1k.bset
@@ -11,5 +11,5 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-fbaa096
+tools/rtems-gcc-9.2.0-newlib-c56f53a
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-riscv.bset b/rtems/config/5/rtems-riscv.bset
index 6678a47..f77f7cc 100644
--- a/rtems/config/5/rtems-riscv.bset
+++ b/rtems/config/5/rtems-riscv.bset
@@ -12,6 +12,6 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.3-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-fbaa096
+tools/rtems-gcc-9.2.0-newlib-c56f53a
 tools/rtems-tools-5-1
 devel/sis-2-1
diff --git a/rtems/config/5/rtems-x86_64.bset b/rtems/config/5/rtems-x86_64.bset
index 7d13ce0..de34156 100644
--- a/rtems/config/5/rtems-x86_64.bset
+++ b/rtems/config/5/rtems-x86_64.bset
@@ -9,5 +9,5 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-fbaa096
+tools/rtems-gcc-9.2.0-newlib-c56f53a
 tools/rtems-tools-5-1
diff --git a/rtems/config/tools/rtems-gcc-7.5.0-newlib-c56f53a.cfg 
b/rtems/config/tools/rtems-gcc-7.5.0-newlib-c56f53a.cfg
new file mode 100644
index 000..0ccad81
--- /dev/null
+++ b/rtems/config/tools/rtems-gcc-7.5.0-newlib-c56f53a.cfg
@@ -0,0 +1,42 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+#
+# FreeBSD specific fix for MIPS
+#
+%if %{_build_os} == freebsd || %{_build_os} == darwin
+ %patch add gcc --rsb-file=freebsd-libgcc-sed-fix.patch -p0 
https://gcc.gnu.org/bugzilla/attachment.cgi?id=41380
+ %hash  sha256 freebsd-libgcc-sed-fix.patch 
8a11bd619c2e55466688e328da00b387d02395c1e8ff4a99225152387a1e60a4
+%endif
+
+%if %{_build_os} == darwin
+ %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/3171/darwin-libstdcpp-noparallel-fix.patch
+ %hash sha512 darwin-libstdcpp-noparallel-fix.patch 
01fa1bd55f19b01f10c41fdfe31356a7a4ddf265ebac8f4b974ccd1718181fd56bcb18a96e0492aa37511f08b37f94052a5557e21075604fceee06d80ffbb7d8
+%endif
+
+%define gcc_version 7.5.0
+%hash sha512 gcc-%{gcc_version}.tar.xz 
fe716cc19f2e3255d3a8b1b8290777bf769c6d98e6e0b07b81a3d6ad43f8af74cb170dfa18b1555dbfcd3f55ae582b91a286ccef496b9b65c1579902f96a1f60
+
+%define newlib_version c56f53a
+%define newlib_external 1
+%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
+%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
+%hash sha512 newlib-%{newlib_version}.tar.gz 
ae973e04fa9a723192d24d7aca708edfd9232d5b009b9e7214447f5947698d16f15285ca97375f1845ee1778c5304f658cd3a7e1c839981102b79c8466ff0e7c
+
+%define isl_version 0.16.1
+%hash sha512 isl-%{isl_version}.tar.bz2 
c188667a84dc5bdddb4ab7c35f89c91bf15a8171f4fcaf41301cf285fb7328846d9a367c096012fec4cc69d244f0bc9e95d84c09ec097394cd4093076f2a041b
+
+%define mpfr_version 3.1.4
+%hash sha512 mpfr-%{mpfr_version}.tar.bz2 
51066066ff2c12ed2198605ecf68846b0c96b548adafa5b80e0c786d0df488411a5e8973358fce7192dc977ad4e68414cf14500e3c39746de62465eb145bb819
+
+%define mpc_version 1.0.3
+%hash sha512 mpc-%{mpc_version}.tar.gz 
0028b76df130720c1fad7de937a0d041224806ce5ef76589f19c7b49d956071a683e2f20d154c192a231e69756b19e48208f2889b0c13950ceb7b3cfaf059a43
+
+%define gmp_version 6.1.0
+%hash sha512 gmp-%{gmp_version}.tar.bz2

[PATCH 2/2] Update gcc to 9.3.0 for targets using 9.2.0

---
 rtems/config/5/rtems-or1k.bset |  2 +-
 rtems/config/5/rtems-riscv.bset|  2 +-
 rtems/config/5/rtems-x86_64.bset   |  2 +-
 .../tools/rtems-gcc-9.3.0-newlib-c56f53a.cfg   | 28 ++
 4 files changed, 31 insertions(+), 3 deletions(-)
 create mode 100644 rtems/config/tools/rtems-gcc-9.3.0-newlib-c56f53a.cfg

diff --git a/rtems/config/5/rtems-or1k.bset b/rtems/config/5/rtems-or1k.bset
index b157742..fc57837 100644
--- a/rtems/config/5/rtems-or1k.bset
+++ b/rtems/config/5/rtems-or1k.bset
@@ -11,5 +11,5 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-c56f53a
+tools/rtems-gcc-9.3.0-newlib-c56f53a
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-riscv.bset b/rtems/config/5/rtems-riscv.bset
index f77f7cc..e85c41a 100644
--- a/rtems/config/5/rtems-riscv.bset
+++ b/rtems/config/5/rtems-riscv.bset
@@ -12,6 +12,6 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.3-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-c56f53a
+tools/rtems-gcc-9.3.0-newlib-c56f53a
 tools/rtems-tools-5-1
 devel/sis-2-1
diff --git a/rtems/config/5/rtems-x86_64.bset b/rtems/config/5/rtems-x86_64.bset
index de34156..e39711b 100644
--- a/rtems/config/5/rtems-x86_64.bset
+++ b/rtems/config/5/rtems-x86_64.bset
@@ -9,5 +9,5 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-c56f53a
+tools/rtems-gcc-9.3.0-newlib-c56f53a
 tools/rtems-tools-5-1
diff --git a/rtems/config/tools/rtems-gcc-9.3.0-newlib-c56f53a.cfg 
b/rtems/config/tools/rtems-gcc-9.3.0-newlib-c56f53a.cfg
new file mode 100644
index 000..f0b52b8
--- /dev/null
+++ b/rtems/config/tools/rtems-gcc-9.3.0-newlib-c56f53a.cfg
@@ -0,0 +1,28 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%if %{_build_os} == freebsd || %{_build_os} == darwin
+ %patch add gcc --rsb-file=freebsd-libgcc-sed-fix.patch -p0 
https://gcc.gnu.org/bugzilla/attachment.cgi?id=41380
+ %hash  sha256 freebsd-libgcc-sed-fix.patch 
8a11bd619c2e55466688e328da00b387d02395c1e8ff4a99225152387a1e60a4
+%endif
+
+%if %{_build_os} == darwin
+ %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/3171/darwin-libstdcpp-noparallel-fix.patch
+ %hash sha512 darwin-libstdcpp-noparallel-fix.patch 
01fa1bd55f19b01f10c41fdfe31356a7a4ddf265ebac8f4b974ccd1718181fd56bcb18a96e0492aa37511f08b37f94052a5557e21075604fceee06d80ffbb7d8
+%endif
+
+%define gcc_version 9.3.0
+%source set gcc 
https://ftp.gnu.org/gnu/gcc/gcc-%{gcc_version}/gcc-%{gcc_version}.tar.xz
+%hash sha512 gcc-%{gcc_version}.tar.xz 
4b9e3639eef6e623747a22c37a904b4750c93b6da77cf3958d5047e9b5ebddb7eebe091cc16ca0a227c0ecbd2bf3b984b221130f269a97ee4cc18f9cf6c444de
+
+%define newlib_version c56f53a
+%define newlib_external 1
+%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
+%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
+%hash sha512 newlib-%{newlib_version}.tar.gz 
ae973e04fa9a723192d24d7aca708edfd9232d5b009b9e7214447f5947698d16f15285ca97375f1845ee1778c5304f658cd3a7e1c839981102b79c8466ff0e7c
+
+%define with_threads 1
+%define with_plugin 0
+%define with_iconv 1
+
+%include %{_configdir}/gcc-9.cfg
-- 
1.8.3.1

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

Re: [PATCH v1] include sys/types.h to include defination of clockid_t

I still don't see why you need the includes. I just posted (
https://lists.rtems.org/pipermail/devel/2020-March/058176.html )  what I
think is a complete implementation of this method. It assumes that the
thread Id does not overlap the valid clockid's which I am pretty sure is
true. Then clock_gettime just needs to (1) treat CLOCK_THREAD_CPUTIME_ID as
a get execution time of executing thread. And (2) if it is a valid thread
id, then return the executing time of that thread.

There is an example program in the Linux man page for
pthread_getcpuclockid() which should work based on what I am describing
plus the code I posted.

On Thu, Mar 12, 2020 at 2:58 PM Eshan Dhawan 
wrote:

> Link to the new patch :
> https://lists.rtems.org/pipermail/devel/2020-March/058174.html
>
> On Fri, Mar 13, 2020 at 1:19 AM Eshan Dhawan 
> wrote:
>
>>
>>
>> On Fri, Mar 13, 2020 at 12:57 AM Joel Sherrill  wrote:
>>
>>> Why did you need to add the include? Per
>>> https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_getcpuclockid.html,
>>> you should only have to include pthread.h and time.h to have access to the
>>> types needed.
>>>
>> I tried to access clockid_t but it wasn't included in the file so then I
>> looked for the clockid_t definition it was in sys/types.h so I included
>> that though the file also has no inclusion of time.h as well
>> I should include that and send a Patch
>>
>> --eshan
>>
>>
>>> --joel
>>>
>>> On Thu, Mar 12, 2020 at 1:22 PM Eshan Dhawan 
>>> wrote:
>>>
 Hello
 I sent this patch a few days ago but no one reviewed it.
 If someone could look into it and give feedback.

 patch link:
 https://lists.rtems.org/pipermail/devel/2020-March/058044.html

 On Fri, Mar 6, 2020 at 7:50 PM Eshan dhawan 
 wrote:

> ---
>  cpukit/posix/src/pthreadgetcpuclockid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c
> b/cpukit/posix/src/pthreadgetcpuclockid.c
> index cd7814b1a6..159a3f9791 100644
> --- a/cpukit/posix/src/pthreadgetcpuclockid.c
> +++ b/cpukit/posix/src/pthreadgetcpuclockid.c
> @@ -22,7 +22,7 @@
>
>  #include 
>  #include 
> -
> +#include 
>  #include 
>
>  int pthread_getcpuclockid(
> --
> 2.17.1
>
> ___
 devel mailing list
 devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] pthreadgetcpuclockid.c: Implement pthread_getcpuclockid to return thread Id

---
 cpukit/posix/src/pthreadgetcpuclockid.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c 
b/cpukit/posix/src/pthreadgetcpuclockid.c
index cd7814b..c15962e 100644
--- a/cpukit/posix/src/pthreadgetcpuclockid.c
+++ b/cpukit/posix/src/pthreadgetcpuclockid.c
@@ -7,8 +7,10 @@
 
 /*
  *  20.1.6 Accessing a Thread CPU-time Clock, P1003.4b/Draft 8, p. 58
- *
- *  COPYRIGHT (c) 1989-2007.
+ */
+
+/*
+ *  COPYRIGHT (c) 1989-2007,2020.
  *  On-Line Applications Research Corporation (OAR).
  *
  *  The license and distribution terms for this file may be
@@ -23,12 +25,31 @@
 #include 
 #include 
 
-#include 
+#include 
 
 int pthread_getcpuclockid(
-  pthread_tpid,
+  pthread_tthread,
   clockid_t   *clock_id
 )
 {
-  rtems_set_errno_and_return_minus_one( ENOSYS );
+  Thread_Control   *the_thread;
+  ISR_lock_Context  lock_context;
+
+  if ( clock_id == NULL ) {
+return EINVAL;
+  }
+
+  the_thread = _Thread_Get( thread, _context );
+
+  if ( the_thread == NULL ) {
+return ESRCH;
+  }
+
+  _Thread_State_acquire_critical( the_thread, _context );
+
+  *clock_id = the_thread->Object.id;
+
+  _Thread_State_release( the_thread, _context );
+
+  return 0;
 }
-- 
1.8.3.1

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

Re: [PATCH v1] include sys/types.h to include defination of clockid_t

Link to the new patch :
https://lists.rtems.org/pipermail/devel/2020-March/058174.html

On Fri, Mar 13, 2020 at 1:19 AM Eshan Dhawan 
wrote:

>
>
> On Fri, Mar 13, 2020 at 12:57 AM Joel Sherrill  wrote:
>
>> Why did you need to add the include? Per
>> https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_getcpuclockid.html,
>> you should only have to include pthread.h and time.h to have access to the
>> types needed.
>>
> I tried to access clockid_t but it wasn't included in the file so then I
> looked for the clockid_t definition it was in sys/types.h so I included
> that though the file also has no inclusion of time.h as well
> I should include that and send a Patch
>
> --eshan
>
>
>> --joel
>>
>> On Thu, Mar 12, 2020 at 1:22 PM Eshan Dhawan 
>> wrote:
>>
>>> Hello
>>> I sent this patch a few days ago but no one reviewed it.
>>> If someone could look into it and give feedback.
>>>
>>> patch link:
>>> https://lists.rtems.org/pipermail/devel/2020-March/058044.html
>>>
>>> On Fri, Mar 6, 2020 at 7:50 PM Eshan dhawan 
>>> wrote:
>>>
 ---
  cpukit/posix/src/pthreadgetcpuclockid.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c
 b/cpukit/posix/src/pthreadgetcpuclockid.c
 index cd7814b1a6..159a3f9791 100644
 --- a/cpukit/posix/src/pthreadgetcpuclockid.c
 +++ b/cpukit/posix/src/pthreadgetcpuclockid.c
 @@ -22,7 +22,7 @@

  #include 
  #include 
 -
 +#include 
  #include 

  int pthread_getcpuclockid(
 --
 2.17.1

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

[PATCH v1] add time.h to pthreadgetcpuclockid file to access clockid_t

2020-03-12 Thread Eshan dhawan

---
 cpukit/posix/src/pthreadgetcpuclockid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c 
b/cpukit/posix/src/pthreadgetcpuclockid.c
index 159a3f9791..39915f3c0a 100644
--- a/cpukit/posix/src/pthreadgetcpuclockid.c
+++ b/cpukit/posix/src/pthreadgetcpuclockid.c
@@ -22,7 +22,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 int pthread_getcpuclockid(
-- 
2.17.1

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

Re: [PATCH v1] include sys/types.h to include defination of clockid_t

On Fri, Mar 13, 2020 at 12:57 AM Joel Sherrill  wrote:

> Why did you need to add the include? Per
> https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_getcpuclockid.html,
> you should only have to include pthread.h and time.h to have access to the
> types needed.
>
I tried to access clockid_t but it wasn't included in the file so then I
looked for the clockid_t definition it was in sys/types.h so I included
that though the file also has no inclusion of time.h as well
I should include that and send a Patch

--eshan


> --joel
>
> On Thu, Mar 12, 2020 at 1:22 PM Eshan Dhawan 
> wrote:
>
>> Hello
>> I sent this patch a few days ago but no one reviewed it.
>> If someone could look into it and give feedback.
>>
>> patch link:
>> https://lists.rtems.org/pipermail/devel/2020-March/058044.html
>>
>> On Fri, Mar 6, 2020 at 7:50 PM Eshan dhawan 
>> wrote:
>>
>>> ---
>>>  cpukit/posix/src/pthreadgetcpuclockid.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c
>>> b/cpukit/posix/src/pthreadgetcpuclockid.c
>>> index cd7814b1a6..159a3f9791 100644
>>> --- a/cpukit/posix/src/pthreadgetcpuclockid.c
>>> +++ b/cpukit/posix/src/pthreadgetcpuclockid.c
>>> @@ -22,7 +22,7 @@
>>>
>>>  #include 
>>>  #include 
>>> -
>>> +#include 
>>>  #include 
>>>
>>>  int pthread_getcpuclockid(
>>> --
>>> 2.17.1
>>>
>>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1] include sys/types.h to include defination of clockid_t

Why did you need to add the include? Per
https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_getcpuclockid.html,
you should only have to include pthread.h and time.h to have access to the
types needed.

--joel

On Thu, Mar 12, 2020 at 1:22 PM Eshan Dhawan 
wrote:

> Hello
> I sent this patch a few days ago but no one reviewed it.
> If someone could look into it and give feedback.
>
> patch link: https://lists.rtems.org/pipermail/devel/2020-March/058044.html
>
> On Fri, Mar 6, 2020 at 7:50 PM Eshan dhawan 
> wrote:
>
>> ---
>>  cpukit/posix/src/pthreadgetcpuclockid.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c
>> b/cpukit/posix/src/pthreadgetcpuclockid.c
>> index cd7814b1a6..159a3f9791 100644
>> --- a/cpukit/posix/src/pthreadgetcpuclockid.c
>> +++ b/cpukit/posix/src/pthreadgetcpuclockid.c
>> @@ -22,7 +22,7 @@
>>
>>  #include 
>>  #include 
>> -
>> +#include 
>>  #include 
>>
>>  int pthread_getcpuclockid(
>> --
>> 2.17.1
>>
>> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Hello world and query about a project availability

2020-03-12 Thread Gedare Bloom

On Thu, Mar 12, 2020 at 1:23 PM Gedare Bloom  wrote:
>
> Hi Richi,
>
> Welcome. The "Improve the SMP Scheduler" will require strong C
> programming skills before the summer. You will be expected to
> demonstrate that during the proposal period. I'm the only likely
> mentor for that project this year, and I haven't decided if I will
> mentor any projects, or which project I might mentor if I do. So it
> can be a bit risky to pursue that project, but if you are passionate
> about it and have the required capabilities, then you should start to
> prepare a proposal and convince me that I should mentor you :).
>
> The project itself is a straightforward implementation from the
> current skeleton of the scheduler. So you will want to also include
> some "extension" activities in case you complete the scheduler
> quickly.
>
> You should add yourself to https://devel.rtems.org/wiki/GSoC/2020
>
PS: thanks for the screenshot, please send your patch as well.

> Gedare
>
> On Thu, Mar 12, 2020 at 1:04 PM Richi Dubey  wrote:
> >
> > Hey everyone,
> >
> > Could someone please tell me if this project
> > (https://devel.rtems.org/ticket/2510) titled
> > "Improve the SMP scheduler with arbitrary processor affinity support"
> > still open? I went through the mpi-sws paper and I found the concept
> > of implementing
> > task's affinity to a processor to increase its efficiency really
> > interesting. Can someone please help me with this?
> >
> > Thanks,
> > Richi.
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Hello world and query about a project availability

2020-03-12 Thread Gedare Bloom

Hi Richi,

Welcome. The "Improve the SMP Scheduler" will require strong C
programming skills before the summer. You will be expected to
demonstrate that during the proposal period. I'm the only likely
mentor for that project this year, and I haven't decided if I will
mentor any projects, or which project I might mentor if I do. So it
can be a bit risky to pursue that project, but if you are passionate
about it and have the required capabilities, then you should start to
prepare a proposal and convince me that I should mentor you :).

The project itself is a straightforward implementation from the
current skeleton of the scheduler. So you will want to also include
some "extension" activities in case you complete the scheduler
quickly.

You should add yourself to https://devel.rtems.org/wiki/GSoC/2020

Gedare

On Thu, Mar 12, 2020 at 1:04 PM Richi Dubey  wrote:
>
> Hey everyone,
>
> Could someone please tell me if this project
> (https://devel.rtems.org/ticket/2510) titled
> "Improve the SMP scheduler with arbitrary processor affinity support"
> still open? I went through the mpi-sws paper and I found the concept
> of implementing
> task's affinity to a processor to increase its efficiency really
> interesting. Can someone please help me with this?
>
> Thanks,
> Richi.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1] include sys/types.h to include defination of clockid_t

Hello
I sent this patch a few days ago but no one reviewed it.
If someone could look into it and give feedback.

patch link: https://lists.rtems.org/pipermail/devel/2020-March/058044.html

On Fri, Mar 6, 2020 at 7:50 PM Eshan dhawan  wrote:

> ---
>  cpukit/posix/src/pthreadgetcpuclockid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/posix/src/pthreadgetcpuclockid.c
> b/cpukit/posix/src/pthreadgetcpuclockid.c
> index cd7814b1a6..159a3f9791 100644
> --- a/cpukit/posix/src/pthreadgetcpuclockid.c
> +++ b/cpukit/posix/src/pthreadgetcpuclockid.c
> @@ -22,7 +22,7 @@
>
>  #include 
>  #include 
> -
> +#include 
>  #include 
>
>  int pthread_getcpuclockid(
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Python Standardization (ticket #3892)

2020-03-12 Thread Amar Takhar

On 2020-03-12 11:52 +0530, Anmol Mishra wrote:
> Hello,
> With whom can I discuss regarding douts, Any tentative??mentor open for 
> guiding
> me, I have a few doubts regarding the project. Is Dr. Gedare going to be a
> tentative??mentor?

I am the mentor for this project.  Can you please send any inquiries to 
devel@rtems.org?  You can sign up for the lists here: https://lists.rtems.org/

Thank you!

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

Re: RTEMS Python Standardization (ticket #3892)

2020-03-12 Thread Gedare Bloom

On Thu, Mar 12, 2020 at 12:22 AM Anmol Mishra  wrote:
>
> Hello,
> With whom can I discuss regarding douts, Any tentative mentor open for 
> guiding me, I have a few doubts regarding the project. Is Dr. Gedare going to 
> be a tentative mentor?
>
No, I won't be. I oversee all projects, and try to provide
guidance/structure and make sure proposals are sufficiently detailed
for us to evaluate. Amar is the most likely potential mentor on this
project and should be engaged to get technical direction/advice. The
mailing list is also preferred for most communication unless of a
personal nature.

> Best Regards
>
> On Tue, Mar 10, 2020 at 11:12 AM Anmol Mishra  wrote:
>>
>> Sure thing, I have replied and reviewed all your comments. Working on them 
>> and I will restructure it at the earliest. Now I understand google's idea to 
>> get it reviewed by mentors asap, so that reshaping can be done to match the 
>> target in time.
>>
>> Thanks for your input and time.
>>
>> Best Regards
>>
>> On Tue, Mar 10, 2020 at 3:18 AM Gedare Bloom  wrote:
>>>
>>> Hello Anmol,
>>>
>>> I have provided some feedback on your draft. Please focus on reshaping
>>> your proposal to provide a stronger organization of both your thought
>>> process and your plan for working in the summer. You might like to
>>> review advice in: https://google.github.io/gsocguides/student/
>>>
>>> On Mon, Mar 9, 2020 at 12:02 PM Anmol Mishra  wrote:
>>> >
>>> > Hello,
>>> > I proposed the project and after a lot of input, I saw that a project 
>>> > RTEMS Python Standardization (ticket #3892) has been added to the list.
>>> > I have drafted a proposal (It needs a lot of refinement and I seek from 
>>> > expected mentor and co-mentor in this step)
>>> >
>>> > https://docs.google.com/document/d/1_G0-q7J2b-5kJzZGI32a-KpC6gMzJ1FcNFFTdMCw1c4/edit?usp=sharing
>>> >
>>> > Please consider me a little naive as this is my first proposal, I will 
>>> > try to match the benchmark in the final proposal, A lot of discussions is 
>>> > to be done at this stage.
>>> >
>>> > Best Regards
>>> > Anmol Mishra
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/2] c-user: Clarify message buffer configuration

The help macro CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE() is not a
configuration option.  Move it into the documentatation of the
CONFIGURE_MESSAGE_BUFFER_MEMORY configuration option.  Move this option
to the general system configuration group.

Update #3836.
---
 c-user/config/general.rst  | 73 ++
 c-user/config/index.rst|  1 -
 c-user/config/msg-queue-buffer.rst | 93 --
 3 files changed, 73 insertions(+), 94 deletions(-)
 delete mode 100644 c-user/config/msg-queue-buffer.rst

diff --git a/c-user/config/general.rst b/c-user/config/general.rst
index f6d7531..f5f44d3 100644
--- a/c-user/config/general.rst
+++ b/c-user/config/general.rst
@@ -324,6 +324,79 @@ NOTES:
 Typically the memory allocation will be too low when an application does
 not account for all message queue buffers or task stacks.
 
+.. index:: CONFIGURE_MESSAGE_BUFFER_MEMORY
+.. index:: configure message queue buffer memory
+.. index:: CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE
+.. index:: memory for a single message queue's buffers
+
+.. _CONFIGURE_MESSAGE_BUFFER_MEMORY:
+
+CONFIGURE_MESSAGE_BUFFER_MEMORY
+---
+
+CONSTANT:
+``CONFIGURE_MESSAGE_BUFFER_MEMORY``
+
+DATA TYPE:
+integer summation macro
+
+RANGE:
+undefined (zero) or calculation resulting in a positive integer
+
+DEFAULT VALUE:
+The default value is zero.
+
+DESCRIPTION:
+The value of this configuration option defines the number of bytes
+resereved for message queue buffers in the RTEMS Workspace.
+
+NOTES:
+The configuration options :ref:`CONFIGURE_MAXIMUM_MESSAGE_QUEUES` and
+:ref:`CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES` define only how many message
+queues can be created by the application.  The memory for the message
+buffers is configured by this option.  For each message queue you have to
+reserve some memory for the message buffers.  The size dependes on the
+maximum number of pending messages and the maximum size of the messages of
+a message queue.  Use the ``CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE()`` macro
+to specify the message buffer memory for each message queue and sum them up
+to define the value for ``CONFIGURE_MAXIMUM_MESSAGE_QUEUES``.
+
+The interface for the ``CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE()`` help
+macro is as follows:
+
+.. code-block:: c
+
+CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( max_messages, max_msg_size )
+
+Where ``max_messages`` is the maximum number of pending messages and
+``max_msg_size`` is the maximum size in bytes of the messages of the
+corresponding message queue.  Both parameters shall be compile time
+constants.  Not using this help macro (e.g. just using
+``max_messages * max_msg_size``) may result in an underestimate of the
+RTEMS Workspace size.
+
+The following example illustrates how the
+`CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE()` help macro can be used to assist in
+calculating the message buffer memory required.  In this example, there are
+two message queues used in this application.  The first message queue has a
+maximum of 24 pending messages with the message structure defined by the
+type ``one_message_type``.  The other message queue has a maximum of 500
+pending messages with the message structure defined by the type
+``other_message_type``.
+
+.. code-block:: c
+
+#define CONFIGURE_MESSAGE_BUFFER_MEMORY ( \
+CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \
+  24, \
+  sizeof( one_message_type ) \
+) \
++ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( \
+  500, \
+  sizeof( other_message_type ) \
+) \
+  )
+
 .. index:: CONFIGURE_MICROSECONDS_PER_TICK
 .. index:: tick quantum
 
diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index 0d6c0dd..2318042 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -17,7 +17,6 @@ Configuring a System
 posix-api
 posix-init-thread
 task-stack-alloc
-msg-queue-buffer
 filesystem
 bdbuf
 bsp-related
diff --git a/c-user/config/msg-queue-buffer.rst 
b/c-user/config/msg-queue-buffer.rst
deleted file mode 100644
index 8d40149..000
--- a/c-user/config/msg-queue-buffer.rst
+++ /dev/null
@@ -1,93 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
-
-Message Queue Buffer Configuration
-==
-
-This section describes the configuration parameters related to specifying the
-amount of memory reserved for message queue message buffers.  See
-:ref:`CONFIGURE_MAXIMUM_MESSAGE_QUEUES` and
-:ref:`CONFIGURE_MAXIMUM_POSIX_MESSAGE_QUEUES`.
-
-.. index:: CONFIGURE_MESSAGE_BUFFER_MEMORY
-.. index:: configure message queue buffer memory
-
-.. _CONFIGURE_MESSAGE_BUFFER_MEMORY:
-
-CONFIGURE_MESSAGE_BUFFER_MEMORY

[PATCH 2/2] c-user: Reorder configuration option groups

Sort the configuration option groups according to the likelihood a user
will define options of a group.

Update #3836.
---
 c-user/config/index.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/c-user/config/index.rst b/c-user/config/index.rst
index 2318042..b0e21a4 100644
--- a/c-user/config/index.rst
+++ b/c-user/config/index.rst
@@ -12,20 +12,20 @@ Configuring a System
 
 intro
 general
+device-driver
 classic-api
 classic-init-task
 posix-api
 posix-init-thread
-task-stack-alloc
+event-record
 filesystem
 bdbuf
-bsp-related
+task-stack-alloc
 idle-task
 scheduler-general
 scheduler-clustered
-device-driver
+bsp-related
 mpci
 libpci
-event-record
 ada
 obsolete
-- 
2.16.4

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

[PATCH] c-user: Add copyright information

Add copyright information according to commit in RTEMS main repository:

commit e53aae2676c42cda521328504f82d26c33827021
Author: Gedare Bloom 
Date:   Mon Mar 26 16:42:38 2012 -0400

confdefs: Add declaration for unlimited objects.

Adds to confdefs a way to specify rtems_resource_unlimited for classic and
posix objects using a new macro CONFIGURE_OBJECTS_UNLIMITED.
Use CONFIGURE_OBJECTS_ALLOCATION_SIZE to declare the allocation size for
extending the set of objects at runtime. Updates the unlimited sample
to demonstrate how to use the new macros. Also adds new documentation in
the C User's Manual regarding configuring with unlimited objects.
---
 c-user/config/intro.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/c-user/config/intro.rst b/c-user/config/intro.rst
index 636a7b8..46267d7 100644
--- a/c-user/config/intro.rst
+++ b/c-user/config/intro.rst
@@ -1,5 +1,6 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2012 Gedare Bloom
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
 Introduction
-- 
2.16.4

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

Re: [PATCH] user: Add a migration chapter


On 12/03/2020 08:06, chr...@rtems.org wrote:


From: Chris Johns

This is a start with the hope we collect useful pieces to aid porting.
Please add to this.

Closes #3895

Thanks for the start. I will add a couple of things once you pushed it.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS CAN support Was: Hello World on BeagleBone

2020-03-12 Thread Pavel Pisa

Hello Gedare and John,

I have long term interrest in (not only) RTEMS CAN
support. So I would help as time and energy allows
me. I want and must spent some holiday time out
of computers and school load. I would apply for
(co-)menthor. Send me invitation, please.

As for RTEMS CAN support, as I know there is no
single CAN driver model available over all BSPs
with CAN support implemented as I know. I need
to go through sources again to analyze actual state.
There is

bsps/shared/grlib/can
bsps/powerpc/gen5200/mscan
bsps/arm/lpc176x/can
bsps/arm/atsam/contrib/libraries/libchip/source/mcan.c

On RTEMS, I have experience only with gen5200 mscan
many years ago. The API was minimal but provided
required functionality.

I have offered cooperation on our LinCAN API porting
to RTEMS. The driver for Linux
http://ortcan.sourceforge.net/lincan/
See 1.4. LinCAN Driver Architecture section from the manual
http://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
The complete concept of our CAN/CANopen components support there
http://cmp.felk.cvut.cz/~pisa/can/doc/ocera-canopen-ug.pdf
But the head of former Real-Time Systems group at our department
has no interrest to continue on work to make it really
usesfull when the EU funded project has finished.
So I have tried to keep it at least at the level usable
as demonstrator of technology and tool for our other
CAN related projects. On Linux side, Oliver Hartkopp and Pengutronix
SocketCAN is the mainline choice. It has more advanced
and easy to use API, CAN FD support etc. So I have helped
to reuse some LinCAN code for this project. As for RT side,
I have still some doubts if the choice is optimal ...
But we use SocketCAN on Linux as main target now for
almost all CAN related faculty activities
http://canbus.pages.fel.cvut.cz/
and our CAopen support can use SocketCAN as the driver API
as well

https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_isocketcan.c
I have demonstrated that the project has some value still in 2017,
when I have setup DS-402 motion control CANopen profile device
from Zynq based MZ_APO board and other PiKRON designed hardware
and PiKRON provided PXMC motion control library
https://www.linuxdays.cz/2017/video/Pavel_Pisa-CAN_canopen.pdf
The connection and use of RTEMS sponsored QEMU CAN support
was part of the presentation.
http://cmp.felk.cvut.cz/~pisa/can/doc/rtlws-17-pisa-qemu-can.pdf
https://github.com/qemu/qemu/blob/master/docs/can.txt
I have bachelor student working on our open source CTU CAN FD IP
core QEMU model now.
I have demonstrated, that I am alive still on LinuxDays 2019
when I have ported most of OrtCAN compnents to work on NuttX
https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_inuttx.c

So back to RTEMS, It would be great if there is some consensus
what is the CAN driver API preferred choice.
The grlib defines basic CANMsg type but even it is non consistent
because it defines it twice. It uses char for each flag instead
of bit and when CAN FD support is added then it would require
to make structure incompatible. SocketCAN API is BSD sockets
based and I think to complex. NuttX CAN API is functional
but too much configurable to squeeze it to less bytes for small
devices
https://bitbucket.org/nuttx/nuttx/src/master/include/nuttx/can/can.h
But it is reasonable character device CAN API. NuttX is Apache
licensed now so even direct use for RTEMS could be OK including drivers.
LinCAN API can be extended to support CAN FD and provide even
internal FIFOs etc. LinCAN is GPL2 licensed with linking exception,
I have though about its RTEMS use from beginning. I have chance
to relicence it, it is partially based on older Linux CAN projects
to keep API partial compatibility but all is rewitted by me at least
onece. I expect no problem to negotiate change with our department
head now to cover even reference to it. But I am not sure if it is
the best option.

As for BeagleBone, it uses D_CAN based on BOSCH C_CAN.
Linux driver

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/c_can/c_can.c
NuttX driver
https://bitbucket.org/nuttx/nuttx/src/master/arch/arm/src/am335x/am335x_can.c
We have worked on CCAN support for OKI ML9620 chip support
under BOSCH funding long time ago, so initial version of working
LinCAN support for CCAN (DCAN) exists there
https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/c_can.c
I have lot of experience with DCAN on TMS570 on the rapid prototyping
platform done on EATON contract at former DCE RT group.
I have lead, guide and invested in diploma theses student to implemented
nice time triggered CAN support but due doctor Michal Sojka and professor
Zdenek Hanzalek order, only disfigured version could be published
as part of final theses text same as the whole work on Matlab/Simulink
target done mainly in a frame of diploma theses of foreign and local students
(often with my personal investment into guiding and

[PATCH] user: Add a migration chapter

2020-03-12 Thread chrisj

From: Chris Johns 

This is a start with the hope we collect useful pieces to aid porting.
Please add to this.

Closes #3895
---
 user/index.rst |  2 +
 user/migration/index.rst   | 17 ++
 user/migration/v4_11-to-v5.rst | 96 ++
 3 files changed, 115 insertions(+)
 create mode 100644 user/migration/index.rst
 create mode 100644 user/migration/v4_11-to-v5.rst

diff --git a/user/index.rst b/user/index.rst
index 0e644c9..8ba1aee 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -42,6 +42,8 @@ RTEMS User Manual (|version|).
 testing/index
 tracing/index
 
+migration/index
+
 tools/index
 rsb/index
 
diff --git a/user/migration/index.rst b/user/migration/index.rst
new file mode 100644
index 000..76012b5
--- /dev/null
+++ b/user/migration/index.rst
@@ -0,0 +1,17 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 Chris Johns
+
+.. index:: Migration
+
+.. _Migration:
+
+Changing Versions
+*
+
+Follow the sections provide support help when migratiing applications
+from one version of RTEMS to a new version.
+
+.. toctree::
+
+v4_11-to-v5
diff --git a/user/migration/v4_11-to-v5.rst b/user/migration/v4_11-to-v5.rst
new file mode 100644
index 000..4329771
--- /dev/null
+++ b/user/migration/v4_11-to-v5.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 Chris Johns
+
+.. _Migration_4_11_to_5:
+
+RTEMS 4.11 to RTEMS 5
+=
+
+This section provides helpful information when migrating from RTEMS 4.11 to
+RTEMS 5.
+
+Configuration
+-
+
+A number of configurations macros have moved as a result of internal changes in
+RTEMS. Some of these will produce a warning indicating the new configuration
+setings you need to define. If you need to run an application on RTEMS 4.11 and
+RTEMS 5 the following code exmaple shows how to conditionally define the
+settings. The example is:
+
+.. code-block:: c
+
+#include 
+
+#if __RTEMS_MAJOR__ < 5
+ #define CONFIGURE_MAXIMUM_FIFOS 10
+ #define CONFIGURE_MAXIMUM_PIPES 10
+#else
+ #define CONFIGURE_IMFS_ENABLE_MKFIFO
+#endif
+
+#define MAX_FILE_DESCRIPTORS 200
+#if __RTEMS_MAJOR__ < 5
+ #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS MAX_FILE_DESCRIPTORS
+#else
+ #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS   MAX_FILE_DESCRIPTORS
+#endif
+
+Networking
+--
+
+The following code samples provides a simple way to initialise and start
+networking with the BSD Library's (``libbsd``) networking stack. The simplest
+method to configure the networking stack is to provide a :file:`/etc/rc,conf`
+file on your target. If your target has no non-volatile media for a file system
+create the :file:`rc.conf` file each time your application starts.
+
+The :file:`rc.conf` support in ``libbsd`` provides a number of needed support
+settings. We recommend you search for FreeBSD and ``rc.conf`` to view the
+available online documentation that FreeBSD provides.
+
+In this example the network interface is ``cgem0``, replace with your
+interface name.
+
+.. code-block:: c
+
+static const char* rc_conf =
+  "# /etc/rc.conf\n" \
+  "hostname=\"rtems5-libbsd\"\n" \
+  "ifconfig_cgem0=\"inet 10.1.2.3 netmask 255.255.255.0 rxcsum txcsum\"\n" 
\
+  "ifconfig_cgem0_alias0=\"ether 00:80:81:82:83:84\"\n" \
+  "defaultrouter=\"10.1.2.1\"\n" \
+  "telnetd_enable=\"YES\"\n";
+
+void start_network(void)
+{
+  FILE *rc;
+  int   r;
+
+  /*
+   * Initialise libbsd.
+   */
+  rtems_bsd_initialize();
+
+  /*
+   * Create the /etc/rc,conf, assume /etc exists.
+   */
+  rc = fopen("/etc/rc.conf", "w");
+  if (rc_conf == NULL) {
+printf("error: cannot create /etc/rc.conf\n");
+exit(1);
+  }
+
+  fprintf(rc, rc_conf);
+  fclose(rc);
+
+  /*
+   * Arguments are timeout and trace
+   */
+  r = rtems_bsd_run_etc_rc_conf(30, false);
+  if (r < 0) {
+printf("error: loading /etc/rc.conf failed: %s\n",strerror(errno));
+exit(1);
+  }
+}
-- 
2.23.0

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

Re: Project proposal for GSOC 2020