rpmsg without remoteproc?

[infn-ke]

Can I use rpmsg without remoteproc or are they coupled? I only want to use rpmsg to communicate over a shared memory. I have two UIO interfaces, one for the interrupt and one for the shared memory, what is the required steps to do that?

[arnopo]

Please have look to this Zephyr sample: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/ipc/openamp
it implements the RPMsg without remoteproc.
Another interesting link that implements an abstraction layer:
https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/ipc/rpmsg_service

[infn-ke]

Please have look to this Zephyr sample: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/ipc/openamp
it implements the RPMsg without remoteproc.
Another interesting link that implements an abstraction layer:
https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/ipc/rpmsg_service

Thanks will have a look at it.

[infn-ke]

@arnopo the Zephyr doc states that one of the apps can run with Linux rpmsg_client_sample. But how to provide shared memory and interrupt resources to the rpmsg_client_sample kernel module?

[arnopo]

The Zephyr application you mention is :
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/ipc/openamp_rsc_table
This sample implements only the slave part, relying on the resource table, so the OpenAMP remoteproc.

rpmsg_client_sample is a Linux kernel sample relying to the rpmsg, remoteproc and mailbox Linux kernel frameworks ( not use the OpenAMP lib). The IRQ are managed by the mailbox Linux kernel framework, the shared memory is managed the remoteproc Linux kernel framework.
So this example does probably not match with your expectation.

Regarding your initial request (based on OpenAMP lib): the IRQs and shared memories are generally implemented in a back-end that is specific to your platform. There is not defined steps but some examples.
Zephyr provides some, the OpenAMP provides some other (but based on the remoteproc) implemented in the platform_info.c files.
I therefore suggest that you take one of these examples as a starting point and adapt it to your platform need.

[infn-ke]

But is the zephyr sample compatible with Linux kernel implementation of rpmsg? E.g. VRING_TX_ADDRESS is placed somewhere in the shared memory (VDEV_START_ADDR + SHM_SIZE). I thought they ring would start at SHM_START_ADDR?

https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/subsys/ipc/openamp/common.h#L23

[arnopo]

No it is not compatible with the Linux kernel generic virtio rpmsg. Only the https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/ipc/openamp_rsc_table is.

Your need is not crystal clear. What exactly is your software architecture? it is relying on OpenAMp lib, or Linux kernel RPMsg drivers?

[infn-ke]

I'm trying to interop openamp with Linux kernel rpmsg. Or possibly rpmsg_lite and Linux kernel rpmsg.

[arnopo]

I'm trying to interop openamp with Linux kernel rpmsg. Or possibly rpmsg_lite and Linux kernel rpmsg.

The generic implementation of the RPMsg in the Linux kernel uses the Virtio backend. The communication protocol is instantiated by the Linux remoteproc framework based on a resource table. If you want to reuse this implementation, you will neede to declare a resource table and use the remoteproc part of the OpenAMP to propertly initialize the communication. If I remember correctly, the rpmsg_lite cannot be used in this case.
if you don't want to use a resource table, an alternative is to develop your own platform driver in the Linux kernel, to add the RPMsg/Virtio support.
An other alternative is to use OpenAMP or rpmsg_lite in the Linux user space, instead of using the Linux kernel framework.

[neuberfran]

@arnopo

I have Remoteproc running in my imx7d-pico (technexion) https://www.youtube.com/watch?v=NFyEJXIpq4E

My goal is to do an echo > "TEST" /dev/ttyRPMSG to the remote using the modprobe imx_rpmsg_tty (Kernel driver). I've been trying this on rpmsg_lite for 3 months on the upstream Zephyr, without success. In Zephyr 1.13 rpmsg_lite works:
https://stackoverflow.com/questions/77526652/rpmsg-lite-in-imx7d-pico-stop-in-while-0-rpmsg-lite-is-link-uprl-instance

Honestly, I'm not sure if I can use this driver (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.99-dev1/zephyr/samples/subsys/ipc/openamp_rsc_table/README.html) and use openamp_rsc_table zephyr project.

https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/ipc/rpmsg_service
Can I achieve my goal (enable the kernel tty driver through an app running in UserSpace and not in Uboot) using just the link above?

I got kernel panic due to this screen setting above.
Please take a look at the links below and check my device tree and AN5317 of imx7d-pico:
https://gist.github.com/neuberfran/389a5eb620ccad6e5694816d3ba43de8
https://www.nxp.com/docs/en/application-note/AN5317.pdf

How to solve this kernel panic?
Using UIO memories (CONFIG_UIO=y. etc) in UserSpace to work with libmetal? Would my device (imx7d-pico) accept this type of setup/memory?

Or do I have to implement resource table?
(Note: Remoteproc runs here without resource table in imx7d-pico by technexion - This device NOT have debug port)
Does my device accept resource_table?
Would I have to use Uio memories in this setup/configuration of the resource_table?

[arnopo]

Hello @neuberfran

As you mentioned, the Zephyr openamp_rs_table sample is based on the use of the resource table to enable the rpmsg protocol. The resource table is simply a table that is defined in a specific ELF section and loaded into shared memory. It is used by Linux to discover the coprocessor's requested resources and to set associated services (traces, virtio rpmsg, etc.).

• On Zephyr, you can refer to this Zephyr PR: Add support for HiFi4 DSP on openamp_rsc_table sample zephyrproject-rtos/zephyr#60455 to see how to enable it. Note that Linux will update this resource table to provide information about the vrings addresses.
• On Linux, your remoteproc driver should provide the address of this resource table to the remoteproc core, if you attach to the coprocessor. Else If you load the image and start the coprocessor using the remoteproc Linux driver, it can retrieve the address from the ELF file. You will also need to define memory regions for the vrings and virtio buffer allocation in the DT.

An alternative is to use a shared memory that contains the static vrings and buffer. You can refer to the Zephyr openamp example https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp/remote or https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/ipc_service/static_vrings/remote, which implement the remote part of the protocol based on shared memory with static vrings. These examples are probably closer to what you're trying to implement with rpmsg-lite.
I don't know if anyone has already tried this configuration. This sample is generally used for Zephyr to Zephyr communication.

[neuberfran]

@arnopo
Tks.
In fact, all the examples we mentioned (with the exception of openamp_rsc_table which is remote-slave) are Zephyr to Zephyr) and I have not yet seen anyone use them using Linux to Zephyr

Could you explain something about the kernel panic I mentioned? The memory address I used in the Zephyr app coincided with that of the RPMSG (used in DT=0x9FFF000) but I programmed remoteproc to start only after the modprobe remoteproc command. Hence the kernel panic became inexplicable.

And about the need to use memories/Uio Setup.(?)

