OpenAMP hangs at MX_OPENAMP_Init() when started from U-Boot, even after waited for linux to fully booted up.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2020-04-14 6:51 PM
When I run the openamp image through linux command prompt, the application working fine. The RPMSG devices is created successfully.
But when I've tried to run it from uboot, it stuck at MX_OPENAMP_Init(). This should be ok because I assume linux isn't running yet.
After I've tried to delay the application for one minute (assuming linux is booted up properly), it still stuck there.
I need a very-fast M4 booting, with RPMSG feature (ok to be delayed).
Hence it must be run from U-Boot. Is this kind of requirement possible?
Please help.
Solved! Go to Solution.
- Labels:
-
STM32MP15 Lines
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2020-04-19 11:40 PM
Hi @fwajie jspa
You have to define a resource table in your coproc .elf.
See https://wiki.st.com/stm32mpu/wiki/Coprocessor_resource_table
Most of example provided in STM32Cube_FW_MP1 package such as OpenAMP_TTY_Echo implement it properly for reference.
Hope it help
Olivier
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2020-04-16 2:01 AM
Hi @fwajie jspa
Indeed, the FW is blocked in OpenAMP_Init function through rproc_virtio_wait_remote_ready(vdev) until the kernel start the TTY.
If still stuck after Linux boot there 2 things to check :
1 - Linux properly detect firmware is running :
- You should see in dmesg message « synchronizing with early booted co_procesor
- /sys/class/remoteproc/remoteproc0/state sould be "running"
if not the case check you properly set « early-booted » option in DT Linux ( cat /proc/device-tree/m4@0/
2- resource table should be present and properly read
- cat /sys/kernel/debug/remoteproc/remoteproc0/resource _table
you should see entry points vdev, « Vring 0 » and « Vring1 »
Else check you properly integrate a resource table in your elf.
Hope it help,
Olivier
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2020-04-17 2:06 AM
Here is the response:
Is there something I must do to the kernel? it seems the kernel isn't ready to sync with early_boot processes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2020-04-19 11:40 PM
Hi @fwajie jspa
You have to define a resource table in your coproc .elf.
See https://wiki.st.com/stm32mpu/wiki/Coprocessor_resource_table
Most of example provided in STM32Cube_FW_MP1 package such as OpenAMP_TTY_Echo implement it properly for reference.
Hope it help
Olivier
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2020-04-20 12:23 AM
Ok, it seems the problem occured after I've update some layers in yocto. It is solved now. thanks.
