date:20170920

Re: Self-contained POSIX synchronization objects for RTEMS 4.12?

2017-09-20 Thread Chris Johns

On 20/9/17 3:48 pm, Sebastian Huber wrote:
> There are some checks that help to debug broken applications. For example the
> heap protection, the deadlock detection, the file descriptor reference 
> counting
> and simple parameter validation. 

Yes I agree some of these are useful and I am not against mechanisms being added
to allow support however I feel grouping support that is consider user friendly
under RTEMS_DEBUG is bending it's usage and leaves the user in an awkward
position of leaving the option on or off for production.

Adding more compile options increases the time we need to spent testing the
combinations. A rtems-bsp-builder run with `--profile=everything --build=all`
has 1552 separate builds and 2.2M object files and took almost 7hr on a fast
machine. That is 16 seconds a BSP on average.

I am not offering a solution here, just raising the issues I see. How we name
this is important.

> A correct application doesn't need these checks
> and simply encounters a run-time penalty and some space overhead, but it 
> should
> be tolerable.

That is true if what is controlled by the switch is what we say it is. This
becomes a key issue for anyone auditing the code.

> However, some internal consistency checks, e.g. for the SMP locks,
> are quite heavy weight and really hurt the performance.

Understood.

> From my experience SMP applications are quite sensitive to the performance of
> mutexes. For example, the glibc POSIX mutex is heavily performance optimized,

Agreed.

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

Re: pthread_getattr_np does not work

2017-09-20 Thread Sebastian Huber


On 20/09/17 09:07, xuelin.t...@qkmtech.com wrote:

I am not sure this is a bug or I just use it in a wrong way. If anyone 
has encountered the same situation like me, I will send a ticket.


Your use case looks all right, if this doesn't work, then its a bug from 
my point of view.


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

[PATCH] posix: Implement self-contained POSIX semaphores

2017-09-20 Thread Sebastian Huber

For semaphore object pointer and object validation see
POSIX_SEMAPHORE_VALIDATE_OBJECT().

Destruction or close of a busy semaphore returns an error status.  The
object is not flushed.

Update #3116.
---
 cpukit/posix/Makefile.am |   3 +-
 cpukit/posix/include/rtems/posix/semaphore.h |  18 +-
 cpukit/posix/include/rtems/posix/semaphoreimpl.h |  82 
 cpukit/posix/src/semaphore.c |  14 +-
 cpukit/posix/src/semaphorecreatesupp.c   | 102 --
 cpukit/posix/src/semaphoredeletesupp.c   |  13 +-
 cpukit/posix/src/semaphorewaitsupp.c |  53 -
 cpukit/posix/src/semclose.c  |  33 ++--
 cpukit/posix/src/semdestroy.c|  31 +--
 cpukit/posix/src/semgetvalue.c   |  33 ++--
 cpukit/posix/src/seminit.c   |  28 +--
 cpukit/posix/src/semopen.c   |  86 +---
 cpukit/posix/src/sempost.c   |  60 --
 cpukit/posix/src/semtimedwait.c  |  97 -
 cpukit/posix/src/semtrywait.c|  36 ++--
 cpukit/posix/src/semunlink.c |  13 +-
 cpukit/posix/src/semwait.c   |  18 +-
 cpukit/score/Makefile.am |   1 +
 cpukit/score/include/rtems/score/semaphoreimpl.h |  73 +++
 cpukit/score/preinstall.am   |   4 +
 cpukit/score/src/semaphore.c |  73 ++-
 testsuites/psxtests/psxsem01/init.c  | 241 +--
 testsuites/sptests/spthreadq01/init.c|  16 --
 23 files changed, 591 insertions(+), 537 deletions(-)
 delete mode 100644 cpukit/posix/src/semaphorecreatesupp.c
 delete mode 100644 cpukit/posix/src/semaphorewaitsupp.c
 create mode 100644 cpukit/score/include/rtems/score/semaphoreimpl.h

diff --git a/cpukit/posix/Makefile.am b/cpukit/posix/Makefile.am
index 3bb5bd29f9..2c88dbbc19 100644
--- a/cpukit/posix/Makefile.am
+++ b/cpukit/posix/Makefile.am
@@ -199,9 +199,8 @@ libposix_a_SOURCES += src/prwlock.c src/prwlockdestroy.c 
src/prwlockinit.c \
 src/rwlockattrinit.c src/rwlockattrsetpshared.c
 
 ## SEMAPHORE_C_FILES
-libposix_a_SOURCES += src/semaphore.c src/semaphorecreatesupp.c \
+libposix_a_SOURCES += src/semaphore.c \
 src/semaphoredeletesupp.c \
