nuttx/mm
2014-09-02 11:21:23 -06:00
..
bin Changes for ZDS-II ez80 build 2013-11-28 17:47:03 -06:00
kbin Changes for ZDS-II ez80 build 2013-11-28 17:47:03 -06:00
ubin Changes for ZDS-II ez80 build 2013-11-28 17:47:03 -06:00
.gitignore Changes for ZDS-II ez80 build 2013-11-28 17:47:03 -06:00
Kconfig Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
kmm_addregion.c mm: Break up mm_user.c and mm_kernel.c into separate files for better symmetry 2014-08-31 11:46:47 -06:00
kmm_brkaddr.c Add low-level memory management hooks that will be needed to support brk() and sbrk() 2014-08-31 14:42:45 -06:00
kmm_calloc.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
kmm_extend.c Add low-level memory management hooks that will be needed to support brk() and sbrk() 2014-08-31 14:42:45 -06:00
kmm_free.c Rename kfree to kmm_free for consistency with other naming conventions 2014-08-31 17:04:02 -06:00
kmm_heapmember.c mm: Break up mm_user.c and mm_kernel.c into separate files for better symmetry 2014-08-31 11:46:47 -06:00
kmm_initialize.c mm: Break up mm_user.c and mm_kernel.c into separate files for better symmetry 2014-08-31 11:46:47 -06:00
kmm_kernel.c mm: Break up mm_user.c and mm_kernel.c into separate files for better symmetry 2014-08-31 11:46:47 -06:00
kmm_mallinfo.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
kmm_malloc.c Rename kmalloc to kmm_malloc for consistency 2014-08-31 17:26:36 -06:00
kmm_memalign.c Rename kmemalign to kmm_memalign for consitency with other naming 2014-08-31 14:57:31 -06:00
kmm_realloc.c Rename kmemalign to kmm_memalign and krealloc to kmm_realooc for consistency with other naming 2014-08-31 15:27:37 -06:00
kmm_sbrk.c Completes the implementation of sbrk() (untested) 2014-09-01 10:46:51 -06:00
kmm_sem.c mm: Break up mm_user.c and mm_kernel.c into separate files for better symmetry 2014-08-31 11:46:47 -06:00
kmm_zalloc.c Reanem kzalloc to kmm_zalloc for consistency 2014-08-31 17:34:44 -06:00
Makefile Completes the implementation of sbrk() (untested) 2014-09-01 10:46:51 -06:00
mm_addfreechunk.c Add support for multiple heaps 2013-03-08 20:36:18 +00:00
mm_brkaddr.c Completes the implementation of sbrk() (untested) 2014-09-01 10:46:51 -06:00
mm_calloc.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
mm_extend.c Add low-level memory management hooks that will be needed to support brk() and sbrk() 2014-08-31 14:42:45 -06:00
mm_free.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
mm_gran.h include/nuttx/pgalloc.h and mm/mm_pgalloc.c: Add a simple page allocator based on the existing NuttX granule allocator. I am not certain if the granule allocator is sufficiently deterministic for long range use, but it gets get a page allocator in place for testing very quickly. 2014-08-23 16:37:16 -06:00
mm_granalloc.c include/nuttx/pgalloc.h and mm/mm_pgalloc.c: Add a simple page allocator based on the existing NuttX granule allocator. I am not certain if the granule allocator is sufficiently deterministic for long range use, but it gets get a page allocator in place for testing very quickly. 2014-08-23 16:37:16 -06:00
mm_grancritical.c New file missed in last check-in 2012-09-12 15:21:26 +00:00
mm_granfree.c Misc fixes and optimizations for the granule allocator 2012-09-12 17:55:03 +00:00
mm_graninit.c Bugfixes.. still integrating SAMA5 ELF with address environment 2014-08-25 15:27:58 -06:00
mm_granmark.c gran_reserve(): Add a new function to reserve unallocatable regions in the granule heap 2014-08-23 12:43:21 -06:00
mm_granreserve.c include/nuttx/pgalloc.h and mm/mm_pgalloc.c: Add a simple page allocator based on the existing NuttX granule allocator. I am not certain if the granule allocator is sufficiently deterministic for long range use, but it gets get a page allocator in place for testing very quickly. 2014-08-23 16:37:16 -06:00
mm_initialize.c More trailing whilespace removal 2014-04-13 14:32:20 -06:00
mm_mallinfo.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
mm_malloc.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
mm_memalign.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
mm_pgalloc.c Rename CONFIG_NUTTX_KERNEL to CONFIG_BUILD_PROTECTED; Partially integrate new CONFIG_BUILD_KERNEL 2014-08-29 14:47:22 -06:00
mm_realloc.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
mm_sbrk.c sbrk() need to initialized the memory manager on the first call 2014-09-02 08:05:11 -06:00
mm_sem.c Cosmetic changes 2014-05-28 14:09:58 -06:00
mm_shrinkchunk.c Add support for multiple heaps 2013-03-08 20:36:18 +00:00
mm_size2ndx.c Add support for multiple heaps 2013-03-08 20:36:18 +00:00
mm_zalloc.c Remove CONFIG_MM_MULTIHEAP. Non-multiheap operation is no longer supported 2014-08-31 10:54:55 -06:00
README.txt Add power management register defintions and clock control logic for the SAM4L 2013-06-05 13:35:19 -06:00
umm_addregion.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_brkaddr.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_calloc.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_extend.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_free.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_initialize.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_mallinfo.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_malloc.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_memalign.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_realloc.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_sbrk.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_sem.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00
umm_zalloc.c Space at the beginning of the process data space is now reserved for user heap management structures. In the kernel build mode, these heap structures are shared between the kernel and use code in order to allocate user-specific data. 2014-09-02 11:21:23 -06:00