I say this because I already developed this project below on rpi4/Linux/FreeRTOS (https://www.youtube.com/watch?v=tNevT71nCpM) and the creator used Uio on UserSpace:
https://qiita.com/t-imada/items/f34ff62d3124a3950423?s=03

[arnopo]

Could you detail what is exactly your setup for the panic, no clear what you are running on zephyr side and Linux side. is it rpmsg-lite or the open-amp lib?

[neuberfran]

@arnopo I'm trying to run Yocto hardknot and start zephyr_openamp_rsc_table.elf (Or zephyr_openamp.elf) in UserSpace using Remoteproc.

I'm not using rpmsg_lite in this issue.

When I comment the line fsl,auto-boot;
in this dts (m4-side of the linux hardknott yocto device tree file)
https://gist.github.com/neuberfran/389a5eb620ccad6e5694816d3ba43de8#file-imx7d-pico-pi-qca-m4-dts_good_2-L47
I get this kernel panic:
https://gist.github.com/neuberfran/d58ac784da21b208e4a2d36d99e1c026

You can see in line 81 of the file above (Starting auxiliary core stack = 0x20002118, pc = 0x1FFF8E4D...)
that I started zephyr_openamp_rsc_table.bin (Or zephyr_openamp.bin) in Uboot (identical procedure to this one in my video where remoteproc worked perfectly:
https://www.youtube.com/watch?v=NFyEJXIpq4E

(Observation-01:
If I don't start this bin file in Uboot I can't even use remoteproc even doing modproble remoteproc)

But in the video project (blink led using Zephyr/Remoteproc in Yocto UserSpace) I didn't comment on the line fsl, auto-boot on device-tree m4 yocto side and on Zephyr my dts is the one below:
https://gist.github.com/neuberfran/2398c7c05b37599d76bded7851f8ae9f

In other words, there is no pico_pi_m4.overlay with this:

/ {
	chosen {
		/*
		 * shared memory reserved for the inter-processor communication
		 */
		zephyr,ipc_shm = &ocram;
		zephyr,ipc = &mub;
	};

	ocram: sram@901000 {
		compatible = "mmio-sram";
		reg = <0x901000 0x1f000>;
	};
};

Observation-02:
Can I Run the project below without using the pico_pi_m4.overlay file?
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/rpmsg_service

Observation-03:
A project I'm basing myself on is the one below, using zephyr and yocto for openamp. But unfortunately (I would like you to comment on this), as can be seen in the PDF, there is no resource_table definition model in Yocto(Only in Zephyr part).
running-zephyr-and-linux.pdf

https://github.com/iotbzh/meta-rcar-zephyr

[arnopo]

Let's focus on the zephyr samples/subsys/ipc/openamp_rsc_table sample.

Here are some checks you can do:

1. the fisrt step is to check that you have a .resourcetable section in your elf file

$> objdump -hw   zephyr_openamp_rsc_table.elf  

...
 26 .resource_table 0000008c  00007e94  00007e94  00007f88  2**2  CONTENTS, ALLOC, LOAD, DATA
...

2. On Linux side your imx_rproc.c driver should provide the address of the resource table to the remoteproc framework
   seems that it is based on a DT memory regions
   https://elixir.bootlin.com/linux/v6.6.13/source/drivers/remoteproc/imx_rproc.c#L755

3. After attaching to the remoteproc device ( loaded by U-boot):
   If the resource table is found by the Linux you should see the content of the resource table in the debugfs file /sys/kernel/debug/remoteproc/remoteproc0/resource_table on your board console

4. As an alternative do you tried to load the firmware with the Linux using the sysfs?

cp zephyr_openamp_rsc_table.elf /lib/firmware/
echo zephyr_openamp_rsc_table.elf > /sys/class/remoteproc/remoteproc0/firmware 
echo start >/sys/class/remoteproc/remoteproc0/state 

[neuberfran]

@arnopo

4. As an alternative do you tried to load the firmware with the Linux using the sysfs?

No

To populate the /sys/class/remoteproc/ folder (I still don't know why), you need to start m4 (I think so) in Uboot.

Of course, I'm currently focusing on zephyr_openamp_rsc_table and I'll post the result of the resource_table memory region command

3. After attaching to the remoteproc device ( loaded by U-boot):
   If the resource table is found by the Linux you should see the content of the resource table in the debugfs file /sys/kernel/debug/remoteproc/remoteproc0/resource_table on your board console

I can't. I have Kernel Panic if I load zephyr_openamp_rsc_table.bin in Uboot

objdump -hw zephyr_openamp_rsc_table.elf

zephyr_openamp_rsc_table.elf: formato do arquivo elf32-little

Seções:
Idx Name            Tam.      VMA       LMA       File off  Algn  Sinalizações
  0 rom_start       0000023c  1fff8000  1fff8000  000000f8  2**2  CONTENTS, ALLOC, LOAD, CODE
  1 text            0000560c  1fff823c  1fff823c  00000334  2**2  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .ARM.exidx      00000008  1fffd848  1fffd848  00005940  2**2  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 initlevel       00000040  1fffd850  1fffd850  00005948  2**2  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 device_area     00000028  1fffd890  1fffd890  00005988  2**2  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 sw_isr_table    000003f8  1fffd8b8  1fffd8b8  000059b0  2**2  CONTENTS, ALLOC, LOAD, DATA
  6 tbss            00000004  1fffdcb0  1fffdcb0  00005da8  2**2  ALLOC, THREAD_LOCAL
  7 rodata          00000900  1fffdcb0  1fffdcb0  00005da8  2**3  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .ramfunc        00000000  20000000  20000000  0000682c  2**0  CONTENTS
  9 datas           000000e0  20000000  1fffe5b0  000066a8  2**2  CONTENTS, ALLOC, LOAD, DATA
 10 device_states   00000004  200000e0  1fffe690  00006788  2**0  CONTENTS, ALLOC, LOAD, DATA
 11 k_heap_area     00000014  200000e4  1fffe694  0000678c  2**2  CONTENTS, ALLOC, LOAD, DATA
 12 k_sem_area      00000030  200000f8  1fffe6a8  000067a0  2**2  CONTENTS, ALLOC, LOAD, DATA
 13 .resource_table 00000058  20000128  1fffe6d8  000067d0  2**0  CONTENTS, ALLOC, LOAD, DATA
 14 bss             00000452  20000180  20000180  00006830  2**3  ALLOC
 15 noinit          00001f40  200005d8  200005d8  00006830  2**3  ALLOC
 16 .comment        00000020  00000000  00000000  0000682c  2**0  CONTENTS, READONLY
 17 .debug_aranges  000012a0  00000000  00000000  00006850  2**3  CONTENTS, READONLY, DEBUGGING, OCTETS
 18 .debug_info     000487b6  00000000  00000000  00007af0  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 19 .debug_abbrev   0000a63d  00000000  00000000  000502a6  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 20 .debug_line     0001a8ea  00000000  00000000  0005a8e3  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 21 .debug_frame    00002e6c  00000000  00000000  000751d0  2**2  CONTENTS, READONLY, DEBUGGING, OCTETS
 22 .debug_str      0000a408  00000000  00000000  0007803c  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 23 .debug_loc      00015ac3  00000000  00000000  00082444  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 24 .debug_ranges   00003538  00000000  00000000  00097f08  2**3  CONTENTS, READONLY, DEBUGGING, OCTETS
 25 .ARM.attributes 00000032  00000000  00000000  0009b440  2**0  CONTENTS, READONLY

[neuberfran]

@arnopo
I put zephyr.bin (from RPMSG-lite) in Uboot and I got populete the folder /sys/class/remoteproc

root@scorpion:~# cat /sys/class/remoteproc/remoteproc0/state 
running
root@scorpion:~# echo stop > /sys/class/remoteproc/remoteproc0/state 
[  203.081126] remoteproc remoteproc0: stopped remote processor imx-rproc
root@scorpion:~# cat /sys/class/remoteproc/remoteproc0/state 
offline
root@scorpion:~# cd /lib/firmware/
root@scorpion:/lib/firmware# echo zephyr_openamp_rsc_table.elf > /sys/class/remoteproc/remoteproc0/firmware
root@scorpion:/lib/firmware# echo start >/sys/class/remoteproc/remoteproc0/state
[  249.311768] remoteproc remoteproc0: powering up imx-rproc
[  249.336273] remoteproc remoteproc0: Booting fw image zephyr_openamp_rsc_table.elf, size 679564
[  249.345742] 8<--- cut here ---
[  249.348814] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  249.358850] pgd = e67e8f94
[  249.362499] [00000000] *pgd=00000000
[  249.366108] Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM
[  249.372033] Modules linked in: **rpmsg_client_sample** ov5640_camera_mipi_v2 mxc_mipi_csi mx6s_capture snd_soc_tfa98xx(O) imx_rpmsg_tty usb_f_ecm g_ether
[  249.385471] CPU: 1 PID: 260 Comm: sh Tainted: G        W  O      5.10.72-2.2.0-next+g000eb85263cb #1
[  249.394604] Hardware name: Freescale i.MX7 Dual (Device Tree)
[  249.400355] PC is at 0x0
[  249.402898] LR is at rproc_elf_load_segments+0x1a8/0x298
[  249.408210] pc : [<00000000>]    lr : [<808fe4d8>]    psr: 40070013
[  249.414477] sp : 8524be28  ip : 00000010  fp : 00000000
[  249.419703] r10: 00000000  r9 : 84758800  r8 : 00000000
[  249.424929] r7 : 00000001  r6 : 000065b0  r5 : 000065b0  r4 : a07bd054
[  249.431458] r3 : 000065b0  r2 : a07bd0f8  r1 : a0158000  r0 : 84758800
[  249.437987] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  249.445124] Control: 10c5387d  Table: 84fb406a  DAC: 00000051
[  249.450874] Process sh (pid: 260, stack limit = 0xabf2d155)
[  249.456449] Stack: (0x8524be28 to 0x8524c000)
[  249.460811] be20:                   000065b0 85313d00 00000000 00000006 00000001 00000020
[  249.468994] be40: a07bd0f8 1fff8000 a0158000 85313380 a07bd000 84758820 9c090000 84758800
[  249.477176] be60: 00000000 84758820 85313380 84758820 85313380 85313d00 00000000 80c844f0
[  249.485358] be80: 84758800 00000000 847589f8 84758a04 84758820 808fbdac 85313380 81205fc8
[  249.493541] bea0: 84758820 85313340 00000006 84758800 84e87a10 00000000 00000000 808fd510
[  249.501724] bec0: 00000006 85313340 84e87a00 8524bf30 84e87a10 802f0d60 00000000 00000000
[  249.509906] bee0: 8526bcc0 00000000 00000006 00000000 8524bf80 00000004 00000000 80259ce0
[  249.518087] bf00: 00000006 81205fc8 00000003 0000000a 01e081d8 00000006 00000005 00000000
[  249.526270] bf20: 00000000 8524bf18 00000000 8026d1a0 8526bcc0 00000000 00000000 00000000
[  249.534452] bf40: 00000000 00000000 00000000 00000000 00000000 00000000 84bc4480 81205fc8
[  249.542634] bf60: 84af0000 8526bcc0 8526bcc0 00000000 00000000 80100264 8524a000 80259f60
[  249.550817] bf80: 00000000 00000000 80100264 81205fc8 00000000 00000006 01e081d8 76f87480
[  249.558999] bfa0: 00000004 80100060 00000006 01e081d8 00000001 01e081d8 00000006 00000000
[  249.567182] bfc0: 00000006 01e081d8 76f87480 00000004 76f15c60 00000000 005bcc00 00000000
[  249.575364] bfe0: 00000004 7ee3b9d8 76eb24bf 76e3e386 40010030 00000001 00000000 00000000
[  249.583558] [<808fe4d8>] (rproc_elf_load_segments) from [<80c844f0>] (rproc_start+0x24/0x154)
[  249.592094] [<80c844f0>] (rproc_start) from [<808fbdac>] (rproc_boot+0x494/0x4ac)
[  249.599586] [<808fbdac>] (rproc_boot) from [<808fd510>] (state_store+0x40/0xc8)
[  249.606904] [<808fd510>] (state_store) from [<802f0d60>] (kernfs_fop_write_iter+0x10c/0x1cc)
[  249.615351] [<802f0d60>] (kernfs_fop_write_iter) from [<80259ce0>] (vfs_write+0x318/0x44c)
[  249.623621] [<80259ce0>] (vfs_write) from [<80259f60>] (ksys_write+0x64/0xe4)
[  249.630764] [<80259f60>] (ksys_write) from [<80100060>] (ret_fast_syscall+0x0/0x54)
[  249.638420] Exception stack(0x8524bfa8 to 0x8524bff0)
[  249.643477] bfa0:                   00000006 01e081d8 00000001 01e081d8 00000006 00000000
[  249.651659] bfc0: 00000006 01e081d8 76f87480 00000004 76f15c60 00000000 005bcc00 00000000
[  249.659838] bfe0: 00000004 7ee3b9d8 76eb24bf 76e3e386
[  249.664897] Code: bad PC value
[  249.669535] ---[ end trace 3437ea7198b76138 ]---

Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.366108] Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.450874] Process sh (pid: 260, stack limit = 0xabf2d155)


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.456449] Stack: (0x8524be28 to 0x8524c000)


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.460811] be20:                   000065b0 85313d00 00000000 00000006 00000001 00000020


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.468994] be40: a07bd0f8 1fff8000 a0158000 85313380 a07bd000 84758820 9c090000 84758800


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.477176] be60: 00000000 84758820 85313380 84758820 85313380 85313d00 00000000 80c844f0


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.485358] be80: 84758800 00000000 847589f8 84758a04 84758820 808fbdac 85313380 81205fc8


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.493541] bea0: 84758820 85313340 00000006 84758800 84e87a10 00000000 00000000 808fd510


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.501724] bec0: 00000006 85313340 84e87a00 8524bf30 84e87a10 802f0d60 00000000 00000000


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.509906] bee0: 8526bcc0 00000000 00000006 00000000 8524bf80 00000004 00000000 80259ce0


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.518087] bf00: 00000006 81205fc8 00000003 0000000a 01e081d8 00000006 00000005 00000000


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.526270] bf20: 00000000 8524bf18 00000000 8026d1a0 8526bcc0 00000000 00000000 00000000


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.534452] bf40: 00000000 00000000 00000000 00000000 00000000 00000000 84bc4480 81205fc8