-src/semaphorewaitsupp.c \
 src/semclose.c src/semdestroy.c src/semgetvalue.c src/seminit.c \
 src/semopen.c src/sempost.c src/semtimedwait.c src/semtrywait.c \
 src/semunlink.c src/semwait.c
diff --git a/cpukit/posix/include/rtems/posix/semaphore.h 
b/cpukit/posix/include/rtems/posix/semaphore.h
index 6598397052..9133db22be 100644
--- a/cpukit/posix/include/rtems/posix/semaphore.h
+++ b/cpukit/posix/include/rtems/posix/semaphore.h
@@ -21,7 +21,6 @@
 
 #include 
 #include 
-#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -41,19 +40,10 @@ extern "C" {
  */
 
 typedef struct {
-   Objects_Control Object;
-   CORE_semaphore_Control  Semaphore;
-   boolnamed;
-   boollinked;
-   uint32_topen_count;
-   /*
-*  sem_t is 32-bit.  If Object_Id is 16-bit, then they are not
-*  interchangeable.  We have to be able to return a pointer to
-*  a 32-bit form of the 16-bit Id.
-*/
-   #if defined(RTEMS_USE_16_BIT_OBJECT)
- sem_t Semaphore_id;
-   #endif
+   Objects_Control Object;
+   sem_t   Semaphore;
+   boollinked;
+   uint32_topen_count;
 }  POSIX_Semaphore_Control;
 
 /** @} */
