Re: [Xenomai] Looking for training on Linux/Xenomai on i.MX6
Hello Cedric 6 months ago we had similar needs we chose phytec that adapt their training to our specific needs http://www.phytec.fr/services/formation-linux/linux-embarque-drivers-et-temps-reel/ they used i.MX6 for support. Should be interesting for you Regards PR - Mail original - De: "Cédric Perles" À: xenomai@xenomai.org Envoyé: Lundi 6 Mars 2017 08:19:53 Objet: [Xenomai] Looking for training on Linux/Xenomai on i.MX6 Hi, I work for a company based in France (La-Roche-Sur-Yon) that build embedded devices and we are planning to switch from QNX to Linux/Xenomai on i.MX6. I am currently searching for a training center able to teach Linux and Xenomai to all software team (8 people). => Does anyone know a correct training center for this ? => Is there anyone experienced in Xenomai on i.MX6 (tricks, classical traps …) ? Regards, Cédric Sepro Cédric PERLES Software R&D engineer SEPRO Robotique - Rue Henry Bessemer - Zone Acti-Est - CS 10084 - 85003 La Roche sur Yon Cedex (France) Tel : +33 (0)2 51 45 05 31 _ <http://www.sepro-group.com/fr> www.sepro-group.com | <https://twitter.com/seprogroup> twitter@SeproGroup -- next part -- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 22984 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170306/6c2f4669/attachment.jpg> -- next part -- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 818 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170306/6c2f4669/attachment.png> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Looking for training on Linux/Xenomai on i.MX6
On 03/06/2017 09:49 AM, pierre.roumag...@free.fr wrote: > Hello Cedric > > 6 months ago we had similar needs > we chose phytec that adapt their training to our specific needs > > http://www.phytec.fr/services/formation-linux/linux-embarque-drivers-et-temps-reel/ > They may want to consider fixing the section related to real-time support in user-space in this presentation. LXRT has never been a Xenomai thing. -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Looking for training on Linux/Xenomai on i.MX6
We have such a training. Regards -- Pierre FICHEUX -/- CTO Smile-ECS, France -\- pierre.fich...@smile.fr http://www.smile.fr http://ingenierie.openwide.fr I would love to change the world, but they won't give me the source code Le 2017-03-06 08:19, Cédric Perles a écrit : Hi, I work for a company based in France (La-Roche-Sur-Yon) that build embedded devices and we are planning to switch from QNX to Linux/Xenomai on i.MX6. I am currently searching for a training center able to teach Linux and Xenomai to all software team (8 people). => Does anyone know a correct training center for this ? => Is there anyone experienced in Xenomai on i.MX6 (tricks, classical traps …) ? Regards, Cédric Sepro Cédric PERLES Software R&D engineer SEPRO Robotique - Rue Henry Bessemer - Zone Acti-Est - CS 10084 - 85003 La Roche sur Yon Cedex (France) Tel : +33 (0)2 51 45 05 31 _ <http://www.sepro-group.com/fr> www.sepro-group.com | <https://twitter.com/seprogroup> twitter@SeproGroup -- next part -- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 22984 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170306/6c2f4669/attachment.jpg> -- next part -- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 818 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170306/6c2f4669/attachment.png> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] any extra reasons for -EINTR in xenomai
Am Fri, 3 Mar 2017 16:57:04 +0100 schrieb Philippe Gerum : > On 03/03/2017 03:18 PM, Henning Schild wrote: > > Hi, > > > > someone came to me asking about reasons why system calls would exit > > with -EINTR on a xenomai 2 system. As far as i know there a are two > > possible reasons for that to happen. > > 1. the thread received a signal while being blocked in the call > > 2. the thread got a rt_task_unblock > > > > Now we are pretty sure that we can rule out both of these cases. It > > is a complex system and there might be signals. But none of the > > applications signal handlers was called and the application did not > > exit, which only leaves very few signals as candidates. Because > > almost all default signal handlers will end an application. > > And my current assumption would be that default signal handlers > > all have SA_RESTART and there would be no -EINTR. Which limits the > > possible signals to the ones where a custom handler was installed > > and SA_RESTART was not set. But according to the logs no custom > > handler was called. > > > > We know it happened while being blocked in rtdm_event_timedwait and > > the documentation mentions the two reasons from above. > > > > Somebody has to raise the XNBREAK bit in the tcb for this to happen, > i.e. xnthread_set_info(thread, XNBREAK). There are four locations in > the nucleus doing that, two of them happen in do_sigwake_event(). > Tracing there would rule out the consequence of receiving a regular > signal. > > In a related case, entering xnpod_suspend_thread() in a runnable state > with the XNKICKED bit set would also cause the XNBREAK bit to be set, > preventing the caller to block. This should only happen if a signal is > raised from another CPU while the caller is traversing the Xenomai > syscall path. > > Finally, there is xnpod_unblock_thread() but that one won't be called > unless the application forcibly unblocks a thread, which you already > ruled out. Thanks for the analysis. I looked at the code myself and came to the same conclusion. To sum this up the first 3/4 are signal-related and the 4th one is rt_task_unblock. And looking at rtdm_event_timedwait it can clearly just happen under that one condition (XNBREAK). So i guess we are looking at a signal after all. Henning ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Looking for training on Linux/Xenomai on i.MX6
Thank's a lot Pierre. I contact them right now. Sepro<http://extranet.sepro-robotique.com/signatures/Logo_GROUP.jpg> Cédric PERLES Software R&D engineer SEPRO Robotique - Rue Henry Bessemer - Zone Acti-Est - CS 10084 - 85003 La Roche sur Yon Cedex (France) Tel : +33 (0)2 51 45 05 31 www.sepro-group.com <http://www.sepro-group.com/fr> | twitter@SeproGroup <https://twitter.com/seprogroup> -Message d'origine- De : pierre.roumag...@free.fr [mailto:pierre.roumag...@free.fr] Envoyé : lundi 6 mars 2017 09:50 À : Cédric Perles Cc : xenomai@xenomai.org Objet : Re: [Xenomai] Looking for training on Linux/Xenomai on i.MX6 Hello Cedric 6 months ago we had similar needs we chose phytec that adapt their training to our specific needs http://www.phytec.fr/services/formation-linux/linux-embarque-drivers-et-temps-reel/ they used i.MX6 for support. Should be interesting for you Regards PR - Mail original - De: "Cédric Perles" À: xenomai@xenomai.org Envoyé: Lundi 6 Mars 2017 08:19:53 Objet: [Xenomai] Looking for training on Linux/Xenomai on i.MX6 Hi, I work for a company based in France (La-Roche-Sur-Yon) that build embedded devices and we are planning to switch from QNX to Linux/Xenomai on i.MX6. I am currently searching for a training center able to teach Linux and Xenomai to all software team (8 people). => Does anyone know a correct training center for this ? => Is there anyone experienced in Xenomai on i.MX6 (tricks, classical traps …) ? Regards, Cédric Sepro Cédric PERLES Software R&D engineer SEPRO Robotique - Rue Henry Bessemer - Zone Acti-Est - CS 10084 - 85003 La Roche sur Yon Cedex (France) Tel : +33 (0)2 51 45 05 31 _ <http://www.sepro-group.com/fr> www.sepro-group.com | <https://twitter.com/seprogroup> twitter@SeproGroup -- next part -- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 22984 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170306/6c2f4669/attachment.jpg> -- next part -- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 818 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170306/6c2f4669/attachment.png> ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] For 2.6 xenomai, where is scheduler spot for realtime world and linux world?
HI:
thanks for your kindly reply and please regret me if my question seems
foolish for this is my first questions.
for 2.6 xenomai, i know the system is divided into two worlds, the primary(rt)
world and the secondary(linux) world, so may be there is a door like
space-time traveler in science fiction movie. i mean maybe a c code line (or
maybe assemble instuctions) that divided the two world in the source code, so,
if this is true, where is the spot?
and i found a place in gatekeeper_thread, is this line？ i mean, if some
rt-thread is ready, the schedule call would not return and system goes to rt
world,
but when no rt thread being ready, the the "xpod_schedule" call in rt domain
would return back to the schedule of linux world? (precisely is "context_swich"
inline assembly, because schedule call it), am i right?
thanks for your kindly reply again.
static int gatekeeper_thread(void *data)
857 {
858 struct task_struct *this_task = current;
859 int cpu = (long)data;
...
874 for (;;) {
875 up(&sched->gksync); /* Make the request token available. */
876 schedule();
877
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] [PATCH 2/2] lib/cobalt: wrap CXXABI One-time Constructor functions
The implementation of these functions uses locks and has the potential
to trigger a SIGXCPU when contended. Wrap them with assert_nrt so they
reliably cause a switch when used in the rt context.
This is a corrected version of: be90f09cf2770
which got reverted in: 0ef9dbd42d16d
Signed-off-by: Henning Schild
---
lib/cobalt/assert.wrappers | 3 +++
lib/cobalt/assert_context.c | 19 +++
lib/cobalt/internal.h | 12
lib/cobalt/wrappers.c | 19 +++
4 files changed, 53 insertions(+)
diff --git a/lib/cobalt/assert.wrappers b/lib/cobalt/assert.wrappers
index 7164858..65320ab 100644
--- a/lib/cobalt/assert.wrappers
+++ b/lib/cobalt/assert.wrappers
@@ -1,2 +1,5 @@
--wrap malloc
--wrap free
+--wrap __cxa_guard_acquire
+--wrap __cxa_guard_release
+--wrap __cxa_guard_abort
diff --git a/lib/cobalt/assert_context.c b/lib/cobalt/assert_context.c
index 2085953..fd18d6b 100644
--- a/lib/cobalt/assert_context.c
+++ b/lib/cobalt/assert_context.c
@@ -66,3 +66,22 @@ COBALT_IMPL(void, free, (void *ptr))
assert_nrt();
__STD(free(ptr));
}
+
+/* CXXABI 3.3.2 One-time Construction API */
+COBALT_IMPL(int, __cxa_guard_acquire, (__guard *g))
+{
+ assert_nrt();
+ return __STD(__cxa_guard_acquire(g));
+}
+
+COBALT_IMPL(void, __cxa_guard_release, (__guard *g))
+{
+ assert_nrt();
+ __STD(__cxa_guard_release(g));
+}
+
+COBALT_IMPL(void, __cxa_guard_abort, (__guard *g))
+{
+ assert_nrt();
+ __STD(__cxa_guard_abort(g));
+}
diff --git a/lib/cobalt/internal.h b/lib/cobalt/internal.h
index fee3fe1..9f58c6a 100644
--- a/lib/cobalt/internal.h
+++ b/lib/cobalt/internal.h
@@ -73,4 +73,16 @@ void cobalt_check_features(struct cobalt_featinfo *finfo);
extern struct sigaction __cobalt_orig_sigdebug;
+#ifdef __ARM_EABI__
+typedef uint32_t __guard;
+#else
+typedef uint64_t __guard;
+#endif
+int __real___cxa_guard_acquire(__guard*);
+void __real___cxa_guard_release(__guard*);
+void __real___cxa_guard_abort(__guard*);
+int __cxa_guard_acquire(__guard*);
+void __cxa_guard_release(__guard*);
+void __cxa_guard_abort(__guard*);
+
#endif /* _LIB_COBALT_INTERNAL_H */
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index 09c74e5..c43772c 100644
--- a/lib/cobalt/wrappers.c
+++ b/lib/cobalt/wrappers.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
/* sched */
__weak
@@ -532,3 +533,21 @@ unsigned int __real_sleep(unsigned int seconds)
{
return sleep(seconds);
}
+
+__weak
+int __real___cxa_guard_acquire(__guard *g)
+{
+ return __cxa_guard_acquire(g);
+}
+
+__weak
+void __real___cxa_guard_release(__guard *g)
+{
+ return __cxa_guard_release(g);
+}
+
+__weak
+void __real___cxa_guard_abort(__guard *g)
+{
+ return __cxa_guard_abort(g);
+}
--
2.10.2
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] [PATCH 1/2] cobalt: fix for incorrect assert wrappers commit
Fixes: ebc039b62c40e
Be consistent with wrapping the asserts with every compiler invokation.
Now you can add arbitrary symbols to assert.wrappers without the linker
complaining about them missing.
That problem lead me to include weak dummies for libstdc++ functions in
be90f09cf2770 .
Signed-off-by: Henning Schild
---
configure.ac | 13 ++---
scripts/wrap-link.sh | 2 +-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4792e46..70990d2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -799,9 +799,14 @@ dnl in-tree executables which require POSIX symbol
wrapping.
assert_wrappers="$topdir/lib/cobalt/assert.wrappers"
cobalt_wrappers="$topdir/lib/cobalt/cobalt.wrappers"
if [[ $ac_cv_ld_file_option = yes ]]; then
- XENO_POSIX_WRAPPERS="-Wl,@$assert_wrappers -Wl,@$cobalt_wrappers"
+ XENO_POSIX_WRAPPERS="-Wl,@$cobalt_wrappers"
+ XENO_ASSERT_WRAPPERS="-Wl,@$assert_wrappers"
else
- XENO_POSIX_WRAPPERS=`cat $assert_wrappers $cobalt_wrappers | \
+ XENO_POSIX_WRAPPERS=`cat $cobalt_wrappers | \
+ while read wrap_option symbol ; do \
+ echo -n "-Wl,$wrap_option,$symbol " ; \
+ done`
+ XENO_ASSERT_WRAPPERS=`cat $assert_wrappers | \
while read wrap_option symbol ; do \
echo -n "-Wl,$wrap_option,$symbol " ; \
done`
@@ -809,13 +814,15 @@ dnl in-tree executables which require POSIX symbol
wrapping.
AC_SUBST(XENO_POSIX_WRAPPERS)
AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ["$assert_wrappers
$cobalt_wrappers"])
+else
+ XENO_ASSERT_WRAPPERS=""
fi
dnl
dnl Build the Makefiles
dnl
-XENO_AUTOINIT_LDFLAGS='$(top_builddir)/lib/boilerplate/init/bootstrap-internal.o'"
-Wl,--wrap=main -Wl,--dynamic-list=$topdir/scripts/dynlist.ld"
+XENO_AUTOINIT_LDFLAGS='$(top_builddir)/lib/boilerplate/init/bootstrap-internal.o'"
-Wl,--wrap=main -Wl,--dynamic-list=$topdir/scripts/dynlist.ld
$XENO_ASSERT_WRAPPERS"
AC_SUBST(XENO_AUTOINIT_LDFLAGS)
XENO_CORE_LIB=$rtcore_type/lib${rtcore_type}.la
diff --git a/scripts/wrap-link.sh b/scripts/wrap-link.sh
index 1b8c3f4..0e50586 100755
--- a/scripts/wrap-link.sh
+++ b/scripts/wrap-link.sh
@@ -138,7 +138,7 @@ while test $# -gt 0; do
next_is_wrapped_symbol=:
;;
- -Wl,--wrap,main|-Wl,--wrap=main|-Wl,--dynamic-list=*)
+
-Wl,--wrap,main|-Wl,--wrap=main|-Wl,--dynamic-list=*|-Wl,@*assert.wrappers)
# special case so that we can interpose on the main()
# routine. For this we need this wrapping to take place in
# the second stage.
--
2.10.2
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [PATCH 1/2] cobalt: fix for incorrect assert wrappers commit
On 03/06/2017 03:00 PM, Henning Schild wrote: > -XENO_AUTOINIT_LDFLAGS='$(top_builddir)/lib/boilerplate/init/bootstrap-internal.o'" > -Wl,--wrap=main -Wl,--dynamic-list=$topdir/scripts/dynlist.ld" > +XENO_AUTOINIT_LDFLAGS='$(top_builddir)/lib/boilerplate/init/bootstrap-internal.o'" > -Wl,--wrap=main -Wl,--dynamic-list=$topdir/scripts/dynlist.ld > $XENO_ASSERT_WRAPPERS" > AC_SUBST(XENO_AUTOINIT_LDFLAGS) > XENO_AUTOINIT_LDFLAGS is only used internally, inside the Xenomai tree for building utilities and test programs which may want the auto-bootstrap feature on. Is this the intent? -- Philippe. ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [PATCH 1/2] cobalt: fix for incorrect assert wrappers commit
Am Mon, 6 Mar 2017 17:18:23 +0100 schrieb Philippe Gerum : > On 03/06/2017 03:00 PM, Henning Schild wrote: > > > -XENO_AUTOINIT_LDFLAGS='$(top_builddir)/lib/boilerplate/init/bootstrap-internal.o'" > > -Wl,--wrap=main -Wl,--dynamic-list=$topdir/scripts/dynlist.ld" > > +XENO_AUTOINIT_LDFLAGS='$(top_builddir)/lib/boilerplate/init/bootstrap-internal.o'" > > -Wl,--wrap=main -Wl,--dynamic-list=$topdir/scripts/dynlist.ld > > $XENO_ASSERT_WRAPPERS" AC_SUBST(XENO_AUTOINIT_LDFLAGS) > > XENO_AUTOINIT_LDFLAGS is only used internally, inside the Xenomai tree > for building utilities and test programs which may want the > auto-bootstrap feature on. Is this the intent? Honestly, i am not sure where to best put that. And i do not know what the auto-bootstrap feature is. It does solve build problems in the tree i.e. for latency and smokey_net_server. The process of coming up with this version was a lot of looking at "make V=1" and pattern matching to where the flags came from. The build issues can be seen when applying 2/2 from this series on top of current master 027898e4732cb5de. After all the CXXAbi patch should have never come with those dummies. I just put them in because of the above build-problems assuming they would be natural for C-code and that weak symbols could not hurt. Both those assumption where wrong ... Would be nice if you could look at the problems and suggest a better place for the adjusted LDFLGAS. regards, Henning ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] cobalt_call_extension(signal_copyinfo) vs. compat calls
Hi Philippe, while the put_siginfo callback allows to select an appropriate siginfo copying handler, cobalt_call_extension(signal_copyinfo) does not get any information about compat vs. regular calls, right? What is your preference to extend this interface? Pass a compat flag, calculated from put_siginfo != signal_put_siginfo? Straightforward but kind of ugly. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
