1.1.1 Reason for the Exponential Acceptance of Linux

Linux is one of the most successful products of the open-source software movement driven by the GNU. The availability of the entire source code of the Linux kernel, along with its very visionary licensing approach, has been driving the success of Linux for more than two decades. Since its source code was publicly available immediately after its origination in the early 1990s, many people became Linux experts, creating and adding useful features to it. Under the guidance of strictly disciplined Linux source code maintenance, Linux became an extremely feature-rich and stable operating system within a couple of years of its inception.

Another major reason for the success of Linux was its “free” availability. Because of an existing monopoly by the de facto leader of desktop operating systems, desktop vendors were looking for options to remove the existing omnipresent operating system. In the late 1990s, desktop PCs started to become a commodity. This put pressure on desktop vendors to reduce costs so that the global availability of desktops could be increased. Linux-based desktops were less costly as Linux was freely available for commercial deployment.

Another movement progressed in parallel—in the domain of research. Supercomputer developers wanted an operating system that they could personally tweak to meet their requirements. Linux came to the rescue. All these factors helped make Linux more feature rich, stable, and popular.

1.1.2 Linux and Embedded Systems

Before Linux, commercial operating systems dominated the entire embedded world. In the late 1990s and early 21st century, there were a good number of embedded devices that needed highly feature-rich operating system to support their many features. Prime uses of such products were enterprise and home routers and set-top boxes. We will consider home routers to explain how the transition from commercial operating systems to Linux happened. Routers were supposed to provide networking layers for Ethernet/ATM/Wifi interfaces along with offering various flavors of network security. These embedded devices used commercial operating systems. Commercial operating systems had small footprints and needed very small RAM and flash storage—these reasons were enough for commercial operating systems to capture the embedded market.

Once desktops started arriving in households, the need for home routers became a necessity. The burden of cost reduction started building on home router providers. After the dot-com bubble burst, enterprise routers also started facing cost pressures. One of the major areas that could offer significant cost reduction was the operating system. Vendors were paying heavy royalties to commercial operating system providers. Linux was not feasible for routers because of its big memory footprint. Constant reductions in the cost of flash storage and SDRAM in the early 21st century made it feasible to accommodate Linux within routers [3]. Soon after this, an open-source forum, named OpenWrt, was set up, focusing on Linux deployments in Wi-Fi routers, in 2004.

The remainder of this chapter focuses on the important features of Linux that mean it can be used in various embedded-world use cases.

1.3.1 Portability

Linux is a highly portable operating system, something that is very clear from the list of supported CPU architectures (see subsequent text). Most parts of the core kernel (that includes scheduler, memory management, device driver frameworks, interrupt framework) are written in such a way that can work on any underlying CPU. In addition to the core kernel, most of the drivers for onboard and on-chip devices run without any modifications on any CPU architecture.

1.3.2 Support of a Wide Variety of Peripheral Devices

Linux provides excellent support for various communication interfaces, e.g., Ethernet, 802.11 Wi-Fi, Bluetooth, ATM. All popular storage devices are supported: USB storage, Secure Disk (SD), SATA, SSD, SCSI, RAID, etc. For onboard connectivity, it provides support for I2C, SPI (serial peripheral interface), PCIe, etc.

In summary, if you are planning to use any existing on-chip or onboard hardware in your system, it’s very likely that its stable driver already exists in Linux. Device drivers contribute 60% of Linux source code—24 million lines of code in Linux kernel 4.19.

1.3.3 Complete Network Stack Solution

For end-to-end connectivity, Linux has a very rich network stack: TCP/UDP, IPv4/v6. Linux has a very feature-rich network stack that is also optimized for throughput performance.

Most of today’s high-speed networking devices have network traffic accelerators—these accelerators perform checksum, TCP functions, and even bridging-routing functions. Linux network and device driver frameworks easily support these proprietary accelerators.

1.3.4 Variety of Task Schedulers

The job of task schedulers in operating systems is to execute a task at an appropriate moment. There are scenarios in which a use case demands a specific way of task scheduling. In case of a multiuser system, the CPU should be allocated in a round-robin way to each of the users so that no user feels excessive delays in completion of his or her tasks.

In the case of a desktop with a single user, if the user is running multiple tasks, such as a browser, a word processor, or a print job, they want to see progress in each of these jobs, in parallel; in addition to this the user wants the mouse pointer to immediately change its position on the desktop monitor when the mouse is moved on a mouse mat.

