If one wants to build a system with 12.04/Xenomai/Linuxcnc to use today are the instructions on the wiki still the best option or is there something better/more current to use? -Tom
On Jul 12, 2013, at 9:59 AM, Michael Haberler <[email protected]> wrote: > > I understand that folks are waiting for 'the RTOS gang' to produce something > tangible, and in Wichita we asked for some leeway for wrapping up the work. > (I said two weeks, meaning 'after I'm home' and that still might hold for a > rawhide cut) > > This is where we are: > > Both John and me work intensively on the merge candidate branch, which will > be based on Johns github repo branch.*) > > At the same time Charles has been working on his BeagleBone-related themes > (authoritative place to look: http://bb-lcnc.blogspot.co.at/), and there is > also some rather interesting work in the pipe by Ian: support for an BB FPGA > cape. > > Thankfully, the RTOS and BB work directions are largely disjoint and can > proceed in parallel without much coordination. > > The current focus of Johns and my work is: > > - until recent, mostly the build system, which John has worked on, and where > he has done incredible amounts of work > - currently non-RIP installs are still work in progress > - it has turned out that some aspects of configure-time constants need to be > mutated into 'depending on flavor selected at runtime' > - I have found John's build system work exceptionally stable despite all the > changes under the hood (by default, in one go a build for every applicable > thread system installed on the build machine will be created, not just a > single one as with the rtos-integration-preview* branches) **) > - John already has taken some steps towards creating a build which will will > be amenable to Debian and other distro's integration ***) > - I looked into realtime fault handling - which was not production quality - > towards making this more intelligent than just logging the fact it happened; > thanks to separation of policy and mechanism in RTAPI there is now a way to > customize RT fault reaction through a HAL component, meaning reaction to RT > faults is now an issue of dealing with stock HAL and RTAPI API's, not with > RTAPI internals - you dont like it: well then change it, comp is your friend. > For instance, creating an estop signal if RT faults happen. ****) > - I have made a sweeping change this week in the way startup sequencing of > the realtime environment works; I justify this change with 'it's going to be > all the same for all flavors and much easier to understand and debug'; and it > is primarily about reducing the number of moving parts (note the 'change' is > minimally new code, but lots of deleted code which is by definition bugfree > and easy to support ;) > > We still believe 'a merge candidate' is viable well within July. > > As for documentation, the next topic is to write a 'Unified Build/Multiple > RTOS Principles of Operations' manual fragment, which outlines the basic > setup and flows, and the machinery to build for, and support a number of > different RTOS platforms by runtime choice. This should be helpful to folks > helping with a code review. > > I routinely build on the BeagleBone and have no surprises to report, meaning > this will be available as a build option as soon as we declare victory. Since > the last remnants of inline assembly code are gone, the > '--with-platform=<foo>' option really only stays to determine the set of > drivers to build. > > Re the rtos-master-v0 branch in my repo: this represents the sum of work > pre-unified build as I have announced my mail to the devlist of May 28 > 'releases & branching'. I have on purpose not announced this branch for > public consumption, but some of that has happened nevertheless (my fault, I > need a hard-to-stalk secondary repo ;). There is a high chance this branch > (which is a forward merge of existing work) will be thrown away and redone > based on the ub* branch. You heard it clear and loud: do not rely on this > branch in any way, and do not expect it to be an ancestor of a merge > candidate. > > We currently have no automated way to build BB (and other) kernels. I have > gotten in touch with Robert Nelson (debian/bb) and Koen Koi (angstrom/bb) to > get something in place and willingness to cooperate is there; I would love to > be able to hand over this effort to another caretaker (all these builds > happen on my server manually right now, and that server still will be > available, but I'd be grateful for somebody else taking over) > > for 'the gang' ;) > > - Michael > > -- > *) to give an indication what 'intensively' translates into: these are my > additions alone to John's ub branch since monday this week - 35 or so > commits: > http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/ub-reorder-startup-cleaned > > > **) this will require build support downstream to have build machines with > all applicable kernels and userland support packages installed, even if > running regression tests of course will apply only to the flavors supported > by the running kernel > > ***) while it is true this isnt absolutely essential for a merge candidate, > we both have found out that once you are working intensively on a theme (and > build support is a complex one) it makes sense to keep going; the loss of > context and re-learning once you start after weeks or months is considerable. > > ****) > see http://tinyurl.com/pcx7x5v for an example fault handling comp > see http://tinyurl.com/or4xzw7 for a usage example > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
