**** BEGIN LOGGING AT Fri Apr 09 03:00:09 2021
Apr 09 03:18:47 <ds2> LSTM RELU CONV2D Convolution Transposed Matrix Multiple CBLAS LINPACK CUDA GPGPU OpenCL OpenGL ComputeShaders VertexShaders
Apr 09 03:19:01 <ds2> that ought to be some chum in the water for the pubic loggers :D
Apr 09 08:09:18 <jduchniewicz1>  ds2 I got your mails and reading through them. jkridner  still getting familiar with the beagleconnect
Apr 09 08:09:36 <jduchniewicz1> I will try to come up with some proposals today for either or both of them
Apr 09 08:09:44 <jduchniewicz1> since YOLO is borked for now
Apr 09 08:21:38 <jduchniewicz1> so why exactly the PowerVR owner company does not release open source libraries for GPGPU acceleration? Because the logic of if eludes me, they are the GPU IP manufacturer right?
Apr 09 08:26:48 <jduchniewicz1> also I am quite curious why TI OpenCL is not using the GPU for any acceleration
Apr 09 08:26:57 <jduchniewicz1> DSPs are listed but not GPUs
Apr 09 08:30:25 <giuliomoro[m]> > <@lorforlinux:matrix.org> There is one student `Leo` on the forum who is interested in the project!
Apr 09 08:30:25 <giuliomoro[m]> > https://forum.beagleboard.org/t/gsoc-21-interested-in-contributing-bela-platform/29049/2
Apr 09 08:30:25 <giuliomoro[m]> I have done my best to reply to all those who posted about it on the forum
Apr 09 08:36:24 <DhruvaGole[m]> giuliomoro:  Bela support on BeagleBone AI seems to be an interesting project idea to me, would you suggest I start writing a proposal or have you found someone suitable already?
Apr 09 08:36:39 <DhruvaGole[m]> Time is very less now hence I am asking before I start writing the proposal
Apr 09 08:37:42 <DhruvaGole[m]> I have already written a proposal for Robocape on BBAI, hence I am somewhat familiar with the DT overlays in place in the BBAI and also the overall idea of porting BB Black codes to the new BBAi...
Apr 09 08:44:10 <DhruvaGole[m]> Is it pre requisite for working on Bela projects that we have some basic background about the audio libraries in C++
Apr 09 08:44:23 <DhruvaGole[m]>  * Is it pre requisite for working on Bela projects that we have some basic background about the audio libraries in C++ and that we implement them?
Apr 09 08:45:42 <DhruvaGole[m]> also, does it require good knowledge of DSP?
Apr 09 08:46:54 <giuliomoro[m]> Dhruva Gole: the ideas I listed are very heterogeneous and require different skillsets. None of those is actually about DSP, (though I wouldn't mind a project about implementing some DSP libraries). What would you be interested in working on?
Apr 09 08:47:38 <DhruvaGole[m]> I found 2 projects interesting
Apr 09 08:47:38 <DhruvaGole[m]> 1. Bela audio driver for common audio APIs
Apr 09 08:47:38 <DhruvaGole[m]> 2. Bela support on BeagleBone AI
Apr 09 09:47:01 <vedant16[m]> <jkridner "vedant16: makes sense, yes."> Should we ask robu to add 2-3 of these in stock aswell ?
Apr 09 10:10:10 <giuliomoro[m]> <DhruvaGole[m] "I was thinkking of starting to w"> that sounds like a good starting point. Do you have experience with Linux drivers?
Apr 09 10:11:02 <DhruvaGole[m]> no, I dont have actual experience with writing linux drivers as such
Apr 09 10:12:47 <jduchniewicz1> how is Bela support handled for now? In terms of ALSA
Apr 09 10:12:47 <jduchniewicz1> is Bela recognized as audio device by Linux?
Apr 09 10:17:06 <giuliomoro[m]> > is Bela recognized as audio device by Linux?
Apr 09 10:17:06 <giuliomoro[m]> No. That is for good reasons: we can bypass the kernel and run it in a Xenomai thread, with the PRU acting as the I/O processor (a sort of sophisticated, heterogeneous DMA). This is a "dirty" solution that works very well for us in terms of increased performance, lower latency and hard real-time performance, but I am thinking it would be worth investigating whether there  may be a way of wrapping all of this in an
Apr 09 10:17:06 <giuliomoro[m]> ALSA driver without losing any of the benefits.
Apr 09 10:18:49 <DhruvaGole[m]> looks like I have a lot of homework to do like how ALSA really works andwhat exactly heterogeneous DMA) means
Apr 09 10:18:50 <jduchniewicz1> go on :D, got my attention
Apr 09 10:19:53 <jduchniewicz1> AFAIK you can map the DMA zones of ALSA drivers
Apr 09 10:20:11 <jduchniewicz1> at least that is what I did with the FPGA and the corresponding ALSA driver
Apr 09 10:20:19 <giuliomoro[m]> look at this http://eecs.qmul.ac.uk/~andrewm/mcpherson_aes2015.pdf
Apr 09 10:21:34 <DhruvaGole[m]> looks like a beginner friendly paper, will go through
Apr 09 10:23:02 <jduchniewicz1> I will look at the issue later during the day, need to finish my other propoosal first :)
Apr 09 10:23:38 <giuliomoro[m]> jduchniewicz: we are not actually using any of the AM3358 DMAs. The PRU talks to the audio codec over McASP, to the SAR ADC and string DAC via SPI and reads some of the ARM GPIOs, puts all of that in a location in PRU RAM from which the ARM core retrieves the input data and to which it writes the output data
Apr 09 10:24:12 <jduchniewicz1> what is McASP?
Apr 09 10:24:32 <jduchniewicz1> seems like a lot of work is happening there
Apr 09 10:24:56 <jduchniewicz1> this paper describes it in more detail?
Apr 09 10:25:23 <giuliomoro[m]> McASP is the multichannel audio serial port (chapter 23 of the AM335x technical reference manual). It can do I2S or TDM or other less standard stuff.
Apr 09 10:27:30 <giuliomoro[m]> that paper has more details, but also look here and the posts I linked at the bottom https://forum.bela.io/d/903-details-for-why-pru-xenomai-is-necessary-for-bela/2
Apr 09 10:29:24 <giuliomoro[m]> Dhruva Gole: "heterogeneous DMA" is something I came up with (I think?) it just means that normally a DMA communicates with a single peripheral at a time. The way we use the PRU we communicate to several peripherals at once and with accurate timing in a way that would not be possible via a regular DMA.
Apr 09 10:31:23 <DhruvaGole[m]> aah I see
Apr 09 10:36:33 <giuliomoro[m]> Dhruva Gole: as far as the porting to BBAI project is concerned, it's mostly a matter of getting the right pins enabled, running the PRU code with `rproc`, probably modify some constants in the PRU code accounting for any difference in SPI, MCASP and GPIO between AM3358 and AM5729 and testing that it all runs with a Xenomai kernel. I believe rcn has released one in the past but I haven't tried it yet.
Apr 09 10:43:06 <giuliomoro[m]> Dhruva Gole jduchniewicz  as optional steps, delegating peripheral initialisation to the mcasp and spi drivers instead of doing it all by setting registers manually as we are doing now. This should hopefully make it more portable for porting to other boards in the family, present or future. There is also the alternative of a project about porting to BeagleV, though that requires more thinking (i.e.: BeagleV does not
Apr 09 10:43:06 <giuliomoro[m]> have a PRU or any real-time mcu on board, afaik).
Apr 09 11:01:53 <DhruvaGole[m]> DT overlay for making BBAI sort of look like a BBB is already in place, hence I dont think  we would need to modify some constants in the PRU code accounting for any difference in SPI, MCASP and GPIO between AM3358 and AM5729  right?
Apr 09 11:02:09 <DhruvaGole[m]>  * DT overlay for making BBAI sort of look like a BBB on the user space level is already in place, hence I dont think  we would need to modify some constants in the PRU code accounting for any difference in SPI, MCASP and GPIO between AM3358 and AM5729  right?
Apr 09 11:03:46 <DhruvaGole[m]> oh wait we will need to write an overlay on the Bela for BBAI compatibility as well you mean?
Apr 09 11:07:29 * giuliomoro[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/ykvpuwNuRVwhoYEmuzatnvbE/message.txt >
Apr 09 11:08:17 <DhruvaGole[m]> :not sure how the cape compatibility layer works, but I expect it should be leveraged in this project to minimise the amount of dtbos to maintain!
Apr 09 11:08:17 <DhruvaGole[m]> agreed
Apr 09 11:08:28 <DhruvaGole[m]> how to quote text in IRC?
Apr 09 11:08:37 <DhruvaGole[m]>  * how to quote text in IRC like u just did?
Apr 09 11:09:43 <DhruvaGole[m]> ```the GPIO, SPI and MCASP base addresses are hardcoded in the PRU code at the moment```
Apr 09 11:09:43 <DhruvaGole[m]> Ok I see then those will have to be changed
Apr 09 11:10:19 <DhruvaGole[m]> Then it won't be able to have backw compat. with the Black anymore right? So you will be sourcing different images for the BBAI and BB Blue/black
Apr 09 11:10:30 <giuliomoro[m]> I quoted prepending the line with `> `
Apr 09 11:11:52 <giuliomoro[m]> > Then it won't be able to have backw compat. with the Black anymore right? So you will be sourcing different images for the BBAI and BB Blue/black
Apr 09 11:11:52 <giuliomoro[m]> the idea is to keep a single codebase where these constants are set at runtime (or build time) instead of being plainly hardcoded and any variation between the working of the different peripherals between the platforms  is also handled at runtime/compile time
Apr 09 11:12:54 * DhruvaGole[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/YTdUIZIxigGtREtJVokUNgNE/message.txt >
Apr 09 11:13:45 <giuliomoro[m]> yes correct. We already have something like that in place. For instance, because the GPIOs we use on PocketBeagle are different from the ones we use on BBB.
Apr 09 11:14:19 <DhruvaGole[m]> <giuliomoro[m] "yes correct. We already have som"> right
Apr 09 11:15:30 <DhruvaGole[m]> should I start writing the proposal then?
Apr 09 11:16:09 <giuliomoro[m]> one such conditional is this one https://github.com/BelaPlatform/Bela/blob/master/pru/pru_rtaudio.p#L376-L396
Apr 09 11:16:09 <giuliomoro[m]> > should I start writing the proposal then?
Apr 09 11:16:09 <giuliomoro[m]> sure!
Apr 09 11:17:15 <DhruvaGole[m]> Due to less time I may not be able to write a very detailed one, but one thing we can doo is I will upload a brief proposal before the deadline to meet the GSoC deadline, and after that I will keep editing my draft to add in more details with time...
Apr 09 11:17:15 <DhruvaGole[m]> Will that be ok with you? giuliomoro
Apr 09 11:20:52 <giuliomoro[m]> sure, let me know when you have a draft that you'd like me to look over
Apr 09 11:22:08 <DhruvaGole[m]> sure, will tag you here once I have it ready
Apr 09 11:22:19 <DhruvaGole[m]> Can you let me know the time you will be available?
Apr 09 11:25:27 <giuliomoro[m]> I am in London UK, that gives you an idea of the timezone
Apr 09 12:39:32 <DhruvaGole[m]> okay I will write you an email please let me know if you recv
Apr 09 12:44:34 <jduchniewicz1> ds2:  here you can see the new proposal :) https://elinux.org/BeagleBoard/GSoC/2021_Proposal/GPGPU_with_GLES
Apr 09 12:44:44 <jduchniewicz1> some feedkack would be nice
Apr 09 12:45:19 <DhruvaGole[m]> <jduchniewicz1 "ds2:  here you can see the new p"> looks impressive
Apr 09 13:49:04 <YadnikBendale[m]> jkridner: So basically summarising the BeagleConnect project all that needs to be done is adding micropython support to the zephyr os and writing various drivers using micropython for GPIO, I2C, SPI, PWM, ADC right?
Apr 09 13:53:26 <YadnikBendale[m]> and for adding micropython support instructions given in the readme file of this repo have to be followed right?https://github.com/micropython/micropython/tree/master/ports/zephyr
Apr 09 13:56:24 <DhruvaGole[m]> [a good intro PPT](https://www.geeklan.co.uk/files/oshug63-bela.pdf) by giuliomoro... Anyone interested in Bela Projects can go thru
Apr 09 13:57:04 <YadnikBendale[m]> jkridner Also I have gone through the datasheet of arm cortex m4f present on the CC1352R Wireless MCU to get a brief idea of the register description needed while writing drivers.
Apr 09 13:57:59 <YadnikBendale[m]> jkridner:is the direction I am heading to correct?
Apr 09 14:05:52 <DhruvaGole[m]> Can someone share a detailed hardware datasheet or sort of ref manual of the Bela Cape? Which will help me understand what pins do what functions and how they communicate with the attached Beagle Board
Apr 09 14:36:53 <DhruvaGole[m]> giuliomoro: [here](https://github.com/BelaPlatform/Bela/blob/master/pru/pru_rtaudio.p#L376-L396) the code that you sent earlier is all written in assembly, is there no higher level code(for eg. in C) that performs a check as to whether it is a Pocketbeagle or a BB Black?
Apr 09 14:38:55 <DhruvaGole[m]> ``` // Find out whether we are on BELA_MINI
Apr 09 14:38:55 <DhruvaGole[m]>      QBBC BELA_MINI_CHECK_DONE, r2, BOARD_FLAGS_BELA_MINI```
Apr 09 14:38:55 <DhruvaGole[m]>  this too seemss to be in assembly
Apr 09 14:39:10 <DhruvaGole[m]>  * ```//
Apr 09 14:39:10 <DhruvaGole[m]>      QBBC BELA_MINI_CHECK_DONE, r2, BOARD_FLAGS_BELA_MINI```
Apr 09 14:39:10 <DhruvaGole[m]>  this too seemss to be in assembly
Apr 09 14:39:27 <DhruvaGole[m]>  * ```//
Apr 09 14:39:27 <DhruvaGole[m]>      QBBC BELA_MINI_CHECK_DONE, r2, BOARD_FLAGS_BELA_MINI ```
Apr 09 14:39:27 <DhruvaGole[m]>  this too seems to be in assembly
Apr 09 14:40:22 <DhruvaGole[m]> [this](https://github.com/BelaPlatform/Bela/blob/master/pru/pru_rtaudio_irq.p#L1015-L1016) too seems to be a check if we are on bela mini, but seems to be written in asm
Apr 09 14:46:44 <DhruvaGole[m]> I think I found it, is it this?
Apr 09 14:46:44 <DhruvaGole[m]> https://github.com/BelaPlatform/Bela/blob/master/include/Bela.h#L79-L89
Apr 09 14:52:18 <DhruvaGole[m]> hmm.. I am still unable to find where Bela communication with the BB Black comes into the picture?
Apr 09 14:54:46 <jkridner[m]> https://github.com/BelaPlatform/bela-hardware
Apr 09 14:55:34 <DhruvaGole[m]> <jkridner[m] "https://github.com/BelaPlatform/"> this has design files only, not exactly their documentation per-say
Apr 09 14:56:18 <jduchniewicz1> Having done the GPGPU proposal (waiting for a review from ds2 ) I am digging around the Micropython and the BELA ALSA drivers
Apr 09 14:56:28 <jduchniewicz1> just informing :)
Apr 09 14:58:53 <jkridner[m]> <YadnikBendale[m] "and for adding micropython suppo"> good summary. all of the upstream quality checks must pass for the pull request to be accepted.
Apr 09 15:03:32 <jduchniewicz1> giuliomoro: speaking of the ALSA driver, we would like to retain the low latency, but still be able to access the BELA device (cape?) like a normal device right?
Apr 09 15:04:01 <DhruvaGole[m]> jduchniewicz: just wondering, are we both  writing proposal for same project
Apr 09 15:04:28 <DhruvaGole[m]> ?
Apr 09 15:04:48 <jduchniewicz1> and speaking of BeagleV which does not have a PRU it seems like there an alternative is required for a low-latency processing
Apr 09 15:04:57 <jduchniewicz1> it may be so Dhruva Gole  :)
Apr 09 15:05:13 <jduchniewicz1> what are you exactly interested in with BELA
Apr 09 15:05:34 <jduchniewicz1> for me it is the ALSA driver/future considerations with BeagleV
Apr 09 15:08:00 <giuliomoro[m]> <DhruvaGole[m] "giuliomoro: [here](https://githu"> that file is in the main repo. Some C++ code is here http://github.com/BelaPlatform/Bela/tree/master/core . There is also a rtdm (Xenomai) driver https://github.com/BelaPlatform/rtdm_pruss_irq  which is not critical to the system, but allows to block on a `read()` in a RT-safe way instead of polling a flag.
Apr 09 15:10:20 <giuliomoro[m]> <jduchniewicz1 "giuliomoro: speaking of the ALSA"> Yes. I think there may be a way of writing a driver that sets up the codec / mcasp / pru / spi (via existing drivers) but then runs the audio thread (a Xenomai user-space thread with hard real-time guarantees) without doing any system calls into Linux.
Apr 09 15:11:34 <DhruvaGole[m]> jduchniewicz:  this is my proposal: https://elinux.org/BeagleBoard/GSoC/2021_Proposal/bela_on_bbai I believe we are sort of aiming for the same project but u are thinking for Beagle V and I am for AI
Apr 09 15:12:12 <lpillsbury[m]> jduchniewicz: I really liked the scope of your proposal and how you laid it out. This is for me, more than you need to include it in the proposal, but: what's a texture?
Apr 09 15:13:55 <giuliomoro[m]> <giuliomoro[m] "Yes. I think there may be a way "> to clarify: this would essentially be an ALSA wrapping layer around the existing Bela core infrastructure
Apr 09 15:15:48 <giuliomoro[m]> <jduchniewicz1 "and speaking of BeagleV which do"> yes, that is to be determined. The role of the PRU could be replaced by an external microcontroller. Or one could dig through the BeagleV specs looking for some hidden unused core that could be exploited for that purpose (e.g.: did you know the AM3358 has a Cortex M3 hidden somewhere (used for power management))?
Apr 09 15:24:45 * satacker[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/pUyCHnlOjmGkvANObCXqNZgZ/message.txt >
Apr 09 15:26:12 <jkridner[m]1> <jkridner[m] "good summary. all of the upstrea"> https://github.com/jadonk/beagle_connect_zephyr_board has the initial BSP
Apr 09 15:27:49 <jduchniewicz1> <lpillsbury[m] "jduchniewicz: I really liked the"> AFAIK OpenGL allows for rendering a frame (instantenous) or to a texture which can be reused later
Apr 09 15:28:34 <jduchniewicz1> <giuliomoro[m] "yes, that is to be determined. T"> oh this is interesting! And the little bits of trivia :D
Apr 09 15:29:47 <lpillsbury[m]> Dhruva Gole and @jduchniewicz: I just joined this community yesterday and have been trying to catch up and get set up in time to submit a proposal. I also thought that the Bela and BB AI project looked good since it was interesting and not "taken." I'm wondering if you want to either collaborate on a joint proposal for this, or discuss different aspects to make complimentary proposals? I'm also open to doing
Apr 09 15:29:47 <lpillsbury[m]> something different, but gotta get started and don't want to step on your toes if you are already deep into it
Apr 09 15:30:52 <jduchniewicz1> I am not really looking into BB AI and Bela but rather creating an ALSA driver and maybe BeagleV part
Apr 09 15:31:27 <jduchniewicz1> I am still unclear whether me and Dhruva are targeting the same proposal
Apr 09 15:32:38 <giuliomoro[m]> <jduchniewicz1 "I am still unclear whether me an"> I don't think you are working on the same topic :)
Apr 09 15:35:44 <jduchniewicz1> It seems like creating this wrapper is some significant work. The most difficult part is getting the ALSA machinery to be routed through the Xenomai thread
Apr 09 15:36:25 <jduchniewicz1> I may dig into this more, but this seems like heavy hacking to me 😃
Apr 09 15:36:49 <giuliomoro[m]> > heavy hacking
Apr 09 15:36:50 <giuliomoro[m]> which is ... good, right? :O
Apr 09 15:38:04 <jduchniewicz1> hmm, don't know if we want to be fighting with the "one true way" of Linux
Apr 09 15:38:29 <jduchniewicz1> I need to read up on how it may be done
Apr 09 15:41:10 <cwicks[m]> Hello Mentors and Students!
Apr 09 15:44:35 <cwicks[m]> Hi jduchniewicz I see your proposal is coming along well on this page https://elinux.org/BeagleBoard/GSoC/2021_Proposal/GPGPU_with_GLES
Apr 09 15:44:43 <lpillsbury[m]> <jduchniewicz1 "hmm, don't know if we want to be"> I'd also want to know that it would be consistent over different releases. I'm not sure how often ALSA changes... would be super annoying to create a wrapper that suddenly stops working, I'm not sure how much of an issue this is. There's also a few things on top of ALSA that might be a better bet etc like portaudio. I'm just brainstorming here though haven't
Apr 09 15:44:43 <lpillsbury[m]> investigated
Apr 09 15:44:58 <giuliomoro[m]> @jduchniewicz the reality is we are already pretty much out of the "one true way", and this would actually bring us closer to that!
Apr 09 15:44:58 <giuliomoro[m]> I think this is the starting point:  https://www.kernel.org/doc/html/v4.10/sound/kernel-api/writing-an-alsa-driver.html#pcm-interface
Apr 09 15:45:31 <cwicks[m]> jduchniewicz: when you get a chance is it ready to put in proposal status on the GSOC webpage ?  We have to have it there also.
Apr 09 15:46:05 <jduchniewicz1> Thanks for the heads up giuliomoro :) I need to wrap my head around this
Apr 09 15:46:10 <giuliomoro[m]> <lpillsbury[m] "I'd also want to know that it wo"> `portaudio` and `RTAudio` are what I originally thought about in the project idea.
Apr 09 15:46:44 <lpillsbury[m]> Hey everyone, real basic question: if you are in the elinux wiki, how do you make a new page from the sample proposal template?
Apr 09 15:46:45 <giuliomoro[m]> lpillsbury:  It just occurred to me recently that the ALSA solution would be more generally applicable
Apr 09 15:46:52 <jduchniewicz1> cwicks: waiting for a review from ds2 Then I can put it on the GSoC webpage
Apr 09 15:47:12 <ArchismanDey[m]> vedant16: Yesterday we were talking about removing the assigning char from int feature, if we remove that, how will arithmetic operators on char work? The way it works in C and the way I was thinking of implementing it is that they get converted to int, and then get converted to char again if the result is assigned to char, so I guess we will have to keep it, but rather than saying it is undefined behaviour for
Apr 09 15:47:12 <ArchismanDey[m]> larger ints, I will mention the value might get altered, which is also the warning C provides.
Apr 09 15:47:14 <jduchniewicz1> <lpillsbury[m] "Hey everyone, real basic questio"> just search for the name and it will prompt you to create a new page
Apr 09 15:47:58 <lpillsbury[m]> @giuliomoro what is the reason to not continue to avoid ALSA all together? seems like that would give you more control
Apr 09 15:48:38 <vedant16[m]> <ArchismanDey[m] "vedant16: Yesterday we were talk"> just use strcat
Apr 09 15:49:07 <vedant16[m]> also, don't add char rather add string
Apr 09 15:49:13 <ArchismanDey[m]> <vedant16[m] "just use strcat"> What I meant was adding two 8 bit integers
Apr 09 15:49:20 <vedant16[m]> then you can actually implement arithmetic operators on it.
Apr 09 15:49:34 <ArchismanDey[m]> similar to how 'A' + 1 becomes 'B'
Apr 09 15:49:52 <vedant16[m]> okay
Apr 09 15:50:02 <vedant16[m]> Abhishek: What's your opinion on this ?
Apr 09 15:50:08 <giuliomoro[m]> lpillsbury:  currently for each different application that a user want to run, the audio backend of the application has to be changed from using ALSA/portaudio/RTAudio/jack to using the Bela API. This could be mitigated by having portaudio/RTAudio/jack wrappers (what I put in the original project idea), but I figured if it could be just an ALSA driver (perhaps an ALSA plugin, which runs all in userspace I think?)
Apr 09 15:50:09 <giuliomoro[m]> then things could be more maintainable
Apr 09 15:50:18 <jduchniewicz1> As for the BeagleV, is the RISCV core not RT? It would probably not need anything to do the PRU work (apart from itself) giuliomoro
Apr 09 15:50:42 <vedant16[m]> <ArchismanDey[m] "similar to how 'A' + 1 becomes '"> Does it work in python, simppru should be modeled after python and not C :P
Apr 09 15:51:27 <ArchismanDey[m]> <vedant16[m] "Does it work in python, simppru "> Python doesn't have char at all
Apr 09 15:51:45 <satacker[m]> Along  lorforlinux Abhishek , can anybody give quotes for [this](https://elinux.org/BeagleBoard/GSoC/2021_Proposal/beagle_config)
Apr 09 15:51:57 <satacker[m]> * Along with  lorforlinux Abhishek , can anybody give quotes for [this](https://elinux.org/BeagleBoard/GSoC/2021_Proposal/beagle_config)
Apr 09 15:52:04 <vedant16[m]> <ArchismanDey[m] "Python doesn't have char at all"> yup, but it has strings
Apr 09 15:52:06 <ArchismanDey[m]> but one of the reasons char is useful is to use it as 8bit integers, so I think it should support arithmetic operations
Apr 09 15:52:39 <vedant16[m]> Hmm, okay. But do take abhishek's opinion too
Apr 09 15:53:17 <ArchismanDey[m]> He has been busy / unwell I think, I will of course consider his opinion once he replies
Apr 09 15:53:42 <vedant16[m]> go ahead and add pdf for now
Apr 09 15:53:51 <vedant16[m]> change it later once he replies ig
Apr 09 15:54:16 <ArchismanDey[m]> Will add by tonight
Apr 09 15:55:34 <ArchismanDey[m]> vedant16: By, the way, can you give quotes for this project?
Apr 09 15:55:52 <ArchismanDey[m]> How will it be beneficial?
Apr 09 15:56:19 <ArchismanDey[m]>  * vedant16: By the way, can you give quotes for this project?
Apr 09 15:56:49 <vedant16[m]> "simpPRU will simplify programming the PRU, and probably make it easy even for a kid to program the PRU, which is a big plus point of this project."
Apr 09 15:57:04 <ArchismanDey[m]> Thanks!
Apr 09 15:57:11 <giuliomoro[m]> <jduchniewicz1 "As for the BeagleV, is the RISCV"> the job done by the PRU is simple but has tight time constrains: every 11us it has to access the SPI bus, the McASP bus and the GPIOs and shift data to/out of RAM.. So you effectively need a computing core that does just that. It doesn't have to be powerful but whatever runs on it cannot be preempted by anything else ever. So yes in principle you could run it on one
Apr 09 15:57:11 <giuliomoro[m]> of the two RISCV cores but that would seem like a huge waste (though in principle doable!)! By having all the low-level access to the peripherals delegated to an external microcontroller, then the data could be shifted to the RISCV core via a single DMA and the 2 CPU cores would be free all of the time!
Apr 09 15:58:13 <vedant16[m]> <giuliomoro[m] "the job done by the PRU is simpl"> use rp2040 maybe as PRU ?
Apr 09 15:58:30 <jduchniewicz1> what is rp2040?
Apr 09 15:59:25 <giuliomoro[m]> > use rp2040 maybe as PRU ?
Apr 09 15:59:25 <giuliomoro[m]> Any cheap microcontroller with good peripherals will do really. I haven't looked into the RP2040's peripheral set, but it may well be good enough
Apr 09 15:59:46 <lorforlinux[m]> <jduchniewicz1 "what is rp2040? "> It's  the first custom MCU from RaspberryPi foundation with dual core ARM-Cortex M0+
Apr 09 15:59:53 <vedant16[m]> It has a mini PRU inside
Apr 09 15:59:58 <vedant16[m]> (state machine)
Apr 09 16:00:10 <jduchniewicz1> I just read through the bela presentation: https://www.geeklan.co.uk/files/oshug63-bela.pdf. I am impressed! Now I kind of understand how the Xenomai works with Linux giuliomoro  good work!
Apr 09 16:01:04 <giuliomoro[m]> <jduchniewicz1 "I just read through the bela pre"> ha! no idea that presentation was available online. Good find !
Apr 09 16:02:07 <jduchniewicz1> As far as I understand it, the BELA devices would still be served by the BELA drivers (operating on Xenomai threads and with the PRU doing all its magic), but it will be under a unified ALSA API
Apr 09 16:02:37 <jduchniewicz1> so the main work is to be feeding the data to the ALSA buffers / or pointing them at wherever the audio arrives
Apr 09 16:03:33 <giuliomoro[m]> <jduchniewicz1 "As far as I understand it, the B"> yes,. Part of the challenge in the design is how to make the "analog"(DC-coupled I/O for sensors and actuators) and "digitals" (GPIOs) available through ALSA ( sometimes it makes sense to have them as audio channels, sometimes they could be downsampled and converted to MIDI).
Apr 09 16:04:07 <jduchniewicz1> the main limitation of ALSA mentioned in the document is multimodal stream of data (audio, analog, digital)
Apr 09 16:04:34 <jduchniewicz1> ah yes you mentioned it above
Apr 09 16:05:04 <jduchniewicz1> So far my experience with ALSA is the custom driver for audio coming from the FPGA
Apr 09 16:05:11 <giuliomoro[m]> <jduchniewicz1 "so the main work is to be feedin"> partly. It's not just about giving the ALSA driver the correct pointers, but also ensure that the audio does not run in a vanilla Linux thread, but it runs on a Xenomai  thread.
Apr 09 16:05:19 <jduchniewicz1> so just one channel :)
Apr 09 16:05:49 <jduchniewicz1> okay, this last part seems to be a major challenge
Apr 09 16:08:15 <jkridner[m]1> <satacker[m] "Along  lorforlinux Abhishek , ca"> Not quite ready to give a quote, but this does look *really* interesting.
Apr 09 16:08:43 <jkridner[m]1> I can imagine many different possible actions taken based on the settings.
Apr 09 16:08:50 <jkridner[m]1> Getting a nice UI and defining what the settings are seems really useful.
Apr 09 16:09:05 <jkridner[m]1> I'd want to reach out to folks like zmatt on #beagle to validate the settings.
Apr 09 16:09:26 <jkridner[m]1> I'd also really want a web-based UI option, though Qt will be awesome as well.
Apr 09 16:11:33 <satacker[m]> <jkridner[m]1 "I'd want to reach out to folks l"> That would be really nice and improve it as  whole.
Apr 09 16:12:36 <vedant16[m]> <jkridner[m]1 "I'd also really want a web-based"> I think, if he makes it as a cpp terminal UI
Apr 09 16:12:43 <vedant16[m]> and then port it using wasm to browser
Apr 09 16:16:17 <lpillsbury[m]> @satacker I have never used BeagleBoard configuration tools, but I will say this: Raspberry pi has a configuration tool that is called from the command line and can be used to set global info. I've used it a lot for setting up industrial hardware for customers (i.e. each pi running the same program should have a different SSID etc). I would imagine that there is a significant use case for an equivalent feature in
Apr 09 16:16:17 <lpillsbury[m]> BeagleBone, and that there are folks like me who would like to do it from a tool rather than manually editing configuration files. (Manual editing is fine if you do one, but if you want to get many products out the door you want it simple and foolproof).
Apr 09 16:18:56 <satacker[m]> <lpillsbury[m] "@satacker I have never used Beag"> Cool, i appreciate your view.
Apr 09 16:23:42 <cwicks[m]> Yadnik Bendale: Have you been able to put your proposal also onto the GSOC website in proposal status?
Apr 09 16:24:30 <YadnikBendale[m]> cwicks: No i have not done it yet
Apr 09 16:24:40 <YadnikBendale[m]> Will do it now
Apr 09 16:25:51 <giuliomoro[m]> <vedant16[m] "It has a mini PRU inside"> that piece of programmable logic is an oversold joke, I think ... it has like a maximum program length of 16 instructions if I remember correctly ... I was thinking about using one M0+ core of the RP2040
Apr 09 16:27:06 <giuliomoro[m]> <jkridner[m]1 "I'd also really want a web-based"> second that! Web based so it can be integrated in the IDE and used without need for a desktop environment!
Apr 09 16:31:41 <jduchniewicz1> giuliomoro: I just looked through my take at the ALSA driver, and I am not quite sure having audio running in the Xenomai thread is possible, as ALSA needs to keep a track (the running pointer) of where in the data buffer it currently is.
Apr 09 16:33:05 <jduchniewicz1> giuliomoro: also I am considering what benefits would there be from using ALSA api? unified reading/writing to the BELA devices?
Apr 09 16:33:50 <jkridner[m]1> Aedan Cullen: how's that draft coming along?
Apr 09 16:34:17 <giuliomoro[m]> <jduchniewicz1 "giuliomoro: also I am considerin"> > currently for each different application that a user want to run, the audio backend of the application has to be changed from using ALSA/portaudio/RTAudio/jack to using the Bela API. This could be mitigated by having portaudio/RTAudio/jack wrappers (what I put in the original project idea), but I figured if it could be just an ALSA driver (perhaps an ALSA plugin,
Apr 09 16:34:17 <giuliomoro[m]> which runs all in userspace I think?) then things could be more maintainable
Apr 09 16:34:27 <jduchniewicz1> giuliomoro: there needs to be some way to expose current situation with the audio buffer to ALSA, so that it can do its magic and show to whoever queries it about the playback/recording where it is
Apr 09 16:35:04 <jduchniewicz1> ok, got it. Read the text 5 minutes ago and it completely eluded me...
Apr 09 16:35:10 <jduchniewicz1> Must be getting tired already :D
Apr 09 16:36:57 <cwicks[m]> <YadnikBendale[m] "Will do it now"> thank you!
Apr 09 16:37:41 <jduchniewicz1> Having one audio card and exposing different devices (audio/ digital/analog) is doable though giuliomoro
Apr 09 16:38:05 <DhruvaGole[m]> <lpillsbury[m] "Dhruva Gole and @jduchniewicz: I"> Hey, feel free to refer my proposal for any info u want about the Bela on BBAI... Mostly due to time constraints I will not be able to write a complete proposal before the deadline so if you feel like you can please go ahead with the topic
Apr 09 16:38:20 <cwicks[m]> Hi satacker can you please remind me of you elinux link?  have you started a gsoc page yet?
Apr 09 16:38:38 <giuliomoro[m]> <jduchniewicz1 "Having one audio card and exposi"> How does that work?
Apr 09 16:38:53 <satacker[m]> <cwicks[m] "Hi satacker can you please remin"> Yes , i have https://elinux.org/BeagleBoard/GSoC/2021_Proposal/beagle_config
Apr 09 16:41:12 <jduchniewicz1> I just refer to the idea of having one soundcard and multiple devices on it giuliomoro. Please refer to this part https://www.kernel.org/doc/html/v4.10/sound/kernel-api/writing-an-alsa-driver.html#management-of-cards-and-components
Apr 09 16:41:47 <jduchniewicz1> At least that is what I remember: one card and one device had to  be created at least
Apr 09 16:41:53 <jduchniewicz1> for interfacing with ALSA
Apr 09 16:42:04 <vedant16[m]> <giuliomoro[m] "that piece of programmable logic"> But, it is really useful, people have made hdmi using that.
Apr 09 16:42:38 <jduchniewicz1> I need to think about marrying xenomai threads and ALSA being nosy and poking its nose in the buffers
Apr 09 16:44:09 <giuliomoro[m]> <jduchniewicz1 "I need to think about marrying x"> what about using ALSA plugins from userspace? Are they of any use ?
Apr 09 16:46:03 <AedanCullen[m]> <jkridner[m]1 "Aedan Cullen: how's that draft c"> Some people at my university really want me to work on a new research project with them over the summer so I decided to do that this year. Never enough months in the year for everything - but I’ll still be here watching as all of you do your awesome gsoc projects :)
Apr 09 16:46:05 <jduchniewicz1> Hmm, will need to read about it
Apr 09 16:50:01 <YadnikBendale[m]> jkridner: Just wanted to ask you that the drivers are to be written for micropython or zephyr os?I interpreted it as Micropython.
Apr 09 16:52:02 <YadnikBendale[m]> cwicks: This much is done.https://elinux.org/BeagleBoard/GSoC/2021_Proposal/GPGPU_with_GLES
Apr 09 16:52:44 <YadnikBendale[m]> cwicks: This much is done.https://elinux.org/BeagleBoard/GSoC_2021/OpenGLES_acceleration_for_DL
Apr 09 16:57:06 * jkridner really hates the matrix.org gateway!
Apr 09 17:31:19 <ds2> jduchniewicz1: will review it shortly... I suggest just throwing it into the GSoC page as I think you can update it... this is to avoid silliness of missing deadlines
Apr 09 17:43:57 <ds2> jduchniewicz1: might want to change the stuff about newer versions of OpenGLES - the problem is imagination/ti isn't releasing newer versions even though it is possible... again non technical... it may also be good to mention that there is a university program for OpenCL but one needs to be approved and from a University
Apr 09 17:45:45 <ds2> jduchniewicz1: data flow - step 6 - context is not released til it is done. It is relatively expensive. The context should be created in an init. Data upload/render/data read is the processing. Release should be in the de-init
Apr 09 17:46:14 <ds2> jduchniewicz1: not all Beagles have a DSP i.e the popular Beagle Bone with the AM335x does not.
Apr 09 17:47:17 <ds2> more comments later
Apr 09 17:48:34 <giuliomoro[m]> jduchniewicz: / lpillsbury
Apr 09 17:49:07 <giuliomoro[m]>  * jduchniewicz: / lpillsbury another fun thing to do with BeagleV would be to use the NVDLA and NN engine for DSP ...
Apr 09 17:49:12 <giuliomoro[m]>  * jduchniewicz: / lpillsbury another fun thing to do with BeagleV would be to use the NVDLA and NN engine for (audio) DSP ...
Apr 09 18:13:57 <ds2> jduchniewicz1: only other comment is -- would you consider a C API instead of a C++ class?
Apr 09 18:16:43 <jduchniewicz1> ds2:  yes, but what is the advantage in terms of usability?
Apr 09 18:17:07 <jduchniewicz1> ds2: do potential users use C or C++?
Apr 09 18:18:26 <jduchniewicz1> giuliomoro: are the BeagleV projects tangible? I would love to get involved with the RiscV world but I am not sure if they will meet the GSoC deadlines
Apr 09 18:18:46 <ds2> jduchniewicz1: you can always call C from C++ but not as easily the other way around
Apr 09 18:19:10 <giuliomoro[m]> I don't actually know, jkridner will BeagleV boards be available for GSoC students?
Apr 09 18:19:39 <jduchniewicz1> the timeline assumes late April for testing with small group of users
Apr 09 18:19:53 <ds2> jduchniewicz1: The way I see is - a C API in the Linux kernel style allows max flexibility. Underneath, that's pretty much what it is anyways (glesaccel_init returns a ptr; glesaccel_init(handle,....) ...
Apr 09 18:20:26 <jduchniewicz1> ds2: right, this could be done in old good C way, but I thought that embedded C++ and soon Rust is gaining ground
Apr 09 18:21:07 <jduchniewicz1> ds2: maybe you are right, some MCUs don't have heap allocations and other things that might be required for C++ API
Apr 09 18:21:09 <jkridner> this matrix bridge is killing me.
Apr 09 18:21:25 <jduchniewicz1> I don
Apr 09 18:21:27 <jkridner> giuliomoro[m]: yes, pdp7 has a couple of boards set aside for GSoC.
Apr 09 18:21:31 <ds2> jduchniewicz1: it may be... but I have spent a lot of time fixing those abstracted language stuff (I work on debugging problems that people get stuck on)
Apr 09 18:21:59 <ds2> C++ just invites poor programs to write obfuscated (from the underlying HW point of view) code just because they can
Apr 09 18:22:56 <ds2> take C++ overloading - that is just a defeat device for simple searches of the code... typo in the parameter and it runs a different function
Apr 09 18:23:31 <jduchniewicz1> ds2: not arguing with this, though having more embedded Rust would be awesome
Apr 09 18:24:07 <jduchniewicz1> not having enough experience with embedded C++ (only at the Linux userspace level) to do so :)
Apr 09 18:24:11 <ds2> jduchniewicz1: I suggest a core in C with rust bindings
Apr 09 18:24:21 <ds2> besides, time is your enemy in GSoC
Apr 09 18:24:29 <jduchniewicz1> sure, this allows for maximum extensibility
Apr 09 18:24:43 <jduchniewicz1> I will change this to a C style API then
Apr 09 18:24:46 <ds2> you really don't want to plan 99.9% of your time on development and get side track when the first issue pops up
Apr 09 18:25:04 <ds2> different people may have other opinions. mine is just from having to debug other people's code
Apr 09 18:25:26 <ds2> templates and overloading is just being a major thorn
Apr 09 18:25:44 <jduchniewicz1> true, for now I don't see a lot of development to be done
Apr 09 18:26:13 <jduchniewicz1> but sure, doing it in C will allow for maximum deployability
Apr 09 18:26:34 <jduchniewicz1> let me fix the proposal in some places
Apr 09 18:26:35 <ds2> a few well defined macros and proper naming scheme can replace most of those uses. And the end result more debugable - gcc -E is the worse case debug tool for macros
Apr 09 18:27:01 <ds2> jduchniewicz1: I also suggest having at least one other mentor review it
Apr 09 18:37:33 <lpillsbury[m]> Hi can someone help me with the cross compile pull request? I cross compiled my program and pushed it to my own repo but having trouble initiating a pull request to Jason's repo. Or should I clone his, make a branch and then commit and push to a new branch in his repo?
Apr 09 18:38:11 <DhruvaGole[m]> <lpillsbury[m] "Hi can someone help me with the "> let me explain in brief:
Apr 09 18:38:25 <cwicks[m]> <YadnikBendale[m] "cwicks: This much is done.https:"> thank you
Apr 09 18:39:48 * DhruvaGole[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/SvJFILefpprDklcrPpAlbdTz/message.txt >
Apr 09 18:40:02 <cwicks[m]> <AedanCullen[m] "Some people at my university rea"> Aedan Cullen: thanks for the update - we have a beagle community in Houston.  Let me know if your plans include being in Houston this summer
Apr 09 18:40:41 * DhruvaGole[m] uploaded an image: (40KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/qTNTELnuVaQZIuqSgFCBzPSB/image.png >
Apr 09 18:40:54 <DhruvaGole[m]> lpillsbury: Click on that pull request button
Apr 09 18:41:17 <cwicks[m]> <satacker[m] "Yes , i have https://elinux.org/"> thank you!
Apr 09 18:42:28 <satacker[m]> <cwicks[m] "thank you!"> You are welcome 👍️
Apr 09 18:44:21 <lpillsbury[m]> Dhruva Gole: so the upstream repository is Jason's not your own?
Apr 09 18:44:57 <cwicks[m]> <satacker[m] "You are welcome 👍️"> satacker: looks like good progress - can you please go ahead and start a draft on the Google summer of code web page? https://summerofcode.withgoogle.com/dashboard/proposals/shared/
Apr 09 18:44:57 <DhruvaGole[m]> <lpillsbury[m] "Dhruva Gole: so the upstream rep"> yes jason's repo is the template repo and we are supposed to submit the PR there
Apr 09 18:46:39 <satacker[m]> <cwicks[m] "satacker: looks like good progre"> cwicks is the draft mutable? Because  I might have a few suggestions from jkridner , possibly from Abhishek lorforlinux too
Apr 09 18:46:57 <lpillsbury[m]> Dhruva Gole: what am i missing
Apr 09 18:47:00 * lpillsbury[m] uploaded an image: (96KiB) < https://matrix.org/_matrix/media/r0/download/beagleboard.org/zShSxYLEucrfHSlyYlQYDfGg/image.png >
Apr 09 18:47:21 <DhruvaGole[m]> you have directly cloned the template repo
Apr 09 18:47:32 * DhruvaGole[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/eeSCUEtZYVlKBpAeVxKvILCc/message.txt >
Apr 09 18:47:35 <DhruvaGole[m]> follow each step
Apr 09 18:47:36 <satacker[m]> <lpillsbury[m] "image.png"> your upstream should be your fork
Apr 09 18:47:36 <lpillsbury[m]> this is after I added and commited locally to my own local branch leah
Apr 09 18:47:39 <DhruvaGole[m]> dont forget to fork
Apr 09 18:47:46 <DhruvaGole[m]> not branch
Apr 09 18:47:47 <jduchniewicz1> <ds2 "jduchniewicz: data flow - step 6"> what do you mean by that? should I change how I create/destroy the context?
Apr 09 18:48:03 <lpillsbury[m]> aha OK thanks
Apr 09 18:48:18 <cwicks[m]> satacker: dont want to waste too much time with duplicate work and not sure if mutable, but at least get a basic one with contact info, etc so we can assign mentors to it, etc.  then as you get it reviewed on eLinux you can copy paste final into the google summer of code form
Apr 09 18:48:49 <satacker[m]> <cwicks[m] "satacker: dont want to waste too"> Understood
Apr 09 18:48:54 <satacker[m]> On it
Apr 09 18:48:56 <cwicks[m]> The eLINUX is the most flexible and detailed, but we have to have some good level of detail into the GSOC official form in order to proceed before the deadline
Apr 09 18:49:07 <jduchniewicz1> giuliomoro:  I will look briefly at the plugin side of the ALSA and tell you what is possible. As for the BeagleV, how do you see the usage of NNs and NVDLA as DSP?
Apr 09 18:49:31 <jduchniewicz1> giuliomoro:  probably quite open project :)
Apr 09 18:49:45 <jduchniewicz1> but nonetheless exciting
Apr 09 18:51:07 <ds2> jduchniewicz1:that description sounds like you are creating/destroying contexts in a loop. Generally, that is done once in the init time to get a handle and you continue til you are done
Apr 09 18:51:08 <DhruvaGole[m]> <cwicks[m] "The eLINUX is the most flexible "> is this something I am unaware of?
Apr 09 18:51:39 <DhruvaGole[m]> I mean I hope I have done the needful formalities, please let me know if I missed out anything
Apr 09 18:52:05 <jduchniewicz1> ds2:  ah, no the idea is twofold: either user asks for oneshot calculation or keeps on feeding data to already existent context and destroys it when they are done
Apr 09 18:52:36 <jduchniewicz1> so either way contexts are not created and destroyed (I know it is expensive :)
Apr 09 18:52:59 <ds2> jduchniewicz1: got it... might want to point that out as that's what I read from it
Apr 09 18:57:58 <giuliomoro[m]> <jduchniewicz1 "giuliomoro:  I will look briefly"> well ... there are these cores that are allegedly devoted to machine learning but have remarkable capabilities for DSP purposes. It would be interesting to do an investigation to understand what latency is involved in using them (because of data transfer between CPU and the core) and how long a block of data has to be for it to make sense to offload its processing
Apr 09 18:57:58 <giuliomoro[m]> to such core. This would be on the same line as the work that dr Iain Hunter did for the BeagleBone GPU recently (available here https://university.imgtec.com/fun-with-beagle-gpu/ ). This is about "GPNN" or "GPNVDLA", if you will. For the project to be possible in the GSoC time frame, there is a need to understand what level of support these cores have at the moment. jkridner or pdp7 will know more than I do on
Apr 09 18:57:58 <giuliomoro[m]> this.
Apr 09 18:59:01 <ds2> giuliomore[m]: machine learning is a very nebulous term... it comes down to convolutions, multiples and adds... almost SIMD like
Apr 09 19:00:02 <giuliomoro[m]> convolution and multiply and add is exactly what is valuable in DSP, that's why I was curious about these cores!
Apr 09 19:00:41 <ds2> yes... but calling it machie learning just hides it
Apr 09 19:05:59 <satacker[m]> cwicks: I have shared a draft (same one that was shared with Abhishek and lorforlinux
Apr 09 19:08:05 <lpillsbury[m]> <DhruvaGole[m] "lpillsbury: Click on that pull r"> got it. thanks for your help. 🙂
Apr 09 19:09:23 <jduchniewicz1> it seems to be quite tangential to my GPGPU proposal ds2  giuliomoro
Apr 09 19:10:10 <jduchniewicz1> I uploaded the proposal draft to the GSoC, waiting for more reviews ds2 cwicks
Apr 09 19:10:35 <ArchismanDey[m]> cwicks: just submitted a pdf (although I will keep updating it for the next few days)
Apr 09 19:11:00 <ds2> jduchniewicz1: thanks. In another call now but I'll look at the Elinux page later
Apr 09 19:11:05 <jduchniewicz1> can I change the PDF once I upload it ?
Apr 09 19:11:08 <ds2> and email comments if any
Apr 09 19:11:17 <jduchniewicz1> thanks
Apr 09 19:11:17 <DhruvaGole[m]> <jduchniewicz1 "can I change the PDF once I uplo"> yes
Apr 09 19:11:24 <DhruvaGole[m]> you can change justt before deadline
Apr 09 19:11:36 <ArchismanDey[m]> Abhishek: Please have a look if you are free and well
Apr 09 19:15:43 <jduchniewicz1> giuliomoro: basically using these cores to perform acceleration for computations. Are there any materials on this topic? Apparently pdp7  and jkridner you have more info on the BeagleV capabilities
Apr 09 19:22:25 <giuliomoro[m]> > basically using these cores to perform acceleration for computations.
Apr 09 19:22:25 <giuliomoro[m]> Yes. Doesn't have to be real-time audio processing for now, but an investigation of their capabilities for general-purpose DSP.
Apr 09 19:30:33 <jduchniewicz1> it would be nice to know more technical details about these subsystems, only found the source code for NVDLA
Apr 09 19:30:49 <jduchniewicz1> seems to be a verilog IP core for DL acceleration
Apr 09 19:30:59 <jduchniewicz1> so there can be some special offloading done
Apr 09 19:31:08 <jduchniewicz1> however not much info about it other than documentation
Apr 09 19:31:14 <jduchniewicz1> NN no idea
Apr 09 19:31:23 <jduchniewicz1> the NN module*
Apr 09 20:02:56 <DhruvaGole[m]> jkridner: please can you let me have the link of the repo where https://github.com/beagleboard/librobotcontrol/pull/203 this PR is from? I would like to locally download this and see how you have tried adding BBAI compat. so far.
Apr 09 20:03:25 <DhruvaGole[m]> If I cloned the original librobot it doesnt have these changes merged into it
Apr 09 20:03:39 <satacker[m]> <DhruvaGole[m] "jkridner: please can you let me "> https://github.com/jadonk/librobotcontrol/tree/bbai
Apr 09 20:04:17 <DhruvaGole[m]> thanks satacker
Apr 09 21:44:41 <YadnikBendale[m]> <jkridner[m] "Yadnik Bendale: cool. Check out "> jkridner: Just researched about this.https://learn.adafruit.com/installing-circuitpython-on-samd21-boards/advanced-creating-your-own-port
Apr 09 21:45:41 <YadnikBendale[m]> jkridner: A similar process can be followed,however I feel that micropython being a superset of circuitpython,initially focus must be on it
Apr 09 21:47:52 <YadnikBendale[m]> jkridner: Also Micropython is more mainstream and has more resources and references available for it,however Circuitpython is more beginner friendly and has a community centred more towards adafruit users only
Apr 09 21:49:15 <jkridner[m]> Those two things really balance out for me. I don't see this as the main development path for BeagleConnect Freedom. I think the Greybus out-of-box is how we'll encourage most people to use it. But, I think this gives people a way to dive deeper on the hardware.
Apr 09 21:49:52 <YadnikBendale[m]> I was thinking that both micropyhon and circuitpython can be ported,however micropython drivers must be written for  GPIO, I2C, SPI, PWM, and ADC.
Apr 09 21:50:02 <jkridner[m]> If there was Micropython and Greybus in the same firmware load, that might be pretty cool.
Apr 09 21:50:21 <jkridner[m]> Just as a nice way to get more visibility into what's going on and extend it.
Apr 09 21:51:23 <jkridner[m]> If you can dive quickly into it, I don't think there is one right approach. Just making sure it is clean and usable and upstream.
Apr 09 21:52:10 <YadnikBendale[m]> <YadnikBendale[m] "I was thinking that both micropy"> I think this can be done in  10 weeks time frame and is like an all win situation
Apr 09 21:53:09 <jkridner[m]> ah, so do both? that's a cool approach.
Apr 09 21:53:42 <YadnikBendale[m]> jkridner: Yes port both but drivers for micropython only
Apr 09 21:53:51 <jkridner[m]> k
Apr 09 21:56:44 <YadnikBendale[m]> I wanted to ask something silly.Please forgive me for this🙏.Can someone please tell me how to make the proposals page on elinux.com. Last time I had done it on the ideas page itself and jkridner transferred it.
Apr 09 22:23:39 <jkridner[m]1> <YadnikBendale[m] "I wanted to ask something silly."> I think you'd overwritten the template page. You should "view raw" the template page, copy the content, create a new page with an appropriate name, and paste the template page information.
Apr 09 22:23:56 <cwicks[m]> <DhruvaGole[m] "I mean I hope I have done the ne"> Hi Dhruva Gole I found yours https://summerofcode.withgoogle.com/dashboard/organization/6398417846140928/proposal/5956207946235904/
Apr 09 22:23:59 <jkridner[m]1> Lots of info on the web for editing Mediawiki sites.
Apr 09 22:25:05 <cwicks[m]> <cwicks[m] "Hi Dhruva Gole I found yours htt"> it says you have already finalized it.
Apr 09 22:26:55 <jkridner[m]1> Dhruva Gole: I don't think Grove modules should be required for the librobotcontrol project, so I expect that is mostly a bad copy-and-paste.
Apr 09 22:28:05 <jkridner[m]1> Dhruva Gole: the time functions should have no board dependencies.
Apr 09 22:29:07 <jkridner[m]1> Dhruva Gole: I think more time is needed for PWM and motors and less for I2C, SPI and UART (which should largely be simple usage of symlinks).
Apr 09 22:30:09 <jkridner[m]1> Dhruva Gole: you'd also need a two-wheel frame for verifying rc_balance.
Apr 09 22:30:31 <jkridner[m]1> I think we want to use https://www.pololu.com/product/3575
Apr 09 22:30:45 <jkridner[m]1> The mounting to that frame is complex.
Apr 09 22:31:27 <jkridner[m]1> Are there other Zephyr or librobotcontrol proposals I should be looking at?
Apr 09 23:17:14 <jkridner[m]1> satacker: I recommend you look to build up a series of manual verification steps for doing things like enable the PRU.
Apr 09 23:19:03 <jkridner[m]1> If I were to guess on what these would be, they'd include checking the kernel version (to make sure it shows up in the right way with the right interfaces), the device-tree entries (the live tree, not just the overlays listed in uEnv.txt), and the file permissions. Each of these should have fairly automateable remedies that I think can be incorporated into the dpkg-reconfigure script.
Apr 10 00:09:16 <OmkarBhilare[m]> https://elinux.org/BeagleBoard/GSoC/2021_Proposal/OmkarBhilare
Apr 10 00:09:16 <OmkarBhilare[m]> m_w I'm done with the proposal, please review it.
Apr 10 00:10:45 <m_w> OmkarBhilare[m], sure I will take a look
Apr 10 00:12:25 <OmkarBhilare[m]> Yes thank you as we discussed on the discord server, I will take a look into GPMC side.
Apr 10 00:12:25 <OmkarBhilare[m]> (https://github.com/pmezydlo/BeagleWire/issues/7#issuecomment-431223796)
Apr 10 00:13:00 <m_w> good
Apr 10 00:16:23 <nerdboy> OmkarBhilare[m]: overall that looks pretty good
Apr 10 00:29:42 <nerdboy> can you state more explicitly some of your intermediate deliverables?
Apr 10 00:30:17 <nerdboy>  *including documentation
Apr 10 00:32:34 <OmkarBhilare[m]> Thank you, I will add more info about deliverables.
Apr 10 02:43:19 <DhruvaGole[m]> <jkridner[m]1 "Dhruva Gole: I don't think Grove"> Alright, my bad, will edit that
Apr 10 02:43:30 <DhruvaGole[m]> <jkridner[m]1 "Dhruva Gole: the time functions "> Ohkk
Apr 10 02:43:44 <DhruvaGole[m]> <jkridner[m]1 "Dhruva Gole: I think more time i"> Okay will change the timeline accordingly
Apr 10 02:44:12 <DhruvaGole[m]> <jkridner[m]1 "I think we want to use https://w"> Okay, will add this to my list of requirements
Apr 10 02:53:44 <jkridner[m]> any students not have at least a draft on elinux?
**** ENDING LOGGING AT Sat Apr 10 02:59:57 2021