Linux To Gain Another Chip Family

An anonymous reader submits "Freescale will unveil the first ColdFire processors ever to include a memory management unit (MMU), and therefore able to run full-scale Linux, this week at the Embedded Processor Forum in San Jose, Calif. The chips cost $17 - $25, and are used mostly in industrial control and factory automation. Simultaneously, Freescale tools subsidiary Metrowerks announced plans to offer Linux development tools for Coldfire chips, which previously had been restricted to running uClinux due to the lack of an MMU."

Great, I can use them

[Orion Blastar]

I want to build a low cost Computer Automated Dispatch system with just the basics for low income firehouses, police stations, and hospitals. This chip might just fit the bill. I was going to go with Transmeta or a low end X86 processor.

Yay!

[ejaw5]

Finally! A day will come where I can get a processor with MM and NX bit on a mobile motherboard featuring MXM interface.

Re:New Amigas

[Anonymous Coward]

AmigaOS 4 could run rings around any other OS even at 266MHz. Its core is still based in the idea of efficiency. Remember the days when a 25mhz machine was fast? Those days are still there. Now the OS that ran well on 25mhz can run at 266, or 500, or 1GHz, and enjoy the same multiples in speed.

XP on a 3.4GHz P4? Still a slug

FYI Freescale is the old Motorola SPS group

[cacheMan]

This isn't some fly-by-night chip maker.

Re:This isn't a great as it seems

[Three Headed Man]

He's right. I'm a developer, and there's nothing that we can say that this chip really offers. As it is, I'm going to wait some time before working with it. It's not uncommon to discover flaws and exploits in a chip architecture in the first few months after it's released. It holds promise, but I'm going to wait and stick with something else for the time being.

Huge Difference

[bsd4me]

There is a really big difference between embedded processors and mainstream CPUs.

The biggest is that power consumption is really important in the embedded world. Sometimes you can only get so much current to a board, or you can't run fans.

Typically, embedded processors can run without support chips. Many have built in memory controllers and I/O.

Another thing is the MMU. A lot of embedded processors have MMUs (I think most of the PPC ones do), but OS support for them is a bit lacking (or it was until recently). But at times, the MMU can get in the way

IMHO, I would never run linux in an embedded product, other than simple internet appliances or where realtime isn't required. Commerical RTOSs like VxWorks [windriver.com] really are worth it for most embedded applications.

ColdFire is 680x0, nearly

[r00t]

ColdFire was created like this:

1. start with 680x0
2. rip out the bloat (MMU, fancy FPU, etc.)
3. redo the opcode-to-binary mapping

Often you can use 680x0 assembly code on
a ColdFire chip, though you'll need to run
it through a ColdFire assembler. You can't
just grab a binary.

Re:Metrowerks

[Megane]

In turn, freescale is a subsidiary of motorola.

Yeah, it was weird going down Parmer Road last week and noticing the Circle-M wasn't there any more. It took me a moment before I realized what those "Freescale" signs meant.

Another chip *family*? No.

[DdJ]

Another chip family? No, unless you think Intel XScale and TI OMAP are in different chip families. The ColdFire chips are just another example of the m68k family, like the DragonBall chips are.

cheapest embedded linux board?

[Anonymous Coward]

What's the cheapest embedded linux board (inluding cost of flash ram .. oh yeah must have ethernet)?

Anyone have ideas?

I am checking on google .. seems like the minimum amount to spend would be over 200.

Re:VxWorks is crummy

[bsd4me]

I have never needed a filesystem on an embedded product, and I don't think I have worked on a deployed system with more that 32 M. I think the biggest had 8M.

I would also be hesitant to deploy an RTOS without a proven track record and without good support. I have found kernel bugs before, and I have had to fly out tech support to help out with problems at customer sites. Most commercial vendors will also support old versions for a long time if needed.

What's so "u" about uCLinux?

[Doc Ruby]

uCLinux is a port of Linux to CPUs without an MMU. Without an MMU, the chips don't support the convincingly simulated parallelism of fork(), rather just the nominally similar (blocking) vfork(). What other compromises must an application concede when running under uCLinux, rather than a "full" Linux kernel?

Re:cheapest embedded linux board?

[AtomicBomb]

I am thinking about buying something similar (for ARM based, decent amount of flash, with ethernet). The best deal I can get is about $250 + complusive DHL option (another $40-50 to Australia/New Zeland). At the same time, I know I can get it for half the price if I can secure an order of 25+... Cannot find enough like minded geeks from my class to make a bulk order.

I feel that we can take advantage of some consumer electronics product... A lot of them are slightly modification of the reference design... Don't know where to start though... Any suggestion is welcome.

Re:Why is this so important?

[jejones]

The ColdFire is a 680x0 with the instruction set constrained in some ways (the number of instruction extensions is limited so that not all the combinations of addressing modes one is used to on the 680x0 are available for all instructions, arithmetic operations are all 32-bit rather than having 8-bit and 16-bit flavors as well) and extended in others (to compensate for the restrictions on arithmetic operations, there are load with sign extend and load with zero extend). Also, the ColdFire will trap on unaligned moves, unlike the 680x0 (68020 and above will cheerfully do unaligned moves, and even the 68000 only insists on 2-byte alignment for 4-byte moves).

The result of all this is to make the CPU more "RISC-like" and allow more efficient operation, but it also means that moving from 680x0 to ColdFire is a serious port--you definitely won't be able to just move 680x0 code over and run it.

Re:What's so "u" about uCLinux?

[pclminion]

Memory protection and the ability to multiprocess are two different concepts. All you need is a timer interrupt to implement concurrency. Without an MMU, the processes could corrupt each other, but there's no reason you can't multiprocess without an MMU.

Consider the TSRs from the days of DOS. You could easily latch onto the timer interrupt and have some background task run 18.2 times per second. Your only restriction was that you couldn't call DOS if the "in-DOS" flag was set, because DOS wasn't reentrant.

One can easily imagine a truly reentrant operating system supporting concurrent processes but which lacks any memory protection.