Broadcast message from systemd-journald@scorpion (Thu 2024-01-25 02:07:22 UTC):

kernel[251]: [  249.542634] bf60: 84af0000 8526bcc0 8526bcc0 00000000 00000000 80100264 8524a000 80259f60


TechNexion i.MX Release Distro 5.10-hardknott scorpion ttymxc4

scorpion login: root
Last login: Thu Jan 25 01:57:22 +0000 2024 on /dev/ttymxc4.
root@scorpion:~# 

[arnopo]

@arnopo

4. As an alternative do you tried to load the firmware with the Linux using the sysfs?

No

To populate the /sys/class/remoteproc/ folder (I still don't know why), you need to start m4 (I think so) in Uboot.

The /sys/class/remoteproc/ should be created when your Linux remoteproc driver is probed ( expect if something goes wrong in the driver

Of course, I'm currently focusing on zephyr_openamp_rsc_table and I'll post the result of the resource_table memory region command

3. After attaching to the remoteproc device ( loaded by U-boot):
   If the resource table is found by the Linux you should see the content of the resource table in the debugfs file /sys/kernel/debug/remoteproc/remoteproc0/resource_table on your board console

I can't. I have Kernel Panic if I load zephyr_openamp_rsc_table.bin in Uboot

objdump -hw zephyr_openamp_rsc_table.elf

zephyr_openamp_rsc_table.elf: formato do arquivo elf32-little

Seções:
Idx Name            Tam.      VMA       LMA       File off  Algn  Sinalizações
  0 rom_start       0000023c  1fff8000  1fff8000  000000f8  2**2  CONTENTS, ALLOC, LOAD, CODE
  1 text            0000560c  1fff823c  1fff823c  00000334  2**2  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .ARM.exidx      00000008  1fffd848  1fffd848  00005940  2**2  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 initlevel       00000040  1fffd850  1fffd850  00005948  2**2  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 device_area     00000028  1fffd890  1fffd890  00005988  2**2  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 sw_isr_table    000003f8  1fffd8b8  1fffd8b8  000059b0  2**2  CONTENTS, ALLOC, LOAD, DATA
  6 tbss            00000004  1fffdcb0  1fffdcb0  00005da8  2**2  ALLOC, THREAD_LOCAL
  7 rodata          00000900  1fffdcb0  1fffdcb0  00005da8  2**3  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .ramfunc        00000000  20000000  20000000  0000682c  2**0  CONTENTS
  9 datas           000000e0  20000000  1fffe5b0  000066a8  2**2  CONTENTS, ALLOC, LOAD, DATA
 10 device_states   00000004  200000e0  1fffe690  00006788  2**0  CONTENTS, ALLOC, LOAD, DATA
 11 k_heap_area     00000014  200000e4  1fffe694  0000678c  2**2  CONTENTS, ALLOC, LOAD, DATA
 12 k_sem_area      00000030  200000f8  1fffe6a8  000067a0  2**2  CONTENTS, ALLOC, LOAD, DATA
 13 .resource_table 00000058  20000128  1fffe6d8  000067d0  2**0  CONTENTS, ALLOC, LOAD, DATA
 14 bss             00000452  20000180  20000180  00006830  2**3  ALLOC
 15 noinit          00001f40  200005d8  200005d8  00006830  2**3  ALLOC
 16 .comment        00000020  00000000  00000000  0000682c  2**0  CONTENTS, READONLY
 17 .debug_aranges  000012a0  00000000  00000000  00006850  2**3  CONTENTS, READONLY, DEBUGGING, OCTETS
 18 .debug_info     000487b6  00000000  00000000  00007af0  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 19 .debug_abbrev   0000a63d  00000000  00000000  000502a6  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 20 .debug_line     0001a8ea  00000000  00000000  0005a8e3  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 21 .debug_frame    00002e6c  00000000  00000000  000751d0  2**2  CONTENTS, READONLY, DEBUGGING, OCTETS
 22 .debug_str      0000a408  00000000  00000000  0007803c  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 23 .debug_loc      00015ac3  00000000  00000000  00082444  2**0  CONTENTS, READONLY, DEBUGGING, OCTETS
 24 .debug_ranges   00003538  00000000  00000000  00097f08  2**3  CONTENTS, READONLY, DEBUGGING, OCTETS
 25 .ARM.attributes 00000032  00000000  00000000  0009b440  2**0  CONTENTS, READONLY

loading this firmware from u-boot implies that your Linux and U-boot support this mode with the management of the resource table. Some platforms support to load the same firmware from U-boot or Linux, some other do not.
It seems here that you need some support from NXP.

[arnopo]

@arnopo I put zephyr.bin (from RPMSG-lite) in Uboot and I got populete the folder /sys/class/remoteproc

root@scorpion:~# cat /sys/class/remoteproc/remoteproc0/state 
running
root@scorpion:~# echo stop > /sys/class/remoteproc/remoteproc0/state 
[  203.081126] remoteproc remoteproc0: stopped remote processor imx-rproc
root@scorpion:~# cat /sys/class/remoteproc/remoteproc0/state 
offline
root@scorpion:~# cd /lib/firmware/
root@scorpion:/lib/firmware# echo zephyr_openamp_rsc_table.elf > /sys/class/remoteproc/remoteproc0/firmware
root@scorpion:/lib/firmware# echo start >/sys/class/remoteproc/remoteproc0/state
[  249.311768] remoteproc remoteproc0: powering up imx-rproc
[  249.336273] remoteproc remoteproc0: Booting fw image zephyr_openamp_rsc_table.elf, size 679564
[  249.345742] 8<--- cut here ---
[  249.348814] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  249.358850] pgd = e67e8f94
[  249.362499] [00000000] *pgd=00000000
[  249.366108] Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM
[  249.372033] Modules linked in: **rpmsg_client_sample** ov5640_camera_mipi_v2 mxc_mipi_csi mx6s_capture snd_soc_tfa98xx(O) imx_rpmsg_tty usb_f_ecm g_ether
[  249.385471] CPU: 1 PID: 260 Comm: sh Tainted: G        W  O      5.10.72-2.2.0-next+g000eb85263cb #1
[  249.394604] Hardware name: Freescale i.MX7 Dual (Device Tree)
[  249.400355] PC is at 0x0
[  249.402898] LR is at rproc_elf_load_segments+0x1a8/0x298
[  249.408210] pc : [<00000000>]    lr : [<808fe4d8>]    psr: 40070013
[  249.414477] sp : 8524be28  ip : 00000010  fp : 00000000
[  249.419703] r10: 00000000  r9 : 84758800  r8 : 00000000
[  249.424929] r7 : 00000001  r6 : 000065b0  r5 : 000065b0  r4 : a07bd054
[  249.431458] r3 : 000065b0  r2 : a07bd0f8  r1 : a0158000  r0 : 84758800
[  249.437987] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  249.445124] Control: 10c5387d  Table: 84fb406a  DAC: 00000051
[  249.450874] Process sh (pid: 260, stack limit = 0xabf2d155)
[  249.456449] Stack: (0x8524be28 to 0x8524c000)
[  249.460811] be20:                   000065b0 85313d00 00000000 00000006 00000001 00000020
[  249.468994] be40: a07bd0f8 1fff8000 a0158000 85313380 a07bd000 84758820 9c090000 84758800
[  249.477176] be60: 00000000 84758820 85313380 84758820 85313380 85313d00 00000000 80c844f0
[  249.485358] be80: 84758800 00000000 847589f8 84758a04 84758820 808fbdac 85313380 81205fc8
[  249.493541] bea0: 84758820 85313340 00000006 84758800 84e87a10 00000000 00000000 808fd510
[  249.501724] bec0: 00000006 85313340 84e87a00 8524bf30 84e87a10 802f0d60 00000000 00000000
[  249.509906] bee0: 8526bcc0 00000000 00000006 00000000 8524bf80 00000004 00000000 80259ce0
[  249.518087] bf00: 00000006 81205fc8 00000003 0000000a 01e081d8 00000006 00000005 00000000
[  249.526270] bf20: 00000000 8524bf18 00000000 8026d1a0 8526bcc0 00000000 00000000 00000000
[  249.534452] bf40: 00000000 00000000 00000000 00000000 00000000 00000000 84bc4480 81205fc8
[  249.542634] bf60: 84af0000 8526bcc0 8526bcc0 00000000 00000000 80100264 8524a000 80259f60
[  249.550817] bf80: 00000000 00000000 80100264 81205fc8 00000000 00000006 01e081d8 76f87480
[  249.558999] bfa0: 00000004 80100060 00000006 01e081d8 00000001 01e081d8 00000006 00000000
[  249.567182] bfc0: 00000006 01e081d8 76f87480 00000004 76f15c60 00000000 005bcc00 00000000
[  249.575364] bfe0: 00000004 7ee3b9d8 76eb24bf 76e3e386 40010030 00000001 00000000 00000000
[  249.583558] [<808fe4d8>] (rproc_elf_load_segments) from [<80c844f0>] (rproc_start+0x24/0x154)

