"Open" is as "Open" Does: Parsing an announcement


Paw Prints: Writings of the maddog

Feb 23, 2015 GMT
Jon maddog Hall

One of the great things about studying compiler theory is that you learn a lot about avoiding ambiguity in language. Computer languages should not be ambiguous, since there is little time for the compiler or the computer to come back and ask “did you really mean that”?

Unfortunately this is not always the case with native languages, particularly English, as can be seen by the simple phrase:

“96Boards is the first open hardware specification....”

which appeared on the 96boards.org webpage. Immediately someone in the Open Hardware community pounced on this and declared that the first board that met the specification was not “Open” because the manufacturer had not published the Printed Circuit Board (PCB) specifications and the code (typically called “Gerbers”) for manufacturing the boards on a Surface Mount Technology (SMT) machine, the giant robot that places and solders the parts with extreme precision.

The manufacturer did publish the schematics of the board, and a lot of detailed data, but these two things were missing and (in the eyes of the community member) this was not “Open Hardware”.

Let us parse the sentence in question again. Not:

“96Boards is the first (open hardware) specification....”


“96Boards is the first open (hardware specification)....”

One of the unique parts of the ARM ecosystem is that many companies can take the ARM specifications and create Systems On a Chip (SoC)s which they (or one of their customers) will then mount on a board to sell to some customer(s). Without guidance, this means a large number of boards that need different cases, different power supplies, different layouts of bus structures, GPIO pins and variety of other things that make life needlessly difficult for the “maker” or the person building a prototype.

In addition there was a real need for a lower-priced ARM-64 board for educational use and development use. The high-end ARM-64 boards currently being manufactured were simply too expensive for most developers, educational institutions and hobbyists to afford.

Therefore the management of Linaro decided to devise two specifications for “minimal functionality” for both ARM-32 and ARM-64 SoCs (“96” is “32” plus “64”). One specification was for a “Consumer Edition” to have a targeted price below 100 US dollars and the other was to be an “Enterprise Edition” that was more for servers and other more powerful systems, with more memory and various other bells and whistles that the simpler “Consumer Edition” boards would not need, but with a price that is targeted for under 300 US dollars.

Obviously at these prices the boards are not trying to compete with systems like the Raspberry Pi, at least not on the ARM-64 level of system. The first board that came out, the HiKey board made by CircuitCo, did not even meet the price goal, coming in at 129 USD. On the other hand, if large numbers of boards are ordered and paid for, this price might drop due to manufacturing cost reductions. Time will tell.

The HiKey board is not a minimalistic board. It has an 8-core ARM-64 processor operating at 1.2 GHz, 3D graphic support via an ARM Mali 450-MP4 GPU, with WiFi and Bluetooth on the board, 4GB of eMMC flash and a reasonable number of USB 2.0 connectors.

Is it “Open Hardware” or “Open Specification”?

The management of Linaro made the specification as minimalistic as it could be to allow the greatest amount of flexibility for the SoC vendors to differentiate themselves to the different target audiences. They also made the specification gratis to license.

In the specification there are a lot of “shalls” where the implementer of the hardware has to provide things or meet certain criteria. There are also a lot of “mays” where the implementer can offer an enhancement.

A friend of mine, for example, pointed out that the HiKey board did not have a CAN bus, something needed for their project. The specification, while not requiring a CAN bus, does specifically point out CAN as a “possible option” for the SoC vendors making boards for that marketplace.

USB 2.0 is a minimal requirement, with USB 3.0 as a possible enhancement that some vendor might put on the board.

Likewise while the circuit diagram is required, the PCB layout and the “Gerbers” are not. This does not prevent the manufacturer of any board from providing these as part of their offering to the program. It also does not prevent the manufacturer from providing these pieces of information at end of manufacturing life of the current boards.

Why didn't the specification demand the PCB and Gerber information? Because a board manufacturer (perhaps using some other company’s SoC) may spend a lot of money in developing the board, getting the Gerbers correct, and setting up the SMT machine. They want to make some of that money back, and if they gave away that information a competitor could underprice them. By allowing board designers to keep this “manufacturing information” proprietary as an option, it encourages more vendors to create more layouts while still meeting the specification.
On the other hand, the SoC vendors want people to use their SoCs, so there is a strong possibility that an SoC vendor may design the board, give away the PCB and Gerber information and make their money through the sales of SoCs.

With an Open Specification, community groups could actually design a board that would have a greater acceptance because cases, power supplies, and software would be more likely to fit their hardware when produced.

So if you read the statement as “Open Specification”, the intent of Linaro of embracing the community of SoC manufacturers, board manufacturers and others to extend the specification to meet the needs of the future communities makes sense, even if every board is not considered to be “Open Hardware”.

I look forward to seeing how this “Open Specification” works out.

Note: In light of full disclosure, Jon “maddog” Hall is a consultant under contract to Linaro.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More