Arduino: now a Single Board Computer!

I like the term "bare metal microcontroller" to denote the processors on Arduino AVR and ARM Cortex-M class boards.  These contrast strongly with those boards which are based on "application processors" that have an MMU and therefore run full operating systems (mostly Linux) and so their applications execute as user-mode processes in virtual memory --- definitely not "bare metal".

It provides a clear distinction and so keeps discussions from attempting to compare apples with orangutans.

PS. It's appalling to see makezine.com make this elementary error though.

PPS.  The source of the error seems to be Intel themselves!

Intel writes (in the FAQ):

 

Q: Can I run Linux on Intel Galileo?

 

A: Yes. Intel Galileo runs Linux* out of the box. It comes in two flavors; the default is a small Linux. If you add an SD card to your kit, you can add a more fully-featured Linux. Refer to the Intel Galileo Getting Started Guide and Intel Quark SoC X1000 IoT Development Kit Software GSG.

I'm still figuring out exactly what this means, but at best it's going to be something like the old uClinux, which was pretty horrible at best.  After all there is no MMU in Quark to support the normal Linux kernel --- see the Quark datasheet.  (uClinux is effectively EOL now owing to MMUs having become so ubiquitous.)

PPPS.  The Galileo Getting Started Guide refers only to Linux support on the host side, not on the board.

PPPPS. Oh dear.  If you zoom into the image showing what they load from uSD card, it boots into:

Poky 9.0 (Yocto Project 1.4 Reference Distro) 1.4.1 clanton /dev/ttyS1

I've got a very bad feeling about this.  I thought the days of MMU-less "Linux" derivatives were over.

===

IMPORTANT ADDENDUM:  Quark does have an MMU, it's just not mentioned in the SoC Datasheet.  See this post.

Intel writes (in the FAQ):

 

Q: Can I run Linux on Intel Galileo?

 

A: Yes. Intel Galileo runs Linux* out of the box. It comes in two flavors; the default is a small Linux. If you add an SD card to your kit, you can add a more fully-featured Linux. Refer to the Intel Galileo Getting Started Guide and Intel Quark SoC X1000 IoT Development Kit Software GSG.

Does this imply that your choices for boot device are either onboard or SD card, but not USB or network?

selsinork wrote:

 

Can RPi, BBB, etc. boot from network or USB ?

Pi can't boot from network or USB because booting is done by the utterly closed VideoCore.  However, BBB can boot from anywhere, in principle, since U-boot runs on the ARM which is free to configure any devices it wants prior to finding and loading a kernel.  And the 2GB flash means that U-boot always has somewhere to run and keep its configs while sorting out from where to get a kernel.

This doesn't mean it's easy if the boot support that one wants doesn't exist yet, but in the open source community that tends to get rectified pretty quick.

Ultimately though, anything can boot from anywhere (with the exception of secure boot systems), since whatever it is that loads the Linux kernel can load a generic boot loader instead.  Even poor ol' Pi has that possibility.

selsinork wrote:

 

Part of the spec for miniPCIe is that it has a usb port wired to the connector as well as stuff like led and sim card connections. In some circumstances various parts are optional and I've seen at least one board that only provides usb to the connector.

 

There seems to have been some thought put into the miniPCIe physical connector to allow it to be used for a wide range of purposes, traditional wifi, cellular modem with remote SIM, usb bluetooth, all in the same form factor, possibly on separate cards, or even combined onto one.

 

One of my first thoughts from the wording was that the connector on the Galileo would be a usb only version and therefore limited in scope. However there's a block diagram in one of the docs that shows both PCIe x1 and USB2.0 going to the connector.

