Beaglebone PRU DMA - Weekly report thread

Hi,

This is the first report for Beaglebone PRU DMA project. More
information regarding the project can be found on the wiki page [1].

This week I was focusing on setting up DMA transfers from kernel module
and interrupt communication between PRU and ARM. For this purpose I
created two modules, one for DMA transfers one for PRU<->A8
communication. I was able to set up DMA channels and test it, and
trigger interrupt from PRU and observe it in the driver.

This week I plan to actually transfer something from linux to PRU, and
work on synchronication between these two.

Roadblocks:

(slight annoyance) I encountered a problem with ethernet dongle i
planned to use for development (PC-BBB communication), but am able to
work on BBB using serial cable. Ordered replacement ethernet dongle,
will upload code to github when it arrives.

[1] http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA

Hi!

Week 2 report

This week I managed to configure DMA transfer to write from A8 to PRU memory
and read back the content on the PRU side.

In following week I want to enable both way DMA transfers and create one
kernel module that will combine interrupt synchronization with DMA.

Week 3 report

This week I continued working on DMA transfers from kernel module,
I am also trying to control DMA transfers from PRU side (without success yet).

By the end of week 4 I want to have working PoC of PRU application +
kernel module with interrupt communication and working DMA transfers.

Week 4 report

This week I managed to trigger DMA transfers from PRU, currently working on passing
all transfer parameters and kernel side buffer from the module to be used on PRU side
to coordinate the transfer and notifty the module on completion.

Week 5 report

This week I worked on communication using rpmsg framework,
I am now able to pass DMA transfer configuration from kernel to PRU via
rpmsg messages and shedule requested transfer on PRU. I also added
transfer parameters to devicetree so transfer parameters can be
configured via dt overlay.

This week I will be trying to do speed measurements of the transfers,
and start preparing some examples.

Week 6 report

Past week, with DMA transfers on PRU and PRU<->kernel module communication
working, I started designing an API for users of the pru-dma interface. First I
refactored the PRU firmware and modified the firmware to form a library that
can be linked to a PRU aplication which can then use provided interface.
Interface is visiblie in firmware/include/pru_dma.h file and as of writing 3
functions are implemented, for initializing EDMA and filling transfer
parameters, for triggering hw to perform the transfer and for blocking until
the transfer is complete. I added place for example applications and created
1st one that I was using earlier for the test but with refactor I moved it to
separate location and linked with the pru_dma lib. It waits for data from
kernel buffer and pushes them to PRU1 GPO (where LEDs are connected). The PRU
API is not yet final but is the basic minimum to operate, will be extended with
new functionality. I also added Travis builds for the project.

Currently I am refactoring the pru_dma kernel module for reusability, so it
does not actually do anything but only provides way for other modules to be
used on top of it with specific purpose. I will add driver for the LED example
first to demonstrate usage. This week I will be creating more examples and
extending the API with needed functionality.

Week 7 Report

Main progress this week in the kernel driver, now it enables other drivers
to plug to it by including appropriate header and use exported functions
for controlling dma transfers. I also added example driver using new functionality
in examples which works with LED example for PRU. I encountered some problems
on the way with creating dependencies between kernel modules but by modyfing
Makefiles I was able to resolve it. Currently I am working on further examples,
and also on moving PRU side configuration to resource table which is linked
to PRU firmware. I also want to enable more then one DMA buffer to be handled
by driver/firmware (currently only 1 is supported).

Week 8 Report

This week I made improvements and bug fixes in kernel driver and firmware,
now it is working fine enabling both direction transfers. I created new example
application consisting of HCSR04 sensor connected to PRU pins from which PRU collects
data to buffer and when it is filled, transfers them to kernel buffer. I am still working on example
applications, I want to create application using double buffering for data transfer. Next week
I will also start creating documentation for the project to make it more accessible for users.

Week 10 Report

I apologize for lack of report last week, had a lot on my head and it slipped my mind.

What has been done: I extended the PRU DMA configuration with new
parameter describing whether after completing DMA transfer kernel module
should be notified,becasue this may be needed or not, depending on application.
On kernel side, I added waiting functions which are based on the linux completion
mechanism. So driver using PRU dma can block on DMA transfer on PRU by using
wait_for_completion function from linux. Examples were updated accordingly.
I am also creating documentation for the project which will describe all interfaces
for potental user and steps needed to build and set up the project.

Week 11 report

I modified method of PRU DMA configuration to use entries in firmware
resource table instead of using rpmsg to provide the parameters to PRU.
This requried refactor of pru_dma driver and modifications to kernel drivers
for remoteproc. Remoteproc allows custom resouces specific to given
processor, so I added new custom resource type for describing the DMA buffers.
While parsing this resource, buffers are allocated and mapped to DMA address,
which is passed back to the resource table, allowing PRU to use it.
Project documentation is still in progress, as the code was not yet finished.
I will be mostly working on documentation, cleaning up the code and providing
more examples in the remaining time.

Week 12 report

I modified PRU firmware part to reflect changes made to kernel part
regarding configuring DMA transfers via resource table. It required modyfing
headers in PRU Software package, for which I added patch to project repository.
I also moved on with project documentation which I plan to finnish in the next 2 days.
If I still have time I will add one more example to the project.