machinekit not ready for Xenomai3, jessie, beagleboard X15

[mhaberler]

we have several major release changes ahead in supporting components and platforms:

• debian jessie has become debian stable as per April 25, 2015
• the Xenomai project is readying a major release
• the Beagleboard X15 high-end successor to the Beaglebone will appear sooner or later but is not supported by the current kernel

there were some offlist discussions on the topic. To summarize the key issues:

• the jessie transition will bring some relief on most of the custom packages required, but not all of them
• the Xenomai 2->3 transition requires a new kernel, an new runtime support package, and review/likely some changes in the RTAPI xenomai code
• the Xenomai2->3 transition affects Xenomai kernels for all platforms (x86, amd64, arm) but there is a less stringent version lock-in with x86 and amd64 as most of required support code is mainlined
• there is a 3.14 xenomai kernel based on a TI branch which supports both the BBB and the X15, however it does not support capemgr (dynamic loading of device tree overlays) -- all device tree overlays needed must be compiled into the kernel. capemgr will appear mainline hopefully but unclear when, and when a Xenomai patch for the matching baseline version is available.
• for the TI 3.14 based kernels, also an RT-PREEMPT kernel is available, which might be interesting for 7i80 ethernet users and other applications.
• Charles' config-pin utility is most what is needed; some tweaks might be required.

resulting feature matrix and options:

kernel    RT        hardware    Xenomai   capemgr   config-pin

3.8       xeno      BBB         2 and 3    yes     yes
3.14-ti   xeno      BBB+X15     2 and 3    no      yes
3.14-ti   rtpreempt BBB+X15     N/A        no      yes

3.14      xeno      x86         2 and 3    N/A     N/A
3.18(20?) rtpreempt x86         N/A        N/A     N/A
3.18.12   xeno      x86         3          N/A     N/A

Based on the above, for a major transition there was some preference for:

• including Xenomai 3 in the transition
• seek to have appropriate kernels for all platforms, which would suggest 3.14-xenomai for BBB/X15 and at least a Xenomai2->3 iteration on the x86/amd64 kernels
• ideally have SGX drivers and accelerated Qt based desktops on the TI platforms

the missing capemgr seems not to be a showstopper, but we must assure all required device trees are compiled in. We might need a bit of soul searching so we have all candidates rounded up.

so much for the wouldnt it be nice if.. feature list.

the intent of this issue: collect all aspects on how to get there

[RunningLight]

On 04/29/2015 05:56 AM, Michael Haberler wrote:

debian jessie will become stable later this spring

Excuse me. As of 25 April 2015, Debian 8 is the "latest stable release."
That's why I'm exercising John's fixes.

[mhaberler]

oops, updated

[zultron]

Packaging-related differences:

• MK deps absent from Jessie that I'm preparing to ship: (shipped)
  • Xenomai and RTAI runtime and kernels
  • czmq
  • libwebsockets: in Jessie; remind me why we have our own package?
• zeromq CURVE support missing in Jessie pkgs: corrected
  • zeromq3 is in Jessie, as is libsodium, but zeromq3 not compiled with CURVE support
    • zeromq3 package in Jessie is ok as of 2015/05/05
      • CURVE support confirmed; downgrade attack in 4.0.5 fixed
  • AFAIK, MK doesn't actually implement CURVE support, so I dropped those packages
  • Therefore my czmq package also drops CURVE support
• Jessie dropped the RT_PREEMPT kernel

Kernels:

• At some point I'll update the ipipe-based kernels.
  • Will use Xenomai 3
  • Looks like there's a 3.16.7 ipipe patch in both Xenomai 3 and RTAI
    • Since RCN is shipping our BBB kernels, I don't need to target 3.14, and can skip to 3.16, yes?
• Debian dropped RT_PREEMPT
  • Fuckers
  • No 3.16 patch, so the featureset won't be in my combined ipipe kernel package
  • A quick fix is to rebuild the Wheezy package for Jessie
  • Need to investigate alternate/3rd-party package sources

[mhaberler]

libwebsockets - that was an API change we needed, I need to check if the jessie version already has it

