[FEATURE] IPC4 on i.MX

[iuliana-prodan]

Is your feature request related to a problem? Please describe. Move to IPC4 for all i.MX platform

• [ ] imx8m (i.MX8MP)
• [ ] imx8 (i.MX8QM)
• [ ] imx8x (i.MX8QXP)
• [ ] 8ulp (i.MX8ULP)

Describe the solution you'd like Use the existing implementation of IPC4 on i.MX.

[iuliana-prodan]

Hi all,

I'm working on enabling IPC4 on i.MX, starting with i.MX8MP (imx8m) and I've found some issues:

1. This include seems Intel specific: https://github.com/thesofproject/sof/blob/main/src/ipc/ipc4/dai.c#L13 I believe it shouldn't be here, right? The IPC4 files should be generic for all platforms, right?

2. These defines are Intel specific: https://github.com/thesofproject/sof/blob/main/src/ipc/ipc4/helper.c#L555

3. basefw_hw_config > this is always compiled and the implementation is Intel specific (at least a part of it). Should we have something similar for i.MX?

4. What is copier_dai - https://github.com/thesofproject/sof/blob/main/src/audio/copier/copier_dai.c#L184? - is compiled by default and it uses some ALH defines, not known by i.MX.

These are all findings on first try compilation of imx8m with CONFIG_IPC_MAJOR_4=y I don't know exactly how to fix some of these, I don't think we want to have (too many) ifdef CONFIG_IMX. :)

Any suggestions, comments are welcome. Thanks!

cc: @lgirdwood @kv2019i @tmleman @lyakh @RanderWang

[marc-hb]

cc: @btian1 @plbossart @ranj063 @aiChaoSONG

[dbaluta]

@lgirdwood @lyakh @kv2019i @plbossart I would also like to understand what is the plan for IPC3. Does Intel still uses it for some boards?

Do you think this should be deprecated?

AFAIK IPC4 was introduce in order for Intel support integration with Windows.

[lgirdwood]

@lgirdwood @lyakh @kv2019i @plbossart I would also like to understand what is the plan for IPC3. Does Intel still uses it for some boards?

No, Intel does NOT use IPC3 for any new devices. All Intel development effort is around IPC4.

Do you think this should be deprecated?

Yes, I think we should like to eventually deprecate IPC3, but we need to get everyone using IPC4 first. This would also mean we can remove an abstraction and further simplify some IPC handling logic and APIs.

AFAIK IPC4 was introduce in order for Intel support integration with Windows.

Yes, IPC4 has better API/feature coverage around the Windows audio architecture and use cases with no loss of flexibility for Linux.

[lgirdwood]

@thesofproject/amd @thesofproject/mediatek @thesofproject/google I think we've all discussed Intel IPC4 direction at previous TSCs, would be good to get feedback on IPC4 and see how we can all eventually integrate IPC4 as it's where the bulk of development is happening today.

[dbaluta]

@lgirdwood I'm thinking to have another TSC around mid-November? Would that work for you?

[lgirdwood]

@lgirdwood I'm thinking to have another TSC around mid-November? Would that work for you?

Works for me. Lots of progress since last TSC and updates that we can all share and align on.

[lgirdwood]

Hi all,

I'm working on enabling IPC4 on i.MX, starting with i.MX8MP (imx8m) and I've found some issues:

1. This include seems Intel specific: https://github.com/thesofproject/sof/blob/main/src/ipc/ipc4/dai.c#L13 I believe it shouldn't be here, right? The IPC4 files should be generic for all platforms, right?

Yes, correct - however, if some IPC4 structures are vendor specific, like we had with DAIs for IPC3 we should make sure we split out vendor specific sections to vendor headers (like with IPC3).

2. These defines are Intel specific: https://github.com/thesofproject/sof/blob/main/src/ipc/ipc4/helper.c#L555

Oh, it sounds like we need a helper-common.c, helper-intel.c and a helper-imx.c and so on for other vendors.

3. basefw_hw_config > this is always compiled and the implementation is Intel specific (at least a part of it).

I would say the same answer here to Q2. we need to split any vendor specific logic.

