Difference between revisions of "BeagleBoard/GSoC/PRUs to offload processing of raw data"

From eLinux.org
Jump to: navigation, search
 
(4 intermediate revisions by the same user not shown)
Line 39: Line 39:
 
===Description===
 
===Description===
  
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).
+
PRUs stands for Programmable Real-time Units it is low‐latency micro controller 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, specialised data handling and DMA operations, and in offloading tasks from the other processor cores of the system-on-chip (SoC).
 
   
 
   
  
Line 56: Line 56:
 
'''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.  
 
'''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.  
+
'''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 deterministic 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.       
 
'''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.  
+
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.<br>
  
'''My workflow will be in this manner for each periphars :'''  
+
'''My workflow will be in this manner for each peripherals :''' <br>
Develop '''DT Overlay''' for specific peripherals : To reserve that pins for PRUs
+
Develop '''DT Overlay''' for specific peripherals : To reserve that pins for PRUs<br>
Develop '''Device driver''' : To pass message can communicate with peripherals & MCU
+
Develop '''Device driver''' : To pass message can communicate with peripherals & MCU<br>
'''Develop APIs :''' for connecting on-board external peripherals  
+
'''Develop APIs :''' for connecting on-board external peripherals <br>
Test APIs  
+
Test APIs <br>
  
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 )
+
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 )<br>
  
 
The remoteproc framework allows different platforms/architectures to control (power on, load firmware, power off) remote processors while
 
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.
+
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 message passing between the kernel and a remote processor.<br>
 
 
 
   
 
   
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)'''.  
+
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, synchronise through event(interrupts)'''.  
  
  
Line 81: Line 80:
 
===Timeline===
 
===Timeline===
  
''' Before Result Declaration '''
+
<br>''' Before Result Declaration '''<br>
 
My semester exam is going to end by 15th April so I planed to spent some hour regularly for this project. My first goal during this period would be get all possible knowledge of BeagleBone and make basics vary clear. Then get some what mastery or say confidence in making DT overlays and device driver. As the main goal of this project is to make C Library's to access and process data from on board peripherals it better knowledge of DT overlays and drivers will help me to do more focus work on developing Library's.   
 
My semester exam is going to end by 15th April so I planed to spent some hour regularly for this project. My first goal during this period would be get all possible knowledge of BeagleBone and make basics vary clear. Then get some what mastery or say confidence in making DT overlays and device driver. As the main goal of this project is to make C Library's to access and process data from on board peripherals it better knowledge of DT overlays and drivers will help me to do more focus work on developing Library's.   
  
Line 110: Line 109:
 
2) Currently I don't know what actually time it may required so I also left this week for some buffer period ( If any additional thing needs to be done then I will do it in this week).<br>
 
2) Currently I don't know what actually time it may required so I also left this week for some buffer period ( If any additional thing needs to be done then I will do it in this week).<br>
  
<br>June 27 - July 18  Week-5-6-7 <br>
+
<br>'''June 27 - July 18  Week-5-6-7 '''<br>
 
Aim: Add offloading support for SPI and I2C <br>
 
Aim: Add offloading support for SPI and I2C <br>
 
Description:<br>
 
Description:<br>
Line 140: Line 139:
 
3) Test developed code and if any bug is there try to resolve.<br>
 
3) Test developed code and if any bug is there try to resolve.<br>
 
    
 
    
<br>August 15 - August 21 Week-12<br>
+
<br>'''August 15 - August 21 Week-12'''<br>
 
Aim: Buffer Week & submit code for final evaluation  <br>
 
Aim: Buffer Week & submit code for final evaluation  <br>
 
Description: <br>
 
Description: <br>

Latest revision as of 09:05, 3 April 2017


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
Code: https://github.com/rishabh00
Wiki: http://elinux.org/BeagleBoard/GSoC/PRUs_to_offload_processing_of_raw_data

Status

This project is currently just a proposal.


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

Description

PRUs stands for Programmable Real-time Units it is low‐latency micro controller 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, specialised 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).

PRU_INTC

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 deterministic 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 peripherals :
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 message 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, synchronise through event(interrupts).



Timeline


Before Result Declaration
My semester exam is going to end by 15th April so I planed to spent some hour regularly for this project. My first goal during this period would be get all possible knowledge of BeagleBone and make basics vary clear. Then get some what mastery or say confidence in making DT overlays and device driver. As the main goal of this project is to make C Library's to access and process data from on board peripherals it better knowledge of DT overlays and drivers will help me to do more focus work on developing Library's.


May 30 - June 6 Week-1
Aim: Start developing C libraries, DTO & Drivers for the McASP
Description:
1) I will start my work from developing DeviceTree Overlay and Drivers for accessing McASP peripherals
2) After completion of above task I will start working on C libraries for McASP offload processing.


June 7 - June 13 Week-2
Aim: Testing first C library and validating concept
Description:
1) I will finish my work on developing C libraries for McASP offload processing.
2) In this week I will also test my code by developing some simple example.
3) This will be first major achievement in whole project so it needs to validate first by mentor so I will send my code for sugetion and this will assure me that I am on right track.



