Re: Test suite's minimum sample has no test banners

[Chris Johns]

On 20/09/2017 15:08, Chris Johns wrote:
> 
> Is it worth running? I am wondering about hard coding a filter to not run it 
> in
> rtems-test runs.
> 

I have add test failure exceptions and minimum is the only hard coded entry. If
this test runs and does not time out it is marked as a pass.

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

[PATCH] RTEMS: Make pthread_barrier_t self-contained

[Sebastian Huber]

Signed-off-by: Sebastian Huber 
---
 newlib/libc/sys/rtems/include/sys/_pthreadtypes.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/newlib/libc/sys/rtems/include/sys/_pthreadtypes.h 
b/newlib/libc/sys/rtems/include/sys/_pthreadtypes.h
index 9db50fe44..6ffedaebf 100644
--- a/newlib/libc/sys/rtems/include/sys/_pthreadtypes.h
+++ b/newlib/libc/sys/rtems/include/sys/_pthreadtypes.h
@@ -179,7 +179,13 @@ typedef struct {
 /* POSIX Barrier Types */
 
 #if defined(_POSIX_BARRIERS)
-typedef __uint32_t pthread_barrier_t;/* POSIX Barrier Object */
+typedef struct {
+  unsigned long _flags;
+  unsigned int _count;
+  unsigned int _waiting_threads;
+  struct _Thread_queue_Queue _Queue;
+} pthread_barrier_t;
+
 typedef struct {
   int   is_initialized;  /* is this structure initialized? */
 #if defined(_POSIX_THREAD_PROCESS_SHARED)
-- 
2.12.3

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

[PATCH] posix: Implement self-contained POSIX barriers

[Sebastian Huber]

Update #3114.
---
 cpukit/libcsupport/include/rtems/libcsupport.h|   1 -
 cpukit/libcsupport/src/resource_snapshot.c|   1 -
 cpukit/posix/Makefile.am  |   3 +-
 cpukit/posix/include/rtems/posix/barrier.h|  64 -
 cpukit/posix/include/rtems/posix/barrierimpl.h|  87 ++---
 cpukit/posix/include/rtems/posix/config.h |   6 --
 cpukit/posix/preinstall.am|   4 -
 cpukit/posix/src/pbarrier.c   |  51 --
 cpukit/posix/src/pbarrierdestroy.c|  44 +++--
 cpukit/posix/src/pbarrierinit.c   | 109 +-
 cpukit/posix/src/pbarrierwait.c   |  58 +++-
 cpukit/rtems/src/rtemsobjectgetapiclassname.c |   1 -
 cpukit/sapi/include/confdefs.h|  25 -
 cpukit/score/include/rtems/score/objectimpl.h |   1 -
 cpukit/score/include/rtems/sysinit.h  |   1 -
 testsuites/psxtests/psxbarrier01/main.c   |   2 -
 testsuites/psxtests/psxbarrier01/psxbarrier01.scn |   7 +-
 testsuites/psxtests/psxbarrier01/test.c   |  82 +++-
 testsuites/psxtests/psxconfig01/init.c|  13 ---
 testsuites/psxtmtests/psxtmbarrier01/init.c   |   1 -
 testsuites/psxtmtests/psxtmbarrier02/init.c   |   1 -
 testsuites/psxtmtests/psxtmbarrier03/init.c   |   1 -
 testsuites/psxtmtests/psxtmbarrier04/init.c   |   1 -
 testsuites/sptests/spsysinit01/init.c |  16 
 24 files changed, 208 insertions(+), 372 deletions(-)
 delete mode 100644 cpukit/posix/include/rtems/posix/barrier.h
 delete mode 100644 cpukit/posix/src/pbarrier.c

diff --git a/cpukit/libcsupport/include/rtems/libcsupport.h 
b/cpukit/libcsupport/include/rtems/libcsupport.h
index e51b250f13..ace61c5c0d 100644
--- a/cpukit/libcsupport/include/rtems/libcsupport.h
+++ b/cpukit/libcsupport/include/rtems/libcsupport.h
@@ -111,7 +111,6 @@ typedef struct {
 } rtems_resource_rtems_api;
 
 typedef struct {
-  uint32_t active_barriers;
   uint32_t active_condition_variables;
   uint32_t active_message_queues;
   uint32_t active_mutexes;
diff --git a/cpukit/libcsupport/src/resource_snapshot.c 
b/cpukit/libcsupport/src/resource_snapshot.c
index 9e026ff222..87d4a0108a 100644
--- a/cpukit/libcsupport/src/resource_snapshot.c
+++ b/cpukit/libcsupport/src/resource_snapshot.c
@@ -69,7 +69,6 @@ static const struct {
   { OBJECTS_CLASSIC_API, OBJECTS_RTEMS_TIMERS }
   #ifdef RTEMS_POSIX_API
 ,
-{ OBJECTS_POSIX_API, OBJECTS_POSIX_BARRIERS },
 { OBJECTS_POSIX_API, OBJECTS_POSIX_CONDITION_VARIABLES },
 { OBJECTS_POSIX_API, OBJECTS_POSIX_MESSAGE_QUEUES },
 { OBJECTS_POSIX_API, OBJECTS_POSIX_MUTEXES },
diff --git a/cpukit/posix/Makefile.am b/cpukit/posix/Makefile.am
index 2c88dbbc19..5f76ecc1d4 100644
--- a/cpukit/posix/Makefile.am
+++ b/cpukit/posix/Makefile.am
@@ -49,7 +49,6 @@ include_rtems_posix_HEADERS += 
include/rtems/posix/semaphoreimpl.h
 include_rtems_posix_HEADERS += include/rtems/posix/threadsup.h
 include_rtems_posix_HEADERS += include/rtems/posix/timer.h
 include_rtems_posix_HEADERS += include/rtems/posix/timerimpl.h
-include_rtems_posix_HEADERS += include/rtems/posix/barrier.h
 include_rtems_posix_HEADERS += include/rtems/posix/barrierimpl.h
 include_rtems_posix_HEADERS += include/rtems/posix/rwlock.h
 include_rtems_posix_HEADERS += include/rtems/posix/rwlockimpl.h
@@ -73,7 +72,7 @@ libposix_a_SOURCES +=  src/pthreadatfork.c
 
 ## BARRIER_C_FILES
 libposix_a_SOURCES += src/barrierattrdestroy.c src/barrierattrgetpshared.c \
-src/barrierattrinit.c src/barrierattrsetpshared.c src/pbarrier.c \
+src/barrierattrinit.c src/barrierattrsetpshared.c \
 src/pbarrierdestroy.c src/pbarrierinit.c \
 src/pbarrierwait.c
 
diff --git a/cpukit/posix/include/rtems/posix/barrier.h 
b/cpukit/posix/include/rtems/posix/barrier.h
deleted file mode 100644
index e445586511..00
--- a/cpukit/posix/include/rtems/posix/barrier.h
+++ /dev/null
@@ -1,64 +0,0 @@
-/**
- * @file
- * 
- * @brief Constants and Structures Associated with the POSIX Barrier Manager
- *
- * This include file contains all the constants and structures associated
- * with the POSIX Barrier Manager.
- *
- * Directives provided are:
- *
- *  - create a barrier
- *  - delete a barrier
- *  - wait for a barrier
- */
-
-/*
- *  COPYRIGHT (c) 1989-2011.
- *  On-Line Applications Research Corporation (OAR).
- *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
- */
-
-#ifndef _RTEMS_POSIX_BARRIER_H
-#define _RTEMS_POSIX_BARRIER_H
-
-#include 
-#include 
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/**
- * @defgroup POSIXBarrier POSIX Barriers
- *
- * @ingroup POSIXAPI
- *
- * This encapsulates functionality which implements the RTEMS API
- * Barrier Manager.
- * 
- */
-/**@{**/
-
-/**
- * This type defines the control

Re: Test suite's minimum sample has no test banners

[Joel Sherrill]

On Thu, Sep 21, 2017 at 2:27 AM, Chris Johns  wrote:

> On 20/09/2017 15:08, Chris Johns wrote:
> >
> > Is it worth running? I am wondering about hard coding a filter to not
> run it in
> > rtems-test runs.
> >
>
> I have add test failure exceptions and minimum is the only hard coded
> entry. If
> this test runs and does not time out it is marked as a pass.
>

The intent of this test is to demonstrate the smallest executable and
data size possible.

Looking at the sizes on a few BSPs this morning, I wonder why it is
so large:

  textdata bss dec hex filename
  45792 8803088   49760c260 erc32/.../minimum.exe
  49344 8886896   57128df28 jmr3904/.../minimum.exe
  660001220 1670996816777188 e4 psim/.../minimum.exe
  768321008 268341188   268419028   fffbfd4
xilinx_zynq_a9_qemu/.../minimum.exe

Any ideas where the large .text size is coming from?

--joel

>
> Chris
> ___
> 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

[GR712 - LEON3] Spacewire Interrupts with RTEMS

[Yannick SARTHOU]

Hi,


I am running RTEMS 4.10 on a LEON3 processor.

Has anyone succeeded in making interruptions with SPW up and running ?

Because I am quite stuck there, the example in RTEMS (rtems_irq.c) is 
not designed for LEON3 and in the drivers documentation given by 
Gaisler, they say that we can connect a virtual interrupt to a spw node, 
this virtual interrupt can be connected to a gpio that will fire the 
interrupt but it is really a mess and there is no example given...



Thank you in advance for any tips !

Best regards,

Yannick.

--
Yannick Sarthou

*Yannick Sarthou *
Informatique

   *EREMS *
   /13, Chemin de la Madeleine - ZI
   31130 - Flourens – France /
   *Web :* http://www.erems.fr 
   *Tel :* +33 (0)5 61 36 06 06
   *Fax :* +33 (0)5 61 83 99 45
   *Mail :* yannick.sart...@erems.fr
    



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

Re: Test suite's minimum sample has no test banners

[Chris Johns]

On 22/09/2017 01:24, Joel Sherrill wrote:
> 
> The intent of this test is to demonstrate the smallest executable and 
> data size possible.  
> 

That runs?

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

Re: Test suite's minimum sample has no test banners

[Joel Sherrill]

On Sep 21, 2017 6:30 PM, "Chris Johns"  wrote:

On 22/09/2017 01:24, Joel Sherrill wrote:
>
> The intent of this test is to demonstrate the smallest executable and
> data size possible.
>

That runs?


Yes. There is no requirement that an RTEMS application include the test
framework or even a console driver.


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

Re: Test suite's minimum sample has no test banners

[Chris Johns]

On 22/09/2017 12:30, Joel Sherrill wrote:
> Yes. There is no requirement that an RTEMS application include the test
> framework or even a console driver.

Agreed. I have made it a pass if the target does not time out.

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

Re: [GR712 - LEON3] Spacewire Interrupts with RTEMS

[Sebastian Huber]

Hello Yannick,

if you want to use the GR712RC, then I would definitely update to RTEMS 
4.12. Gaisler integrated all their drivers and they are now up to date. 
In addition the GCC used with RTEMS 4.12 contains an errata fix for the 
GR712RC.



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

BBB u-boot

[Chris Johns]

Hi,

I built u-boot from the git master repo for the Beaglebone Black and I have been
working with an RTEMS u-boot type image plus a local patch to by pass
`bsp_fdt_copy` that is now called for this board. With the change there is a
crash as `r3` is not valid with the RTEMS OS entry.

I have also tested a Linux image format and the kernel crashes early in
`bsp_start_hook_1`. This is with the same patch to by pass `bsp_fdt_copy`.

What configuration was used to test the GSoC code?

The change to add `bsp_fdt_copy` has created an inconsistency because u-boot
master has support for RTEMS images which uses the RTEMS OS boot entry and the
parameters used for that call are different to the ARM specific Linux entry
parameters. It is sensible for someone, me in this case, to use an RTEMS image
on RTEMS however this hidden dependence on a Linux type image makes using RTEMS
difficult. I am ok with having the upstream u-boot RTEMS OS support removed
however we need to have a working BBB before this can happen.

I have created https://devel.rtems.org/ticket/3152 to track the issue.

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

Re: BBB u-boot

[Sichen Zhao]

> Hi,
>
> I built u-boot from the git master repo for the Beaglebone Black and I have 
> been
> working with an RTEMS u-boot type image plus a local patch to by pass
> `bsp_fdt_copy` that is now called for this board. With the change there is a
> crash as `r3` is not valid with the RTEMS OS entry.
>
> I have also tested a Linux image format and the kernel crashes early in
> `bsp_start_hook_1`. This is with the same patch to by pass `bsp_fdt_copy`.
>
> What configuration was used to test the GSoC code?
Can you please tell me which version of u-boot you used?
My version is old: U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 
13:23:54)

Best regards
Sichen
>
> The change to add `bsp_fdt_copy` has created an inconsistency because u-boot
> master has support for RTEMS images which uses the RTEMS OS boot entry and the
> parameters used for that call are different to the ARM specific Linux entry
> parameters. It is sensible for someone, me in this case, to use an RTEMS image
> on RTEMS however this hidden dependence on a Linux type image makes using 
> RTEMS
> difficult. I am ok with having the upstream u-boot RTEMS OS support removed
> however we need to have a working BBB before this can happen.
>
> I have created https://devel.rtems.org/ticket/3152 to track the issue.
>
> Chris
> ___
> 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: BBB u-boot

[Chris Johns]

On 22/09/2017 16:13, Sichen Zhao wrote:
> Can you please tell me which version of u-boot you used?
> My version is old: U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 
> 13:23:54)

I built git://git.denx.de/u-boot.git master and I think commit
8a1c44271c55961fb70fb6177f9c02fdb05287c5. Looking at the trace in a little more
detail I see `U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53)` which seems wrong.
I am now confused.

My uEnv.txt is being read from the mmc ...

] gpio: pin 53 (gpio 53) value is 1
] mmc0 is current device
] micro SD card found
] mmc0 is current device
] gpio: pin 54 (gpio 54) value is 1
] SD/MMC found on device 0
] reading uEnv.txt
] 182 bytes read in 3 ms (58.6 KiB/s)
] Loaded environment from uEnv.txt

That is how I am controlling the boot. Could I be booting from the on-chip 
flash?

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