BeagleBoard/GSoC/2020Proposal/VedantParanjape

=Proposal for Port am335x_pru_package to remoteproc =

Student: Vedant Paranjape Mentors: Kumar Abhishek, Zubeen Tolani Code: https://github.com/beagleboard/am335x_pru_package Wiki: https://elinux.org/BeagleBoard/GSoC/2020Proposal/VedantParanjape GSoC: [N/A]

=Status= This project is currently just a proposal.

=Proposal= Completed all the requirements listed on the ideas page. the code for the cross-compilation task can be found here submitted through the pull request #138.

About you
IRC: vedant16 Github: https://github.com/vedantparanjape/ School: Veermata Jijabai Technological Institute (VJTI) Country: India Primary language : English, Hindi, Marathi Typical work hours : 10AM - 7PM Indian Standard Time Previous GSoC participation: I find embedded pretty interesting, given I have experience with ESP32, I think I will be able to excel in this project. This is the first time i am participating in GSoC

About your project
Project name: Port am335x_pru_package to remoteproc

Description

 * Introduction


 * This project will enable the control of the Beaglebone's PRUs using remoteproc and rpmsg driver rather than using uio drivers. The PRU is a dual core micro-controller system present on the AM335x SoC 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 remote processor (RPROC) framework allows the different platforms/architectures to control (power on, load firmware, power off) remote processors while abstracting the hardware differences. In addition it offers services to monitor and debug the remote coprocessor. This eliminates the need of a custom kernel driver for varying range of devices, and in general kernel driver development is a tough task. Using remoteproc vastly increases development efficiency. It also reduces the probability of severe kernel exploits due to elimination of need to write a kernel driver for PRU, rather a Userspace API which is uses sysfs to communicate with RPROC(remoteproc). Even though prussdrv which currently uses uio to handle PRU. RPROC is specially built for the task of handling interprocessor task, it supports full featured interprocessor communications. Thus developing a custom kernel driver for each device is a futile task. Rather we should use an uniform and inbuilt way to access PRU across various BeagleBoards.


 * How is it better that using uio_pruss?


 * With a kernel framework like RPROC, it is possible to create firmware defined devices that can be accessed like any other Linux device under /dev.To Linux, this would look no different to /dev/tty0. The Virtio is an extremely powerful concept. RPMSG/RemoteProc is implemented in kernel space and UIO_PRUSS is implemented in userspace. UIO_PRUSS is also a compromise to system security.


 * If we consider a simplistic example of toggling an LED, It might be easier to implement this in uio_pruss, but when we are dealing with more serious device interface, the infrastructure available with RemoteProc makes the implementation much easier.


 * Features to be implemented:
 * 1) Updating prussdrv C library to use remoteproc interface rather than the uio interface.
 * 2) Adding ELF support to PASM, as remoteproc only supports ELF binaries. Provide a option to build using clpru as well.
 * 3) Port all the existing examples to use remoteproc.
 * 4) Create a GUI application to control PRU and load firmware into it.

Details of implementation

 * Updating prussdrv C library to use remoteproc interface rather than the uio interface.


 * Implement basic functions to control the PRU like start, stop, load binary firmware and load the drivers


 * modprobe: Load the pru_rproc module using modprobe
 * modunprobe: Unload the pru_rproc module using rmmod
 * pru_start: Starts the specified PRU(0/1) by writing "start" to /sys/class/remoteproc/.../state, runs the firmware indicated by, or written to, /sys/class/remoteproc/.../firmware
 * pru_stop: Stops the specified PRU(0/1) by writing "stop" to /sys/class/remoteproc/.../state
 * pru_read_state: Reports the current state of the specified PRU(0/1) by reading into /sys/class/remoteproc/.../state
 * pru_load_firmware: Copies the provided firmware to /sys/class/remoteproc/.../firmware


 * I intend to implement functions like RESUME, PAUSE using sysfs /sys/kernel/debug/remoteproc/remoteproc.


 * Adding ELF support to PASM, as remoteproc only supports ELF binaries. Provide a option to build using clpru as well
 * Refering to this webpage.
 * We can make a ELF file out of a bin (raw binary) file with the GNU ‘objcopy‘ command like this: arm-none-eabi-objcopy.exe --input-target=binary --output-target=elf32-little myApp.bin myApp.bin.elf
 * ‘myApp.bin’ is the application binary file, and it adds an ELF/Dwarf header file to the output file myApp.bin.elf.


 * Port all the existing examples to use remoteproc.


 * Reimplement stock examples in pru_package repository
 * PRU_industrialEthernetTimer
 * PRU_PRUtoPRU_Interrupt
 * PRU_memAccessPRUDataRa
 * PRU_memAccess_DDR_PRUsharedRAM
 * I intend to add simple examples like LED Blink, LED toggle switch, etc to the examples directory

Command line can be intimidating for beginers and windows users ;)
 * Create a GUI application to control PRU and load firmware into it.


 * So, i propose to use a GUI to control the PRU, and load firmware as well remoteproc kernel module. Users comfortable with command line can use the command line utility.
 * This is implemented using Qt5, I have linked the GUI i intend to use.

Experience and approach
I have decent experience in C++, C and Python. I have done several projects involving embedded systems like ESP32, I well-versed with freeRTOS. I recently did a project on ESP32, in which I used ESP to control and plot PID loop running on the embedded device, plotting the values on a python GUI. Other than that I have developed firmware for a 3 DOF arm based on a ESP32 custom board. I did a internship with a embedded deviced startup, where I built:
 * 1) Built TCP network stack for embedded IoT Devices
 * 2) Implemented Synchronous TCP server using Boost.Asio(C++) and Boost.Thread(C++)
 * 3) Implemented a tool to calculate round trip time(RTT) of tcp packets

I actively contribute to open source and do a lot of mini projects throughout the year, you can find my several more interesting projects at my github page

Contingency
I believe that if I get stuck on my project and my mentor isn’t around, I will use the resources that are available to me. Some of those information portals are listed below.
 * 1) https://git.ti.com/pru-software-support-package
 * 2) https://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs PRU Guide
 * 3) https://markayoder.github.io/PRUCookbook/ Mark Yoder's cookbook is a excellent guide
 * 4) Derek Molly's beagle bone guide provides all the information needed for getting up and running with my beagle.
 * 5) The technical reference manuals provided by TI on am3358 and am5729 are the best source
 * 6) Processor SDK Linux Software Guide is a good reference material
 * 7) sysfs remoteproc class documentation

Benefit
If successfully completed, what will its impact be on the BeagleBoard.org community? Include quotes from BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.

Misc
Please complete the requirements listed on the ideas page. Provide link to pull request.

Suggestions
Is there anything else we should have asked you?