Re: [I-PIPE] ipipe-core-4.4.185-cip35-x86-16 released
Hey Jan, On Wed, Aug 07, 2019 at 06:51:27PM +0200, Jan Kiszka via Xenomai wrote: > On 07.08.19 18:45, xenomai--- via Xenomai wrote: > > Download URL: > > https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.4.185-cip35-x86-16.patch > > > > Repository: https://git.xenomai.org/ipipe-x86 > > Release tag: ipipe-core-4.4.185-cip35-x86-16 > > > > With this release, I'd like to announce that I will no longer update the > plain-LTS branch ipipe-4.4.y and therefore also no longer publish new > ipipe-core-4.4.y-x86 releases. This will simply reduce the number of branches > and test targets on my side while the CIP kernel is providing the longer > perspective anyway. > > Reminder: When folks send me test reports for ARM on the ipipe-4.4.y-cip > branch, > I'll also do the corresponding release. Sure, hopefully I can provide them next week. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: Fwd: Building Xenomai 3 , Kernel 4 ... for BeagleBone Black
On Wed, Jul 31, 2019 at 09:59:41AM +0200, danwe wrote: > Thanks for the setup. Sorry for asking but as I am new to that topic I > don't understand how to use that site u sent me. Do I have to download > Xenomai 3 first and then copy/paste the files on your site? I don't really > understand the readme file. > For example: In the readme file I see the following: > > > > After adding meta-core and a BSP layer (right now there's only meta-beaglebone > available, so probably that one!), build the xenomai-test-image. > > > So now I ask myself. Where should I add meta-core and meta-beaglebone to > and how can I build the xenomai-test-image then? > I don't understand the dependencies. Its a completely generic OpenEmbedded build setup. If you're not used to doing so, just go to readme item IV: Using kas. Then it essentially boils down to the three commands given there verbatim, just needing docker to be available as well as quite some HD space and CPU cycles. > > Thanks. > > Daniel > > Am Mi., 31. Juli 2019 um 09:01 Uhr schrieb Josef Holzmayr < > holzm...@rsi-elektrotechnik.de>: > > > On Wed, Jul 31, 2019 at 08:50:18AM +0200, danwe via Xenomai wrote: > > > Thanks for your response. Maybe it was a bit unclear from my side: > > > I need to build the Kernel and Xenomai 3. So I do neither want to build > > the > > > kernel and userland tools on top of an existing image nor building > > anything > > > on top. Or what do you mean by building on top? Is there anything > > "deeper" > > > than a Kernel? > > > And again: Does building a Kernel with Xenomai 3 depends on the paltform > > I > > > want to use it on? I need to use it on a BeagleBone Black. Do I have to > > > change anything for use it on BBB? > > > Thanks. > > > > You could use the setup I employ for doing the CIP kernel tests. All > > nicely prepared for Xenomai 3 and BBB, only thing you'd have to swap out > > is the kernel itself which is not too complicated. > > > > https://github.com/LetoThe2nd/meta-xenomai Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: Fwd: Building Xenomai 3 , Kernel 4 ... for BeagleBone Black
On Wed, Jul 31, 2019 at 08:50:18AM +0200, danwe via Xenomai wrote: > Thanks for your response. Maybe it was a bit unclear from my side: > I need to build the Kernel and Xenomai 3. So I do neither want to build the > kernel and userland tools on top of an existing image nor building anything > on top. Or what do you mean by building on top? Is there anything "deeper" > than a Kernel? > And again: Does building a Kernel with Xenomai 3 depends on the paltform I > want to use it on? I need to use it on a BeagleBone Black. Do I have to > change anything for use it on BBB? > Thanks. You could use the setup I employ for doing the CIP kernel tests. All nicely prepared for Xenomai 3 and BBB, only thing you'd have to swap out is the kernel itself which is not too complicated. https://github.com/LetoThe2nd/meta-xenomai Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: Xenomai kernel for BBB
Hi Jan, On Thu, Apr 04, 2019 at 12:47:10PM +0200, Josef Holzmayr via Xenomai wrote: > On Thu, Apr 04, 2019 at 12:12:10PM +0200, Jan Kiszka wrote: > > > > BTW, if you have time to test the current ipipe-4.4.y[-cip] branches, I > > would also tag ARM stable releases for them. Here we go for 4.4.y-cip, 33f523bee3eba222ac67e9d27d783418f2408078 xenomai on stable/v3.0.x, 0e79d326061190e08f53e7a41bcea50da4859615 xeno-test passes root@beaglebone-xenomai:~# latency -q -s -t 0 -T 86400 == Sampling period: 1000 us == Test mode: periodic user-mode task == All results in microseconds warming up... running quietly for 86400 seconds HSH|--param|--samples-|--average--|---stddev-- HSS|min| 86399| 7.876| 0.924 HSS|avg| 86399985| 16.155| 4.353 HSS|max| 86399| 35.361| 2.108 ---|---|---|---||--|- RTS| 6.026| 16.659| 52.157| 0| 0|24:00:00/24:00:00 root@beaglebone-xenomai:~# latency -q -s -t 2 -T 86400 == Sampling period: 1000 us == Test mode: in-kernel timer handler == All results in microseconds warming up... running quietly for 86400 seconds HSH|--param|--samples-|--average--|---stddev-- HSS|min| 86399| 0.046| 0.208 HSS|avg| 86399987| 4.091| 1.306 HSS|max| 86399| 11.764| 1.379 ---|---|---|---||--|- RTS| -1.084| 4.605| 20.697| 0| 0|24:00:00/24:00:00 Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: Xenomai kernel for BBB
On Thu, Apr 04, 2019 at 12:12:10PM +0200, Jan Kiszka wrote: > On 04.04.19 11:24, Josef Holzmayr wrote: > > On Thu, Apr 04, 2019 at 10:40:13AM +0200, Jan Kiszka via Xenomai wrote: > > > On 04.04.19 10:31, Philippe Gerum via Xenomai wrote: > > > > On 4/3/19 7:16 PM, Philippe Gerum wrote: > > > > > On 4/3/19 9:55 AM, Pierre FICHEUX via Xenomai wrote: > > > > > > Hi, > > > > > > > > > > > > Xenomai kernel (-xenomai branches) is available for BBB (AM335x) > > > > > > from > > > > > > https://github.com/beagleboard/linux for some kernel releases (4.4, > > > > > > 4.9, > > > > > > 4.14). I've tried 4.9 and 4.14 but jitter is very bad with latency > > > > > > tool (> > > > > > > 200 µs). > > > > > > > > > > > > According to Xenomai wiki, AM335x SoC is supported for "vendor > > > > > > branch", > > > > > > hope this is the same thing (?) > > > > > > > > > > > > Dos anybody use AM335x with success? I did it a long time ago with > > > > > > Xenomai > > > > > > 2 and 3.8.13 kernel. > > > > > > > > > > > > > > > > CONFIG_ARM_CPUIDLE hurts badly on this platform, disabling it restores > > > > > proper latency figures. > > > > > > > > > > A quick port of the latest I-pipe code ported to the bbb kernel 4.14 > > > > > can > > > > > be pulled from this URL (lightly tested): > > > > > https://lab.xenomai.org/ipipe-rpm.git/log/?h=arm/4.14.110-bbb > > > > > > > > > > > > > too much haste: clone from [1], branch arm/4.14.108-bbb, which is based > > > > on the 4.14 branch of the Beagleboard tree (as of yesterday). > > > > > > > > [1] git://lab.xenomai.org/ipipe-rpm.git > > > > > > > > > > Does the BBB really still need a vendor kernel? Definitely not for booting > > > and core functionality. > > > > > > Jan > > > > It should already do pretty fine with 4.4-cip, as thats what I'm doing > > my tests on. > > Thanks, good to know. > > BTW, if you have time to test the current ipipe-4.4.y[-cip] branches, I > would also tag ARM stable releases for them. > > Jan > Sure, will do. Hopefully done by the end of next week, given the needed ~3 days for long term runs and I can't start until Monday. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: Xenomai kernel for BBB
On Thu, Apr 04, 2019 at 10:40:13AM +0200, Jan Kiszka via Xenomai wrote: > On 04.04.19 10:31, Philippe Gerum via Xenomai wrote: > > On 4/3/19 7:16 PM, Philippe Gerum wrote: > > > On 4/3/19 9:55 AM, Pierre FICHEUX via Xenomai wrote: > > > > Hi, > > > > > > > > Xenomai kernel (-xenomai branches) is available for BBB (AM335x) from > > > > https://github.com/beagleboard/linux for some kernel releases (4.4, 4.9, > > > > 4.14). I've tried 4.9 and 4.14 but jitter is very bad with latency tool > > > > (> > > > > 200 µs). > > > > > > > > According to Xenomai wiki, AM335x SoC is supported for "vendor branch", > > > > hope this is the same thing (?) > > > > > > > > Dos anybody use AM335x with success? I did it a long time ago with > > > > Xenomai > > > > 2 and 3.8.13 kernel. > > > > > > > > > > CONFIG_ARM_CPUIDLE hurts badly on this platform, disabling it restores > > > proper latency figures. > > > > > > A quick port of the latest I-pipe code ported to the bbb kernel 4.14 can > > > be pulled from this URL (lightly tested): > > > https://lab.xenomai.org/ipipe-rpm.git/log/?h=arm/4.14.110-bbb > > > > > > > too much haste: clone from [1], branch arm/4.14.108-bbb, which is based > > on the 4.14 branch of the Beagleboard tree (as of yesterday). > > > > [1] git://lab.xenomai.org/ipipe-rpm.git > > > > Does the BBB really still need a vendor kernel? Definitely not for booting > and core functionality. > > Jan It should already do pretty fine with 4.4-cip, as thats what I'm doing my tests on. Greetz > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: [ANNOUNCE] Xenomai 3.0.8 released
On Tue, Jan 15, 2019 at 06:02:09PM +0100, Jan Kiszka wrote: > On 15.01.19 15:23, Josef Holzmayr wrote: > > Hi Jan, > > > > On Mon, Jan 14, 2019 at 04:12:32PM +0100, Jan Kiszka via Xenomai wrote: > > > An overdue stable release has just been completed. > > > > Do you see any value in a test cycle comparable to the CIP kernel on the > > BBB? > > > > If your other test was using master and you didn't run anything against > stable for a while, yes. The tests were conducted against 9741e102 which is stable, yet not exactly HEAD. Will hopefully have some updated results next week. > Ideally, we should do more of those tests in the future before a release :). :-) -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: [ANNOUNCE] Xenomai 3.0.8 released
Hi Jan, On Mon, Jan 14, 2019 at 04:12:32PM +0100, Jan Kiszka via Xenomai wrote: > An overdue stable release has just been completed. Do you see any value in a test cycle comparable to the CIP kernel on the BBB? Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: I-pipe 4.4.x-cip
On Thu, Dec 20, 2018 at 05:32:37PM +0100, Jan Kiszka wrote: > https://gitlab.denx.de/Xenomai/ipipe/tree/ipipe-4.4.y-cip > > For now, I would ask everyone interested in this baseline, may it be on x86 > or ARM, to try out the new branch. So here's some proper test results for 4.4.166-cip29 / 60a778a4a6aebf030d12c0eeab08ea9b060389b1 on the Beaglebone Black (ARM32). As far as I can say, looks good. with $ switchtest -s 200 -Q& $ while :; do dd if=/dev/zero of=/dev/null bs=32M; done& root@beaglebone-xenomai:~# latency -t0 --silent -q -s -T 86400 == Sampling period: 1000 us == Test mode: periodic user-mode task == All results in microseconds warming up... running quietly for 86400 seconds HSH|--param|--samples-|--average--|---stddev-- HSS|min| 86399| 8.528| 1.130 HSS|avg| 86399988| 17.416| 5.038 HSS|max| 86399| 38.505| 1.526 ---|---|---|---||--|- RTS| 6.206| 17.911| 51.523| 0| 0|24:00:00/24:00:00 root@beaglebone-xenomai:~# latency -t2 --silent -q -s -T 86400 == Sampling period: 1000 us == Test mode: in-kernel timer handler == All results in microseconds warming up... running quietly for 86400 seconds HSH|--param|--samples-|--average--|---stddev-- HSS|min| 86399| 0.002| 0.046 HSS|avg| 86399988| 4.624| 1.289 HSS|max| 86399| 12.269| 1.688 ---|---|---|---||--|- RTS| -1.049| 5.109| 21.314| 0| 0|24:00:00/24:00:00 freestanding xeno-test: root@beaglebone-xenomai:~# xeno-test -- --silent -q -s Started child 16390: /bin/sh /usr/bin/xeno-test-run-wrapper /usr/bin/xeno-test -- --silent -q -s ++ echo 0 ++ testdir=/usr/bin ++ /usr/bin/smokey --run arith OK bufp OK cpu_affinity OK iddp OK leaks OK net_packet_dgram skipped (no kernel support) net_packet_raw skipped (no kernel support) net_udp skipped (no kernel support) posix_clock OK posix_cond OK posix_fork OK mutex_trylock not supported posix_mutex OK posix_select OK rtdm OK sched_quota OK sched_tp OK setsched OK sigdebug OK timerfd OK tsc OK vdso_access OK xddp OK ++ /usr/bin/clocktest -D -T 30 -C CLOCK_HOST_REALTIME hostrt data area is live sequence counter : 575854 wall_time_sec: 1545676197 wall_time_nsec : 268000965 wall_to_monotonic_sec: -1545674157 wall_to_monotonic_nsec : 106265047 cycle_last : 48969069692 mask : 0x mult : 699050667 shift: 24 == Testing built-in CLOCK_HOST_REALTIME (32) CPU ToD offset [us] ToD drift [us/s] warps max delta [us] --- -- -- 0 0.9 -0.016 00.0 ++ /usr/bin/switchtest -T 30 == Testing FPU check routines... d0: 1 != 2 d1: 1 != 2 d2: 1 != 2 d3: 1 != 2 d4: 1 != 2 d5: 1 != 2 d6: 1 != 2 d7: 1 != 2 d8: 1 != 2 d9: 1 != 2 d10: 1 != 2 d11: 1 != 2 d12: 1 != 2 d13: 1 != 2 d14: 1 != 2 d15: 1 != 2 == FPU check routines: OK. == Threads: sleeper_ufps0-0 rtk0-1 rtk0-2 rtk_fp0-3 rtk_fp0-4 rtk_fp_ufpp0-5 rtk_fp_ufpp0-6 rtup0-7 rtup0-8 rtup_ufpp0-9 rtup_ufpp0-10 rtus0-11 rtus0-12 rtus_ufps0-13 rtus_ufps0-14 rtuo0-15 rtuo0-16 rtuo_ufpp0- 17 rtuo_ufpp0-18 rtuo_ufps0-19 rtuo_ufps0-20 rtuo_ufpp_ufps0-21 rtuo_ufpp_ufps0-22 RTT| 00:00:01 RTH|-cpu|ctx switches|---total RTD| 0| 16215| 16215 RTD| 0| 16213| 32428 RTD| 0| 16215| 48643 RTD| 0| 16215| 64858 RTD| 0| 16150| 81008 RTD| 0| 16215| 97223 RTD| 0| 16211| 113434 RTD| 0| 16215| 129649 RTD| 0| 16215| 145864 RTD| 0| 16215| 162079 RTD| 0| 16150| 178229 RTD| 0| 16215| 19 RTD| 0| 16213| 210657 RTD| 0| 16215| 226872 RTD| 0| 16215| 243087 RTD| 0| 16213| 259300 RTD| 0| 16215| 275515 RTD| 0| 16215| 291730 RTD| 0| 16215| 307945 RTD| 0| 16215| 324160 RTD| 0| 16215| 340375 RTT| 00:00:22 RTH|-cpu|ctx switches|---total RTD| 0| 16215| 356590 RTD| 0| 16148| 372738 RTD| 0| 16215| 388953 RTD| 0| 16213| 405166 RTD| 0| 16215| 421381 RTD| 0| 16150| 437531 RTD| 0| 16213| 453744 RTD| 0| 16215| 469959 RTD| 0| 14695| 484654 ++ start_load ++ echo start_load ++ false ++ check_alive /usr/bin/latency --silent -q -s ++ echo check_alive /usr/bin/latency --silent -q -s ++ wait_load ++ read rc Started child 16488: dohell 900
Re: I-pipe 4.4.x-cip
Hi Jan, On Thu, Dec 20, 2018 at 05:32:37PM +0100, Jan Kiszka wrote: > Hi all, > > just a quick note that I started a 4.4-cip based I-pipe tree: > > https://gitlab.denx.de/Xenomai/ipipe/tree/ipipe-4.4.y-cip > > So far it's just a merge of ipipe-4.4.y @ipipe-core-4.4.166-x86-12 with the > CIP tree @4.4.166-cip29. I'm not yet sure whether to switch 4.4 completely > to -cip or have both running in parallel for some more time. Thanks, https://github.com/LetoThe2nd/meta-xenomai has been updated accordingly. > > For now, I would ask everyone interested in this baseline, may it be on x86 > or ARM, to try out the new branch. Preliminary results on Beaglebone Black: - xeno-test passes - latency -t 0 maxes out at ~70µs - latency -t 2 maxes out at ~23µs Our companys long term testing booth is unavailable until Jan 7th, so more delay again for proper results, sorry. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32
Hi Jan, On Mon, Nov 26, 2018 at 03:40:38PM +0100, Jan Kiszka wrote: > On 26.11.18 15:30, Josef Holzmayr wrote: > > On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote: > > > On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote: > > > > - only one BSP layer so far, namely the Beaglebone. This was chosen for > > > > two major reasons: a) it is supported well enough in 4.4. to not > > > > need > > > > additional patches which might introduce new issues, and b) it is > > > > hardware that I have here ready for testing. > > > > > > I was thinking about which ARMv7 board to add to xenomai-images (enabling > > > qemu will be first, though), and that is a good candidate there as well. > > > > > > Another half-done topic here: CI builds. For that, the BB defconfig could > > > be > > > useful too. > > > > My local tinkering of xenoami-images to create a qemu-armhf build is > > still in progress. But yes, we should have a build there too. But I > > Oh, we might have worked in parallel, sorry: I've qemu-armhf for > xenomai-images locally already (just started today). Will post later. Saw that, thanks. Given my limited time investment, I'm happy to see it happening, and thats it. > > > don't think the BB defconfig I'm using at the moment is really suited > > for xenomai testing. I'll certainly need to tinker with it some more. > > Yes, configs is a good topic. I was playing with them a lot today, to get > some output first, then to find some reasonable debug setup. Considering to > have a "release" (measurement) and "debug" profile for configs. > > > > > > > > > > - no higher automation like a kas cofiguration so far. Yet this probably > > > > will be the first limitation to be gotten rid of. kas files are now in place, equivalent to the ones in xenomai-images > > > > Preliminary results to kick off things: > > > > - xeno-test completes successfully > > > > - latency -t0 under load maxes at ~58µs > > > > - latency -t2 under load maxes at ~18µs > > > > > > > > > > Great! According to [1], we could then tag 63637800 also for ARM? Or do > > > you > > > want to run more of the tests you have in mind first? > > > > Given my current testing experience, I would like to not say yes or no, > > as I'm not knowledgeable enough to judge. So please decide yourself upon > > the given information, with those additional "hints": > > - xeno-test "only" runs for 15minutes by default. > > - the latency tests I did were not really more long-lived, I don't think > >any one exceeded 30minutes. > > - it will be at least two more weeks until I have the long-run results. > >Could also be three. So if you want to tag rather soon, I can't rally > >help more. > > OK, then I will not hurry. Digging deeper, I now have a couple of questions. xeno-test gives me net_packet_dgram skipped (no kernel support) net_packet_raw skipped (no kernel support) net_udp skipped (no kernel support) ... mutex_trylock not supported ... sched_quota skipped (no kernel support) sched_tp skipped (no kernel support) ... sigdebug "SIGDEBUG_MIGRATE_PRIOINV" skipped (no kernel support) So what do I need to increase test coverage here? And, during the run I get [ 75.650644] [Xenomai] watchdog triggered on CPU #0 -- runaway thread 'test' signaled [ 75.658601] sched: RT throttling activated Is that good, bad, upgly, or expected? Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
Re: Testing of 4.4/Ipipe + Xenomai 3.0.X on ARM32
Hi Jan, On Fri, Nov 23, 2018 at 01:48:27PM +0100, Jan Kiszka wrote: > Hi Sepp, > > On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote: > > Hello! > > > > To improve the testing situation for the 4.4 Kernel family on ARM32, I > > created a set of layers [1] for OpenEmbedded. Currently the features are > > rather limited: > > > > - only the Morty branch exists, as this one natively includes Linux 4.4 > >and therefore the GCC version etc. matches. > > To my best knowledge, there is no dependency (yet) between a too new > compiler and kernel 4.4. We are building 4.4-cip with pyro, e.g. Yes, I agree that pyro and rocko should probably not give any major trouble. Yet, something in the back of my head tells me that thud and maybe sumo will be problematic. Will investigate and report! > > - only one BSP layer so far, namely the Beaglebone. This was chosen for > >two major reasons: a) it is supported well enough in 4.4. to not need > >additional patches which might introduce new issues, and b) it is > >hardware that I have here ready for testing. > > I was thinking about which ARMv7 board to add to xenomai-images (enabling > qemu will be first, though), and that is a good candidate there as well. > > Another half-done topic here: CI builds. For that, the BB defconfig could be > useful too. My local tinkering of xenoami-images to create a qemu-armhf build is still in progress. But yes, we should have a build there too. But I don't think the BB defconfig I'm using at the moment is really suited for xenomai testing. I'll certainly need to tinker with it some more. > > > - no higher automation like a kas cofiguration so far. Yet this probably > >will be the first limitation to be gotten rid of. > > > > My current planning is to add a set of testing scripts based of > > Philippe's suggestion, and run that suite on each new release for a > > couple of days and post the results to the ML. > > That sounds very helpful! We should try to keep common parts (anything > unrelated to the image build system) in the core so that we can reuse that > in xenomai-images as well. In the end, it would probably just be something like "xeno-test-long" > > > > > Preliminary results to kick off things: > > - xeno-test completes successfully > > - latency -t0 under load maxes at ~58µs > > - latency -t2 under load maxes at ~18µs > > > > Great! According to [1], we could then tag 63637800 also for ARM? Or do you > want to run more of the tests you have in mind first? Given my current testing experience, I would like to not say yes or no, as I'm not knowledgeable enough to judge. So please decide yourself upon the given information, with those additional "hints": - xeno-test "only" runs for 15minutes by default. - the latency tests I did were not really more long-lived, I don't think any one exceeded 30minutes. - it will be at least two more weeks until I have the long-run results. Could also be three. So if you want to tag rather soon, I can't rally help more. Greetz -- ——— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
[PATCH][xenomai-images] start-qemu.sh: detect if DISPLAY is set
If DISPLAY is not set and therefore the SDL-based
GUI of QEMU is most likely to fail, we resort to the
-nographic variant.
Signed-off-by: Josef Holzmayr
---
start-qemu.sh | 4
1 file changed, 4 insertions(+)
diff --git a/start-qemu.sh b/start-qemu.sh
index 3d1117e..0daf69c 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -63,6 +63,10 @@ IMAGE_FILE=$(ls ${IMAGE_PREFIX}.ext4.img)
KERNEL_FILE=$(ls ${IMAGE_PREFIX}.vmlinuz* | tail -1)
INITRD_FILE=$(ls ${IMAGE_PREFIX}.initrd.img* | tail -1)
+if [ -z "${DISPLAY}" ]; then
+ QEMU_EXTRA_ARGS="${QEMU_EXTRA_ARGS} -nographic"
+fi
+
shift 1
${QEMU_PATH}${QEMU} \
--
2.19.1
--
_
R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
Fon: +49 8444 9204-0
Fax: +49 8444 9204-50
www.rsi-elektrotechnik.de
_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548