I'm glad to hear that the Finnegan board (I can't bear to call a Quark-based Irish board "Galileo") has PCIe.  I have a major FPGA design that's currently using 32-bit PCI and it's getting harder to find processors with PCI.  (I don't need the bandwidth -- I just need the connectivity.)  At some point I may need to change the PCI interfaces to PCIe -- once I can get a cheap enough FPGA that has built-in PCIe.  So Finnegan would be a cheap way to exercise the PCI interface -- with lots of fun bare-metal programming

It's curious how ARM is taking over the world without really having a coordinated strategy for high-bandwidth I/O.  Maybe Galileo will give them a bit of a push in that direction, although a single PCIe connector isn't really pushing anything when the board lacks both SATA and gigabit Ethernet and so needs at least two just to be on par.

It's worth pointing out that the Ethernet MAC on the Quark is only 10/100Mbps, so this chip has limited life expectancy in a world where network speeds and expectations are heading rapidly skywards.  TI's low-cost AM3359 device has two gigabit MACs and has been around for a long time now, so Intel has some way to go to stay in touch with the field in this area.

Morgaine Dinova wrote:

 

It's curious how ARM is taking over the world without really having a coordinated strategy for high-bandwidth I/O.  Maybe Galileo will give them a bit of a push in that direction, although a single PCIe connector isn't really pushing anything when the board lacks both SATA and gigabit Ethernet and so needs at least two just to be on par.

 

It's worth pointing out that the Ethernet MAC on the Quark is only 10/100Mbps, so this chip has limited life expectancy in a world where network speeds and expectations are heading rapidly skywards.  TI's low-cost AM3359 device has two gigabit MACs and has been around for a long time now, so Intel has some way to go to stay in touch with the field in this area.

The vast majority of ARM applications are cell/smart phones and tablets.  Both are limited to wireless networking speeds, so 100 Mb/s is adequate.  Even a wired media center is limited by the bandwidth into your home.  ARM processors with high-performance video are usually integrated SoCs, so who needs PCIe if you have 64-bit on-chip buses?  Also, you usually don't have a hard drive in your phone or tablet, so you don't need SATA.

In contrast, AM3359 is designed for high-performance industrial networking, so GBE is definitely useful.

Morgaine Dinova wrote:

 

Pi can't boot from network or USB because booting is done by the utterly closed VideoCore.  However, BBB can boot from anywhere, in principle, since U-boot runs on the ARM which is free to configure any devices it wants prior to finding and loading a kernel.

http://elinux.org/RPi_U-Boot

So let me rephrase the question, where can the BBB, SL, Cubieboard, RPi etc boot from without loading u-boot first?   Generally I find they're all pretty limited, mostly to something out of SPI or NAND flash, or a FAT partition on SD card.

Ultimately though, anything can boot from anywhere (with the exception of secure boot systems), since whatever it is that loads the Linux kernel can load a generic boot loader instead.  Even poor ol' Pi has that possibility.

Precisely, so if Galileo has the possibility to boot u-boot (or similar) from SPI then it's exactly as capable as any other embedded device using u-boot.

Morgaine Dinova wrote:

although a single PCIe connector

It seems that the SoC has the capacity for two PCIe lanes, default configured as 2 PCIe x1.  The miniPCIe connector theoretically has the capability for two lanes, but whether anything actually implements that is a different matter. Regardless, without a second connector on the board it's probably irrelevant.

It's probably worth pointing out that things like this exist: http://linitx.com/product/mini-pcie-to-dual-pci-13cm-cable/13202

So while you'll always be limited to whatever PCIe bandwidth is available, there is the possibility of more slots by way of a bridge chip. Not really sure what the point would be though, at 400MHz the cpu is probably too weak to take advantage.

John Beetem wrote:

The vast majority of ARM applications are cell/smart phones and tablets.  Both are limited to wireless networking speeds, so 100 Mb/s is adequate.  Even a wired media center is limited by the bandwidth into your home. 

Wireless networking can already exceed 100Mb/s, cheap consumer internet connections are already reaching 100Mb/s here and set to exceed it soon.  With deep enough pockets I could have 10Gb/s to my home in a few months time (the few months being mostly lead time to run the fibre).

The only thing that's realitively certain is that both bandwidth requirements and availibility will continue to increase over time and that devices that don't keep up are destined to die.

On the other hand, taking into account use cases and target price range, 100Mb/s was probably the right choice. There's bound to be a new spin of the SoC along soon enough that'll include updated capabilities.

John Beetem wrote:

 

At some point I may need to change the PCI interfaces to PCIe -- once I can get a cheap enough FPGA that has built-in PCIe.

At least one way to extend the lifetime of the design would be a bridge chip:

http://www.plxtech.com/products/expresslane/pex8112

I'm sure fpga's with PCIe will be along sooner or later too.

selsinork wrote:

 

There's bound to be a new spin of the SoC along soon enough that'll include updated capabilities.

Yep, extremely likely.  I can't believe that Intel want their name associated with low-performance embedded only.

Today's embedded ARM SoCs are having their cake and eating it too, combining high performance with low power consumption, and the level of integration is extreme.  And as if that weren't enough, the killer problem for Intel is one that they have not faced before:  very low prices.  Catch-up with ARM is going to be hard.

Morgaine Dinova wrote:

 

And as if that weren't enough, the killer problem for Intel is one that they have not faced before:  very low prices.  Catch-up with ARM is going to be hard.

The thing about having Intel as the opposition is that it's like tip-toe around the slumbering beast, do you really want to wake it up and have it focus it's attention on you ?

They obviously have some strategic/political reasons for pushing x86 as far as they can, but you can't really blame them when it's historically been very lucrative.

However I wouldn't bet against them if they ever decided to truly focus on the Arm segment without dragging along the x86 baggage.

Morgaine Dinova wrote:

 

And as if that weren't enough, the killer problem for Intel is one that they have not faced before:  very low prices.  Catch-up with ARM is going to be hard.

The thing about having Intel as the opposition is that it's like tip-toe around the slumbering beast, do you really want to wake it up and have it focus it's attention on you ?

They obviously have some strategic/political reasons for pushing x86 as far as they can, but you can't really blame them when it's historically been very lucrative.

However I wouldn't bet against them if they ever decided to truly focus on the Arm segment without dragging along the x86 baggage.