Slashdot Mirror


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.

5 of 35 comments (clear)

  1. Re:Does this give us anything Raspberry Pi didn't by Halo1 · · Score: 4, Interesting

    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).

    --
    Donate free food here
  2. It's an attempt at a PC-like standard for ARM by Morgaine · · Score: 2

    Does this give us anything Raspberry Pi didn't?

    If successful, it would give the ARM world a PC-like, vendor-neutral standard architecture, and so it would counteract the horrible balkanization of ARM communities by every manufacturer's boards being different.

    Even if this doesn't succeed, standardization is a very worthwhile goal for ARM (just as it was for x86 PCs), and it's quite important that a broadly funded organization has recognized the need. It will also usher in the days of ARM64, at last.

    There is one glaring omission in the spec though, the lack of Ethernet. No Ethernet means extremely limited sales outside of mobile, and at the HiKey's price of $129 it has to be gigabit Ethernet at that.

    --
    "The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
  3. Re:Does this give us anything Raspberry Pi didn't by Gravis+Zero · · Score: 2

    if nothing else, it provides a ARMv8 (64bit and 8 cores) dev board that doesn't cost multiple internal organs.

    --
    Anons need not reply. Questions end with a question mark.
  4. Obligatory XKCD by YuppieScum · · Score: 2
    --
    This sig left unintentionally blank.
  5. options means consumer confusion by lkcl · · Score: 3, Interesting

    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.