Weekly Progress Report Thread: PRU User Space API

[pratim...@gmail.com]

Hi,

I am currently working on an updated PRU User Space API as my GSoC 2019 project, with mentors: Kumar Abhishek, ZeekHuge and Patryk Mężydło.

The introductory video for the project is available here:  https://www.youtube.com/watch?v=3Z2PxDIoCpE, I have also created a project progress website/blog here: https://pratimugale.github.io/. Looking forward to hearing suggestions from you. I will be using this thread to submit the weekly progress report about the project.

Regards,

Pratim Ugale.

[Pratim Ugale]

Hello,

 

This is the Week 1 Progress Report of the project.

Accomplishments:

- Created the API in C and added functions - libraries/cpruss.c in the repository.

- Project Repository: https://github.com/pratimugale/pruss-api

- Added the Blinky Program from PRU CookBook and tested with the API for both PRUs.

- Added Installation scripts and Documentation of current work.

- Made a script that will modify .bashrc for shortened terminal commands for starting and stopping the PRUs (There is an issue for restarting - will resolve it).

- Studied more about Makefiles.

Issues Resolved

- Makefile gave recipe for target 'start' failed error which the API functions check beforehand.

Current Blockers:

- No major blockers.

Plans for Next Week: 

- Study and implement RPMsg Functions.

- Add Documentation for usage of all functions in API.

- See the Debian distro packaging rules. 

Regards, 

Pratim Ugale.

[Pratim Ugale]

Hello,
 
This is the Week 2 Progress Report of the project.

Accomplishments:
- Got started with RPMsg, added its example, and documented how to run it - https://pratimugale.github.io/gsoc/2019/06/09/Blog1.html
- Modified previously written functions like `modprobe`, `rmmod` according to rpmsg.
- Added RPMsg functions (still developing, pull request has not yet been made to the master branch).

Issues Resolved:
- Was stuck while running RPMsg examples, found the problem and explained the detailed process on the blog site.

Current Blockers:
- No Blockers as of now.

Plans for Next Week:
- Complete the RPMsg functions make a userspace program for the example using the API library.
- Add more examples.
- Documentation of these functions.
- Study and implement the memory functions.

Regards,
Pratim Ugale.

[Pratim Ugale]

Hello,

This is the Week 3 status update of my project.

Detailed Blog Updates are here: https://pratimugale.github.io/gsoc/2019/06/16/Post3.html

Accomplishments:
- Added RPMsg functions and example in the old repository.
- Thought of examples to add in the project.
- Dug deeper in the working of linker command file and resource table
  Will be working in Muneeb Mohammed's fork repository now: https://github.com/pratimugale/PRUSS-Bindings
- Learned how swig works and generated files for the API.
- Sent the email that jkridner wanted to be sent.

Plans for next Week:
- Will discuss with mentors and post the plans ASAP.
- Couldn't add the memory read write functions last week, so will add these in the python daemon and modify the bindings.
- Currently Working on restructuring the C api to use the daemon.

Current Blockers:
- No blockers  

 
Regards,
Pratim Ugale.

I’m protected online with Avast Free Antivirus. Get it here — it’s free forever.

[Pratim Ugale]

Hello,

This is the Week 4 status update of my project.

Detailed Blog Updates are here: https://pratimugale.github.io/gsoc/2019/06/20/Post4.html

Accomplishments:
- Added C-bindings to the PRUSS-Bindings repo and made it use the daemon service: https://github.com/pratimugale/PRUSS-Bindings/pull/1; https://github.com/pratimugale/PRUSS-Bindings/pull/2

- Added the Read/Write functions to the PRU memory through /dev/mem: https://github.com/pratimugale/PRUSS-Bindings/pull/4; https://github.com/pratimugale/PRUSS-Bindings/pull/6
  Checked these functions by writing data to shared memory from PRU and reading that memory from the ARM side.  
