BeagleBoard/GSoC/2019Proposal/PRUUserSpaceAPI-PratimUgale

From eLinux.org
< BeagleBoard‎ | GSoC
Revision as of 07:33, 31 March 2019 by Pratimugale (talk | contribs) (Timeline)
Jump to: navigation, search


Proposal for PRU User Space API project

{{#ev:youtube|Jl3sUq2WwcY||right|BeagleLogic}}

This project aims to provide an API for different programming languages to load/unload firmware and communicate with the PRUs from User Space.

Student: Pratim Ugale
Possible Mentors: Kumar Abhishek, Zubeen Tolani
Wiki: https://elinux.org/BeagleBoard/GSoC/Ideas#PRU_User_Space_API
GSoC: GSoC entry

Status

This project is currently just a proposal.

Proposal

I have completed the requirements listed on the ideas page and have opened a pull request here.

About you

IRC: pratimugale
Github: Pratim Ugale
School: Veermata Jijabai Technological Institute (VJTI), Mumbai
Country: India
Primary language: English
Typical work hours: 08:00 to 21:00 IST (GMT+ 05:30)
Previous GSoC participation: I haven't participated in GSoC before. Having used open source technologies and programming forums before to solve my problems, I want to start contributing back to the community through GSoC and then continue on my own.

About your project

Project name: PRU User Space API

Description

Introduction
This project will enable the control of the Beaglebone's PRUs from a User Space Client Program on the ARM. The PRU is a dual core micro-controller system present on the AM335x SoC (TI's ARM A8 based chip) which powers the BeagleBone. It is meant to be used for high speed jitter free IO control. Being independent from the linux scheduler and having direct access to the IO pins of the BeagleBone Black, the PRU is ideal for offloading IO intensive tasks.
  • The User Space Client Program must be able to
    • Load firmware into the PRU cores
    • Control PRU execution (start, stop, etc.)
    • Manage resources (memory, interrupt mappings, etc.)
    • Have a method to send/receive messages
The new Remoteproc and RPMsg drivers will be used for the ARM<->PRU communication.
  • The remoteproc framework allows different platforms/architectures to control (power on, load firmware, power off) remote processors while abstracting any hardware differences.
  • A scalable TLV (table, length, value) Table (Resource Table) is used to inform the remoteproc driver about the remote processor’s available resources. To configure the Resource Table, one typically needs to modify up to three things.
    • Event-to-channel mapping
    • Channel-to-host mapping
    • Number and location of vrings
  • Rpmsg is a Linux framework designed to allow for message passing between the kernel and a remote processor. It uses a virtual ring buffer (VRING) that allows one to post messages to this buffer. Then, interrupts are used to notify the PRU/ARM that messages are in the buffer. RPMsg provides scalability for integrating individual PRU peripherals with the respective driver sub-systems.
Deliverables
The project will consist of the following components:
  • The User Space Client Program: I plan to provide two mechanisms for the User Space Program to access remoteproc :
    • Through
  • The user space libraries for the API in different programming languages. The API will use UNIX sockets to communicate with the Daemon server.
  • The Daemon: Written in python, the daemon will listen to the requests, use language bindings to call the appropriate Remoteproc and RPMsg functions, and pass the corresponding return value back to the userspace program.
  • The PRU Remoteproc and RPMsg device drivers
  • The PRU firmware
  • Documentation: This is one of the most important aspects of the project. Currently, the documentation regarding the PRU remoteproc and RPMsg drivers is scattered, incomplete and outdated. Also, there is a steep learning curve to program the PRUs. I plan to provide an exhaustive Documentation along with hands-on examples so that one can utilize the PRU to its full capacity.
The Project

The workflow of the project is:
UserSpace Client Program <-> API Libraries <-> Daemon <-> Language Bindings <-> pru_rproc, rpmsg_pru <-> Remoteproc, RPMsg drivers <-> PRU

The PRU attributes and its functions will be encapsulated into a single unit.

The functions provided by the Daemon will be:

  • disableHdmi()  : By uncommenting "dtb=am335x-boneblack-emmc-overlay.dtb" from ‘/boot/uEnv.txt’ file
  • modprobe(), rmmod()  : For loading and removing remoteproc module
  • reboot()  : Reboots the PRU cores. After the firmwares are /lib/firmware/am335x-pru1(0)-fw is present, rebooting the PRU cores automatically loads the PRU with these firmwares. The sysfs bindings at the ‘/sys/bus/platform/drivers/pru-rproc/’ are to be used to reboot the PRUs
  • configPinMux():  : Config-pin utility - To change the pinmux settings for a pin does not need device tree overlays now (4.4+ kernel), you can simply use ‘config-pin’ utility.
  • shutdown(int core)  : Shuts the PRU core provided in the parameter ("echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind" for PRU 0)
  • boot(int core)  : Boots the PRU core provided in the parameter ("echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind" for PRU 0)
  • reboot(int core)  : To shutdown and boot the PRU core
  • writemsg(), readmsg() using "/dev/rpmsg_pru30" and "/dev/rpmsg_pru31"  : Read/Write message to PRU

PRU Debugging Functions: Using Remoteproc, we can actually see the content of the PRU registers; we can execute one instruction at a time on the PRU, and then wait for the user for a flag to execute the next instruction.

Timeline

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

--TODO--: While putting together your proposal, you should pick out a set of GPIOs that you will target for your project. If we can change that to be more generic, then great.

Community Bonding Period(6th May - 26th May)
  • Unavailable until 15th May due to End Semester Examinations
  • Learn Rust and Node.js (How to create libraries)(Won't take me much time as I have already started working on it.)
Week 1 (27th May - 2nd June)
  • Start implementing disableHdmi(), modprobe(), rmmod(), functions in Python
  • Test the Blinky example given here which requires loading firmware, configuring pinmux and rebooting the PRU cores.
  • SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.
Week 2 (3rd June - 9th June)
  • Start making the Daemon (in python) that will listen to requests on UNIX sockets.
  • Write the functions that the Daemon will listen to and call the respective functions created above.
  • Make the Introductory Youtube Video
Week 3 - 4 (10th June - 23rd June)
  • Create the API libraries that the User Space Client Program will use to interact with the daemon.
  • Test the above with examples given in the PRU CookBook.

At the end of Phase 1, I must complete the Daemon and API for atleast two languages.

Week 5 (24th June - 30th June)
  • Directly create API for different programming languages using language bindings.
Week 6 (1st July - 7th July)
  • Create a simple program that displays in the terminal the status of the PRU at that time, the resources it is using and firmware that is loaded on it.
Week 7 (8th July - 14th July)
  • Create GUI for the above. The GUI must also be able to start/stop; load and unload firmware into the PRUs
Week 8, 9 (15th July - 21st July)
  • Write API libraries for more languages.
Week 9 (22nd July - 28th July)
  • Add the PRU debugging functions.
Week 10 (29th July - 4th August)
  • Porting some legacy PASM projects into the new remoteproc framework.
  • Test these new examples.
Week 11 (5th August - 11th August)
  • Documentation for all the languages along with examples.
  • The Documentation will also contain the errors one might expect while working with the PRU and how to resolve them.
Week 12 (12th August - 18th August)
  • Buffer Period in case of any disturbance in the timeline.
  • Make the Completion Youtube Video

Experience and approach

I am in my sophomore year of engineering, doing Information Technology. I am currently enrolled in a "Computer Organisation and Architecture" course which motivated me to learn more about the PRUs. I have worked with C, Python, Java, C++, Makefiles, Vimscript before.
I have learnt Linux driver development over the Internet in the past few months (I have implemented basic programs, and listed the errors I encountered on my github profile here).
I have worked with the Arduino UNO and ATMega boards before (made a self balancing and line following bot using PID algorithm in college).
I have always been using Linux(Ubuntu) as my primary OS, so getting along with Embedded Linux won't be a problem.
Hence, I am confident that I'll be able to complete the given project in due time.

Contingency

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

While working with open source software, one thing I realised for sure is that one has to be self-sufficient. Knowing how to use a search engine effectively is also an important skill. I like to give my best before asking anyone else for help when I’m stuck with any problem and I consider it to be a way I actually learn and become independent.

However, if I get terribly stuck on a problem, and the mentor isn't around, I shall:

Benefit

If successfully completed, what will its impact be on the BeagleBoard.org community?

This project will allow larger programs to be developed in the programming language of the user's choice. Right now one has to manually load the firmware and execute long commands to get things done. The API will provide simple and intuitive functions so that the user can easily read values from the PRU and use them for his/her other needs directly from the program itself.

   Mar 08 05:03:15 <zeekhuge[m]>: 
   To make it easy to use interface and standards for the PRU. 
   Right now, we have to execute commands to get some code loaded onto the PRUs, by echoing into the sysfs entries.
   Also, the remoteproc mechanism allows to communicate with the PRUs using char device entries (mostly, and can be configured). 
   The APIs need to provide a way, in different languages, to be able to read and write message to and from the PRUs within the program itself.
                 Zubeen Tolani(zeekhuge)

Benefit of using Remoteproc :- The UIO is just like random memory access while Remoteproc is more systematic and very well supported by the kernel and can be used to allow PRUs to use other resources as well like DMA access. Also, using Remoteproc, PRUs can act as different hardware devices (implemented by code on the PRU). For example, if the firmware on PRU can read/write data using SPI interface, then using Remoteproc, PRUs can act as if it was a SPI device itself, and the SPI system will just work with it.

Future Work

  • In the future, the project will be expanded to support many more programming languages.
  • The Documentation will always be updated to use the newest methods that are developed.

Suggestions

Is there anything else we should have asked you?