BeagleBoard/GSoC/PRU I2C-SPI master furtherwork - GSoC 2018

= Create a PRU based soft-peripheral example =

Student: Hernan Gonzalez Mentors: Hunyue Yau Code: https://github.com/hgonzalez234/ Wiki: http://elinux.org/BeagleBoard/GSoC/PRU_SPI_master_soft-peripheral_-_GSoC_2018

=Status= This project is currently just a proposal.

=Proposal= I have completed the requirements listed on the ideas page and created a pull request here.

About me
IRC: hgonzalez Github: https://github.com/hernang234 School: Facultad de Ciencias Exactas, Ingeniería y Agrimensura, UNR, Rosario Country: Argentina Primary language: Spanish, English Typical work hours: 11:00 - 11:00 UTC Previous GSoC participation: This is my first GSoC participation. During my internship at VanguardiaSur, I worked on developing a UART driver for the Sitara platform on a BBB. This experience introduced me to the open source world and made me realize that I want to contribute back to the community and, if possible, make a career out of it. Working on the GSoC would be an ideal starting point.

About the project
Project name: Create a PRU SPI master

Description
The PRU is a hard realtime co-processor with dedicated realtime pins. Previous GSoC have created an assortment of examples and foundation pieces. However, most of them have custom interfaces. This project is to tie things together to implement at least one example of using the PRU with a standard interface. For example, this can be a SPI master interface that can be bound with another peripheral via DT. Goal: Create at least one non trivial example that includes both the PRU firmware and the kernel driver interface. Utilization of remoteproc (other means of loading the firmware will be considered provided it is appropriately justified) to load the firmware and control the PRU. A device driver should expose the functionality using standard kernel APIs. The example should NOT be a trivial one (i.e. GPIO controller, simple input events, plain on-off LEDs) unless proper justification is provided. Simple non trivial possible examples include SPI master, I2C master (potential HW issues), or UART. This project includes creating the relevant PRU firmware.

Implementation
The project can be divided into the following stages:

Get in-depth knowledge of how the protocol and the frameworks work in order to develop a clean PRU implementation.
 * Re-study SPI protocol and Remoteproc/RPMsg frameworks

Focus on the PRU behavior as a SPI master.
 * Develop the PRU firmware

The device driver should support standard kernel APIs.
 * Develop the device driver

Once the firmware is loaded on the PRUs and before the driver’s module is probed, the device should be added to the DT, a DT overlay could be made to accomplish this.
 * Develop a device tree overlay

Testing could be done against a STM32 or something similar that can work as a SPI slave, a real peripheral. Code for this will also be part of the project.
 * Testing

Extensive documentation of the process and use of the PRU will be written, as one of the goals of this project is to show the capabilities of the PRU. It is hard for someone just starting with the PRU to find and order the existent documentation as there are a lot of outdated examples out there.
 * Documentation & Debugging


 * NOTE: If things go smoother than in the plan, further work on the line of this project could be made, e.g. use the PRU as a video capture interface and expose it as a v4l2 interface, which will include making a camera PRU-SPI/v4l2 driver. The schedule can and will be revisited with the mentor at every stage of the project.

Week 1: May 14 - May 20

 * Re-study the protocols: SPI.
 * Re-study the remoteproc and RPMsg frameworks.
 * Re-study the PRU documentation
 * Study SPI masters implementations to define a proper way to develop the PRU one.

Week 2-4: May 21 - June 10

 * Develop the PRU firmware considering everything studied the week before.

Weeks 5-7: June 11 - July 1

 * Develop the device driver to expose the PRU to the kernel, following the standard APIs.

Week 8: July 2 - July 8

 * Make the DT overlay, and automate the whole process. (Script or Makefile to load the firmware, add the device to the DT and probe the device driver module)

Week 9-12: July 9 - August 5

 * Testing: Make code for a micro controller (STM32) to test all of PRU SPI’s functionalities.
 * Debugging.
 * Cleanup Documentation. (Documentation will be written in parallel to the other activities to make sure that nothing gets forgotten, aiming to develop clear and extensive documentation as this should be accessible to PRU beginners too).
 * Buffer time.

Experience and approach
I am an Electronics Engineering student and, as such, I have coded a lot in Matlab, C and a bit of assembler. During my internship at VanguardiaSur, I worked on developing a UART driver for the Sitara platform, which has improved my C skills considerably and taught me a lot about Linux, Git and tools like Buildroot. For my thesis I am working with OpenCV (C++), gathering new image feature detectors, descriptors and matchers and implementing them - the ones that are not yet - in OpenCV, to try to improve a SLAM algorithm (S-PTAM). You can check some of my code (a couple of tools to test the UART driver) in my github profile. Even though I have been introduced to Linux only a year ago, I have got hugely interested in its inner workings. In that sense, I contributed with some simple patches to mainline Linux with the objective to learn how the process works, I installed Linux From Scratch as a learning experience and explored the Device Tree and the I2C and SPI user APIs on a BeagleBone Black and an Olimex A20-Olinuxino-Micro, getting to read a temperature sensor through I2C and running a small TFT display through SPI. With the display functioning, I got to run 2 simple games: a Game of Life C/SDL implementation and SuperTux. The challenge for the first one was to add it to Buildroot and for the second one, get ALSA working, plus a USB keyboard for both. I really enjoyed these bring-up experiences (short videos of them working ). I also got interested in the PRU when developing the UART driver during my internship, as the client had some realtime constraints. I started studying it and, even though I got some PRU examples working through the remoteproc/RPMsg framework like toggling a GPIO, the project was not long enough for an actual implementation. For these reasons, I would be honored to work with the BeagleBoard organization and I will be really motivated to learn more through this initiative.

Approach
I am currently working on my final thesis so I do not have classes to attend, giving me the opportunity to manage my own schedule. I will have full-time, exclusive dedication to the GSoC during the 3 months that it lasts, working at least 40 hours per week.

Contingency
If I get stuck at some point in the project I will contact the organization administrator and mentors to talk about the issue and make sure the work is not delayed in the meantime by documenting and testing/debugging what has already been done. I also have a really nice relationship with my former employers, so, if really needed, I could ask them for pointers. The mailing lists and IRC channels are always a good place to ask for pointers too.

Benefit
The main objective of this project is to create a PRU soft-peripheral example that shows the PRU capabilities and also provides enough documentation to make similar projects accessible to the community.