On 04.10.19 18:48, Nitin Kulkarni via Xenomai wrote:
Hi,
A few months back I wrote to the mailing list about our attempt to run
Xenomai on IMX8M mini.
We had a bumpy ride but we managed to fix the kernel to run Xenomai.
So we thought it would be helpful to others too and share it with the
mailin
Download URL:
https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.4.192-cip37-x86-18.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.4.192-cip37-x86-18
Hi,
A few months back I wrote to the mailing list about our attempt to run
Xenomai on IMX8M mini.
We had a bumpy ride but we managed to fix the kernel to run Xenomai.
So we thought it would be helpful to others too and share it with the
mailing list.
We identified the irqchip which was causing the
On 04.10.19 17:29, François Legal wrote:
Le Vendredi, Octobre 04, 2019 17:16 CEST, François Legal via Xenomai
a écrit:
Le Vendredi, Octobre 04, 2019 16:31 CEST, Jan Kiszka a
écrit:
On 04.10.19 16:22, François Legal wrote:
Le Vendredi, Octobre 04, 2019 15:36 CEST, Jan Kiszka a
écrit
robe rt$PROTOCOL >/dev/null
> >>>> +else
> >>>> +modprobe rt$PROTOCOL >/dev/null || exit 1
> >>>> +fi
> >>>> +fi
> >>>> +done
> >>>>
Download URL:
https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.75-cip11-x86-7.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.19.75-cip11-x86-7
Download URL:
https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.75-x86-7.patch
Repository: https://git.xenomai.org/ipipe-x86
Release tag: ipipe-core-4.19.75-x86-7
On 04.10.19 16:22, François Legal wrote:
Le Vendredi, Octobre 04, 2019 15:36 CEST, Jan Kiszka a
écrit:
On 04.10.19 13:10, Jan Kiszka wrote:
On 03.10.19 10:10, François Legal via Xenomai wrote:
Subject: [PATCH] Allow RTNet to be builtin kernel
Makefile is changed because when builtin, the
Le Vendredi, Octobre 04, 2019 15:36 CEST, Jan Kiszka a
écrit:
> On 04.10.19 13:10, Jan Kiszka wrote:
> > On 03.10.19 10:10, François Legal via Xenomai wrote:
> >> Subject: [PATCH] Allow RTNet to be builtin kernel
> >>
> >> Makefile is changed because when builtin, the modules
> >> get loaded in
From: Jan Kiszka
This signals if the core supports synchronous stop and resume on
breakpoints. It depends on I-pipe support that is not available for all
architectures and I-pipe kernel version.
Signed-off-by: Jan Kiszka
---
include/cobalt/uapi/corectl.h | 1 +
kernel/cobalt/posix/corectl.c |
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
testsuite/smokey/gdb/gdb.c | 36 +---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/testsuite/smokey/gdb/gdb.c b/testsuite/smokey/gdb/gdb.c
index a6909d595b..33c16fe876 100644
--- a/testsuite/smokey
On 03.10.19 10:43, François Legal via Xenomai wrote:
From: François LEGAL
Subject: [PATCH] Make MACB driver compliant with GEM hardware
Make MACB driver compliant with GEM hardware (as mainline linux
driver does). Main fix is about interrupt flag that is never
cleared (write 1 to clear)
Signed
On 04.10.19 13:10, Jan Kiszka wrote:
On 03.10.19 10:10, François Legal via Xenomai wrote:
Subject: [PATCH] Allow RTNet to be builtin kernel
Makefile is changed because when builtin, the modules
get loaded in the link order. In the previous version
protocols would get loaded before stackmgr whic
On 03.10.19 10:10, François Legal via Xenomai wrote:
> Subject: [PATCH] Allow RTNet to be builtin kernel
>
> Makefile is changed because when builtin, the modules
> get loaded in the link order. In the previous version
> protocols would get loaded before stackmgr which
> obviously fails.
>
> Sign
On 04.10.19 12:41, Laurentiu-Cristian Duca wrote:
I have tested the nomac discipline:
- on rteth0 ethernet traffic has ethernet type = IPv4 = 0x0800
(tested rtping and rtt-sender <-> rtt-responder)
- on vnic0 ethernet traffic has ethernet type 0x9021
(tested using ping and ssh between two rtnet m
I have tested the nomac discipline:
- on rteth0 ethernet traffic has ethernet type = IPv4 = 0x0800
(tested rtping and rtt-sender <-> rtt-responder)
- on vnic0 ethernet traffic has ethernet type 0x9021
(tested using ping and ssh between two rtnet machines)
I captured the traffic with wireshark.
It
On 03.10.19 17:23, Rossier Daniel via Xenomai wrote:
Hi all,
We are currently working on a project called OpenCN which is a framework deeply
inspired from LinuxCNC, but with a revisited architecture.
Hence, OpenCN is related to machine control.
Our framework mainly use a AMP approach and runs
On 03.10.19 15:34, Laurentiu-Cristian Duca via Xenomai wrote:
Hello rtnet dev,
I think I found a bug in RTnet:
ping and non-rt applications (e.g. dropbear) send non-rt traffic via vnic0,
but the ethernet type is 0x9021 (real-time media access control type):
xenomai-3.0.9/kernel/drivers/net/st
18 matches
Mail list logo
