Why LPC1788 does not support Linux

       As a powerful Cortex-M3 chip, why can't LPC1788 be ported to Linux? Because like ARM7, LPC1788 does not contain MMU - memory management unit. MMU is necessary for advanced operating systems (Windows, Linux). Simply put, the role of MMU is to provide safer storage space for threads.

        ARM9, ARM11 and other CPUs include

        Of course, there are solutions. For CPUs without MMU such as LPC17xx, uCLinux can be used. However, there is still little information on porting uCLinux to LPC17xx.

        Learn more about MMU from Baidu

        Full entry: http://baike.baidu.com/link?url=eOwAmbW0dXaXsQh1ylxcKFI8vxWQ54o_tAmfv1OAu51hB-Nv3mo1EowL8Er4TciT

MMU is the abbreviation of Memory Management Unit. Its Chinese name is memory management unit. It is the control circuit used to manage virtual memory and physical memory in the central processing unit (CPU). It is also responsible for mapping virtual addresses to physical addresses and providing memory access authorization for hardware mechanisms.

Mapping linear addresses to physical addresses

Modern multi-user, multi-process operating systems require MMU to achieve the goal of each user process having its own independent address space. Using MMU, the operating system divides an address area, and the content seen by each process in this address area may not be the same. For example, the MICROSOFT WINDOWS operating system divides the address range 4M-2G into user address space. Process A maps an executable file at address 0X400000 (4M), and process B also maps an executable file at address 0X400000 (4M). If process A reads address 0X400000, it reads the content of A's executable file mapped to RAM, and when process B reads address 0X400000, it reads the content of B's ​​executable file mapped to RAM.

This is where the MMU comes in to perform address translation.

Provides hardware-based memory access authorization

For many years, microprocessors have come with on-chip memory management units (MMUs) that enable a single software thread to work in a hardware-protected address space. However, in many commercial real-time operating systems, the MMU is not used even if the system contains such hardware.

When all threads of an application share the same memory space, any thread can intentionally or unintentionally damage the code, data, or stack of other threads. Abnormal threads may even damage kernel code or internal data structures. For example, a pointer error in a thread can easily crash the entire system, or at least cause the system to work abnormally.

In terms of security and reliability, process-based real-time operating systems (RTOS) have superior performance. To generate processes with separate address spaces, the RTOS only needs to generate some RAM-based data structures and let the MMU enforce the protection of these data structures. The basic idea is to "access" a new set of logical addresses in each associated conversion. The MMU uses the current mapping to map the logical addresses used in instruction calls or data reads and writes to physical addresses of the memory. The MMU also marks accesses to illegal logical addresses that are not mapped to any physical addresses.

Although these processes add the system overhead inherent in accessing memory using lookup tables, the benefits they achieve are high. At process boundaries, carelessness or erroneous operations will not occur, and a defect in a user interface thread will not cause code or data in other more critical threads to be corrupted. It is incredible that there are still operating systems without memory protection in complex embedded systems with high reliability and security requirements.

The use of an MMU also facilitates the selective mapping or unmapping of pages into the logical address space. Physical memory pages are mapped into the logical space to hold the code for the current process, and the remaining pages are used for data mapping. Similarly, physical memory pages are mapped to hold the thread stacks of a process. The RTOS can easily retain the contents of the page corresponding to the logical address after each thread stack is unmapped. This way, if the stack allocated by any thread overflows, a hardware memory protection fault will occur, and the kernel will suspend the thread without allowing it to corrupt other important memory areas located in the address space, such as another thread stack. This adds memory protection not only between threads, but also between the same address space.

Memory protection, including this type of stack overflow detection, is usually very effective in application development. With memory protection, program errors will generate exceptions and can be detected immediately, which can be traced from the source code. Without memory protection, program errors will cause subtle failures that are difficult to trace. In fact, since RAM is usually located at page zero of physical address in a flat memory model, even the dereference of a NULL pointer cannot be detected.