Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

Thank you for the clarification, I will proceed accordingly. On Thu, Apr 9, 2020 at 10:36 PM Joel Sherrill wrote: > > > On Thu, Apr 9, 2020 at 11:56 AM Utkarsh Rai > wrote: > >> Thank you, under psxtests/psxhdrs/time we have a test for clock_nanosleep >> for CLOCK_REALTIME, would it be a good

Re: Test for timer_create() with CLOCK_MONOTONIC

On Thu, Apr 9, 2020 at 10:47 PM Joel Sherrill wrote: > > > On Thu, Apr 9, 2020 at 12:14 PM Eshan Dhawan > wrote: > >> hello, >> >> where would the test case of timer_create() with CLOCK_MONOTONIC be added >> ?? >> would they be added in >> psxtimer01 or psxtimer02 or will it be required to

Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

On Thu, Apr 9, 2020 at 11:56 AM Utkarsh Rai wrote: > Thank you, under psxtests/psxhdrs/time we have a test for clock_nanosleep > for CLOCK_REALTIME, would it be a good idea to add test for CLOCK_MONOTONIC > under the same test, or should I add a different test using RTEMS Test > framework? >

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

How is this dealt with in sp01 and samples/ticker in the main tree? I suppose we need a patch for the rtems-examples repository. On Thu, Apr 9, 2020 at 8:34 AM Alan Cudmore wrote: > Hi Sebastian, > Thank you for reproducing this. I added the floating point attribute > to my demo tasks and it

Test for timer_create() with CLOCK_MONOTONIC

hello, where would the test case of timer_create() with CLOCK_MONOTONIC be added ?? would they be added in psxtimer01 or psxtimer02 or will it be required to create a new test file for that? thanks - Eshan ___ devel mailing list devel@rtems.org

Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

Thank you, under psxtests/psxhdrs/time we have a test for clock_nanosleep for CLOCK_REALTIME, would it be a good idea to add test for CLOCK_MONOTONIC under the same test, or should I add a different test using RTEMS Test framework? On Thu, Apr 9, 2020 at 6:43 PM Sebastian Huber <

[PATCH RSB 4/4] qemu-couverture: update to qemu-stable-4.0.0

--- bare/config/devel/qemu-couverture-git-1.cfg | 16 +--- bare/config/devel/qemu-couverture.bset | 5 +++-- 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/bare/config/devel/qemu-couverture-git-1.cfg b/bare/config/devel/qemu-couverture-git-1.cfg index

[PATCH RSB 1/4] bare/glib-2.48.2: Add patches to suppress null string warning

--- bare/config/devel/glib-2.48.2-1.cfg | 7 +++ 1 file changed, 7 insertions(+) diff --git a/bare/config/devel/glib-2.48.2-1.cfg b/bare/config/devel/glib-2.48.2-1.cfg index 9e85fce..38b6d93 100644 --- a/bare/config/devel/glib-2.48.2-1.cfg +++ b/bare/config/devel/glib-2.48.2-1.cfg @@ -14,6

[PATCH RSB 2/4] bare/config: Add devel/dtc-1.6.0

--- bare/config/devel/dtc-1.6.0-1.cfg | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg diff --git a/bare/config/devel/dtc-1.6.0-1.cfg b/bare/config/devel/dtc-1.6.0-1.cfg new file mode 100644 index 000..f293f12 --- /dev/null +++

[PATCH RSB 3/4] source-builder: Add capstone

--- bare/config/devel/capstone-4.0.1-1.cfg | 27 +++ bare/config/devel/capstone.bset| 7 +++ source-builder/config/capstone-1-1.cfg | 62 ++ 3 files changed, 96 insertions(+) create mode 100644 bare/config/devel/capstone-4.0.1-1.cfg create mode 100644

Re: Test for timer_create() with CLOCK_MONOTONIC

On Thu, Apr 9, 2020 at 12:14 PM Eshan Dhawan wrote: > hello, > > where would the test case of timer_create() with CLOCK_MONOTONIC be added > ?? > would they be added in > psxtimer01 or psxtimer02 or will it be required to create a new test file > for that? > I would probably just create a new

[PATCH v2] Tests for pthread_getcpuclockid method. Ticket:3891

--- testsuites/psxtests/Makefile.am | 10 ++ testsuites/psxtests/configure.ac | 1 + testsuites/psxtests/psxgetcpuclockid01/init.c | 120 ++ .../psxgetcpuclockid01/psxgetcpuclockid01.doc | 19 +++ .../psxgetcpuclockid01/psxgetcpuclockid01.scn | 4 +

Re: Test for timer_create() with CLOCK_MONOTONIC