Something seems wrong during the parse or load of your elf file. Are you sure that your linux driver allows to load a firmware?

[neuberfran]

@arnopo Tks.
[1]https://doc.embedfire.com/linux/stm32mp1/driver/zh/latest/linux_driver/framework_ipcc.html
[2] https://www.youtube.com/watch?v=JqwPljnm2_k&t=1690s
[3] https://www.spinics.net/lists/arm-kernel/msg926098.html
[4] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2558691.html

In the last 3 days, I studied the links above a lot

In link [1] there are 3 interesting moments:

First:
The compatible = "st,stm32mp1-ipcc" attribute in the device tree will match drivers/mailbox/stm32-ipcc.cthe driver, and an mbox controller will be created in the driver.
Observation-01: It seems to me that nothing like this is mentioned in the video [2]

Second:
The compatible = "st,stm32mp1-rproc" attribute in the device tree will match drivers/remoteproc/stm32_rproc.cthe driver. An mbox client will be created in the driver and associated with the mbox client based on the RemoteProc and RPMsg frameworks.

Third:
In the M4 core code, the code to create the above two rpmsg devices is as follows:

Observation-02: How to implement it (rpmsg_tty part) in UserSpace of the Yocto/Hardknott/imx7d-pico?

Regarding @iuliana-prodan (Pls help-me to configure DT & Kernel drivers & Zephyr/m4 Side) video/links[2][3][4] She makes important changes to imx_dsp_rproc.c (which in my case would be imx_rproc.c)

