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@intel.com wrote:
On Mon, 2022-08-22 at 16:44 +0000, Daniel Baluta wrote:
- andyross@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@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