maciejjo / beaglebone-pru-dma

Beaglebone PRU DMA support

Beaglebone PRU DMA support

This project aims to provide support for bidirectional DMA transfers between PRU and Cortex-A8 on AM335x SoC. It is developed on BeagleBone Black.

I am developing this project for GSoC 2017 for beagleboard.org.

Task description

Goal: Create a sample program to demonstrate using EDMA on the PRU to transfer data to and from the main (DDR) memory with a Linux host. Most existing code utilizes (wastes) the 2nd PRU on the PRUSS for data xfer. Using DMA can allow the PRU to be used for other purposes.

Software requirements

This application was developed and tested using following SW revisions:

• BBB:
  • Beagleboard.org Debian, version 8.8
  • linux: 4.9.30-ti-r38
• Host:
  • toolchain: arm-linux-gnueabihf gcc linaro 6.3.1-2017.05
  • dtc: 1.4.4
  • PRU CGT: 2.1.5
  • PRU Software Support Package: v5.1.0

To work properly, PRU remoteproc must be enabled in device tree.

Implementation overview

Implementation of the project is split in two main parts, kernel module and PRU firmware. PRU firmware and kernel module communicate via interrupts.

Following scenario is implemented:

• During loading procedure of PRU firmware, driver performs buffer allocation (using kzalloc call) to obtain contiguous buffer in memory based on requirements specified in PRU DMA entry in resource table,
• Buffer is then mapped using dma_map_single call to ensure the address is in DMA able region and caching is turned off for the buffer,
• Resource table is modified to include address of the mapped buffer,
• After boot, PRU configures EDMA based on parameters passed in resource table (buffer address and size, EDMA channel, PaRAM slot)
• PRU schedules the transfer by writing to EDMA registers,
• PRU polls periodically for the transfer completion event,
• Once the transfer is complete, interrupt is optionally sent to the driver (configurable via option in resource table entry)
• In interrupt routine driver signals finished transfer using Linux completion mechanism

Project structure

• firmware - code for PRU software. Receives transfer parameters via resource table, configures EDMA for transfer and INTC to trigger event on EDMA interrupt

• kernel-patch - kernel-side implementation of the project, contains patches to ti-linux-kernel-dev repository (based on 4.9.36-ti-r46 release)

• pru-swpkg-patch - contains patch that needs to be applied to pru software support package (based on v5.1.0 release)

• dts - basic device tree overlay needed to load the module. More concrete dt overlays exist for each example

• examples - every subdirectory is an example usage of pru-dma, demonstrating practical application, consisting of PRU firmware, kernel module and dt overlay

• Documentation - contains detailed description of the project, build instructions and description of API for PRU firmware and kernel modules

• wip - (work in progress) isolated examples created to test specific features (e.g. linux DMA API, PRU-ARM communication), not an essential part of the project.

Demonstration video

beaglebone-pru-dma's Issues

What do you mean by resource table?

Hi what do you guys mean by resource table? Is it the device tree to pick the address of the source of data?

Also, how to correctly write a device tree?

Change PRU Firmware Library to a Permissive License?

Would it be possible to change the licensing on the PRU firmware library portion of the project to a more permissive license? Specifically any PRU application firmware which uses this library would be required to adopt the GPL for the entire PRU application. Unfortunately this is not an option for many applications, such as is the case with my code. The project and the work you've done are useful and I would like to help extend it and build on it, but I am not at liberty to GPL our entire PRU firmware code base. At the least this could require me re-writing the PRU portion of the library, though the kernel portions are helpful. :-)

I propose adopting an MIT/BSD License, MPL 2.0, or LGPL license for the PRU firmware library potion of the code if the GSoC/BeagleBone commitments allow it. The BSD license seems similar to the TI license of the base PRU libraries, the MPL provides for a file-level copyleft, and the LGPL is trickiest since it requires providing the ability to re-link a static binary.

Error in patch to 4.9.78-ti-r94

Tryed to patch kernel dev (version 4.9.78-ti-r94) with 0001-Add-pru-dma-patches.patch and catch the next error:
error: patch failed: patch.sh:566
error: patch.sh: patch does not apply
Patch failed at 0001 Add pru-dma patches
Are there any more versions of patches for older kernel's or maybe something else to solve this?
(Or, maybe, the easiest way is to downgrade kernel?)

Using the EDMA for data transfers to/from the PRU Memories

Hi,
I've been working on using the EDMA for memory transfer to/from the PRU memories using the slave-DMA API of the DMA Engine as you have done here
The DMA transfer doesn't work when I try to run this module. It gets timed out at dma_sync_wait(). Apart from the obvious modification to pruss_get(), I couldn't find any other fault with the code. Was this working for you, when you tried it? It would be great if you could help me debug this.
uname -r - 4.9.36-ti-r45
/boot/uEnv.txt - dtb_overlay=/lib/firmware/pru-dma-test-00A0.dtbo
Log:

[    1.656951] edma 49000000.edma: TI EDMA DMA engine driver
[  543.116361] pru_dma_test: loading out-of-tree module taints kernel.
[  543.124268] pru_dma_test pru-dma-test: Start probe
[  543.124311] pru_dma_test pru-dma-test: Configure dma xfer
[  543.124355] pru_dma_test pru-dma-test: Map src buf
[  543.124373] pru_dma_test pru-dma-test: Perform transfer from 0x9a110590 to 0x4a300000
[  543.124391] pru_dma_test pru-dma-test: Submit xfer to pending queue
[  543.124402] pru_dma_test pru-dma-test: Issue pending transfer
[  548.143618] edma 49000000.edma: dma_sync_wait: timeout!
[  548.148935] pru_dma_test pru-dma-test: Probe complete

PRU DMA Driver probe fails

After compiling the kernel with the DMA patches and installing the debian package, I get the following error on bootup

[   27.109034] ti-pruss 4a300000.pruss: creating PRU cores and other child platform devices
[   27.109159] irq: no irq domain found for /ocp/pruss_soc_bus@4a326000/pruss@4a300000/intc@4a320000 !
[   27.192919] pru_dma 4a300000.pruss:pru_dma: Unable to get PRUSS RAM.
[   27.201309] remoteproc remoteproc1: 4a334000.pru0 is available
[   27.201427] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a334000 probed successfully
[   27.202841] remoteproc remoteproc2: 4a338000.pru1 is available
[   27.202949] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a338000 probed successfully
[   27.212016] pru_dma: probe of 4a300000.pruss:pru_dma failed with error -16

It looks like the DMA driver is probed just before the remoteproc driver probe and it is unable to get the PRU memory regions. Any idea how to fix this?
The kernel version I'm using is 4.9.36-ti-r45.
uEnv.txt - uboot_overlay_addr0 = /lib/firmware/pru-dma-00A0