mm/README.txt
=============

This directory contains the NuttX memory management logic.  This include:

1) Standard Memory Management Functions:

     The standard memory management functions as prototyped in stdlib.h as
     specified in the  Base definitions volume of IEEE Std 1003.1-2001.  This
     include the files:

     o Standard Interfaces: mm_malloc.c, mm_calloc.c, mm_realloc.c,
       mm_memalign.c, mm_free.c
     o Less-Standard Interfaces: mm_zalloc.c, mm_mallinfo.c
     o Internal Implementation: mm_initialize.c mm_sem.c  mm_addfreechunk.c
       mm_size2ndx.c mm_shrinkchunk.c, mm_internal.h
     o Build and Configuration files: Kconfig, Makefile

   Memory Models:

     o Small Memory Model.  If the MCU supports only 16-bit data addressing
       then the small memory model is automatically used.  The maximum size
       of the heap is then 64K.  The small memory model can also be forced
       MCUs with wider addressing by defining CONFIG_SMALL_MEMORY in the
       NuttX configuration file.
     o Large Memory Model.  Otherwise, the allocator uses a model that
       supports a heap of up to 4G.

     This implementation uses a variable length allocator with the following
     properties:

     o Overhead:  Either 8- or 4-bytes per allocation for large and small
       models, respectively.
     o Alignment:  All allocations are aligned to 8- or 4-bytes for large
       and small models, respectively.

   Multiple Heaps:

     This allocator can be used to manage multiple heaps (albeit with some
     non-standard interfaces).  A heap is represented by struct mm_heap_s
     as defined in the file include/nuttx/mm.h.  To create another heap
     instance, you would allocate a heap structure, most likely statically
     in memory:

       include <nuttx/mm.h>
       static struct mm_heap_s g_myheap;

     Then initialize the heap using:

       mm_initialize(&g_myheap, myheap_start, myheap_size);

     Where mm_initialize() and all related interfaces are prototyped in the
     header file include/nuttx/mm.h.

     After the new heap instance has been initialized, it can then be used
     with these almost familiar interfaces: mm_malloc(), mm_realloc(), mm_free(),
     etc.  These are 'almost familiar' because they are analogous of the
     standard malloc(), realloc(), free(), etc. except that they expect a
     reference to the initialized heap structure as the first parameter.

     In fact, the standard malloc(), realloc(), free() use this same mechanism,
     but with a global heap structure called g_mmheap.

2) Granule Allocator.

     A non-standard granule allocator is also available in this directory  The
     granule allocator allocates memory in units of a fixed sized block ("granule").
     Allocations may be aligned to a user-provided address boundary.

     The granule allocator interfaces are defined in nuttx/include/nuttx/gran.h.
     The granule allocator consists of these files in this directory:

       mm_gran.h, mm_granalloc.c, mm_grancritical.c, mm_granfree.c
       mm_graninit.c

     The granule allocator is not used anywhere within the base NuttX code
     as of this writing.  The intent of the granule allocator is to provide
     a tool to support platform-specific management of aligned DMA memory.

     NOTE: Because each granule may be aligned and each allocation is in
     units of the granule size, selection of the granule size is important:
     Larger granules will give better performance and less overhead but more
     losses of memory due to quantization waste.  Additional memory waste
     can occur from alignment;  Of course, heap alignment should no be
     used unless (a) you are using the granule allocator to manage DMA memory
     and (b) your hardware has specific memory alignment requirements.

     The current implementation also restricts the maximum allocation size
     to 32 granules.  That restriction could be eliminated with some
     additional coding effort, but currently requires larger granule
     sizes for larger allocations.

   General Usage Example.

     This is an example using the GCC section attribute to position a DMA
     heap in memory (logic in the linker script would assign the section
     .dmaheap to the DMA memory.

        FAR uint32_t g_dmaheap[DMAHEAP_SIZE] __attribute__((section(.dmaheap)));

     The heap is created by calling gran_initialize.  Here the granule size
     is set to 64 bytes and the alignment to 16 bytes:

       GRAN_HANDLE handle = gran_initialize(g_dmaheap, DMAHEAP_SIZE, 6, 4);

     Then the GRAN_HANDLE can be used to allocate memory (There is no
     GRAN_HANDLE if CONFIG_GRAN_SINGLE=y):

       FAR uint8_t *dma_memory = (FAR uint8_t *)gran_alloc(handle, 47);

     The actual memory allocates will be 64 byte (wasting 17 bytes) and
     will be aligned at least to (1 << log2align).