Linaro Launches an Open-Source Spec For ARM SBCs

DeviceGuru writes: Not content to just standardize ARM-based Linux and Android software, Linaro has just launched 96Boards, an open-source spec for ARM-based single board computers. Along with the spec's rollout, Linaro also announced a $129 HiKey SBC based on a HiSilicon 64-bit, octa-core Kirin 620 SoC, and compatible with the 96Boards Consumer Edition (CE) spec's 85 x 54mm 'standard' form factor option. The 96Boards initiative plans to offer a series of specs for small-footprint 32- and 64-bit Cortex-A boards, including an Enterprise Edition (EE) of its spec in Q2.

Comments

Does this give us anything Raspberry Pi didn't

[Chrisq]

Does this give us anything Raspberry Pi didn't? Just wondering, even if not more choice of open boards is obviously better

Re:Does this give us anything Raspberry Pi didn't

[Halo1]

This is the first low-cost aarch64 silicon on the market. There are piles of piles of developers that will get it just for porting their software for arm64

This. Just logged in because I wanted to say exactly the same. Until now, afaik the cheapest option was actually a jailbroken iPad Mini 2 (and you obviously can't run Linux on that).

options means consumer confusion

[lkcl]

i'm the author of the EOMA standards, including EOMA68, so i have spent something like two years developing and refining hardware standards that will not confuse end-users. http://elinux.org/Embedded_Ope...

the 1.0 (i.e. final and absolute unchangeable) version of the 96boards "consumer" standard from 96boards will be going on the list of alternative standards, as, sadly, another example of a standard that will result in end-user confusion, annoyance, product returns and, ultimately, failure.

the reason is incredibly simple: an end-user standard MUST NOT have optional interfaces. i do not understand why people developing standards do not understand this. page 7 of the 27 page v1.0 specification states, clearly, "1 OR 2 MIPI CSI-2 ports MAY be provided on the expansion bus interface" and "From 1-2 lanes MAY be implemented on the CSI1 port interface". now whilst the latter is absolutely fine (because negotiation takes place at the hardware-level, so either host or client will correctly negotiate 1 or 2 lanes), the former most definitely is NOT.

let's think it through. here's a simple scenario. an end-user buys a 2-lane box, and a lot of expensive camera equipment. they then find that the box is too slow, and need to upgrade. so they go out and buy another box, and, BY MISTAKE, when they get it home, they discover that they only bought a 1-lane box. as there is NOTHING WRONG with it, they may NOT return it as faulty under warranty.

additional confusion results from page 8, over the options that the 3rd USB port MAY be a USB-OTG port. again, people will buy a system and a set of peripherals, relying on the USB-OTG capabilities... and then upgrade at a later date and make the mistake of not knowing what the hell is going on until it's too late. they investigate further and find "whoops, i bought the wrong system: this one doesn't have USB-OTG power damnit".

DC power requirements, page 8: again, more confusion when upgrading.

2nd (optional) UART, page 9: more confusion results.

a summary is given on page 12, where the moment you see the word "optional", count them. that becomes a permutation of the number of possible things that an end-user has to check when first selecting and then double-checking on upgrading the device. i count (if you include the USB confusion and the power options) at least *SEVEN* possible "options", giving... someone else can do the math here, it's what... over a hundred different permutations at least.

and then, when you get to the end of page 12 only then do you discover that the expansion board connections may be used as GPIO!

*sigh* i have to say that this really does not look like a very well-thought-out standard, at all.