June 14 - June 20 Week-3
Aim:Start work on CAN
Description:
1) After getting review from mentor if need I will change code so that further development be on track.
2) In this week I planed to start work on CAN interface this include developing its DT overlays, Drivers and C Library


June 20 - June 27 Week-4
Aim: Testing CAN interface
Description:
1) I will complete developing C library for CAN interface and if I will check my code by some demo or how to use application.
2) Currently I don't know what actually time it may required so I also left this week for some buffer period ( If any additional thing needs to be done then I will do it in this week).


June 27 - July 18 Week-5-6-7
Aim: Add offloading support for SPI and I2C
Description:
As its been 4 week from now I will have good understanding and grep on development so I will push my self heard in this 3 week do maximum work
1) First I will work on SPI peripherals and then I2C peripherals
2) My first step would be to make DT overlays and and Driver to SPI and I2C peripherals from PRUs
3) Then Devlope library for SPI and I2C peripherals.


July 18 - July 25 Week-8
Aim: Validated previously developed 4 on-board peripherals and do add patch if need
Description:
1) Second Evaluation : so according to feed back I will do changes in my code which will makes it more error less and help in further development
2) My focus in this week is test my code for previously developed 4 on-board peripherals

After this week only two week remaining and according to plan I have completed support for 4 on-board peripherals offloading. Now in weeks remain so in that from remaining peripherals like UART , Ethernet, eCAP which ever is possible and benefit to community I will try to build C library for that.


July 25 - August 8 Week-9-10
Aim: Add support for at list one other peripherals
Description:
1) After discussing with mentor mentor I will start working on adding support for last peripherals buy developing its C library, and then DTO and drivers

As BegalBone Board have other on board peripherls which is not covered in this project due to time constrain GSoC pus on us I will windup my work in such way that remaining peripherals support can be added after GSoC ends.


August 8 - August 15 Week-11
Aim: Documentation of Project
Description:
1) In this week I will do proper documentation of code APIs using Doxygen.
2) I will commit final code on git repository
3) Test developed code and if any bug is there try to resolve.


August 15 - August 21 Week-12
Aim: Buffer Week & submit code for final evaluation
Description:
1) This week has been kept for any unpredictable delays happens so this time can be utilised if needed

Experience and approach

I am currently in my last year of Electronics and Communication engineering. During this four years I learned from basic of electronics and programming to advance topics such as Microprocessor, ARM architecture, Modern OS etc. During this period I practicaly worked on 8085 microcontroll, 8088 microprocessor and NXP's LPC2368 ( ARM development kit ).So I have good knowledge of how all this system works.

Apart from this I work on various embedded projects evolving AVR microcontroller and programming with C, Assembly so I have vary good command on this two language. In this semester my project is to make Generic APIs for ZigBee cluster library. I implemented various stack of ZigBee( like APS, NWK, ZCL ) but the amazing part is I cross compiled my code and I make BeagleBone Black as server ( data push ) and my laptop as client ( coordinator ), it ran successfully. Apart from this I made various program on BBB like DT overlay for LED & switch , Basic Linux kernel module and blinking led. This all shows my capability to work on such complex project in BeagleBone and I am continuously trying improve my knowledge in this topic.

I also attend various seminars and workshops on embedded system plus I did online courses from prestigious university like MIT , Delf on edx.org. I also did internship in two embedded company so my this experience will also help me in this project.

Finally My team was finalist in 2016 e-YRC national robotics My team's work competition organise by IIT-Bombay and Indian government (More then 19,200 student participated). It is 6 month competition in which you have do coding on embedded robot they provided to us also do documentation and all.

So this all shows I have required skills, and right attitude for the project like this.


Contingency

I will try to get help from IRC chat , other open source forums. Plus TI have good documentation so refereeing it thoroughly will definitely going to help. As I said early I did internship in two embedded company so I know some prudent people there and I am sure they will help me in this kind of problem. I am member of IEEE and in committee of our collage IEEE student branch so I have contacts in my collage and region where I can ask for solution. My collage professors can also help me out if I get stuck .

Benefit

TI’s Sitara Processors are based on ARM Cortex-A core. One of these processors that is used in the microcomputer board BeagleBone is AM335x . These processors have a very interesting subsystem called PRU-ICSS. It can be thus said that AM335x has 3 processing cores. Two of them are enclosed in the PRU-ICSS subsystem and are called PRUs. This SoC have architecture such that PRUs can access all SoC peripherals but till now not any strong work done in direction of accessing all on-board peripherals and process the data. This project aims to provide bridge to this problem by developing APIs, DTO and drivers to access peripherals and process data from PRUs. After completion of this project it will easy process development process plus by offloading we are reducing burden on main processor so it will definitely improve MCU performance. I am very sure that this project will help Beagle community a lot.

Suggestions

-