Here’s an update on the past couple of eventful weeks. A plan of action (in development) has been started in a bugtracker, flights are booked to HK, we’re doing the t-shirts before we leave, we dealt with the DDR3 RAM upgrade and sent it off for prototyping estimates, we sorted out revision 1.4 of the Microdesktop layout, and we spent an enormous and disproportionate amount of time dealing with Wikipedia.
This is being maintained in a Bugseverywhere bugtracker because it plays nice with the rhombus-tech web site git source. Anyone is therefore welcome to both keep an eye on the project (including auditing the financial aspects, which is not something that’s normally done in a crowd-funding project), and to check out the git repository for themselves and submit changes to the tracker and the web site. In all honesty, the sheer number of tasks involved was a little overwhelming, so creating the bugtracker was a good way to make it less intimidating. Starting at the top-level allowed us to "drill-down" to more concrete items, the first of which to be tackled was the DDR3 RAM Upgrade (covered below). The addition of financial records was also considered prudent as a way to publicly keep track of how the crowd-sourced funds should be spent: there is a lot to get done, and some things may need to be prioritised or considered in creative ways.
It’s with some sadness that I noticed that nobody pledged for a pink t-shirt, so in true macho style (see "Unseen Academicals" by Terry Pratchett) I’ve made up for that by getting one for myself. There were over 50 t-shirts pledged, so the t-shirt company is very happy. We have however removed the t-shirts from the "pre-orders" because honestly they’re a bit expensive to get in small batches. We’ll revisit this later.
We booked about four weeks ago before we knew that the campaign would be a success! We really did have to take a risk, there, as the cost of the flights to HK would have been insane amounts at short notice, otherwise. One thing I haven’t mentioned before is that as I’m a UK Citizen who has been staying (with my family) at my sponsor’s home in Keene, NH. Whilst I’m on a 90-day visa waiver, my partner Marie and our daughter, Lilyana, have US passports. They could stay in the US indefinitely but that wouldn’t be a lot of fun being apart for six months (we tried that once: it wasn’t fun), so they’re coming with me. Fortunately, Marie speaks Mandarin, which won’t be much use in Hong Kong but will prove really handy when we visit Taiwan and Shenzen.
The other reason they’re coming with me is something else that I haven’t really discussed before: we don’t actually have what could be called "a home". Technically-speaking we would be termed "International Nomads". Shocking as this may be for some readers used to a "less exciting" lifestyle, the cost of maintaining an empty "home" - which when we were in Holland cost around $USD 1200 a month in rent - is not something that can be justified if it has to come out of the crowd-funding budget. We’ll work on that later, when it’s more appropriate, and there’s no longer a need to switch locations ad-hoc on a five to six month basis.
I initially posted about this on the arm-netbook list. Adding the extra address line went much more smoothly than anticipated. The video above shows the layers and the tracks, and explains what’s going on. Just for reference, in case you’ve never seen this stuff before, it’s just incredible. The tracks are 5 mil (5 thousandths of an inch!) wide, and the permitted distance (called "track-to-track clearance") is also set to 5 mil. That sets a benchmark for the factory so that they can use the right equipment to make the PCBs: the smaller the distances, the more accuracy needed, meaning that the equipment and the manufacturing process are much more expensive. Also, it’s six layers: Top, GND, Layer 3, Power, GND, Bottom. The two GND planes are put specially close to the TOP and BOTTOM layers, to reduce EM radiation. Only having six layers significantly keeps the cost down.
In the beginning of the video I point out that the distance between the centres of each of the A20’s BGA pads is only 0.65 millimetres. One of those tracks (only one, mind!) has to fit in between those with enough clearance either side to ensure that the copper doesn’t get "merged" into either of the BGA copper pads either side: that would be a short-circuit and the entire PCB and its components would need to be thrown out (it’s too expensive to debug and fix them!) Then you have vertical interconnect access (VIA) points which are mechanical or laser drilled holes between layers. Typically these go all the way through. 7 mil and below you really need to use laser-drilling, because mechanical drill bits that small just snap. If you want what’s called "Blind VIAs" (which you only use in desperation as they’re so expensive), the PCB layer manufacturing has to be stopped half-way through, you can only use a laser to do part-way-through drilling, then you continue the sandwiching process. It’s ridiculously expensive to do this for prototyping, it’s only typically used as a last resort on tiny mass-produced boards.
I have to say that it’s just incredible what humans have been able to achieve. The level of cooperative achievement is highlighted by a hilarious effort by Thomas Thwaites to build his own $4 toaster. He mentions in the video that he actually had to go back several hundred years to medieval times in order to find descriptions of iron ore smelting techniques, because we have advanced "so far ahead" and assumed that it’s okay for other countries to mass-produce of critical things like "steel" for us because it’s more "cost-effective" abroad. Thomas cites his talk as an example for designers to learn from; my feeling is that it has a much wider lesson, that we are placing ourselves and our way of life in quite a lot of peril by becoming critically dependent on International Trade.
The Revision 1.4 Micro-desktop PCB was also sorted out, with the addition of a huge number of extra VIAs around the D2A conversion for the VGA, as well as fixing the mistakes made with the USB connectors (reversed pin order). The other correction done compared to the previous revision was to put the VGA connector on the right way round! This is a surprisingly common mistake as it can be hard, in PCB design, to visually tell which side the pins of a connector are supposed to go.
I’m sitting here, holding my head in my hands, wondering where to begin with this. I’m not going to fill in too many links, because I actually don’t want people to be spending too much time on this: I’m documenting it more than anything, as a lesson to anyone else who may be considering editing Wikipedia. Someone very kindly started a wikipedia page for EOMA68 less than two weeks ago, and someone else mentioned it on the arm-netbook list. Now, bear in mind that I’ve (impartially) edited several highly technical topics on Wikipedia that were clearly lacking (or misleading). The reasons for the misleading information varied from the fact that they’re exceptionally unusual topics (for example the "Direct Drive Wheel Hub Electric Motor" page) to being overwhelmingly technically complex to understand (for example the Bourke Engine page, which requires a comprehensive understanding of maths, physics, chemistry, metallurgy, mechanical engineering and much more). You can probably tell where this is leading, and to the surprise of people on the list, I predicted that the EOMA68 page would not go well.
Straight away I had to begin editing the page to resolve some severely misleading statements. Calling on my experience in editing pages like LMDB, I used the Q-Seven page as a starting point and quickly turned it into something half-way decent. Several people usefully contributed; many others did not. In something that can only be described as a failure on my part to communicate to people what EOMA68 is really about, over a ten day period no less than six separate individuals put in misleading statements, which broke down into two main categories: "EOMA68 is a physical item that can be held in your hands" and the other was "EOMA68 is a CPU standard". If we have that many people misunderstanding what EOMA68 really is, we’ve got what can only be described as "A Breakdown In Communication".
So we began some really quite useful discussions on the list, to clarify the specification. This is about the only helpful thing that the Wikipedia page debacle has spawned. If you’re not sure what’s meant by that, you can take a look at the length of the EOMA68 Wikipedia page itself, then take the length of the "Talk" page, add it to the length of the "COI Noticeboard" page, then add that to the length of the "Scheduled for Deletion" page: divide those two to get a ratio of the amount of "information" to "discussion about information" (which at the time of writing must be somewhere close to 15% - *five times* more discussion than actual information) and you immediately get a handle for how desperately in trouble Wikipedia really is when it comes to these kinds of "new and complex technical" topics.
Where it started to go wrong was that one of the long-standing, experienced Editors (who is also a contributor to this campaign) noticed the page and decided to get involved and take it under their wing. In correcting some of the factually misleading information, they noticed that I was the author ("Guardian" is more accurate) of the EOMA68 Standard. Not knowing the history of the project as an open and libre project, they assumed that it was operating as a pure commercial business venture, and asked that i make a declaration of a "Conflict of Interest". I researched it, found that it applies to "roles" rather than to "people", made an assessment of the applicable "roles", and indicated my disagreement that there was in fact a conflict. Or, more specifically, I requested further examples (similar to those in the Wikipedia COI page) that I could compare against, in order to assess whether there was in fact a "conflict". Bear in mind that making a public statement that there exists a conflict when there is in fact no such conflict is a "false declaration". This didn’t go down well, the editor misunderstood it (hardly surprising when the way that these things are discussed in a massively non-linear fashion is hugely ad-hoc), requested a "COI Review" (which I said was inappropriate, as the COI Policy clearly didn’t cover this type of situation), and that’s really when the "pungent stuff hit the spinning air-extraction device".
During the "COI Review", instead of focussing on the actual review, several experienced Wikipedia Editors (including one with Administrative rights) began editing the page. Some of those edits were extremely valuable, including removing unverified sources (more on the consequences of this later), and generally cleaning it up according to sensible Wikipedia rules. Others worked on removing carefully-crafted technically-accurate statements that were still in the process of being verified for citations, and replaced them with utterly false, completely misleading statements that clearly indicated that these much more experienced Wikipedia Editors were utterly and hopelessly out of their depth on the technical aspects of what it was that they had decided to edit. The basis for carrying out this editing it is presumed was done on yet another misleading assumption that the entire EOMA68 venture is being done by a "paid employee" of a "corporation which doesn’t actually exist". If that were actually even remotely true I would have signed the COI Declaration myself!
In what can only be described as one of those "arghh nooo" moments, I reverted the rapid spate of factually false editing that had taken place pretty much overnight, preserved the accurate parts, going to a lot of trouble to hand-restore some of the intermediate edits, and then set about tracking down and explaining to each of the authors of the factually-misleading edits why this had been done. Imagine my surprise, then, at receiving a "Warning" - a single paragraph from a senior Wikipedia Administrator which itself had so many factually incorrect assumptions, every single one of which violates known Wikipedia Policies and Guidelines (and a stern notice that he had restored the false statements not just once but twice) that it’s too overwhelming to even begin to correct him. When each and every sentence in a paragraph is false, it’s genuinely overwhelmingly difficult to know where to even start.
Here’s where it gets interesting though, because not only was this "Administrator" pulling "length of service" rank (acting as a bully in other words), his seniority actually meant that he should know better. Instead, he’s completely technically out of his depth, has accused you - the backers and sponsors of this project - of being "sock puppets" (yes, really!), hasn’t checked any of the facts (that he reverted not once but twice), hasn’t done any research into the author, hasn’t done any research into the background of the project, has assumed "bad faith" in direct violation of Wikipedia’s own policies - the list goes on and on. But, more than that, by strictly applying Wikipedia "unverifiable sources" rules (despite there being 65 such news articles to choose from that have been found and publicly documented), he and other editors had stripped the article almost entirely of citations, thus providing a perfectly logical justifiable reason for scheduling the entire article for deletion!
Now, if this was any other article I would be laughing and citing it as an example of how Wikipedia is seriously failing, but in this case it’s had an adverse and detrimental effect on you, the backers of this project. There exists now a public record - an accusation by a Senior Wikipedia Administrator - that you are "sock puppets" with a "vested conflict of interest" in making statements on Wikipedia. Worse than that I have had to invest considerable time in ensuring that the Wikipedia article does not bring the EOMA68 project into disrepute, by being comprised of false and misleading statements. That’s several days worth of potential delay to fulfilling the promises that I’ve made to you. So for that and many other reasons which I’ve documented on the page, I’m supporting the "Deletion" of the Wikipedia Page. The thing is: what people actually collaboratively developed (before the COI-inspired editing began) was actually really good, so that has been preserved on the "talk" page of the elinux.org EOMA68 Specification. But what’s up there now is just… utterly misleading.
So I apologise for having felt compelled to spend your time on this. You’ve backed this project, and instead of getting on with that I’ve had to spend time dealing with people violating Wikipedia’s own guidelines - people who should know better. I’m not going to do that any more. I’ve put a warning right at the top of the EOMA68 specification on elinux.org: I’ll take it down when the Wikipedia page is deleted. In the meantime, if anybody would like to actually work on a technically accurate and informative article about EOMA68, you’re more than welcome to help out: join the arm-netbook mailing list, where it’s easy to coordinate efforts, create an account on elinux.org, and we’ll move the well-edited text to its own page.
Anyway, apologies: I have to go. We’re leaving in two days, we’ve a moving van that’s just arrived (six weeks late) containing all our belongings from Holland, we still have to pack and I need some of the items from the 25 boxes that have just arrived.
Watch the interview on YouTube
These guys were hilarious and wanted to do an interview with Joshua (of Crowd Supply) and the "people behind EOMA68". After watching the briefest part of one of their shows I got the feeling that "hamming it up" would be ok, so without telling Joshua that I was going to be doing that, we went ahead. It was a lot of fun, they loved it. Joshua: thank you for keeping a straight face throughout.