re CURVE: oops - #204 is a really important todo item IMO, we have no authentication on the zeromq sockets right now (!) - we really should have the option in case we find somebody to work on it, that issue is not going away (I didnt know until now libsodium is not included anymore? maybe I missed something)

re x86/amd64 kernels: I think 3.16 is ok, yes: http://download.gna.org/adeos/patches/v3.x/x86/

re RT_PREEMPT: Xenomai3 can run over RT_PREEMPT as well, I have no experience with that yet

[mhaberler]

libwebsockets: just checked - unfortunately the jessie version is still useless for us, https://github.com/warmcat/libwebsockets/commits/v1.21-chrome26-firefox18

[zultron]

Buildbot:

• New Docker-based build scripts looking pretty good
  • Build Wheezy and Jessie (and Trusty and part of RPi) MK and build-dep packages
  • Build x86_64, i386 and armhf packages (with below Jessie/ARM exception)
• The Jessie qemu regression threw a wrench into my plan for retiring the native ARM builder
  • (This was fixed)
  • Options:
    • Temporarily acquire additional ARM builder to develop Buildbot config (@cdsteinkuehler: nudge, wink ;)
      • Build scripts need to be updated for ARM-arch Docker container
    • Issue is with gettext utilities; teach build system to only build that for binary-indep pkg builds
• Then, set up Jessie test slaves (set up)
  • For now, slaves will continue to be separate VMs for each distro+arch+kernel combo
  • Still no provision for RIP build in new builder scripts
    • Current Buildbot builds separate RIP build for use in tests
    • Goal is package-only builds, but this would require packaging functional tests
    • TBD which can be set up most quickly

Dovetail Automata package repository:

• No significant differences planned other than adding Jessie and later, possibly Trusty and RPi

[zultron]

On 04/29/2015 09:38 AM, Michael Haberler wrote:

re CURVE: oops - this is a a really important todo item IMO, we have no
authentication on the zeromq sockets right now (!): #204
#204 - we really should
have the option in case we find somebody to work on it, that issue is
not going away

If someone wants to work on it, I'll pick up the package again. What
I'd prefer is someone work with the Debian developers to rebuild the
zeromq3 and pyzmq packages with libsodium. The pieces are all
there, just needs to be enabled.

#204 neglects an important question: what is the infrastructure for
sharing the crypto data needed to establish trust? It's been a while
since I looked at CURVE, but talking in terms of other crypto systems,
there's a certificate authority pki like ssl, pubkeys like ssh, and
shared secrets like WPA personal, telnet, etc. IIRC CURVE supports at
least two of those.

IMO there's still a way to go before any kind of implementation can
start, and my plate's already pretty full.

(I didnt know until now they are not included anymore?
maybe I missed something)

Upstream distro packages never had CURVE support. The only change for
Jessie is I'm dropping my Wheezy zeromq3 etc. packages that did.

[mhaberler]

I'll take your comment on #204 over there to keep this focused on the 'next iteration' issues. But I hope we have agreement that authentication is a must-have prerequisite, even if not implemented as of now. The situation now is worse than the LinuxCNC approach (which is: unencrypted TCP and a compiled-in default password which everybody can read in the repo).

re prerequisites packages which are not available upstream:

• I understand the desire to use stock packages only - building our own is a lot of work, so of course it would be best not to have any at all
• back when we decided to build a few of our own packages, the driving factor was: either the packages were not available at all, or the versions were so outdated that we could not use them. So we decided to go for a particular released tree (eg zeromq 4.0.x) and use that API version in machinekit.
• the hope was: eventually the debian packages will catch up and we can stop producing our own; and for most of the packages this worked out. But this relies on an external factor we have no control over right now: some projects care less what goes into the debian stream. libwebsockets and zeromq are clearly in this 'dont care' category. So that has not happened, and it's questionable if we ever reach this state.

the question at hand now is - how do we deal with the situation?

• we can stay on course with our own packages and hope for upstream.
• we can work with the people doing the debian packages in parallel to get those packages up to snuff.
• we can try to step back in terms of API's to whatever is provided upstream.