Should we have something similar for i.MX?

4. What is copier_dai - https://github.com/thesofproject/sof/blob/main/src/audio/copier/copier_dai.c#L184? - is compiled by default and it uses some ALH defines, not known by i.MX.

So the ALH parts are Intel specific and should be split like 2 and 3.

The copier part is generic though, it's job is to copy data to/from DMA buffers in a coherent manner that manages any races wrt DSP FW R/W pointers vs DMA HW R/W pointers. It's also useful to copy data from A->B in pipelines where needed, i.e. some modules need the copier to copy data.

These are all findings on first try compilation of imx8m with CONFIG_IPC_MAJOR_4=y I don't know exactly how to fix some of these, I don't think we want to have (too many) ifdef CONFIG_IMX. :)

Any suggestions, comments are welcome. Thanks!

Lets start with splitting some of the files into common.c and vendor.c, once this compiles lets merge and also merge an IPC4 build test for i.MX i.e. to enforce no vendor specific logic goes into common IPC4 files.

cc: @lgirdwood @kv2019i @tmleman @lyakh @RanderWang

[plbossart]

4. What is copier_dai - https://github.com/thesofproject/sof/blob/main/src/audio/copier/copier_dai.c#L184? - is compiled by default and it uses some ALH defines, not known by i.MX.

There's also a relatively large change in programming models with the use of those copiers. With IPC3 the dais are configured by passing "human-readable" values that are converted into registers in firmware. With the Intel IPC4 implementation, the firmware receives a pre-canned set of register values stored in a binary blob. The binary blob is now generated with the ALSA utils and stored in the binary topology file, that may or may not be suitable for all vendors.

[kv2019i]

Thanks @iuliana-prodan for the list, this is very useful.

Adding to above comments, for (1) and (4) the Zephyr DAI interface (zephyr/include/zephyr/drivers/dai.h) is close copy of the DAI interface we had in SOF, so it should be straighforward to add non-Intel DAI implementations (as we had those in SOF DAIs as well). There's already e.g. types for DAI_IMX_SAI and DAI_IMX_ESAI in there in upstream Zephyr. Like Pierre noted, we change the parameter passing interface so that dai_config_set() gets a binary blob as bepsoke data. This matches Intel uses where we get such blobs e.g. from ACPI/NHLT. But we did also implement IPC3 support using the Zephyr DAI interface, so this should be doable as well (or define a IPC3-like-DAI-parameters container that can be used with IPC4 messages).