- Was able to add a basic PWM example: working on making it multichannel, taking input from user space: https://github.com/pratimugale/PRUSS-Bindings/pull/5

Plans for next Week:
- Complete the multichannel PWM example also taking the input from user space.
- Add multithreading support in python daemon so that the the daemon can listen to other requests while waiting for a response from the PRU.

Current Blockers:
- Couldn't get the PRU-DMA project to start working.
- Whenever the PRU is running and memory is tried to be accessed from ARM (to change the inputs) , the PRU stops working and the pru_rproc module gets unprobed.
[ 4997.682918] pruss 4a300000.pruss: unconfigured system_events[63-0] = 0x00000000.000c0000
[ 4997.682940] pruss 4a300000.pruss: unconfigured host_intr = 0x0000000a
[ 4997.683016] remoteproc remoteproc2: stopped remote processor 4a338000.pru
[ 4997.724012] pru-rproc 4a338000.pru: pru_rproc_remove: removing rproc 4a338000.pru
[ 4997.730226] remoteproc remoteproc2: releasing 4a338000.pru
[ 4997.730482] pru-rproc 4a334000.pru: pru_rproc_remove: removing rproc 4a334000.pru
[ 4997.730881] remoteproc remoteproc1: releasing 4a334000.pru
[ 4997.742442] pruss 4a300000.pruss: remove PRU cores and other child platform devices

 
Regards,
Pratim Ugale.

[Pratim Ugale]

Hello,

This is the Week 5 status update of my project.

This was a bit unproductive week coding-wise as a lot of time was spent in debugging assembly code for accurate PWM frequency.

Accomplishments:

- Learnt .asm and wrote the PWM firmware code in assembly. 

- Tested the assembly code using the 'single-step' mode in /sys/kernel/debug/ : There is some overhead being added to the number of ON and OFF steps of the GPIO. This might be due to looping. Trying to remove the overhead further complicates the code. I have explained this in detail here: https://pratimugale.github.io/gsoc/2019/07/01/Post6.html. The GPIO is ON for 4 more steps and OFF for 3 more steps than required.  

Resolutions to Blockers  
- Solved the "prussd.service entered a failed state" error https://pastebin.com/mAZASD0t - It was a syntax error in prussd.py but the error message was a bit non-intuitive.

Plans for next Week: 

- Use RPMsg to transfer data to the PRUs instead of using /dev/mem.
- Complete the stepper motor and analog wave examples, if possible and try to make the PWM multichannel.

- Wasn't able to add multi-threading support as mentioned in last week's plan - will add this after I have completed some firmware examples.

Current Blockers:
- I still have to figure out how to use RPMsg to transfer data to the PRU. I am looking into Zeekhuge's BeagleScope to solve the errors I am facing while using RPMsg
 
Regards, 
Pratim Ugale.

[Pratim Ugale]

Hello,

This is the Week 6 status update of the project.

Daily updates are here: https://pratimugale.github.io/gsoc/2019/07/07/Post6.html

Accomplishments:

Modified the Daemon and cpp-bindings functions to write message to the buffer in raw form as well as string form through the rpmsg_pruX channel. - https://github.com/pratimugale/PRUSS-Bindings/pull/11/commits/cfb44d00e3c67aef050021b80b8d5f749b835ac7. Made seperate RPMsg firmwares also for storing data input in both forms into the PRU memory.

Documented the results of PWM that I was getting with single_step mode.

Modified the generalized Makefiles to make them specific for the examples.

Tested the working of the pwm example on a SERVO motor. Will add a demonstration video soon.

I have started working on other examples too but haven't uploaded the code yet as they are not complete. 

Checked the current state of the project on another Debian Image - removed small bugs.  

Resolutions to Blockers 

- Studied RPMsg and was able to use it to write to the PRU memory. I have a much better understanding of it now. 

- I wasn't able to figure out how to make the PWM multichannel; after talking to the mentors, the process has become much clear and I think I should complete it within the next couple of days.