In the case of zeromq and libwebsockets, I do not see a sensible way for the last option. And: if we decide to change course now, then we have been addressing the wrong problem in terms of packaging so far - we should have worked with the upstream maintainers right away.

I guess we need to make a decision how to proceed.

[RunningLight]

This discussion illustrates our severe manpower limitation. Practically, to "work with the people doing the debian packages" means dividing John's time even more (although I suspect him of having at least one clone already, given how much he's doing!). Further, I suspect any forceful expression of need on our part would elicit the reasonable suggestion that we become co-maintainers of the debian packages in question. They have their manpower problems too. I can hope for the best, that nudging package maintainers will do the trick, but planning for the worst, I think we have to "stay on course." We will always face the problem that one package or another may diverge from our expectations.

As for authentication, I consider it irresponsible in this day and age not to build it into our architecture from the get-go even if what we are limited in what we can implement today. Just my 2-cents worth.

@zultron I'm unclear about parts of your Buildbot synopsis:

• Temporarily acquire additional ARM builder to develop Buildbot config (@cdsteinkuehler: nudge, wink ;) --- could you be more specific here? I first took "builder" to mean a human being, to wit, Charles, but it could also mean a builder in the Buildbot sense. What "Buildbot config" development is needed? Do you mean solely updating the ARM-arch Docker container to accommodate Jessie or are there other issues?
• For now, [Jessie] slaves will continue to be separate VMs for each distro+arch+kernel combo --- I thought that's what all your slaves are now, except for BBB. If so, what would you change?

[zultron]

I agree that we should've been working with Debian maintainers. Also agree with these:

• we can stay on course with our own packages and hope for upstream.
• we can work with the people doing the debian packages in parallel to get those packages up to snuff.

So, I'll pick up the packages since we all feel it's important to have security, and on the assumption that we're going to start work on #204 soon, and the hope that we can start working with upstream packagers.

@RunningLight, by 'ARM builder' I mean the ARM board (Wandboard) that's doing the ARM builds. It's been flakey, needs constant attention, and after spending several hours just now replacing the rootfs sdcard (mostly repairing packages after a hang in the update), I don't think it's going to be any better. I'd like to remove it and do builds under qemu, but that may be too much work in the short-term (although I have resolved the Jessie-qemu problem).

As for test slaves, you're right, they're all VMs, except for BBB, and for now will stay that way. I have ideas for a different scheme that I probably shouldn't have mentioned.

[mhaberler]

@zultron - thanks, I really appreciate it!

[mhaberler]

with a bit of luck we might have the libzmq/czmq package issue solved for us. If I read this correctly, rsyslog uses zeromq plugins, and has a similar prerequisite issue like us . I'll inquire with the author if this has any upside for us.

[RunningLight]

@zultron, as for the ARM builder, I'm experimenting with my own Wandboard Quad, an Odroid-C1, and a CuBox-i4Pro. They all have Gigabit ethernet ports, so an nfs*-mounted rootfs should have decent benefit, and the Wandboard and the CuBox-i include a SATA port. I'd like to finish getting some performance numbers, but any or all can be contributed to the Buildbot whether as remote slave from here or local slave at your location.

*note added: or iSCSI

[mhaberler]

zmq* and debian - studying who is doing what here:

libzmq:

http://zeromq.org/distro:debian says a Alessandro Ghedini maintains debian libzmq3
however this repo has serious cobwebs, last change 2014-03-16 ie 14 months ago
Alessandro's debian QA page does not list any zmq-related packages any more:

https://packages.debian.org/jessie/libzmq3-dev says the maintainer is László Böszörményi, for stable this lists 4.0.5+dfsg-2 (John: I assume this is the one we could use modulo the missing curve support?)

this looks like a change in maintainers to me, I have no idea what the practices are but looks like László is the man to talk to - does it make sense approaching László and suggesting a jessie-backports or unstable libzmq+curve package (or maybe a different package - libzmq3-sodium; unsure)?

czmq:

http://zeromq.org/distro:debian says Alessandro Ghedini and Gergely Nagy manage this
Gergely Nagy's debian QA page does not list czmq:
Allesandro indicated he lost interest
the last released commit was from a different person, Arnaud Quette, looks like an experienced maintainer

http://anonscm.debian.org/cgit/collab-maint/czmq.git/ has last change in Nov 2014, but API version 2.2

pyzmq:

current debian maintainer: Julian Taylor, jessie lists 14.4.0-1
unsure if sodium-enabled
do we consider the alternative - installing via pypy?

[mhaberler]

re libwebsockets & debian: I've filed an issue: warmcat/libwebsockets#285

[cdsteinkuehler]

@zultron I've also got two quad-core ARM boards (CuBox and Wandboard) I'd be happy to setup as build slaves. Throw the buildbot configs online somewhere and I'll see about setting one up to test.

[zultron]

(The packaging plan above is now updated to reflect the fixed Debian Jessie zeromq3 packages and fixed qemu in the build scripts.)

[mhaberler]

wow, I'm really relieved that the zeromq situation is clearing up, modulo czmq. Thanks, John - great move on the debian bug report!

[mhaberler]

I'm confused wrt jessie install-from-source - is this now possible with the dovetail automata packages and the stock jessie package stream, or not yet?

I tried an x86 jessie install, mutated the website instructions /wheezy/jessie/ and got stuck here:

root@j1900:/home/mah# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  libgssglue1 libmpc2
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libzmq3
The following NEW packages will be installed:
  libzmq3
