* Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
@ 2019-06-05 10:30 danwe
2019-06-06 6:06 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: danwe @ 2019-06-05 10:30 UTC (permalink / raw)
To: xenomai
Hello,
I am using two Beaglebone Black with Linux kernel version 3.8.13 and
Xenomai version 2.6.3. I have built the Kernel with Xenomai and RTnet with
buildroot. At the moment I am trying to use the provided source-files
"rtt-sender" and "rtt-responder" for sending some "Round-Trip Time Request".
I have changed my destination IP in "rtt-responder" to my destination BBB.
I did not do any other changes. Then I did run "rtt-responder" on BBB2 and
"rtt-sender" on BBB1 but I always get the following error:
[image: image.png]
Can anyone tell me why I do get that error?
In order to this I need to say that both BBB's get a random MAC-Adress
after each boot. That means I need to tell each BBB which MAC adress
belongs to which IP-Adress. For example BBB1 has IP 192.168.127.10 with MAC
AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11 with MAC BB:BB:BB:BB:BB I
need to execute the following commands:
For BBB1: rtroute add 192.168.127.11 BB:BB:BB:BB:BB dev rteth0
For BBB2: rtroute add 192.168.127.10 AA:AA:AA:AA:AA dev rteth0
Now it is possible to send rtpings with the command: rtping 192.168.127.10
or rtping 192.168.127.11. Depens on which BBB you want to send the ping.
So my idea was it is only possible to run the "rtt-sender" and
"rtt-responder" file when my BBB's know which MAC belongs to which IP.
But there is still the error, that the Network is unreachable. Why?
You can find the source-files enclosed.
Kind Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13271 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtt-sender.c
Type: application/octet-stream
Size: 9879 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtt-responder.c
Type: application/octet-stream
Size: 5705 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-05 10:30 Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black danwe
@ 2019-06-06 6:06 ` Jan Kiszka
[not found] ` <CAEmXcAxuFzE2uQHGMUjBnbgadTTcNU_DwV64uvLPahxxDMKTyQ@mail.gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-06-06 6:06 UTC (permalink / raw)
To: danwe, xenomai
On 05.06.19 12:30, danwe via Xenomai wrote:
> Hello,
>
> I am using two Beaglebone Black with Linux kernel version 3.8.13 and
> Xenomai version 2.6.3. I have built the Kernel with Xenomai and RTnet with
Why did you choose these old versions? The problem might be unrelated, but it's
now impossible for us to reproduce easily.
Where did you get the RTnet Ethernet driver from? It's not upstream as far as I
know. Was that source the reason for this version choice?
> buildroot. At the moment I am trying to use the provided source-files
> "rtt-sender" and "rtt-responder" for sending some "Round-Trip Time Request".
> I have changed my destination IP in "rtt-responder" to my destination BBB.
> I did not do any other changes. Then I did run "rtt-responder" on BBB2 and
> "rtt-sender" on BBB1 but I always get the following error:
> [image: image.png]
Better copy&paste the text from the console than taking screenshots.
The error messages could indicate that those tools are trying to use regular
Linux sockets, not RTnet ones. Did you compile them manually, or where they
built by the Xenomai build system? Check if they refer to symbols like
"__wrap_socket", rather than just "socket".
Jan
> Can anyone tell me why I do get that error?
> In order to this I need to say that both BBB's get a random MAC-Adress
> after each boot. That means I need to tell each BBB which MAC adress
> belongs to which IP-Adress. For example BBB1 has IP 192.168.127.10 with MAC
> AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11 with MAC BB:BB:BB:BB:BB I
> need to execute the following commands:
>
> For BBB1: rtroute add 192.168.127.11 BB:BB:BB:BB:BB dev rteth0
> For BBB2: rtroute add 192.168.127.10 AA:AA:AA:AA:AA dev rteth0
>
> Now it is possible to send rtpings with the command: rtping 192.168.127.10
> or rtping 192.168.127.11. Depens on which BBB you want to send the ping.
>
> So my idea was it is only possible to run the "rtt-sender" and
> "rtt-responder" file when my BBB's know which MAC belongs to which IP.
>
> But there is still the error, that the Network is unreachable. Why?
>
> You can find the source-files enclosed.
>
> Kind Regards
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image.png
> Type: image/png
> Size: 13271 bytes
> Desc: not available
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: rtt-sender.c
> Type: application/octet-stream
> Size: 9879 bytes
> Desc: not available
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: rtt-responder.c
> Type: application/octet-stream
> Size: 5705 bytes
> Desc: not available
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj>
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
[not found] ` <CAEmXcAxuFzE2uQHGMUjBnbgadTTcNU_DwV64uvLPahxxDMKTyQ@mail.gmail.com>
@ 2019-06-06 10:00 ` Jan Kiszka
[not found] ` <CAEmXcAxs3O_Hmph-48JArHgCmWSj+wAiffkNCZKiL9uVew6irg@mail.gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-06-06 10:00 UTC (permalink / raw)
To: danwe, Xenomai
[Re-adding the list]
On 06.06.19 11:40, danwe wrote:
> Hello Jan,
>
> yes the source for RTnet was the reason for the version choice. I did get the
> whole operation system (with Kernel, Xenomai, RTnet) from one programmer who
> made it out of buildroot and who said that RTnet is only working on BBB if you
> use that version. It may work on Xenomai 3 but you have to do some config
> operations and I do not have time in my research work for changing to Xenomai 3.
> The whole Xenomai 2 thing was made before in a research work.
> I do have two source-files working under RTnet where no error occur. These
> source-files like "raw-ethernet.c" or "rtping.c" did come with the buildroot. So
> did the files "rtt-sender" and "rtt-responder" come from. Those files were
> developed for using RTnet. I did compile theses files by using a makefile which
> is necessary for that operation system which was build by buildroot. I have used
> that makefile for e.g. "raw-ethernet" and it's working finde.
And this manual step is very likely the source for the error. Make sure you
build and link with the proper flags provided by xeno-config.
Jan
>
> Daniel
>
> Am Do., 6. Juni 2019 um 08:06 Uhr schrieb Jan Kiszka <jan.kiszka@siemens.com
> <mailto:jan.kiszka@siemens.com>>:
>
> On 05.06.19 12:30, danwe via Xenomai wrote:
> > Hello,
> >
> > I am using two Beaglebone Black with Linux kernel version 3.8.13 and
> > Xenomai version 2.6.3. I have built the Kernel with Xenomai and RTnet with
>
> Why did you choose these old versions? The problem might be unrelated, but it's
> now impossible for us to reproduce easily.
>
> Where did you get the RTnet Ethernet driver from? It's not upstream as far as I
> know. Was that source the reason for this version choice
>
>
> > buildroot. At the moment I am trying to use the provided source-files
> > "rtt-sender" and "rtt-responder" for sending some "Round-Trip Time Request".
> > I have changed my destination IP in "rtt-responder" to my destination BBB.
> > I did not do any other changes. Then I did run "rtt-responder" on BBB2 and
> > "rtt-sender" on BBB1 but I always get the following error:
> > [image: image.png]
>
> Better copy&paste the text from the console than taking screenshots.
>
> The error messages could indicate that those tools are trying to use regular
> Linux sockets, not RTnet ones. Did you compile them manually, or where they
> built by the Xenomai build system? Check if they refer to symbols like
> "__wrap_socket", rather than just "socket".
>
> Jan
>
> > Can anyone tell me why I do get that error?
> > In order to this I need to say that both BBB's get a random MAC-Adress
> > after each boot. That means I need to tell each BBB which MAC adress
> > belongs to which IP-Adress. For example BBB1 has IP 192.168.127.10 with MAC
> > AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11 with MAC BB:BB:BB:BB:BB I
> > need to execute the following commands:
> >
> > For BBB1: rtroute add 192.168.127.11 BB:BB:BB:BB:BB dev rteth0
> > For BBB2: rtroute add 192.168.127.10 AA:AA:AA:AA:AA dev rteth0
> >
> > Now it is possible to send rtpings with the command: rtping 192.168.127.10
> > or rtping 192.168.127.11. Depens on which BBB you want to send the ping.
> >
> > So my idea was it is only possible to run the "rtt-sender" and
> > "rtt-responder" file when my BBB's know which MAC belongs to which IP.
> >
> > But there is still the error, that the Network is unreachable. Why?
> >
> > You can find the source-files enclosed.
> >
> > Kind Regards
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: image.png
> > Type: image/png
> > Size: 13271 bytes
> > Desc: not available
> > URL:
> <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: rtt-sender.c
> > Type: application/octet-stream
> > Size: 9879 bytes
> > Desc: not available
> > URL:
> <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: rtt-responder.c
> > Type: application/octet-stream
> > Size: 5705 bytes
> > Desc: not available
> > URL:
> <http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj>
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
[not found] ` <22b6931e-8f7b-0cae-2316-5b278d1186d6@siemens.com>
@ 2019-06-06 17:50 ` danwe
2019-06-07 5:00 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: danwe @ 2019-06-06 17:50 UTC (permalink / raw)
To: xenomai
---------- Forwarded message ---------
Von: Jan Kiszka <jan.kiszka@siemens.com>
Date: Do., 6. Juni 2019 um 12:14 Uhr
Subject: Re: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone
Black
To: danwe <daniel.wenninger92@gmail.com>
Mailingliste!
On 06.06.19 12:10, danwe wrote:
> Oh that's what I'm doing. Sorry for the misunderstanding.
> There is a provided makefile for all source-files which needs to be
compiled.
> When I like to compile a source-file I do need to set some flags (will be
done
> in Makefile) and set some variables (will be done by export commands). I
am
> setting DESTDIR variable because it is using by xeno-config.
> So before I am compile anything with makefile I am using the following
commands
> in the Linux terminal of Virtual Box where my Makefile is located:
>
> $ export DESTDIR=~/Desktop/compile/Daniel/buildroot-2014.08/output/staging
>
> $ export
>
PATH=~/Desktop/compile/Daniel/buildroot-2014.08/output/host/usr/bin:$DESTDIR/usr/bin:$PATH
>
>
> And now I can compile source-files with my Makefile. If I do not export
these
> variables I do get error while compiling or at least I do get some
warnings. Now
> with export commands and my Makefile I do not get any errors or warnings
and
> some programs are running (like "raw-ethernet" provided by buildroot) but
one
> error with the "rtt-sender" file.
>
> The Makefile is the following:
>
> # Allow overriding xeno-config on make command line
> XENO_CONFIG := xeno-config
>
> prefix := $(shell $(XENO_CONFIG) --prefix)
>
> ifeq ($(prefix),)
> $(error Please add <xenomai-install-path>/bin to your PATH variable)
> endif
>
> CC := $(shell $(XENO_CONFIG) --skin=native --cc)
> STD_CFLAGS := $(shell $(XENO_CONFIG) --skin=native --cflags) -g
> STD_LDFLAGS := $(shell $(XENO_CONFIG) --skin=native --ldflags) -g -lrtdm
>
> STD_TARGETS := rtt-sender
>
> all: $(STD_TARGETS)
>
> $(STD_TARGETS): $(STD_TARGETS:%=%.c)
> $(CC) -o $@ $< $(STD_CFLAGS) $(STD_LDFLAGS)
>
> clean:
> $(RM) -f *.o *~ $(STD_TARGETS)
>
>
> Regards.
>
>
> Daniel
>
>
> Am Do., 6. Juni 2019 um 12:00 Uhr schrieb Jan Kiszka <
jan.kiszka@siemens.com
> <mailto:jan.kiszka@siemens.com>>:
>
> [Re-adding the list]
>
> On 06.06.19 11:40, danwe wrote:
> > Hello Jan,
> >
> > yes the source for RTnet was the reason for the version choice. I
did get
> the
> > whole operation system (with Kernel, Xenomai, RTnet) from one
programmer who
> > made it out of buildroot and who said that RTnet is only working
on BBB
> if you
> > use that version. It may work on Xenomai 3 but you have to do some
config
> > operations and I do not have time in my research work for changing
to
> Xenomai 3.
> > The whole Xenomai 2 thing was made before in a research work.
> > I do have two source-files working under RTnet where no error
occur. These
> > source-files like "raw-ethernet.c" or "rtping.c" did come with the
> buildroot. So
> > did the files "rtt-sender" and "rtt-responder" come from. Those
files were
> > developed for using RTnet. I did compile theses files by using a
makefile
> which
> > is necessary for that operation system which was build by
buildroot. I
> have used
> > that makefile for e.g. "raw-ethernet" and it's working finde.
>
> And this manual step is very likely the source for the error. Make
sure you
> build and link with the proper flags provided by xeno-config.
>
> Jan
>
> >
> > Daniel
> >
> > Am Do., 6. Juni 2019 um 08:06 Uhr schrieb Jan Kiszka
> <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> > <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>>:
> >
> > On 05.06.19 12:30, danwe via Xenomai wrote:
> > > Hello,
> > >
> > > I am using two Beaglebone Black with Linux kernel version
3.8.13 and
> > > Xenomai version 2.6.3. I have built the Kernel with Xenomai
and
> RTnet with
> >
> > Why did you choose these old versions? The problem might be
> unrelated, but it's
> > now impossible for us to reproduce easily.
> >
> > Where did you get the RTnet Ethernet driver from? It's not
upstream
> as far as I
> > know. Was that source the reason for this version choice
> >
> >
> > > buildroot. At the moment I am trying to use the provided
source-files
> > > "rtt-sender" and "rtt-responder" for sending some
"Round-Trip Time
> Request".
> > > I have changed my destination IP in "rtt-responder" to my
> destination BBB.
> > > I did not do any other changes. Then I did run
"rtt-responder" on
> BBB2 and
> > > "rtt-sender" on BBB1 but I always get the following error:
> > > [image: image.png]
> >
> > Better copy&paste the text from the console than taking
screenshots.
> >
> > The error messages could indicate that those tools are trying
to use
> regular
> > Linux sockets, not RTnet ones. Did you compile them manually,
or
> where they
> > built by the Xenomai build system? Check if they refer to
symbols like
> > "__wrap_socket", rather than just "socket".
> >
> > Jan
> >
> > > Can anyone tell me why I do get that error?
> > > In order to this I need to say that both BBB's get a random
MAC-Adress
> > > after each boot. That means I need to tell each BBB which
MAC adress
> > > belongs to which IP-Adress. For example BBB1 has IP
192.168.127.10
> with MAC
> > > AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11 with MAC
> BB:BB:BB:BB:BB I
> > > need to execute the following commands:
> > >
> > > For BBB1: rtroute add 192.168.127.11 BB:BB:BB:BB:BB dev
rteth0
> > > For BBB2: rtroute add 192.168.127.10 AA:AA:AA:AA:AA dev
rteth0
> > >
> > > Now it is possible to send rtpings with the command: rtping
> 192.168.127.10
> > > or rtping 192.168.127.11. Depens on which BBB you want to
send the
> ping.
> > >
> > > So my idea was it is only possible to run the "rtt-sender"
and
> > > "rtt-responder" file when my BBB's know which MAC belongs
to which IP.
> > >
> > > But there is still the error, that the Network is
unreachable. Why?
> > >
> > > You can find the source-files enclosed.
> > >
> > > Kind Regards
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: image.png
> > > Type: image/png
> > > Size: 13271 bytes
> > > Desc: not available
> > > URL:
> >
> <
http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png
>
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: rtt-sender.c
> > > Type: application/octet-stream
> > > Size: 9879 bytes
> > > Desc: not available
> > > URL:
> >
> <
http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj
>
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: rtt-responder.c
> > > Type: application/octet-stream
> > > Size: 5705 bytes
> > > Desc: not available
> > > URL:
> >
> <
http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj
>
> > >
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-06 17:50 ` Fwd: " danwe
@ 2019-06-07 5:00 ` Jan Kiszka
2019-06-07 8:09 ` danwe
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-06-07 5:00 UTC (permalink / raw)
To: danwe, xenomai
On 06.06.19 19:50, danwe via Xenomai wrote:
> ---------- Forwarded message ---------
> Von: Jan Kiszka <jan.kiszka@siemens.com>
> Date: Do., 6. Juni 2019 um 12:14 Uhr
> Subject: Re: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone
> Black
> To: danwe <daniel.wenninger92@gmail.com>
>
>
> Mailingliste!
>
> On 06.06.19 12:10, danwe wrote:
>> Oh that's what I'm doing. Sorry for the misunderstanding.
>> There is a provided makefile for all source-files which needs to be
> compiled.
>> When I like to compile a source-file I do need to set some flags (will be
> done
>> in Makefile) and set some variables (will be done by export commands). I
> am
>> setting DESTDIR variable because it is using by xeno-config.
>> So before I am compile anything with makefile I am using the following
> commands
>> in the Linux terminal of Virtual Box where my Makefile is located:
>>
>> $ export DESTDIR=~/Desktop/compile/Daniel/buildroot-2014.08/output/staging
>>
>> $ export
>>
> PATH=~/Desktop/compile/Daniel/buildroot-2014.08/output/host/usr/bin:$DESTDIR/usr/bin:$PATH
>>
>>
>> And now I can compile source-files with my Makefile. If I do not export
> these
>> variables I do get error while compiling or at least I do get some
> warnings. Now
>> with export commands and my Makefile I do not get any errors or warnings
> and
>> some programs are running (like "raw-ethernet" provided by buildroot) but
> one
>> error with the "rtt-sender" file.
>>
>> The Makefile is the following:
>>
>> # Allow overriding xeno-config on make command line
>> XENO_CONFIG := xeno-config
>>
>> prefix := $(shell $(XENO_CONFIG) --prefix)
>>
>> ifeq ($(prefix),)
>> $(error Please add <xenomai-install-path>/bin to your PATH variable)
>> endif
>>
>> CC := $(shell $(XENO_CONFIG) --skin=native --cc)
>> STD_CFLAGS := $(shell $(XENO_CONFIG) --skin=native --cflags) -g
>> STD_LDFLAGS := $(shell $(XENO_CONFIG) --skin=native --ldflags) -g -lrtdm
>>
The rtt examples are using the posix skin, not "native". So your makefile fails
to wrap socket, sendmsg etc. calls to the Xenomai implementation.
Jan
>> STD_TARGETS := rtt-sender
>>
>> all: $(STD_TARGETS)
>>
>> $(STD_TARGETS): $(STD_TARGETS:%=%.c)
>> $(CC) -o $@ $< $(STD_CFLAGS) $(STD_LDFLAGS)
>>
>> clean:
>> $(RM) -f *.o *~ $(STD_TARGETS)
>>
>>
>> Regards.
>>
>>
>> Daniel
>>
>>
>> Am Do., 6. Juni 2019 um 12:00 Uhr schrieb Jan Kiszka <
> jan.kiszka@siemens.com
>> <mailto:jan.kiszka@siemens.com>>:
>>
>> [Re-adding the list]
>>
>> On 06.06.19 11:40, danwe wrote:
>> > Hello Jan,
>> >
>> > yes the source for RTnet was the reason for the version choice. I
> did get
>> the
>> > whole operation system (with Kernel, Xenomai, RTnet) from one
> programmer who
>> > made it out of buildroot and who said that RTnet is only working
> on BBB
>> if you
>> > use that version. It may work on Xenomai 3 but you have to do some
> config
>> > operations and I do not have time in my research work for changing
> to
>> Xenomai 3.
>> > The whole Xenomai 2 thing was made before in a research work.
>> > I do have two source-files working under RTnet where no error
> occur. These
>> > source-files like "raw-ethernet.c" or "rtping.c" did come with the
>> buildroot. So
>> > did the files "rtt-sender" and "rtt-responder" come from. Those
> files were
>> > developed for using RTnet. I did compile theses files by using a
> makefile
>> which
>> > is necessary for that operation system which was build by
> buildroot. I
>> have used
>> > that makefile for e.g. "raw-ethernet" and it's working finde.
>>
>> And this manual step is very likely the source for the error. Make
> sure you
>> build and link with the proper flags provided by xeno-config.
>>
>> Jan
>>
>> >
>> > Daniel
>> >
>> > Am Do., 6. Juni 2019 um 08:06 Uhr schrieb Jan Kiszka
>> <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
>> > <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>>:
>> >
>> > On 05.06.19 12:30, danwe via Xenomai wrote:
>> > > Hello,
>> > >
>> > > I am using two Beaglebone Black with Linux kernel version
> 3.8.13 and
>> > > Xenomai version 2.6.3. I have built the Kernel with Xenomai
> and
>> RTnet with
>> >
>> > Why did you choose these old versions? The problem might be
>> unrelated, but it's
>> > now impossible for us to reproduce easily.
>> >
>> > Where did you get the RTnet Ethernet driver from? It's not
> upstream
>> as far as I
>> > know. Was that source the reason for this version choice
>> >
>> >
>> > > buildroot. At the moment I am trying to use the provided
> source-files
>> > > "rtt-sender" and "rtt-responder" for sending some
> "Round-Trip Time
>> Request".
>> > > I have changed my destination IP in "rtt-responder" to my
>> destination BBB.
>> > > I did not do any other changes. Then I did run
> "rtt-responder" on
>> BBB2 and
>> > > "rtt-sender" on BBB1 but I always get the following error:
>> > > [image: image.png]
>> >
>> > Better copy&paste the text from the console than taking
> screenshots.
>> >
>> > The error messages could indicate that those tools are trying
> to use
>> regular
>> > Linux sockets, not RTnet ones. Did you compile them manually,
> or
>> where they
>> > built by the Xenomai build system? Check if they refer to
> symbols like
>> > "__wrap_socket", rather than just "socket".
>> >
>> > Jan
>> >
>> > > Can anyone tell me why I do get that error?
>> > > In order to this I need to say that both BBB's get a random
> MAC-Adress
>> > > after each boot. That means I need to tell each BBB which
> MAC adress
>> > > belongs to which IP-Adress. For example BBB1 has IP
> 192.168.127.10
>> with MAC
>> > > AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11 with MAC
>> BB:BB:BB:BB:BB I
>> > > need to execute the following commands:
>> > >
>> > > For BBB1: rtroute add 192.168.127.11 BB:BB:BB:BB:BB dev
> rteth0
>> > > For BBB2: rtroute add 192.168.127.10 AA:AA:AA:AA:AA dev
> rteth0
>> > >
>> > > Now it is possible to send rtpings with the command: rtping
>> 192.168.127.10
>> > > or rtping 192.168.127.11. Depens on which BBB you want to
> send the
>> ping.
>> > >
>> > > So my idea was it is only possible to run the "rtt-sender"
> and
>> > > "rtt-responder" file when my BBB's know which MAC belongs
> to which IP.
>> > >
>> > > But there is still the error, that the Network is
> unreachable. Why?
>> > >
>> > > You can find the source-files enclosed.
>> > >
>> > > Kind Regards
>> > > -------------- next part --------------
>> > > A non-text attachment was scrubbed...
>> > > Name: image.png
>> > > Type: image/png
>> > > Size: 13271 bytes
>> > > Desc: not available
>> > > URL:
>> >
>> <
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png
>>
>> > > -------------- next part --------------
>> > > A non-text attachment was scrubbed...
>> > > Name: rtt-sender.c
>> > > Type: application/octet-stream
>> > > Size: 9879 bytes
>> > > Desc: not available
>> > > URL:
>> >
>> <
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj
>>
>> > > -------------- next part --------------
>> > > A non-text attachment was scrubbed...
>> > > Name: rtt-responder.c
>> > > Type: application/octet-stream
>> > > Size: 5705 bytes
>> > > Desc: not available
>> > > URL:
>> >
>> <
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj
>>
>> > >
>> >
>> > --
>> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> > Corporate Competence Center Embedded Linux
>> >
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux
>>
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-07 5:00 ` Jan Kiszka
@ 2019-06-07 8:09 ` danwe
2019-06-07 8:40 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: danwe @ 2019-06-07 8:09 UTC (permalink / raw)
To: Jan Kiszka, xenomai
I'm sorry I did upload the old Makefile as I had a source-file which was
using the "native" skin. For "rtt-sender" and "rtt-responder" I was using
the posix skin. Otherwise it would throw "undefined reference" error and I
it would not be able to compile my source-file. So I did use POSIX skin and
the compiling was successful but there is still the error that the network
is not reachable when I'm running "rtt-sender". By running "rtt-responder"
no error occurs.. Any other ideas? Could it be a problem that I have to
define which MAC belongs to which IP address like I described before?
Regards
Daniel
Am Fr., 7. Juni 2019 um 07:00 Uhr schrieb Jan Kiszka <jan.kiszka@siemens.com
>:
> On 06.06.19 19:50, danwe via Xenomai wrote:
> > ---------- Forwarded message ---------
> > Von: Jan Kiszka <jan.kiszka@siemens.com>
> > Date: Do., 6. Juni 2019 um 12:14 Uhr
> > Subject: Re: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone
> > Black
> > To: danwe <daniel.wenninger92@gmail.com>
> >
> >
> > Mailingliste!
> >
> > On 06.06.19 12:10, danwe wrote:
> >> Oh that's what I'm doing. Sorry for the misunderstanding.
> >> There is a provided makefile for all source-files which needs to be
> > compiled.
> >> When I like to compile a source-file I do need to set some flags (will
> be
> > done
> >> in Makefile) and set some variables (will be done by export commands). I
> > am
> >> setting DESTDIR variable because it is using by xeno-config.
> >> So before I am compile anything with makefile I am using the following
> > commands
> >> in the Linux terminal of Virtual Box where my Makefile is located:
> >>
> >> $ export
> DESTDIR=~/Desktop/compile/Daniel/buildroot-2014.08/output/staging
> >>
> >> $ export
> >>
> >
> PATH=~/Desktop/compile/Daniel/buildroot-2014.08/output/host/usr/bin:$DESTDIR/usr/bin:$PATH
> >>
> >>
> >> And now I can compile source-files with my Makefile. If I do not export
> > these
> >> variables I do get error while compiling or at least I do get some
> > warnings. Now
> >> with export commands and my Makefile I do not get any errors or warnings
> > and
> >> some programs are running (like "raw-ethernet" provided by buildroot)
> but
> > one
> >> error with the "rtt-sender" file.
> >>
> >> The Makefile is the following:
> >>
> >> # Allow overriding xeno-config on make command line
> >> XENO_CONFIG := xeno-config
> >>
> >> prefix := $(shell $(XENO_CONFIG) --prefix)
> >>
> >> ifeq ($(prefix),)
> >> $(error Please add <xenomai-install-path>/bin to your PATH variable)
> >> endif
> >>
> >> CC := $(shell $(XENO_CONFIG) --skin=native --cc)
> >> STD_CFLAGS := $(shell $(XENO_CONFIG) --skin=native --cflags) -g
> >> STD_LDFLAGS := $(shell $(XENO_CONFIG) --skin=native --ldflags) -g -lrtdm
> >>
>
> The rtt examples are using the posix skin, not "native". So your makefile
> fails
> to wrap socket, sendmsg etc. calls to the Xenomai implementation.
>
> Jan
>
> >> STD_TARGETS := rtt-sender
> >>
> >> all: $(STD_TARGETS)
> >>
> >> $(STD_TARGETS): $(STD_TARGETS:%=%.c)
> >> $(CC) -o $@ $< $(STD_CFLAGS) $(STD_LDFLAGS)
> >>
> >> clean:
> >> $(RM) -f *.o *~ $(STD_TARGETS)
> >>
> >>
> >> Regards.
> >>
> >>
> >> Daniel
> >>
> >>
> >> Am Do., 6. Juni 2019 um 12:00 Uhr schrieb Jan Kiszka <
> > jan.kiszka@siemens.com
> >> <mailto:jan.kiszka@siemens.com>>:
> >>
> >> [Re-adding the list]
> >>
> >> On 06.06.19 11:40, danwe wrote:
> >> > Hello Jan,
> >> >
> >> > yes the source for RTnet was the reason for the version choice.
> I
> > did get
> >> the
> >> > whole operation system (with Kernel, Xenomai, RTnet) from one
> > programmer who
> >> > made it out of buildroot and who said that RTnet is only working
> > on BBB
> >> if you
> >> > use that version. It may work on Xenomai 3 but you have to do
> some
> > config
> >> > operations and I do not have time in my research work for
> changing
> > to
> >> Xenomai 3.
> >> > The whole Xenomai 2 thing was made before in a research work.
> >> > I do have two source-files working under RTnet where no error
> > occur. These
> >> > source-files like "raw-ethernet.c" or "rtping.c" did come with
> the
> >> buildroot. So
> >> > did the files "rtt-sender" and "rtt-responder" come from. Those
> > files were
> >> > developed for using RTnet. I did compile theses files by using a
> > makefile
> >> which
> >> > is necessary for that operation system which was build by
> > buildroot. I
> >> have used
> >> > that makefile for e.g. "raw-ethernet" and it's working finde.
> >>
> >> And this manual step is very likely the source for the error. Make
> > sure you
> >> build and link with the proper flags provided by xeno-config.
> >>
> >> Jan
> >>
> >> >
> >> > Daniel
> >> >
> >> > Am Do., 6. Juni 2019 um 08:06 Uhr schrieb Jan Kiszka
> >> <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> >> > <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com
> >>>:
> >> >
> >> > On 05.06.19 12:30, danwe via Xenomai wrote:
> >> > > Hello,
> >> > >
> >> > > I am using two Beaglebone Black with Linux kernel version
> > 3.8.13 and
> >> > > Xenomai version 2.6.3. I have built the Kernel with
> Xenomai
> > and
> >> RTnet with
> >> >
> >> > Why did you choose these old versions? The problem might be
> >> unrelated, but it's
> >> > now impossible for us to reproduce easily.
> >> >
> >> > Where did you get the RTnet Ethernet driver from? It's not
> > upstream
> >> as far as I
> >> > know. Was that source the reason for this version choice
> >> >
> >> >
> >> > > buildroot. At the moment I am trying to use the provided
> > source-files
> >> > > "rtt-sender" and "rtt-responder" for sending some
> > "Round-Trip Time
> >> Request".
> >> > > I have changed my destination IP in "rtt-responder" to my
> >> destination BBB.
> >> > > I did not do any other changes. Then I did run
> > "rtt-responder" on
> >> BBB2 and
> >> > > "rtt-sender" on BBB1 but I always get the following
> error:
> >> > > [image: image.png]
> >> >
> >> > Better copy&paste the text from the console than taking
> > screenshots.
> >> >
> >> > The error messages could indicate that those tools are
> trying
> > to use
> >> regular
> >> > Linux sockets, not RTnet ones. Did you compile them
> manually,
> > or
> >> where they
> >> > built by the Xenomai build system? Check if they refer to
> > symbols like
> >> > "__wrap_socket", rather than just "socket".
> >> >
> >> > Jan
> >> >
> >> > > Can anyone tell me why I do get that error?
> >> > > In order to this I need to say that both BBB's get a
> random
> > MAC-Adress
> >> > > after each boot. That means I need to tell each BBB which
> > MAC adress
> >> > > belongs to which IP-Adress. For example BBB1 has IP
> > 192.168.127.10
> >> with MAC
> >> > > AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11 with MAC
> >> BB:BB:BB:BB:BB I
> >> > > need to execute the following commands:
> >> > >
> >> > > For BBB1: rtroute add 192.168.127.11 BB:BB:BB:BB:BB dev
> > rteth0
> >> > > For BBB2: rtroute add 192.168.127.10 AA:AA:AA:AA:AA dev
> > rteth0
> >> > >
> >> > > Now it is possible to send rtpings with the command:
> rtping
> >> 192.168.127.10
> >> > > or rtping 192.168.127.11. Depens on which BBB you want to
> > send the
> >> ping.
> >> > >
> >> > > So my idea was it is only possible to run the
> "rtt-sender"
> > and
> >> > > "rtt-responder" file when my BBB's know which MAC belongs
> > to which IP.
> >> > >
> >> > > But there is still the error, that the Network is
> > unreachable. Why?
> >> > >
> >> > > You can find the source-files enclosed.
> >> > >
> >> > > Kind Regards
> >> > > -------------- next part --------------
> >> > > A non-text attachment was scrubbed...
> >> > > Name: image.png
> >> > > Type: image/png
> >> > > Size: 13271 bytes
> >> > > Desc: not available
> >> > > URL:
> >> >
> >> <
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png
> >>
> >> > > -------------- next part --------------
> >> > > A non-text attachment was scrubbed...
> >> > > Name: rtt-sender.c
> >> > > Type: application/octet-stream
> >> > > Size: 9879 bytes
> >> > > Desc: not available
> >> > > URL:
> >> >
> >> <
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj
> >>
> >> > > -------------- next part --------------
> >> > > A non-text attachment was scrubbed...
> >> > > Name: rtt-responder.c
> >> > > Type: application/octet-stream
> >> > > Size: 5705 bytes
> >> > > Desc: not available
> >> > > URL:
> >> >
> >> <
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj
> >>
> >> > >
> >> >
> >> > --
> >> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> > Corporate Competence Center Embedded Linux
> >> >
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> >>
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-07 8:09 ` danwe
@ 2019-06-07 8:40 ` Jan Kiszka
2019-06-07 9:40 ` danwe
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-06-07 8:40 UTC (permalink / raw)
To: danwe, xenomai
On 07.06.19 10:09, danwe wrote:
> I'm sorry I did upload the old Makefile as I had a source-file which was using
> the "native" skin. For "rtt-sender" and "rtt-responder" I was using the posix
> skin. Otherwise it would throw "undefined reference" error and I it would not be
> able to compile my source-file. So I did use POSIX skin and the compiling was
> successful but there is still the error that the network is not reachable when
> I'm running "rtt-sender". By running "rtt-responder" no error occurs.. Any other
> ideas? Could it be a problem that I have to define which MAC belongs to which IP
> address like I described before?
As I suggested in my first reply: Check if the generated binary actually uses
__wrap_socket, __wrap_ioctl etc., or if it calls directly the non-rt glibc
services. Eg., "readelf -a" can provide that information.
Jan
>
> Regards
>
> Daniel
>
> Am Fr., 7. Juni 2019 um 07:00 Uhr schrieb Jan Kiszka <jan.kiszka@siemens.com
> <mailto:jan.kiszka@siemens.com>>:
>
> On 06.06.19 19:50, danwe via Xenomai wrote:
> > ---------- Forwarded message ---------
> > Von: Jan Kiszka <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>
> > Date: Do., 6. Juni 2019 um 12:14 Uhr
> > Subject: Re: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone
> > Black
> > To: danwe <daniel.wenninger92@gmail.com
> <mailto:daniel.wenninger92@gmail.com>>
> >
> >
> > Mailingliste!
> >
> > On 06.06.19 12:10, danwe wrote:
> >> Oh that's what I'm doing. Sorry for the misunderstanding.
> >> There is a provided makefile for all source-files which needs to be
> > compiled.
> >> When I like to compile a source-file I do need to set some flags (will be
> > done
> >> in Makefile) and set some variables (will be done by export commands). I
> > am
> >> setting DESTDIR variable because it is using by xeno-config.
> >> So before I am compile anything with makefile I am using the following
> > commands
> >> in the Linux terminal of Virtual Box where my Makefile is located:
> >>
> >> $ export DESTDIR=~/Desktop/compile/Daniel/buildroot-2014.08/output/staging
> >>
> >> $ export
> >>
> >
> PATH=~/Desktop/compile/Daniel/buildroot-2014.08/output/host/usr/bin:$DESTDIR/usr/bin:$PATH
> >>
> >>
> >> And now I can compile source-files with my Makefile. If I do not export
> > these
> >> variables I do get error while compiling or at least I do get some
> > warnings. Now
> >> with export commands and my Makefile I do not get any errors or warnings
> > and
> >> some programs are running (like "raw-ethernet" provided by buildroot) but
> > one
> >> error with the "rtt-sender" file.
> >>
> >> The Makefile is the following:
> >>
> >> # Allow overriding xeno-config on make command line
> >> XENO_CONFIG := xeno-config
> >>
> >> prefix := $(shell $(XENO_CONFIG) --prefix)
> >>
> >> ifeq ($(prefix),)
> >> $(error Please add <xenomai-install-path>/bin to your PATH variable)
> >> endif
> >>
> >> CC := $(shell $(XENO_CONFIG) --skin=native --cc)
> >> STD_CFLAGS := $(shell $(XENO_CONFIG) --skin=native --cflags) -g
> >> STD_LDFLAGS := $(shell $(XENO_CONFIG) --skin=native --ldflags) -g -lrtdm
> >>
>
> The rtt examples are using the posix skin, not "native". So your makefile fails
> to wrap socket, sendmsg etc. calls to the Xenomai implementation.
>
> Jan
>
> >> STD_TARGETS := rtt-sender
> >>
> >> all: $(STD_TARGETS)
> >>
> >> $(STD_TARGETS): $(STD_TARGETS:%=%.c)
> >> $(CC) -o $@ $< $(STD_CFLAGS) $(STD_LDFLAGS)
> >>
> >> clean:
> >> $(RM) -f *.o *~ $(STD_TARGETS)
> >>
> >>
> >> Regards.
> >>
> >>
> >> Daniel
> >>
> >>
> >> Am Do., 6. Juni 2019 um 12:00 Uhr schrieb Jan Kiszka <
> > jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> >> <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>>:
> >>
> >> [Re-adding the list]
> >>
> >> On 06.06.19 11:40, danwe wrote:
> >> > Hello Jan,
> >> >
> >> > yes the source for RTnet was the reason for the version choice. I
> > did get
> >> the
> >> > whole operation system (with Kernel, Xenomai, RTnet) from one
> > programmer who
> >> > made it out of buildroot and who said that RTnet is only working
> > on BBB
> >> if you
> >> > use that version. It may work on Xenomai 3 but you have to do some
> > config
> >> > operations and I do not have time in my research work for changing
> > to
> >> Xenomai 3.
> >> > The whole Xenomai 2 thing was made before in a research work.
> >> > I do have two source-files working under RTnet where no error
> > occur. These
> >> > source-files like "raw-ethernet.c" or "rtping.c" did come with the
> >> buildroot. So
> >> > did the files "rtt-sender" and "rtt-responder" come from. Those
> > files were
> >> > developed for using RTnet. I did compile theses files by using a
> > makefile
> >> which
> >> > is necessary for that operation system which was build by
> > buildroot. I
> >> have used
> >> > that makefile for e.g. "raw-ethernet" and it's working finde.
> >>
> >> And this manual step is very likely the source for the error. Make
> > sure you
> >> build and link with the proper flags provided by xeno-config.
> >>
> >> Jan
> >>
> >> >
> >> > Daniel
> >> >
> >> > Am Do., 6. Juni 2019 um 08:06 Uhr schrieb Jan Kiszka
> >> <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>
> >> > <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>>>:
> >> >
> >> > On 05.06.19 12:30, danwe via Xenomai wrote:
> >> > > Hello,
> >> > >
> >> > > I am using two Beaglebone Black with Linux kernel version
> > 3.8.13 and
> >> > > Xenomai version 2.6.3. I have built the Kernel with Xenomai
> > and
> >> RTnet with
> >> >
> >> > Why did you choose these old versions? The problem might be
> >> unrelated, but it's
> >> > now impossible for us to reproduce easily.
> >> >
> >> > Where did you get the RTnet Ethernet driver from? It's not
> > upstream
> >> as far as I
> >> > know. Was that source the reason for this version choice
> >> >
> >> >
> >> > > buildroot. At the moment I am trying to use the provided
> > source-files
> >> > > "rtt-sender" and "rtt-responder" for sending some
> > "Round-Trip Time
> >> Request".
> >> > > I have changed my destination IP in "rtt-responder" to my
> >> destination BBB.
> >> > > I did not do any other changes. Then I did run
> > "rtt-responder" on
> >> BBB2 and
> >> > > "rtt-sender" on BBB1 but I always get the following error:
> >> > > [image: image.png]
> >> >
> >> > Better copy&paste the text from the console than taking
> > screenshots.
> >> >
> >> > The error messages could indicate that those tools are trying
> > to use
> >> regular
> >> > Linux sockets, not RTnet ones. Did you compile them manually,
> > or
> >> where they
> >> > built by the Xenomai build system? Check if they refer to
> > symbols like
> >> > "__wrap_socket", rather than just "socket".
> >> >
> >> > Jan
> >> >
> >> > > Can anyone tell me why I do get that error?
> >> > > In order to this I need to say that both BBB's get a random
> > MAC-Adress
> >> > > after each boot. That means I need to tell each BBB which
> > MAC adress
> >> > > belongs to which IP-Adress. For example BBB1 has IP
> > 192.168.127.10
> >> with MAC
> >> > > AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11 with MAC
> >> BB:BB:BB:BB:BB I
> >> > > need to execute the following commands:
> >> > >
> >> > > For BBB1: rtroute add 192.168.127.11 BB:BB:BB:BB:BB dev
> > rteth0
> >> > > For BBB2: rtroute add 192.168.127.10 AA:AA:AA:AA:AA dev
> > rteth0
> >> > >
> >> > > Now it is possible to send rtpings with the command: rtping
> >> 192.168.127.10
> >> > > or rtping 192.168.127.11. Depens on which BBB you want to
> > send the
> >> ping.
> >> > >
> >> > > So my idea was it is only possible to run the "rtt-sender"
> > and
> >> > > "rtt-responder" file when my BBB's know which MAC belongs
> > to which IP.
> >> > >
> >> > > But there is still the error, that the Network is
> > unreachable. Why?
> >> > >
> >> > > You can find the source-files enclosed.
> >> > >
> >> > > Kind Regards
> >> > > -------------- next part --------------
> >> > > A non-text attachment was scrubbed...
> >> > > Name: image.png
> >> > > Type: image/png
> >> > > Size: 13271 bytes
> >> > > Desc: not available
> >> > > URL:
> >> >
> >> <
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png
> >>
> >> > > -------------- next part --------------
> >> > > A non-text attachment was scrubbed...
> >> > > Name: rtt-sender.c
> >> > > Type: application/octet-stream
> >> > > Size: 9879 bytes
> >> > > Desc: not available
> >> > > URL:
> >> >
> >> <
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj
> >>
> >> > > -------------- next part --------------
> >> > > A non-text attachment was scrubbed...
> >> > > Name: rtt-responder.c
> >> > > Type: application/octet-stream
> >> > > Size: 5705 bytes
> >> > > Desc: not available
> >> > > URL:
> >> >
> >> <
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj
> >>
> >> > >
> >> >
> >> > --
> >> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> > Corporate Competence Center Embedded Linux
> >> >
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> >>
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-07 8:40 ` Jan Kiszka
@ 2019-06-07 9:40 ` danwe
2019-06-07 10:15 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: danwe @ 2019-06-07 9:40 UTC (permalink / raw)
To: Jan Kiszka, xenomai
I have checked what the generated binary is using.
E.g. it is using lines like:
19: 00008bc8 0 FUNC GLOBAL DEFAULT UND ioct1@GLIBC_2.4 (3)
45: 00008cc4 0 FUNC GLOBAL DEFAULT UND socket@GLIBC_2.4 (3)
Does that mean that it is using the non-rt glibc services? If so then I do
not understand one thing: the file "raw-ethernet" is a example where it
uses the same ioct1@GLIBC and socket@GLIBC but it does not throw the
"network is unreachable error".
But how can I change that it is using the __wrap_socket?
Daniel
Am Fr., 7. Juni 2019 um 10:40 Uhr schrieb Jan Kiszka <jan.kiszka@siemens.com
>:
> On 07.06.19 10:09, danwe wrote:
> > I'm sorry I did upload the old Makefile as I had a source-file which was
> using
> > the "native" skin. For "rtt-sender" and "rtt-responder" I was using the
> posix
> > skin. Otherwise it would throw "undefined reference" error and I it
> would not be
> > able to compile my source-file. So I did use POSIX skin and the
> compiling was
> > successful but there is still the error that the network is not
> reachable when
> > I'm running "rtt-sender". By running "rtt-responder" no error occurs..
> Any other
> > ideas? Could it be a problem that I have to define which MAC belongs to
> which IP
> > address like I described before?
>
> As I suggested in my first reply: Check if the generated binary actually
> uses
> __wrap_socket, __wrap_ioctl etc., or if it calls directly the non-rt glibc
> services. Eg., "readelf -a" can provide that information.
>
> Jan
>
> >
> > Regards
> >
> > Daniel
> >
> > Am Fr., 7. Juni 2019 um 07:00 Uhr schrieb Jan Kiszka <
> jan.kiszka@siemens.com
> > <mailto:jan.kiszka@siemens.com>>:
> >
> > On 06.06.19 19:50, danwe via Xenomai wrote:
> > > ---------- Forwarded message ---------
> > > Von: Jan Kiszka <jan.kiszka@siemens.com <mailto:
> jan.kiszka@siemens.com>>
> > > Date: Do., 6. Juni 2019 um 12:14 Uhr
> > > Subject: Re: Round-Trip Time Requester with Xenomai / RTnet on
> Beaglebone
> > > Black
> > > To: danwe <daniel.wenninger92@gmail.com
> > <mailto:daniel.wenninger92@gmail.com>>
> > >
> > >
> > > Mailingliste!
> > >
> > > On 06.06.19 12:10, danwe wrote:
> > >> Oh that's what I'm doing. Sorry for the misunderstanding.
> > >> There is a provided makefile for all source-files which needs to
> be
> > > compiled.
> > >> When I like to compile a source-file I do need to set some flags
> (will be
> > > done
> > >> in Makefile) and set some variables (will be done by export
> commands). I
> > > am
> > >> setting DESTDIR variable because it is using by xeno-config.
> > >> So before I am compile anything with makefile I am using the
> following
> > > commands
> > >> in the Linux terminal of Virtual Box where my Makefile is
> located:
> > >>
> > >> $ export
> DESTDIR=~/Desktop/compile/Daniel/buildroot-2014.08/output/staging
> > >>
> > >> $ export
> > >>
> > >
> >
> PATH=~/Desktop/compile/Daniel/buildroot-2014.08/output/host/usr/bin:$DESTDIR/usr/bin:$PATH
> > >>
> > >>
> > >> And now I can compile source-files with my Makefile. If I do not
> export
> > > these
> > >> variables I do get error while compiling or at least I do get
> some
> > > warnings. Now
> > >> with export commands and my Makefile I do not get any errors or
> warnings
> > > and
> > >> some programs are running (like "raw-ethernet" provided by
> buildroot) but
> > > one
> > >> error with the "rtt-sender" file.
> > >>
> > >> The Makefile is the following:
> > >>
> > >> # Allow overriding xeno-config on make command line
> > >> XENO_CONFIG := xeno-config
> > >>
> > >> prefix := $(shell $(XENO_CONFIG) --prefix)
> > >>
> > >> ifeq ($(prefix),)
> > >> $(error Please add <xenomai-install-path>/bin to your PATH
> variable)
> > >> endif
> > >>
> > >> CC := $(shell $(XENO_CONFIG) --skin=native --cc)
> > >> STD_CFLAGS := $(shell $(XENO_CONFIG) --skin=native --cflags) -g
> > >> STD_LDFLAGS := $(shell $(XENO_CONFIG) --skin=native --ldflags)
> -g -lrtdm
> > >>
> >
> > The rtt examples are using the posix skin, not "native". So your
> makefile fails
> > to wrap socket, sendmsg etc. calls to the Xenomai implementation.
> >
> > Jan
> >
> > >> STD_TARGETS := rtt-sender
> > >>
> > >> all: $(STD_TARGETS)
> > >>
> > >> $(STD_TARGETS): $(STD_TARGETS:%=%.c)
> > >> $(CC) -o $@ $< $(STD_CFLAGS) $(STD_LDFLAGS)
> > >>
> > >> clean:
> > >> $(RM) -f *.o *~ $(STD_TARGETS)
> > >>
> > >>
> > >> Regards.
> > >>
> > >>
> > >> Daniel
> > >>
> > >>
> > >> Am Do., 6. Juni 2019 um 12:00 Uhr schrieb Jan Kiszka <
> > > jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> > >> <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com
> >>>:
> > >>
> > >> [Re-adding the list]
> > >>
> > >> On 06.06.19 11:40, danwe wrote:
> > >> > Hello Jan,
> > >> >
> > >> > yes the source for RTnet was the reason for the version
> choice. I
> > > did get
> > >> the
> > >> > whole operation system (with Kernel, Xenomai, RTnet)
> from one
> > > programmer who
> > >> > made it out of buildroot and who said that RTnet is only
> working
> > > on BBB
> > >> if you
> > >> > use that version. It may work on Xenomai 3 but you have
> to do some
> > > config
> > >> > operations and I do not have time in my research work
> for changing
> > > to
> > >> Xenomai 3.
> > >> > The whole Xenomai 2 thing was made before in a research
> work.
> > >> > I do have two source-files working under RTnet where no
> error
> > > occur. These
> > >> > source-files like "raw-ethernet.c" or "rtping.c" did
> come with the
> > >> buildroot. So
> > >> > did the files "rtt-sender" and "rtt-responder" come
> from. Those
> > > files were
> > >> > developed for using RTnet. I did compile theses files by
> using a
> > > makefile
> > >> which
> > >> > is necessary for that operation system which was build by
> > > buildroot. I
> > >> have used
> > >> > that makefile for e.g. "raw-ethernet" and it's working
> finde.
> > >>
> > >> And this manual step is very likely the source for the
> error. Make
> > > sure you
> > >> build and link with the proper flags provided by
> xeno-config.
> > >>
> > >> Jan
> > >>
> > >> >
> > >> > Daniel
> > >> >
> > >> > Am Do., 6. Juni 2019 um 08:06 Uhr schrieb Jan Kiszka
> > >> <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>
> > <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>
> > >> > <mailto:jan.kiszka@siemens.com <mailto:
> jan.kiszka@siemens.com>
> > <mailto:jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>>>>:
> > >> >
> > >> > On 05.06.19 12:30, danwe via Xenomai wrote:
> > >> > > Hello,
> > >> > >
> > >> > > I am using two Beaglebone Black with Linux kernel
> version
> > > 3.8.13 and
> > >> > > Xenomai version 2.6.3. I have built the Kernel
> with Xenomai
> > > and
> > >> RTnet with
> > >> >
> > >> > Why did you choose these old versions? The problem
> might be
> > >> unrelated, but it's
> > >> > now impossible for us to reproduce easily.
> > >> >
> > >> > Where did you get the RTnet Ethernet driver from?
> It's not
> > > upstream
> > >> as far as I
> > >> > know. Was that source the reason for this version
> choice
> > >> >
> > >> >
> > >> > > buildroot. At the moment I am trying to use the
> provided
> > > source-files
> > >> > > "rtt-sender" and "rtt-responder" for sending some
> > > "Round-Trip Time
> > >> Request".
> > >> > > I have changed my destination IP in
> "rtt-responder" to my
> > >> destination BBB.
> > >> > > I did not do any other changes. Then I did run
> > > "rtt-responder" on
> > >> BBB2 and
> > >> > > "rtt-sender" on BBB1 but I always get the
> following error:
> > >> > > [image: image.png]
> > >> >
> > >> > Better copy&paste the text from the console than
> taking
> > > screenshots.
> > >> >
> > >> > The error messages could indicate that those tools
> are trying
> > > to use
> > >> regular
> > >> > Linux sockets, not RTnet ones. Did you compile them
> manually,
> > > or
> > >> where they
> > >> > built by the Xenomai build system? Check if they
> refer to
> > > symbols like
> > >> > "__wrap_socket", rather than just "socket".
> > >> >
> > >> > Jan
> > >> >
> > >> > > Can anyone tell me why I do get that error?
> > >> > > In order to this I need to say that both BBB's
> get a random
> > > MAC-Adress
> > >> > > after each boot. That means I need to tell each
> BBB which
> > > MAC adress
> > >> > > belongs to which IP-Adress. For example BBB1 has
> IP
> > > 192.168.127.10
> > >> with MAC
> > >> > > AA:AA:AA:AA:AA and BBB2 has IP 192.168.127.11
> with MAC
> > >> BB:BB:BB:BB:BB I
> > >> > > need to execute the following commands:
> > >> > >
> > >> > > For BBB1: rtroute add 192.168.127.11
> BB:BB:BB:BB:BB dev
> > > rteth0
> > >> > > For BBB2: rtroute add 192.168.127.10
> AA:AA:AA:AA:AA dev
> > > rteth0
> > >> > >
> > >> > > Now it is possible to send rtpings with the
> command: rtping
> > >> 192.168.127.10
> > >> > > or rtping 192.168.127.11. Depens on which BBB you
> want to
> > > send the
> > >> ping.
> > >> > >
> > >> > > So my idea was it is only possible to run the
> "rtt-sender"
> > > and
> > >> > > "rtt-responder" file when my BBB's know which MAC
> belongs
> > > to which IP.
> > >> > >
> > >> > > But there is still the error, that the Network is
> > > unreachable. Why?
> > >> > >
> > >> > > You can find the source-files enclosed.
> > >> > >
> > >> > > Kind Regards
> > >> > > -------------- next part --------------
> > >> > > A non-text attachment was scrubbed...
> > >> > > Name: image.png
> > >> > > Type: image/png
> > >> > > Size: 13271 bytes
> > >> > > Desc: not available
> > >> > > URL:
> > >> >
> > >> <
> > >
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.png
> > >>
> > >> > > -------------- next part --------------
> > >> > > A non-text attachment was scrubbed...
> > >> > > Name: rtt-sender.c
> > >> > > Type: application/octet-stream
> > >> > > Size: 9879 bytes
> > >> > > Desc: not available
> > >> > > URL:
> > >> >
> > >> <
> > >
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment.obj
> > >>
> > >> > > -------------- next part --------------
> > >> > > A non-text attachment was scrubbed...
> > >> > > Name: rtt-responder.c
> > >> > > Type: application/octet-stream
> > >> > > Size: 5705 bytes
> > >> > > Desc: not available
> > >> > > URL:
> > >> >
> > >> <
> > >
> >
> http://xenomai.org/pipermail/xenomai/attachments/20190605/8613c6ca/attachment-0001.obj
> > >>
> > >> > >
> > >> >
> > >> > --
> > >> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > >> > Corporate Competence Center Embedded Linux
> > >> >
> > >>
> > >> --
> > >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > >> Corporate Competence Center Embedded Linux
> > >>
> > >
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-07 9:40 ` danwe
@ 2019-06-07 10:15 ` Jan Kiszka
2019-06-07 10:22 ` danwe
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-06-07 10:15 UTC (permalink / raw)
To: danwe, xenomai
On 07.06.19 11:40, danwe wrote:
> I have checked what the generated binary is using.
> E.g. it is using lines like:
>
> 19: 00008bc8 0 FUNC GLOBAL DEFAULT UND ioct1@GLIBC_2.4 (3)
> 45: 00008cc4 0 FUNC GLOBAL DEFAULT UND socket@GLIBC_2.4 (3)
>
> Does that mean that it is using the non-rt glibc services? If so then I do not
> understand one thing: the file "raw-ethernet" is a example where it uses the
> same ioct1@GLIBC and socket@GLIBC but it does not throw the "network is
> unreachable error".
> But how can I change that it is using the __wrap_socket?
Compare the invoked gcc command line with the output of "xeno-config
--skin=posix --ldflags". Something is preventing the the required flags make it
into your build. Also try building manually, to exclude flaws in your buildroot
environment.
Does "raw-ethernet rteth0" actually work? Or are you calling "raw-ethernet eth0"
by accident?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-07 10:15 ` Jan Kiszka
@ 2019-06-07 10:22 ` danwe
2019-06-07 11:48 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: danwe @ 2019-06-07 10:22 UTC (permalink / raw)
To: Jan Kiszka, xenomai
Raw-ethernet rteth0 does work. See the output:
# /usr/examples/xenomai/posix/raw-ethernet eth0
cannot get interface index: No such device
# /usr/examples/xenomai/posix/raw-ethernet rteth0
Sent frame of 1514 bytes
Sent frame of 1514 bytes
Sent frame of 1514 bytes
Sent frame of 1514 bytes
shutting down
So should I compare the invoked gcc command line with the output of
"xeno-config
--skin=posix --ldflags"? Can that be possible if "raw-ethernet" is working?
Daniel
Am Fr., 7. Juni 2019 um 12:15 Uhr schrieb Jan Kiszka <jan.kiszka@siemens.com
>:
> On 07.06.19 11:40, danwe wrote:
> > I have checked what the generated binary is using.
> > E.g. it is using lines like:
> >
> > 19: 00008bc8 0 FUNC GLOBAL DEFAULT UND ioct1@GLIBC_2.4 (3)
> > 45: 00008cc4 0 FUNC GLOBAL DEFAULT UND socket@GLIBC_2.4 (3)
> >
> > Does that mean that it is using the non-rt glibc services? If so then I
> do not
> > understand one thing: the file "raw-ethernet" is a example where it uses
> the
> > same ioct1@GLIBC and socket@GLIBC but it does not throw the "network is
> > unreachable error".
> > But how can I change that it is using the __wrap_socket?
>
> Compare the invoked gcc command line with the output of "xeno-config
> --skin=posix --ldflags". Something is preventing the the required flags
> make it
> into your build. Also try building manually, to exclude flaws in your
> buildroot
> environment.
>
> Does "raw-ethernet rteth0" actually work? Or are you calling "raw-ethernet
> eth0"
> by accident?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-07 10:22 ` danwe
@ 2019-06-07 11:48 ` Jan Kiszka
2019-06-12 6:48 ` danwe
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-06-07 11:48 UTC (permalink / raw)
To: danwe, xenomai
On 07.06.19 12:22, danwe wrote:
> Raw-ethernet rteth0 does work. See the output:
>
> # /usr/examples/xenomai/posix/raw-ethernet eth0
> cannot get interface index: No such device
> # /usr/examples/xenomai/posix/raw-ethernet rteth0
> Sent frame of 1514 bytes
> Sent frame of 1514 bytes
> Sent frame of 1514 bytes
> Sent frame of 1514 bytes
> shutting down
>
> So should I compare the invoked gcc command line with the output of "xeno-config
> --skin=posix --ldflags"? Can that be possible if "raw-ethernet" is working?
It doesn't make sense yet, I agree - unless there is RTmac with its vnic also
loaded so that you have rteth0 on the Linux side as well (check ifconfig -a).
Jan
>
> Daniel
>
> Am Fr., 7. Juni 2019 um 12:15 Uhr schrieb Jan Kiszka <jan.kiszka@siemens.com
> <mailto:jan.kiszka@siemens.com>>:
>
> On 07.06.19 11:40, danwe wrote:
> > I have checked what the generated binary is using.
> > E.g. it is using lines like:
> >
> > 19: 00008bc8 0 FUNC GLOBAL DEFAULT UND ioct1@GLIBC_2.4 (3)
> > 45: 00008cc4 0 FUNC GLOBAL DEFAULT UND socket@GLIBC_2.4 (3)
> >
> > Does that mean that it is using the non-rt glibc services? If so then I
> do not
> > understand one thing: the file "raw-ethernet" is a example where it uses the
> > same ioct1@GLIBC and socket@GLIBC but it does not throw the "network is
> > unreachable error".
> > But how can I change that it is using the __wrap_socket?
>
> Compare the invoked gcc command line with the output of "xeno-config
> --skin=posix --ldflags". Something is preventing the the required flags make it
> into your build. Also try building manually, to exclude flaws in your buildroot
> environment.
>
> Does "raw-ethernet rteth0" actually work? Or are you calling "raw-ethernet
> eth0"
> by accident?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black
2019-06-07 11:48 ` Jan Kiszka
@ 2019-06-12 6:48 ` danwe
0 siblings, 0 replies; 12+ messages in thread
From: danwe @ 2019-06-12 6:48 UTC (permalink / raw)
To: Jan Kiszka, xenomai
I have checked ifconifg -a and rtifconfig -a. For my "rtt-sender" do I have
to use my IP address 192.168.127.11 or my internet address 127.0.0.1?
Output:
# rtifconfig -a
rteth0 Medium: Ethernet Hardware address: 86:98:B3:8B:88:B4
IP address: 192.168.127.11 Broadcast address: 192.168.127.255
UP BROADCAST RUNNING MTU: 1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Am Fr., 7. Juni 2019 um 13:48 Uhr schrieb Jan Kiszka <jan.kiszka@siemens.com
>:
> On 07.06.19 12:22, danwe wrote:
> > Raw-ethernet rteth0 does work. See the output:
> >
> > # /usr/examples/xenomai/posix/raw-ethernet eth0
> > cannot get interface index: No such device
> > # /usr/examples/xenomai/posix/raw-ethernet rteth0
> > Sent frame of 1514 bytes
> > Sent frame of 1514 bytes
> > Sent frame of 1514 bytes
> > Sent frame of 1514 bytes
> > shutting down
> >
> > So should I compare the invoked gcc command line with the output of
> "xeno-config
> > --skin=posix --ldflags"? Can that be possible if "raw-ethernet" is
> working?
>
> It doesn't make sense yet, I agree - unless there is RTmac with its vnic
> also
> loaded so that you have rteth0 on the Linux side as well (check ifconfig
> -a).
>
> Jan
>
> >
> > Daniel
> >
> > Am Fr., 7. Juni 2019 um 12:15 Uhr schrieb Jan Kiszka <
> jan.kiszka@siemens.com
> > <mailto:jan.kiszka@siemens.com>>:
> >
> > On 07.06.19 11:40, danwe wrote:
> > > I have checked what the generated binary is using.
> > > E.g. it is using lines like:
> > >
> > > 19: 00008bc8 0 FUNC GLOBAL DEFAULT UND ioct1@GLIBC_2.4 (3)
> > > 45: 00008cc4 0 FUNC GLOBAL DEFAULT UND socket@GLIBC_2.4 (3)
> > >
> > > Does that mean that it is using the non-rt glibc services? If so
> then I
> > do not
> > > understand one thing: the file "raw-ethernet" is a example where
> it uses the
> > > same ioct1@GLIBC and socket@GLIBC but it does not throw the
> "network is
> > > unreachable error".
> > > But how can I change that it is using the __wrap_socket?
> >
> > Compare the invoked gcc command line with the output of "xeno-config
> > --skin=posix --ldflags". Something is preventing the the required
> flags make it
> > into your build. Also try building manually, to exclude flaws in
> your buildroot
> > environment.
> >
> > Does "raw-ethernet rteth0" actually work? Or are you calling
> "raw-ethernet
> > eth0"
> > by accident?
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-06-12 6:48 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-05 10:30 Round-Trip Time Requester with Xenomai / RTnet on Beaglebone Black danwe
2019-06-06 6:06 ` Jan Kiszka
[not found] ` <CAEmXcAxuFzE2uQHGMUjBnbgadTTcNU_DwV64uvLPahxxDMKTyQ@mail.gmail.com>
2019-06-06 10:00 ` Jan Kiszka
[not found] ` <CAEmXcAxs3O_Hmph-48JArHgCmWSj+wAiffkNCZKiL9uVew6irg@mail.gmail.com>
[not found] ` <22b6931e-8f7b-0cae-2316-5b278d1186d6@siemens.com>
2019-06-06 17:50 ` Fwd: " danwe
2019-06-07 5:00 ` Jan Kiszka
2019-06-07 8:09 ` danwe
2019-06-07 8:40 ` Jan Kiszka
2019-06-07 9:40 ` danwe
2019-06-07 10:15 ` Jan Kiszka
2019-06-07 10:22 ` danwe
2019-06-07 11:48 ` Jan Kiszka
2019-06-12 6:48 ` danwe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.