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! On Wednesday, February 10, 2021 at 4:09:35 PM UTC-5 din...@gmail.com wrote: > On Wednesday, February 10, 2021 at 9:54:39 PM UTC+2 Jason Kridner wrote: > >> On Wed, Feb 10, 2021 at 12:03 PM din...@gmail.com <din...@gmail.com> >> wrote: >> >>> 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. > > >> >> >>> 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 :) >>> >> >> oh no. I hope there’s not too much magic in the OpenCL stuff. >> >> >>> >>> Regards, >>> Dimitar >>> >>> On Wednesday, February 10, 2021 at 4:49:49 PM UTC+2 Daniel Block wrote: >>> >>>> 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 >>>> >>>> On Thu, Feb 4, 2021 at 3:49 PM Jason Kridner <jkri...@beagleboard.org> >>>> wrote: >>>> >>>>> 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. >>>>> -- >>>>> BeagleBoard.org Foundation is a US-based 501(c)3 non-profit providing >>>>> education and collaboration around open source hardware and software >>>>> >>>>> Use https://beagleboard.org/about/jkridner to schedule a meeting >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to beagleboard...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/CAK8RMs3X_7pLpMC%2BHkhM0V91jwNRQuMs8aZCQHHN3b0vvB2Q0w%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/beagleboard/CAK8RMs3X_7pLpMC%2BHkhM0V91jwNRQuMs8aZCQHHN3b0vvB2Q0w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to beagleboard...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/1e98dc57-3904-4887-883f-c3b6a6b870c6n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/beagleboard/1e98dc57-3904-4887-883f-c3b6a6b870c6n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> https://beagleboard.org/about/jkridner - a 501c3 non-profit educating >> around open hardware computing >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/eed09272-a5d6-41ff-9cb7-12d979a9d1b6n%40googlegroups.com.