For (3) on baseconfig, I think parts of this could be retrieved from Zephyr device-tree data, in a platform agnostic manner. For the information that is not related to hardware properties as such, I think we could use the platform.h abstraction (see https://github.com/thesofproject/sof/issues/7248) to implement vendor/board specific way to get these properties and have common code in src/ipc/ipc4 for the handler. I filed https://github.com/thesofproject/sof/issues/8391 to track this.

[iuliana-prodan]

Thanks @iuliana-prodan for the list, this is very useful.

Adding to above comments, for (1) and (4) the Zephyr DAI interface (zephyr/include/zephyr/drivers/dai.h) is close copy of the DAI interface we had in SOF, so it should be straighforward to add non-Intel DAI implementations (as we had those in SOF DAIs as well). There's already e.g. types for DAI_IMX_SAI and DAI_IMX_ESAI in there in upstream Zephyr. Like Pierre noted, we change the parameter passing interface so that dai_config_set() gets a binary blob as bepsoke data. This matches Intel uses where we get such blobs e.g. from ACPI/NHLT. But we did also implement IPC3 support using the Zephyr DAI interface, so this should be doable as well (or define a IPC3-like-DAI-parameters container that can be used with IPC4 messages).

@kv2019i I'm working on IPC4 with SOF drivers (not Zephyr native drivers). As mentioned here I thought that is possible IPC4 with legacy DAI and DMA drivers (from SOF). On native drivers is working @LaurentiuM1234. And we are trying to do this is parallel.

You think is better to have everything in Zephyr and then try IPC4?

For (3) on baseconfig, I think parts of this could be retrieved from Zephyr device-tree data, in a platform agnostic manner. For the information that is not related to hardware properties as such, I think we could use the platform.h abstraction (see #7248) to implement vendor/board specific way to get these properties and have common code in src/ipc/ipc4 for the handler. I filed #8391 to track this.

For base_fw I also see this issue: https://github.com/thesofproject/sof/issues/7549 Can we, for i.MX disable it? Now, with IPC4 is required, but not very sure what is used for? Since is more Intel based, I would try to disable it for i.MX.. for now, at least. What do you think?

[kv2019i]

Ack @iuliana-prodan , SOF drivers should still be doable. We did the initial IPC4 work with SOF driver interface and only later moved to native drivers, so both have worked. But just noting that when we added the DAI interface to Zephyr, we did think of bringing all SOF users onboard, so that is not Intel specific by design.

For basefw, ack on that, I think most of those are not used. You can grep the Linux SOF driver on what fields are used in Linux (e.g. sof_ipc4_query_fw_configuration() shows a few field - I think only a few are really needed for functionality), and for rest, you can start by just not filling those values or having incorrect data in them. The full set of fw/hw properties is used by Intel Windows SW stack,

[iuliana-prodan]

While trying to load FW for IPC I'm getting different errors related with extended manifest (or header) for .ri image, sof-audio-of-imx8m 3b6e8000.dsp: Unexpected extended manifest magic number: 0x6e614d58 or

sof-audio-of-imx8m 3b6e8000.dsp: Invalid fw_header->len 2453732000
sof-audio-of-imx8m 3b6e8000.dsp: error: firmware imx/sof/sof-imx8m.ri contains unsupported or invalid extended manifest: -22

I've check and the extended manifest is computed (or a part of it) and parsed in rimage.

Now, for imx8m we have: version = [1, 0] # use simple file write in config toml file. So it uses parse_adsp_config_v1_0() and simple_write_firmware() to write_firmware and NULL for write_firmware_meu.

I've tried to use a higher version, like version = [2, 5], but in parse_adsp_config_v2_5() there are a lot of required sections for toml config file, like:

• adsp
• cse
• css
• signed_pkg
• module I've tried to skip them (leave only the adsp.name and adsp.mem_zone as we have now in imx8m.toml), but still getting some errors:

  Signing with tool /opt/samba/nxa06898/sof/build-rimage/rimage
  Signing for SOC target imx8m
  /opt/samba/nxa06898/sof/build-rimage/rimage -o /opt/samba/nxa06898/sof/build-imx8m/zephyr/zephyr.ri -k 'key param ignored by imx8m' -f 2.7.99 -b 1 -c /opt/samba/nxa06898/sof/sof/tools/rimage/config/imx8m.toml -e /opt/samba/nxa06898/sof/build-imx8m/zephyr/zephyr.elf
  error: 'alias_mask' not found
  malloc(): memory corruption

  So, my questions are:

• which sections (or fields from sections) are required for IPC4?
• do we need a custom parse_adsp_config() for i.MX or can we reuse an existing one?

Thanks!

cc: @marc-hb @kv2019i @lgirdwood @RanderWang @singalsu @dbaluta @LaurentiuM1234

[iuliana-prodan]

For the MAGIC_NUMBER I saw we use a new one for IPC4:

• defined here https://elixir.bootlin.com/linux/latest/source/include/sound/sof/ext_manifest4.h#L22
• checked here: https://elixir.bootlin.com/linux/latest/source/sound/soc/sof/ipc4-loader.c#L51
• set only here, for Intel cavs 2.5 or ace 1.5: https://github.com/thesofproject/rimage/blob/main/src/ext_manifest.c#L196C37-L196C37 So, this is why I tried to use version = [2, 5], but I'm getting other issues - mentioned above.

[lgirdwood]

@iuliana-prodan could you try a "copy exactly" of an Intel toml file and only modify memory related data (I would probably use mtl toml file). I've put some inline comments below that may help/hinder you ;)

[adsp]
name = "mtl"  <<< I hope this has no impact to rimage, but you can try keeping it the same.
image_size = "0x2C0000" # (22) bank * 128KB   << should be safe, its a max size
alias_mask = "0xE0000000"      << Intel only - it a memory alias for uncache, try keeping the same or pointing to the base of your RAM. 

[[adsp.mem_zone]]   <<<< I would leave ROM the same
type = "ROM"
base = "0x1FF80000"
size = "0x400"
[[adsp.mem_zone]]  <<< ditto as ROM
type = "IMR"
base = "0xA104A000"
size = "0x2000"
[[adsp.mem_zone]]   <<< This is the base of your SRAM where FW is copied.
type = "SRAM"
base = "0xa00f0000"
size = "0x100000"

[[adsp.mem_alias]]  << these two are Intel specific, I would try leaving them or change them to your SRAM addr.
type = "uncached"
base = "0x40000000"
[[adsp.mem_alias]]
type = "cached"
base = "0xA0000000"

[cse]  << leave all this the same
partition_name = "ADSP"
[[cse.entry]]
name = "ADSP.man"
offset = "0x5c"
length = "0x464"
[[cse.entry]]
name = "ADSP.met"
offset = "0x4c0"
length = "0x70"
[[cse.entry]]
name = "ADSP"
offset = "0x540"
length = "0x0"  # calculated by rimage

[css]  << ditto, dont touch

[signed_pkg]
name = "ADSP"
partition_usage = "0x23"
[[signed_pkg.module]]
name = "ADSP.met"

[adsp_file]  << this is the offset from start of manifest (not ext manifest) to FW TEXT.
[[adsp_file.comp]]
base_offset = "0x2000"

[fw_desc.header]  <<<< this is the size of the file excluding ext manifest to nearest page (round up) dont think this matter for NXP, used on Intel to verify signature.
name = "ADSPFW"
load_offset = "0x40000"

[module]
count = 19  <<< total count of modules in the FW file.
    [[module.entry]]   <<< NXP probably dont need this module as it loads BASEFW module into SRAM on Intel.
    name = "BRNGUP"
    uuid = "2B79E4F3-4675-F649-89DF-3BC194A91AEB"
    affinity_mask = "0x1"
    instance_count = "1"
    domain_types = "0"
    load_type = "0"
    module_type = "0"
    auto_start = "0"

    [[module.entry]]  << This module should be your entry point on NXP. Pls dont modify the data here as it should be generic and work..
    name = "BASEFW"
    uuid = "0E398C32-5ADE-BA4B-93B1-C50432280EE4"
    affinity_mask = "3"
    instance_count = "1"
    domain_types = "0"
    load_type = "0"
    module_type = "0"
    auto_start = "0"

[lgirdwood]

For the MAGIC_NUMBER I saw we use a new one for IPC4:

• defined here https://elixir.bootlin.com/linux/latest/source/include/sound/sof/ext_manifest4.h#L22
• checked here: https://elixir.bootlin.com/linux/latest/source/sound/soc/sof/ipc4-loader.c#L51
• set only here, for Intel cavs 2.5 or ace 1.5: https://github.com/thesofproject/rimage/blob/main/src/ext_manifest.c#L196C37-L196C37 So, this is why I tried to use version = [2, 5], but I'm getting other issues - mentioned above.

Try version = [3, 0] as this is used for MTL (and what most of Intel folks using with IPC4).

[iuliana-prodan]

@lgirdwood @plbossart @kv2019i @lyakh @RanderWang @marc-hb

I've tried version = [3, 0] for imx8m.toml and I encountered some restrictions that doesn't apply to i.MX.

1. Why we only have 3 segments for sof_man_module https://github.com/thesofproject/sof/blob/main/tools/rimage/src/include/rimage/sof/user/manifest.h#L103 ? This is not valid for i.MX where the TEXT or BSS sections are NOT contiguous:

Found 47 sections, listing valid sections...
    No  LMA     VMA     End     Size    Type    Name
    1   0x3b6f8000  0x3b6f8000  0x3b6f8121  0x121   TEXT    .ResetVector.text
    2   0x3b6f8400  0x3b6f8400  0x3b6f856a  0x16a   TEXT    .WindowVectors.text
    3   0x3b6f857c  0x3b6f857c  0x3b6f857f  0x3 TEXT    .Level2InterruptVector.text
    4   0x3b6f859c  0x3b6f859c  0x3b6f859f  0x3 TEXT    .Level3InterruptVector.text
    5   0x3b6f85bc  0x3b6f85bc  0x3b6f85bf  0x3 TEXT    .DebugExceptionVector.text
    6   0x3b6f85dc  0x3b6f85dc  0x3b6f85df  0x3 TEXT    .NMIExceptionVector.text
    7   0x3b6f85fc  0x3b6f85fc  0x3b6f85ff  0x3 TEXT    .KernelExceptionVector.text
    8   0x3b6f861c  0x3b6f861c  0x3b6f8632  0x16    TEXT    .UserExceptionVector.text
    9   0x3b6f863c  0x3b6f863c  0x3b6f8642  0x6 TEXT    .DoubleExceptionVector.text
    10  0x3b6f8658  0x3b6f8658  0x3b6f8718  0xc0    TEXT    .iram.text
    11  0x92400000  0x92400000  0x924103dc  0x103dc DATA    .rodata
    12  0x924103dc  0x924103dc  0x9243a6b6  0x2a2da TEXT    .text
    13  0x9243a6b8  0x9243a6b8  0x9243a7b8  0x100   DATA    initlevel
    14  0x9243a7b8  0x9243a7b8  0x9243a7e0  0x28    DATA    device_area
    15  0x9243a7e0  0x9243a7e0  0x9243a998  0x1b8   DATA    log_const_area
    16  0x9243a998  0x9243a998  0x9243a9a8  0x10    DATA    log_backend_area
    17  0x9243a9a8  0x9243a9a8  0x9243aa14  0x6c    DATA    .fw_ready
    18  0x9243aa20  0x9243aa20  0x92443e20  0x9400  BSS .noinit
    19  0x92443e20  0x92443e20  0x92445000  0x11e0  DATA    .data
    20  0x92445000  0x92445000  0x92445100  0x100   DATA    sw_isr_table
    21  0x92445100  0x92445100  0x92445104  0x4 DATA    device_states
    22  0x92445104  0x92445104  0x9244513c  0x38    DATA    log_mpsc_pbuf_area
    23  0x9244513c  0x9244513c  0x92445140  0x4 DATA    log_msg_ptr_area
    24  0x92445140  0x92445140  0x92445154  0x14    DATA    k_heap_area
    25  0x92445154  0x92445154  0x92445164  0x10    DATA    k_sem_area
    26  0x92445180  0x92445180  0x924465c8  0x1448  BSS .bss
    27  0x92c05000  0x92c05000  0x933f9000  0x7f4000    BSS .heap_mem

I get errors on man_copy_sram() - https://github.com/thesofproject/sof/blob/main/tools/rimage/src/manifest.c#L143

For this I'm thinking of 3 possible solutions: A. Split the elf in 2 (or multiple) .mod files with the sections corresponding to IRAM, or SDRAM in a different .mod file. B. Add a new sof_man_module_type - IPC3 legacy fw load (now there are only 2 for load_type - https://github.com/thesofproject/sof/blob/main/tools/rimage/src/include/rimage/sof/user/manifest.h#L25). Based on this new type we (for i.MX) will not use the 3 segments (we might have more). C. Compile SOF for IPC4, but have the .ri image formatted as for IPC3.

Which should be better?

2. How is the fw loaded in Linux?

For IPC3 we have load_fw_to_dsp operation which is not used for IPC4. IIUC, for IPC4, there's the .run op, which does hda_dsp_cl_boot_firmware(), which does a memcpy of the fw data to an address.

Can I use the ipc3 ops for loading? This means Solution C from 1.

3. What is the benefit of using IPC4 over IPC3?

Right now IPC4 seems over complicated and I don't understand its purpose.

Thank you!

[lyakh]

This is not valid for i.MX where the TEXT or BSS sections are NOT contiguous:

Sorry, I don't know details of your platform. How do you load your firmware image to the DSP? Which parts do you copy to DSP's memory? I see two address ranges above: one starting with 0x3b6f8000 and another one starting with 0x92400000. The former contains exception vectors and similar things, the latter contains the usual .data, .text, .bss, .rodata, and custom sections. But if you include those custom sections, of which the largest one is .noinit with 0x9400 (37KiB) bytes apparently zero-initialised data (BSS type), that address range is contiguous. Could you move .noinit to the end to merge it with .bss to avoid loading them? Do you need to copy all the rest like "initlevel," "sw_isr_table," etc.?

[dbaluta]

@lyakh @iuliana-prodan I think we might be facing here the same problem we had for IPC3.

We describe memory blocks to be loaded based on their physical type (e.g IRAM, ROM, SRAM, SDRAM) while the current implementation (I guess) describe a memory block based on their logical memory type (e.g TEXT, DATA, RODATA).

In the case of IMX we have multiple sections for TEXT (which aren't placed in the same physical memory area, eg. we load some parts of the TEXT into IRAM and some part of the text into SDRAM).

Relevant past modifications for IPC3:

https://github.com/thesofproject/rimage/commit/b65618612b1904548de76bf8564f9d27d5686f0a https://github.com/thesofproject/rimage/commit/42aca3d129179577b6b362e4d9a0a42e431b4f43

I will have a deeper look together with @iuliana-prodan on this issue.

[lgirdwood]

@dbaluta @iuliana-prodan on Intel the older platforms did have separate and non contiguous IRAM and DRAM, they were based on IPC3 and did not have a complex manifest.

Fwiw, today's manifest does allow for placing TEXT, DATA, BSS from many different manifest modules (not real modules, but the manifests ability to split up binaries) into multiple non contiguous memory locations. IIRC, Intel uses this feature on some platforms for a "BRNGUP" bring up module (second stage bootloader).

TBH, it sounds like your current code loading manifest may be best suited for NXP arch. This manifest does not prevent IPC4 usage, IPC version is not tightly bound to the code loading manifest. However, the "extended manifest" is needed for IPC4 and this is pre-pended in front of the code loading manifest (it's parsed by the driver but not copied to DSP. I think this is @iuliana-prodan solution C above).

[iuliana-prodan]

@kv2019i @lgirdwood @lyakh I’ve tried using IPC4 with topology 1, but I got into a lot of trouble.

When trying to load the topology I get:

[   20.737979] sof-audio-of-imx8m 3b6e8000.dsp:  loading topology:imx/sof-tplg/sof-imx8mp-wm8960.tplg
[   20.766425] asoc-simple-card sof-sound-wm8960: soc-topology: soc_tplg_manifest_load > manifest()
[   20.775492] sof-audio-of-imx8m 3b6e8000.dsp: topology: sof_manifest > parse_manifest()
[   20.801234] sof-audio-of-imx8m 3b6e8000.dsp: sof_ipc4_parse_manifest: Invalid topology ABI size: 3
[   20.812955] asoc-simple-card sof-sound-wm8960: ASoC: topology: could not load header: -22
[   20.823354] sof-audio-of-imx8m 3b6e8000.dsp: error: tplg component load failed -22
[   20.831789] sof-audio-of-imx8m 3b6e8000.dsp: error: failed to load DSP topology -22
[   20.840189] sof-audio-of-imx8m 3b6e8000.dsp: ASoC: error at snd_soc_component_probe on 3b6e8000.dsp: -22
[   20.854721] asoc-simple-card sof-sound-wm8960: ASoC: failed to instantiate card -22
[   20.870093] asoc-simple-card: probe of sof-sound-wm8960 failed with error -22

Then, I’ve tried to load the tplg using IPC3 ops:

diff --git a/sound/soc/sof/ipc4.c b/sound/soc/sof/ipc4.c
index 95b838efc1da..83781513f99b 100644
--- a/sound/soc/sof/ipc4.c
+++ b/sound/soc/sof/ipc4.c
@@ -790,7 +790,7 @@ const struct sof_ipc_ops ipc4_ops = {
       .get_reply = sof_ipc4_get_reply,
       .pm = &ipc4_pm_ops,
       .fw_loader = &ipc3_loader_ops,
-       .tplg = &ipc4_tplg_ops,
+       .tplg = &ipc3_tplg_ops,
       .pcm = &ipc4_pcm_ops,
       //.fw_tracing = &ipc4_mtrace_ops,
};

In this case from Linux, for tplg1, we send IPC3 commands which arrive in sof_ipc4_tx_msg, which only accepts IPC4 commands. Even if I try to convert them to IPC4 like commands, they are not accepted by SOF which only expects IPC4 commands.

...
[   22.803814] asoc-simple-card sof-sound-wm8960: ASoC: Parent card not yet available, widget card binding deferred
[   22.817817] sof-audio-of-imx8m 3b6e8000.dsp: tplg: config SAI3 fmt 0x1 mclk 12288000 width 32 slots 2 mclk id 0
[   22.817842] sof-audio-of-imx8m 3b6e8000.dsp: tplg: config SAI3 fmt 0x1 mclk 12288000 width 32 slots 2 mclk id 0
[   22.817855] sof-audio-of-imx8m 3b6e8000.dsp: IPC4: sof_ipc4_tx_msg
[   22.817863] sof-audio-of-imx8m 3b6e8000.dsp: IPC4: ipc4_tx_msg_unlocked
[   22.817866] sof-audio-of-imx8m 3b6e8000.dsp: ipc tx      : 0x30|0x30100000: GLB_BOOT_CONFIG [data size: 8589934603]
[   22.817896] sof-audio-of-imx8m 3b6e8000.dsp: imx8m_send_msg - msg_data->data_ptr 0xa
[   22.817899] sof-audio-of-imx8m 3b6e8000.dsp: imx8m_send_msg - msg_data->data_size 8589934603
[   22.817949] Modules linked in: caamhash_desc caamalg_desc crypto_engine authenc libdes snd_soc_imx_card snd_soc_imx_hdmi crct10dif_ce polyval_ce polyval_generic dw_hdmi_cec snd_soc_fsl_xcvr snd_soc_fsl_easrc snd_soc_fsl_aud2htx snd_soc_fsl_asrc snd_soc_fsl_sai snd_soc_fsl_micfil snd_soc_fsl_utils snd_sof_imx8m imx_pcm_dma flexcan imx8_media_dev(C) snd_sof_xtensa_dsp snd_sof_of snd_soc_wm8960 imx_common snd_sof can_dev caam secvio error snd_sof_utils fuse
[   23.101437] lr : sof_mailbox_write+0x2c/0x38 [snd_sof]
[   23.187354]  imx8m_send_msg+0x178/0x17c [snd_sof_imx8m]
[   23.192588]  sof_ipc_send_msg+0x80/0xc0 [snd_sof]
[   23.197326]  ipc4_tx_msg_unlocked+0x94/0x2c0 [snd_sof]
[   23.202495]  sof_ipc4_tx_msg+0x94/0x150 [snd_sof]
[   23.207232]  sof_ipc_tx_message+0x34/0x48 [snd_sof]
[   23.212141]  sof_ipc3_widget_setup+0x4c/0xf4 [snd_sof]
[   23.217307]  sof_widget_setup_unlocked+0x108/0x324 [snd_sof]
[   23.222996]  sof_widget_setup+0x34/0x58 [snd_sof]
[   23.227730]  sof_ipc3_set_up_all_pipelines+0xbc/0x28c [snd_sof]
[   23.233680]  sof_complete+0x2c8/0x32c [snd_sof]
[   23.243215]  snd_sof_load_topology+0xd4/0x134 [snd_sof]
[   23.248469]  sof_pcm_probe+0x64/0x13c [snd_sof]
root@imx8mpevk:~#

So, to move forward, I only have one option to move to topology2. As it is right now, SOF with IPC4 doesn't work with topology1.

[lgirdwood]

oh, ok - I guess topology 1 is missing some components/modules that will requirements for ipc4. Can you try and modifying an simple Intel based topology2 machine for NXP and see how that goes. Pls note that IPC4 has a new module called copier that will be used in many places by default (i.e. dont remove it from your test)