0 upgraded, 1 newly installed, 0 to remove and 1249 not upgraded.
54 not fully installed or removed.
Need to get 0 B/442 kB of archives.
After this operation, 725 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
(Reading database ... 139357 files and directories currently installed.)
Unpacking libzmq3:i386 (from .../libzmq3_4.0.5+dfsg-2+deb8u1_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libzmq3_4.0.5+dfsg-2+deb8u1_i386.deb (--unpack):
 trying to overwrite '/usr/lib/i386-linux-gnu/libzmq.so.3.1.0', which is also in package libzmq4:i386 4.0.4-2~1da~wheezy1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libzmq3_4.0.5+dfsg-2+deb8u1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

is the wheezy install as per website still what we recommend to do, or is it jessie and we have just not updated the website yet?

[zultron]

The Dovetail Automata Jessie packages are super stale tests (and were never announced for either testing or GA). Don't use them, and please remove libzmq4 if it's installed.

I'll have time to push out a new repo for testing in a few days, and will call for testing then. Thanks!

[RunningLight]

@zultron Is your deb-testing repo still worth testing our revised procedure on?

[RunningLight]

FYI, I just built MK in Jessie against your deb-testing repo ala the newly revised http://machinekit.io/docs/building-from-source page (changed as necessary for your repo and for jessie). I had no problems...until, that is, I tried to start the sim/axis-mm configuration from Axis and ran into tcl awfulness.

In the process of trying to sort tcl/tk 8.5 vs tcl/tk 8.6 I realize there's a disagreement between the informative message from src/configure and the output from src/configure --help which I'm posting in a new issue.

Starting with a fresh VM, I got to:

kreed@jessie-amd64-xfce-virgin:~/Desktop/machinekit$ debian/configure -p -t8.5
debian/control:  copied base template
debian/rules:  copied base template
debian/control:  added POSIX threads package
debian/rules:  enabled posix threads
debian/control:  Set tcl/tk build deps to version 8.5
debian/control:  add final Build-Depends: list

and then, at the end of src/configure

...
checking version of python libraries... python2.7
checking match between tk and Tkinter versions... TCL mismatch: 8.5 vs 8.6
configure: error: Python requires use of Tcl 8.6 and Tk 8.6.
Install this version and specify --with-tclConfig and --with-tkConfig if necessary

At this point, versions tcl8.5, tcl8.5-dev, tcl8.6, tk8.5, tk8.5-dev, and tk8.6 are all installed, but I don't seem to be able to find the right incantation to satisfy the configure gods at this point. Forgive my poor attention span (Washington Capitals are playing Game 7 against the New York Rangers as I write this!). Perhaps you've resolved this in email exchanges in the past but I can't find it.

[zultron]

@RunningLight, I don't have any Jessie repo online that I think might work.

Remove tcl8.5 and tk8.5. Apparently, m4/tcl.sh (a less-broken copy of the broken system-installed version from Jessie) searches for /usr/lib/tkConfig.sh before /usr/lib/tk8.6/tkConfig.sh, and the former may be a symlink to v. 8.5 if that version was installed after the tcl8.6 package.

[RunningLight]

@zultron Ok, I know you're working on the real deal so this is just for fun using deb-testing.

tcl8.5 and tk8.5 got in there because of my meddling. Sorry, I shouldn't have mentioned it. I had tried debian/configure -t8.5 only after my first build succeeded but I couldn't run the sim/axis-mm configuration.

Back to a virgin build on a virgin jessie-amd64 VM: It builds fine (modulo the pub-key business, which I know you'll take care of when you publicly release a jessie repo).

Invoking . ./scripts/rip-environment, then invoking machinekit, and selecting the sim/axis-mm configuration, I get to the expected Axis window. In it, I can toggle Emergency Stop, but when I then toggle Machine Power, homing buttons don't light up and I can't home axes.

Meanwhile, I see the following reported on the command line from which I invoked machinekit

kreed@jessie-amd64-xfce-virgin:~/Desktop/machinekit$ machinekit
MACHINEKIT - 0.1
Machine configuration directory is '/home/kreed/Desktop/machinekit/configs/sim/axis'
Machine configuration file is 'axis_mm.ini'
Starting Machinekit...
io started
halcmd loadusr io started
task pid=12646
emcTaskInit: using builtin interpreter
//...at this point I toggle Machine Power...
TCL error in asynchronous code:
wrong # args: should be ".toolbar.program_step cmd ?arg ...?"
    while executing
".toolbar.program_step"
    invoked from within
"if {$::last_interp_state != $::INTERP_IDLE || $::last_task_state != $::task_state} {
                set_mode_from_tab
            }"
    (procedure "update_state" line 44)
    invoked from within
"update_state"
    ("after" script)

Granted, I did not consider that this may be an artifact of some recent change to the repo and not the result of building on jessie. I'll try the same on wheezy tomorrow.

Oh, yeah, the Washington Capitals were eliminated from the Stanley Cup Playoffs by the New York Rangers tonight in the first Overtime period of Game 7.

[zultron]

(Updated issue: added 3.18.12 + Xenomai-3 and RTAI kernel candidate)

[zultron]

Ok, I've got a new deb-testing repo rsyncing right now for Jessie-x86. Same deal, url is http://deb.dovetail-automata.com/deb-testing/, packages are signed with a random key. 100% untested, aside from verifying that MK packages can be built. This is the package base I'm getting ready to support, so you're not wasting your time testing.

No armhf packages yet. Anyone know the status of RCN's Jessie-BBB images? Do they exist? Do they have kernels? Once I know what needs to be built, I'll do so.

[cdsteinkuehler]

On 5/17/2015 3:41 PM, John Morris wrote:

No armhf packages yet. Anyone know the status of RCN's
Jessie-BBB images? Do they exist?

Yes, for some time now.

Do they have kernels?

There's a 3.14 kernel with Xenomai patches (untested AFAIK), but it's
possible to continue running the known-good 3.8.13 as well.

Charles Steinkuehler
charles@steinkuehler.net

[zultron]

On 05/17/2015 04:40 PM, cdsteinkuehler wrote:

There's a 3.14 kernel with Xenomai patches (untested AFAIK), but it's
possible to continue running the known-good 3.8.13 as well.

Ok, so RCN is handling armhf-architecture Xenomai and kernel packages.
He picked up most other MK deps for Wheezy, too (ISTR he had trouble
with Cython, but we drop that dep for Jessie), so I'll assume he'll
continue carrying czmq and libwebsockets.

Wow, looks like I don't need to build any MK deps for armhf, just MK
itself when the Jessie Buildbot comes online.

Hey, sorry for being out of the loop.

[luminize]

to all,

Please have a look here: installing packages instructions where you can then choose wheezy or jessie at this section and let me know what's missing.

Specific instructions (if needed) for platforms (beaglboard X15, zed board and whatnot) can be added to the table.

when the linked document has been "done" then one should return to choosing an appropriate kernel. No differences here (AFAIK) so no need to differentiate between wheezy and jessie

your input would be highly appreciates, and PR's to the working branch are of course perfectly possible.

[ArcEye]

" assure the only package installed from sid is libczmq-dev BUT NOTHING ELSE"

The firmware-realtek and firmware-linux-nonfree packages are needed from sid at present for the newer RTL NICs, or you will missing firmware warnings whenever you do a kernel install or anything that touches update-initramfs

"Please have a look here: installing packages instructions where you can then choose wheezy or jessie at this section and let me know what's missing."

There is not yet an installation candidate as a package in Jessie for rt-preempt, so the kernel installation instructions will not work for Jessie, just Wheezy.

Self build is simple, but we don't want to get into kernel building tutorials.
Any news on Debian adopting one of the patches and producing a stock one?

The apt instructions for Jessie look fine.
It is not how I do it, I don't have tremendous faith in the apt preferences method and just have a sid entry which I uncomment, update, download what I need and comment out, and update again.
But your way is a lot easier to explain.

[luminize]

I've references the last 3 comments re. installation instructions here machinekit/machinekit-docs#38 (comment) so we can split this as a separate issue

[luminize]

@zultron @cdsteinkuehler (or whoever is interested) since Michael is pretty busy, travelling etc, could one of you review these instructions for installing for Jessie.
I've made an issue for that, and the thing I need reviewing is the apt-preferences part. After that I can verify with a pristine VM install.
I've put the pages it's about below.
https://github.com/luminize/machinekit-docs/blob/jessie-instructions/machinekit-documentation/getting-started/getting-started-platform.asciidoc
https://github.com/luminize/machinekit-docs/blob/jessie-instructions/machinekit-documentation/getting-started/installing-packages.asciidoc#configure-apt
https://github.com/luminize/machinekit-docs/blob/jessie-instructions/machinekit-documentation/getting-started/APT-packages-jessie.asciidoc
Thanks.

[ArcEye]

Looks bang on Bas :)

