BeagleBoard/GSoC/Port am335x-pru-package to remoteproc - GSOC 2018
- 1 Port am335x_pru_package to remoteproc
- 2 Status
- 3 Proposal
- 3.1 About me
- 3.2 About the project
- 3.2.1 Description
- 3.2.2 Implementation
- 3.2.3 Timeline
- 3.2.4 Experience and approach
- 3.2.5 Contingency
- 3.2.6 Benefit
Port am335x_pru_package to remoteproc
Student: Hernan Gonzalez
Mentors: Jason Kridner, Kumar Abhishek
The am335x_pru_package is a community supported set of tools and examples on using the PRU. It includes an assembler and a C library for managing the PRU over UIO. It would be preferred to use the remoteproc framework instead.
This project is currently just a proposal.
School: Facultad de Ciencias Exactas, Ingeniería y Agrimensura, UNR, Rosario
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 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: Port am335x_pru_package to remoteproc
The am335x_pru_package is a community supported set of tools and examples on using the PRU. It includes an assembler and a C library for managing the PRU over UIO. The BeagleBoard community mostly desires to migrate PRU development to remoteproc to give the Linux kernel greater knowledge of the cores.
Goal: Move all examples to remoteproc, including adding elf support to pasm, adding an option to build using clpru and updating the C library to use the remoteproc interface for basic PRU control and using mmap() for a limited set of communications functions.
The project can be divided into the following stages
- Study current am335x_pru_package
Get in-depth knowledge of the full package, with special emphasis on pasm.
- Update the C library to use remoteproc
Get the current C library to use the remoteproc/rpmsg framework, try to avoid using mmap() as much as possible.
- Port Examples
Port the examples to remoteproc/rpmsg. Other simple examples, like toggling a GPIO, could be added. This also includes adding the option to build with clpru.
- Elf support for pasm
Devote some time to study elf and the current pasm binary format, finally add support.
- Documentation & Debugging
This project aims to expose the pru to the kernel, which will lead to an increase of users. This set of examples and the library are a way to help new users to get a hold of the pru programming process so proper and clear documentation is fundamental.
Week 1: May 14 - May 20
- Study the current am335x_pru_package.
- Study the old UIO framework.
- Re-study the remoteproc and RPMsg frameworks.
Week 2-4: May 21 - June 10
- Get the current C library to use the remoteproc/rpmsg framework, try to avoid using mmap() as much as possible.
Weeks 5-7: June 11 - July 1
- Port the examples to remoteproc/rpmsg.
- Other simple examples, like toggling a GPIO, could be added.
Week 8-9: July 2 - July 15
- Study elf and current pasm binary format
- Add elf support for pasm.
Week 10-12: July 16 - August 5
- Testing and Debugging.
- Cleanup Documentation. (I plan to work on the documentation in parallel to the other activities to make sure that I am not forgetting anything 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.
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.
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.
The main objective is to give the Linux kernel more knowledge of the cores but it will also help the community to get a hang of the PRU programming, as most of the examples out there are outdated. It also facilitates the task of programming the PRU as it can be done completely in C, with no need to get into assembly. This will help most programmers who are not used with such low-level coding to get their hands on the PRUs.