In real-time systems, the task schedule must ensure that real-time jobs finish their work within bounded timelines. For example, in a cellular 4G world, the base station is supposed to transmit the “subframe” exactly at the time defined in the 3GPP specifications. This transmission can only afford delays of less than a microsecond—if the base station incurs higher delays it causes system failure.

For each of the above examples, a custom task scheduler is required. Linux provides task schedulers for each of the above scenarios, and more.

1.3.5 Security

Security is a prime concern when everything is connected—be it the security of the connected device or the security of the data that is being processed by the device. Linux (with the help of underlying CPU architecture) ensures that a device boots with genuine software and also provides enough hooks that prevent the execution of undesired software.

For secure data transfers, Linux provides for the support of security protocols like Ipsec.

Another aspect of security are the firewalls in gateway/router devices. Linux has performance-optimized solutions to ensure that internal/LAN users are not impacted by malicious activities initiated outside of the LAN.

Not only does Linux provide a highly optimized stack to enable the above but it also has a good framework to support proprietary crypto hardware accelerators.

1.3.6 User Space Drivers

Traditionally, device drivers were written to execute in the Linux kernel. Some of the drivers need lots of information to be exchanged with their corresponding user space software. For example, a network interface driver must exchange vast volumes of data each second between the kernel and a webserver running in user space. As we will see later in this chapter, this kind of design incurs a huge penalty on CPU horsepower—Linux provides a user space driver framework where the network driver executes in user space.

1.3.7 Endianness

Some of the product vendors want to use the same onboard and/or on-chip devices on different CPU architectures. For example, a vendor may want to use the same USB device in two separate product lines, one that uses big-endian CPUs and other that uses little-endian CPUs. Maintaining two separate drivers for the same device to handle this situation is a costly proposition. The same scenario arises when one product line uses 32-bit CPU architecture and another uses 64-bit CPU architecture.

The Linux device driver framework and coding practices ensure that when a new driver is added in Linux, endianness and CPU bus sizes of devices do not demand modifications in the drivers.

1.3.8 Debuggability

The success of a design depends on how easily it can be debugged. Debugging doesn’t only mean debugging of the hang/crash of software, it also refers to finding places where optimizations can be made for better performance. Linux has several kinds of debugging mechanisms available to developers for various types of issues in networking, file systems, synchronization mechanisms, device drivers, Linux initialization, and schedulers. The debug features allow developers to inspect what is happening in the system in online mode (while Linux is running) and in offline mode (i.e., take the logs and review them separately).

1.4.1 Free of Cost

Linux is freely available to everyone—individuals or commercial/noncommercial companies. One can use it as it is; one can modify and sell the modified Linux—no money needs to be paid to Linux or anyone else. All versions of Linux are free for use—long-term stable (LTS) versions or non-LTS versions.

Note that it’s not only the Linux kernel that is free, its entire ecosystem is also free, for example, the GNU toolchain that compiles the Linux kernel, the GDB debugger, and root file systems (buildroot, Yocto, OpenWrt, ubuntu, etc.) are all free.

1.4.2 Time to Market

In today’s competitive market, return on investment (ROI) also depends on how early you bring your product to market. Software development and testing needs a considerable amount of time in terms of product development therefore it’s very important to reduce the software cycle.

Most CPU architectures (old, latest, and upcoming) are generally available in Linux. This means that with Linux you get an operating system that has already been tested for your specific CPU architecture. As mentioned in an earlier section of this chapter, Linux is already deployed in a variety of market segments. This means that required features are likely to be already available in Linux. These aspects reduce the overall product development time.

Other things that reduce time to market include:

1. 1. Quick software team ramp-up. There are many white papers, articles, and videos available on Linux that can be used to quickly ramp-up a project.
2. 2. Linux has a vast open-source community. If software developers face an issue, they can generally do a search on the web and most of the time find some forum or group that has already discussed/solved a particular issue—or can assist through web-posts or chat.
3. 3. Linux’s debugging is very feature rich. It can easily help localize problems.

1.4.3 No “Vendor Lock-in”

If a product manufacturer deploys a commercially available operating system in a product, the product manufacturer will have to customize the application software for that particular operating system. Additionally, the software team within the product development organization will have to create expertise in that particular operating system.

