[Sound-open-firmware] SOF Zephyr and ARM support on STM32

[Daniel Baluta]

On Thu, May 23, 2019 at 2:00 PM Liam Girdwood
<liam.r.girdwood at linux.intel.com> wrote:
>
> On Thu, 2019-05-23 at 09:28 +0000, Calvin AGENEAU wrote:
> > Hello SOF subscribers,
> >
> > I am currently in my 5th year of Master's degree as an intern at ST
> > Microelectronics and my internship subject is the porting of SOF to
> > the latest STM32 card.
> > I come to you because I couldn't find information about the
> > implementation of SOF in Zephyr and about ARM architecture, I only
> > found information for Xtensa and Baytrail in the official
> > documentation.
> > Can someone gives me advices ?
>
> This is still WiP internally, but I will put you in contact with the
> Zephyr folks at Intel and see if we can create a branch to do this work
> in public. What architecture is your DSP core ? I'm assuiming STM32 has
> large ARM cores for Linux but a smaller core for DSP audio ?
>
> The intention is to take the pipeline, topology, audio processing code
> and some drivers an craete a Zephyr "process" for each pipeline using
> the Zephyr EDF scheduler. This way things should be able to run on ARM
> DSP target nicely.
>

I am also interested in seeing SOF on Zephyr. If Intel folks could
provide a public branch this would be awesome :).

> There are some items that dont depend on this branch :-
>
> 1) Linux driver support. The driver should already build and run on ARM
> but you will need to add some HW abstraction for the STM32. This will
> allow the STM32 to send and receive IPC messages, load FW and boot FW.
> I also think it will need device tree support but maybe Daniel has
> already done this ?

I already have a build working on arm64 (i.MX8) with device tree support. Will
send the patches for this in the next weeks.

What is your setup? We are using Linux kernel on Application processor
(i.MX8 family)
and SOF FW on Hifi4 DSP processor.

>
> 2) Intrinsic or vectorisation support for ARM DSP. Some of the audio
> processing component give better performance using SIMD optimisations.
> The audio components have support for generic C processing and xtensa
> intrinsics, but are missing any intrinsic support fro ARM (meaning
> generic C version is used)