Plans for next Week: 

- Complete the mentioned examples(waveform generation, stepper motor, multi-channel pwm), their Documentation and make Demonstration Videos for them.

- Figure out how to send if possible, more than 512 bytes without splitting the data into multiple RPMsgs.

Current Blockers:

- The stepper motor and driver have not arrived yet - it is expected to arrive by today evening.

 

Regards, 

Pratim Ugale.

[Pratim Ugale]

Hello,

This is the Week 7 status update of the project.

Daily updates are here: https://pratimugale.github.io/gsoc/2019/07/15/Post7.html

Accomplishments:

Got the stepper motor and driver to work, and wrote a library for controlling it using the pruss.cpp API. Right now I'm using usleep() so that multiple commands to the stepper motor don't overlap. - https://github.com/pratimugale/PRUSS-Bindings/commit/25aed50b9f12c602b5d21cff8e81cbc0c79622d4

Was able to create a 4-channel pwm example using assembly. - https://github.com/pratimugale/PRUSS-Bindings/tree/master/examples/firmware_examples/example5-multichannel-pwm The DC of the GPIOs need to be in ascending order. 

Resolutions to Blockers 

- The stepper motor and driver arrived and are working.

Plans for next Week: 

- Currently I am working on completing the stepper motor control, which involves writing a library (driver_lib.cpp) which in turn will use the pruss.cpp cpp-bindings. I have to add GPIO control to the library for functions such as direction, microstepping and sleep. The PRU firmware written by me earlier needs to be modified so that it sends out a message once the assembly code has completed executing, so that the Linux side knows that the motor is done rotating, and can send out the next command to the PRU.

- Waveform generation code needs to be completed.

- Will discuss with mentors what is to be done after the stepper motor example. 

Current Blockers:-

- Learning how to pass interrupts from PRU0 to PRU1. The example in TI's software support package is no longer supported. This is what I'm working on right now.

 

Regards, 

Pratim Ugale.

[Pratim Ugale]

Hello,

This is the Week 8 status update of the project.

Accomplishments:

- Completed code for accurately controlling stepper motors using the PRU API: https://github.com/pratimugale/PRUSS-Bindings/tree/master/examples/firmware_examples/example7-stepper-control. Demonstration Video: https://www.youtube.com/watch?v=W-Kr37lqM98. The video mainly demonstrates: 1. Correctness of RPM i.e. frequency of pulses being sent; 2. Calculations of degrees to rotate and RPM for different step modes made in driver_lib.cpp and sending appropriate values to the PRU.

- Created a simple example to demonstrate calling and linking multiple .asm files using "extern" keywords from the C-program and return back using R3.w2 https://github.com/pratimugale/PRUSS-Bindings/tree/master/examples/firmware_examples/example8-multiple-assembly-calls

- Completed single channel waveform generation with adjustable time period by sending wave sample values as raw integers individually: https://github.com/pratimugale/PRUSS-Bindings/tree/master/examples/firmware_examples/example4-analog-wave-gen. Video: https://www.youtube.com/watch?v=3A2SspbW3k8 - Has 1s time period.

- Tried adding another channel to the waveform generation example but it requires some more work. Need to recheck the flow of the code.

Resolutions to Blockers 

- Learnt and properly configured interrupts for the stepper motor example; Host 1 being for RPMsg and Host 0 for PRU0 to PRU1 interrupt.

Plans for next Week: 

- Add channels to the waveform example.

- Figure out if all samples of the wave can be sent to the PRU in one go.

- Have to discuss with mentors how to proceed next. 

Current Blockers:-

- Don't know how to pass large amount of raw integers to the PRU in a single 'kick' and if it is to be done in this way. Also whether the (512-16 =) 496 byte rpmsg buffer length can be exceeded.

- How to proceed after the waveform example - will discuss with mentors today.