Now, if the product manufacturer has to come up with a new product, they will have to use the same commercial operating system since their workforce is already trained in that particular operating system. Even if the product needs a different operating system due to its specific needs, the product manufacturer will prefer to reuse their trained workforce to reduce product development costs. If the manufacturer decides to change the operating system, they will have to retrain the workforce and recustomize the application software for a new operating system.

On the other hand, the vendor of the commercial operating system may take undue advantage of the dependence of the product manufacturer on this operating system.

With Linux, there is no “lock-in” with any operating system vendor. This is because Linux expertise can help in tailoring Linux for different use cases. Therefore retraining of the workforce is not required. Also, there are many software vendors that offer Linux-based software—if a product manufacturer wants to outsource software work, they will have variety of choices for selecting software providers.

1.4.4 Highly Stable Operating System

The Linux open-source community is supposed to be one of the biggest open-source communities. Every new software feature (whether a driver, new framework, new scheduler) undergoes strict reviews by the community. These reviewers and repo maintainers are mostly subject-matter experts and they ensure that new proposed code changes comply with all the rules set by Linux.

Once a Linux version is released, it’s tested by several members in the community. Each day, the community keeps adding patches to the mainline Linux and each night the “Linux-next” is tested on a wide range of platforms touching all CPU architectures and almost all features.

The outcome of this effort is that every version of Linux is very stable.

1.4.5 Low Maintenance

There are two aspects of software maintenance that this section describes and in both cases the product vendor achieves low-cost maintenance.

1.5.1 Linux Kernel Components

The Linux kernel is composed of several components and in a typical Linux configuration all these components are essential.

1.5.1.1 Device Driver Framework

75% of overall Linux code is for device drivers. This is not a surprise since Linux is ported on a wide range of systems and this deployment has led to the inclusion of drivers of most devices on such systems. These devices include high-complexity hardware like Ethernet and graphics as well as low-complexity devices like EEPROM. To ensure all varieties of devices are plugged into Linux properly, Linux has a device driver framework.

Linux has a generic driver infrastructure that provides a base framework for all kinds of devices. For example, a “struct device” is required by all drivers to help driver modules organize generic resources like interrupts, the bus-type on which such devices exist, and hooks for power management.

The generic driver framework provides further frameworks for each type of device. For example, there is an Ethernet device framework that provides for common jobs associated with a typical Ethernet driver. Any hardware that has Ethernet can leverage from this framework: the actual Ethernet driver becomes smaller in size due to the Ethernet driver framework. Also, the author of an Ethernet device driver does not need to worry about exactly how the driver will exchange Ethernet frames with Linux’s network stack.

Fig. 3 shows only a few of the many example device driver frameworks that exist. There are many more in the kernel. Details can be seen in the Linux source tree (visit/drivers at top level directory of the Linux tree).

1.6.1 Kernel Compilation

GNU GCC toolchain, an open-source compilation toolchain, is generally used to compile and link the Linux kernel to all popular CPU architectures. You may also use a commercial toolchain.

Before you compile the kernel, you should configure the kernel to match your CPU architecture by running “make menuconfig” at the top-level directory of the Linux kernel tree on your build machine. This command allows the user to select the CPU architecture of the target, kernel configuration (e.g., virtual memory page size and endianness), protocol stack configuration (e.g., IPv6/v6, firewall), and hardware devices that are present in the system—you may include, exclude, or customize kernel features using “make menuconfig.” Subsequent execution of “make” compiles and links the kernel.

1.6.2 Root Filesystem

The Linux kernel alone is not very interesting—it’s an operating system without any user-friendly shell interface. Root filesystem provides user-friendly applications, including shells, management applications for devices (e.g., ethtool for Ethernet interfaces), kernel configurations (e.g., “top” to check CPU usage), network stacks (e.g., “ip” for IPv4/IPv6-related configuration), and runtime libraries. Based on user choice, it may include a compiler toolchain and a gdb debugger as well!

There are several ways in which users can generate a root filesystem. This section describes Yocto, one of the most popular frameworks for generating a root filesystem.

1.7.1 Low Memory Footprint

Low-end embedded devices support a limited set of features. To reduce the cost of these products they have the lowest possible memory resources. Full-blown Linux needs several megabytes of persistent storage (i.e., flash or other media) and several hundred bytes of runtime space (i.e., RAM). It is generally the Linux kernel and root filesystem that take up almost all the memory spaces in a typical embedded system.

