I'm told that the Atmel AVR32UC3A/B (and their associated eval boards, the EVK1100/1) cannot run Linux because the processor doesn't have an MMU... hence something like the AVR32-AP7, at a minimum, is needed.
On the other hand, uCLinux is specifically designed to run on processors without MMUs. So, any reason why uCLinux cannot run on the AVR32UCA/B?
Has anyone done such a port? I have searched the net and cannot find one so far.
The AVR32UCA/B are targeted as microcontrollers, not microprocessors. It's not the lack of the MMU that's the main problem (as you say, uCLinux can be used to get around that). It's the lack of memory - these devices have internal flash and ram, and no external databus. You need at least 2 MB flash and 4 MB ram to make a sensible Linux system, and these devices have not nearly enough.
Linux for CPUs without an MMU is called µCLinux (or uCLinux). It is very widely used on small devices.
-Michael
Do you have any data supporting that statement?
Of all embedded ARM Linux projects I have seen (~200), I can think of *one* using a MMU less ARM. That was around year 2000. Rest are using ARM9/11 with MMU.
-- Best Regards, Ulf Samuelsson
Regarding ARM you might be right, as the more powerful (thus useful for Linux projects) do have an MMU. Even though the ARM MMU design is bad (located "behind" the cache instead of "before" as with the x86 and other CPUs and thus requesting for cache flush with any task switch) and thus not using the MMU makes some projects a lot faster, most developers don't like to do without the additional comfort an MMU grants.
But there are lots of other processor brands but ARM (regarding the subject we are discussing AVR right now). The Linux tool chain I use features 23 main CPU architectures (one is ARM which internally is split in an MMU enabled and a non-MMU branch).
Of course not implementing an MMU makes the hardware faster, too.
I'm working on a project with a NIOS processor. This CPU does not exist in hardware, but is configured in an FPGA. You can choose if you want it with or without MMU. (With MMU: more programming comfort and security, but more FPGA resources, slower hardware and slower OS.) So I plan to use it without MMU in production but fall back to configure an MMU in a testing system for debugging when appropriate.
-Michael
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.