She also made changes to the linker script, which in my case would be this file:
....../zephyr/samples/subsys/ipc/zephyr/soc/arm/nxp_imx/mcimx7_m4

About imx_rproc. (You already referred to this saying: On Linux side your imx_rproc.c driver should provide the address of the resource table to the remoteproc framework...)
I have to tell you that:
I dont have (My Yocto in imx7d-pico is hardknott = 5.10.72-2.2.0-next+g000eb85263cb ) this part in my imx_rproc.c

if (!strcmp(node->name, "rsc-table"))
priv->rsc_table = priv->mem[b].cpu_addr;

https://gist.github.com/neuberfran/d0f0d8355f8c424420842381eb0db218
https://gist.github.com/neuberfran/4afe2bfeb1bddadbdc7fb9fe1ca9cec7

Observation-03 : Could this difference between the old imx_rproc.c and the upstream imx_rproc.c be a problem in my case?

[arnopo]

please could you fix (chiness?) character to make comment more readable.

[iuliana-prodan]

@neuberfran Please take a newer kernel version: https://github.com/nxp-imx/linux-imx/tree/lf-6.1.y (this is latest release).
At the end of March we'll have a new BSP release with kernel 6.6.

If I understand correctly you want to run openamp_rsc_table sample from Zephyr on Cortex M4 from imx7D?
On Cortex A you'll run Linux and on Cortex M Zephyr, right?

In my opinion you should try to compile the simple hello_world sample from Zephyr, for CortexM from imx7d - pico_pi_m4 (is this one, right?) and try to load it using remoteproc from Linux. So... start small and simple.
This way you'll know that everything is ok in Linux, in imx_rproc for firmware loading. I see there's support for 7D https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/remoteproc/imx_rproc.c#L1240
You can also boot the core from uboot - here's a post I found https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/remoteproc/imx_rproc.c#L1240

Next, for openamp_rsc_table follow the Zephyr PR: zephyrproject-rtos/zephyr#60455 and Linux patches from here: https://patchwork.kernel.org/project/linux-remoteproc/cover/20231013152731.23471-1-iuliana.prodan@oss.nxp.com/
The other patches ([1] and [2]) were some limitations of hw DSP.

[neuberfran]

@arnopo

@iuliana-prodan Tks.

Ok. Fortunately I have a machine with Ubuntu 22.04 where I can get Yocto Kirkstone with a newer imx_rproc.c (which seems to meet the requirements of this project).

https://gist.github.com/neuberfran/f90b54de9b44fd53a07906774e4046e8

It is not possible to migrate to anything beyond that(kernel upstream via Yocto BSP Official Build). Because it is an old device (Ex Android Things) imx7d-pico from TechNexion. It is currently not possible to do repo init and repo sync anymore for this device. Because I have it saved on my machine, I can still do it.