1. 1. Optimizing Linux. Linux can easily be fine-tuned to meet these limited resources so that it can fit in much smaller persistent and runtime memories. At compiling time, a designer can specify desirable and undesirable features using “make menuconfig.” Linux classifies all features in a hierarchical order that allows a designer to either completely remove a feature or remove only part of a feature. For example, you can remove the complete network stack, or just remove IPv6 and retain IPv4. Even within IPv4 you can pick and choose specific features. The compiled Linux image will contain only the selected features.
2. 2. Optimizing the root filesystem. This is the biggest memory consumer in most embedded systems. Yocto is the most popular root filesystem builder for Linux-based embedded system products and a full Yocto root filesystem may take up to several hundreds of megabytes of persistent storage. Yocto provides designers with a customization option that allows making a small root filesystem. This is described in more detail later in the chapter.

1.7.2 Boot Performance

When you turn on your home router, you want it to become operational instantly. This is where boot performance comes in, that is, how quickly the software¹ completes all of its initialization. To reduce the boot time, the first thing that a software designer must do is remove undesired software components as described in the previous text.

The next phase of optimization is product specific. Linux starts its multitasking subsystem (i.e., scheduler) very early in its Linux init: boot-critical jobs should be implemented in separate sets of threads and the remainder of jobs should be placed in other threads. If some part of the init system is CPU intensive, and you are operating a multicore system, then you can implement such functions in separate kernel threads and distribute these threads to separate cores. Modules, that are not important for the init system should be moved to separate kernel threads and assigned low priority.

1.7.3 High Throughput Performance

In some categories of products performance is critical. For example, a router is generally expected to route network traffic at Ethernet line rates; similarly, a storage device (USB pen drive) is expected to read/write files as early as possible. There are several options available in Linux that can be enabled at compile and/or runtime to achieve maximum throughput performance.

1.7.4 Latencies

Real-time systems need bounded latencies for handling some of events. Linux, using its default configuration, cannot ensure bounded latencies. The default scheduling scheme in Linux is a sort of nonpreemptive round-robin—if some task is running and a higher priority task becomes runnable due to some event, this new high-priority task will have to wait for the existing low-priority task to complete its scheduling quota. Linux provides some kernel configurations (CONFIG_PREEMPT…) to make scheduling more deterministic.

If you want Linux to be completely deterministic during scheduling, to ensure bounded latencies, you can use another open-source project “PREEMPT_RT.” This is a decade-old project for making Linux an “RTOS”—gradually features of the PREEMPT_RT projects are moving into mainline Linux.

1.8.1 Linux Versions

Like other open-source communities, Linux developers send, review, and approve features and bug fixes via email. These changes are sent to the community in the form of a “patch” or “patch-set.” Every 2 to 3 months, a Linux kernel maintainer adds the approved features and fixes to the existing kernel and comes up with a candidate release for the new Linux kernel version. Once the release candidate is found to be stable enough, a formal Linux kernel release is announced.

Linux kernel version numbers use a template like “a.b.c.,” where a, b, and c are natural numbers. For example, the latest Linux version as of October 2018 is 4.18.0. These Linux versions are also called stable kernel releases.

1.8.2 Long-Term Support (LTS) Linux Version

These are the Linux versions that are maintained by Linux maintainers over the long term (approximately 2 years). Every year, one of the stable Linux releases is chosen as an LTS Linux version.

1.8.3 Related Open-Source Communities

The open-source community has created several forums to promote open-source projects, some of these are working around Linux. This section describes a couple of these forums.

2.2.1 Multiple Boot Source Support

A boot source is a nonvolatile onboard memory from where hardware loads U-Boot into preinitialized memory or transfers control directly for in-place execution (also known as XIP). Later sections in this chapter will share further details on this topic.

U-Boot supports booting from NOR, Serial NOR, SD/MMC, DSPI, NAND, etc.—some systems support multiple boot sources in the same U-Boot executable image while some systems support only one boot source in one U-Boot executable. Once U-Boot executes, it can load next-level images from a desired boot source—U-Boot makes this decision based on the user configuration saved in its “environment variables” (see later sections of this chapter for more on environment variables).

2.2.2 Shell (User Interface)

U-Boot provides a shell (also known as a command-line interface) over its serial interface which lets users manage various U-Boot attributes (e.g., which boot source to use for loading next-level images). This command-line interface provides lots of commands depending upon compile-time configuration. Major supported commands are flash read/write, networking (mdio, dhcp, tftp, ping, etc.), i2c, sdhc, usb, pcie, sata, and memory operations. Users can use these commands to configure the system and access I/O devices. Memory tests can also be initiated using the U-Boot shell.

