Google Summer of Code

The BeagleBoard.org community has been a mentoring organization in Google Summer of code for 9 years now. This will be the first year students will have the opportunity to propose RISC-V projects!

Also, with PRU support now uptream in GCC, doing low-latency projects on BeagleBone might be especially fun. Also, having the C66x DSP (also supported by GCC) in BeagleBone AI is another chance for some heterogenous processing fun.

Visit beagleboard.org/gsoc to learn more and please help with the ideas page on the eLinux wiki.

Jason (or anyone else), what would you recommend to a person just getting started programming the C66x DSP cores on the BeagleBone AI board for this summer of code? If you recall I use the BBX-15 in my mechatronics class at the University of Illinois and program the C66x DSP cores both with JTAG and I have written my own Linux program running on the A15 cores to load and run code on the C66x cores given a Hex file compiled by CCS 10. This DSP Load program works great in the release of Linux that I am running on the A15 cores but I am afraid that as I upgrade to newer releases of Linux my solution may break. I would like to figure out remoteproc. I have been monitoring the beagleboard and TI forums and I have not come across a simple example that programs the C66x cores to just toggle an LED or something like that. A simple example like that would help me understand how to use remoteproc to load and run programs on the DSP cores. Or if the idea is to stick with OpenCL, from what I have been able to gather, a default starter program is loaded to both DSP cores on boot. Then when you run your Linux app you are able to run code on the DSP cores somehow using OpenCL. Again a simple example here blinking an LED would be super helpful, and even better if the LED was being blinked inside a SYS/BIOS Clock object.
What are your thoughts?

Dan

I would love to see a simple “echo” rpmsg example for C66 cores using GCC toolchain.That would allow interesting experiments without any proprietary bits.

I tried and failed to get a simple C66 ELF from c6x-gcc to be loaded by remoteproc. I then saw mentions of setting up IOMMU in the linux remoteproc driver and gave up :slight_smile:

Regards,
Dimitar

Jason (or anyone else), what would you recommend to a person just getting started programming the C66x DSP cores on the BeagleBone AI board for this summer of code?

Well, looking at how the PRU stuff works could be a great way to getting into the C66x stuff. I think we ship with the TI toolchain. A couple of the remoteproc endpoints are for the C66x DSPs. Look at the cloud9-examples PRU code and Makefile.

If you recall I use the BBX-15 in my mechatronics class at the University of Illinois and program the C66x DSP cores both with JTAG and I have written my own Linux program running on the A15 cores to load and run code on the C66x cores given a Hex file compiled by CCS 10. This DSP Load program works great in the release of Linux that I am running on the A15 cores but I am afraid that as I upgrade to newer releases of Linux my solution may break. I would like to figure out remoteproc. I have been monitoring the beagleboard and TI forums and I have not come across a simple example that programs the C66x cores to just toggle an LED or something like that.

That’d be a great project starting point.

A simple example like that would help me understand how to use remoteproc to load and run programs on the DSP cores. Or if the idea is to stick with OpenCL, from what I have been able to gather, a default starter program is loaded to both DSP cores on boot. Then when you run your Linux app you are able to run code on the DSP cores somehow using OpenCL. Again a simple example here blinking an LED would be super helpful, and even better if the LED was being blinked inside a SYS/BIOS Clock object.
What are your thoughts?

Getting started should probably include both the OpenCL stuff and a more raw remoteproc/shared-mem/rpmsg approach.

Look at the TIDL examples in cloud9-examples for the OpenCL make I setup.

I would love to see a simple “echo” rpmsg example for C66 cores using GCC toolchain.That would allow interesting experiments without any proprietary bits.

+1 on GCC!

I tried and failed to get a simple C66 ELF from c6x-gcc to be loaded by remoteproc. I then saw mentions of setting up IOMMU in the linux remoteproc driver and gave up :slight_smile:

oh no. I hope there’s not too much magic in the OpenCL stuff.

I would love to see a simple “echo” rpmsg example for C66 cores using GCC toolchain.That would allow interesting experiments without any proprietary bits.

+1 on GCC!

One possible issue with C66 GCC is that most likely it has not been regression-tested in the past few years.

C66 Linux appears dead, so native execution of the GCC testsuite is not possible. A free Linux simulator was never released to allow running the GCC testsuite on a x86 host.

I started porting YAC6xSim to Linux, but did not manage to finish it - https://github.com/dinuxbg/YAC6xSim . Continuing this effort might be a good GSOC project, if c66 remoteproc with a free toolchain is a viable path.

Hi all,

I’m very curious about this as I have been trying to figure out how get started with developing a DSP-based application on the C66’s, but one that also involves the beagleboard Debian distro on the A15’s. I’m hoping the GSOC students et. al. can post up any example projects utilizing the other cores on either the BB-X15 or beaglebone-AI. They’ve come up with some really nifty projects…

I’m hoping to experiment around with the different interfaces (e.g. IPC, OpenCL) and the partitioning of the application (e.g. moving some of the DSP blocks in the DSP chain inside the A15, and they pass their output to DSP1 via IPC. DSP1 passes it’s output to DSP2 via another buffer which was “carved away” from Linux, etc. )

But from all the posts above and over the last-couple of days, I’m confused as to the state of remote proc, rpmsg, the C compiler for the C66’s, and what path to go down first.

But right now, I’m hoping I can at least get part of the way there by starting with the latest bb.org, BB-X15 image and corresponding sources and then following the steps on ( http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_IPC.html#ipc-for-am57xx ) as guidance for how to setup the board so that Debian Linux can simultaneously run on the A15’s with a C66 application running on DSP1. The latter compiled via CCS and downloaded via JTAG to DSP1, at least initially. In this configuration, the DSP application won’t initially communicate with Linux on the A15. I just want to get the DSP running something and the two programs from stepping on each other.

Then once that’s working start fussing with communications A15 Linux <-> C66, posting up the results and asking for help or googling how to push this through the system if something really appears broken (vs. user error).
Later on, once the DSP application is debugged worrying about how to deploy the executables from A15/Debian to the C66 of interest.

Does the above IPC-based approach make any sense?

I plan to at least try it this weekend and also the TI Linux SDK example if I’m completely stuck.

Also, it’s been a couple of years, since I’ve been working with Linux, so please bare with me!

Thanks!