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.

I have no problem with this use of Single-Board Computer.  The earliest SBCs had very simple processors like Intel 8080 or MOS Technology 6502, which didn't have MMUs and didn't address much memory.  When I hear the phrase "Single-Board Computer", I still think of Multibus

John Beetem wrote:

 

When I hear the phrase "Single-Board Computer", I still think of Multibus

The rival VME Bus in my case --- I still have some self-made 68k-based VME boards in a box somewhere, and I wrote a program to lay out VME backplanes to link them up.  Motorola did everything much more elegantly than Intel in those days.

But to avoid the confusion of meanings, I highly recommend "bare metal microcontroller" to refer to this type of board and processor.  It was unambiguous .... er, until now.

Drew, leaving aside the puzzling situation with Galileo and how it's managing to run its peculiar version of Yocto, the Arduino TRE looks very good indeed!  In fact, over the last year and a half, haven't several of us called (repeatedly) for combining a Linux applications processor and an AVR microcontroller on the same board for the best of both worlds?  It makes so much sense on multiple fronts.  I'm delighted to see this in the Arduino TRE.

Morgaine Dinova wrote:

 

But to avoid the confusion of meanings, I highly recommend "bare metal microcontroller" to refer to this type of board and processor.  It was unambiguous .... er, until now.

Well, I use the term "bare-metal programming" to mean programming a processor at the machine/assembly language level (usually using C as a portable assembly language) with no device drivers restricting my access to the hardware.  So I can in principle do "bare-metal programming" on any processor -- with or without MMU -- whether or not it is capable of running a mainframe OS like GNU/Linux.  Now it's generally easier to do bare-metal programming on a small microcontroller since you don't need 50-100 pages of initialization code, but as long as the hardware is documented it's certainly possible to treat an ARM Cortex-A15 as a bare-metal processor.

By the way, jamesh at RasPi doesn't like the term "bare-metal" since he thinks you're programming at the silicon level.  I didn't bother to explain to him that once the chip is in a package, you can only access it through the metal pins.  However, I do use the phrase as often as possible chez RasPi just to be cheeky.

I just noticed that the Galileo board says it was Designed in Ireland.  Then it definitely should have an Irish name like James Joyce or Finnegan.

You're right in an absolute sense, since you can do "bare-metal programming" even on an applications processor by booting into your application directly instead of into an O/S kernel first.  You can also do the opposite, for example run uClinux on a microcontroller and program as if you weren't actually hitting the bare metal (you realize that you are though as soon as things go wrong).

However, in a practical sense, the use of these two types of programming does actually correlate very strongly with the type of device being programmed.  In practice you never do bare metal programming on an applications processor (unless you're developing the kernel or a kernel driver) and likewise, you never do anything but bare-metal programming on a microcontroller without an MMU even when the illusion is sometimes offered.

This distinction corresponds to the different levels of programming abstraction in the two cases.  On an applications processor running a system like Linux, the kernel creates an execution environment for user-mode processes that is a virtual abstraction which has very little to do with the details of the hardware, and this abstraction is enforced by the hardware MMU so it cannot be broken, bugs aside.  On a microcontroller lacking an MMU, there is no such virtual abstraction enforced by hardware, so even if software wizardry provides a superficially similar environment, when you're programming in C then a single errant pointer can penetrate the facade and ruin your whole day.

If Galileo was supposed to be OSHW/SW, someone forgot to tell Intel's lawyers.  The Intel Software License Agreement which you would have to tick before downloading the Galileo software is nothing short of demonic, and totally unacceptable given the intended aims of Galileo.  It's also totally out of step with the Arduino ecosystem.

Woah, there's no MMU?!  I hadn't read much yet but was assuming it was similar to atom - some low power x86 chip.  I thought everything since 386 had protected mode - weird.  I guess I need to read some more of the flurry of coverage from today.  Good catch.... I will add to my personal defination that SBC must have MMU

Woah, there's no MMU?!  I hadn't read much yet but was assuming it was similar to atom - some low power x86 chip.

I assumed the same thing.  It's described as a Pentium, and Pentiums have MMUs.

The Intel Quark Core Developer's Manual, section 3.3.1 "Address Spaces" says:

https://communities.intel.com/servlet/JiveServlet/previewBody/21826-102-2-25118/Intel%20Quark%20Core_DevMan_001.pdf

The Intel Quark SoC X1000 Core has three distinct address spaces: logical, linear, and

physical. A logical address (also known as a virtual address) consists of a selector and

an offset. A selector is the contents of a segment register. An offset is formed by

summing all of the addressing components (BASE, INDEX, DISPLACEMENT) discussed

in Section 3.5.3 into an effective address. Because each task on the Intel Quark SoC

X1000 Core has a maximum of 16 K (214 - 1) selectors, and offsets can be 4 Gbytes

(232 bits), this gives a total of 246 bits or 64 terabytes of logical address space per task.

The programmer sees this virtual address space.

 

The segmentation unit translates the logical address space into a 32-bit linear address

space. If the paging unit is not enabled then the 32-bit linear address corresponds to

the physical address. The paging unit translates the linear address space into the

physical address space. The physical address is what appears on the address pins.

This sounds like it is doing at least some sort of MMU function in translating virtual addresses

to physical addresses.

The FAQ, says under "What development operating systems are supported" at

http://www.intel.com/support/galileo/faq.htm

• Linux Ubuntu 12.04* (32-bit & 64-bit)
• Mac OS X version 10.8.5* (also tested on Mac OS X 10.6.8, 10.7.5, and 10.9* developer preview)
• Windows 7* (32-bit & 64-bit) and Windows 8*

I had initially understood that to mean supported on the Galileo, although the 64-bit versions

made no sense, and running Windows 7 in 256MB doesn't sound reasonable. 

Now I'm reading that as those OSs are supported on host computers connected to Galileo,

so it's not clear at all what OSs are supported on Galileo.