U-Boot also supports commands for the management of environment variables and the display of runtime system configuration.

2.2.3 Environment Variables

These variables control the hardware configuration and boot behavior. Environment variables are usually stored on nonvolatile memory—they are given a default value at compile time, based on a user’s choice for that specific system. Users can also modify these variables at runtime (using U-Boot shell) and save them to nonvolatile memory.

Runtime control and configuration environment variables consist of variables such as the IP address, UART baud rates, Linux bootargs, system MAC address, and bootcmd.

Boot-time control and configurations changes the way devices boot. For example, SDRAM configurations (ECC on/off, type of interleaving) modifies the way SDRAM is initialized during boot-sequence.

2.2.4 Scripts

The scripting feature of U-Boot allows storing multiple command sequences in a plain text file. This plain text file, can be run at the U-Boot user shell by simply invoking the “source” command followed by the script’s name. This allows the user to run multiple command sequences in one go.

2.2.5 Stand-Alone Applications

U-Boot supports “stand-alone” applications. These applications can be loaded dynamically during U-Boot execution by bringing in RAM via network or nonvolatile memory. These stand-alone applications can have access to the U-Boot console, I/O functions, and memory allocations.

Stand-alone applications use a jump table, provided by U-Boot, to use U-Boot services.

2.2.6 Operating System Boot Commands

The U-Boot command “bootm” allows booting of next-level executable images (typically an operating system) preloaded in RAM—an operating system image can be obtained via RAM from a network or from onboard nonvolatile memory.

U-Boot also supports file systems. This way, rather than requiring the data that U-Boot will load to be stored at a fixed location on the storage device, U-Boot can read the file system on nonvolatile storage to search for and load specific files (e.g., the kernel and device tree). U-Boot supports all commonly used file systems like btrfs, cramfs, ext2, ext3, ext4, FAT, FDOS, JFFS2, Squashfs, UBIFS, and ZFS.

An operating system boot command is intelligent enough to perform all required prerequisites for operating system boot, such as device tree fix-up, required operating system image and file system uncompressing, and architecture-specific hardware configuration (cache, mmu). Once all prerequisites are completed, it transfers control to the operating system.

2.2.7 Autoboot

This feature allows a system to automatically boot to a next-level image (such as Linux or any user application) without the need for user commands. If any key is pressed before the boot delay time expires, U-Boot stops the autoboot process, provides a U-Boot shell prompt, and waits forever for a user command.

2.2.8 Sandbox U-Boot

The “sandbox” architecture of U-Boot is designed to allow U-Boot to run under Linux on almost any hardware. It is achieved by building U-Boot as a normal C application with a main () and normal C libraries. None of U-Boot’s architecture-specific code is compiled as part of the sandbox U-Boot.

The purpose of running sandbox U-Boot under Linux is to test all the generic code—code that is not specific to any one architecture. It helps in creating unit tests which can be run to test upper level code.

The reader is referred to U-Boot documentation for further information on sandbox U-Boot.

2.4.1 Single-Stage Boot Loader

If hardware (SoC or board) has XIP (eXecute In Place) nonvolatile (NV) storage, single-stage U-Boot architecture is preferred. In this architecture the entire U-Boot software is compiled into a single U-Boot binary. This single U-Boot binary is stored in XIP NV memory. During a system boot, the hardware transfers control to the abovementioned XIP memory; consequently, U-Boot executes from this memory and configures other desired hardware blocks. In the last stage of execution, U-Boot relocates to a bigger RAM. If the bigger RAM is SDRAM, then U-Boot first configures the SDRAM hardware and then relocates itself from the NV memory to RAM. A detailed flow diagram of this process is given in Fig. 4.

The relocated U-Boot has access to the complete SDRAM, allowing the initialization of the complete system, including drivers, such as USB, PCIe, SATA, and Ethernet. Once all the initialization is completed, U-Boot enters an infinite loop, waiting for user input. Further execution is controlled by the user. Alternatively, relocated U-Boot loads next-level images.

The approximate size of the single-stage boot loader for NXP’s QorIQ LS2080ARDB platform is 700 kB.

