Anders, thanks for the detailed report; just let me add some notes inline
Am 02.12.2012 um 19:58 schrieb Anders Wallin: > With some help from Michael I have now got this installed & running. > If anyone else is interested, here is a steb-by-step description of what I > did, roughly: > > Download ubuntu-12.04.1-desktop-i386.iso and write to USB-stick. Note that > the 64-bit version causes problems later, and the default > startup-disk-creator did not work for me (I used unetbootin) > > Download debs from Michael: > http://static.mah.priv.at/public/xenomai-debs<http://static.mah.priv.at/public/xenomai-debs/libxenomai-dev_2.6.1_i386.deb> > > first install the xenomai kernel > sudo dpkg -i linux-headers-3.2.21-xenomai+_0.1_i386.deb > sudo dpkg -i linux-image-3.2.21-xenomai+_0.1_i386.deb > sudo update-initramfs -c -k 3.2.21-xenomai+ (I am not sure this is > required or done by dpkg) at least the 10.04 dpkg fails to do that for me, maybe this is some option I am missing; but dpkg and friends are in such deplorable shape in 10.04 that I prefer not to look into the issue - they are too old to even compile 3.x kernels. > sudo update-grub > > reboot. uname -r now says "3.2.21-xenomai+" > > Now install the rest of xenomai: > sudo dpkg -i libxenomai1_2.6.1_i386.deb > sudo dpkg -i libxenomai-dev_2.6.1_i386.deb > sudo dpkg -i xenomai-runtime_2.6.1_i386.deb > > Now we need to get git and other dependencies: > sudo apt-get install synaptic > sudo apt-get install git > > By looking at the output of ./configure I installed the following packages. > I don't know if this set is minimal or optimal, but at least configure and > the build seems to complete. Packages: build-essential autoconf libpth-dev > libglib2.0-dev libgtk2.0-dev tcl-dev tk-dev bwidget libreadline-dev > python-tk python-dev libgl1-mesa-dev libglu1-mesa-dev libxmu-dev I would think you can achieve this a tad easier by: $ cd debian $ ./configure sim successfully configured for 'sim-Ubuntu-12.04'-'sim'.. $ cd .. $ dpkg-checkbuilddeps dpkg-checkbuilddeps: Unmet build dependencies: dvipng texlive-extra-utils texlive-latex-recommended texlive-fonts-recommended ghostscript imagemagick texlive-lang-french texlive-lang-german texlive-lang-spanish texlive-lang-polish texlive-font-utils asciidoc (>= 8.5) source-highlight dblatex (>= 0.2.12) xsltproc groff libgnomeprintui2.2-dev texlive-lang-cyrillic note the 'configure sim' part is just to make the debian directory happy, this is not adapted yet to be in sync with src/configure (and I would appreciate help on that) (those missing dependencies above I can live with until I --enable-build-documentation) > > get Michaels rtos version of linuxcnc and checkout the rtos-integration > branch > git clone git://git.mah.priv.at/emc2-dev emc2-dev > cd emc2-dev > git branch --track rtos origin/rtos-integration-preview1 > git checkout rtos > > configure for xenomai and run-in-place > cd src > ./autogen.sh > ./configure --with-threads=xenomai-user --enable-run-in-place > make > sudo make setuid > cd.. > . ./scripts/rip-environment > latency-test > yay! it works. I get a little high numbers (30us) without any tweaking. > With HT disabled and isolcpus (exists on xenomai?) I hope things will > improve. you hit the right options - just a note on current configure options: --enable-run-in-place is the default so not needed --with-threads=posix,rtai,rt-preempt-user,rt-preempt-kernel,xenomai-user,xenomai-kernel of which currently only rtai, xenomai-user, rt-preempt-user and maybe xenomai-kernel make sense (the latter will be deprecated) --with-kernel=/boot/config-<some kernel version> # enable a cross build for some other kernel --with-platform=PC,raspberry,beaglebone # PC being default --enable-drivers # will enable drivers even on --with-threads=posix; this really applies only to hal_parport and hal_gpio (pi) currently --enable-portable-parport # this is for the rare case where the architecture doesnt support inb/outb (ie non-x86) but does have ppdev ioctl suport for parports --enable-gcc-atomic-ops # fyi only, not needed as it is set implicitly for the non-x86 builds - forces disabling of the inline assembly in src/rtapi/rtappi_bitops.h and replaces it by gcc builtin operations --enable-simulator # nowadays is just a different way of saying --with-threads=posix > FWIW I would consider this rtos work more important for a linuxcnc 2.6 > release than the redis work that just seems to break the build and cause > problems on 12.04/12.10. I think that comparison is as concludent as saying: 'sunlight is more important than a full wine cellar';) one has really absolutely nothing to do with the other, so I dont see your point. I am aware there is no using code for redis yet; this was discussed at length before making the step, and there is a substantial patch in the queue pending the reviewer finishing his part. And btw, the redis code is not in this branch to start with because it is forked off 2.5, not master, and for a reason. If you do have a detailed build report which helps work out issues, or a patch, that would be most welcome, I am moving on a bit too many fronts anyway. > Next I hope to work on some stand-alone HAL logic together with gscreen/GTK > gui's. I understand the PCI drivers for mesa cards etc are still missing > but are being worked on? Yes, that is the works - it is clear how that will be done, but it's just 'mere work left', and I do not expect any surprises; to the contrary I think that moving hardware drivers into user space will make it substantially easier to add and debug drivers - you can use gdb like on any other user code and an error shouldnt bring down the kernel as easily. It already has shown to reduce that guru factor with the hal_parport and hal_gpio drivers. John Morris has put in substantial effort into rearranging RTAPI to support the somewhat ad-hack initial changes we got from here and there and bring them into a coherent framework, and Charles Steinkuehler is working on the PCI support. RTAI: despite that work, we've taken pains not to introduce any code changes into the RTAI kernel support, and we would be very grateful for any build/run reports of building that branch with '--with-threads=rtai'. It will be needed as this work approaches 'merge candidate' status. -- As I mentioned, this branch is forked off 2.5 because I felt the urgency of bringing in new RT OS support be the driving factor. As this code matures, we will have to decide whether to merge it into 2.5/2.5something, or into master. While I understand the 'please do not rock the boat' argument which has already been raised, I strongly suggest that we take the - IMO very well manageable - risk of merging it into 2.5 to bring in new options as early as possible, and to curb the danger of early deprecation of the current 2.5/RTAI combination branch which is clearly on the table. LinuxCNC has been out on the 'x86/PC architecture only' limb for so long that not moving on this front is becoming a quite risky (non-)decision. It would help if folks made up their minds on this question ahead of time. - Michael > > Anders > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > DESIGN Expert tips on starting your parallel project right. > http://goparallel.sourceforge.net/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
