Using dynamic RAM with uClinux on LPC1788

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by Vladimir Khusainov on Wed Feb 08 09:14:00 MST 2012
To run on the LPC1788 devices, Linux (uClinux) requires external RAM. The on-chip Flash and SRAM are just not large enough to host the bulky Linux kernel, let alone various user-space tools and applications a practical Linux configuration may require.

Being able to execute code from external RAM is, thus, a pre-requisite for running uClinux on the LPC1788. This however is not an issue that is specific to uClinux only. Up to 512 KBytes of the on-chip Flash may be sufficient for some embedded configurations however for an application that requires "features", fitting all code that is needed into the integrated Flash may be a challenge. An obvious solution here would be to run some code from external RAM.

The LPC1788 memory map allocates the address region of 0xA0000000-0xDFFFFFFF to dynamic memory devices. Using an SDRAM device may indeed be a practical implementation option for those LPC1788 designs that require external RAM to run code from - SDRAM provides a reasonable compromize for configurations where high density, low cost and performance are all requirements.

Here comes the issue however. The Cortex-M3 memory map, to which LPC1788 of course adheres, defines 0xA0000000-0xDFFFFFFF as a "nonexecutable external device" region. In other words, an attempt to execute code from an SDRAM device results in an exception, as long as the default memory map is in action.

The solution is to use the Cortex-M3 Memory Protection Unit (MPU). The MPU sets up the protection and memory attributes by defining the default memory map as a number of regions. Up to eight regions of varying size can be defined, each with its own protection and memory attributes.

To return to the specific uClinux implementation, before passing control to the Linux kernel loaded into external RAM, the U-Boot firmware enables the MPU and defines a single region allowing read/write/execute accesses to the entire 4G of the memory space. This allows running code from everywhere in the memory space, including "external devices" that reside in the 0xA0000000-0xDFFFFFFF region.

The described approach has been successfully validated in Emcraft Systems' port of uClinux for LPC1788.