openamp_rsc_table App in imx7d-pico (M4-Side name in Zephyr=pico_pi_m4) I cant see /dev/ttyRPMSG #69433
Comments
neuberfran
changed the title
|
Hello, I'm trying to acheive the same RPSMG communication on an CL-SOM-IMX7D. Have you got any progress or success ? I've seen a first thing is that we are missing the ressource table definition in the linker script of the imx7d soc. Similar to the one on the imx8m m7 core: When you compile the openamp_rsc_table example, there should not be saying "orphaned section .ressource_table...". add the linker section to a linker.ld file like on the imx8m/m7 example and change the linker script path in the imx7d soc imx7/m4: Cmakelist.txt: imx7/m4 linker.ld: I'm not upstreaming my changes for now since I'm still having issues with my linux kernel to get rpmsg to work. |
|
BTW have you also compiled and inserted the drivers/rpmsg/imx_rpmsg_tty.c kernel module as mentionned by the sample ? |
|
@jlh-makeen I'm glad you showed up about imx7 and remoteproc using resource table. I'm kinda alone in this (imx7d) for now
https://community.toradex.com/t/rpmsg-does-not-work-on-imx8m-plus/13740/92?page=4 -12 = missing memory Every codes to github analyzer: below = imx_rpmsg_tty.c
#define RPMSG_NUM_BUFS (128) #define to_imx_virdev(vd) container_of(vd, struct imx_virdev, vdev) rpdev->ivdev[i]->vring[0] = start; #define MAX_RPMSG_NUM_BUFS (128) #define RPMSG_RESERVED_ADDRESSES (1024) |
Yes And You said: I've seen a first thing is that we are missing the ressource table definition in the linker script of the imx7d soc. I suggest you read and participate in this meeting |
|
my Kconfig.defconfig.mcimx7_m4 don`t have config IPM_IMX_REV2 Compared to mimx8mm6_m4 |
|
You are using Yocto kirkstone with Linux kernel 5.15 right ? A the moment I have a Kirkstone image with Linux 5.10.9 and a backport of the imx-rproc drivers from 5.15 and a hack to boot my image from OCRAM (our app program uses more than 32kB). Might be too outdated as mainline kernel imx-rproc driver for 5.10.9 has quite some differences from 5.15 driver.
As soon as I define the mailboxes in the A7 DT and start the M4, I get a seg fault. That might be our fault from missing something in the backport, but we are struggling with Compulab not having released a kernel and patches for newer than linux 5.10.9. |
|
@jlh-makeen Yes I have Yocto Kirkstone. Linux Kernel version 5.15.52. What about your device vendor? Do u have qspi (I don Why I can`t see vdev0buffer in result of the cat /sys/kernel/debug/remoteproc/remoteproc0/carveout_memories And cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table commands? M4 Side is not completely inert. Some main start-of-function messages are shown. But it never shows the hello-world from the imx_rpmsg_tty driver nor the messages from the rpmsg_client_sample driver What are you trying to do? Maybe like me I want to echo > test /dev/ttyRPMSG using Zephyr's openamp_rsc_table so we can work together on this |
|
We are trying to achieve the same goal which is have /dev/ttyRPMSG up in Linux to talk to the M4 chip. We are using the Compulab vendor with their CL-SOM-IMX7. The module is a 1GB Ram variant. But their BSP is outdated and is using the linux kernel lf-5.10.y with vendor patches: We also have a custom carrier board with 4x RS485 ports used by the Cortex M and 1x UART for the Cortex A. My kernel at the moment: As per my colleague who is responsible for the Linux yocto image, the generic ttyRPMSG driver, mentionned by the openamp_rsc_table sample was introduced in Linux 5.16 (CONFIG_TTY_RPMSG). I'm using this Zephyr version, before the switch to v2 boards/soc directory structure. Regarding the A7 device tree: And the carveout/ressource tables outputs: |
|
You said: "As per my colleague who is responsible for the Linux yocto image, the generic ttyRPMSG driver, mentionned by the openamp_rsc_table sample was introduced in Linux 5.16 (CONFIG_TTY_RPMSG)." I never knew anything about it. If you could provide more details, I would appreciate it. |
|
I managed to fix my driver crashing and can now start my M4 processor correctly and have rproc probe the core and kick the MU. Yes, up until 5.15 we had the imx_rpmsg_tty driver but there was introduced a new more generic one as rpmsg_tty from 5.16. Not sure it has more feature though. Check out the nxp/linux-imx repo, latest revision: Which is different from: It is now part of the imx_v8_defconfig file: I'm also suspecting that something is missing in about the NS annoucement in the RPMSG on Linux. Here is an associated driver source that listens to annoucements: |
|
Here is a hint that may indicate that I'm right about the NS annoucement thing: Linux lf 6.6.y: The tty_rpmsg and imx_rpmsg_tty don't use the same annoucement id's. And guess what, the Zephyr implementation uses the "rpmsg-tty" channel id: |
|
You have a lot of useful knowledge. Please help me more on my imx7d-pico (Remoteproc and echo test > /dev/ttyRPMSG regarding mounting the DT and the zephyr overlay file: As you will see below, I am now focusing on using OCRAM (0X00901000 using F000) and not 9FF00000 in Remoteproc. Is it right? And this is my overlay on zephyr and other settings: Are you using ipm_imx_rev2??? Or not? Please, Look it. Nothing about virtio0 (type 7) (this, immediately above.) |
|
Well it's hard to tell because I've not gotten /dev/ttyRPMSG to appear on my system yet. I don't see errors in when you start the M4 core though, so that's a first good thing. I'm not sure if the shared memories and vrings can reside in the OCRAM region 0x009xxxxx. On our system we have put them in DDR area at address 0xBFF00000 since we only have 1GB of RAM (from 0x80000000 to 0xBFFFFFFF). I believe you are accessing the sh_mem on the "System bus" aka as RAM and not CODE. Therefore pay attention to the addresses. Maybe I'm wrong, but I'd suggest you use DDR instead of OCRAM. If you have 1GB ram, use 0xBFF00000, if you have 512MB, use 0x9FF00000 |
|
@jlh-makeen I have 1gb here (imx7d-pico with 1gb Model and not 512mb model) Are you using ipm_imx_rev2??? Or not? For a better basis, we have this updated an5317: |
I don't believe we are using IPM_IMX_REV2 no. |
|
@jlh-makeen below = imx_rpmsg_tty.c
#define RPMSG_NUM_BUFS (512) #define to_imx_virdev(vd) container_of(vd, struct imx_virdev, vdev) rpdev->ivdev[i]->vring[0] = start; #define MAX_RPMSG_NUM_BUFS (512) #define RPMSG_RESERVED_ADDRESSES (4096) |
|
I'm sorry I'm no sure if this will be useful. One thing my colleague pointed out is that the function virtqueue_get_available_buffer() fails on my zephyr program: This could explain why the Name Service (NS) notification don't wakeup the drivers in Linux (as for my case at least). Here is what I can log from my zephyr appplication: EDIT: Well I've added some printk statements here and there in my Zephyr openamp: I can see that the buffers are correctly taken from the vdev0buffer reserved memory which is 0xbff02000 and onwards. But nothing else happens on the Linux side unfortunately. |
|
Unfortunately, I still don't have carveout for vdev0buffer And /dev/ttyRPMSG. pico_pi_m4.overlay imx7d-pico-pi-qca-m4.dts |
|
@jlh-makeen I really need vdev0buffer to appear in Cat Carveout result and you (maybe) need to check the correct mailbox passage (mub or mu?) |
|
So regarding the DT configs, Zephyr needs to use MU_B 0x30ab0000 and Linux needs to use MU_A 0x30aa0000. Otherwise you get a ressource conflict. |
|
@jlh-makeen Pls. Tell me Why I don't have vdev0buffer in Cat Carveout Cmd Result |
damn! Am I always doing it wrong using mub on Linux and Zephyr? And what do you think about my mbox-namex (tx0, rx0, rxdb0 and not tx, rx, rxdb) and my mboxes (mub 0 1, mub 1 1 and mub 3 1) I change my main.c in openamp_tsc_table Zephyr project to ret = rpmsg_create_ept(&tty_ept, rpdev, "rpmsg-virtual-tty-channel", But not solved yet I change 9ff00000 to bff00000 |
|
It looks mostly right, your zephyr side was missing a zero in the reg= <0x9ff00000... But you know I'm not expert here and I still haven't got my ttyrpmsg to show up. I would disable the rpsmg node as the rproc is also allocating the mailboxes and virtio rpmsg bus. |
|
@jlh-makeen Pls, give-me your main.c from openamp_rsc_table. I think there are differences between your main.c and mine. I want to keep them both the same. |
You can run the default openamp_rsc_table sample without modifications. It is only necessary to provide the Zephyr ipc and shm nodes with the same setting as your Linux side, I advise that you use DDR for the shared memory vrings/vdevbuffer and zephyr side shm, in order to have symetric setup in zephyr/linux (the addresses will be the same). When the openamp_rsc_table sample starts up, you should see rpmsg virtio bus ns-announcements, even if you don't have tty-rpmsg driver from Linux 5.16. If you have that, you'll be ready for rpmsg :) |
I need change my /home/neuberfran/zephyrproject/zephyr/include/zephyr/arch/arm/cortex_m/scripts/linker.ld from this: to?????????? |
|
As I explained before to this: |
|
@jlh-makeen Unfortunately, it hasn't been resolved yet. The *.bin file generated after the changes did not fit in the Uboot partition (I had to remove it to load Linux). According to the commands in the photo, I still have virtio0 in the directories, but I still don't have /dev/ttyRPMSG |
|
@jlh-makeen In portuguese to english novo=new and antigo=old. VsCode only noticed 2 changes
|
|
@jlh-makeen I'm already suspecting that my vrings may not be 0x1000 but rather 0x8000. So I don't know if I have enough (remaining) memory for the vdevbuffer and what the vdevbuffer would look like. Could you tell me? |
In order to get rpmsg to work, we had to update to kernel 5.16 to have the official tty-rpmsg and rpmsgctrl drivers. When rproc cannot allocate the memory you request (512 bytes * CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF) For 0x8000 you can go up to CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=32 buffers Our particular setup: When our app starts we created 3 tty endpoints: In our case we needed the linker script to start the M4 boot-vector as I mention in this discussion: I'll provide a PR for the bootvector when I have time. Regarding the if your kernel doesn't have the rpmsg-tty driver but instead the: You also need to use mbox id 0 as mentionned before in the Linux DT. |
|
After I chage zephyr,flash (to)= &ocram_code; (from &tcml_code)
|
|
|
I carried out several tests today, but unfortunately still without success.
|
|
@jlh-makeen Hello. Firstly, I want to congratulate you for being able to upload /dev/ttyRPMSG using Remoteproc/Linux-UserSpace/Zephyr Upstream on your imx7d device (even though it only has 1gb) For my part, I haven't managed it yet and I would like you (if possible) to clarify my doubts using the photos below:
|
There is no need to modify the Linux driver, at least in Linux 5.16. We have only been able to successfully have ttyRPMSG on Linux 5.16 (and newer should work too) You need PR #71684 in order to have the zephyr.elf file place the rom_start region (aka boot vector) into the OCRAM_S in order to be able to boot the M4 core using tcml_code memory. There is a trick where you can get the M4 to boot by using ocram_s by changing the definition in the DT for ocram_s_code from address to the alias 0x00000000, this way the rproc driver is going to properly load the zephyr.elf file and boot-vectors at the right place. I do not have the ressources and time to try it with linux 5.15, we need people from NXP or your vendor to support us here. As I explained linux 5.15 doesn't include the generic "tty-rpmsg" driver but instead the "imx-tty-rpmsg" which uses different rpmsg-endpoint names. As of now, people have been very silent on the subject. |
|
@jlh-makeen I can do echo "test2" > /dev/ttyRPMSG0 and led light red blink in cp2102 UART-USB adapter in USB1 (by m4 side) But nothing appear in USB1 m4 side |
|
@neuberfran Does /dev/ttyRPMSG0 show up by itself in the /dev directory ? Because I can see the dmesg output it not showing that the rpmsg-tty driver was probed by the annoucement on channel rpmsg-tty / 0x401. Did you manage to update to Linux 5.16 or are you still on 5.15 ? If on 5.15, you probably don't have the rpmsg-tty driver but rather the imx_rpmsg_tty driver instead. See the endpoint names here: Change is done here: I haven't tested on kernel 5.15 and cannot test it for you. Make sure you also enable the LOGGING framework in Zephyr to see all the messages coming on the M4 side as it doesn't use PRINTK the print statements in openamp_rsc_table example. |
|
Yes, I use kernel 5.16 now, So I'm trying two approaches:
In this case the resulting zephyr.bin became very large (511m) (i don't know why). 1,1) I even tried to approach your approach (that is, using PR) and uploading zephyr.elf only in sysfs (echo start) in Userspace, but I got error -62 and I can't upload rproc that way, unfortunately.
I could be wrong, but this concludes that I have to use zephyr.bin(Uboot starts) and zephyr.elf(rproc starts) in this project on a mandatory basis. Otherwise I may have error -62 Now comes the issue that Linux (TX part of Linux) is not sending messages (**RPMsg/OpenAMP messages) to the Zephyr ** You can see in the window on the right side of the last photo (print screen) I posted that (despite CONFIG_PRINTK=n and CONFIG_LOG_PRINTK=n) some messages already arrive in m4, but not the main ones about RPMsg and OpenAMP, type test in echo "test" > /dev/ttyRPMSG0 What I've already tried to resolve:
Please, give-me your main_remote.c and your prj.conf generic and your_board.conf |
|
Let me try to be as clear as possible. We have a custom carrier board using the cl-som-imx7d from Compulab so some changes might not be necessary on your board: In the Zephyr DT I have &mub set to status = "okay" Regarding the project I can build the native example from samples/subsys/ipc/openamp_rsc_table using this board config: Create boards/makeen_gw_mcimx7d_m4.conf in samples/subsys/ipc/openamp_rsc_table: Before Building you must use my ROMSTART_REGION relocation PR in order to have the correct boot-vector placement for Linux RPROC. You don't need the BIN files anymore, only ELF file. Then on your Linux board create the following boot_m4.sh script: Don't forget to Build : Then SCP the Then call the script: It should output the following: Now I have 2 To use the shell you can use your TTY terminal of choice like minicom: Then press CTRL+C a few times to trigger the shell prompt: You can also use /dev/ttyRPMSG1 to see the regular TTY echo of the sample when you send data to the tty Be aware that the sample uses approximately 48kB of CODE memory so I think you must run the code from OCRAM, but RAM usage is approx 20kB and can fit on any of TCM/OCRAM_S/DDR I hope this helps. |
|
@jlh-makeen Tks. But I don't want open /dev/ttyRPMSG0 in minicom or picocom. I want:
|
Congrats ! You don't see anything from your LOG_INF because you have not enabled CONFIG_LOG=y. Try to add a printk statement instead, like this: When you receive a message from Linux, you'll the message content appear in the Zephyr console. Now it is implementation details you will have to care about by yourself, now that /dev/ttyRPMSG shows in Linux and the RPMSG sample works on your platform I think we should close the issue as it's resolved. If you encounter application specific requests, feel free to report to the documentation or open a new issue for the new subject. |
|
@jlh-makeen Unfortunately, I still couldn't get echo test > /dev/ttyRPMSG0 to appear in the other window I am one of the first interested parties to close this topic. I thought that adding the printk you suggested would solve it (it was the only thing I hadn't tried yet). But unfortunately not yet
prj.conf pico_pi_m4.conf This is Correct Result When Everything Works Ok 5.2 openamp_rsc_table application in Page=12 |
|
Pls
|
|
It is weird that printk doesn't display the message can you print the size of the message too ? |
|
Linux rx message [5]
|
|
@jlh-makeen??????? |
You succesfully received the "test\n" string so it is working, the length of the message is 5 :) You don't see the message because I made a mistake with the printk: See the test here: |
|
@jlh-makeen Tks. With Other things I changed (in main remote.c) to have the messages shown in the screenshot below:
|
|
Excellent, here we are finally 👍 Regarding the LOG framework, the default level is INF that's why you had to change the module default level, but you could also have changed the default log level in prj.conf: Refer to the logging doc: |
Hi,
https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table#id6
I stay trying this since last month in my imx7d-pico (m4 side) Zephyr upstream board is pico_pi_m4 using mailbox=mub
I can run Remoteproc and zephyr on this device but without resource table, vrings and RPMsg: https://www.youtube.com/watch?v=NFyEJXIpq4E
Now I stay trying openamp_rsc_table
based on this link below:
#60455
I can go up and run everything but the channel and /dev/ttyRPMSG are not created
cat /sys/kernel/debug/remoteproc/remoteproc0/carveout_memories
cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table
pico_pi_m4.overlay
In linux Yocto A7 Side imx7d-pico-pi-qca-m4.dts (file):
Why I can`t see vdev0buffer in result of the cat /sys/kernel/debug/remoteproc/remoteproc0/carveout_memories And cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table commands?
Why when I change MAX_RPMSG_NUM_BUFS and MAX_RPMSG_BUF_SIZE from 512 to 256 in virtio_rpmsg_bus.c (file in rpmsg/drivers in my linux kernel), nothing change in Number of buffers 8 in my resource_table?
Edited:
Change CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=8 to
CONFIG_OPENAMP_RSC_TABLE_NUM_RPMSG_BUFF=512 in prj.conf. But not solved.
The text was updated successfully, but these errors were encountered: