Template:Glsdk ipc

The table below shows the remote cores and their corresponding definitions in the kernel dtsi files, as well as the argument to be used in the loading/unloading commands.

For example, the argument of  corresponds to IPU2 as can be seen from. ipu2: ipu@55020000 { compatible = &quot;ti,dra7-rproc-ipu&quot;; In the sections below,  will be used as the example. For a specific use case, please select the corresponding argument which is applicable.

Unloading and loading remotecores at runtime
It is possible to unload and reload a remotecore at runtime from Linux using the  interface.

target $ cd /sys/bus/platform/drivers/omap-rproc/ target $ echo 55020000.ipu > unbind target $ echo 55020000.ipu > bind

The  command tears down the communication channels between the A15 and the remotecore and unloads the remotecore. Any application level shutdown that needs to be performed needs to be handled by the system integrator.

The  loads the appropriate firmware binary onto the remotecore.

Changing the remotecore binary at runtime
To change the remotecore binary at runtime


 * 1) Unload the remotecore using.
 * 2) Change the remotecore binary in the firmware folder. Default location is   on the target filesystem.
 * 3) Load the remotecore using.

target $ cd /sys/bus/platform/drivers/omap-rproc/ target $ echo 55020000.ipu &gt; unbind target $ cp /home/root/new-binary.xem4 /lib/firmware/dra7-ipu2-fw.xem4 target $ echo 55020000.ipu &gt; bind

If it is desirable to avoid overwriting the existing remote binaries, the method of symbolic links can be used instead of direct copy. For example, Processor SDK provides two types of DSP remotecore binaries: one for DSPDCE (dra7-dsp1-fw.xe66.dspdce-fw) and another one for OpenCL (dra7-dsp1-fw.xe66.opencl-monitor). dra7-dsp1-fw.xe66 is created as a symbolic link by default pointing to the OpenCL binary. When it is needed to switch to DSPDCE, the symbolic link of dra7-dsp1-fw.xe66 can be updated pointing to dra7-dsp1-fw.xe66.dspdce-fw.

target $ cd /sys/bus/platform/drivers/omap-rproc/ target $ echo 40800000.dsp &gt; unbind target $ rm /lib/firmware/dra7-dsp1-fw.xe66 target $ ln -s /lib/firmware/dra7-dsp1-fw.xe66.dspdce-fw /lib/firmware/dra7-dsp1-fw.xe66 target $ echo 40800000.dsp &gt; bind

After the switch, copycodectest application can be run to verify that DSPDCE firmware is loaded. This application fills the input buffer with a number entered as the argument and after process the output buffer is tested for the same pattern.

usage: copycodectest pattern.

Example: target # copycodectest 123

Sample console output: root@am57xx-evm:~# copycodectest 123 0x22070: Opening Engine.. Created dsp_universalCopy Fill input buffer with pattern 123 Verifing the UniversalCopy algorithm copycodectest executed successfully

Loading firmware during initial boot without using udev
During the default boot, firmware is supplied to the kernel by. Starting the  service on boot causes a few seconds increase in boot time. In cases where a quick boot is required, the user may not start the  service in boot. In such cases, firmware can be supplied to the kernel using the sysfs interface. An example script is shown below.

FW_NAMES=&quot;dra7-dsp1-fw.xe66 dra7-dsp2-fw.xe66 dra7-ipu1-fw.xem4 dra7-ipu2-fw.xem4&quot; for FW in $FW_NAMES ; do   echo 1 &gt; /sys/class/firmware/$FW/loading cat /lib/firmware/$FW &gt; /sys/class/firmware/$FW/data echo 0 &gt; /sys/class/firmware/$FW/loading done

{{#ifeq: {{{processor}}} | AM57xx |

Handling the IPU bitbanding region
The ARM Cortex-M4 memory map includes a bit-banding region of memory from 0x4000:0000 to 0x400F:FFFF and 0x4200:0000 to 0x43FF:FFFF. Here is a Cortex-M4 memory map picture from ARM:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDBIJJE.html

Many Vayu components running on the IPUs, including IPC, must access peripherals physically located in this bit-banding region. As a result, these accesses must be performed indirectly using a virtual memory address, mapped using the IPU's AMMU.

Many of the components aligned on mapping this memory using one Large AMMU page that maps 512M of physical memory beginning at 0x4000:0000 to virtual memory beginning at 0x6000:0000. Then the components (by default) access the peripherals using the 0x6XXX:XXXX address space.

IPC specifics
IPC follows the convention of, by default, accessing memory physically located at 0x4XXX:XXXX using virtual memory at 0x6XXX:XXXX. You can see an example of this here - note the mailbox addresses configured here are in the 06XXX:XXXX range:

http://git.ti.com/cgit/cgit.cgi/ipc/ipcdev.git/tree/packages/ti/sdo/ipc/family/vayu/InterruptIpu.xs

In that same file, you can see that these addresses are configurable, and the default 0x6XXX:XXXX addresses are only used if other addresses haven't already been configured by the system integrator (e.g. in a .cfg script). Users can override these default mailbox addresses using the ti.sdo.ipc.family.vayu.InterruptIpu module's mailboxBaseAddr[] array, documented here:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/latest/docs/cdoc/ti/sdo/ipc/family/vayu/InterruptIpu.html#metamailbox.Base.Addr }}