Working with rpmsg on PRU0 and PRU1
Introduction
Beaglebone boards are an example of Heterogenous computing systems . Such systems refers to systems that use more than one kind of processors or cores. The objective of deploying different architectures can be to gain performance or energy efficiency by adding dissimilar coprocessors. In the beaglbone boards one of the coprocessors implemented is called PRUs. There are two of these termed as PRU0 and PRU1 and are used to perform tasks where real time performence is required.
In order to establish communication between the two RPMsg framework is used. It is based on virtio vrings to send/receive messages to/from the remote CPU over shared memory.The vrings are uni-directional, one vring is dedicated to messages sent to the remote processor, and the other vring is used for messages received from the remote processor. In addition, shared buffers are created in memory space visible to both processors.The Mailbox framework is then used to notify cores when new messages are waiting in the shared buffers. Relying on these frameworks, The RPMsg framework implements a communication based on channels. The channels are identified by a textual name and have a local (“source”) RPMsg address, and a remote (“destination”) RPMsg address”. Recently i wanted to implement communication between PRU0 and ARM core. I started with the Ultrasonic sensor example. Here you can see the Rpmsg fuctionality is implemented on the PRU1 core.But I wanted write my own code that could run on PRU0 as most of the enhanced PRU pins exposed on the header of pocketbeagle belongs to PRU0. In my further investigation i figured out some important aspects that one need to keep me mind to succeed in porting or implmenting rpmsg on any PRU core. Here i will be showing the changes that one should make in the ultrasonic sensor code to run it on Core0 and in the process you would understand some important aspects.
Broadly speaking when the code is loaded in the PRU using remoteproc, a channel is created with the name defined in the CHAN_NAME. Setting right value to it is very important as it determines which kernal module will be probed and used. Moreover, system events are configured using TO_ARM_HOST and FROM_ARM_HOST. Further whenever ARM core writes to shared memory it sets the interrupt pin, There is bit 31 of r31 register for PRU1 interrupt and bit 30 for PRU0.
Configuration for PRU1
#define HOST_INT ((uint32_t) 1 << 31)
#define TO_ARM_HOST 18
#define FROM_ARM_HOST 19
#define CHAN_NAME "rpmsg-pru"
#define CHAN_DESC "Channel 31"
#define CHAN_PORT 31
Apart from this you will have a resoure_table_1.h file included in your main file. This file also has 2 important sections which need to be configured with specific values as shown.
Mapping ofsystem events to a channel. Each pair contains a sysevt, channel.>
struct ch_map pru_intc_map[] = { {18, 3},
{19, 1},
};
Channel-to-host mapping, 255 is used for unused Mapping Channel-1 to Host-1 (PRU0/1 R31 bit 31), HOST_UNUSED represents 255
{
HOST_UNUSED, 1, HOST_UNUSED, 3, HOST_UNUSED,
HOST_UNUSED, HOST_UNUSED, HOST_UNUSED, HOST_UNUSED, HOST_UNUSED
},
Configuration For PRU0
#define HOST_INT ((uint32_t) 1 << 30)
#define TO_ARM_HOST 16
#define FROM_ARM_HOST 17
#define CHAN_NAME "rpmsg-pru"
#define CHAN_DESC "Channel 30"
#define CHAN_PORT 30
Similarly resource_table_0 file need to have following values Mapping ofsystem events to a channel. Each pair contains a sysevt, channel.>
struct ch_map pru_intc_map[] = { {16, 2},
{17, 0},
};
Channel-to-host mapping, 255 is used for unused Mapping Channel-0 to Host-0 HOST_UNUSED represents 255
{
0, HOST_UNUSED, 2, HOST_UNUSED, HOST_UNUSED,
HOST_UNUSED, HOST_UNUSED, HOST_UNUSED, HOST_UNUSED, HOST_UNUSED
},
I have also created a patch to automatically make the changes and port the code in the repository to run on PRU0. Patch using the instructions in README