Slashdot Mirror

uClinux - can be built without MMU support. There's no memory protection, and program binaries have to be patched up by the loader, so that address references reflect the physical memory address at which the binary is loaded. http://www.uclinux.org/

Alright, here's my shtick... It's a great race between two open source software ecosystems: copyLEFT and copyFREE.

The copyFREE side is a more amicable pacifist bunch, with more freedoms and more choices, and it has been gaining ground in the last decade in all software categories but one - the kernels. The copyLEFT side was founded by a bunch of militant hippies trying to destroy capitalism, and it had several years' head start, so its viral licenses were grandfathered into some of the most important pieces of open source software. The OS projects within each team like to share code, and the copyLEFT team can also mooch copyFREE code as well, but not the other way around...

This race is contested on many fronts, and one obscure comparison (that I just came up with) is: while running the race forward, to still maintain support for the 80386 platform. Only UNIX systems (sorry, sorry, sorry) that can run on a 80386 PC (sorry, sorry) with actively maintained current versions (sorry) are to be included. Let's see how the two teams compare:

THE COPYLEFT TEAM:

(1) Linux - now i486, as mentioned in this article.

THE COPYFREE TEAM:

(1) FreeBSD - i486 since 2005.

(2) OpenBSD - i486 since 2007.

(3) NetBSD - i486, "80386 support removed" in 2007.

(4) MINIX 3 - i586, 32mb RAM, 635mb HD.

So it looks like the copyLEFT camp had this little "current UNIX on 80386" advantage, and now lost it...

--libman

Exactly. Chips with no MMU (Cortex-M4 et al) cannot run real linux because an MMU is a fundamental requirement for real linux (or any other serious operating system). Otherwise, Cortex-M4 is ARMv7 just like Cortex-A8.

OTOH, Freescale i.MX233 is only ARMv5 and is VERY lightweight, but does have an MMU. As a result you can run real linux on it.

In the above I use the expression "real linux". There is also a bastardized linux called uClinux which can run without an MMU. Of necessity, there can be no memory protection between processes, and there can be no fork. There is a vfork to allow multitasking, but any program which fork's (and that's practically every non-trivial program) has to be customized compared to the version for real linux. (See Q2.5 in the above link)

Yes.

