Slashdot Mirror
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."
These chips, distantly related to the 68k motorolas, were once touted as a possible upgrade path for new Amigas in the mid 1990s. Hopefully with these new ones, the more modern AmigaOS4 can be ported to them, and continue the heritage. At the moment the only stock available is AmigaOne G3, G4 and mini-itx PPC boards, which are artificially inflated in price by the apple/ibm/motorola consortium.
I thought I knew which processors were important in the embedded world. What exactly is Coldfire, and why does it matter compare to ARM and Motorola's offerings?
I realise that Yet Another Embedded Processor that can run all of linux is a good thing. I just don't see why that is important, since the difference between embedded and desktop processors has been diminishing sharply.
Huh? Metrowerks produces apple development tools, and they dabble in linux/embedded development tools. I'm pretty sure that Metrowerks is not a freescale subsidary. See for example this PR.
freescale is a subsidiary of motorola, here is homepage for coldfire.
Marge, get me your address book, 4 beers, and my conversation hat.
Wait a minute.....
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.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I wonder when MSFT Embedded Visual C++ will support this?
I want my rights back. I was actually using them when our government stole them after 9/11.
Yeah but do they run... oh... wait... nevermind.
Since when has this country used intellectual elite as a pejorative term?
Other key features of the new MCF547x and MCF548x ColdFire processors include on-chip FPU and eMAC
Dammit apple, I just bought a brand new eMac only months ago, and now they're putting them on-chip for under $30!
I added support for ColdFire processors to Linux years ago. This won't be new. It was added to Linus kernels in the 2.5 series, and is fully supported in the 2.6 kernels for all the older ColdFire parts (5206, 5249, 5272, 5282, 5307, 5407). Ofcourse the older parts did not have an MMU.
Look under the arch/m68knommu branch for all the architecture support...
Finally! A day will come where I can get a processor with MM and NX bit on a mobile motherboard featuring MXM interface.
$cat
This isn't some fly-by-night chip maker.
Cold fusion processors... Is it real or is...oh, nevermind...
What?
Just as Power begat PowerPC and x86 begat x86-64,
so 680x0 begat ColdFire.
In this case, the instruction set was recoded
to save memory and reduce power consumption.
Given some 680x0 assembly code, you pretty much
have ColdFire assembly code. The mapping from
opcode to binary is different. Most likely there
are a few minor changes beyond that, but not much.
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.
I'm probably at the karma cap. Mod up a funny troll instead, it lightens the mood
First, let's compare apples to apples. These new ColdFire processors run at 266 MHz and cost $20-27. The 266MHz PowerPC MPC5200 (also from Motorola) costs $27.
Even the desktop-class PPC 750s and 74xxs aren't expensive if you buy them in volume. The AmigaOne is expensive because it is a niche-of-a-niche product, not because Moto is ripping people off.
There is actually an Atari Cold Fire Project based on these processors: http://acp.atari.org/
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 really are worth it for most embedded applications.
(S(SKK)(SKK))(S(SKK)(SKK))
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.
Don't click that link. If you check your status bar, it's "http://www.google.com/url?sa=D&q=http://www.peopl esprimary.com/?n=Sarojin", which redirects to http://www.peoplesprimary.com/?n=Sarojin, not a Google search. The page is nasty
Their shell is an abomination. Their filesystem
is plain old DOS FAT, optionally with an
incompatible long-filename feature. The "mount"
command (function? all the same...) is totally
defective, doing some kind of dumb text substitution
instead of real mount points. Memory support is
terribly limited -- is 32 MB enough for you?
For the cost of VxWorks, you can get a bit of
extra memory for running Linux. You'll also save
on development costs that way.
If you'd really prefer a tiny OS designed for
strict real-time from the start, use eCos.
It's free even.
Sorry about that, I didn't check the link. -THM
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.
What's the cheapest embedded linux board (inluding cost of flash ram .. oh yeah must have ethernet)?
.. seems like the minimum amount to spend would be over 200.
Anyone have ideas?
I am checking on google
Innovation like this underscores the need for relying on free software (or, put differently, the problem with relying or recommending non-free software). It's an easy trap to get into when you use an i386 GNU/Linux distribution (as most GNU/Linux users do, I suspect) because there are so many opportunities to get hardware that only fully work with non-free software (like nVidia video cards that require non-free kernel driver software to operate fully). When you become dependent on non-free software you lose portability which prevents easily moving to interesting hardware like this one. Non-free video and audio codecs are similar; if you base your work on some Microsoft library for decoding audio or video you won't easily be able to read those files on a non-i386 platform.
Software proprietors won't supply the wide range of support the free software community does. Software proprietors won't give you the power to provide your own support or buy it from programmers and sysadmins in the free marketplace.
Digital Citizen
Revive the excellent Atari ST! Blew Amiga's away big time.
mmmm.. that kind of sounds like an STD of some kind. A mix of crabs and clymedia. Can't wait to catch that one.
-I DDoSed your mom.
Consider the disk array controllers EMC makes.
Last I heard, a year or two ago, they were
using about 32 GB of RAM.
Consider the airborne radar systems and cell
phone base station software-defined radio based
on Mercury Computer Systems hardware. It's common
to have dozens of gigabytes of memory, sometimes
even hundreds of gigabytes. Each node of the
multi-CPU system might have 2 gigabytes or so.
Linux is often used.
Consider the telephone switchs NexTel produces.
That's a few gigabytes, running Linux of course.
Are all the Tramails dead yet? No? Then it is not yet time.
We looked at VxWorks for our first-ever embedded project. When we found out there was no Perl for VxWorks, nor any chance of ever, ever having Perl on VxWorks, we quickly abandonded VxWorks in favor of Linux.
We've have no problems whatsoever using Linux as an embedded OS. Plus, we get to write much of our code in Perl as well. This is as it should be.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Anyone else find uClinux to be a funny word?
Rush fans everywhere rejoice!
Motorola has sold a lot of coldfire controllers. They usually offer a dozen or so independently addressable relays, rs232, firewire, usb1.0/2.0 support, sensor and tie points (and usually a gob of other stuff) all stuck onto a small 10.16x12.7cm (4x5 inch) printed circuit board. Great boards for feedback/monitoring/control/SCADA. They usually are fairly cheap too.
It's now able to "qualify" for something like the Gumstix project [for intel Xscale]...a quick and dirty hobby board that's easy to port common stuff [telnet, serial I/O, and run some programs] to and use in some kind of hobby project. Not that it couldn't before, but now it can use off-the-shelf programs simply recompiled rather than hacked up to cover for missing hardware functions that we mere mortals can't do easily!!!
helical-scan CAT (a 3-D X-ray)
ultrasound with live 3-D video
digital X-ray, again with live video
PET scan (radioactive sugar emits positrons)
virtual bowel exam, with the doctor having a game-like 3-D view of your butt -- except that he doesn't get a BFG9000 to hit the cancers (the data comes from one of the above of course, the digital X-ray I think)
That $30 chip is almost twice as fast as my combination (web/ftp/print/useless crap)server. If it has above 32M of memory, it has more RAM also.
I've got to admit that the thing is finally going to die at some point.
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?
--
make install -not war
They try to fool you into thinking they are. But they aren't. They are an entirely different architecture that uses similar nmeumonics and addressing modes.
Even the hexidecimal encodings of those instructions (i.e. the machine language) is dissimilar from 68K machine language.
ColdFire is a strange product, I moto has been pushing it for some time now. I'm not sure why it is still around.
Wasn't that to make old software and hardware work that couldn't run right on the new machines?
With great power comes great fan noise.
Perl for an embedded application!? I have a favorite scripting language too, but small and fast is king. I feel like a C compiler is a guilty convienience.
Then again, I'm used to the days when "embedded" meant 64K of ram on a 4 Mhz processor.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
is send out signals to activate alarm clocks, lights, bells, sirens, speakers, and display a message on a computer with details of the 911 emergancy.
We are talking about something that an original Palm Pilot or security alarm system can do. An 8 bit processor may be too underpowered, but I believe this is more of a 16/32 bit hybrid like a 68K processor. If you examine ADT, and other boxes that security alarm systems use, you won't find the most powerful processors in those. Maybe a 16 or 32 bit processor with low end speed.
Now building a 911 CAD box with a Pentium 4 is overkill, and unless you really need the horsepower, it would be overpriced.
You have missed the point, I wanted to make a low cost, no frills, version of a 911 CAD box. Other companies have this box but charge $1000USD to $4000USD or more for each box, and some emergency providers cannot afford that.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
That was my original idea to use a low end X86 processor. Embedded Linux already exists for it, and if SCO gets their way we can always change to BSD Unix.
;)
Anyway an original socket 7 X86 chip should work fine for low end 911 Computer Automated Dispatch. That is if they still sell them.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
No secret here -- Motorola SPS bought Metrowerks and kept it as a wholly owned subsidiary, Motorola SPS is now Freescale (a wholly owned subsidiary of Motorola).
The only x86 chip you would want to think about in an alarm box would be imbedded _3_86 flavors.
That said, they'll still consume _way_ too much power. Yer alarm system has to run on batteries during power outages, or when intruders are smart enough to shut off the power before entering.
You _definately_ want to look at 8-bit CMOS microcontrollers, or something else in that range. I'm rather fond of 80C31/51 types myself. No, these won't run Linux, but plenty of F/OSS tools are available. Do you want to do image and sound recognition, or do you just want to watch switches and sensors?
Exceeding the recommended torque is not recommended.
and can be programmed for things like voice over IP, image displays, real streaming audio, and perhaps have a small build in web server that can be used to configure or interface with another system. Security is a must, everything must be encrypted and password protected. I thought about using GPG for encryption for data packets the dispatch system sends to each 911 CAD box. We don't wany any false alarms or crackers tampering with the boxes.
Windows and DOS simply won't do, not stable enough for a 24/7 realtime environment. Also very insecure. Linux or Embedded Linux seems to be ideal.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
it might help to lower the cost if we use standard off the shelf parts instead of fabercating our own.
Just need a double-throw relay interface for the box to access the various devices it will set off. Like in a firehouse it needs to flicker the lights in the shower, etc. Everyone in the firehouse should know that there is a real emergancy going on, so a device is needed for every room. Figure about 12 to 15 double-throw relay interfaces. It will be a matrix that can be controlled, and one or more of those relays might send data to a printer or image device with more info on the emergency. I'd like to use Wifi, but it is too insecure to manage, plus someone could block it easily. Maybe a CAT5/CAT6 network as well? I figure throw in SAMBA on an Ethernet and print out the emercency details to a networked printer or file server somewhere.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
It may not add massive functionality, but if it allows building more reliable systems, due to use of MMU, that seems hardly a bad thing.
If you're not part of the solution, you're part of the precipitate.