I would suggest however creating a file within /etc/apt/preferences.d
It is a cleaner solution and the reason for the additions is obvious from the file name.

I used your file contents in a file called /etc/apt/preferences.d/machinekit-jessie
After running update, I verified by deleting firmware-realtek, which I know has a more up to date version in sid.
apt-get install firmware-realtek installs the jessie non free archive version
apt-get install -t sid firmware-realtek installs the updated sid version

BTW you can update the rt-preempt kernel patches tested to include 4.1.7-rt8, I have just built it

regards

[mhaberler]

Von: Philippe Gerum rpm@xenomai.org
Betreff: [Xenomai] [RELEASE] Xenomai 3.0
Datum: 08. Oktober 2015 17:13:23 MESZ
An: "Xenomai@xenomai.org" Xenomai@xenomai.org

Eventually,

http://xenomai.org/downloads/xenomai/stable/latest/xenomai-3.0.tar.bz2

Thanks to everyone involved.

Philippe.

[luminize]

I'm building the rt-preempt kernel on a pristine jessie installation (my new J1900 motherboard) as per instructions from @ArcEye .
One comment i have on not having the kernel installable as with wheezy is that from a user friendly perspective is that the wheezy way was a lot nicer. Now it's not just "install" the kernel, but at least a 60min+ compiling time. Not very "lowering the barrier" imo.
Anyways, no troubles encountered with installing MK posix, nor with the pinned sid apt-preferences.
see: machinekit/machinekit-docs#40

[mhaberler]

I just tried manually dist-upgrading the 2015-12-27 BB SD image by Robert to jessie

while the process takes long and is not totally free of hicccups it resulted in a BB jessie install which installs and runs the current machinekit packages fine (only axis_mm tried)

