Changes

D1 and D2 communicates through the [https://en.wikipedia.org/wiki/RPMsg RPMsg protocol]. On the Cortex M7 side, the [https://github.com/NXPmicro/rpmsg-lite RPMsg Lite] implementation by NXP is used. The interface between D1 and D2 comprises a shared memory buffer as well. This area is used to exchange audio samplesbetween the domains. Synchronization messages are exchanged over RPMsg channels instead.

For the sake of simplicity, the audio samples are not captured by the Cortex M7 with a real microphone. They are retrieved from prefilled memory buffers inaccessible to the Cortex A53 cores. For the purposes of discussion, this simplification is neglectable as the communication mechanisms between the domains are not affected at all. Likewise, the inference algorithm could probably be executed by the powerful Cortex M7 core itself. Again, This is not a big deal as the aim of this TN is to show an architectural solution that can be tailored to address more challenging, real-world use cases .

The reserved SDRAM buffers used to store the audio samples are protected at Linux device tree levelto prevent D1 domain from accessing them directly. It is worth remembering that, to restrict accessibility, it is also possible to make use of a hardware-based, stronger protection mechanism thank to by exploiting the i.MX8M Plus Resource Domain Controller (RDC).

The inference application (IAPP) running in D1 uses a simple sysfs-based interface to interact with the firmware running in D2. BasicallyAs such, it the whole operation of the software works like this:

* U-Boot starts* U-Boot and populates the audio samples buffers by retrieving WAV files via TFTP protocol

* U-Boot start Yocto starts the Linux kernel , which then takes control of the Cortex A53 complex

Please note that MFW the Cortex M7 firmware has not to be started before the Linux kernel necessarily. It is also possible to start MFW from the user-space Linux.