Please read the other thread "Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)" Have a look at the RTEMS Test Framework. On Thu, Apr 9, 2020 at 11:31 AM Eshan Dhawan wrote: > > > > On Thu, Apr 9, 2020 at 10:47 PM Joel Sherrill wrote: >> >> >> >> On Thu, Apr 9, 2020 at 12:14 PM Eshan

Re: [PATCH RSB 4/4] qemu-couverture: update to qemu-stable-4.0.0

How was it tested? On Thu, Apr 9, 2020 at 2:22 PM Vijay Kumar Banerjee wrote: > > --- > bare/config/devel/qemu-couverture-git-1.cfg | 16 +--- > bare/config/devel/qemu-couverture.bset | 5 +++-- > 2 files changed, 8 insertions(+), 13 deletions(-) > > diff --git

Re: [PATCH 0/5] Proposes fixes for RTEMS Tester documentation page

Pushed, thanks. On Thu, Apr 9, 2020 at 8:34 AM wrote: > > From: Cláudio Maia > > This set of patches proposes several fixes for RTEMS Tester > documentation. Namely: > > - Text was reviewed and improved for clarity; > - References to 'sparc-rtems5-run' command and 'erc32-run' were removed >

Re: [PATCH v2 0/1] testsuite: A description for each test added

On 09/04/2020 07:52, gabriel.moy...@dlr.de wrote: I am wondering why this patch was not accepted. Is there anything bad or missing? (I was following thishttps://www.mail-archive.com/devel@rtems.org/msg23478.html) Sorry, I just forgot to have a look at this patch. I checked in the patch.

Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

Hello Utkarsh Rai, On 09/04/2020 14:28, Utkarsh Rai wrote: I am willing to add tests for clock_nanosleep with CLOCK_MONOTONIC. What is the standard way of adding test for an already present API but with different configuration? For eg. should I add 'psxtmclocknanosleep04/ 05/ 06' in the

Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

On Thu, Apr 9, 2020, 7:28 AM Utkarsh Rai wrote: > Hi, > I am willing to add tests for clock_nanosleep with CLOCK_MONOTONIC. What > is the standard way of adding test for an already present API but with > different configuration? For eg. should I add 'psxtmclocknanosleep04/ 05/ > 06' in the

Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

Hi, I am willing to add tests for clock_nanosleep with CLOCK_MONOTONIC. What is the standard way of adding test for an already present API but with different configuration? For eg. should I add 'psxtmclocknanosleep04/ 05/ 06' in the testsuite? ___

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

Hello Alan, On 08/04/2020 17:48, Alan Cudmore wrote: Regarding the LEON3: I am noticing something with the release that I don't understand yet. I am able to build and run a number of ARM BSPs including raspberrypi, raspberrypi2, beagleboneblack, and xlinx_zynq_a9_qemu When I build my

Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

On 09/04/2020 14:40, Joel Sherrill wrote: On Thu, Apr 9, 2020, 7:28 AM Utkarsh Rai > wrote: Hi, I am willing to add tests for clock_nanosleep with CLOCK_MONOTONIC. What is the standard way of adding test for an already present  API but with

Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

On 09/04/2020 15:04, Joel Sherrill wrote: On Thu, Apr 9, 2020, 7:43 AM Sebastian Huber > wrote: On 09/04/2020 14:40, Joel Sherrill wrote: On Thu, Apr 9, 2020, 7:28 AM Utkarsh Rai mailto:utkarsh.ra...@gmail.com>> wrote: Hi,

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

Hi Sebastian, Thank you for reproducing this. I added the floating point attribute to my demo tasks and it works as expected. I was just about to try Chris' suggestion of using GDB when I saw this message. I encountered the same problem building the examples with waf. Regards, Alan On Thu, Apr

Re: Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

On Thu, Apr 9, 2020, 7:43 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 09/04/2020 14:40, Joel Sherrill wrote: > > On Thu, Apr 9, 2020, 7:28 AM Utkarsh Rai wrote: > >> Hi, >> I am willing to add tests for clock_nanosleep with CLOCK_MONOTONIC. What >> is the standard way of

Codid Code-in Update (9 April 2020)

Hi I hope this email finds you all well. It has really been nice to see all the patches and test reports flying across the mailing list. If you have patches outstanding with no feedback, ping a core developer. Personally, I have been consumed this week with required training and less responsive

[PATCH v4 2/3] i386: Update build system

- Update FreeBSD files in libbsd.py - Introduce path-mappings in waf_libsd.py and libbsd.py for include path fixes --- libbsd.py | 17 +++-- waf_libbsd.py | 13 +++-- 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/libbsd.py b/libbsd.py index

[PATCH v4 0/3] [5-freebsd-12] Fix compilation for i386

This is the backport for the 5-freebsd-12 branch to make rtems-libbsd compile for i386 again: - It also introduces path-mappings to waf_libbsd.py as introduced here: https://lists.rtems.org/pipermail/devel/2020-February/057457.html Changes compared to v3: - iflib.c: Properly deactivate usage of

[PATCH v4 3/3] i386: Port to RTEMS

- Update imported files to compile rtems-libbsd for i386 based BSPs --- freebsd-org |2 +- freebsd/sbin/sysctl/sysctl.c |8 + freebsd/sys/dev/pci/pci_pci.c|2 + freebsd/sys/i386/i386/legacy.c | 381

Re: [PATCH v4 3/3] i386: Port to RTEMS

> -Ursprüngliche Nachricht- > Von: Sommer, Jan > Gesendet: Donnerstag, 9. April 2020 15:57 > An: devel@rtems.org > Cc: Sommer, Jan > Betreff: [PATCH v4 3/3] i386: Port to RTEMS > > - Update imported files to compile rtems-libbsd for i386 based BSPs > --- [...] > diff --git

AW: [PATCH v4 3/3] i386: Port to RTEMS

> -Ursprüngliche Nachricht- > Von: Sommer, Jan > Gesendet: Donnerstag, 9. April 2020 15:57 > An: devel@rtems.org > Cc: Sommer, Jan > Betreff: [PATCH v4 3/3] i386: Port to RTEMS > > - Update imported files to compile rtems-libbsd for i386 based BSPs > --- > freebsd-org

[PATCH 3/5] user/tools/tester.rst: Clarifies the need of --rtems-tools in rtems-test command line

From: Cláudio Maia --- user/tools/tester.rst | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/user/tools/tester.rst b/user/tools/tester.rst index c07fc49..9f9933a 100644 --- a/user/tools/tester.rst +++ b/user/tools/tester.rst @@ -280,7 +280,6 @@ BSP build tree:

[PATCH 1/5] user/tools/tester.rst: Cleans up text

From: Cláudio Maia --- user/tools/tester.rst | 170 ++ 1 file changed, 90 insertions(+), 80 deletions(-) diff --git a/user/tools/tester.rst b/user/tools/tester.rst index e3a21c9..b77240b 100644 --- a/user/tools/tester.rst +++ b/user/tools/tester.rst @@

[PATCH 5/5] user/tools/tester.rst: Removes text references to 'erc32-run' and replaces the example with 'erc32-sis'

From: Cláudio Maia --- user/tools/tester.rst | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/user/tools/tester.rst b/user/tools/tester.rst index 153809f..e00eb0d 100644 --- a/user/tools/tester.rst +++ b/user/tools/tester.rst @@ -61,9 +61,7 @@ You can list the

[PATCH 2/5] user/tools/tester.rst: Removes wrong reference to GDB

From: Cláudio Maia --- user/tools/tester.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/user/tools/tester.rst b/user/tools/tester.rst index b77240b..c07fc49 100644 --- a/user/tools/tester.rst +++ b/user/tools/tester.rst @@ -259,9 +259,6 @@ You can see your executable running in the

[PATCH 0/5] Proposes fixes for RTEMS Tester documentation page

From: Cláudio Maia This set of patches proposes several fixes for RTEMS Tester documentation. Namely: - Text was reviewed and improved for clarity; - References to 'sparc-rtems5-run' command and 'erc32-run' were removed from the documentation page. Now, the example uses 'erc32-sis' instead.

[PATCH 4/5] user/tools/tester.rst: Removes example using 'sparc-rtems5-run'

From: Cláudio Maia --- user/tools/tester.rst | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/user/tools/tester.rst b/user/tools/tester.rst index 9f9933a..153809f 100644 --- a/user/tools/tester.rst +++ b/user/tools/tester.rst @@ -97,19 +97,7 @@ make finishes,

Re: Use weak functions in the RTEMS core?

On Thu, Apr 9, 2020 at 9:25 AM Gedare Bloom wrote: > On Wed, Apr 8, 2020 at 10:53 PM Sebastian Huber > wrote: > > > > On 09/04/2020 03:32, Chris Johns wrote: > > > > > On 2020-04-09 03:43, Sebastian Huber wrote: > > >> On 08/04/2020 19:34, Jonathan Brandmeyer wrote: > > >>> Instead of treating

Re: Use weak functions in the RTEMS core?

On Wed, Apr 8, 2020 at 10:53 PM Sebastian Huber wrote: > > On 09/04/2020 03:32, Chris Johns wrote: > > > On 2020-04-09 03:43, Sebastian Huber wrote: > >> On 08/04/2020 19:34, Jonathan Brandmeyer wrote: > >>> Instead of treating weak references as a single level of > >>> indirection, I think you