DE0-NANO-Soc Stretch image

There is now a Debian Stretch based Machinekit SD card image for the DE0-NANO-Soc.

It contains the new machinekit code which uses the new czmq4 API, so the RIP build is fully updateable from the main Machinekit repo.

The image is not extensively tested, but runs the mksocfpga sim fine, so should not have any issues with hardware.

The image is in compressed .xz format, expanding to 5GB approx.
It is heavier than previously, but does contain all the tools and libraries
necessary to rebuild Machinekit in situ and do some development.

There is a .bmap file with it to allow copying to card using bmaptool.

Files are located at:
http://deb.machinekit.io/uploads/de0-nano/debian-9.2-console-armhf-2017-10-29

You will need to write to at least a  8GB card and expand the fs
That will allow room for a swapfile, which is essential for rebuilding the RIP
using -j2, or else you will run out of memory compiling the C++ elements,
because g++ is particularly memory hungry in later versions.

Multicore merged into Machinekit

This is to advise users, that a major merge has occurred in the Machinekit repo.

The work christened 'multicore', has been finalised and tested for the last few months and as of 3rd Feb 2017 is now part of Machinekit.

What is multicore?
This talk from 2015 gives the full details.
https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo

What do you need to do?

With 3 particular exceptions, nothing at all, the aim has been to make it backwardly compatible,
so all your configs should work as before.

Please report any problems via the tracker at https://github.com/machinekit/machinekit/issues/1123

Once any teething problems are sorted, the capabilities and enhancements available within the code, will be rolled out, documented and advised for any users wishing to make use of them.

Exceptions

• The primary exception is for anyone using the DE0-NANO-Soc or Zynq as a Mesa 5i25 replacement

Improvements to the hm2_soc_ol driver now make use of a different string argument handling mechanism.

In practice, this simply means editing your hal file driver instantiation line from
newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME config=[HOSTMOT2](CONFIG)
to
newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME -- config=[HOSTMOT2](CONFIG)

The 2 dashes route the config string to the driver via a safer mechanism.
Any integer instanceparams such as 'debug=1' are passed as previously, so remain to the left side of the delimiter

If interested, this gives more details
https://github.com/machinekit/machinekit-multicore/issues/20

The binary SD card image for the DE0-NANO-Soc has been updated with a new
pull of Machinekit, containing Multicore available from
http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/

•  The multicore concept relies upon atomic operations in the C11++ standard and newer

These are supported sufficiently in gcc 4.7.2 and above in x86, which means the code will build under Wheezy with backports installed


Originally there were problems building for wheezy-armhf.
This was because all embedded toolchains have effectively deprecated gcc-4.7.

Builds had to be done on gcc-4.9 but ABI peculiarities meant that even linking with 4.9 left an unmet dependency that shouldn't have really been there.

Charles battled this for several days and has now sorted it and armhf packages for Wheezy are being built.

Users are however encouraged to upgrade from Wheezy, which is almost 'end of life' and no longer receiving new backports from Debian in any case.
All support will end in 2018.

• Something that will only affect users who have written their own C components which use ringbuffers.  (We have no idea if there are any out there.)
  

An API change sees
hal_ring_detach(char *name, ringbuffer_t *rb)
become
hal_ring_detach(ringbuffer_t *rb)

Beta Test volunteers wanted.

For a while there has been a parallel repo on github that incorporates the multicore capabilities developed by Michael Haberler and Mick Grant a couple of years ago into the main machinekit repo.
This talk from 2015 gives the full details.
https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo

Volunteers are wanted to do the initial backward compatibility testing.
95% of existing configurations should work unchanged.
A few specialised configs that use ring buffers and some other components will require minor API syntax changes, which can be advised on a case by case basis.

After testing for any problems in backward compatibility, it is intended to merge with the main machinekit repo.
Thereafter the features of multicore can be tested and rolled out, without any impact upon the majority of the user base, who can just carry on as before.

Testers need to be able to build and run RIP builds,
        (http://www.machinekit.io/docs/developing/developing/ )
set debugging levels
        ( http://www.machinekit.io/docs/config/ini_config/#sub:EMC-section  - DEBUG=7 is normally sufficient)
and provide comprehensive logs of any errors
        (copy of relevant section of /var/log/linuxcnc.log, copy of dmesg for segfaults etc. and stderr output to terminal)
plus access to complete configs that produce them.
        (preferably via a github repo)

Testing across as wide a range of computers and machines as possible is crucial.

The repo is here http://github.com/machinekit/machinekit-multicore.git

If you are able to test;
from a terminal session
clone it
        (git clone http://github.com/machinekit/machinekit-multicore.git)
build it locally
        (cd machinekit-multicore/src && autogen.sh && configure (insert any platform specific switches) && make -j$(nproc) && sudo make setuid)
then set the env
        ( cd ../ && . ./scripts/rip-environment )
run your existing configs.
         (machinekit   ---- then select your config)

Results, bugs queries etc should be addressed to < https://github.com/machinekit/machinekit-multicore/issues/10 >