Workflow of stepper motor: PRU1 takes input values and PRU0 sends out pulses accordingly, after which it interrupts back PRU1. PRU1 then sends back a message to the ARM saying it's "done" with the command, after which the next command is to be sent.

Regards, 

Pratim Ugale

[Pratim Ugale]

Hello,

This is the Week 9 status update of the project.

Accomplishments:-

- Designed and Implemented assembly code for 2-channels, 4-channels and 8-channels for waveform generation. https://github.com/pratimugale/PRUSS-Bindings/tree/master/examples/firmware_examples/example9-multichannel-waveform-gen Couldn't add a video because I don't have 8 resistors of the same value. Will do it asap.

All 8 channels can have different frequency/time period and phase difference. 

- Understood today that all waves must pass the same number of samples even if they have different frequencies, otherwise a phase difference will be produced in between them due to the way the .asm code is written.

- Got a further understanding of the error and how it is affecting the example. (In blockers)

Resolutions to Blockers:-

- It was recommended that integers could be passed in different kicks as well instead of accumulation on the ARM.

Current Blockers:-

- When BB boots for the first time and the example9 Makefile is run, the kernel throws some messages: https://pastebin.com/24gXsKni after prussd.py writes around 15 values to the rpmsg channel  https://gist.github.com/pratimugale/9820cf72065f4f0a01e01295c4459b57#file-dmesg_example9-txt-L369. After the first time, the Makefile runs without any issues and messages in dmesg.

Plans for next Week:-

- Try to implement a dedicated kernel driver with a relevant key like "pruss-api" instead of "rpmsg-pru30/31" 

- Look into Debian Packaging methods.

Regards, 

Pratim Ugale

[Pratim Ugale]

Hello all,

This is the Week 10 status update of the project.

Work done:

- Started working on the Documentation starting with adding Travis CI. I don't know how to integrate it with rcn-ee's package distribution.

- Studied about the rpmsg drivers and started trying to implement the dedicated rpmsg driver by using the `rpmsg_client_sample.c` as a reference.

- Installed and studied how 'prudebug' works so that it can be integrated with this project.

- Removed a small bug that wrote only integers to the rpmsg channels: https://github.com/pratimugale/PRUSS-Bindings/issues/14

Timeline for next weeks:

- This Week:

  - Complete the implementation of the driver, 

  - Discuss with mentors how to submit the work done by me for the final evaluation.

  - Any other work left in Documentation for ex. adding CI tests for `clpru` for firmware as well.

- Next Week: 

  - Integrate `prudebug` with this project.

  - Do the debian packaging.

Current Blockers:

- Have been down with viral fever since Saturday. It slowed me down but I'm feeling much better now and am working at my full capacity again.

Resolutions to Blockers:

- Still solving the kernel oops error. I'm getting a better understanding about the error as it is related to the rpmsg_pru driver.

Regards,

Pratim Ugale.

[Pratim Ugale]

Hello,

This is the Week 11 status update of the project.

Accomplishments:

- Implemented the 'pruss_api' loadable kernel module that creates a device file with the name 'pruss_api_pruN' : https://github.com/pratimugale/PRUSS-Bindings/tree/pruss-api-driver/drivers

  Made changes in prussd.py and the previous examples to use this device file now instead of rpmsg_pru31.

Plan for next Week:

1. Complete the Documentation and the Wiki page.

2. Do the Debian Packaging.

3. Solve the kernel oops problem.

4. Integrate 'prudebug', if possible.

Current Blockers:

- Not a 'block'er, but I went through the debian packaging documentation, and creating the package is somewhat complicated, as I didn't understand how to modify all the configuration files in the /debian directory, in particular how the installation process takes place. Will go through it again.

Resolutions to Blockers:

- I studied how to understand the kernel oops message, and am trying to learn and use kgdb to pin point where the NULL pointer dereference happens. 

Regards,

Pratim Ugale.

[Pratim Ugale]

Here is the description of kernel oops that occurs:

The problem occurs when rpmsg is used for the first time after booting the BBB. Either the oops error message shows up, or the first 14/15 values to be passed through rpmsg_pru31 aren't received on the PRU firmware side.

Oops Mesage, dmesg logs: https://gist.github.com/pratimugale/3cb56d8f3b611e96d92c444f10c49d70

PRU SRAM values: https://gist.github.com/pratimugale/cc8385e32eb77d582939441ce4100ec8 (This shows the data that was passed through the rpmsg_pru31 channel when the errors occurs, and the actual data that should have been received by the PRU)

Code: https://github.com/pratimugale/PRUSS-Bindings/tree/sandbox/examples/firmware_examples/example9-multichannel-waveform-gen : PRU1/ contains the rpmsg firmware code.

The error can be reproduced by rmmod'ing the rpmsg_pru driver/rebooting the BBB before starting the PRU rpmsg firmware again. 

However, after the first time (keeping rpmsg_pru probed), all the data is passed through the rpmsg_pru31 channel and written to the PRU SRAM perfectly.

Kernel version: Linux version 4.14.71-ti-r80 (root@b2-am57xx-beagle-x15-2gb) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP PREEMPT Fri Oct 5 23:50:11 UTC 2018

[Pratim Ugale]

Hello,

This is the Week 12 status update of the project.

Accomplishments:- 

- Created a debian package for the project: 

- Documented the project and added uml diagram on the GitHub Wiki page: https://github.com/pratimugale/PRUSS-Bindings/wiki

- Reorganized and cleaned the code: https://github.com/pratimugale/PRUSS-Bindings/pull/30 

- Tested all the firmware examples again and made them use the pruss_api driver.

- Tested and removed bugs present in cpp-bindings and prussd.py which prevented the load() and showRegs() functions from working properly: https://github.com/pratimugale/PRUSS-Bindings/pull/31.  

Currently I am testing the debian package on another debian image to check the installation. There are some small changes to be done after which I will release the project on GitHub.

Plan for next Week:

1. Solve the kernel oops problem.

2. Add inline documentation comments to the main code.

3. Make a release of the project on Github.

4. Integrate 'prudebug', if possible.

Current Blockers:

- No major blockers except for the kernel oops.

Resolutions to Blockers:

- I have got a USB-UART converter as suggested by Abhishek_ to debug the kernel NULL pointer dereference and am looking into how to use it for debugging.

Also, I had mailed Prof. Mark Yoder before informing about the project and to discuss it, but haven't received a reply from him yet.

Regards,

Pratim Ugale.

[Pratim Ugale]

Hello, 

This is the Week 13 status update of the project.

Accomplishments:

- Made a release on GitHub that contains the .deb package: https://github.com/pratimugale/PRUSS-Bindings/releases

- Added inline documentation comments for the API

- The prevention of the kernel oops is done in user-space by waiting until the rpmsg device file is created in /dev: https://github.com/pratimugale/PRUSS-Bindings/commit/bc4ba9070c68a3c3d686c8d28a3f07b83f656d99

- Made the final evaluation for GSoC

Resolutions to Blockers:

- No data loss takes place now and oops message is not thrown whenever rpmsg_pru hasn't probed before running the userspace.c program.

I tried debugging using gdb by compiling the kernel with `CONFIG_DEBUG_INFO`, on doing so, only the rpmsg_pru.ko file wouldn't be generated. This is where there is a null pointer dereference according to oops. All the other .ko files - rpmsg_core.ko, virtio_rpmsg_bus.ko would be generated with debug symbols for gdb. The rpmsg_pru.ko file is generated if the `CONFIG_DEBUG_INFO` is set to NO.

Kernel source I used was for 4.14.71-ti-r80(my BBB version)

Blockers:

- There are no more blockers remaining in the project.

Plans for next Week:

- Host the documentation of the API on GitHub pages.

Regards,

Pratim Ugale.