Using dynamic RAM with uClinux on LPC1788

[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.

[lpcware]

Content originally posted in LPCWare by Vladimir Khusainov on Fri Feb 10 04:30:33 MST 2012
Running code from external RAM is of course slower than running code from the integrated Flash of Cortex-M3.

It is possible to build the uClinux kernel in such a way that kernel components of user's choice would be linked into an address region corresponding to the built-in Flash (and hence run from embedded Flash), while the rest of the kernel code would run from external RAM.

Another possibility is to put a romfs filesystem into embedded Flash and run critical user-space applications from there in XIP (eXecute-In-Place) mode.

Even without those optimizations though, uClinux appears to be sufficiently performant on LPC1788. I invite you to watch the "Linux LPC17xx: Shell, Networking and Journalled Flash Filesystem" at www.emcraft.com. It shows uClinux running on Embedded Artists' LPC1788 board from a 32 MBytes SDRAM device ... At the user shell level, when running various Unix commands, there is no sluggishness or delays one may fear when running software on a slow microprocessor.

Of course performance needs to be measured against requirements of a specific application however I would think that uClinux on an 120MHz LPC1788 running from external RAM device should be performant enough for kind of things that are expected from a Cortex-M3 based device.

As they say, "whatever works".

[lpcware]

Content originally posted in LPCWare by EReyes on Wed Feb 08 19:31:05 MST 2012
Cortex-M3 devices with external memory interfaces typically experience a performance loss when executing code out of external memory. Is there any reference about this for the LPC1788?