Generic Linux can't be run on Cortex M3 because Cortex M3 has no MMU. Okay, there're special versions of Linux that can run there.
The problem is I don't quite get how this affects application software.
Suppose I have some application - any user application, let it be ZIP unpacker as an example. I have it in source form and can compile it for ARM.
Will it run on Cortex M3 that has no MMU? How do I know if lack of MMU will affect any given program?
There are several things that an MMU gives you:
Memory Protection: In a multitasking environment this prevents one buggy program from affecting another program. For example, if the buggy program tries to write to a memory location using an uninitialized pointer it might overwrite code or data for the good program. Memory protection prevents this by putting restrictions on what memory each program can access.
Memory Translation: The MMU does a "logical to physical memory address translation". Memory is normally split up into blocks or pages. Sometimes, especially after a multitasking system has been running for a while, the physical memory pages can get all mixed up into discontinuous chunks. The MMU can rearrange these pages to create virtual memory chunks that are contiguous. Think of this like defragmenting a hard drive, but with memory and without the time-comsuming copying/moving of data around.
Virtual Memory: More sophisticated OS's allow for virtual memory, where the apparent amount of RAM in a system is larger than what is physically installed. The extra memory is usually located on the hard drive. When a program tries to access a page of memory that is not physically located in main memory the MMU informs the OS. The OS then loads that page of "memory" into main memory. If main memory is full, another page of main memory is transferred to the hard drive to make room. The MMU and OS do this fairly quickly, and in a way that the program doing the memory accessing does not even know it is happening. This was more important back in the days when memory was small and expensive, but it is still used to day for almost all major OS's.
MMUs are most important for multitasking systems. For single tasking systems and many embedded applications, the value of an MMU is questionable.
When there's no MMU, the part of the operating system that loads application programs into memory needs to be able to "relocate" the application code to run in the region of memory assigned to it. The compiler used for the application (or more specifically, the linker) needs to produce a file that the OS loader can understand in order to accomplish this.
There are rarely any changes required in the application source code. However, keep in mind that systems that don't have MMUs also don't have virtual memory, so the application and its data will have to fit into whatever physical memory is available, along with the OS itself and whatever other applications you want to have running simultaneously.
As I understand it, you need to compile your applications against the given architecture and operating system.
In the example of uCLinux, you would need a compatible compiler (like the one CodeSorcery offers here) and then you'd have to compile your desired applications targeting uCLinux and ARMv7-M. My suspicion is that by targeting uCLinux specifically, it's targeting the memory management code inherent to uCLinux that allows it to run on MMU-less microcontrollers/microprocessors.