In terms of design considerations for single-stage boot loader architecture, U-Boot performs some of the tasks before relocation and the remaining tasks after relocation. Execution from XIP NV memory is generally much slower than execution from SRAM or SDRAM. Hence, the user will have to carefully design what should be included in the phase before relocation.

2.4.2 Two-Stage Boot Loader

If the hardware (SoC or board) does not have XIP (eXecute In Place) nonvolatile (NV) storage but has internal SRAM, then two-stage U-Boot architecture is preferred. In this architecture U-Boot is compiled into two sets of binaries known as SPL (Secondary Program Loader) and U-Boot. Here, the SPL and U-Boot binary are stored in nonvolatile memory (such as SD and SPI).

SPL binary is loaded into internal SRAM by the system’s BootROM. BootROM further transfers control to SPL. SPL, executing from internal SRAM, configures SDRAM. Once SDRAM is configured it copies U-Boot into SDRAM and transfers control to U-Boot. A detailed flow diagram of this process is given in Fig. 5.

Once U-Boot gets control, it initializes some of the hardware components like USB, PCIe, SATA, Ethernet etc. After complete initialization, U-Boot enters an infinite loop, waiting for user input. Further execution is controlled by the user. A detailed flow diagram of this process is given in Fig. 6.

The approximate sizes of the two-stage boot loaders for NXP’s ARMv8 LS2080ardb platforms are ~ 75 kB for SPL and ~ 700 kB for U-Boot.

The beauty of U-Boot is that its size is controlled by the user at compile time. Users can customize its size based on system requirements by removing compile-time config options.

Note: selection of type of boot architecture.

• The type of boot stage loader used for U-Boot depends upon the system’s hardware configurations. If the system’s hardware has XIP (eXecute In Place) flash, like NOR flash, then a single-stage boot loader can be used.
• However, for cases where a system’s hardware does not have XIP (eXecute In Place) memory and has internal RAM of limited size, then the default U-Boot may not be able to fit into the internal RAM. In this case a two-stage boot loader is the best option, i.e., having a small SPL loading normal U-Boot in SDRAM.

FreeRTOS doesn’t have any restrictions on the number of real-time tasks that can be created and the number of task priorities that can be used. Multiple tasks can have the same priorities too.

A task can have one of these states: running, ready, blocked, or suspended.

The scheduling algorithm is based on the configUSE_PREEMPTION and configUSE_TIME_SLICING values in FreeRTOSConfig.h (Table 1).

3.7.2 Low Power

FreeRTOS supports tickless idle mode for low-power implementation. A developer can use the idle task hook to enter low-power state. However, power saving using this method is limited because periodically the tick interrupt will be served, hence exit and entry to low-power mode will be frequent. It may introduce an overhead instead of power saving if the tick interrupt frequency is too high. The FreeRTOS tickless idle mode stops the tick interrupt during an idle task to overcome this issue.

FreeRTOS provides for an idle task hook function which is called from the idle task. An application author can use this hook function to enter the device into low-power mode.

3.7.3 Debugging

FreeRTOS provides a mechanism for stack overflow detection. An application needs to provide the stack overflow hook function with a specific prototype and name. The kernel calls the hook function if the stack pointer has a value outside the valid range.

The FreeRTOS kernel contains different types of trace macros that are defined empty by default. An application writer can redefine these macros according to their need to collect application behavioral data.

3.7.4 IPC and Synchronizations

FreeRTOS supports various intertask communication mechanisms like stream and message buffers, task notifications, queues, and event groups.

FreeRTOS supports many synchronization primitives like binary semaphores, counting semaphores, mutexes, and recursive mutexes.

3.7.5 Memory Management

FreeRTOS supports creating different objects, such as tasks, queues, timers, and semaphores, either by using dynamic memory or by an application provided in static memory.

FreeRTOS supports five dynamic memory allocation implementations, i.e., heap_1, heap_2, heap_3, heap_4, and heap_5, which are in the Source/Portable/MemMang directory. An application writer must include only one of these memory allocation implementations in a project.

heap_1 is the simplest and the only implementation which doesn’t allow freeing of memory. heap_2 allows freeing memory but doesn’t concatenate adjacent free blocks. heap_3 is wrapper around standard "malloc" and "free" interfaces provided by compiler. heap_4 concatenates adjacent blocks to avoid fragmentation. heap_5 allows spanning the heap over multiple nonadjacent memory and concatenates adjacent blocks to avoid fragmentation.

It is also possible to provide your own implementation.