Difference between revisions of "BeagleBoard/GSoC/BeagleBone PRU DMA"
m (Update article categories) |
(→Implementation of the project: Add diagram) |
||
| Line 103: | Line 103: | ||
# Measure speed of provided interface | # Measure speed of provided interface | ||
# Create documentation for both PRU and kernel parts of the project | # Create documentation for both PRU and kernel parts of the project | ||
| + | |||
| + | =====Communication Proposal===== | ||
| + | |||
| + | This is how communication between Hardware and Software parts of the project could look like: | ||
| + | |||
| + | [[File:Pru dma diagram.png|900px|frameless|center|Communication proposal]] | ||
===Timeline=== | ===Timeline=== | ||
Revision as of 16:58, 22 March 2017
Contents
BeagleBone PRU DMA
Most of existing PRU applications utilize (waste) one PRU core for data transfer. The goal of this project is to enable usage of EDMA controller for copying of data to and from main memory (DDR), which would allow applications to use both cores for computation.
Student: Maciej Sobkowski
Mentors: Hunyue Yau
Code: https://github.com/maciejjo
Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA_-_Maciej_Sobkowski
GSoC: GSoC entry
Status
This project is currently just a proposal.
About you
IRC: maciejjo
Github: maciejjo
School: Poznań University of Technology
Country: Poland
Primary language English
Typical work hours 8AM-5PM CEST/UTC+2
About your project
Project name: BeagleBone PRU DMA transfer support
Description
BeagleBone's SoC, TI Sitara AM3358, contains (besides main ARM Cortex-A core) two additional processing units called PRU (Programmable Realtime Unit). These cores' main purpose is running code subject to a real-time constraint. Such approach lets the user run a non-realtime operating system on the main ARM core and offload parts of application which require realtime capabilities to PRU cores.
Current PRU applications requiring data exchange with Linux (i.e. Cortex-A8) dedicate one PRU core for this task, leaving only one for actual application purposes. This project aims to use AM3358's built-in DMA controller to handle data transfers between PRU memory and system DRAM, effectivly freeing the second core to be used for other purposes.
PRU
PRU and related peripherals form PRU-ICSS - Industrial Communication Subsystem (also called PRUSSv2 becasue it replaced older PRU subsystem revision called PRUSS). It consists of two 32-bit RISC cores (PRUs), shared data and instruction memories, internal peripherals and interrupt controller. Details of PRU-ICSS can be found on the block diagram.
Features of PRU-ICSS:
- 2 PRU cores, each featuring:
- 200MHz clock
- 8KB program memory, parity detection
- 8KB data memory, parity detection
- OCP Master port
- GPIO
- Scratchpad shared memory (SPAD)
- 12KB shared RAM
- Interrupt controller (INTC)
- UART
In Linux kernel there are two mutually exclusive ways to use PRU. One is older uio_pruss driver based on UIO framework, and the other is newer set of drivers (pru_rproc and rpmsg_pru) which make use of newer remoteproc (for controlling the processor) and rpmsg (for exchanging messages between Linux and processor) frameworks.
DMA - EDMA controller
EDMA is general purpose DMA controller inegrated in AM335x SoC. It supports up to 64 DMA channels. It consists of two main blocks: channel controller (TPCC), and three transfer controllers (TPTC). Channel controller is the programmer inteface to EDMA. It prioritizes transfer requests and events from peripherals, and schedules tranfser requests to tranfser controllers. EDMA is supported in mainline Linux kernel by a standard dmaengine framework driver.
DMAengine API
Linux provides an uniform API for device drivers that want to make use of DMA transfers. It is called dmaengine and EDMA controller driver provides support to make use of this interface.
Implementation of the project
Main Goals
- Create Linux driver capable of communication with PRU with rpmsg framework
- Write PRU application communicating with the module
- Develop support for DMA transfers using DMAEngine client API
- Extend PRU application to use DMA transfers
- Add support for Device Tree configuration of DMA channels for the driver
- Provide example PRU applications making use of created DMA capabilities
- Measure speed of provided interface
- Create documentation for both PRU and kernel parts of the project
Communication Proposal
This is how communication between Hardware and Software parts of the project could look like:
Timeline
TBD
2017-06-06: Milestone #1
2017-06-13: Milestone #2
2017-06-20: Milestone #3
2017-06-27: Milestone #4
2017-07-04: Milestone #5
2017-07-11: Milestone #6
2017-07-18: Milestone #7
2017-07-25: Milestone #8
2017-08-01: Milestone #9
2017-08-08: Milestone #10
2017-08-15: Milestone #11
Experience and approach
I have previous experience with BeagleBone and other embedded HW. I know Linux kernel internals and have wirtten several modules for various purposes (e.g. SPI and I2C slave devices, SPI master driver). I am able to quickly grasp new concepts.
Contingency
In case of problems I will be consulting AM335x TRM, PRU-ICSS reference guide, and Linux documentation. I will check for solutions and examples in existing kernel code. If I need help, I will try to find it on BeagleBone IRC and ML. I am able to describe my problems in detail and ask specific questions.
Benefit
This project will bring a big benefit to BeagleBoard community (and possibly users of other hardware featuring PRU) as it will enable PRU users to design applications using both PRU cores in cases where one was effectively wasted on copying data back and forth to memory. If some cases this could mean double speed or I/O pins for those applications.