In any case, I don't imagine this will be a problem (imx_rproc.c from Yocto Hardknott Or Kirkstone)

If I understand correctly you want to run openamp_rsc_table sample from Zephyr on Cortex M4 from imx7D?
On Cortex A you'll run Linux and on Cortex M Zephyr, right?
Yes. U're Right

In my opinion you should try to compile the simple hello_world sample from Zephyr, for CortexM from imx7d - pico_pi_m4 (is this one, right?) and try to load it using remoteproc from Linux. So... start small and simple.
I already have this:
https://www.youtube.com/watch?v=NFyEJXIpq4E

for CortexM from imx7d - pico_pi_m4 (is this one, right?)
Yes, in Zephyr my imx7d-pico m4 side is pico_pi_m4

Observation-01: In parallel to this (openamp_rsc_table) I tried and managed to compile the remote part of the Zephyr samples, namely: rpmsg_service and openamp, using the commands below:
[1]west build -b pico_pi_m4 samples/subsys/ipc/rpmsg_service/remote/
[2]west build --sysbuild -b pico_pi_m4 samples/subsys/ipc/openamp/remote/
At this point, obviously, I left the M4/Side DT on the simpler Yocto (without preparation for Remoteproc):
https://gist.github.com/neuberfran/0a94b083dbbd7e0ab25636cd644a632c

In the first app [1] when I start it in Uboot I don't see anything in the m4 part (/tty/USB01 in minicom)
Not even that: RPMsg Service [master] demo started which is in the main.c app_task of the remote app
Would you have any hypothesis as to why this happens?

In the second app [2] I can see Starting application thread And OpenAMP[remote] demo started 2
But that stops there because there is nothing sending messages from the Master/Linux/Yocto part, correct?
Would you know how to implement this part?
In this app[2] openamp does not need resource_table, correct?

Going back to openamp_rsc_table the first thing I saw was this: zephyrproject-rtos/zephyr#60455 And then the video: https://www.youtube.com/watch?v=JqwPljnm2_k&t=1690s
And then
[3] https://www.spinics.net/lists/arm-kernel/msg926098.html
[4] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2558691.html

About the links below (and the video) I have questions:

1. Will I have to make changes to linker script, which in my case would be this file:
   ....../zephyr/samples/subsys/ipc/zephyr/soc/arm/nxp_imx/mcimx7_m4 (?)

Before second question, I need post again this important memory file tutorial:
https://www.nxp.com/docs/en/application-note/AN5317.pdf
2) Will I have to make changes like the ones below in the device-tree(
https://gist.github.com/neuberfran/389a5eb620ccad6e5694816d3ba43de8) and imx_rproc.c? Which?Why

examples:
@@ -91,3 +164,41 @@ examples:
         mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
         memory-region = <&dsp_reserved>;
     };
+  - |
+    #include <dt-bindings/clock/imx8mp-clock.h>
+    dsp_reserved: dsp@92400000 {
+      reg = <0x92400000 0x1000000>;
+      no-map;
+    };
+    dsp_vdev0vring0: vdev0vring0@942f0000 {
+      reg = <0x942f0000 0x8000>;
+      no-map;
+    };
+    dsp_vdev0vring1: vdev0vring1@942f8000 {
+      reg = <0x942f8000 0x8000>;
+      no-map;
+    };
+    dsp_vdev0buffer: vdev0buffer@94300000 {
+      compatible = "shared-dma-pool";
+      reg = <0x94300000 0x100000>;
+      no-map;
+    };
+
+    dsp: dsp@3b6e8000 {
+      compatible = "fsl,imx8mp-hifi4";
+      reg = <0x3b6e8000 0x88000>;
+      clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSP_ROOT>,
+               <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_OCRAMA_IPG>,
+               <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSP_ROOT>,
+               <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSPDBG_ROOT>;
+      clock-names = "ipg", "ocram", "core", "debug";
+      firmware-name = "imx/dsp/hifi4.bin";
+      power-domains = <&audiomix_pd>;
+      mbox-names = "tx", "rx", "rxdb";
+      mboxes = <&mu2 0 0>,
+               <&mu2 1 0>,
+               <&mu2 3 0>;
+      memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
+                      <&dsp_vdev0vring1>, <&dsp_reserved>;
+      fsl,dsp-ctrl = <&audio_blk_ctrl>;
+    };
-- 
2.17.1

[neuberfran]

