**** BEGIN LOGGING AT Sun Mar 11 03:00:03 2018 Mar 11 03:58:35 Hey, My name is Vatsa,i am a sophmore pursuing Engineering at NSIT(New Delhi).I found Project Speak,spell project is very interesting and i would love to contribute. I do have some experience with Arm based micro boards work. Who is the mentor for the speak and spell project ? Mar 11 05:39:57 what? Mar 11 07:08:06 ds2: Anything? Mar 11 07:10:53 Sidharth: not sure what you are asking Mar 11 07:12:36 ds2: well, for the GPU thing.. the CPU->GPU xfer are expensive right? But i found out that the bufferclass API provides a way to access the RAM memeory region set by CPU in GPU Mar 11 07:12:43 If we pass the pointer Mar 11 07:12:59 So would still CPU->GPU and vice cersa be a problem Mar 11 07:13:05 Oh Power VR with GLES 2.0? Mar 11 07:13:09 Yes Mar 11 07:13:11 s/Oh/On/ Mar 11 07:13:16 'k Mar 11 07:14:16 So i was thinking that the project would be about documenting the hardware capabilities... But that is decidded by the extensions for GLES 2.0 Mar 11 07:14:35 well... a GSoC project cannot be solely documentation Mar 11 07:14:47 you need to write code... it is Google Summer of _CODE_ Mar 11 07:15:01 In other words, the GLES API is alredy documented pretty well... So I thought that making a benchmarking tool willl help with demoes Mar 11 07:15:17 that is only a part of it.. Mar 11 07:15:29 need to show some alg or computation Mar 11 07:15:55 a lot of embeded devices are headless Mar 11 07:16:19 but we have a HW block... showing how it can be used would add value Mar 11 07:16:55 ds2: True, so I thought about making an interface for that such that the user doesn't have to worry about shaders and stuff Mar 11 07:17:29 I don't disagree that being nice but... keep in mind GSoC is SHORT Mar 11 07:17:43 I much rather we start with something that work rather then an interface Mar 11 07:18:26 a basic demo is a bunch of GL calls to set things up and create a shader follow by a send texture, render, read texture loop...that part isn't that complex Mar 11 07:18:41 but putting it together to show it being useful has value Mar 11 07:19:45 ds2 : But it doesn't need to be grandiose right? Mar 11 07:19:54 yes Mar 11 07:20:34 if you really think having all those bits is doable, I'd recommend breaking it up into steps and make those additonal things stretch goals Mar 11 07:21:11 I really think its more than doable. I mean I have 12 WEEKS of ABSOLUTELY NOTHING!!! Mar 11 07:21:36 few more things to keep in mind - Mar 11 07:22:09 the GLES stuff is a bunch of binary blobs... on paper, it should be possible to use GLES with framebuffers, wayland, X, Android, etc Mar 11 07:22:26 in reality, only a few of those work (due to the binary libEGL) Mar 11 07:22:45 so it would be wise to plan on time to figure out which one of those work well enough for this Mar 11 07:23:47 search for SGX and PowerVR on the Beagle mailling list to get some context of that Mar 11 07:24:02 you can use the google mirror/archives Mar 11 07:24:47 Yeah yeah I know a little bit... Was trying to use TI graphics SDK until osmeone pointed out (yesterday) the blob is available as install.... Didn't see that coming on the internet Mar 11 07:25:19 exactly... there will be time needed to sort it out Mar 11 07:25:33 I will look up the mailing lists. btw, thanks for helping me out... I was getting very confused to be frank... Mar 11 07:26:01 if anything - getting it work w/framebuffer and X and other EGL flavors would be potentially useful Mar 11 07:26:19 I am personally interestedi n framebuffer as I suspect it is the lowest overhead Mar 11 07:26:52 if you need to get hold of me, email the beagle-gsoc list Mar 11 07:27:09 Ok alright!!! Yeah baby!!! Mar 11 07:27:17 I'll get on it right away Mar 11 07:27:23 the last few days has taken a lot of our attention (we are at ScaLe) Mar 11 07:27:38 look forward to reading the proposal/app Mar 11 10:23:09 @nerdboy here's my proposal for the anemometer project,i know you are busy but since you are a mentor aswell i would like if you could take a look and comment on it https://goo.gl/PibEUN Mar 11 10:26:57 @jkrinder i have posted my proposal on the google board as well,kindly make sure it reaches Stephanie childs Mar 11 15:42:02 nerdboy: you around? Headed to ELC? Mar 11 16:52:17 no ELC this year, too much startup-y stuff... Mar 11 16:57:33 Hello Mar 11 16:58:54 I need help downloading the linaro releases and hardware pack as I don't know which one to choose Mar 11 17:36:18 jkridner: Hi. So, are we gonna use pru-gcc for the PyPRUSS project or the TI C compiler? Mar 11 17:36:57 whatever you can get working easily. Mar 11 17:37:34 eventually, I’d like to end up at the GCC compiler. Mar 11 17:37:45 I tried pru-gcc, most of the examples are working fine Mar 11 17:38:07 so, if it works nicely already, jump to it. no ideas here about the performance delta. Mar 11 17:38:29 important stuff likely should still be assembly. Mar 11 17:38:46 don’t know how much different or how well documented the assembly is. Mar 11 17:39:10 yeah, did you try pruas? Mar 11 17:39:26 no. Mar 11 17:39:50 last i used was pasm, but it is likely too limited now. Mar 11 17:40:46 About the project, we just have to replace the communication with remoteproc, right? Mar 11 17:41:10 recent commits to https://github.com/jadonk/bone101 show using the TI PRU compiler with remoteproc. Mar 11 17:41:27 any examples or APIs provided too... Mar 11 17:41:51 should show people how to communicate with the running PRU code from Python. Mar 11 17:42:09 yeah Mar 11 17:43:33 I will start working for the proposal. Any suggestions? Mar 11 17:45:08 Clarity of milestones is big. Achievable but useful/productive. Showing that you understand the objective and have the requisite skills and resolve will help. Mar 11 17:45:47 Thanks! Mar 11 17:45:48 all the google docs are a pain. Mar 11 17:46:07 yeah, I'll use the template Mar 11 17:46:28 they are resource hogs on the browser when trying to look at 40-50 of them. Mar 11 17:47:19 eLinux pages are much better anyway. Mar 11 17:48:26 * jkridner[m] wonders if we should have a github repo with pull requests for pre-submission review next year (if accepted). this year is going to be a bit adhoc for previews. really, really appreciate having it on elinux! Mar 11 17:50:56 Are there fixed no of projects for an org in GSoC? BeagleBoard generally has 5-6, right? Mar 11 17:52:08 we request a certain number of slots and Google allocates. Mar 11 17:52:54 Oh Mar 11 18:11:31 zeekhuge: for the pru offloading project we just have to fetch raw data from the mcasp0 and sample it at a rate of our choice in the PRU and store it in the PRU memory? Mar 11 18:13:46 zeekhuge: mcasp? anything like the bela.io work or ctag|face-whatever? Mar 11 18:15:03 or we can just use the pru memory as a buffer and use the other PRU at certain intervals to trasfer the processed data to main memory and interrupt the main processor Mar 11 18:26:40 transfer at intervals should be done by DMA. Mar 11 18:27:21 jkridner: zeekhuge: oh! Mar 11 18:28:03 last year’s PRU DMA project should help with that, I hope. Mar 11 18:28:04 I was going through the bela project, will get back to you! Mar 11 18:29:07 no reason to waste a PRU. we’ve already shown that off with BeagleLogic. Mar 11 18:30:15 they might not know about the dma and they have really small packets and a real-time xenomai kernel on the arm. Mar 11 18:30:20 yes totally! well the last GSOC project on the PRU DMA fits in well Mar 11 20:01:56 jkridner: basically the offload project was about creating C++ libraries to be able to access and use different onboard components. Mar 11 20:02:29 But I am not sure if the project makes sense or not now .. Mar 11 20:03:06 maybe some comments from ds2 on the PRU-offloading project, if it makes sense or not to do it ? Mar 11 20:25:13 jkridner: zeekhuge: I saw the bela project! they also use the pru as a dma to lower the latency of recording using Mcasp Mar 11 20:30:18 zeekhuge: i think i can try offloading the processing of spi, mcasp, CAN and even others to the Pru (maybe even both simultaneously), and then use PRU DMA to store them in the main memory for use by the A8 Mar 11 20:32:21 apoorvtintin: Why does the `bela` project use a PRU instead of directly using the A8 for McAsp ? Mar 11 20:39:37 zeekhuge: they use the pru as a dma to decrease latency, quoting them "We have written a custom audio driver using the Programmable Realtime Unit (PRU), a microcontroller on the same chip as the BeagleBone Black CPU. This driver is capable of buffer sizes as small as 2 audio samples for very low latency, and its performance is not affected by other system load" Mar 11 20:41:02 McAsp in on L4 ? outside the PRUSS ? right ? Mar 11 20:41:08 zeekhuge: well here they are only claiming to be processing it on the pru, with a little more poking around I found they are also using the pru as a DMA in cases Mar 11 20:42:23 yes I think, according to what i could understand they also use the bela cape, which i think has a audio codec too Mar 11 20:53:03 I would wait for ds2 to comment on it. Mar 11 20:55:48 got disconnected. did i miss anything? Mar 11 20:57:43 apoorvtintin: http://bbb.io/gsoclogs Mar 11 21:02:52 zeekhuge: sorry the logs are available only for conversations till yesterday Mar 11 21:03:39 oops . the current one is at beagle-gsoc.txt Mar 11 21:03:42 wait Mar 11 21:04:13 http://logs.nslu2-linux.org/livelogs/beagle-gsoc.txt Mar 11 21:06:53 zeekhuge: thanks I missed nothing Mar 11 21:11:58 zeekhuge: ds2: the project idea PRU based soft pheripheral is also sort of similiar to what i have been discussing for the PRU offloading project idea. Mar 11 21:13:45 you mean like implementing protocols like the I2C etc using PRUs ? Mar 11 21:16:32 Oh ! I see the idea there on the page .. Mar 11 21:16:40 zeekhuge: yes wasn't our aim in the PRU offloading idea to use the PRU read from interfaces to offload some processing and store the data for use by the A8. In the PRU soft pheripheral idea we are just using just the PRU for processing Mar 11 21:19:56 yeah ... try to look into the I2C, SPI bitbanging project from 2016. I dont know how far did that project go to implement the thing. Mar 11 22:14:06 zeekhuge: I went through the bitbanging project, it went only as far as writing the i2c and spi firmware for the pru and remote-proc and rmsg drivers for communicating with the PRU Mar 11 22:15:04 and tested only with bitbanging Mar 11 22:16:16 but surely i can use the work already done and build upon it. Mar 12 00:34:10 comment? Mar 12 00:36:20 hmmmm nothing in email... *shrug* Mar 12 01:44:55 Erik: https://github.com/jadonk/node-beagle-boot/tree/hack-in-netconsole **** ENDING LOGGING AT Mon Mar 12 03:00:01 2018