Linux: AM335x RPMsg devices not detected

Please post what Linux version you are using.

Jaime,

I am also having a hard time seeing the rpmsg character devices. No 'pru' devices are seen in /dev

I am using 4.9.59-ga75d8e9305 which I believe is the latest TI SDK version. I have also been trying to use 4.14 version under Yocto->Poky

When I go to run the example rpmsg_client_sample.ko nothing is output after following along in the PRU labs and RPMsg Quick Start Guide you linked above.

Any help would be greatly appreciated or other debugging tips to try.

Thank you!

-Mike T

Hello Jaime & Mike,
I'll try to help both of you. If it gets too cluttered, Mike can start a new thread and reference this one.

Jaime,
What is your kernel and where are you getting it from? Make sure you are using a TI-provided kernel, because remoteproc functionality hasn't made its way to the mainline kernel quite yet.

Mike,
1) Same thing as Jaime. Make sure it's a TI-provided kernel ( 4.9.59-ga75d8e9305 is from TI, as long as you didn't add any patches to it)
2) What board are you using?
3) I have verified the quick start guide example works on BeagleBone Black with the prebuilt image in Linux Processor SDK 4.2. Can you get it working with the prebuilt image?

Regards,
Nick

Hello Mike,

Did you upgrade to the PRU SW support package 5.1.0 as found in Processor SDK 4.2: ti-processor-sdk-linux-.../example-applications/pru-icss-.../ ? (or git.ti.com/.../ )

I actually updated the RPMsg Quick Start guide using PRU SW Support Package 5.1.0 and Processor SDK 4.2 about a month ago, so /dev/rpmsg-pru* devices are still used when using system events. Again, let me know if you see anything different while going through the Quick Start guide using the prebuilt image in SDK 4.2.

Regards,
Nick

Nick,

I only see the current version as v04.02 http://www.ti.com/tool/PROCESSOR-SDK-AM335X nothing around 4.2 for the SDK.  The PRU SW Support Package has a note saying it is no longer being maintained and to use the Processor SDK instead since it is incorporated in that package.

This is the version, v04.02, that I'm using.  What does it mean if I do not have any /dev/rpmsg_pru* devices but am getting the 100 'Hello World' messages being sent to the PRU and received back on the ARM side?

Is there an exact list of kernel modules that need to be loaded?  I did see a rpmsg_char module somewhere, but I do not have that loading or building in the latest SDK.

-Mike T

Hello Mike,

Processor SDK 04.02 and Processor SDK 4.2 are the same thing. When the PRU SW Support Package was first introduced, users had to download it separately on TI.com and then add it to the Processor SDK. Nowadays, it is automatically included in the Processor SDK at (e.g.) ti-processor-sdk-linux-am335x-evm-04.02.00.09/example-applications/pru-icss-5.1.0.

So if you're using the PRU SW Support Package in Processor SDK 4.2, then the PRU SW Support Package version is 5.1.0.

As far as modules go: as long as you are 1) building the Linux Kernel with RPMsg support and building the modules as per the RPMsg Quick Start Guide, 2) installing the modules into the filesystem as per the Quick Start Guide, you should be able to see /dev/rpmsg_pru*. I think but am not sure that simply using ti-processor-sdk.../bin/create-sdcard.sh is sufficient to see rpmsg_pru as well.

I would be surprised if you got the Hello World messages but were unable to see the pru modules. The PRU should only echo back if PRU channels have been established as in the PRU_RPMsg_Echo_Interrupt0/main.c :

/*
 * Using the name 'rpmsg-pru' will probe the rpmsg_pru driver found
 * at linux-x.y.z/drivers/rpmsg/rpmsg_pru.c
 */
#define CHAN_NAME			"rpmsg-pru"
#define CHAN_DESC			"Channel 30"
#define CHAN_PORT			30

Something to note is that I believe Lab 5 expects CHAN_NAME to be "rpmsg-client-sample" while the Quick Start Guide expects it to be "rpmsg-pru". I'm not sure if that could be causing problems for you.

Regards, 

Nick

Nick,

Ok on the SDK 04.02 = 4.2  ... I wasn't sure since you weren't using the 2 digits...thought you may have meant 4.20 perhaps.  Yes, I am using 5.1.0 since I have the 04.02.00.09 TI SDK.

I have used the create.sdcard.sh, but prefer to TFTP boot and NFS mount my rootfs for faster development and debugging;-)

I am getting the 100 'Hello World' messages and see this showup in dmesg and on the console/shell from my UART.  Here is why I do not think you need to have /dev/rpmsg-pru*

In the main.c file of PRU_RPMsg_Echo_Interrupt1 for 5.1.0 it says this:

/*
* Using the name 'rpmsg-client-sample' will probe the RPMsg sample driver
* found at linux-x.y.z/samples/rpmsg/rpmsg_client_sample.c
*
* Using the name 'rpmsg-pru' will probe the rpmsg_pru driver found
* at linux-x.y.z/drivers/rpmsg/rpmsg_pru.c
*/
#define CHAN_NAME "rpmsg-client-sample"
//#define CHAN_NAME "rpmsg-pru"

#define CHAN_DESC "Channel 31"
#define CHAN_PORT 31

As you can see, the rpmsg-pru channel name is commented out.  Then if you look at the rpmsg-client-sample.c file, found at the above commented location, the rpmsg_sample_probe does not create or look for any /dev/rpmsg-pru* devices.  These are used only when channel name is "rpmsg-pru."  So, different probe functions get called depending on which CHAN_NAME you are using.  Digging in a little further, the rpmsg_device struct seems to use a different way to communicate via endpoints and I never see anything in the linux-x.y.z/drivers/rpmsg_core & other files that suggest needing or using device files rpmsg-pru*

My initial problem as the original poster stated was that we should see /dev/rpmsg-pru* device files and I associated this for the example programs and rpmsg-client-sample kernel module not working.  However, my issue wasn't that the /dev/rpmsg-pru* files were missing but rather previous version of the PRU SW Support Package (and rolled into the AM335X SDK) were using system events for mailboxes around the 59 range.  However, the newer examples use system events 16-19 for mapping events to channels.  Also, the code snippet indicates that rpmsg-client-sample.ko is used instead of rpmsg-pru.

Anyways, hope this is becoming clearer and others that perhaps fall into this can see.

Thanks!

-Mike T