Today I have kernel panic (Stop in start linux message:

I compiled Yocto Kirkstone Ok. I compiled Zephyr with this command:
west build --sysbuild -b pico_pi_m4 samples/subsys/ipc/openamp_rsc_table/

Below are listed the main files used today. Just press Control-F on the word My
Note that with the imx7d-pico-pi-qca-m4.dts file, I made two attempts with different files and nothing changed
https://gist.github.com/neuberfran/5d2ad0d4386eab7d23306eb9e051713c

@iuliana-prodan
I don't have this in Uboot 2022.04 which I use in imx7d-pico (soc.c file)

[iuliana-prodan]

From the first screen shot, from the zephyr console it seems the firmware is loading in a loop and it get's stuck at some point.
There are too many Starting application threads!
I believe there is a problem on how you load the fw, from uboot.

On second screenshot I don't understand what soc.c file you refer to, but you definitely don't need a dsp node.
The dsp node I used in PR#60455 corresponds with your m4. I was loading the fw on a DSP (a hifi4 core).

For both rpmsg_service and openamp samples you have Zephyr on both cores - core A is master and Core M is slave, no Linux.
How to start both cores, with Zephyr? TBH, I don't know, I haven't run Zephyr without Linux.
But is normal to not get any messages from Master side since your master (cortex A with Zephyr) is not started.
Yes, openamp sample doesn't use resource table.

Will I have to make changes to linker script, which in my case would be this file:
....../zephyr/samples/subsys/ipc/zephyr/soc/arm/nxp_imx/mcimx7_m4 (?)

Yes, you need to add a file like this one: https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/arm/nxp_imx/mimx8mm6_m4/linker.ld

2. Will I have to make changes like the ones below in the device-tree(
   https://gist.github.com/neuberfran/389a5eb620ccad6e5694816d3ba43de8) and imx_rproc.c? Which?Why

imx_rproc seems ok, you have the find_loaded_rsc_table ...so, I don't see any issues now. If they appear you'll need to debug the code to see where it get's stuck :)

In the dts you need the memory-region property that defines the rings and buffers base addresses and sizes, from the ARM Cortex A point of view.
These memory regions are used for firmware code and data, and for IPC.
You also have to define them in a reserved-memory node.
In Zephyr, in the openamp_rsc_table sample, you need to add a dts overlay in which you must add the shared memory address for the 2 cores - this must correspond to the address of the first ring from Linux.
Also, an important aspect is the size - it must be large enough to encapsulate the virtual rings, one for RX and one for TX, and also the buffers.

You also need a mailbox.
We have the imx_mailbox, the platform specific controller which is in charge of configuring and handling IRQ from the MU peripheral.
For mailbox, you need to provide the mboxes and mbox-name properties in DTS.

If those addresses, from dts, are correct? I don't know exactly - I have never worked with imx7d.
But you can ask questions on NXP community and a FAE or SE can help you.

[neuberfran]

@iuliana-prodan
From the first screen shot, from the zephyr console it seems the firmware is loading in a loop and it get's stuck at some point.
There are too many Starting application threads!
I believe there is a problem on how you load the fw, from uboot.
This screen shot is just to show that I have a kernel panic on the a7/linux side (left side of the photo). The right side can only be considered (one) a Starting application threads!, as I rebooted Linux and the message came out again on the right side (photo)

On second screenshot I don't understand what soc.c file you refer to, but you definitely don't need a dsp node.
The dsp node I used in PR#60455 corresponds with your m4. I was loading the fw on a DSP (a hifi4 core).
This soc.c file refers to Uboot, in my case Uboot 2022.04 (..../u-boot-tn-imx/arch/arm/mach-imx/imx8m/soc.c)
My question comes because in this link (https://www.spinics.net/lists/arm-kernel/msg926098.html) someone used:
dsp: dsp@3b6e8000
I really don't have DSP on my device. But I'm trying to make a real base copy of your project in my imx7d-pico and I don't have addresses like this @3b6e8000 (unless I have to use UiO in the Linux userspace). That's because I asked about dsp@3b6e8000

For both rpmsg_service and openamp samples you have Zephyr on both cores - core A is master and Core M is slave, no Linux.
How to start both cores, with Zephyr? TBH, I don't know, I haven't run Zephyr without Linux.

If you look at the two commands I gave:
[1]west build -b pico_pi_m4 samples/subsys/ipc/rpmsg_service/remote/
[2]west build --sysbuild -b pico_pi_m4 samples/subsys/ipc/openamp/remote/
I'm trying to compile (and I managed to compile and generate a zephyr.bin) the remote part of the Zephyr project.
Ok. These are designs for Zephyr in both cores originally.
I'm trying to adapt this to my case. Which is to have /dev/ttyRPMSG (or pingpong to m4) in the userspace:
https://qiita.com/t-imada/items/f34ff62d3124a3950423?s=03
https://www.youtube.com/watch?v=tNevT71nCpM
Continuing:
I get the zephyr.bin resulting from this and run it in Uboot to run in m4(remote part of the my project).
I have two consoles/terminals. USB00 to Linux/Kirkstone/A7 and USB01 to M4/Zephyr Side.
In linux side I can boot Ok.
But in Zephyr Side I only see messages in openamp project. How to solve it? Why in rpmsg_service/remote project I can't see messages in m4/USB01 side?
I have Zephyr to zephyr project running:
https://www.youtube.com/watch?v=mXcwJprm_Ds

But is normal to not get any messages from Master side since your master (cortex A with Zephyr) is not started.
I think you meant it like this: But is normal to not get any messages from Remote side since your Master (cortex A with Linux and without UserSpace openamp.elf or rpmsg_service_remote.elf) is not started

Really,
All your approaches were important because I didn't completely understand the video (maybe because of my English) but the main thing is the memory addresses

pico_pi_m4.overlay

/ {
    chosen {
        /*
         * shared memory reserved for the inter-processor communication
         */
        zephyr,ipc_shm = &ocramfake;
        zephyr,ipc = &mub;
    };

    ocramfake: memory@9FFF0000 {
        compatible = "mmio-sram";
        reg = <0x9FFF0000 0x110000>;
    };
};


// ocram: sram@901000 {
//  compatible = "mmio-sram";
//  reg = <0x901000 0x1f000>;
//  clocks = <&clks IMX7D_OCRAM_CLK>;
// };

imx7d-pico-pi-qca-m4.dts

#include "imx7d-pico-pi-qca.dts"

/ {
	memory {
		linux,usable-memory = <0x80000000 0x1ff00000>;
	};

	reserved-memory {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;		

		// m4_tcm: tcml@007f8000 {
		// 	compatible = "fsl, m4_tcml";
		// 	reg = <0x007f8000 0x8000>;
		// };

		vdev0vring0: vdev0vring0@9FFF0000 {
			reg = <0x9FFF0000  0x4000>;
			no-map;
		};

		vdev0vring1: vdev0vring1@9FFF4000 {
			reg = <0x9FFF4000  0x4000>;
			no-map;
		};

		// rsc_table: rsc_table@900ff000 {
		// 	reg = <0x900ff000  0x1000>;
		// 	no-map;
		// };

		vdevbuffer: vdevbuffer {
            compatible = "shared-dma-pool";
			reg = <0x9FFF8000 0x4000>;
			no-map;
		};
	};

    imx7d-cm4 {
        compatible = "fsl,imx7d-cm4";
        clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
        fsl,auto-boot;
		mbox-names = "tx", "rx", "rxdb";
		mboxes = <&mub 0 1
			  &mub 1 1
			  &mub 3 1>;
        memory-region =  <&vdev0vring0>, <&vdev0vring1>,  <&vdevbuffer> ;
        syscon = <&src>;

//		status = "okay";

    };

	m4_tcm: tcml@007f8000 {
		compatible = "fsl, m4_tcml";
		reg = <0x007f8000 0x8000>;
	};

	gpio-leds {
		status = "disabled";
	};
};

&adc1 {
	status = "disabled";
};

&adc2 {
	status = "disabled";
};

&gpt3 {
	status = "disabled";
};

&gpt4 {
	status = "disabled";
};

&ocram {
	reg = <0x00901000 0xf000>;
};

&rpmsg {
	// compatible = "fsl,imx7d-rpmsg";
//	compatible = "fsl,imx7d-cm4";
//	mbox-names = "tx", "rx", "rxdb";
//	mboxes = <&mub 0 1
//			  &mub 1 1
//			  &mub 3 1>;
//	memory-region = <&vdevbuffer>;
	vdev-nums = <1>;
	reg = <0x9fff0000 0x10000>;
	status = "okay";
};

&uart6 {
	status = "disabled";
};

&mub {
	status = "okay";
 };

&wdog3{
	status = "disabled";
};

https://gist.github.com/neuberfran/5d2ad0d4386eab7d23306eb9e051713c

[neuberfran]

@iuliana-prodan

Why are these addresses completely different from the ones you use(type 0x942f0000)?

https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts?h=toradex_5.4-2.3.x-imx

[iuliana-prodan]

Because Toradex takes SoCs from NXP, but they created their own SOM - https://www.variscite.com/products/system-on-module-som/?cpu_name=NXP%20i.MX8M%20Plus

[neuberfran]

@arnopo @iuliana-prodan
I have a kernel panic:
My device not have debug port
https://gist.github.com/neuberfran/15cfb8c9e4dd8b940408862fccc02946

It looks like there's a kernel panic occurring. The relevant information indicates that the issue is an "Unhandled fault: imprecise external abort" at address 0xf5ab0024. The fault occurred in the context of the imx_mu_startup function.

Here are some steps you can take to diagnose and potentially resolve the issue:

Check the hardware: Ensure that there are no hardware issues, such as faulty memory or peripheral devices. You can try removing or replacing hardware components to see if the issue persists.

Check the kernel source code: Examine the source code of the imx_mu_startup function to understand what it is doing. Look for any potential issues, such as dereferencing null or invalid pointers.

Check the device tree: Verify that the device tree (DT) for your platform is correctly configured. The error mentions "device ID = 0x0a16030000000000," and any inconsistency in the device tree might lead to such faults.

Update the kernel: If you're not using the latest kernel version, consider upgrading to see if the issue has already been addressed in a newer release.

Check for kernel patches: Investigate whether there are any relevant patches or bug fixes available for the specific kernel version you're using.

Enable kernel debugging: Enable kernel debugging options (if not already enabled) to gather more information about the crash, such as stack traces and function names.

Check kernel logs: Review any previous kernel logs or messages that might provide additional information leading up to the crash.

Contact the kernel community: If the issue persists and you cannot identify a solution, consider reaching out to the kernel community for support. This could be through mailing lists, forums, or bug trackers associated with the Linux kernel.

Please note that debugging kernel issues can be complex, and the above steps provide a general guideline. It's recommended to have a good understanding of kernel development and debugging techniques.

My last imx7d-pico-pi-qca-m4.dts

/*
 * Copyright 2018 TechNexion Ltd.
 *
 * Author: Tapani Utriainen <tapani@technexion.com>
 *         Richard Hu <richard.hu@technexion.com>
 *         Ray Chang <ray.chang@technexion.com>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 *
 */

#include "imx7d-pico-pi-qca.dts"

/ {
	memory {
		linux,usable-memory = <0x80000000 0x1ff00000>;
	};

	reserved-memory {
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;		

		// m4_tcm: tcml@007f8000 {
		// 	compatible = "fsl, m4_tcml";
		// 	reg = <0x007f8000 0x8000>;
		// };

		vdev0vring0: vdev0vring0@9FFF0000 {
			reg = <0x9FFF0000  0x1000>;
			no-map;
		};

		vdev0vring1: vdev0vring1@9FFF1000 {
			reg = <0x9FFF1000  0x1000>;
			no-map;
		};

		// rsc_table: rsc_table@900ff000 {
		// 	reg = <0x900ff000  0x1000>;
		// 	no-map;
		// };

		vdevbuffer: vdevbuffer {
            compatible = "shared-dma-pool";
			reg = <0x9FFF2000 0xE000>;
			no-map;
		};
	};

    imx7d-cm4 {
        compatible = "fsl,imx7d-cm4";
        clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
        fsl,auto-boot;
		mbox-names = "tx", "rx", "rxdb";
		mboxes = <&mub 0 1
			  &mub 1 1
			  &mub 3 1>;
        memory-region =  <&vdev0vring0>, <&vdev0vring1>,  <&vdevbuffer> ;
        syscon = <&src>;

//		status = "okay";

    };

	m4_tcm: tcml@007f8000 {
		compatible = "fsl, m4_tcml";
		reg = <0x007f8000 0x8000>;
	};

	gpio-leds {
		status = "disabled";
	};
};

&adc1 {
	status = "disabled";
};

&adc2 {
	status = "disabled";
};

&gpt3 {
	status = "disabled";
};

&gpt4 {
	status = "disabled";
};

&ocram {
	reg = <0x00901000 0xf000>;
};

&rpmsg {
	// compatible = "fsl,imx7d-rpmsg";
//	compatible = "fsl,imx7d-cm4";
//	mbox-names = "tx", "rx", "rxdb";
//	mboxes = <&mub 0 1
//			  &mub 1 1
//			  &mub 3 1>;
//	memory-region = <&vdevbuffer>;
	vdev-nums = <1>;
	reg = <0x9fff0000 0x10000>;
	status = "okay";
};

&uart6 {
	status = "disabled";
};

&mub {
	status = "okay";
 };

&wdog3{
	status = "disabled";
};

[neuberfran]

@iuliana-prodan Pls, Why I can't see fsl,imx7d-mu (Or fsl,imx7-mu, Or fsl,imx8mp-mu)
in ../kernel-source/drivers/mailbox/imx-mailbox.c

How to implement this?
Could this be the cause of my kernel panic?

[neuberfran]

https://community.nxp.com/t5/Other-NXP-Products/imx-mailbox-c-Kernel-driver-Yocto-Kirkstone-missing-imx7d-pico/m-p/1800942#M20993

[iuliana-prodan]

@neuberfran very good you posted the question on NXP community.

imx7D or imx8MP are using the "fsl,imx6sx-mu" compatible.
See https://elixir.bootlin.com/linux/v6.7.3/source/arch/arm64/boot/dts/freescale/imx8mp.dtsi:

			mu: mailbox@30aa0000 {
				compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
				reg = <0x30aa0000 0x10000>;
				interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
				clocks = <&clk IMX8MP_CLK_MU_ROOT>;
				#mbox-cells = <2>;
			};

			mu2: mailbox@30e60000 {
				compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
				reg = <0x30e60000 0x10000>;
				interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
				#mbox-cells = <2>;
				status = "disabled";
			};

OR https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm/boot/dts/imx7d.dtsi#L306:

	mu: mu@30aa0000 {
		compatible = "fsl,imx7d-mu", "fsl,imx6sx-mu";
		reg = <0x30aa0000 0x10000>;
		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
		clocks = <&clks IMX7D_MU_ROOT_CLK>;
		clock-names = "mu";
		#mbox-cells = <2>;
	};

So, this means that is using these ops:(https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/mailbox/imx-mailbox.c#L899)

[neuberfran]

@iuliana-prodan You forgot about the great NXP AM62 for sale at Variscite: https://developer.toradex.com/hardware/verdin-som-family/modules/verdin-am62/

[iuliana-prodan]

@neuberfran please, try to understand, I'm not working on this and I've never worked with im7d.
I don't even have the board you're using.

As our tech support reply to you on NXP community (https://community.nxp.com/t5/Other-NXP-Products/imx-mailbox-c-Kernel-driver-Yocto-Kirkstone-missing-imx7d-pico/m-p/1800942#M20993), we don't provide support for the board your using.

You need to get the memory map of your board, see where the Cortex M core is mapped, what memory regions can it access, what MU is using, etc.

[neuberfran]

https://www.youtube.com/watch?v=V06RC2G_3M8

[neuberfran]

https://youtu.be/reaRG2VV6Lo?si=D_xdOqMp1QvtVsPF