[Sound-open-firmware] Zephyr memory allocation from heap
Daniel Baluta
daniel.baluta at gmail.com
Tue Aug 23 11:04:18 CEST 2022
I see. We've done this in the past.
But with https://github.com/thesofproject/sof/pull/3602
but for i.MX8 PLATFORM_DCACHE_ALIGN is 128 and with XTOS memory management
we got some -ENOMEM.
This seems to be because all blocks < 128 bytes could not be used with
such a big alignment size.
Any idea, why SOF with XTOS requires that all allocations to be
aligned to cache line size?
Thanks,
Daniel.
On Mon, Aug 22, 2022 at 10:50 PM Girdwood, Liam R
<liam.r.girdwood at intel.com> wrote:
>
> On Mon, 2022-08-22 at 16:44 +0000, Daniel Baluta wrote:
> > + andyross at google.com
> >
> >
> > Subject: Re: [Sound-open-firmware] Zephyr memory allocation from
> > heap
> > + Andy, as he also worked on the initial zephyr with SOF.
> >
> > On Mon, Aug 22, 2022 at 5:04 PM Daniel Baluta
> > <daniel.baluta at gmail.com> wrote:
> > >
> > > Hi guys,
> > >
> > > Did you encountered any problems with memory allocations when
> > > switching to Zephyr?
> > >
> > > I'm facing a very strange issue with a playback pipeline with
> > > module
> > > adapter (MP3) where
> > > it looks like the DAI hits underruns as soon as I start the
> > > pipeline.
> > >
> > > With normal PCM playback everything works fine.
> > >
> > > I think it might be a problem in the sense Zephyr allocates memory
> > > and/or Cadence
> > > memory alignment requirements?
> > >
> > > Looks like as soon as I change this:
> > >
> > > -#define PLATFORM_DCACHE_ALIGN sizeof(void *)
> > > +#define PLATFORM_DCACHE_ALIGN 32
> > >
> > >
> > > everything seems to work.
> > >
> > > But I cannot find any logical explanation.
> >
> >
> The cache line size should align to the value in core-isa.h.
>
> IIRC, I think the sizeof(void*) is a catch all when its not defined.
>
> Liam
More information about the Sound-open-firmware
mailing list