Project: Add PRU drivers to RTEMS
Student: Nils Hölscher
Mentors: Chris Johns, Amaan Cheval, Kuan-Hsun Chen, Sarvesh Patkar
This project added PRU support to RTEMS, using the Beaglebone Black (BBB). The BBB has a Texas Instruments AM3358 SoC with a Programmable Real-Time Unit (PRU). The PRU is able to connect to the SoCs i/o within one cycle. This should enable the RTEMS community to develop heavily i/o dependent tasks on the Texas Instruments SoCs with PRUs.
However currently only tested on the BBB, with its PRUSS-v2.
The project goals were to to port the Linux UIO drivers to RTEMS. However this changed after I found out that I missed a part of the Linux driver in my project proposal. I missed the “actual” UIO driver in Linux and started porting just the library for accessing this driver. After realising this I looked into Linux UIO drivers and realized porting them would not be easy. So we redefined the goal to porting the FreeBSD driver, as this would be easier to integrate into RTEMS and these drivers are also more feature rich. My mentors and me also agreed on having a RTEMS-Shell command for accessing the PRU during development would be nice, so we also added this to the goals.
- RTEMS-App for testing and developing the SHELL command.
- The SHELL command I wrote, link.c, link.h.Why not a link to the root folder?
- Source and binaries of my PRU examples, link.
- Short test to run the loop example, link.
- Short test to run the irq example from FreeBSD, link.
- Files needed to get working SD image, link
- To recreate my results please see the README.md.
- RTEMS-libbsd Fork containing the ported PRU drivers.
- Import PRU driver from FreeBSD, link.
- Port PRU driver to RTEMS, link
- Patch to RTEMS-libbsd fixing issues with the bus init process.
- PRU test apps:
- Loop example running exactly 10s.
- Device tree files:
- Device Tree Overlay for PRUSS from TI.
- Rtems-libbsd init output:
- Important output I used to debug libbsd init.
- RTEMS Documentation for libsd init process:
- Documentation for libbsd init. (Currently no libbsd chapter in RTEMS Doc.)
This section will describe each Phase of my neat GSoC project. Most of the information is taken from our weekly GSoC meetings at RTEMS-IRC with the GSoC’ers and some mentors. The short summaries of our meeting can be found here.
Phase I [May 27 – June 28]
During this phase my time was very compromised, because in Germany semester has just started. And I also wasted quite some time with the aforementioned misconceptions.
- The Project started with coding some test applications for the PRU and to run them via Linux. This was necessary to ensure that the applications behave the same way on RTEMS later on.
- I spend a lot time with trying to route PRU access to the GPIO pins of the BBB via device tree overlays. Later I realised that Linux uses a management software that resets all device tree definitions after boot and decided to go on with the project, since this software is not part of RTEMS.
- After finishing running my sample code on Linux it was time to move on to RTEMS and build a running SD-Card. At this point I had to figure out the boot process with U-Boot, RTEMS and device tree overlays.
- Figuring out the right device tree and its overlay took some time and help. So I started writing the SHELL command whilst waiting for answers concerning device tree.
- In the las week during this phase I got everything to boot and was able to test the Linux “drivers” without success.
Phase II [June 29 – July 26]
In this phase I realized my misconceptions and my focus changed to the FreeBSD drivers for RTEMS.
- Because my Linux “drivers” weren’t working I spent the first week enabling debugging via Network. Luckily my mentor Chris Johns was just working on this so I didn’t need to get a JTAG controller.
- Also I had to reassess my device tree again, because the one from Linux, I was using, caused trouble. In the end I changed over to FreeBSDs device tree.
- After I realized that the /dev/uio devices were missing under RTEMs, it was obvious that I missed some part of the PRU driver in my proposal. Following this I had to discuss with the community and it was decided that I would go with the FreeBSD drivers. This rendered parts of my work useless. ):
- Now that everything was decided I ported the FreeBSD drivers to RTEMS-libbsd.
- When testing the ported drivers I encountered the projects biggest blocker. The PRU driver needed a driver, that was able to set the PRU clock. But that driver always initialised after the PRU driver and so it could not attach itself to the system.
Phase III [July 27 – August 26]
- The blocker kept me busy for nearly three weeks. And because my debugging solution depended on the RTEMS-libbsd networking modules I wasn’t able to debug this whole process of interest. So I had to read into the whole FreeBSD init process and investigate the differences to RTEMS-libbsd. During this work I wrote down what I learned about the init process and had my program print everything during initialization.
- I wrote a Blog entry about the whole process and a few paragraphs for the rtems Documentation project.
- When I found the solution to this problem, it got merged into RTEMS-libbsd pretty fast.
- In the last two week I ported my SHELL-command, now using the FreeBSd driver and tested all I could during the time I was left with.
- I successfully tested my loop example running for exactly 10 second.
- Please see Future Work for what still needs to be done.
I had a nice time during GSoC and the community was very friendly and helpful.
During my time working, I learned a lot of things, for example I have never heard of device trees before and also learned my share about the FreeBSD init process.
But for me the greatest feat is to have openly communicated with an open source community, taking away the fear to do so in the future.
If I would do the same project again I would take more time preparing my initial proposal. Also I would directly start communicating on the mailing list and not just with my mentors, as this will generate more input by having a wider audience. Also when starting GSoC the whole community should be seen as mentors.
I still wasn’t able to read IRQ’s triggered by the PRU (see here). However this doesn’t seem to be related to the driver but to some issue with the app I use for testing. When this is resolved I still need to see my drivers merged and add Documentation.
After resolving this and having my code merged I think it might be nice to build something using pru and maybe propose to my university staff to teach with RTEMS in their courses. I would call myself a part of the RTEMS community and see what the future brings.