I would think we're now good to actually create a jessie-based BB SD image - no stumbling blocks found!

(not recommended - I'm doing this manually for now because I'm trying to cook up a minimal SD image which has ROS-comm installed so we can experiment with the ROS/machinekit integration - see #689 )

[mhaberler]

a further datapoint:

I flashed a mmc with (lxqt-4gb) (BeagleBone Black/Green 4GB eMMC)

added

sudo bash
apt-get install linux-image-3.8.13-xenomai-r78 \
      linux-headers-3.8.13-xenomai-r78 \
      linux-firmware-image-3.8.13-xenomai-r78
bash sh -c \
    "echo 'deb http://deb.machinekit.io jessie main' > \
    /etc/apt/sources.list.d/machinekit.list; \
    apt-get update ; \
    apt-get install dovetail-automata-keyring"
apt-get update
apt-get install machinekit-posix  machinekit-xenomai  machinekit-dev 

and got a running Xenomai jessie platform

[zultron]

@mhaberler See #842 (comment); I believe @kinsamanka has Jessie packages in packagecloud.io and possibly deb.mah.priv.at. deb.da.com is deprecated.

[mhaberler]

Finally, a machinekit beaglebone jessie SD card:

I have prepared a jessie machinekit configuration for @RobertCNelson 's omage-image-builder here: https://github.com/mhaberler/omap-image-builder/commits/machinekit-jessie (plus tentative changes to publish on http://rcn-ee.us/rootfs/bb.org/testing/ - Robert - please review, not sure I hit the right file)

It has no more references to deb.dovetail-automata.com and uses the deb.machinekit.io repo.

The resulting img (4GB SD card) file is here: http://static.mah.priv.at/public/bone-debian-8.3-machinekit-armhf-2016-03-28-4gb.img.xz

works fine for me - feedback welcome!

Time for the ROS digerati to consider what should be added to this image

for the determined: commands to rebuild the image (needs arm host):

# fix MM-DD as needed:
# clone https://github.com/mhaberler/omap-image-builder, checkout branch machinekit-jessie 
`./RootStock-NG.sh -c machinekit-debian-jessie.conf
cd deploy/debian-8.3-machinekit-armhf-2016-MM-DD
./setup_sdcard.sh --img-4gb bone-debian-8.3-machinekit-armhf-2016-MM-DD --dtb beaglebone --bbb-old-bootloader-in-emmc --rootfs_label rootfs --hostname beaglebone --enable-systemd

(As a precursor for building the Altera DE0-Nano images, I wanted to start from a jessie SD image - should not be far from here).

[RobertCNelson]

@mhaberler and merged. ;)

[mhaberler]

stop the presses: this image is broken, HDMI does not work, fix in progess

and available: the new BB jessie image is now up at: https://rcn-ee.net/rootfs/bb.org/testing/2016-04-03/machinekit/bone-debian-8.4-machinekit-armhf-2016-04-03-4gb.img.xz

It'd be good to have some initial reports on go/no-go before we announce on the list

thanks, Robert!

[mhaberler]

A revised machinekit jessie image is up for testing at http://static.mah.priv.at/public/bb-jessie-test/ - works fine for me including HMDI

built from: https://github.com/mhaberler/omap-image-builder/commits/mk-jessie-pr

please test & report - thanks!

ps: we tried using the "4.4.6-bone-rt-r8" rt-preempt kernel for this release. It turned out that the performance difference is just enough to make it problematic on the BB. We therefore remained with 3.8.13-xenomai-r78.

[cdsteinkuehler]

On 4/8/2016 4:28 AM, Michael Haberler wrote:

A revised machinekit jessie image is up for testing at
http://static.mah.priv.at/public/bb-jessie-test/ - works fine for me including HMDI

built from: https://github.com/mhaberler/omap-image-builder/commits/mk-jessie-pr

please test & report - thanks!

Initial tests are significantly better than the first Jessie image I
tried. This one boots and gets to the normal desktop at least! :)

I can launch a real-machine configuration, but one strangeness is when
I start up machinekit (with my EggBot configuration), in addition to
the normal machinekit tasks, I get eight new systemd-udevd processes
in top that consume 10-11% of the CPU (so around 80% of the total
available). These run for about 17 seconds each (per top), so close
to two and a half minutes in real time (~8 processes X ~17 seconds
each = ~140 seconds). If I exit axis and re-launch, the systemd-udevd
process do not respawn, likely because whatever triggered them
(perhaps loading a cape?) has already happened. Can someone else see
if they get this behavior as well?

If needed, the EggBot config I tested can run without any hardware
other than the BBB itself:
https://github.com/cdsteinkuehler/machine-configs/tree/master/configs/EggBot.BeBoPr

Also, window dragging is very sluggish (especially so while the CPU is
pegged, but still cumbersome when the systemd process have gone away).
Is there a setting to not update the full window contents when moving
(like there is for resizing)? If so, we might want to turn that on by
default.

I'm on to see if I can get the image properly moving motors.

Charles Steinkuehler
charles@steinkuehler.net

[mhaberler]

systemd-udevd: reproduced, no cape, config Mendelmax-CRAMPS

here is a log of udevadm monitor : http://static.mah.priv.at/public/udev.log

could that be the pinmuxing? maybe we can trigger this somehow earlier like during boot

[mhaberler]

I'm only now noticing that between wheezy and jessie the beaglebone image switched to lxqt (we still use lxde)

I guess we're supposed to track that for minimum surprise?

[RobertCNelson]

So the lxde developers are behind lxqt..

At the time, i also thought, great since the sgx drivers work with qt, we'd finally have 3d support..

But now, we also need wayland for sgx .;)

Regards,

[mhaberler]

not sure I can read between the lines - clear commands please ;) lxde or lxqt?

I'm out of my depth deciding this - I dont track these projects

[cdsteinkuehler]

On 4/9/2016 12:54 PM, Michael Haberler wrote:

systemd-udevd: reproduced, no cape, config Mendelmax-CRAMPS

here is a log of |udevadm monitor| : http://static.mah.priv.at/public/udev.log

could that be the pinmuxing? maybe we can trigger this somehow earlier like
during boot

All of the stuff in your udev.log file happens pretty quickly, in less
than a second or so (from 256.8 seconds to 257.2), which matches the
behavior of the setup.sh script (exits pretty quickly) and behavior on
Wheezy. I don't know why the setupd_udevd processes are created, but
they chew up a whole lot of CPU for a while.

I suspect, however it has something to do with loading the cape, since
that is one of the big things that doesn't happen the second time
machinekit is launched. It's definitely worth looking into.

Charles Steinkuehler
charles@steinkuehler.net

[cdsteinkuehler]

On 4/9/2016 3:27 PM, Michael Haberler wrote:

I'm only now noticing that between wheezy and jessie the beaglebone image
switched to lxqt (we still use lxde)

I guess we're supposed to track that for minimum surprise?

I would try to match Robert's Jessie omap-builder configuration as
closely as possible. Least amount of surprise all the way around (we
can track Robert's updates easier, and any online docs for the Jessie
version of the BBB install will also apply to Machinekit meaning
hopefully less user confusion).

Charles Steinkuehler
charles@steinkuehler.net

[cdsteinkuehler]

On 4/9/2016 12:01 PM, Charles Steinkuehler wrote:

On 4/8/2016 4:28 AM, Michael Haberler wrote:

A revised machinekit jessie image is up for testing at
http://static.mah.priv.at/public/bb-jessie-test/ - works fine for me including HMDI

built from: https://github.com/mhaberler/omap-image-builder/commits/mk-jessie-pr

please test & report - thanks!

Initial tests are significantly better than the first Jessie image I
tried. This one boots and gets to the normal desktop at least! :)

I'm on to see if I can get the image properly moving motors.

Other than what I already reported, everything works well enough to
move motors!

https://youtu.be/XKCG_Vgj9_k

Charles Steinkuehler
charles@steinkuehler.net

[ArcEye]

Historical? Stretch is mainstream now, Xenomai3 was never followed.