If you use one the EmCraft Cortex M3 development boards based on Actel SmartFusion (149 USD), you will get the Linux Board Support Package (BSP) for the board you purchased. EmCraft also sells Linux BSP (for 99 USD – software only) for STMicroelectronics STM32F2, NXP NXP LPC1788 (Cortex M3) and Freescale Kinetis (Cortex M4) development boards.

If you just want to play around, most of those board will be fairly expensive starting at several hundreds of dollars to nearly one thousand dollars. There also some low cost Cortex-M boards such as the STM32F4-Discovery board available for around 15 USD, but there is unfortunately not enough RAM (192KB) to be able to run uClinux.

So if you are a hobbyist, you’d probably better stick to boards such as Beagleboard or Raspberry Pi , but if you want to develop and mass-produce a real product, Cortex M3/M4 based devices running uClinux are definitely an option. If you can find a cheap Cortex-M dev board with 1MB or more RAM that costs less than 100 USD, let me know in the comment section.

@Guillaume FORTAINE
Happy New Year to you too !
The link you sent me talks about a Freescale Soc with Cortex A5 + Cortex M4 and the CoreTile Express development board. But it seems it need to be connected to a motherboard, and I can’t find any pricing info.

Clearly, the idea that you mention in your post is really interesting. However, to my knowledge, there is no Cortex-M3/M4 processor with more than 256kb of RAM and I don’t think that the situation will evolve. That’s why this chip from Freescale seems to be a good alternative, especially, due to the choice of a Cortex-A5 as Application Processor. The corresponding price and development boards should be available in the following months.

@Guillaume FORTAINE
Cortex M3/M4 processors do not embed more than 256 KB of RAM, but some development boards (like the one provided by Emcraft or Keil) use external RAM. That’s why they are able to run uClinux.
Having that said, the Freescale Cortex A5 SoC may also prove be a good alternative, we’ll have to wait and see.

Well, essentially, what you are saying is, if you want to run Linux, use a MMU-full microprocessor; don’t use Cortex-M3.

I am not sure I agree. Outside of the price, there are power considerations. Applications with low-power requirements is where Cortex-M3 shines. Perfect power profiles at dynamic times; plenty of low-power modes to choose from for static times. You don’t get that with a MMU-full processor.

Consider an application that is idle most of the time but needs lots of “features” when active. True, uClinux requires external RAM to run from, however at idle times external RAM is idle too and draws very little power.

uClinux may actually make perfect sense for higher-end Cortex-M3/M4 applications, including designs based on the STM32F2/F4 devices. With Linux, you get royalty-free support for pretty much all I/O interfaces (and there are plentty of those on STM32F) as well as lots and lots of ready-to-go tools and applications. Yet, you are able to be low cost and low power, which is why people choose Cortex-M in the first place.

Linux (uClinux) runs just beatifully on this device. Using ‘dhrystone’, we get about 50% performance we get on a 250Mhz Freescale PowerPC box. Fast boot-up, lots of RAM (the TWR-K70 module provides 128MB of RAM and 256MB of NAND Flash), networking, JFFS2, framebuffer, SSH, HTTPD, Qt/E – all this runs just fine on K70. Overall user experience is your regular “embedded Linux” on an MMU-full microprocessor.

In the Kinetis K70 context, the only type of input device we support with Qt at this time is an emulated keyboard using stdin input. We are working on a device driver for the USB host interface, which will allow us to support USB mouse. When done, we will provide a Qt GUI video for uClinux on K70.

Meanwhile, we have developed a video showing the Linux framebuffer and a Qt GUI demo for another Cortex-M3, NXP’s LPC1788. Details are available here:

Would packages of ARMv7 thumb2 distributions like Debian armhf and Ubuntu on ARM work with Cortex-M4 MCUs? The kernel would still be a custom build, but having a package repository is a big help to application developers. They can then focus on coding their vertical app instead of building general purpose apps.