Minerva is attracting your attention because they like to advertise themselves. The box is made from some reference design (the ones I'm familiar with are based on a Sigma chip) that a hardware vendor makes light modifications to (there are several candidate companies for your box). The Minerva software is put on top of that, and it's possible - but unlikely - that other software from your ISP or a system integrator acting for them - has been included. Sigma has opened much of its code, and the uclinux site hosts a Sigma variant (the Sigma chip is a SoC processor / video decoder). You will need an arm cross-compiler. You can then see for yourself how much of the rest of the code on your box has changed. Certainly busybox won't have. The GPL violation, in this case, is mostly that not everyone in the distribution chain is hosting the modified software. http://www.uclinux.org/pub/uClinux/ports/arm/EM8500/

• GNU/Linux: Uses glibc, GNU libstdc++, GNU Coreutils, and a plain Linux kernel.
• uClinux: Uses uClibc, uClibc++, BusyBox, and a kernel modified not to need an MMU.

I think id Games used to compile on SGIs. I know MS did some development on Xenix/i286 and Xenix/i386 (somewhere, there's an MS quote about how MS-DOS/Win is not suitable for serious development..hah). In fact, the i286 had a memory management unit, but the only OS (that I know of) which took full advantage of it was Xenix. Minix/i286 may have supported it to some extent, as well.
Some emulator pages....mac&ppc, simos (for SGI/IRIX5), DEC 10 and Big Iron, various DEC emulation, Apple Lisa, Z80 sim&development, yaze Z80, Apricot and Amstrad, bochs x86, ... and there's always emulators that run under DOS that you could run under Bochs or QEMU.

Other possibly helpful links:
emulators on freshmeat
OS kernels on freshmeat
OS's on freshmeat
bunches of old OS disk images
CP/M and MP/M
CP/M disks
Lisa Xenix
LisaOS
tandy xenix
elks and uclinux
freevms
freedos
Apple I (not II) development
reactos - winnt clone
MAME stuff and pinball Mame
info about tandy disk images
solaris minix
minix info and version 3
various free (as in beer and/or speech) OS list
The OS list at tunes.org

Linux takes way too much space for an embedded OS and REQUIRES a 32-bit cpu.

If you're not using all the features of the kernel you can strip it down (2.6 is even more modular than previous) and get it under a megabyte. You can use fbui and for another ~50kB get a gui with a window mangler in the kernel. uClinux runs on more limited systems (including those without MMUs). It runs on several 16 bit platforms, for example H8 300S.

It's also quite complex and therefore better suited to larger and more featureful devices. Even there, the numerous distributions lack of standards and standardized packaging and nonstandard GUI hampers it.

There is no support for your argument that it is better suited to larger and more featureful devices, because again, you can strip portions out of it.

Since these aren't desktop devices, your complaints about desktop linux are utterly irrelevant.

That's the reason why PalmOS, Symbian, QNX and wxworks exist. Not to mention eCos, uOS, FreeRTOS etc. Linux is not simply the best tool for the job. Linux is the best tool for certain jobs, the rest will require you to choose. The mobile market is just too diverse to standardize.

All of those exist because Linux was not ready to do those jobs (or didn't exist) when they were created. Many of them have no reason to exist now, except that they are better-supported than Linux (a correctable problem) or that they are FAR smaller, in which case they are not really suitable for a mobile phone either because you will have to develop too much of the software. Which is why we use operating systems and don't just write one big program.

Linux takes way too much space for an embedded OS and REQUIRES a 32-bit cpu.

If you're not using all the features of the kernel you can strip it down (2.6 is even more modular than previous) and get it under a megabyte. You can use fbui and for another ~50kB get a gui with a window mangler in the kernel. uClinux runs on more limited systems (including those without MMUs). It runs on several 16 bit platforms, for example H8 300S.

It's also quite complex and therefore better suited to larger and more featureful devices. Even there, the numerous distributions lack of standards and standardized packaging and nonstandard GUI hampers it.

There is no support for your argument that it is better suited to larger and more featureful devices, because again, you can strip portions out of it.

Since these aren't desktop devices, your complaints about desktop linux are utterly irrelevant.

That's the reason why PalmOS, Symbian, QNX and wxworks exist. Not to mention eCos, uOS, FreeRTOS etc. Linux is not simply the best tool for the job. Linux is the best tool for certain jobs, the rest will require you to choose. The mobile market is just too diverse to standardize.

All of those exist because Linux was not ready to do those jobs (or didn't exist) when they were created. Many of them have no reason to exist now, except that they are better-supported than Linux (a correctable problem) or that they are FAR smaller, in which case they are not really suitable for a mobile phone either because you will have to develop too much of the software. Which is why we use operating systems and don't just write one big program.

There is a port of Linux that will run on some microcontrollers, and ELKS, which is "sort-of Linux" aims to run on the 8086 and the 286.

What's most interesting about these mobos is that they're fanless. So they can be used in multiples around roomsful of normal people, especially driving TVs and stereos, without the annoying noise driving people crazy. But that's also true of some PII mobos.

These mobos support 1GHz CPUs, but they're Via C7. So what's the performance of these new mobos actually running, say, Linux (no X or desktop) and a streamplayer like madplay or even MythTV clients? Compared to their Pentium competitors, or even uCLinux running on these Blackfin DSP boards?

> You need a CPU with a MMU though.

In principle you could run uClinux without an MMU. http://www.uclinux.org/ports/ has a dead link to an Atari project, but no mention of the Amiga.
Anyone who cares enough about their Amiga to want to run Linux is going to have a processor upgrade anyway, I suspect.

Because Linux is so flexible and modular :-)

In its original form, Linux is basically a server OS like Unix. They've tweaked the scheduler to make it more responsive as Desktop OS. With some modifications, Linux can be a real-time OS. It has been modified to run on 16-bit processors without MMUs, so it can be an embedded OS for tiny systems. It compiles on x86, x86_64, sparc, ppc, alpha, IBM mainframes of every kind, itanium, arm, mips, and even the OpenRISC open-source-design embedded processor.

But there *are* lots of alternative FLOSS systems in use, I think! One alternative that no one ever mentions, for some reason, is eCos. It's a modular RTOS for embedded systems. A lot of routers use it actually, I had an 802.11b router that was based on eCos. If you need real-time, and don't want the overhead of a "full" operating system, eCos seems like a great choice! (I haven't developed with it myself.)

http://www.uclinux.org/index.html
If this dosn't work on your processor, nothing does.

Concidering that there are at least two different Commercial operations that have created a pared down version of linux for use as an embedded os saying that linux is to large to be worth using as an embedded os shows that you are really suffering from bad management decision making.

http://www.pt.com/products/nexusware.html [NexusWare(TM) Linux-Based Software Suite]

http://www.uclinux.org/ [Embedded Linux/Microcontroller Project]

http://www.denx.de/wiki/bin/view/DULG/ELDK [Embedded Linux Development Kit ]

http://www.mentor.com/products/embedded_software/ [ Mentor Graphics site ]

the last one above might actually be of use in your particular case, being embedded graphics applications specialised they may have something for your current device to improve the performance.

If you are using a normal distro on a device with extremely limited resources, then you would naturally have a very unreliable or slow device. If you are using linux on a excellent system, and are doing video compositing / editing work, then it may be that the particular application isn't as effective as it could be.

Cinelerra is an Adobe Premiere type of tool, but it's requirements for hardware are extremely high.
[ I don't have the hardware that can run it..dual opteron 275s with 4 x 1 Gb Registered pc3200 ram and 500 Gb hard drive is minimal ]

It's rue that in the case of Movie and Television needs linux is serioulsly lacking in the software to even support the needs. The options are there, if you have the time to find them, but the number of options is far less than with windows or mac systems.

You should be able to drop one of those SIMM sized linux modules in the mouth of a Mickey's Big Mouth. If only they had an equally small wireless module, you might fit the whole thing including enough AA batteries to run for a few days and have a working linux bottle with the cap on.

The spec page lists the ARM940T as a "video coprocessor", so in a way it is a GPU. It might not have very high performance compared to a real GPU, but it uses very little power. And it can probably be used for other things as well. Sound perhaps.

And the MMU-less uClinux looks to be doing well, with the uCsimm and uCdimm devices. I agree there's not much point in having an MMU and modern multi-user OS in a gaming platform that's only going to be running one thing at a time. But the hardware is becoming ever more capable and the OS features are certainly very nice, saving development time. So why not use an OS like Linux?

Analog Devices makes a family of DSP called the Blackfin that runs uClinux. We've been using a development board for well over a year. If this is TI's first linux offering, I'd say they're late to the party. Maybe it was hard to port Linux because sizeof(char) was 2. (If you've ever used a 16-bit TI DSP... :)

Call me when hackers have got it to boot into Linux, with the PalmOS GUI. Then it'll run the SW I want, over the 3G network, with an interface useable on a tiny device. When Verizon and Sprint try to charge me for downloading songs that they have nothing to do with, I'll just stream over a secure tunnel I make to my home computer over my cablemodem. If Apple can't deliver, I'll wait for Palm to hook me up.

Well, hows that for small? Don't even need a power cable! Booya!

And to eliminate the Slashdot effect jokes now... does their webserver run on one of these?

I've been working on something similar: last Christmas, I picked up 3 Network Everywhere NWR04B wireless routers on sale -- $18 each! -- and have been trying ever since to duplicate this guy's success in getting uClinux (a version of Linux for CPUs with no MMU) running on the thing.

The guy who got it running originally hasn't responded to my emails, so it's a good thing he made his kernel tree available. Alsoplus, I think he used a JTAG adapter to load the image; since I wanted to make a firmware image that anyone could upload with the web interface, I had to reverse engineer the firmware checksum too. (Luckily it was a pretty simple checksum, or else I don't think I would've been able to do it...I'm really learning all this as I go along.)

In July I finally managed to get a kernel panic, am now trying to get BusyBox working on the thing. I keep getting these errors:

Unhandled fault: external abort on linefetch (D4) at 0x00000001
fault-common.c(97): start_code=0x740040, start_stack=0x71ffbc)

which, from what I have been able to Google, may be because of differing opinions (libc/uClibc vs. the kernel vs. the chip) about whether or not this thing has an FPU. If anyone's got any suggestions, please leave a note -- I need all the help I can get.

It's been an incredible learning experience -- I know more now about how the kernel interacts with CPUs, the filesystems, compilers and the bootloader than I ever had. (Still got tons to learn, mind you.) I'm looking forward to the day I can get a Beowulf cluster of these things going. :-)

I've been working on something similar: last Christmas, I picked up 3 Network Everywhere NWR04B wireless routers on sale -- $18 each! -- and have been trying ever since to duplicate this guy's success in getting uClinux (a version of Linux for CPUs with no MMU) running on the thing.

The guy who got it running originally hasn't responded to my emails, so it's a good thing he made his kernel tree available. Alsoplus, I think he used a JTAG adapter to load the image; since I wanted to make a firmware image that anyone could upload with the web interface, I had to reverse engineer the firmware checksum too. (Luckily it was a pretty simple checksum, or else I don't think I would've been able to do it...I'm really learning all this as I go along.)

In July I finally managed to get a kernel panic, am now trying to get BusyBox working on the thing. I keep getting these errors:

Unhandled fault: external abort on linefetch (D4) at 0x00000001
fault-common.c(97): start_code=0x740040, start_stack=0x71ffbc)

which, from what I have been able to Google, may be because of differing opinions (libc/uClibc vs. the kernel vs. the chip) about whether or not this thing has an FPU. If anyone's got any suggestions, please leave a note -- I need all the help I can get.

It's been an incredible learning experience -- I know more now about how the kernel interacts with CPUs, the filesystems, compilers and the bootloader than I ever had. (Still got tons to learn, mind you.) I'm looking forward to the day I can get a Beowulf cluster of these things going. :-)

I've been working on something similar: last Christmas, I picked up 3 Network Everywhere NWR04B wireless routers on sale -- $18 each! -- and have been trying ever since to duplicate this guy's success in getting uClinux (a version of Linux for CPUs with no MMU) running on the thing.

The guy who got it running originally hasn't responded to my emails, so it's a good thing he made his kernel tree available. Alsoplus, I think he used a JTAG adapter to load the image; since I wanted to make a firmware image that anyone could upload with the web interface, I had to reverse engineer the firmware checksum too. (Luckily it was a pretty simple checksum, or else I don't think I would've been able to do it...I'm really learning all this as I go along.)

In July I finally managed to get a kernel panic, am now trying to get BusyBox working on the thing. I keep getting these errors:

Unhandled fault: external abort on linefetch (D4) at 0x00000001
fault-common.c(97): start_code=0x740040, start_stack=0x71ffbc)

which, from what I have been able to Google, may be because of differing opinions (libc/uClibc vs. the kernel vs. the chip) about whether or not this thing has an FPU. If anyone's got any suggestions, please leave a note -- I need all the help I can get.

It's been an incredible learning experience -- I know more now about how the kernel interacts with CPUs, the filesystems, compilers and the bootloader than I ever had. (Still got tons to learn, mind you.) I'm looking forward to the day I can get a Beowulf cluster of these things going. :-)

I've been working on something similar: last Christmas, I picked up 3 Network Everywhere NWR04B wireless routers on sale -- $18 each! -- and have been trying ever since to duplicate this guy's success in getting uClinux (a version of Linux for CPUs with no MMU) running on the thing.

The guy who got it running originally hasn't responded to my emails, so it's a good thing he made his kernel tree available. Alsoplus, I think he used a JTAG adapter to load the image; since I wanted to make a firmware image that anyone could upload with the web interface, I had to reverse engineer the firmware checksum too. (Luckily it was a pretty simple checksum, or else I don't think I would've been able to do it...I'm really learning all this as I go along.)

In July I finally managed to get a kernel panic, am now trying to get BusyBox working on the thing. I keep getting these errors:

Unhandled fault: external abort on linefetch (D4) at 0x00000001
fault-common.c(97): start_code=0x740040, start_stack=0x71ffbc)

which, from what I have been able to Google, may be because of differing opinions (libc/uClibc vs. the kernel vs. the chip) about whether or not this thing has an FPU. If anyone's got any suggestions, please leave a note -- I need all the help I can get.

It's been an incredible learning experience -- I know more now about how the kernel interacts with CPUs, the filesystems, compilers and the bootloader than I ever had. (Still got tons to learn, mind you.) I'm looking forward to the day I can get a Beowulf cluster of these things going. :-)

I've been working on something similar: last Christmas, I picked up 3 Network Everywhere NWR04B wireless routers on sale -- $18 each! -- and have been trying ever since to duplicate this guy's success in getting uClinux (a version of Linux for CPUs with no MMU) running on the thing.

The guy who got it running originally hasn't responded to my emails, so it's a good thing he made his kernel tree available. Alsoplus, I think he used a JTAG adapter to load the image; since I wanted to make a firmware image that anyone could upload with the web interface, I had to reverse engineer the firmware checksum too. (Luckily it was a pretty simple checksum, or else I don't think I would've been able to do it...I'm really learning all this as I go along.)

In July I finally managed to get a kernel panic, am now trying to get BusyBox working on the thing. I keep getting these errors:

Unhandled fault: external abort on linefetch (D4) at 0x00000001
fault-common.c(97): start_code=0x740040, start_stack=0x71ffbc)

which, from what I have been able to Google, may be because of differing opinions (libc/uClibc vs. the kernel vs. the chip) about whether or not this thing has an FPU. If anyone's got any suggestions, please leave a note -- I need all the help I can get.

It's been an incredible learning experience -- I know more now about how the kernel interacts with CPUs, the filesystems, compilers and the bootloader than I ever had. (Still got tons to learn, mind you.) I'm looking forward to the day I can get a Beowulf cluster of these things going. :-)

Unfortunately I don't have a link (maybe someone else will provide one) but recently someone on the m68k-linux mailing list has had some success on the Macintosh Classic, a 68000 based machine. I think they are using a port of ucLinux.

Forgot to mention that, from what I can see on the uCLinux website, uCLinux hasn't been ported to any rad-hard or space-qualified processors. Which further reduces the odds that JPL would use it for a mission as important as JIMO/Prometheus.

"Does it run Linux?" ... yes, it does. The onboard microcontrollers on the craft will run the uCLinux kernel, with Gentoo userspace. I have no idea what the boxen back at NASA supporting this will run though.

It's a pleasant thought that the first software that aliens might encounter from Earth won't be from M$ ... I for one don't want to welcome our angry alien overlords after they get sick of the crashes :-)

If you do not want anything do not compile it. simple

http://openwrt.org/
http://www.uclinux.org/
http://www.lynuxworks.com/
http://www.windriver.com/

The iPod can't run BSD, Darwin or any other system like that because it does not have a hardware memory management unit. iPod linux is based on the uClinux distribution, which is, "a port of Linux to systems without a Memory Management Unit (MMU)".

I'd be interested to know what this is, and how it differs from a cross-compiled copy of uClinux..

Which, by the way, has supposedly now been integrated into 2.6, so my question could also be, how does this differ from vanilla kernel 2.6 compiled for MMU-less ARM?

Isn't ARM-no-MMU the same as uClinux? If so, it's hardly new - uClinux started in 1998.

actually, linux runs just fine without an MMU - see uclinux

There doesn't seem to be a 2.6 version (only 2.4), but then I'm not sure if 2.6 hasn't had uclinux merged in. (a quick look at the config says no)

BTW. How's that Doom clone on the Speccy doing?

If the "u" stands for micro, what's the "C"? I've looked around but can't seem to find it.

"Mu" stands for "micro", and the "C" is for "controller".

ref: http://www.uclinux.org/

which begs the question, "where exactly were you looking?!?!?!?

"Linux wil run on most, if not all desktop computers currently running Windows."

In fact, Linux runs on about 23 additional architectures that Microsoft can't even remotely support with their most-flexible embedded target.

• Diverse PDA / embedded / microcontroller / router devices:
  • Advanced RISC Machines, Ltd. ARM family (StrongARM SA-1110, XScale, ARM6, ARM7, ARM2, ARM250, ARM3i, ARM610, ARM710, ARM720T, and ARM920T)
  • Analog Devices, Inc.'s Blackfin DSP
  • Axis Communications ETRAX series ("CRIS" = Code Reduced Instruction Set RISC architecture)
  • Elan SC520 and SC300
  • Fujitsu FR-V
  • Hitachi H8 series
  • Intel i960
  • Intel IA32-compatibles (Cyrix MediaGX, STMicroelectronics STPC, ZF Micro ZFx86)
  • Matsushita AM3x
  • MIPS-compatibles (Toshiba TMPRxxxx / TXnnnn, NEC VR series, Realtek 8181)
  • Motorola 680x0-based machines (Motorola VMEbus boards, ISICAD Prisma machines, and Motorola Dragonball & ColdFire CPUs, and Cisco 2500/3000/4000 series routers)
  • Motorola embedded PowerPC (including MPC / PowerQUICC I, II, III families)
  • NEC V850E
  • Renesas Technology (formerly Hitachi) SH3/SH4 (SuperH: link1 link2)
  • Samsung CalmRISC
  • Texas Instruments's DM64x and C54x DSP families
• Intel 8086 / 80286 .
• Intel IA32 family: i386, i486, Pentium, Pentium Pro, Pentium II, Pentium III, Xeon, and Pentium IV processors, as well as IA32 clones from AMD, Cyrix, VIA, IDT, Winchip, NexGen, Transmeta, VIA C3 Ezra "CentaurHauls", and others.
• Intel/HP IA64: Trillian/Itanium/Itanium2
• AMD x86-64 Hammer family (including AMD Opteron)
• Motorola 68020-68040 series (with MMU): m68k Mac, Amiga, Atari ST/TT/Medusa/Falcon, HP/Apollo Domain, HP9000/300, sun3, and Sinclair Q40.
• Motorola/IBM PowerPC family: Most PowerMac (including G3/G4/G5) / CHRP / PReP / POP, Amiga PowerUP System, and IBM PPC64 (AS/400, RS/6000).
• MIPS

"Linux wil run on most, if not all desktop computers currently running Windows."

In fact, Linux runs on about 23 additional architectures that Microsoft can't even remotely support with their most-flexible embedded target.

• Diverse PDA / embedded / microcontroller / router devices:
  • Advanced RISC Machines, Ltd. ARM family (StrongARM SA-1110, XScale, ARM6, ARM7, ARM2, ARM250, ARM3i, ARM610, ARM710, ARM720T, and ARM920T)
  • Analog Devices, Inc.'s Blackfin DSP
  • Axis Communications ETRAX series ("CRIS" = Code Reduced Instruction Set RISC architecture)
  • Elan SC520 and SC300
  • Fujitsu FR-V
  • Hitachi H8 series
  • Intel i960
  • Intel IA32-compatibles (Cyrix MediaGX, STMicroelectronics STPC, ZF Micro ZFx86)
  • Matsushita AM3x
  • MIPS-compatibles (Toshiba TMPRxxxx / TXnnnn, NEC VR series, Realtek 8181)
  • Motorola 680x0-based machines (Motorola VMEbus boards, ISICAD Prisma machines, and Motorola Dragonball & ColdFire CPUs, and Cisco 2500/3000/4000 series routers)
  • Motorola embedded PowerPC (including MPC / PowerQUICC I, II, III families)
  • NEC V850E
  • Renesas Technology (formerly Hitachi) SH3/SH4 (SuperH: link1 link2)
  • Samsung CalmRISC
  • Texas Instruments's DM64x and C54x DSP families
• Intel 8086 / 80286 .
• Intel IA32 family: i386, i486, Pentium, Pentium Pro, Pentium II, Pentium III, Xeon, and Pentium IV processors, as well as IA32 clones from AMD, Cyrix, VIA, IDT, Winchip, NexGen, Transmeta, VIA C3 Ezra "CentaurHauls", and others.
• Intel/HP IA64: Trillian/Itanium/Itanium2
• AMD x86-64 Hammer family (including AMD Opteron)
• Motorola 68020-68040 series (with MMU): m68k Mac, Amiga, Atari ST/TT/Medusa/Falcon, HP/Apollo Domain, HP9000/300, sun3, and Sinclair Q40.
• Motorola/IBM PowerPC family: Most PowerMac (including G3/G4/G5) / CHRP / PReP / POP, Amiga PowerUP System, and IBM PPC64 (AS/400, RS/6000).
• MIPS

"Linux wil run on most, if not all desktop computers currently running Windows."

In fact, Linux runs on about 23 additional architectures that Microsoft can't even remotely support with their most-flexible embedded target.

• Diverse PDA / embedded / microcontroller / router devices:
  • Advanced RISC Machines, Ltd. ARM family (StrongARM SA-1110, XScale, ARM6, ARM7, ARM2, ARM250, ARM3i, ARM610, ARM710, ARM720T, and ARM920T)
  • Analog Devices, Inc.'s Blackfin DSP
  • Axis Communications ETRAX series ("CRIS" = Code Reduced Instruction Set RISC architecture)
  • Elan SC520 and SC300
  • Fujitsu FR-V
  • Hitachi H8 series
  • Intel i960
  • Intel IA32-compatibles (Cyrix MediaGX, STMicroelectronics STPC, ZF Micro ZFx86)
  • Matsushita AM3x
  • MIPS-compatibles (Toshiba TMPRxxxx / TXnnnn, NEC VR series, Realtek 8181)
  • Motorola 680x0-based machines (Motorola VMEbus boards, ISICAD Prisma machines, and Motorola Dragonball & ColdFire CPUs, and Cisco 2500/3000/4000 series routers)
  • Motorola embedded PowerPC (including MPC / PowerQUICC I, II, III families)
  • NEC V850E
  • Renesas Technology (formerly Hitachi) SH3/SH4 (SuperH: link1 link2)
  • Samsung CalmRISC
  • Texas Instruments's DM64x and C54x DSP families
• Intel 8086 / 80286 .
• Intel IA32 family: i386, i486, Pentium, Pentium Pro, Pentium II, Pentium III, Xeon, and Pentium IV processors, as well as IA32 clones from AMD, Cyrix, VIA, IDT, Winchip, NexGen, Transmeta, VIA C3 Ezra "CentaurHauls", and others.
• Intel/HP IA64: Trillian/Itanium/Itanium2
• AMD x86-64 Hammer family (including AMD Opteron)
• Motorola 68020-68040 series (with MMU): m68k Mac, Amiga, Atari ST/TT/Medusa/Falcon, HP/Apollo Domain, HP9000/300, sun3, and Sinclair Q40.
• Motorola/IBM PowerPC family: Most PowerMac (including G3/G4/G5) / CHRP / PReP / POP, Amiga PowerUP System, and IBM PPC64 (AS/400, RS/6000).
• MIPS

This sounds much like uClinux, which specifically targets boards without MMUs (memory management units). uClinux already runs on tons of target boards and platforms, including older Cisco 2500 / 3000 / 4000 routers. It's commonly used on smaller embedded devices, such as the Actiontec Dual PC Modem and Linksys WRT45G.

This sounds much like uClinux, which specifically targets boards without MMUs (memory management units). uClinux already runs on tons of target boards and platforms, including older Cisco 2500 / 3000 / 4000 routers. It's commonly used on smaller embedded devices, such as the Actiontec Dual PC Modem and Linksys WRT45G.

ipodLinux is based on uClinux, which is a version of Linux that runs on processors without an MMU (Memory Management Unit).

The research group where I work is quite involved in embedded linux work. Last year I ported the Linux kernel to an FPGA-based processor called Microblaze. I'm now doing all sorts of fun stuff involving dynamically self-modifying hardware and other bizarro stuff. All good fun.

uClinux is running in something like 20 million devices, ranging from DVD players to netowrking routers and embedded VPN servers.

Give it a couple of years, and the embedded linux market will make the desktop look puny. The talk on slashdot is all about the Linux desktop, but Linux is already winning the real war, embedded systems.

An infinite amount of time, because Linux needs at least a i386 (MMU and all that).

I wouldn't go so far to call it an infinite amount of time, since uClinux, a kernel tree designed to run on systems without a MMU, does in fact run on 286'es. But I wouldn't recommend a kernel compile on you good'ol'8MHz, as it would take (infinite - 1) monkies to figure out the binary sources for kernel 2.8 by the time it gets done.

if you're jobless and bored...

go here: blackfin.uclinux.org

they're trying to port xmame to a dsp board and looking for some people to work on the project... compensation looks to be experience and free hardware...

Did you know uCLinux, once a project fork, got adopted into the main kernel during 2.5? Do you know what uCLinux is for? Running Linux on microcontrollers that don't have memory management units. It's for systems that run completely out of physical RAM with no memory protection.

You see, there are systems for which the power, heat, cost, weight and space of an MMU would be objectionable.

I'm concerned about how the Linux kernel can continue to serve everyone's disparate needs. If the uCLinux folks are running Linux on an ARM7TDMI chip that's smaller than a postage stamp, are they going to be able to use code from the same project that's running a cluster of Oracle databases on a cluster file system?

Another concern I have is old hardware. Will 2.7 still run well on old boxes that would otherwise be destined for the landfill?

One of the great strengths that Linux has always had is that it runs great on hardware that's too slow to run Windows or (nowadays) Mac OS on. My PowerMac 8500 was once one of the fastest desktop computers money could buy, but now its 150 Mhz PowerPC 604 is too slow to run Mac OS X. Linux, however, runs great and it has been serving as an IP masquerading gateway, file server and all-around Linux desktop box.

I will never understand why Linux and NetBSD are currently looked down upon in the embedded corporations currently

Because they're fucking HUGE.

The uCLinux kernel for 68k which is more compact than SPARClite, but maybe less so than x86, is 512K.

That's a stripped-down kernel with no MMU support and the special uClib C standard library designed to take less space.

I'm working on a digital camera with 512K of flash and 8MB of SDRAM. That flash is divided into 7 64K sectors and 8+16+16+32K little sectors. We use the upper 64K for sensor calibration data and the lower 64K for a boot block that can be locked so you can recover a camera with a bad firmware load.

That leaves 384K for everything else. Our kernel is Precise/MQX from ARC International and it's 30K !.

Oh, and the RAM is needed for image processing and buffering movie frames on their way out to NAND flash, so your piggy kernels can't have it.

While I'd like some things from uCLinux and busybox and netBSD, I have to be very selective. I'm presently porting elf2flt to the Metaware tools for ARC so we can dynamically load code resources. We'll also get a real log facility and monitor soon and maybe someday the Almquist shell.

At least MQX and the Metaware tools are reasonably cheap and we get kernel and library sources (and ARC CPU hackable RTL instead of a giant impenetrable lump like ARM). I've heard nothing but irritation with WindRiver's high pricing and closed-IP attitude.

uCLinux has been ported to some 68K derivatives. See their Ports Page.

I can run Linux on Ipod but will one have the support to house my distro?

I have a company that am building an embedded device and plan to use embedded Linux, probably uClinux as its operating system. The hardware engineering design firm I am working with says that they are using WinCE in their projects "because of the lawsuit". The "lawsuit" is not stopping my company from using Linux, but it is interesting and disturbing to see very technical and well informed hardware engineers being taken in by SCO FUD.

Tangentially, I find it interesting that my patent attorney from a large and respectable firm in downtown Boston believes that the GPL is viral. I have forwarded him some information from GNU that should clear up his confusion, but it does disturb me that some people in the patent and copyright field are not doing their homework.

Anyway, I'm doing my little bit to educate "the masses"!

Well, there's ucLinux, a project designed for microcontrollers without a MMU. With tools, it adds up to about 900KB. Somebody with way too much time on their hands (i.e. maths students) could probably port it to the TI-89, though I have no idea what hardware it has. Now, what would've been cool, is porting it to Casio calculators. In Norway, Casio rules for some reason, and I have to use my 1.5MB FX 1.0 for something! (-: Does anybody know anything about custom OS for Casio calculators?

I have the same player. It's great, but I too would like to modify the source. It would've been cool to add network functionality using the PCMCIA-slot etc.

I've downloaded the ROMFS. The root contained these files (and some images etc): fileplayer.bin, fipmodule.o, khwl.o, linux.bin.gz, minimod, mpegplayer.bin

Seems like the 'real' (custom?) system is contained in /bin/init (binary). (The strings output of that file makes me believe so)

khwl.o (using strings): EM85xx driver module /project/liteon-release/v0.02.27/uClinux-2.4/ 2.4.17-uc0 Proprietary. Copyright (c) 2002 Sigma Designs Inc. All rights reserved.

So maybe they use a stock uClinux kernel, some proprietary modules, and a custom init system?

If the init system doesn't contain any GPL-code, do they have to release it? How about the legality of including proprietary modules? If it's ok, don't they only have to say: "Get the source for the kernel at uClinux.org"? - and make it pretty much unhackable?

You can get the ROMFS I used at Kiss-Tuning's download area.
By the way, the links-section contains a list of players using embedded linux.

I've updated the player with the latest beta-driver (they had it on the website for a little while). It's great. It adds directory browsing to the system. Subtitle-support. Smoother avi-playing (think they've increased the use of buffer/cache). It can even play videos and music from the CF-card reader. (Very nice)