In my previous post Parallella Problems – Initial Investigations  I detailed the problems I was having with the 4 Parallella boards  in my mini-cluster and what I had done to investigate them. Since then I have been continuing my investigations and it looks like I might have found a reason and solution to the more serious problem suffered by the board that suffers complete system lock ups when running Epiphany chip  tests and examples.
In my last two posts Building a Parallella Mini-Cluster  and Bringing Up a Parallella Mini-Cluster – Trials and Tribulations  I described constructing a small cluster of 4 Parallella boards  into a case with power and cooling and initial steps at getting the cluster up and running. I finished at the point where I knew of the following problems:
My previous post Building a Parallella Mini-Cluster  dealt with physically building the cluster and ended at the point it could be switched on and off. The next stage is bringing the cluster up to a stable and usable state, and I am sorry to report that it has not been a trouble free ride and tracking down the problems is ongoing as of mid-July 2014.
One thing I should mention is that before turning on the power for the first time I installed the provided heat sinks on the Zynq FPGA chips.
In early May 2014 I finally received from Adapteva  my Parallella Kickstarter project  mini-cluster reward of 4 Parallella boards plus network switch, power adapters, cables etc. The reward was originally supposed to be delivered in May 2013 but suffered many delays and setbacks, as documented on the Parallella website  and forums .
I have been adding support for peripheral types to my Raspberry Pi C++ peripherals library and as a result have been reading the BCM2835 ARM Peripherals data sheet document rather closely as well as the document’s errata page on eLinux. I, like others, have been bumping into documentation errors – and even added one to the eLinux list errata.
I have posted some example code on GitHub showing the Shared Immutable, Exclusive Setup ideas discussed in the Comments on comments to Herb Sutter's updated GotW #6b solution (part 2) blog post to demonstrate the ideas:
Previously I wondered, from musing when reading Herb Sutter’s updated Guru of the Week 6b article, how one might – in C++11 – enforce a concurrent usage pattern in which an object can only be modified after creation by the creating thread until all modifications are done when the object becomes immutable and concurrently accessible. Concurrent access before an object becomes immutable is considered an error as are attempts to modify an object that is immutable.