reserved-memory node and linking it to consumer drivers via phandles. This approach ensures that specific physical address ranges are excluded from the general system allocator, preventing fragmentation and guaranteeing availability for critical subsystems like video buffers or secure world communications.
Understanding Reserved Memory in Embedded Systems
In embedded Linux environments, hardware components often require access to specific regions of physical RAM that must not be touched by the general-purpose memory manager. The Linux kernel provides a mechanism called CMA (Contiguous Memory Allocator) for dynamic allocation, but some devices need static, fixed reservations at boot time. These reservations are defined in the device tree, which is parsed early during the kernel initialization process. By reserving memory explicitly, you prevent the kernel from allocating these pages for other purposes, ensuring that DMA-capable devices have guaranteed access to contiguous physical memory. This is particularly crucial for systems with limited RAM where efficient memory management is vital for stability and performance.Defining Reserved Memory Regions in Device Tree
The primary method for configuring reserved memory is through the Device Tree Source (DTS) file. You must create areserved-memory node within the root of your device tree. Inside this node, you define child nodes that specify the size and alignment of the memory region. Each child node should include the reg property to define the base address and size, and the compatible property to identify the type of reservation. For example, you might define a region for a framebuffer or a secure monitor. It is important to note that modern kernels do not use deprecated parameters like memreserve; instead, they rely on the structured DTS definitions. Ensure that the addresses used do not overlap with existing hardware mappings or the kernel image itself.
```dts
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
my_reserved_region: buffer@80000000 {
reg = <0x80000000 0x1000000>;
no-map;
};
};
```
In this example, a 16MB region starting at address 0x80000000 is reserved. The no-map flag indicates that this memory should not be mapped into the kernel's virtual address space automatically, which is often desired for security or specific driver handling. The label my_reserved_region creates a phandle that can be referenced by other nodes in the device tree.
Linking Consumer Drivers to Reserved Memory
Simply defining a reserved region is not enough; you must also tell the relevant driver how to use it. This is done by adding a reference to the reserved memory node in the device node of the consumer driver. Using the phandle created earlier, you add a property such asmemory-region or a vendor-specific property that points to the reserved node. This linkage allows the driver to request the reserved memory during its probe function. Without this connection, the memory remains reserved but unused, leading to wasted resources. Proper configuration ensures that the driver can safely allocate buffers from this pre-allocated pool, avoiding runtime allocation failures.
```dts
&video_encoder {
memory-region = <&my_reserved_region>;
};
```
This snippet shows how the video_encoder device accesses the previously defined memory region. The driver code will typically call functions like of_reserved_mem_lookup() or similar APIs to retrieve the physical address and size of the reserved block. This method is robust and standard across many embedded platforms supported by the mainline Linux kernel.
Verifying Reservations at Boot Time
After compiling and flashing the updated device tree, verify that the memory has been correctly reserved by checking the kernel log messages during boot. Look for lines indicating that the reserved memory region has been identified and marked as unavailable for general use. Tools like/proc/iomem can also provide insights into the memory map, although reserved regions may not always appear there depending on the no-map flag. If the driver fails to initialize due to memory issues, ensure that the phandle reference is correct and that the address range does not conflict with other hardware. Debugging these issues often requires comparing the device tree against the hardware manual to confirm valid address ranges.
For more context on memory management, see [Why would a process use more memory running on one OS compared to another?](/news/1036543/process-memory-usage-on-different-operating-systems).
Frequently Asked Questions
How do I check if a memory region is already reserved?
You can inspect the kernel boot logs for messages about reserved memory regions. Additionally, examining /proc/iomem after boot can show mapped regions, though strictly reserved areas with no-map might not appear there.
What happens if two drivers claim the same reserved memory?
The kernel will typically fail to probe the second driver or report an error because the memory resource is already in use. You must ensure that each reserved memory node is referenced by only one consumer or implement sharing logic within the driver code.
Can I change reserved memory size without recompiling the kernel?
No, the device tree source must be compiled into a binary blob (DTB) and flashed to the storage medium. Changes to the DTS require a rebuild of the device tree and a reboot to take effect.
Is CMA a better alternative to static reservation?
CMA is generally preferred for flexible allocations, but static reservation is necessary for hardware that requires physically contiguous memory at boot time or for security-sensitive regions that must never be swapped or moved.
How do I debug a driver failing to find reserved memory?
Check the device tree syntax for correct phandle references and ensure the reserved-memory node is properly defined in the root. Use dmesg to look for errors related to memory allocation or invalid device tree properties.