diff --git a/cpukit/posix/include/rtems/posix/semaphoreimpl.h 
b/cpukit/posix/include/rtems/posix/semaphoreimpl.h
index 43440298ec..fd17743699 100644
--- a/cpukit/posix/include/rtems/posix/semaphoreimpl.h
+++ b/cpukit/posix/include/rtems/posix/semaphoreimpl.h
@@ -21,7 +21,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -29,13 +29,17 @@ extern "C" {
 #endif
 
 /**
+ * @brief This is a random number used to check if a semaphore object is
+ * properly initialized.
+ */
+#define POSIX_SEMAPHORE_MAGIC 0x5d367fe7UL
+
+/**
  *  This defines the information control block used to manage
  *  this class of objects.
  */
 extern Objects_Information _POSIX_Semaphore_Information;
 
-#define POSIX_SEMAPHORE_TQ_OPERATIONS &_Thread_queue_Operations_FIFO
-
 RTEMS_INLINE_ROUTINE POSIX_Semaphore_Control *
   _POSIX_Semaphore_Allocate_unprotected( void )
 {
@@ -57,54 +61,46 @@ RTEMS_INLINE_ROUTINE void _POSIX_Semaphore_Free (
 }
 
 RTEMS_INLINE_ROUTINE POSIX_Semaphore_Control *_POSIX_Semaphore_Get(
-  const sem_t  *id,
-  Thread_queue_Context *queue_context
+  sem_t *sem
 )
 {
-  _Thread_queue_Context_initialize( queue_context );
-  return (POSIX_Semaphore_Control *) _Objects_Get(
-(Objects_Id) *id,
-&queue_context->Lock_context.Lock_context,
-&_POSIX_Semaphore_Information
-  );
+  return RTEMS_CONTAINER_OF( sem, POSIX_Semaphore_Control, Semaphore );
 }

[PATCH] RTEMS: Make sem_t self-contained

2017-09-20 Thread Sebastian Huber

Signed-off-by: Sebastian Huber 
---
 newlib/libc/sys/rtems/include/semaphore.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/newlib/libc/sys/rtems/include/semaphore.h 
b/newlib/libc/sys/rtems/include/semaphore.h
index e3c61da04..44ecc58f4 100644
--- a/newlib/libc/sys/rtems/include/semaphore.h
+++ b/newlib/libc/sys/rtems/include/semaphore.h
@@ -24,7 +24,7 @@
  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
- * $FreeBSD$
+ * $FreeBSD: head/include/semaphore.h 314424 2017-02-28 21:47:00Z vangyzen $
  */
 
 /* semaphore.h: POSIX 1003.1b semaphores */
@@ -33,10 +33,14 @@
 #define _SEMAPHORE_H_
 
 #include 
+#include 
 #include 
 #include 
 
-typedef__uint32_t  sem_t;
+typedef struct {
+   unsigned long _flags;
+   struct _Semaphore_Control _Semaphore;
+} sem_t;
 
 #defineSEM_FAILED  ((sem_t *)0)
 
-- 
2.12.3

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

Re: Many BSPs Fail with Debug Enabled

2017-09-20 Thread Sebastian Huber


On 19/09/17 21:18, Joel Sherrill wrote:


Hi

I am starting to investigate the failures but 41 BSPs fail to
build with --enable-rtems-debug and --enable-tests=all.

Some fail because tests are too large to fit with debug enabled.

These fail with an error related to bsp_interrupt_assert:

log/powerpc-mpc8260ads.log
log/powerpc-psim.log
log/powerpc-qemuppc.log


I fixed this.



These fail with an error about bsp_interrupt_dispatch:
log/arm-raspberrypi2.log
log/arm-raspberrypi.log


I didn't get these errors.


log/powerpc-beatnik.log
log/powerpc-brs5l.log
log/powerpc-brs6l.log
log/powerpc-br_uid.log
log/powerpc-dp2.log
log/powerpc-haleakala.log
log/powerpc-hsc_cm01.log
log/powerpc-icecube.log
log/powerpc-mcp750.log
log/powerpc-mpc8309som.log
log/powerpc-mpc8313erdb.log
log/powerpc-mpc8349eamds.log
log/powerpc-mtx603e.log
log/powerpc-mvme2100.log
log/powerpc-mvme2307.log
log/powerpc-mvme3100.log
log/powerpc-mvme5500.log
log/powerpc-pghplus.log
log/powerpc-pm520_cr825.log
log/powerpc-pm520_ze30.log
log/powerpc-qemuprep-altivec.log
log/powerpc-qemuprep.log
log/powerpc-t32mppc.log
log/powerpc-tqm8xx_stk8xx.log
log/powerpc-virtex4.log
log/powerpc-virtex5.log
log/powerpc-virtex.log


I fixed them except t32mppc. I will have a look at this tomorrow.

--
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: RTEMS Tester Kit

2017-09-20 Thread Alan Cudmore

Hi Chris,
Lurking RPi Linux user here..

Are you talking about having the RPI control the reset line to one or more
targets?
Would a GPIO pin be sufficient for that, or would we need another output?

Also, what would the serial port on the Pi be used for? Would it connect to
a test target serial port and host the ser2net program?

Alan






On Tue, Sep 19, 2017 at 7:35 PM, Chris Johns  wrote:

> Hi,
>
> I am currently looking into getting `rtems-test` to support TFTP loading of
> tests to targets that support networking with bootloaders like u-boot that
> can
> boot executables.
>
> I have added a TFTP server implemented in python to the `rtems-test`
> command and
> each request to the server sends the next test so the tester can cycling
> through
> all the tests. The file requested by the target is ignored.
>
> I have also added telnet as a tty console so you can get serial data via
> telnet.
> This integrates with the rather useful ser2net package that is widely
> available.
>
> If you combine TFTP and telnet you have a nice clean way to support target
> testing. The loading is fast, the connections to the testing host is all
> via the
> network and there is no extra complexity of JTAG and related software or
> the
> need to write to flash devices that can fail or wear.
>
> However there is a simple but important piece missing, recovery when a test
> fails due to the target locking up. There needs to be a way to reset the
> board.
>
> I can add support to the configuration file to use a script that can
> interface
> to networked power switches and the power can be toggled. This is support
> needs
> to be added however these devices and often slow and some targets do not
> take
> kindly to lots of power cycles. Another solution would be some way to
> toggle an
> output that can be connected to the reset of a board. Most boards have
> reset on
> a pin we could connect too.
>
> I was wondering about a RPi with a commonly available IO board and a Linux
> image
> we provide as an SD image we document as a standard test support kit. The
> RPi
> could have ser2net ready to go and a way to control outputs via telnet.
>
> I know there are RPi Linux users lurking in our community so I am wanting
> to
> draw on the expertise we have to create a small project to do this.
>
> To highlight the importance testing of master (4.12) on real hardware, I
> spot
> checked on a Beaglebone Black yesterday a few tests and I have found
> minimum and
> dl02 do not finish. That is 2 out of 10 or so tests I have tried that
> fails.
>
> I am after ideas for hardware, software and most all volunteers. Please
> join in.
>
> 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: Many BSPs Fail with Debug Enabled

2017-09-20 Thread Joel Sherrill

Thanks for fixing so many. Now it is down to these failures.

These are BSPs where enabling debug resulted in more tests not
fitting. Do we add all of these test build/link failures to the tcfg?

log/arm-lm3s3749.log
log/arm-lpc1768_mbed_ahb_ram_eth.log
log/arm-lpc2362.log
log/arm-lpc23xx_tli800.log
log/arm-lpc24xx_ncs_rom_int.log
log/arm-lpc24xx_plx800_rom_int.log
log/arm-lpc32xx_mzx_stage_1.log
log/arm-rtl22xx_t.log
log/arm-tms570ls3137_hdk_intram.log
log/m68k-mcf52235.log
log/m68k-mcf5225x.log

This is a real build failure:

log/powerpc-t32mppc.log

../../../../../t32mppc/lib/start.o: In function `bsp_exc_vector_base':
/home/joel/rtems-work/rtems-testing/rtems/build-powerpc-t32mppc-rtems/powerpc-rtems4.12/c/t32mppc/lib/libbsp/powerpc/t32mppc/../../../../../../../../rtems/c/src/lib/libbsp/powerpc/t32mppc/start/start.S:117:
undefined reference to `ppc_exc_interrupt'

All Raspberry Pi BSP variants built. Not sure what happened
on those before.

--joel


On Wed, Sep 20, 2017 at 9:03 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19/09/17 21:18, Joel Sherrill wrote:
>
> Hi
>>
>> I am starting to investigate the failures but 41 BSPs fail to
>> build with --enable-rtems-debug and --enable-tests=all.
>>
>> Some fail because tests are too large to fit with debug enabled.
>>
>> These fail with an error related to bsp_interrupt_assert:
>>
>> log/powerpc-mpc8260ads.log
>> log/powerpc-psim.log
>> log/powerpc-qemuppc.log
>>
>
> I fixed this.
>
>
>> These fail with an error about bsp_interrupt_dispatch:
>> log/arm-raspberrypi2.log
>> log/arm-raspberrypi.log
>>
>
> I didn't get these errors.
>
>
> log/powerpc-beatnik.log
>> log/powerpc-brs5l.log
>> log/powerpc-brs6l.log
>> log/powerpc-br_uid.log
>> log/powerpc-dp2.log
>> log/powerpc-haleakala.log
>> log/powerpc-hsc_cm01.log
>> log/powerpc-icecube.log
>> log/powerpc-mcp750.log
>> log/powerpc-mpc8309som.log
>> log/powerpc-mpc8313erdb.log
>> log/powerpc-mpc8349eamds.log
>> log/powerpc-mtx603e.log
>> log/powerpc-mvme2100.log
>> log/powerpc-mvme2307.log
>> log/powerpc-mvme3100.log
>> log/powerpc-mvme5500.log
>> log/powerpc-pghplus.log
>> log/powerpc-pm520_cr825.log
>> log/powerpc-pm520_ze30.log
>> log/powerpc-qemuprep-altivec.log
>> log/powerpc-qemuprep.log
>> log/powerpc-t32mppc.log
>> log/powerpc-tqm8xx_stk8xx.log
>> log/powerpc-virtex4.log
>> log/powerpc-virtex5.log
>> log/powerpc-virtex.log
>>
>
> I fixed them except t32mppc. I will have a look at this t
> omorrow.
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS Tester Kit

2017-09-20 Thread Chris Johns

On 21/09/2017 03:21, Alan Cudmore wrote:
> Lurking RPi Linux user here..

Nice and thanks for responding.

> Are you talking about having the RPI control the reset line to one or more 
> targets?

Yes. I was thinking about insecure telnet access to pulse a GPIO pin.

> Would a GPIO pin be sufficient for that, or would we need another output?

It could be. I was wondering if we want a board with some signal conditioned IO
so we can match voltages or even have micro-switches to avoid any issues with
the hardware we interface to. I am thinking about 3V3, 5V or some other voltage
plus the ability of the RPi CPU to sink enough current. It would make the kit
more robust and help avoid users killing the RPi or their target. May be a RPi
is cheap enough we do not need to be concerned.

> Also, what would the serial port on the Pi be used for? Would it connect to a
> test target serial port and host the ser2net program?

You could use the serial port on the RPi. I have a RPi running FreeBSD with a
couple of large powered USB hubs and I have many ports attached. The RPi runs
ser2net so I can get remote access to arond 15 ports. Boards like the RPi and
Beaglebone Black have TTL serial pins or headers and you can buy inexpensive TTL
serial to USB cables.

I am still working on rtems-test however the results so far look good. I am now
even wondering if I could group targets together and run tests in parallel to
speed things up.

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

Re: Self-contained POSIX synchronization objects for RTEMS 4.12?

Re: pthread_getattr_np does not work

[PATCH] posix: Implement self-contained POSIX semaphores

[PATCH] RTEMS: Make sem_t self-contained

Re: Many BSPs Fail with Debug Enabled

Re: RTEMS Tester Kit

Re: Many BSPs Fail with Debug Enabled

Re: RTEMS Tester Kit

8 matches

Site Navigation

Mail list logo

Footer information