Difference between revisions of "BeagleBoard/GSoC/2020Proposal/VedantParanjape"

From eLinux.org
Jump to: navigation, search
(Created page with "Category: BeagleBoard Category: GSoC Category: GSoCProposal2020 =ProposalTemplate = {{#ev:youtube|Jl3sUq2WwcY||right|BeagleL...")
 
 
(53 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
[[Category: GSoCProposal2020]]
 
[[Category: GSoCProposal2020]]
  
=[[BeagleBoard/GSoC/ProposalTemplate|ProposalTemplate]] =
+
=[https://elinux.org/BeagleBoard/GSoC/2020Proposal/VedantParanjape Proposal for Port am335x_pru_package to remoteproc] =
{{#ev:youtube|Jl3sUq2WwcY||right|BeagleLogic}} <!-- latest video will go here -->
 
  
 +
<!-- 
 +
{{#ev:youtube|Jl3sUq2WwcY||right|BeagleLogic}}latest video will go here
 
A short summary of the idea will go here.
 
A short summary of the idea will go here.
 +
-->
  
 
''Student'': [https://elinux.org/User:Vedant16 Vedant Paranjape]<br>
 
''Student'': [https://elinux.org/User:Vedant16 Vedant Paranjape]<br>
''Mentors'': [http://elinux.org/User:Jkridner Jason Kridner]<br>
+
''Mentors'': [http://elinux.org/User:Abhishek_ Kumar Abhishek], [http://elinux.org/User:ZeekHuge Zubeen Tolani]<br>
''Code'': https://github.com/BeaglePilot<br>
+
''Code'': https://github.com/beagleboard/am335x_pru_package<br>
''Wiki'': http://elinux.org/BeagleBoard/GSoC/ProposalTemplate<br>
+
''Wiki'': https://elinux.org/BeagleBoard/GSoC/2020Proposal/VedantParanjape<br>
''GSoC'': [https://summerofcode.withgoogle.com/archive/2016/projects/4885400476712960/ GSoC entry]<br>
+
''GSoC'': [N/A]<br>
 
<div style="clear:both;"></div>
 
<div style="clear:both;"></div>
  
Line 28: Line 30:
 
''Primary language'' : English, Hindi, Marathi<br>
 
''Primary language'' : English, Hindi, Marathi<br>
 
''Typical work hours'' : 10AM - 7PM Indian Standard Time<br>
 
''Typical work hours'' : 10AM - 7PM Indian Standard Time<br>
''Previous GSoC participation'': I find embedded pretty interesting field, 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
+
''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==
 
==About your project==
''Project name'': Super Awesome Project<br>
+
''Project name'': Port am335x_pru_package to remoteproc<br>
  
===Description===
+
==Description==
In 10-20 sentences, what are you making, for whom, why and with what technologies (programming languages, etc.)? (We are looking for open source SOFTWARE submissions.)
+
 
 +
;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 [https://elinux.org/images/6/6b/Using_virtio_to_Talk_With_Remote_Processors.pdf 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.
 +
<!--Going by your philosophy, you don't need Linux drivers at all. Mmap
 +
everything and do everything in userspace, why bother with the kernel at
 +
all? /dev/mem is your friend.
 +
 
 +
This is what I like most about RemotProc/RPMSG, in that you are using the same framework between ARM, PRU, DSP, etc.
 +
 
 +
-->
 +
;Features to be implemented:
 +
# [https://github.com/MuneebMohammed/PRUSS-Bindings Port this] python implementation of a remoteproc driver to C.
 +
# Implement a wrapper library to simplify tasks like writing to a pin, reading from a pin, delay, accessing memory.
 +
# Adding ELF support to PASM, as remoteproc only supports ELF binaries. Provide a option to build using clpru as well.
 +
# Port all the existing examples to use remoteproc.
 +
# Solve issues on [https://github.com/beagleboard/am335x_pru_package/issues am335x_pru_package] github.
 +
==Details of implementation==
 +
;[https://github.com/MuneebMohammed/PRUSS-Bindings Port this] python implementation of a remoteproc driver to C
 +
 
 +
:Python based driver can be quite slow, as compared to a C driver for high speed operations on the PRU, I propose to port this python remoteproc driver to C driver. Make it similar to how the UIO driver's interface was.
 +
 
 +
;Implement a wrapper library to simplify tasks like writing to a pin, reading from a pin, delay, accessing memory.
 +
 
 +
:# Writing to a pin: ''__R30 ^= (1 << 3)''. This can be replaced by a more intuitive command like ''GPO_set_level(pin,  state)''
 +
:# Delay: ''__delay_cycles(100000000)'' to wait for 500ms, this is non intuitive, this can be replaced by a command like ''delay(TIME(in ms))''
 +
 
 +
If we define functions to wrap around the existing function, it can increase the size of the firmware, to overcome this, we can use MACROS to define these functions.
 +
;Adding ELF support to PASM, as remoteproc only supports ELF binaries. Provide a option to build using clpru as well
 +
:[https://dzone.com/articles/converting-a-raw-binary-file-into-an-elfdwarf-file 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.
 +
 
 +
;Solve issues on [https://github.com/beagleboard/am335x_pru_package/issues am335x_pru_package] github
 +
 
 +
:# Solve issue [https://github.com/beagleboard/am335x_pru_package/issues/44 #44], [https://github.com/beagleboard/am335x_pru_package/issues/41 #41], [https://github.com/beagleboard/am335x_pru_package/issues/49 #49]
 +
 
 +
;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
  
 
===Timeline===
 
===Timeline===
Provide a development timeline with a milestone each of the 11 weeks and any pre-work. (A realistic timeline is critical to our selection process.)
 
 
 
{| class="wikitable"
 
{| class="wikitable"
| Mar 30 || Proposal complete, Submitted to https://summerofcode.withgoogle.com
+
| May 4 || Proposal accepted or rejected || Community Bonding Period and discussion on the project and resources available.  
 
|-
 
|-
| Apr 27 || Proposal accepted or rejected
+
| June 1 || Pre-work complete || Coding officially begins!
 
|-
 
|-
| May 18 || Pre-work complete, Coding officially begins!
+
| June 8 || Milestone #1 ||
 +
* Introductory YouTube video
 +
* Setting up PocketBeagle i.e flashing up to date Linux image and Testing user-led blink code :D
 +
* Running existing example codes from this [https://github.com/beagleboard/am335x_pru_package repository]
 +
* Creating header file for the ported driver.
 
|-
 
|-
| May 25 || Milestone #1, Introductory YouTube video
+
| June 15 || Milestone #2 ||
 +
* Implementing modprobe and modunprobe functions
 +
* Testing the above functions
 +
* Writing documentation for same
 +
* Setting up documentation generators like readthedocs
 
|-
 
|-
| June 1 || Milestone #2
+
| June 22 || Milestone #3 ||
 +
* Implementing pru_load_firmware, pru_start, pru_stop and pru_read_state functions, and remaining debugfs functions.
 +
* Testing the above functions
 +
* Writing documentation for same
 
|-
 
|-
| June 8 || Milestone #3
+
| June 29 - July 3 18:00 UTC || Milestone #4 (Phase 1 evaluations) ||
 +
* Demonstrating use of implemented functions by running LED Blink code using the functions.
 +
* Finalizing and documenting everything done till now, submitting first report for evaluation
 
|-
 
|-
| June 15 18:00 UTC || Milestone #4, Mentors and students can begin submitting Phase 1 evaluations
+
| July 10 || Milestone #5 ||
 +
* Implementing a tool to convert PASM binaries to ELF binaries, accepted by remoteproc.
 +
* Testing the above tool
 +
* Writing documentation
 
|-
 
|-
| June 19 18:00 UTC || Phase 1 Evaluation deadline
+
| July 17 || Milestone #6 ||
 +
* Porting all the example codes to use the remoteproc based prussdrv
 +
* Adding more simple examples like LED Blink, LED toggle switch, etc.
 
|-
 
|-
| June 22 || Milestone #5
+
| July 24 || Milestone #7 ||
 +
* Add option to use clpru for compilation
 +
* Writing documentation
 
|-
 
|-
| June 29 || Milestone #6
+
| July 27 - July 31 18:00 UTC || Milestone #8 (Phase 2 evaluations) ||
 +
* Demonstrating use of tool to convert binaries to ELF binaries and use of clpru
 +
* Finalizing and documenting everything done till now, submitting second report for evaluation
 
|-
 
|-
| July 6 || Milestone #7
+
| August 3 || Milestone #9 ||
 +
* Implementing wrapper library
 +
* Adding documentation for the wrapper library
 +
* Testing the library
 
|-
 
|-
| July 13 18:00 UTC || Milestone #8, Mentors and students can begin submitting Phase 2 evaluations
+
| August 10 || Milestone #10 ||
 +
* Solving issues [https://github.com/beagleboard/am335x_pru_package/issues/44 #44], [https://github.com/beagleboard/am335x_pru_package/issues/41 #41], [https://github.com/beagleboard/am335x_pru_package/issues/49 #49]
 +
* Completing the documentation
 +
* Taking feedback from mentors
 
|-
 
|-
| July 17 18:00 UTC || Phase 2 Evaluation deadline
+
| August 17 || Milestone #11 || Completion YouTube video
 
|-
 
|-
| July 20 || Milestone #9
+
| August 24 -  August 31 18:00 UTC || Final week || Students submit their final work product and their final mentor evaluation
 
|-
 
|-
| July 27 || Milestone #10
+
| August 31 - September 7 18:00 UTC || End of Session || Mentors submit final student evaluations  
|-
 
| August 3 || Milestone #11, Completion YouTube video
 
|-
 
| August 10 - 17 18:00 UTC || Final week: Students submit their final work product and their final mentor evaluation
 
|-
 
| August 17 - 24 18:00 UTC || Mentors submit final student evaluations
 
 
|}
 
|}
  
 
===Experience and approach===
 
===Experience and approach===
In 5-15 sentences, convince us you will be able to successfully complete your project in the timeline you have described.
+
I have decent experience in C++, C and Python. I have done several projects involving embedded systems like ESP32, I well-versed with freeRTOS. [https://github.com/VedantParanjape/pid-plotter-component 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 [https://github.com/VedantParanjape/ROS-Workshop-ESP32-Codes firmware] for a 3 DOF arm based on a ESP32 custom board. I did a internship with a embedded deviced startup, where I built:
 +
# Built TCP network stack for embedded IoT Devices
 +
# Implemented Synchronous TCP server using Boost.Asio(C++) and Boost.Thread(C++)
 +
# 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 [https://github.com/vedantparanjape/ my github page]
 
===Contingency===
 
===Contingency===
What will you do if you get stuck on your project and your mentor isn’t around?
+
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.
 
+
# https://git.ti.com/pru-software-support-package 
 +
# https://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs PRU Guide 
 +
# https://markayoder.github.io/PRUCookbook/ Mark Yoder's cookbook is a excellent guide
 +
# Derek Molly's beagle bone guide provides all the information needed for getting up and running with my beagle.
 +
# The technical reference manuals provided by TI on am3358 and am5729 are the best source
 +
# [https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_01_00_08/linux/index.html Processor SDK Linux Software Guide] is a good reference material
 +
# [https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-remoteproc sysfs remoteproc class documentation]
 
===Benefit===
 
===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.
+
:The reason I have been pushing is because I understood remoteproc loading is to have better support in mainline, and that means longer-term support for the community
 
+
::-Jason Kridner
==Misc==
 
Please complete the requirements listed on the [[BeagleBoard/GSoC/Ideas#General_requirements|ideas page]]. Provide link to pull request.
 
 
 
===Suggestions===
 
Is there anything else we should have asked you?
 

Latest revision as of 02:44, 31 March 2020


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. Port this python implementation of a remoteproc driver to C.
  2. Implement a wrapper library to simplify tasks like writing to a pin, reading from a pin, delay, accessing memory.
  3. Adding ELF support to PASM, as remoteproc only supports ELF binaries. Provide a option to build using clpru as well.
  4. Port all the existing examples to use remoteproc.
  5. Solve issues on am335x_pru_package github.

Details of implementation

Port this python implementation of a remoteproc driver to C
Python based driver can be quite slow, as compared to a C driver for high speed operations on the PRU, I propose to port this python remoteproc driver to C driver. Make it similar to how the UIO driver's interface was.
Implement a wrapper library to simplify tasks like writing to a pin, reading from a pin, delay, accessing memory.
  1. Writing to a pin: __R30 ^= (1 << 3). This can be replaced by a more intuitive command like GPO_set_level(pin, state)
  2. Delay: __delay_cycles(100000000) to wait for 500ms, this is non intuitive, this can be replaced by a command like delay(TIME(in ms))

If we define functions to wrap around the existing function, it can increase the size of the firmware, to overcome this, we can use MACROS to define these functions.

Adding ELF support to PASM, as remoteproc only supports ELF binaries. Provide a option to build using clpru as well
Refering to this webpage.
  1. 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
  2. ‘myApp.bin’ is the application binary file, and it adds an ELF/Dwarf header file to the output file myApp.bin.elf.
Solve issues on am335x_pru_package github
  1. Solve issue #44, #41, #49
Port all the existing examples to use remoteproc.
Reimplement stock examples in pru_package repository
  1. PRU_industrialEthernetTimer
  2. PRU_PRUtoPRU_Interrupt
  3. PRU_memAccessPRUDataRa
  4. PRU_memAccess_DDR_PRUsharedRAM
I intend to add simple examples like LED Blink, LED toggle switch, etc to the examples directory

Timeline

May 4 Proposal accepted or rejected Community Bonding Period and discussion on the project and resources available.
June 1 Pre-work complete Coding officially begins!
June 8 Milestone #1
  • Introductory YouTube video
  • Setting up PocketBeagle i.e flashing up to date Linux image and Testing user-led blink code :D
  • Running existing example codes from this repository
  • Creating header file for the ported driver.
June 15 Milestone #2
  • Implementing modprobe and modunprobe functions
  • Testing the above functions
  • Writing documentation for same
  • Setting up documentation generators like readthedocs
June 22 Milestone #3
  • Implementing pru_load_firmware, pru_start, pru_stop and pru_read_state functions, and remaining debugfs functions.
  • Testing the above functions
  • Writing documentation for same
June 29 - July 3 18:00 UTC Milestone #4 (Phase 1 evaluations)
  • Demonstrating use of implemented functions by running LED Blink code using the functions.
  • Finalizing and documenting everything done till now, submitting first report for evaluation
July 10 Milestone #5
  • Implementing a tool to convert PASM binaries to ELF binaries, accepted by remoteproc.
  • Testing the above tool
  • Writing documentation
July 17 Milestone #6
  • Porting all the example codes to use the remoteproc based prussdrv
  • Adding more simple examples like LED Blink, LED toggle switch, etc.
July 24 Milestone #7
  • Add option to use clpru for compilation
  • Writing documentation
July 27 - July 31 18:00 UTC Milestone #8 (Phase 2 evaluations)
  • Demonstrating use of tool to convert binaries to ELF binaries and use of clpru
  • Finalizing and documenting everything done till now, submitting second report for evaluation
August 3 Milestone #9
  • Implementing wrapper library
  • Adding documentation for the wrapper library
  • Testing the library
August 10 Milestone #10
  • Solving issues #44, #41, #49
  • Completing the documentation
  • Taking feedback from mentors
August 17 Milestone #11 Completion YouTube video
August 24 - August 31 18:00 UTC Final week Students submit their final work product and their final mentor evaluation
August 31 - September 7 18:00 UTC End of Session Mentors submit final student evaluations

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

The reason I have been pushing is because I understood remoteproc loading is to have better support in mainline, and that means longer-term support for the community
-Jason Kridner