cdocutils.nodes document q)q}q(U nametypesq}q(X developmentqXdebugging-techniquesqXmulti-process-testqXlinux-cma-supportq Xdts configurationq Xwince-configurationq Xbuilding-test-binariesq Xandroid-cma-supportq Xintroduction-linux-cmemqXcmemqNXcommand line configurationqX licensingqXapplication-cleanupqX!test-setup-and-validation-processqXcmem-faqqXapi-testqX configurationqXlinux-configurationqXtranslate-testqXgeneral-purpose-heapsqXbuild-environment-setupquUsubstitution_defsq}qUparse_messagesq]qcdocutils.nodes system_message q)q }q!(U rawsourceq"UU attributesq#}q$(Udupnamesq%]UlevelKUidsq&]Ubackrefsq']Usourcecdocutils.nodes reprunicode q(X1source/linux/Foundational_Components/CMEM.rst.incq)q*}q+bUclassesq,]Unamesq-]UlineKUtypeUINFOq.uUparentq/cdocutils.nodes list_item q0)q1}q2(h"X12) removal via machine's "``.reserve``" function h/cdocutils.nodes bullet_list q3)q4}q5(h"Uh/cdocutils.nodes section q6)q7}q8(h"Uh/hUsourceq9h*Utagnameq:Usectionq;h#}q<(h%]h,]h']h&]q=Ucmemq>ah-]q?hauUlineq@KUdocumentqAhUchildrenqB]qC(cdocutils.nodes title qD)qE}qF(h"XCMEMqGh/h7h9h*h:UtitleqHh#}qI(h%]h,]h']h&]h-]uh@KhAhhB]qJcdocutils.nodes Text qKXCMEMqLqM}qN(h"hGh/hEubaubcdocutils.nodes rubric qO)qP}qQ(h"X IntroductionqRh/h7h9h*h:UrubricqSh#}qT(h&]qUUintroduction-linux-cmemqVah']h%]h,]h-]qWhauh@NhAhhB]qXhKX IntroductionqYqZ}q[(h"hRh/hPubaubcdocutils.nodes paragraph q\)q]}q^(h"XCMEM is an API (`Reference Guide `__) and library for managing one or more blocks of physically contiguous memory. It also provides address translation services (e.g. virtual to physical translation) and user-mode cache management APIs. This physically contiguous memory is useful as data buffers that will be shared with another processor (e.g. for the DSP on an `OMAP3 `__) or a hardware accelerator/DMA (e.g. used by codecs on a `DM365 `__)h/h7h9h*h:U paragraphq_h#}q`(h%]h,]h']h&]h-]uh@K hAhhB]qa(hKXCMEM is an API (qbqc}qd(h"XCMEM is an API (h/h]ubcdocutils.nodes reference qe)qf}qg(h"X`Reference Guide `__h#}qh(UnameXReference GuideUrefuriqiXkhttp://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/latest/docs/html/cmem_8h.htmlh&]h']h%]h,]h-]uh/h]hB]qjhKXReference Guideqkql}qm(h"Uh/hfubah:U referenceqnubhKXH) and library for managing one or more blocks of physically contiguous memory. It also provides address translation services (e.g. virtual to physical translation) and user-mode cache management APIs. This physically contiguous memory is useful as data buffers that will be shared with another processor (e.g. for the DSP on an qoqp}qq(h"XH) and library for managing one or more blocks of physically contiguous memory. It also provides address translation services (e.g. virtual to physical translation) and user-mode cache management APIs. This physically contiguous memory is useful as data buffers that will be shared with another processor (e.g. for the DSP on an h/h]ubhe)qr}qs(h"XB`OMAP3 `__h#}qt(UnameXOMAP3hiX6http://processors.wiki.ti.com/index.php/OMAP3_Overviewh&]h']h%]h,]h-]uh/h]hB]quhKXOMAP3qvqw}qx(h"Uh/hrubah:hnubhKX:) or a hardware accelerator/DMA (e.g. used by codecs on a qyqz}q{(h"X:) or a hardware accelerator/DMA (e.g. used by codecs on a h/h]ubhe)q|}q}(h"X9`DM365 `__h#}q~(UnameXDM365hiX-http://processors.wiki.ti.com/index.php/DM365h&]h']h%]h,]h-]uh/h]hB]qhKXDM365qq}q(h"Uh/h|ubah:hnubhKX)q}q(h"X)h/h]ubeubh\)q}q(h"XUsing its pool-based configuration, CMEM enables users to avoid memory fragmentation, and ensures large physically contiguous memory blocks are available even after a system has been running for very long periods of time.qh/h7h9h*h:h_h#}q(h%]h,]h']h&]h-]uh@KhAhhB]qhKXUsing its pool-based configuration, CMEM enables users to avoid memory fragmentation, and ensures large physically contiguous memory blocks are available even after a system has been running for very long periods of time.qq}q(h"hh/hubaubh\)q}q(h"XIt was originally developed for the `DM644x `__, and has been ported to several Operating Systems (e.g. Linux, WinCE, QNX, Nucleus, Green Hills Integrity, and others). Although generally associated with `Codec Engine `__, it has no dependency on Codec Engine and can be used on its own.h/h7h9h*h:h_h#}q(h%]h,]h']h&]h-]uh@KhAhhB]q(hKX$It was originally developed for the qq}q(h"X$It was originally developed for the h/hubhe)q}q(h"XD`DM644x `__h#}q(UnameXDM644xhiX7http://processors.wiki.ti.com/index.php/Category:DM644xh&]h']h%]h,]h-]uh/hhB]qhKXDM644xqq}q(h"Uh/hubah:hnubhKX, and has been ported to several Operating Systems (e.g. Linux, WinCE, QNX, Nucleus, Green Hills Integrity, and others). Although generally associated with qq}q(h"X, and has been ported to several Operating Systems (e.g. Linux, WinCE, QNX, Nucleus, Green Hills Integrity, and others). Although generally associated with h/hubhe)q}q(h"XP`Codec Engine `__h#}q(UnameX Codec EnginehiX=http://processors.wiki.ti.com/index.php/Category:Codec_Engineh&]h']h%]h,]h-]uh/hhB]qhKX Codec Engineqq}q(h"Uh/hubah:hnubhKXB, it has no dependency on Codec Engine and can be used on its own.qq}q(h"XB, it has no dependency on Codec Engine and can be used on its own.h/hubeubh\)q}q(h"XIt's currently distributed as a component in the `Linux Utils `__ and `WinCE Utils `__ products, which may be included in various Linux and WinCE based SDKs.h/h7h9h*h:h_h#}q(h%]h,]h']h&]h-]uh@K hAhhB]q(hKX1It's currently distributed as a component in the qq}q(h"X1It's currently distributed as a component in the h/hubhe)q}q(h"XM`Linux Utils `__h#}q(UnameX Linux UtilshiX;http://processors.wiki.ti.com/index.php/Linux_Utils_Roadmaph&]h']h%]h,]h-]uh/hhB]qhKX Linux Utilsqq}q(h"Uh/hubah:hnubhKX and qq}q(h"X and h/hubhe)q}q(h"XN`WinCE Utils `__h#}q(UnameX WinCE UtilshiX<http://processors.wiki.ti.com/index.php/Category:WinCE_Utilsh&]h']h%]h,]h-]uh/hhB]qhKX WinCE Utilsqq}q(h"Uh/hubah:hnubhKXG products, which may be included in various Linux and WinCE based SDKs.qq}q(h"XG products, which may be included in various Linux and WinCE based SDKs.h/hubeubhO)q}q(h"X Developmentqh/h7h9h*h:hSh#}q(h&]qU developmentqah']h%]h,]h-]qhauh@NhAhhB]qhKX Developmentq˅q}q(h"hh/hubaubh\)q}q(h"XUCMEM is a component of `Linux Utils `__, and is actively being developed in the publicly maintained, TI-hosted 'ludev' git repository - http://git.ti.com/ipc/ludev. The `Linux Utils development process is documented here `__, patches are welcome!h/h7h9h*h:h_h#}q(h%]h,]h']h&]h-]uh@K(hAhhB]q(hKXCMEM is a component of q҅q}q(h"XCMEM is a component of h/hubhe)q}q(h"XM`Linux Utils `__h#}q(UnameX Linux UtilshiX;http://processors.wiki.ti.com/index.php/Linux_Utils_Roadmaph&]h']h%]h,]h-]uh/hhB]qhKX Linux Utilsqمq}q(h"Uh/hubah:hnubhKXa, and is actively being developed in the publicly maintained, TI-hosted 'ludev' git repository - q܅q}q(h"Xa, and is actively being developed in the publicly maintained, TI-hosted 'ludev' git repository - h/hubhe)q}q(h"Xhttp://git.ti.com/ipc/ludevqh#}q(Urefurihh&]h']h%]h,]h-]uh/hhB]qhKXhttp://git.ti.com/ipc/ludevq䅁q}q(h"Uh/hubah:hnubhKX. The q煁q}q(h"X. The h/hubhe)q}q(h"XY`Linux Utils development process is documented here `__h#}q(UnameX2Linux Utils development process is documented herehiX http://git.ti.com/ipc/pages/Homeh&]h']h%]h,]h-]uh/hhB]qhKX2Linux Utils development process is documented hereqq}q(h"Uh/hubah:hnubhKX, patches are welcome!qq}q(h"X, patches are welcome!h/hubeubhO)q}q(h"X Configurationqh/h7h9h*h:hSh#}q(h&]qU configurationqah']h%]h,]h-]qhauh@NhAhhB]qhKX Configurationqq}q(h"hh/hubaubhO)q}r(h"XLinux Configurationrh/h7h9h*h:hSh#}r(h&]rUlinux-configurationrah']h%]h,]h-]rhauh@NhAhhB]rhKXLinux Configurationrr}r (h"jh/hubaubh\)r }r (h"XCMEM configuration can be done in 2 ways either through device tree soruce file (DTS) or command line when installing cmemk.ko driver using insmod command.r h/h7h9h*h:h_h#}r (h%]h,]h']h&]h-]uh@K4hAhhB]rhKXCMEM configuration can be done in 2 ways either through device tree soruce file (DTS) or command line when installing cmemk.ko driver using insmod command.rr}r(h"j h/j ubaubhO)r}r(h"XDTS Configurationrh/h7h9h*h:hSh#}r(h&]rUdts-configurationrah']h%]h,]h-]rh auh@NhAhhB]rhKXDTS Configurationrr}r(h"jh/jubaubh\)r}r(h"XThe CMEM configuration can be defined in the DTS file. Take AM57xx CMEM configuration as an example which is defined in arch/arm/boot/dts/am57xx-evm-cmem.dtsi.rh/h7h9h*h:h_h#}r (h%]h,]h']h&]h-]uh@K9hAhhB]r!hKXThe CMEM configuration can be defined in the DTS file. Take AM57xx CMEM configuration as an example which is defined in arch/arm/boot/dts/am57xx-evm-cmem.dtsi.r"r#}r$(h"jh/jubaubcdocutils.nodes literal_block r%)r&}r'(h"X/ { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; cmem_block_mem_0: cmem_block_mem@a0000000 { reg = <0x0 0xa0000000 0x0 0x0c000000>; no-map; status = "okay"; }; cmem_block_mem_1_ocmc3: cmem_block_mem@40500000 { reg = <0x0 0x40500000 0x0 0x100000>; no-map; status = "okay"; }; }; cmem { compatible = "ti,cmem"; #address-cells = <1>; #size-cells = <0>; #pool-size-cells = <2>; status = "okay"; cmem_block_0: cmem_block@0 { reg = <0>; memory-region = <&cmem_block_mem_0>; cmem-buf-pools = <1 0x0 0x0c000000>; }; cmem_block_1: cmem_block@1 { reg = <1>; memory-region = <&cmem_block_mem_1_ocmc3>; }; }; };h/h7h9h*h:U literal_blockr(h#}r)(U xml:spacer*Upreserver+h&]h']h%]h,]h-]uh@K?hAhhB]r,hKX/ { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; cmem_block_mem_0: cmem_block_mem@a0000000 { reg = <0x0 0xa0000000 0x0 0x0c000000>; no-map; status = "okay"; }; cmem_block_mem_1_ocmc3: cmem_block_mem@40500000 { reg = <0x0 0x40500000 0x0 0x100000>; no-map; status = "okay"; }; }; cmem { compatible = "ti,cmem"; #address-cells = <1>; #size-cells = <0>; #pool-size-cells = <2>; status = "okay"; cmem_block_0: cmem_block@0 { reg = <0>; memory-region = <&cmem_block_mem_0>; cmem-buf-pools = <1 0x0 0x0c000000>; }; cmem_block_1: cmem_block@1 { reg = <1>; memory-region = <&cmem_block_mem_1_ocmc3>; }; }; };r-r.}r/(h"Uh/j&ubaubh\)r0}r1(h"XIThere are 2 memory blocks reserved, one in DDR starting at 0xa0000000 of size 0x0c000000. The other reserved memory block is in MSMC at 0x40500000 of size 0x100000. There are 2 CMEM blocks configuration. The first CMEM block is from DDR area and has 1 buffer in the pool of size 0x0c000000. The 2nd CMEM block is from OCMC area.r2h/h7h9h*h:h_h#}r3(h%]h,]h']h&]h-]uh@KghAhhB]r4hKXIThere are 2 memory blocks reserved, one in DDR starting at 0xa0000000 of size 0x0c000000. The other reserved memory block is in MSMC at 0x40500000 of size 0x100000. There are 2 CMEM blocks configuration. The first CMEM block is from DDR area and has 1 buffer in the pool of size 0x0c000000. The 2nd CMEM block is from OCMC area.r5r6}r7(h"j2h/j0ubaubh\)r8}r9(h"X9The CMEM buffer pool allocation can be viewed at run timer:h/h7h9h*h:h_h#}r;(h%]h,]h']h&]h-]uh@KihAhhB]r<hKX9The CMEM buffer pool allocation can be viewed at run timer=r>}r?(h"j:h/j8ubaubj%)r@}rA(h"Xroot@am57xx-evm:~# cat /proc/cmem Block 0: Pool 0: 1 bufs size 0xc000000 (0xc000000 requested) Pool 0 busy bufs: Pool 0 free bufs: id 0: phys addr 0xa0000000h/h7h9h*h:j(h#}rB(j*j+h&]h']h%]h,]h-]uh@KohAhhB]rChKXroot@am57xx-evm:~# cat /proc/cmem Block 0: Pool 0: 1 bufs size 0xc000000 (0xc000000 requested) Pool 0 busy bufs: Pool 0 free bufs: id 0: phys addr 0xa0000000rDrE}rF(h"Uh/j@ubaubhO)rG}rH(h"XCommand Line ConfigurationrIh/h7h9h*h:hSh#}rJ(h&]rKUcommand-line-configurationrLah']h%]h,]h-]rMhauh@NhAhhB]rNhKXCommand Line ConfigurationrOrP}rQ(h"jIh/jGubaubh\)rR}rS(h"XCMEM Linux configuration through command line is done when installing the cmemk.ko driver, typically done using the insmod command. The cmemk.ko driver accepts command line parameters for configuring the physical memory to reserve and how to carve it up.rTh/h7h9h*h:h_h#}rU(h%]h,]h']h&]h-]uh@KzhAhhB]rVhKXCMEM Linux configuration through command line is done when installing the cmemk.ko driver, typically done using the insmod command. The cmemk.ko driver accepts command line parameters for configuring the physical memory to reserve and how to carve it up.rWrX}rY(h"jTh/jRubaubh\)rZ}r[(h"XAThe following is an example of installing the cmem kernel module:r\h/h7h9h*h:h_h#}r](h%]h,]h']h&]h-]uh@KhAhhB]r^hKXAThe following is an example of installing the cmem kernel module:r_r`}ra(h"j\h/jZubaubj%)rb}rc(h"XN/sbin/insmod cmemk.ko pools=4x30000,2x500000 phys_start=0x0 phys_end=0x3000000h/h7h9h*h:j(h#}rd(j*j+h&]h']h%]h,]h-]uh@KhAhhB]rehKXN/sbin/insmod cmemk.ko pools=4x30000,2x500000 phys_start=0x0 phys_end=0x3000000rfrg}rh(h"Uh/jbubaubh3)ri}rj(h"Uh/h7h9h*h:U bullet_listrkh#}rl(UbulletrmX-h&]h']h%]h,]h-]uh@KhAhhB]rn(h0)ro}rp(h"XAphys\_start and phys\_end must be specified in hexadecimal formatrqh/jih9h*h:U list_itemrrh#}rs(h%]h,]h']h&]h-]uh@NhAhhB]rth\)ru}rv(h"jqh/joh9h*h:h_h#}rw(h%]h,]h']h&]h-]uh@KhB]rxhKX?phys_start and phys_end must be specified in hexadecimal formatryrz}r{(h"XAphys\_start and phys\_end must be specified in hexadecimal formath/juubaubaubh0)r|}r}(h"Xpools must be specified using decimal format (for both number and size), since using hexadecimal format would visually clutter the specification due to the use of "x" as a token separator h/jih9h*h:jrh#}r~(h%]h,]h']h&]h-]uh@NhAhhB]rh\)r}r(h"Xpools must be specified using decimal format (for both number and size), since using hexadecimal format would visually clutter the specification due to the use of "x" as a token separatorrh/j|h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhB]rhKXpools must be specified using decimal format (for both number and size), since using hexadecimal format would visually clutter the specification due to the use of "x" as a token separatorrr}r(h"jh/jubaubaubeubh\)r}r(h"XThis particular command creates 2 pools. The first pool is created with 4 buffers of size 30000 bytes and the second pool is created with 2 buffers of size 500000 bytes. The CMEM pool buffers start at 0x0 and end at 0x3000000 (max).rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKXThis particular command creates 2 pools. The first pool is created with 4 buffers of size 30000 bytes and the second pool is created with 2 buffers of size 500000 bytes. The CMEM pool buffers start at 0x0 and end at 0x3000000 (max).rr}r(h"jh/jubaubh\)r}r(h"X/Pool buffers are aligned on a module-dependent boundary, and their sizes are rounded up to this same boundary. This applies to each buffer within a pool. The total space used by an individual pool will therefore be greater than (or equal to) the exact amount requested in the installation of the module.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKX/Pool buffers are aligned on a module-dependent boundary, and their sizes are rounded up to this same boundary. This applies to each buffer within a pool. The total space used by an individual pool will therefore be greater than (or equal to) the exact amount requested in the installation of the module.rr}r(h"jh/jubaubh\)r}r(h"X\The poolid used in the driver calls would be 0 for the first pool and 1 for the second pool.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKX\The poolid used in the driver calls would be 0 for the first pool and 1 for the second pool.rr}r(h"jh/jubaubh\)r}r(h"XPool allocations can be requested explicitly by pool number, or more generally by just a size. For size-based allocations, the pool which best fits the requested size is automatically chosen.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKXPool allocations can be requested explicitly by pool number, or more generally by just a size. For size-based allocations, the pool which best fits the requested size is automatically chosen.rr}r(h"jh/jubaubh\)r}r(h"XuFor more details on CMEM configuration, please find info in [Linux ProcSDK]/board_support/extra-drivers/cmem-mod-(version+commit_ID)/include/ti/cmem.h which documents CMEM user interface, or refer to the device tree binding document in board-support/extra-drivers/cmem-mod-[version]+[git-commit-id]/src/cmem/module/kernel/Documentation/device-tree/bindings/cmem/ti,cmem.txtrh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKXuFor more details on CMEM configuration, please find info in [Linux ProcSDK]/board_support/extra-drivers/cmem-mod-(version+commit_ID)/include/ti/cmem.h which documents CMEM user interface, or refer to the device tree binding document in board-support/extra-drivers/cmem-mod-[version]+[git-commit-id]/src/cmem/module/kernel/Documentation/device-tree/bindings/cmem/ti,cmem.txtrr}r(h"jh/jubaubhO)r}r(h"XWinCE Configurationrh/h7h9h*h:hSh#}r(h&]rUwince-configurationrah']h%]h,]h-]rh auh@NhAhhB]rhKXWinCE Configurationrr}r(h"jh/jubaubh\)r}r(h"XConfiguration of CMEM in WinCE-based environments is typically done via the registry and/or statically built into the driver (for closed systems). Here is an example for a line to be added to the MEMORY section of 'config.bib' of your BSP:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKXConfiguration of CMEM in WinCE-based environments is typically done via the registry and/or statically built into the driver (for closed systems). Here is an example for a line to be added to the MEMORY section of 'config.bib' of your BSP:rr}r(h"jh/jubaubj%)r}r(h"X6CMEM_DSP 89000000 02800000 RESERVED ; 40 MBh/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@KhAhhB]rhKX6CMEM_DSP 89000000 02800000 RESERVED ; 40 MBrr}r(h"Uh/jubaubh\)r}r(h"X\That reserves 40MB of memory for CMEM, DSPLINK, DSP code as well as DSP heap usage starting at virtual address 0x89000000. There is no distinction here between the different modules memory usage. Obviously all of them need to be configured accordingly. Registry settings for CMEM use physical start and end addresses for any defined block of pools.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKX\That reserves 40MB of memory for CMEM, DSPLINK, DSP code as well as DSP heap usage starting at virtual address 0x89000000. There is no distinction here between the different modules memory usage. Obviously all of them need to be configured accordingly. Registry settings for CMEM use physical start and end addresses for any defined block of pools.rr}r(h"jh/jubaubh\)r}r(h"XTHere is an example CMEM configuration registry entry in platform.reg for TI EVM3530:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKXTHere is an example CMEM configuration registry entry in platform.reg for TI EVM3530:rr}r(h"jh/jubaubj%)r}r(h"X;-- CMEM -------------------------------------------------------------------- IF SYSGEN_CMEM [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\CMEMK] "Prefix"="CMK" "Dll"="cmemk.dll" "Index"=dword:1 ; Make 7 pools available for allocation for block 0 ; Make 1 pool available for allocation for block 1 "NumPools0"=dword:7 "NumPools1"=dword:0 "Block0_NumBuffers_Pool0"=dword:20 "Block0_PoolSize_Pool0"=dword:1000 ; size in bytes (hex) "Block0_NumBuffers_Pool1"=dword:8 "Block0_PoolSize_Pool1"=dword:20000 ; size in bytes (hex) "Block0_NumBuffers_Pool2"=dword:5 "Block0_PoolSize_Pool2"=dword:100000 ; size in bytes (hex) "Block0_NumBuffers_Pool3"=dword:1 "Block0_PoolSize_Pool3"=dword:15cfc0 ; size in bytes (hex) "Block0_NumBuffers_Pool4"=dword:1 "Block0_PoolSize_Pool4"=dword:3e800 ; size in bytes (hex) "Block0_NumBuffers_Pool5"=dword:1 "Block0_PoolSize_Pool5"=dword:36ee80 ; size in bytes (hex) "Block0_NumBuffers_Pool6"=dword:3 "Block0_PoolSize_Pool6"=dword:96000 ; size in bytes (hex) ;; "Block1_NumBuffers_Pool1"=dword:2 ;; "Block1_PoolSize_Pool1"=dword:4000 ; size in bytes (hex) ; Physical start + physical end can be use to ask CMEM to map a specific ; range of physical addresses. ; This is a potential security risk. If physical start == 0 then the code ; hits a special case. ; physical end - physical start == length of allocation. In the special ; case, memory is allocated via a call to AllocPhysMem() (as shown in ; this example). MmMapIoSpace() is used to map the normal case where ; physical start != 0. ; ; physical start and end for block 0 "PhysicalStart0"=dword:85000000 "PhysicalEnd0"=dword:86000000 ; physical start and end for block 1 "PhysicalStart1"=dword:0 "PhysicalEnd1"=dword:0 ENDIF SYSGEN_CMEM ;------------------------------------------------------------------------------h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@KhAhhB]rhKX;-- CMEM -------------------------------------------------------------------- IF SYSGEN_CMEM [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\CMEMK] "Prefix"="CMK" "Dll"="cmemk.dll" "Index"=dword:1 ; Make 7 pools available for allocation for block 0 ; Make 1 pool available for allocation for block 1 "NumPools0"=dword:7 "NumPools1"=dword:0 "Block0_NumBuffers_Pool0"=dword:20 "Block0_PoolSize_Pool0"=dword:1000 ; size in bytes (hex) "Block0_NumBuffers_Pool1"=dword:8 "Block0_PoolSize_Pool1"=dword:20000 ; size in bytes (hex) "Block0_NumBuffers_Pool2"=dword:5 "Block0_PoolSize_Pool2"=dword:100000 ; size in bytes (hex) "Block0_NumBuffers_Pool3"=dword:1 "Block0_PoolSize_Pool3"=dword:15cfc0 ; size in bytes (hex) "Block0_NumBuffers_Pool4"=dword:1 "Block0_PoolSize_Pool4"=dword:3e800 ; size in bytes (hex) "Block0_NumBuffers_Pool5"=dword:1 "Block0_PoolSize_Pool5"=dword:36ee80 ; size in bytes (hex) "Block0_NumBuffers_Pool6"=dword:3 "Block0_PoolSize_Pool6"=dword:96000 ; size in bytes (hex) ;; "Block1_NumBuffers_Pool1"=dword:2 ;; "Block1_PoolSize_Pool1"=dword:4000 ; size in bytes (hex) ; Physical start + physical end can be use to ask CMEM to map a specific ; range of physical addresses. ; This is a potential security risk. If physical start == 0 then the code ; hits a special case. ; physical end - physical start == length of allocation. In the special ; case, memory is allocated via a call to AllocPhysMem() (as shown in ; this example). MmMapIoSpace() is used to map the normal case where ; physical start != 0. ; ; physical start and end for block 0 "PhysicalStart0"=dword:85000000 "PhysicalEnd0"=dword:86000000 ; physical start and end for block 1 "PhysicalStart1"=dword:0 "PhysicalEnd1"=dword:0 ENDIF SYSGEN_CMEM ;------------------------------------------------------------------------------rr}r(h"Uh/jubaubh\)r}r(h"XThe CMEM driver information must also be added to the platform.bib file (or some other .bib file that gets put into ce.bib). Here is an example of the CMEM driver entry in platform.bib:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKXThe CMEM driver information must also be added to the platform.bib file (or some other .bib file that gets put into ce.bib). Here is an example of the CMEM driver entry in platform.bib:rr}r(h"jh/jubaubj%)r}r(h"X;-- CMEM ---------------------------------------------------------------------- IF SYSGEN_CMEM cmemk.dll $(_FLATRELEASEDIR)\cmemk.dll NK SHK ENDIF BSP_CMEM ;------------------------------------------------------------------------------h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@KhAhhB]rhKX;-- CMEM ---------------------------------------------------------------------- IF SYSGEN_CMEM cmemk.dll $(_FLATRELEASEDIR)\cmemk.dll NK SHK ENDIF BSP_CMEM ;------------------------------------------------------------------------------rr}r(h"Uh/jubaubhO)r}r(h"XDebugging Techniquesrh/h7h9h*h:hSh#}r(h&]rUdebugging-techniquesrah']h%]h,]h-]rhauh@NhAhhB]rhKXDebugging Techniquesrr}r(h"jh/jubaubh\)r}r(h"XdLinux users can execute "``cat /proc/cmem``" to get status on the buffers and pools managed by CMEM.h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]r(hKXLinux users can execute "rr}r(h"XLinux users can execute "h/jubcdocutils.nodes literal r)r}r(h"X``cat /proc/cmem``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXcat /proc/cmemrr}r (h"Uh/jubah:Uliteralr ubhKX9" to get status on the buffers and pools managed by CMEM.r r }r (h"X9" to get status on the buffers and pools managed by CMEM.h/jubeubh\)r}r(h"XThere is also a debug library provided that provides tracing diagnostics during execution. XDC Config users can link in this library by adding the following to their application's config script:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@KhAhhB]rhKXThere is also a debug library provided that provides tracing diagnostics during execution. XDC Config users can link in this library by adding the following to their application's config script:rr}r(h"jh/jubaubj%)r}r(h"XKvar CMEM = xdc.useModule('ti.sdo.linuxutils.cmem.CMEM'); CMEM.debug = true;h/h7h9h*h:j(h#}r(UlinenosrUlanguagerX javascriptj*j+h&]h']h%]Uhighlight_argsr}h,]h-]uh@KhAhhB]rhKXKvar CMEM = xdc.useModule('ti.sdo.linuxutils.cmem.CMEM'); CMEM.debug = true;rr}r(h"Uh/jubaubhO)r }r!(h"XGeneral Purpose Heapsr"h/h7h9h*h:hSh#}r#(h&]r$Ugeneral-purpose-heapsr%ah']h%]h,]h-]r&hauh@NhAhhB]r'hKXGeneral Purpose Heapsr(r)}r*(h"j"h/j ubaubh\)r+}r,(h"XIn CMEM 2.00, CMEM added support for a general purpose heap. Using the example above, in addition to the 2 pools, a general purpose heap block is created from which allocations of any size can be requested. Internally, allocation sizes are rounded up to a module-dependent boundary and allocation addresses are aligned either to this same boundary or to the requested alignment (whichever is greater).r-h/h7h9h*h:h_h#}r.(h%]h,]h']h&]h-]uh@MhAhhB]r/hKXIn CMEM 2.00, CMEM added support for a general purpose heap. Using the example above, in addition to the 2 pools, a general purpose heap block is created from which allocations of any size can be requested. Internally, allocation sizes are rounded up to a module-dependent boundary and allocation addresses are aligned either to this same boundary or to the requested alignment (whichever is greater).r0r1}r2(h"j-h/j+ubaubh\)r3}r4(h"XThe size of the heap block is the amount of CMEM memory remaining after all pool allocations. If more heap space is needed than is available after pool allocations, you must reduce the amount of CMEM memory granted to the pools.r5h/h7h9h*h:h_h#}r6(h%]h,]h']h&]h-]uh@M hAhhB]r7hKXThe size of the heap block is the amount of CMEM memory remaining after all pool allocations. If more heap space is needed than is available after pool allocations, you must reduce the amount of CMEM memory granted to the pools.r8r9}r:(h"j5h/j3ubaubh\)r;}r<(h"XAThe main disadvantage to using heap(s) over pools is fragmentation. After several sequences of codec creation/deletion, in different orders, with possibly different create() params, you may end up fragmenting your heap and being unable to acquire a requested memory block - possibly resulting in a codec creation failure.r=h/h7h9h*h:h_h#}r>(h%]h,]h']h&]h-]uh@MhAhhB]r?hKXAThe main disadvantage to using heap(s) over pools is fragmentation. After several sequences of codec creation/deletion, in different orders, with possibly different create() params, you may end up fragmenting your heap and being unable to acquire a requested memory block - possibly resulting in a codec creation failure.r@rA}rB(h"j=h/j;ubaubh\)rC}rD(h"XJTypically, during development, users will use CMEM with heap-based memory, as heap usage requires very little configuration, and users don't know how to configure pool memory(!). In a production system, however, it's strongly recommended that pool configuration be used to avoid memory fragmentation and confusing end user errors.rEh/h7h9h*h:h_h#}rF(h%]h,]h']h&]h-]uh@MhAhhB]rGhKXJTypically, during development, users will use CMEM with heap-based memory, as heap usage requires very little configuration, and users don't know how to configure pool memory(!). In a production system, however, it's strongly recommended that pool configuration be used to avoid memory fragmentation and confusing end user errors.rHrI}rJ(h"jEh/jCubaubhO)rK}rL(h"XApplication CleanuprMh/h7h9h*h:hSh#}rN(h&]rOUapplication-cleanuprPah']h%]h,]h-]rQhauh@NhAhhB]rRhKXApplication CleanuprSrT}rU(h"jMh/jKubaubh\)rV}rW(h"XCMEM 2.23 introduced a facility to clean up unfreed buffers when an application exits, either prematurely or in a normal fashion. This facility is achieved by maintaining an "ownership" list for each allocated buffer that is inspected upon closing a device driver instance. During this inspection all allocated buffers are checked, and when it is determined that the closing process is on the ownership list of an allocated buffer, the process is removed from the list. If this causes the list to become empty the associated buffer is actually freed, otherwise it is maintained in the allocated state on behalf of other owners. A side-effect of this model is that only a buffer "owner" is allowed to free the buffer.rXh/h7h9h*h:h_h#}rY(h%]h,]h']h&]h-]uh@M!hAhhB]rZhKXCMEM 2.23 introduced a facility to clean up unfreed buffers when an application exits, either prematurely or in a normal fashion. This facility is achieved by maintaining an "ownership" list for each allocated buffer that is inspected upon closing a device driver instance. During this inspection all allocated buffers are checked, and when it is determined that the closing process is on the ownership list of an allocated buffer, the process is removed from the list. If this causes the list to become empty the associated buffer is actually freed, otherwise it is maintained in the allocated state on behalf of other owners. A side-effect of this model is that only a buffer "owner" is allowed to free the buffer.r[r\}r](h"jXh/jVubaubh\)r^}r_(h"X`In order to facilitate multiple owners of an allocated buffer, a new set of APIs was introduced:r`h/h7h9h*h:h_h#}ra(h%]h,]h']h&]h-]uh@M-hAhhB]rbhKX`In order to facilitate multiple owners of an allocated buffer, a new set of APIs was introduced:rcrd}re(h"j`h/j^ubaubj%)rf}rg(h"Xhvoid *CMEM_registerAlloc(unsigned long physp); int CMEM_unregister(void *ptr, CMEM_AllocParams *params);h/h7h9h*h:j(h#}rh(jjXcj*j+h&]h']h%]j}h,]h-]uh@M0hAhhB]rihKXhvoid *CMEM_registerAlloc(unsigned long physp); int CMEM_unregister(void *ptr, CMEM_AllocParams *params);rjrk}rl(h"Uh/jfubaubh\)rm}rn(h"X``CMEM_registerAlloc()`` takes a buffer physical address as input (achieved through ``CMEM_getPhys()``) and returns a fresh virtual address that is mapped to that buffer, while also adding the calling process to the ownership list. ``CMEM_unregister()`` is equivalent to ``CMEM_free()`` and releases ownership of the buffer (as well as freeing it if all owners have released the buffer).h/h7h9h*h:h_h#}ro(h%]h,]h']h&]h-]uh@M5hAhhB]rp(j)rq}rr(h"X``CMEM_registerAlloc()``h#}rs(h%]h,]h']h&]h-]uh/jmhB]rthKXCMEM_registerAlloc()rurv}rw(h"Uh/jqubah:j ubhKX< takes a buffer physical address as input (achieved through rxry}rz(h"X< takes a buffer physical address as input (achieved through h/jmubj)r{}r|(h"X``CMEM_getPhys()``h#}r}(h%]h,]h']h&]h-]uh/jmhB]r~hKXCMEM_getPhys()rr}r(h"Uh/j{ubah:j ubhKX) and returns a fresh virtual address that is mapped to that buffer, while also adding the calling process to the ownership list. rr}r(h"X) and returns a fresh virtual address that is mapped to that buffer, while also adding the calling process to the ownership list. h/jmubj)r}r(h"X``CMEM_unregister()``h#}r(h%]h,]h']h&]h-]uh/jmhB]rhKXCMEM_unregister()rr}r(h"Uh/jubah:j ubhKX is equivalent to rr}r(h"X is equivalent to h/jmubj)r}r(h"X``CMEM_free()``h#}r(h%]h,]h']h&]h-]uh/jmhB]rhKX CMEM_free()rr}r(h"Uh/jubah:j ubhKXe and releases ownership of the buffer (as well as freeing it if all owners have released the buffer).rr}r(h"Xe and releases ownership of the buffer (as well as freeing it if all owners have released the buffer).h/jmubeubh\)r}r(h"XIn CMEM 2.24, ownership is established on a per-process (and per-thread) basis. This detail becomes important when using CMEM in multiple threads of a given process - if one thread allocates a CMEM buffer and a separate thread of the same process is responsible for freeing that buffer, the "freeing" thread will not be allowed to free the buffer since it is not on the ownership list.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@M<hAhhB]rhKXIn CMEM 2.24, ownership is established on a per-process (and per-thread) basis. This detail becomes important when using CMEM in multiple threads of a given process - if one thread allocates a CMEM buffer and a separate thread of the same process is responsible for freeing that buffer, the "freeing" thread will not be allowed to free the buffer since it is not on the ownership list.rr}r(h"jh/jubaubh\)r}r(h"X|CMEM 2.24.01 changes the ownership policy to be based on the calling process' file descriptor instead of the calling process' process descriptor. This facilitates thread-based sharing of buffers, allowing any thread within a process to free a buffer that was allocated by a different thread within the same process, since threads within a process all use the same file descriptor.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MChAhhB]rhKX|CMEM 2.24.01 changes the ownership policy to be based on the calling process' file descriptor instead of the calling process' process descriptor. This facilitates thread-based sharing of buffers, allowing any thread within a process to free a buffer that was allocated by a different thread within the same process, since threads within a process all use the same file descriptor.rr}r(h"jh/jubaubhO)r}r(h"XLinux CMA Supportrh/h7h9h*h:hSh#}r(h&]rUlinux-cma-supportrah']h%]h,]h-]rh auh@NhAhhB]rhKXLinux CMA Supportrr}r(h"jh/jubaubh\)r}r(h"XCMEM 4.00 added the ability to leverage the `Linux kernel's CMA feature `__. CMA supports a "global" memory pool, as well as device-specific memory - CMEM provides the facilities to allocate from either type of CMA pool.h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MMhAhhB]r(hKX,CMEM 4.00 added the ability to leverage the rr}r(h"X,CMEM 4.00 added the ability to leverage the h/jubhe)r}r(h"X@`Linux kernel's CMA feature `__h#}r(UnameXLinux kernel's CMA featurehiXhttp://lwn.net/Articles/396657/h&]h']h%]h,]h-]uh/jhB]rhKXLinux kernel's CMA featurerr}r(h"Uh/jubah:hnubhKX. CMA supports a "global" memory pool, as well as device-specific memory - CMEM provides the facilities to allocate from either type of CMA pool.rr}r(h"X. CMA supports a "global" memory pool, as well as device-specific memory - CMEM provides the facilities to allocate from either type of CMA pool.h/jubeubh\)r}r(h"XCMA also defines the carveout area of the physical location where the DSP code/data will actually reside. The DSP carveouts are defined in the dts file. For example the AM57xx EVM, it is linux/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MRhAhhB]rhKXCMA also defines the carveout area of the physical location where the DSP code/data will actually reside. The DSP carveouts are defined in the dts file. For example the AM57xx EVM, it is linux/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi.rr}r(h"jh/jubaubj%)r}r(h"XMdsp1_cma_pool: dsp1_cma@99000000 { compatible = "shared-dma-pool"; reg = <0x0 0x99000000 0x0 0x4000000>; reusable; status = "okay"; }; dsp2_cma_pool: dsp2_cma@9f000000 { compatible = "shared-dma-pool"; reg = <0x0 0x9f000000 0x0 0x800000>; reusable; status = "okay"; };h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MXhAhhB]rhKXMdsp1_cma_pool: dsp1_cma@99000000 { compatible = "shared-dma-pool"; reg = <0x0 0x99000000 0x0 0x4000000>; reusable; status = "okay"; }; dsp2_cma_pool: dsp2_cma@9f000000 { compatible = "shared-dma-pool"; reg = <0x0 0x9f000000 0x0 0x800000>; reusable; status = "okay"; };rr}r(h"Uh/jubaubh\)r}r(h"XNote that using CMEM to allocate from CMA-based memory is an additional feature. You can continue to use CMEM to manage memory carveouts as well.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MehAhhB]rhKXNote that using CMEM to allocate from CMA-based memory is an additional feature. You can continue to use CMEM to manage memory carveouts as well.rr}r(h"jh/jubaubhO)r}r(h"XAndroid CMA Supportrh/h7h9h*h:hSh#}r(h&]rUandroid-cma-supportrah']h%]h,]h-]rh auh@NhAhhB]rhKXAndroid CMA Supportrr}r(h"jh/jubaubhO)r}r(h"XBuild Environment Setuprh/h7h9h*h:hSh#}r(h&]rUbuild-environment-setuprah']h%]h,]h-]rhauh@NhAhhB]rhKXBuild Environment Setuprr}r(h"jh/jubaubh\)r}r(h"XFirst download an unzip the latest Linux utils(4.00.01.08) zip file. The file products.mak (at the top level of this tree) contains two definitions used by the build subsystem:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MohAhhB]rhKXFirst download an unzip the latest Linux utils(4.00.01.08) zip file. The file products.mak (at the top level of this tree) contains two definitions used by the build subsystem:rr}r(h"jh/jubaubj%)r}r(h"XKERNEL_INSTALL_DIR - The base directory of your Linux kernel source tree TOOLCHAIN_PREFIX - the 'prefix' for the GNU ARM codegen toolsh/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MwhAhhB]rhKXKERNEL_INSTALL_DIR - The base directory of your Linux kernel source tree TOOLCHAIN_PREFIX - the 'prefix' for the GNU ARM codegen toolsrr}r(h"Uh/jubaubh\)r}r(h"XhThe TOOLCHAIN\_PREFIX can contain the full path of the codegen tools, ending with the tool prefix, i.e.:h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MxhAhhB]rhKXgThe TOOLCHAIN_PREFIX can contain the full path of the codegen tools, ending with the tool prefix, i.e.:rr}r(h"XhThe TOOLCHAIN\_PREFIX can contain the full path of the codegen tools, ending with the tool prefix, i.e.:h/jubaubj%)r}r (h"XbTOOLCHAIN_PREFIX=/db/toolsrc/library/vendors2005/cs/arm/arm-2008q1-126/bin/arm-none-linux-gnueabi-h/h7h9h*h:j(h#}r (j*j+h&]h']h%]h,]h-]uh@MhAhhB]r hKXbTOOLCHAIN_PREFIX=/db/toolsrc/library/vendors2005/cs/arm/arm-2008q1-126/bin/arm-none-linux-gnueabi-r r }r(h"Uh/jubaubh\)r}r(h"X`or it can be just the tool prefix if your shell's $PATH contains your codegen's 'bin' directory:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]rhKX`or it can be just the tool prefix if your shell's $PATH contains your codegen's 'bin' directory:rr}r(h"jh/jubaubj%)r}r(h"X(TOOLCHAIN_PREFIX=arm-none-linux-gnueabi-h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKX(TOOLCHAIN_PREFIX=arm-none-linux-gnueabi-rr}r(h"Uh/jubaubh\)r}r(h"Xwhere your $PATH contains:r h/h7h9h*h:h_h#}r!(h%]h,]h']h&]h-]uh@MhAhhB]r"hKXwhere your $PATH contains:r#r$}r%(h"j h/jubaubj%)r&}r'(h"X9/db/toolsrc/library/vendors2005/cs/arm/arm-2008q1-126/binh/h7h9h*h:j(h#}r((j*j+h&]h']h%]h,]h-]uh@MhAhhB]r)hKX9/db/toolsrc/library/vendors2005/cs/arm/arm-2008q1-126/binr*r+}r,(h"Uh/j&ubaubh\)r-}r.(h"X>For example, below is the setup environment which is validatedr/h/h7h9h*h:h_h#}r0(h%]h,]h']h&]h-]uh@MhAhhB]r1hKX>For example, below is the setup environment which is validatedr2r3}r4(h"j/h/j-ubaubj%)r5}r6(h"XTOOLCHAIN_LONGNAME = arm-eabi TOOLCHAIN_INSTALL_DIR = /home/(user)/mydroid/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7 KERNEL_INSTALL_DIR =/home/(user)/kernel/android-3.8h/h7h9h*h:j(h#}r7(j*j+h&]h']h%]h,]h-]uh@MhAhhB]r8hKXTOOLCHAIN_LONGNAME = arm-eabi TOOLCHAIN_INSTALL_DIR = /home/(user)/mydroid/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7 KERNEL_INSTALL_DIR =/home/(user)/kernel/android-3.8r9r:}r;(h"Uh/j5ubaubh\)r<}r=(h"XNNow move to the src/cmem/module directory to run "make clean" and then "make".r>h/h7h9h*h:h_h#}r?(h%]h,]h']h&]h-]uh@MhAhhB]r@hKXNNow move to the src/cmem/module directory to run "make clean" and then "make".rArB}rC(h"j>h/j<ubaubhO)rD}rE(h"XBuilding Test BinariesrFh/h7h9h*h:hSh#}rG(h&]rHUbuilding-test-binariesrIah']h%]h,]h-]rJh auh@NhAhhB]rKhKXBuilding Test BinariesrLrM}rN(h"jFh/jDubaubh\)rO}rP(h"XTFrom the downloaded and installed linux utils base directory run the below commands,rQh/h7h9h*h:h_h#}rR(h%]h,]h']h&]h-]uh@MhAhhB]rShKXTFrom the downloaded and installed linux utils base directory run the below commands,rTrU}rV(h"jQh/jOubaubh\)rW}rX(h"XNote: Any non-android toolchain should work and don't forget to export the toolchain path(until the bin folder) to PATH environment variable.rYh/h7h9h*h:h_h#}rZ(h%]h,]h']h&]h-]uh@MhAhhB]r[hKXNote: Any non-android toolchain should work and don't forget to export the toolchain path(until the bin folder) to PATH environment variable.r\r]}r^(h"jYh/jWubaubj%)r_}r`(h"Xexport ARCH=arm export CROSS_COMPILE=arm-linux-gnueabihf ./configure --disable-shared --host=arm-linux-gnueabihf --prefix=$PWD CFLAGS='--static'h/h7h9h*h:j(h#}ra(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rbhKXexport ARCH=arm export CROSS_COMPILE=arm-linux-gnueabihf ./configure --disable-shared --host=arm-linux-gnueabihf --prefix=$PWD CFLAGS='--static'rcrd}re(h"Uh/j_ubaubh\)rf}rg(h"XFNow run "make clean" and "make" to build the test binaries for androidrhh/h7h9h*h:h_h#}ri(h%]h,]h']h&]h-]uh@MhAhhB]rjhKXFNow run "make clean" and "make" to build the test binaries for androidrkrl}rm(h"jhh/jfubaubhO)rn}ro(h"X!Test Setup and Validation Processrph/h7h9h*h:hSh#}rq(h&]rrU!test-setup-and-validation-processrsah']h%]h,]h-]rthauh@NhAhhB]ruhKX!Test Setup and Validation Processrvrw}rx(h"jph/jnubaubh\)ry}rz(h"X>For testing purpose we built the android kernel for mem=1200M.r{h/h7h9h*h:h_h#}r|(h%]h,]h']h&]h-]uh@MhAhhB]r}hKX>For testing purpose we built the android kernel for mem=1200M.r~r}r(h"j{h/jyubaubh\)r}r(h"XSBoot the system with android and then do **adb push** on the below mentioned files,h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]r(hKX)Boot the system with android and then do rr}r(h"X)Boot the system with android and then do h/jubcdocutils.nodes strong r)r}r(h"X **adb push**h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXadb pushrr}r(h"Uh/jubah:UstrongrubhKX on the below mentioned files,rr}r(h"X on the below mentioned files,h/jubeubj%)r}r(h"X(linux utils base directory)/src/cmem/module/cmemk.ko to /system/lib/modules (linux utils base directory)/src/cmem/tests/apitest to /system/bin (linux utils base directory)/src/cmem/tests/multi_process to /system/bin (linux utils base directory)/src/cmem/tests/translate to /system/binh/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKX(linux utils base directory)/src/cmem/module/cmemk.ko to /system/lib/modules (linux utils base directory)/src/cmem/tests/apitest to /system/bin (linux utils base directory)/src/cmem/tests/multi_process to /system/bin (linux utils base directory)/src/cmem/tests/translate to /system/binrr}r(h"Uh/jubaubh\)r}r(h"XThe loadable kernel module '**cmemk.ko'** can be installed into any running system. Out of the 3 tests mentioned below Multi\_Process & Translate tests have been used to validate the CMEM module's usage of OCMC1 ram. OCMC1 ram range is 0x40300000 ~ 0x4033FFFF.h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]r(hKXThe loadable kernel module 'rr}r(h"XThe loadable kernel module 'h/jubj)r}r(h"X **cmemk.ko'**h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX cmemk.ko'rr}r(h"Uh/jubah:jubhKX can be installed into any running system. Out of the 3 tests mentioned below Multi_Process & Translate tests have been used to validate the CMEM module's usage of OCMC1 ram. OCMC1 ram range is 0x40300000 ~ 0x4033FFFF.rr}r(h"X can be installed into any running system. Out of the 3 tests mentioned below Multi\_Process & Translate tests have been used to validate the CMEM module's usage of OCMC1 ram. OCMC1 ram range is 0x40300000 ~ 0x4033FFFF.h/jubeubhO)r}r(h"XMulti Process Testrh/h7h9h*h:hSh#}r(h&]rUmulti-process-testrah']h%]h,]h-]rhauh@NhAhhB]rhKXMulti Process Testrr}r(h"jh/jubaubh\)r}r(h"XThis app tries to use CMEM from multiple processes. It takes the number of processes to start as a parameter. Now load the kernel module 'cmemk.ko' with the below command:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]rhKXThis app tries to use CMEM from multiple processes. It takes the number of processes to start as a parameter. Now load the kernel module 'cmemk.ko' with the below command:rr}r(h"jh/jubaubj%)r}r(h"X% insmod cmemk.ko phys_start=0xcaf01000 phys_end=0xCB601000 pools=4x1000 phys_start_1=0xCB601000 phys_end_1=0xCB701000 pools_1=4x1000h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKX% insmod cmemk.ko phys_start=0xcaf01000 phys_end=0xCB601000 pools=4x1000 phys_start_1=0xCB601000 phys_end_1=0xCB701000 pools_1=4x1000rr}r(h"Uh/jubaubh\)r}r(h"X (Uses DDR)rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]rhKX (Uses DDR)rr}r(h"jh/jubaubj%)r}r(h"X% insmod cmemk.ko phys_start=0x40300000 phys_end=0x4033FFFF pools=4x500 phys_start_1=0x4033FFFF phys_end_1=0x4037ffff pools_1=4x500 allowOverlap=1h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKX% insmod cmemk.ko phys_start=0x40300000 phys_end=0x4033FFFF pools=4x500 phys_start_1=0x4033FFFF phys_end_1=0x4037ffff pools_1=4x500 allowOverlap=1rr}r(h"Uh/jubaubh\)r}r(h"X(Uses OCMC1, for this rebuild the Translate Test app with macro BUFFER\_SIZE = 500 at line #49 in file (linuxutils)/src/cmem/tests/multi\_process.c) Now run the Multi Process test,h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]rhKX(Uses OCMC1, for this rebuild the Translate Test app with macro BUFFER_SIZE = 500 at line #49 in file (linuxutils)/src/cmem/tests/multi_process.c) Now run the Multi Process test,rr}r(h"X(Uses OCMC1, for this rebuild the Translate Test app with macro BUFFER\_SIZE = 500 at line #49 in file (linuxutils)/src/cmem/tests/multi\_process.c) Now run the Multi Process test,h/jubaubj%)r}r(h"X% multi_process 3h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKX% multi_process 3rr}r(h"Uh/jubaubh\)r}r(h"X1where 3 is the number of processes to be spawned.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]rhKX1where 3 is the number of processes to be spawned.rr}r(h"jh/jubaubhO)r}r(h"XTranslate Testrh/h7h9h*h:hSh#}r(h&]rUtranslate-testrah']h%]h,]h-]rhauh@NhAhhB]rhKXTranslate Testrr}r(h"jh/jubaubh\)r}r(h"XeThis app tests the address translation. Now load the kernel module 'cmemk.ko' with the below command:rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]rhKXeThis app tests the address translation. Now load the kernel module 'cmemk.ko' with the below command:rr}r(h"jh/jubaubj%)r}r(h"XK% insmod cmemk.ko phys_start=0xcaf01000 phys_end=0xCB601000 pools=1x3145728h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKXK% insmod cmemk.ko phys_start=0xcaf01000 phys_end=0xCB601000 pools=1x3145728rr}r(h"Uh/jubaubh\)r}r(h"X (Uses DDR)rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]r hKX (Uses DDR)r r }r (h"jh/jubaubj%)r }r(h"XX% insmod cmemk.ko phys_start=0x40300000 phys_end=0x4037ffff pools=1x20000 allowOverlap=1h/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKXX% insmod cmemk.ko phys_start=0x40300000 phys_end=0x4037ffff pools=1x20000 allowOverlap=1rr}r(h"Uh/j ubaubh\)r}r(h"X(Uses OCMC1, for this rebuild the Translate Test app with macro BUFSIZE = 20000 at line #48 in file (linuxutils)/src/cmem/tests/translate.c) Now run the Translate test,rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]rhKX(Uses OCMC1, for this rebuild the Translate Test app with macro BUFSIZE = 20000 at line #48 in file (linuxutils)/src/cmem/tests/translate.c) Now run the Translate test,rr}r(h"jh/jubaubj%)r}r(h"X % translateh/h7h9h*h:j(h#}r(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rhKX % translater r!}r"(h"Uh/jubaubhO)r#}r$(h"XAPI Testr%h/h7h9h*h:hSh#}r&(h&]r'Uapi-testr(ah']h%]h,]h-]r)hauh@NhAhhB]r*hKXAPI Testr+r,}r-(h"j%h/j#ubaubh\)r.}r/(h"XTests basic API usage and memory allocation. This particular test has a limitation as it runs successfully only on kernel built with mem=120M. Now load the kernel module 'cmemk.ko' with the below command:r0h/h7h9h*h:h_h#}r1(h%]h,]h']h&]h-]uh@MhAhhB]r2hKXTests basic API usage and memory allocation. This particular test has a limitation as it runs successfully only on kernel built with mem=120M. Now load the kernel module 'cmemk.ko' with the below command:r3r4}r5(h"j0h/j.ubaubj%)r6}r7(h"X% insmod cmemk.ko phys_start=0x87800000 phys_end=0x87F00000 pools=4xBUFSIZE phys_start_1=0x87F00000 phys_end_1=0x88000000 pools_1=4xBUFSIZEh/h7h9h*h:j(h#}r8(j*j+h&]h']h%]h,]h-]uh@MhAhhB]r9hKX% insmod cmemk.ko phys_start=0x87800000 phys_end=0x87F00000 pools=4xBUFSIZE phys_start_1=0x87F00000 phys_end_1=0x88000000 pools_1=4xBUFSIZEr:r;}r<(h"Uh/j6ubaubh\)r=}r>(h"Xwhere BUFSIZE is the number of bytes you plan on passing as command line parameter to apitest. If in doubt, use a larger number as BUFSIZE denotes the maximum buffer you can allocate.Now run the Translate test, Now run the API test,r?h/h7h9h*h:h_h#}r@(h%]h,]h']h&]h-]uh@MhAhhB]rAhKXwhere BUFSIZE is the number of bytes you plan on passing as command line parameter to apitest. If in doubt, use a larger number as BUFSIZE denotes the maximum buffer you can allocate.Now run the Translate test, Now run the API test,rBrC}rD(h"j?h/j=ubaubj%)rE}rF(h"X% apitest h/h7h9h*h:j(h#}rG(j*j+h&]h']h%]h,]h-]uh@MhAhhB]rHhKX% apitest rIrJ}rK(h"Uh/jEubaubh\)rL}rM(h"X(e.g) With BUFSIZE=10240rNh/h7h9h*h:h_h#}rO(h%]h,]h']h&]h-]uh@MhAhhB]rPhKX(e.g) With BUFSIZE=10240rQrR}rS(h"jNh/jLubaubj%)rT}rU(h"X% apitest 10240h/h7h9h*h:j(h#}rV(j*j+h&]h']h%]h,]h-]uh@M hAhhB]rWhKX% apitest 10240rXrY}rZ(h"Uh/jTubaubhO)r[}r\(h"XCMEM FAQr]h/h7h9h*h:hSh#}r^(h&]r_Ucmem-faqr`ah']h%]h,]h-]rahauh@NhAhhB]rbhKXCMEM FAQrcrd}re(h"j]h/j[ubaubh\)rf}rg(h"X**Q:** Why am I'm getting this error when loading the CMEM (or other!) driver: "insmod: error inserting 'cmemk.ko': -1 Invalid module format"?h/h7h9h*h:h_h#}rh(h%]h,]h']h&]h-]uh@M hAhhB]ri(j)rj}rk(h"X**Q:**h#}rl(h%]h,]h']h&]h-]uh/jfhB]rmhKXQ:rnro}rp(h"Uh/jjubah:jubhKX Why am I'm getting this error when loading the CMEM (or other!) driver: "insmod: error inserting 'cmemk.ko': -1 Invalid module format"?rqrr}rs(h"X Why am I'm getting this error when loading the CMEM (or other!) driver: "insmod: error inserting 'cmemk.ko': -1 Invalid module format"?h/jfubeubh\)rt}ru(h"X2**A:** This error indicates the CMEM kernel module was built with a different Linux kernel version than the version running on the target. You need to rebuild CMEM against the kernel running on your target. **Q:** Can ``CMEM_getPhys()`` be used to translate **any** virtual address to its physical address?h/h7h9h*h:h_h#}rv(h%]h,]h']h&]h-]uh@MhAhhB]rw(j)rx}ry(h"X**A:**h#}rz(h%]h,]h']h&]h-]uh/jthB]r{hKXA:r|r}}r~(h"Uh/jxubah:jubhKX This error indicates the CMEM kernel module was built with a different Linux kernel version than the version running on the target. You need to rebuild CMEM against the kernel running on your target. rr}r(h"X This error indicates the CMEM kernel module was built with a different Linux kernel version than the version running on the target. You need to rebuild CMEM against the kernel running on your target. h/jtubj)r}r(h"X**Q:**h#}r(h%]h,]h']h&]h-]uh/jthB]rhKXQ:rr}r(h"Uh/jubah:jubhKX Can rr}r(h"X Can h/jtubj)r}r(h"X``CMEM_getPhys()``h#}r(h%]h,]h']h&]h-]uh/jthB]rhKXCMEM_getPhys()rr}r(h"Uh/jubah:j ubhKX be used to translate rr}r(h"X be used to translate h/jtubj)r}r(h"X**any**h#}r(h%]h,]h']h&]h-]uh/jthB]rhKXanyrr}r(h"Uh/jubah:jubhKX) virtual address to its physical address?rr}r(h"X) virtual address to its physical address?h/jtubeubh\)r}r(h"X**A:** In theory, "yes". However, sometime after Linux version 2.6.10 the CMEM kernel module ``get_phys()`` function stopped working for kernel addresses. A new ``get_phys()`` was provided to work with newer kernels, but it was discovered that this new one didn't correctly translate non-direct-mapped kernel addresses, so code was added to CMEM to save the lower/upper bounds of the CMEM blocks' kernel addresses, and manually look for those in ``get_phys()`` before trying more general methods of translation. So, in short, CMEM's ``get_phys()`` doesn't handle non-direct-mapped kernel addresses except the ones that correspond to CMEM's managed memory block(s). **Q:** How does CMEM relate to `DSPLink's POOL `__ feature?h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MhAhhB]r(j)r}r(h"X**A:**h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXA:rr}r(h"Uh/jubah:jubhKXW In theory, "yes". However, sometime after Linux version 2.6.10 the CMEM kernel module rr}r(h"XW In theory, "yes". However, sometime after Linux version 2.6.10 the CMEM kernel module h/jubj)r}r(h"X``get_phys()``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX get_phys()rr}r(h"Uh/jubah:j ubhKX6 function stopped working for kernel addresses. A new rr}r(h"X6 function stopped working for kernel addresses. A new h/jubj)r}r(h"X``get_phys()``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX get_phys()rr}r(h"Uh/jubah:j ubhKX was provided to work with newer kernels, but it was discovered that this new one didn't correctly translate non-direct-mapped kernel addresses, so code was added to CMEM to save the lower/upper bounds of the CMEM blocks' kernel addresses, and manually look for those in rr}r(h"X was provided to work with newer kernels, but it was discovered that this new one didn't correctly translate non-direct-mapped kernel addresses, so code was added to CMEM to save the lower/upper bounds of the CMEM blocks' kernel addresses, and manually look for those in h/jubj)r}r(h"X``get_phys()``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX get_phys()rr}r(h"Uh/jubah:j ubhKXI before trying more general methods of translation. So, in short, CMEM's rr}r(h"XI before trying more general methods of translation. So, in short, CMEM's h/jubj)r}r(h"X``get_phys()``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX get_phys()rr}r(h"Uh/jubah:j ubhKXv doesn't handle non-direct-mapped kernel addresses except the ones that correspond to CMEM's managed memory block(s). rr}r(h"Xv doesn't handle non-direct-mapped kernel addresses except the ones that correspond to CMEM's managed memory block(s). h/jubj)r}r(h"X**Q:**h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXQ:rr}r(h"Uh/jubah:jubhKX How does CMEM relate to rr}r(h"X How does CMEM relate to h/jubhe)r}r(h"XY`DSPLink's POOL `__h#}r(UnameXDSPLink's POOLhiXDhttp://processors.wiki.ti.com/index.php/DSPLink_POOL_Module_Overviewh&]h']h%]h,]h-]uh/jhB]rhKXDSPLink's POOLrr}r(h"Uh/jubah:hnubhKX feature?rr}r(h"X feature?h/jubeubh\)r}r(h"Xd**A:** Though they provide overlapping features, they are independent, and each has unique features.h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@M$hAhhB]r(j)r}r(h"X**A:**h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXA:rr}r(h"Uh/jubah:jubhKX^ Though they provide overlapping features, they are independent, and each has unique features.rr}r(h"X^ Though they provide overlapping features, they are independent, and each has unique features.h/jubeubh3)r}r(h"Uh/h7h9h*h:jkh#}r(jmX-h&]h']h%]h,]h-]uh@M'hAhhB]r(h0)r}r(h"XnCMEM - CMEM can be used on systems without a remote DSP slave (e.g. DM365 codecs require physically contiguous memory when using HW accelerators) - CMEM buffers can be cached - CMEM blocks support fixed size pools (no fragmentation) as well as heaps (easier to use) - CMEM configuration doesn't require a rebuild (they're provided as insmod params) h/jh9Nh:jrh#}r(h%]h,]h']h&]h-]uh@NhAhhB]r(h\)r}r(h"XCMEMrh/jh9h*h:h_h#}r(h%]h,]h']h&]h-]uh@M'hB]rhKXCMEMrr}r(h"jh/jubaubh3)r}r (h"Uh#}r (jmX-h&]h']h%]h,]h-]uh/jhB]r (h0)r }r (h"XCMEM can be used on systems without a remote DSP slave (e.g. DM365 codecs require physically contiguous memory when using HW accelerators)h#}r(h%]h,]h']h&]h-]uh/jhB]rh\)r}r(h"XCMEM can be used on systems without a remote DSP slave (e.g. DM365 codecs require physically contiguous memory when using HW accelerators)rh/j h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@M)hB]rhKXCMEM can be used on systems without a remote DSP slave (e.g. DM365 codecs require physically contiguous memory when using HW accelerators)rr}r(h"jh/jubaubah:jrubh0)r}r(h"XCMEM buffers can be cachedrh#}r(h%]h,]h']h&]h-]uh/jhB]rh\)r}r(h"jh/jh9h*h:h_h#}r(h%]h,]h']h&]h-]uh@M,hB]r hKXCMEM buffers can be cachedr!r"}r#(h"jh/jubaubah:jrubh0)r$}r%(h"XXCMEM blocks support fixed size pools (no fragmentation) as well as heaps (easier to use)h#}r&(h%]h,]h']h&]h-]uh/jhB]r'h\)r(}r)(h"XXCMEM blocks support fixed size pools (no fragmentation) as well as heaps (easier to use)r*h/j$h9h*h:h_h#}r+(h%]h,]h']h&]h-]uh@M-hB]r,hKXXCMEM blocks support fixed size pools (no fragmentation) as well as heaps (easier to use)r-r.}r/(h"j*h/j(ubaubah:jrubh0)r0}r1(h"XQCMEM configuration doesn't require a rebuild (they're provided as insmod params) h#}r2(h%]h,]h']h&]h-]uh/jhB]r3h\)r4}r5(h"XPCMEM configuration doesn't require a rebuild (they're provided as insmod params)r6h/j0h9h*h:h_h#}r7(h%]h,]h']h&]h-]uh@M/hB]r8hKXPCMEM configuration doesn't require a rebuild (they're provided as insmod params)r9r:}r;(h"j6h/j4ubaubah:jrubeh:jkubeubh0)r<}r=(h"XPPOOL - POOL buffers can be allocated on one processor and freed on another h/jh9Nh:jrh#}r>(h%]h,]h']h&]h-]uh@NhAhhB]r?(h\)r@}rA(h"XPOOLrBh/j<h9h*h:h_h#}rC(h%]h,]h']h&]h-]uh@M2hB]rDhKXPOOLrErF}rG(h"jBh/j@ubaubh3)rH}rI(h"Uh#}rJ(jmX-h&]h']h%]h,]h-]uh/j<hB]rKh0)rL}rM(h"XDPOOL buffers can be allocated on one processor and freed on another h#}rN(h%]h,]h']h&]h-]uh/jHhB]rOh\)rP}rQ(h"XCPOOL buffers can be allocated on one processor and freed on anotherrRh/jLh9h*h:h_h#}rS(h%]h,]h']h&]h-]uh@M4hB]rThKXCPOOL buffers can be allocated on one processor and freed on anotherrUrV}rW(h"jRh/jPubaubah:jrubah:jkubeubeubh\)rX}rY(h"XG**Q:** In Linux, how do I set aside the memory carveout that CMEM uses?rZh/h7h9h*h:h_h#}r[(h%]h,]h']h&]h-]uh@M7hAhhB]r\(j)r]}r^(h"X**Q:**h#}r_(h%]h,]h']h&]h-]uh/jXhB]r`hKXQ:rarb}rc(h"Uh/j]ubah:jubhKXA In Linux, how do I set aside the memory carveout that CMEM uses?rdre}rf(h"XA In Linux, how do I set aside the memory carveout that CMEM uses?h/jXubeubh\)rg}rh(h"X**A:** The memory carveout used by CMEM must not be in use by Linux else an error will occur during module loading (i.e., insmod/modprobe). There are two simple methods for defining CMEM's memory carveout:h/h7h9h*h:h_h#}ri(h%]h,]h']h&]h-]uh@M9hAhhB]rj(j)rk}rl(h"X**A:**h#}rm(h%]h,]h']h&]h-]uh/jghB]rnhKXA:rorp}rq(h"Uh/jkubah:jubhKX The memory carveout used by CMEM must not be in use by Linux else an error will occur during module loading (i.e., insmod/modprobe). There are two simple methods for defining CMEM's memory carveout:rrrs}rt(h"X The memory carveout used by CMEM must not be in use by Linux else an error will occur during module loading (i.e., insmod/modprobe). There are two simple methods for defining CMEM's memory carveout:h/jgubeubh3)ru}rv(h"Uh/h7h9h*h:jkh#}rw(jmX-h&]h']h%]h,]h-]uh@M=hAhhB]rxh0)ry}rz(h"X1) kernel command line h/juh9Nh:jrh#}r{(h%]h,]h']h&]h-]uh@NhAhhB]r|cdocutils.nodes enumerated_list r})r~}r(h"Uh#}r(UsuffixrU)h&]h']h%]UprefixrUh,]h-]UenumtyperUarabicruh/jyhB]rh0)r}r(h"Xkernel command line h#}r(h%]h,]h']h&]h-]uh/j~hB]rh\)r}r(h"Xkernel command linerh/jh9h*h:h_h#}r(h%]h,]h']h&]h-]uh@M=hB]rhKXkernel command linerr}r(h"jh/jubaubah:jrubah:Uenumerated_listrubaubaubh\)r}r(h"XThis method involves the kernel command line issued from u-boot. When booting Linux, one may restrict the memory available to Linux by specifying physical memory blocks for Linux to use: "mem=#[KMG]@0xXXXXXXXX" e.g.: mem=128M@0x80000000 mem=256M@0x90000000 which grants the memory at 0x80000000 -> 0x88000000 and 0x90000000 -> 0xa0000000 to Linux, leaving the CMEM memory carveout as 128MB at 0x88000000 (0x88000000 -> 0x90000000). Without a "mem=" entry on the command line, Linux will use all available memory.h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@M?hAhhB]r(hKXThis method involves the kernel command line issued from u-boot. When booting Linux, one may restrict the memory available to Linux by specifying physical memory blocks for Linux to use: "mem=#[KMG]@0xXXXXXXXX" e.g.: rr}r(h"XThis method involves the kernel command line issued from u-boot. When booting Linux, one may restrict the memory available to Linux by specifying physical memory blocks for Linux to use: "mem=#[KMG]@0xXXXXXXXX" e.g.: h/jubhe)r}r(h"Xmem=128M@0x80000000h#}r(UrefuriXmailto:mem=128M@0x80000000h&]h']h%]h,]h-]uh/jhB]rhKXmem=128M@0x80000000rr}r(h"Uh/jubah:hnubhKX r}r(h"X h/jubhe)r}r(h"Xmem=256M@0x90000000h#}r(UrefuriXmailto:mem=256M@0x90000000h&]h']h%]h,]h-]uh/jhB]rhKXmem=256M@0x90000000rr}r(h"Uh/jubah:hnubhKX which grants the memory at 0x80000000 -> 0x88000000 and 0x90000000 -> 0xa0000000 to Linux, leaving the CMEM memory carveout as 128MB at 0x88000000 (0x88000000 -> 0x90000000). Without a "mem=" entry on the command line, Linux will use all available memory.rr}r(h"X which grants the memory at 0x80000000 -> 0x88000000 and 0x90000000 -> 0xa0000000 to Linux, leaving the CMEM memory carveout as 128MB at 0x88000000 (0x88000000 -> 0x90000000). Without a "mem=" entry on the command line, Linux will use all available memory.h/jubeubh4h\)r}r(h"XThis method involves modifying a machine's ``.reserve`` function to remove a block of memory from Linux. For example, for the Vayu architecture, the file arch/arm/mach-omap2/common.c contains a function named ``dra7_reserve()`` which is assigned to the machine ``.reserve`` function in arch/arm/mach-omap2/board-generic.c. Adding the following C statement to ``dra7_reserve()`` accomplishes the same memory carveout as specified in 1) above: ``memory_remove(0x88000000, 0x08000000);`` The CMEM memory carveout can either precede, overlap, or succeed the Linux memory. For the case where it precedes or overlaps, don't forget to specify "allowOverlap=1" on the cmemk.ko insmod/modprobe command, else the module loading will fail. For both cases above, you would load cmemk.ko as follows: % modprobe cmemk.ko phys\_start=0x88000000 phys\_end=0x90000000 allowOverlap=1 pools=... The advantage for method 1) is that the CMEM memory carveout can be specified to be anywhere by the system integrator without changing the kernel, with a disadvantage of having to document this carveout specification along with potential error in doing so. The advantage of method 2) is that a given kernel image will always properly create the carveout for CMEM without any intervention by the system integrator, with a disadvantage of not being moveable without changing/rebuilding the kernel. **Q:** Why CMEM failed in physical address > 32bits?h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MLhAhhB]r(hKX+This method involves modifying a machine's rr}r(h"X+This method involves modifying a machine's h/jubj)r}r(h"X ``.reserve``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX.reserverr}r(h"Uh/jubah:j ubhKX function to remove a block of memory from Linux. For example, for the Vayu architecture, the file arch/arm/mach-omap2/common.c contains a function named rr}r(h"X function to remove a block of memory from Linux. For example, for the Vayu architecture, the file arch/arm/mach-omap2/common.c contains a function named h/jubj)r}r(h"X``dra7_reserve()``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXdra7_reserve()rr}r(h"Uh/jubah:j ubhKX" which is assigned to the machine rr}r(h"X" which is assigned to the machine h/jubj)r}r(h"X ``.reserve``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX.reserverr}r(h"Uh/jubah:j ubhKXV function in arch/arm/mach-omap2/board-generic.c. Adding the following C statement to rr}r(h"XV function in arch/arm/mach-omap2/board-generic.c. Adding the following C statement to h/jubj)r}r(h"X``dra7_reserve()``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXdra7_reserve()rr}r(h"Uh/jubah:j ubhKXA accomplishes the same memory carveout as specified in 1) above: rr}r(h"XA accomplishes the same memory carveout as specified in 1) above: h/jubj)r}r(h"X*``memory_remove(0x88000000, 0x08000000);``h#}r(h%]h,]h']h&]h-]uh/jhB]rhKX&memory_remove(0x88000000, 0x08000000);rr}r(h"Uh/jubah:j ubhKXv The CMEM memory carveout can either precede, overlap, or succeed the Linux memory. For the case where it precedes or overlaps, don't forget to specify "allowOverlap=1" on the cmemk.ko insmod/modprobe command, else the module loading will fail. For both cases above, you would load cmemk.ko as follows: % modprobe cmemk.ko phys_start=0x88000000 phys_end=0x90000000 allowOverlap=1 pools=... The advantage for method 1) is that the CMEM memory carveout can be specified to be anywhere by the system integrator without changing the kernel, with a disadvantage of having to document this carveout specification along with potential error in doing so. The advantage of method 2) is that a given kernel image will always properly create the carveout for CMEM without any intervention by the system integrator, with a disadvantage of not being moveable without changing/rebuilding the kernel. rr}r(h"Xx The CMEM memory carveout can either precede, overlap, or succeed the Linux memory. For the case where it precedes or overlaps, don't forget to specify "allowOverlap=1" on the cmemk.ko insmod/modprobe command, else the module loading will fail. For both cases above, you would load cmemk.ko as follows: % modprobe cmemk.ko phys\_start=0x88000000 phys\_end=0x90000000 allowOverlap=1 pools=... The advantage for method 1) is that the CMEM memory carveout can be specified to be anywhere by the system integrator without changing the kernel, with a disadvantage of having to document this carveout specification along with potential error in doing so. The advantage of method 2) is that a given kernel image will always properly create the carveout for CMEM without any intervention by the system integrator, with a disadvantage of not being moveable without changing/rebuilding the kernel. h/jubj)r}r(h"X**Q:**h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXQ:rr}r(h"Uh/jubah:jubhKX. Why CMEM failed in physical address > 32bits?rr}r(h"X. Why CMEM failed in physical address > 32bits?h/jubeubh\)r}r(h"X**A:** The user space application need to be compiled with “–D\_FILE\_OFFSET\_BITS=64" to allow physical addresses > 32 bits. |h/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MehAhhB]r(j)r}r(h"X**A:**h#}r(h%]h,]h']h&]h-]uh/jhB]rhKXA:rr}r(h"Uh/jubah:jubhKXz The user space application need to be compiled with “–D_FILE_OFFSET_BITS=64" to allow physical addresses > 32 bits. |rr}r(h"X} The user space application need to be compiled with “–D\_FILE\_OFFSET\_BITS=64" to allow physical addresses > 32 bits. |h/jubeubhO)r}r(h"X Licensingrh/h7h9h*h:hSh#}r(h&]rU licensingrah']h%]h,]h-]rhauh@NhAhhB]rhKX Licensingrr}r(h"jh/jubaubh\)r }r (h"XlIn CMEM 2.00, the CMEM Linux release is LGPL v2 for the user mode lib and GPL v2 for the kernel mode driver.r h/h7h9h*h:h_h#}r (h%]h,]h']h&]h-]uh@MlhAhhB]r hKXlIn CMEM 2.00, the CMEM Linux release is LGPL v2 for the user mode lib and GPL v2 for the kernel mode driver.rr}r(h"j h/j ubaubh\)r}r(h"XIn CMEM 2.21, the Linux user mode library licensing changed from LGPL to BSD. The Linux kernel mode driver continued to be GPL v2.rh/h7h9h*h:h_h#}r(h%]h,]h']h&]h-]uh@MohAhhB]rhKXIn CMEM 2.21, the Linux user mode library licensing changed from LGPL to BSD. The Linux kernel mode driver continued to be GPL v2.rr}r(h"jh/jubaubeubh9h*h:jkh#}r(jmX-h&]h']h%]h,]h-]uh@MJhAhhB]rh1aubh9Nh:jrh#}r(h%]h,]h']h&]h-]uh@NhAhhB]rj})r}r(h"Uh#}r(jU)Ustartr Kh&]h']h%]jUh,]h-]jjuh/h1hB]r!h0)r"}r#(h"X.removal via machine's "``.reserve``" function h#}r$(h%]h,]h']h&]h-]uh/jhB]r%h\)r&}r'(h"X-removal via machine's "``.reserve``" functionr(h/j"h9h*h:h_h#}r)(h%]h,]h']h&]h-]uh@MJhB]r*(hKXremoval via machine's "r+r,}r-(h"Xremoval via machine's "h/j&ubj)r.}r/(h"X ``.reserve``h#}r0(h%]h,]h']h&]h-]uh/j&hB]r1hKX.reserver2r3}r4(h"Uh/j.ubah:j ubhKX " functionr5r6}r7(h"X " functionh/j&ubeubah:jrubah:jubaubhB]r8h\)r9}r:(h"X:Enumerated list start value not ordinal-1: "2" (ordinal 2)h#}r;(h%]h,]h']h&]h-]uh/h hB]r<hKX:Enumerated list start value not ordinal-1: "2" (ordinal 2)r=r>}r?(h"Uh/j9ubah:h_ubah:Usystem_messager@ubaUcurrent_sourcerANU decorationrBNUautofootnote_startrCKUnameidsrD}rE(hhhjhjh jh jh jh jIh jhhVhh>hjLhjhjPhjshj`hj(hhhjhjhj%hjuhB]rF(cdocutils.nodes comment rG)rH}rI(h"X5http://processors.wiki.ti.com/index.php/CMEM_Overviewh/hh9h*h:UcommentrJh#}rK(j*j+h&]h']h%]h,]h-]uh@KhAhhB]rLhKX5http://processors.wiki.ti.com/index.php/CMEM_OverviewrMrN}rO(h"Uh/jHubaubh7eh"UU transformerrPNU footnote_refsrQ}rRUrefnamesrS}rTUsymbol_footnotesrU]rVUautofootnote_refsrW]rXUsymbol_footnote_refsrY]rZU citationsr[]r\hAhU current_liner]NUtransform_messagesr^]r_Ureporterr`NUid_startraKU autofootnotesrb]rcU citation_refsrd}reUindirect_targetsrf]rgUsettingsrh(cdocutils.frontend Values riorj}rk(Ufootnote_backlinksrlKUrecord_dependenciesrmNU rfc_base_urlrnUhttps://tools.ietf.org/html/roU tracebackrpUpep_referencesrqNUstrip_commentsrrNU toc_backlinksrsUentryrtU language_coderuUenrvU datestamprwNU report_levelrxKU _destinationryNU halt_levelrzKU strip_classesr{NhHNUerror_encoding_error_handlerr|Ubackslashreplacer}Udebugr~NUembed_stylesheetrUoutput_encoding_error_handlerrUstrictrU sectnum_xformrKUdump_transformsrNU docinfo_xformrKUwarning_streamrNUpep_file_url_templaterUpep-%04drUexit_status_levelrKUconfigrNUstrict_visitorrNUcloak_email_addressesrUtrim_footnote_reference_spacerUenvrNUdump_pseudo_xmlrNUexpose_internalsrNUsectsubtitle_xformrU source_linkrNUrfc_referencesrNUoutput_encodingrUutf-8rU source_urlrNUinput_encodingrU utf-8-sigrU_disable_configrNU id_prefixrUU tab_widthrKUerror_encodingrUUTF-8rU_sourcerX\/home/gtbldadm/nightlybuilds/processor-sdk-doc/source/linux/Foundational_Components_CMEM.rstrUgettext_compactrU generatorrNUdump_internalsrNU smart_quotesrU pep_base_urlrU https://www.python.org/dev/peps/rUsyntax_highlightrUlongrUinput_encoding_error_handlerrjUauto_id_prefixrUidrUdoctitle_xformrUstrip_elements_with_classesrNU _config_filesr]Ufile_insertion_enabledrU raw_enabledrKU dump_settingsrNubUsymbol_footnote_startrKUidsr}r(hhjjjIjDjjjjjjjjjLjGjjhVhPh>h7jjjPjKjsjnj`j[j(j#hhjhjjj%j jjuUsubstitution_namesr}rh:hAh#}r(h%]h&]h']Usourcejh,]h-]uU footnotesr]rUrefidsr}rub.