BeagleBoard/GSoC/PRUs to offload processing of raw data

< BeagleBoard‎ | GSoC
Revision as of 03:39, 3 April 2017 by Rishabh bb (talk | contribs)
Jump to: navigation, search

PRUs to offload processing of raw data

The idea is to be able to access on-board peripherals like the McSPI, McASP etc from the PRUs and to be able to use fetch data directly from these peripherals. This will allow to offload processing of the Raw data onto the PRUs. The project will basically involve developing C libraries for the PRUs to connect to these peripherals, developing DT overlays for the peripherals to be used and developing Drivers to reserver the device on behalf of the PRUs.

Student: Rishabh Sheth
Mentors: Zubeen Tolani


This project is currently just a proposal.


I cross-complied "Hello world" application and generated a pull request as per requirement. Apart from this to prove my ability I made programs on DToverlay for LED on off using switch, simple Loadable Kernel Module (LKM) and LED blinking using PRU. I have successfully tested code on BeagleBone Black. Currently I am learning more advance concept which can help me in this project.

About you

IRC: rishabh_bb
Github: rishabh00
School: Dharamsinh Desai University
Country: India
Primary language: Hindi, English
Typical work hours : 9AM-6PM IST
Previous GSoC participation: I am participating first time in GSoC.

I am hobbyist and love to play with embedded systems. Normally I used AVR microcontroller for my projects but as project grows I need more powerfully platform and I that's how I found beagle-bone. I used BBB as server in my current semester project of Generic ZigBee stack simulation. I am vary impressed with capabilities & performance of this board . It will be honer for me to contribute in such great community. GSoC project will not only help me to improve my knowledge but this is a kind of project which will definitely help community and add more capability in BeagleBone .

About your project

Project name: PRUs to offload processing of raw data from on-board Peripherals


PRUs stands for Programmable Real-time Units it is low‐latency microcontroller subsystem. There are two independent PRU execution units with features like 32‐Bit RISC architecture, 200Mhz single cycle execution,no pipeline, interrupt Controller ,fast I/O interface. This makes PRU best choice for real time processing task in board like BeagleBone which have Linux OS running on it. The programmable nature of the PRUs, along with their access to pins and events, provide flexibility in implementing custom peripheral interfaces, fast real-time responses, power saving techniques, specialized data handling and DMA operations, and in offloading tasks from the other processor cores of the system-on-chip (SoC).

The goal of this project is to be able to access on-board peripherals and allow to offload processing of the Raw data. The main part in project is to develop C libraries for the PRUs to connect to on-board peripherals. This will reduce load on main processor and enhance performance of device.

ARM + PRU SoC Architecture

From above image you can see that the L3 and L4 bus are exposed with both ARM core and PRUs, so we can directly poke all of the peripheral registers from PRUs. As this bus are exposed to ARM core and PRUs we need to make sure that main CPU isn't trying to access them at a same time so when PRU accessing on-board peripherals we need to manually disable access of particular on-board peripherals for the main CPU. Currently I don't find way so that both processor can access same peripheral. This thing needs more exploration and if it is possible then it should be left for future expansion of this project as our major goal is to make APIs for maximum possible peripherals.

Following are some impotent part in system which will encounter(need) during development of this project :

The OCP ports : (Open Core Protocol ports) are generally used for communication between various subsystem on the same chip. PRU-ICSS use this to access external peripherals that are present on the SoC. These ports allow PRU to SoC peripheral (RAM, SPI unit, ADC etc) communication, or A8 MPU to PRU-ICSS peripheral (shared RAM, INTC, instruction RAM etc) communication. The OCP master port is for PRU to external peripheral (via L3 connect bus) communication and OCP slave port is for External peripheral to PRU-ICSS peripheral communication (via L4 connect bus).


INTC : The PRU-ICSS INTC supports up to 64 system interrupts from different peripherals and PRUs to be mapped to 10 channels inside the INTC (see Figure PRU_INTC). Interrupts from these 10 channels are further mapped to 10 Host Interrupts. This is an Interrupt controller can use to manage interrupts from one PRU to other, from PRU to external peripherals or from external peripherals to PRU.

Constant Table : The PRU Constants Table is a structure connected to a dedicated interface on the PRU core within the PRU that is used to provide the base address for the Load Burst Constant + Offset (LBCO) and Store Burst Constant + Offset (SBCO). The PRU constants table is provided in order to maximize the usage of the PRU register file for embedded processing applications by moving many of the commonly used constant or deterministically calculated base addresses from the internal register file to an external table. This will reduce peripherals access timing.

Scratch Pad : Another possibility is that we can use both PRUs at a time for same peripheral offloading. i.e some part of processing done by PRU0 then using Scratch Pad feature pass it to PRU1 then got to read new data PRU1 will do further processing !! I think this is interesting idea and time permits I will work on this. Using this feature we can further distribute task which helps to utilise all available resource but feasibility and usefulness of this concept needs to discusses.

Goal is to support maximum external on-board peripherals for offload processing I will develop solution for peripherals in following sequence : McASP > CAN > SPI > I2C > Ethernet > UART > eCAP and then other reaming peripherals ( If time permits ). The reason behind this is PRUs have it's own dedicated Internal peripheral modules (UART, eCAP, MII_RT, MDIO, and IEP) so that thing we can use directly.

My workflow will be in this manner for each periphars : Develop DT Overlay for specific peripherals : To reserve that pins for PRUs Develop Device driver : To pass message can communicate with peripherals & MCU Develop APIs : for connecting on-board external peripherals Test APIs

My plan is to develop APIs in C for more portability compared to Assembly ( If needed then in line assembly can be add in APIs )

The remoteproc framework allows different platforms/architectures to control (power on, load firmware, power off) remote processors while abstracting any hardware differences. It already exists and enables us to use rpmsg framework for message sharing. Rpmsg is a Linux framework designed to allow for messageg passing between the kernel and a remote processor.

I will develop hole project on newest version of software and kernel available. For the PRU APIs, firmware development and testing I will use remoteproc and RPMsg. Combination of remoteproc/rpmsg (+ virtio transport) frameworks use for services like Load the Firmware ,Manage resources (memory, CPU, etc.), Control execution (start, stop, etc.), Send/receive messages to share data, synchronize through event(interrupts).


Provide a development timeline with a milestone each of the 11 weeks. (A realistic timeline is critical to our selection process.)

2017-06-06: Milestone #1
2017-06-13: Milestone #2
2017-06-20: Milestone #3
2017-06-27: Milestone #4
2017-07-04: Milestone #5
2017-07-11: Milestone #6
2017-07-18: Milestone #7
2017-07-25: Milestone #8
2017-08-01: Milestone #9
2017-08-08: Milestone #10
2017-08-15: Milestone #11

Experience and approach

I am


What will you do if you get stuck on your project and your mentor isn’t around?


If successfully completed, what will its impact be on the community? Include quotes from community members who can be found on and