**** BEGIN LOGGING AT Mon Jun 01 02:59:57 2020
Jun 01 10:55:04 <deepankarmaithan> jkridner:  thanks. I  checked with fedex  the package is  somewhere in my city but the local fedex guy was saying i have to pay customes. I asked him to check again , he agreed to check again, But to be safe do you have any receipt for the customs you paid for any customer ID of beaglebones fedex account
Jun 01 10:55:52 <deepankarmaithan> *But to be safe do you have any receipt for the customs you paid  or  any customer ID of beaglebone's fedex account
Jun 01 11:12:56 <deepankarmaithan> jkridner:  I called back and he said he doesnot have payment confirmation. Asking me to show receipt
Jun 01 11:31:16 <deepankarmaithan> jkridner:  I called to the customer care now and he also said he doenot see any such request that the sender will pay the customs
Jun 01 11:47:09 <deepankarmaithan> jkridner:  here is my tracking no for your quick reference 182485642510
Jun 01 12:41:49 <Abhishek_> trying to compile linux kernel with clang turned out to be a rabbit hole
Jun 01 12:42:03 <Abhishek_> I'll try it later someday with a more recent kernel
Jun 01 14:07:51 <vedant16[m]> Hey zeekhuge here's my proposal: https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Improvements#Implementation_Details
Jun 01 14:08:15 <Abhishek_> Can't see zeekhuge here
Jun 01 14:11:48 <vedant16[m]> zeekhuge:
Jun 01 14:12:00 <vedant16[m]> <Abhishek_ "Can't see zeekhuge here"> @zee
Jun 01 14:12:08 <vedant16[m]> > <@freenode_Abhishek_:matrix.org> Can't see zeekhuge here
Jun 01 14:12:08 <vedant16[m]>  * zeekhuge:
Jun 01 14:12:57 <vedant16[m]> https://github.com/VedantParanjape/simpPRU/blob/master/frontend/lexer.l
Jun 01 14:13:09 <Abhishek_> I'm via IRC, for some reason ZeekHuge's messages are not appearing here
Jun 01 14:13:36 <vedant16[m]> Try on riot ?
Jun 01 14:13:48 <Abhishek_> Yes, I got it there
Jun 01 14:14:03 <vedant16[m]> ok
Jun 01 15:35:12 <Abhishek_> Hi yoder, good to e-meet you here :)
Jun 01 15:57:55 <Abhishek_> meeting soon
Jun 01 15:58:02 <Abhishek_> vedant16[m]: you there?
Jun 01 16:04:16 <vedant16[m]> Abhishek_: Yes, I'm here
Jun 01 16:04:29 <Abhishek_> Hello
Jun 01 16:04:35 <vedant16[m]> https://github.com/VedantParanjape/simpPRU/tree/master/frontend did this today
Jun 01 16:04:37 <pratimugale[m]> Hey
Jun 01 16:04:41 <Abhishek_> Can't see hendersa around
Jun 01 16:04:47 <vedant16[m]> hey pratimugale
Jun 01 16:04:48 <Abhishek_> Hi pratimugale[m]
Jun 01 16:04:55 <vedant16[m]> hendersa: hey you here ?
Jun 01 16:05:07 <vedant16[m]>  * hendersa: hey you there ?
Jun 01 16:06:33 <Abhishek_> Hi zeekhuge[m]
Jun 01 16:08:48 <zeekhuge[m]> Hey Abhishek_ ! Came across the project titles in the email. They are interesting.
Jun 01 16:10:13 <pratimugale[m]> Hi zeekhuge Nice to see you
Jun 01 16:10:26 <vedant16[m]> I had forgot to add relational operators, added that in the wiki
Jun 01 16:10:47 <jkridner[m]> hi all
Jun 01 16:11:21 <Abhishek_> So you've written the basic lexer example right now, correct?
Jun 01 16:11:29 <Abhishek_> Q for vedant16[m] ^
Jun 01 16:12:10 <vedant16[m]> <Abhishek_ "So you've written the basic lexe"> Yup, it can handle variable assigment and lex arithmetic expressions.
Jun 01 16:12:27 <Abhishek_> Nice, what's your next step?
Jun 01 16:12:29 <jkridner[m]> yoder: howdy!
Jun 01 16:12:43 <saketh> hola all!
Jun 01 16:12:51 <vedant16[m]> <Abhishek_ "Nice, what's your next step?"> https://github.com/VedantParanjape/simpPRU/blob/master/frontend/test.sim test codes
Jun 01 16:13:27 <vedant16[m]> I will write semantic analyser then, implement LLVM backend for the same in this week.
Jun 01 16:13:43 <vedant16[m]> <vedant16[m] "Yup, it can handle variable assi"> for this.
Jun 01 16:14:06 <Abhishek_> Don't forget implementing stuff on the PRU, did you make any progress on improving your PRU knowledge?
Jun 01 16:15:26 <pratimugale[m]> vedant16: Did you get your package, if not let me know if you want ssh access
Jun 01 16:15:40 <vedant16[m]> <Abhishek_ "Don't forget implementing stuff "> Yup, i read up exploring beagleboard, cleared pretty much all stuff.
Jun 01 16:15:56 <Abhishek_> Did you try yoder[m] 's PRU cookbook?
Jun 01 16:16:01 <vedant16[m]> practised basic codes in pru assembly
Jun 01 16:16:14 <vedant16[m]> <Abhishek_ "Did you try yoder 's PRU cookboo"> No, I will take a look
Jun 01 16:16:36 <vedant16[m]> <pratimugale[m] "vedant16: Did you get your packa"> Nope, I will get on 3rd June. current task doesnot require bb
Jun 01 16:16:44 <vedant16[m]> > <@pratimugale:matrix.org> vedant16: Did you get your package, if not let me know if you want ssh access
Jun 01 16:16:44 <vedant16[m]>  * Nope, I will get on 3rd June. current task doesnot require bb. Sure !
Jun 01 16:16:45 <pratimugale[m]> Okay
Jun 01 16:17:17 <vedant16[m]> I will submit kernel task after i test it on BBB
Jun 01 16:17:23 <vedant16[m]> is that okay ?
Jun 01 16:17:33 <Abhishek_> Sure, no problem
Jun 01 16:18:09 <Abhishek_> BTW check out rcn-ee's yakbuild repository if you want a readymade script to build the kernel
Jun 01 16:18:11 <jkridner[m]> do we have an up-to-date set of objectives?
Jun 01 16:18:25 <Abhishek_> jkridner[m]: https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Improvements#Implementation_Details
Jun 01 16:18:41 * jkridner[m] is using https://elinux.org/BeagleBoard/GSoC/2020_Projects#Projects as the snapshot dashboard.
Jun 01 16:19:23 <vedant16[m]> <Abhishek_ "BTW check out rcn-ee's yakbuild "> Yup
Jun 01 16:19:43 <vedant16[m]> <jkridner[m] "do we have an up-to-date set of "> I have updated on wiki
Jun 01 16:21:07 <jkridner[m]> for deliverable #3 (Update PRUSpeak to work with the latest kernel.) will this move from Python to kernel/rpmsg ?
Jun 01 16:21:08 <vedant16[m]> jkridner: Do we have to send weekly progress on mailing list?
Jun 01 16:21:34 <jkridner[m]> vedant16: yes, as replies to previous status updates so they are on a single thread.
Jun 01 16:21:43 * jkridner[m] can find where this is spelled out.
Jun 01 16:22:13 <vedant16[m]> <jkridner[m] "for deliverable #3 (Update PRUSp"> But python thing was already using a userspace program with rpmsg
Jun 01 16:22:25 <jkridner[m]> https://elinux.org/BeagleBoard/GSoC/2020_Projects#Weekly_reports
Jun 01 16:22:50 <vedant16[m]> <jkridner[m] "vedant16: yes, as replies to pre"> Could you tell me the mailing list address please.
Jun 01 16:23:18 <jkridner[m]> vedant16: k, my main concern is creating something that is there on boot-up and is unlikely to stop working on future revisions.
Jun 01 16:23:49 <jkridner[m]> I don't think this stuff works right now as-is and being out of tree is a big part of that.
Jun 01 16:23:57 <Abhishek_> vedant16[m] and For all students -> beagleboard-gsoc@googlegroups.com
Jun 01 16:24:18 <vedant16[m]> <jkridner[m] "I don't think this stuff works r"> ohh, so rather making something new, i will tweak it to run on current version ?
Jun 01 16:24:21 <jkridner[m]> yeah.
Jun 01 16:24:23 <Abhishek_> jkridner[m]: Remoteproc is a moving target, that's what I've kinda learnt
Jun 01 16:24:25 <vedant16[m]> <Abhishek_ "vedant16 and For all students ->"> thanks
Jun 01 16:24:44 <jkridner[m]> Abhishek_: because it hasn't landed upstream yet?
Jun 01 16:24:51 <Abhishek_> jkridner[m]: Yes
Jun 01 16:25:18 <Abhishek_> I've tried building BeagleLogic on 4.19 and 5.4 so far and I can't get a single C file to target both, there're some minor API changes
Jun 01 16:25:42 <jkridner[m]> <vedant16[m] "ohh, so rather making something "> I'm not trying to say how... other mentors can say that.... I'm just saying I worry about how the existing example became stale. Unless I'm wrong and it "just works".
Jun 01 16:25:45 <Abhishek_> Not something I can't work around with but unless it's stable I have to play fast follow
Jun 01 16:26:17 <vedant16[m]> <jkridner[m] "I'm not trying to say how... oth"> Sure, I will discuss this with mentors
Jun 01 16:26:48 <vedant16[m]> <Abhishek_ "Not something I can't work aroun"> Why does it become outdated ? does the RPROC API keep changing
Jun 01 16:27:07 <Abhishek_> Yes, subtle changes between kernel versions
Jun 01 16:27:46 <vedant16[m]> <Abhishek_ "Not something I can't work aroun"> Then this something that can't be avoided i guess ?
Jun 01 16:28:24 <zeekhuge[m]> @pratimugale:matrix.org: Hey! Happy to be here. Its mostly busy here. The projects look interesting, and will try to help.
Jun 01 16:29:26 <Abhishek_> Thinking out aloud here but BeagleLogic moving to UIO will be a step back. I'm considering a relook on the module anyway.
Jun 01 16:29:44 <jkridner[m]> howdy zeekhuge !
Jun 01 16:29:52 <Abhishek_> zeekhuge[m]: Maybe you have something to offer on the parallel bus as well, I remember you did some work with a parallel bus on BeagleScope
Jun 01 16:30:24 <vedant16[m]> <Abhishek_ "Thinking out aloud here but Beag"> Write something like HAL for remoteproc ?
Jun 01 16:30:41 <Abhishek_> remoteproc itself is the HAL
Jun 01 16:31:17 <vedant16[m]> <Abhishek_ "remoteproc itself is the HAL"> Wrapper on top of it, which will remain constant, add make it easy to update the wrapper.
Jun 01 16:31:24 <Abhishek_> UIO is disliked in general because it moves driver implementation to userspace
Jun 01 16:31:26 <vedant16[m]> > <@freenode_Abhishek_:matrix.org> remoteproc itself is the HAL
Jun 01 16:31:26 <vedant16[m]>  * Wrapper on top of it, which will remain constant, add make it easy to update the wrapper whenever changes occur.
Jun 01 16:31:33 <jkridner[m]> Abhishek_: I'd hope we can work with the remoteproc developers to avoid any backsliding to UIO. Note: UIO can still be used for direct memory accesses where it makes sense. Not sure if control registers fit into that ever.
Jun 01 16:31:39 <Abhishek_> vedant16[m]: Yes, sounds like a good idea
Jun 01 16:31:50 <Abhishek_> I've been reading about it recently in another context
Jun 01 16:32:48 <saketh> for some context on the parallel bi-dir bus https://photos.app.goo.gl/L85myc4qhvBsLya37
Jun 01 16:32:48 <vedant16[m]> We could implement it using some script which can autogenerate python library depending how rproc changed. I will read up about this.
Jun 01 16:33:42 <Abhishek_> jkridner[m]: I think remoteproc makes it a little clumsy when you want to quickly patch running firmware on the PRU. Thinking about scenarios when you can quickly compile a PRU code snippet and want to execute it on the PRU.
Jun 01 16:34:03 <Abhishek_> something like what vedant16[m]'s code is going to do.
Jun 01 16:34:36 <jkridner[m]> Indeed. If his code is running within the kernel, which is what I'm advocating, there's more flexibility.
Jun 01 16:35:02 <Abhishek_> But this means the REPL is in the kernel itself, not sure if it should be inside the kernel
Jun 01 16:35:19 <jkridner[m]> I think people should be less afraid of making their code a kernel module, especially when it is impacting potentially shared resources.
Jun 01 16:35:40 <jkridner[m]> Abhishek_: think of existing assemblers in the kernel.
Jun 01 16:35:53 <vedant16[m]> <jkridner[m] "I think people should be less af"> But it's not a REPL in sense, it is going to compile code.
Jun 01 16:36:18 <zeekhuge[m]> Hi @jkridner:matrix.org
Jun 01 16:36:53 <zeekhuge[m]> @abhishek_:matrix.org: I think so. I have asked the student to share the proposal link. Will look into it.
Jun 01 16:37:32 <jkridner[m]> https://www.kernel.org/doc/html/latest/bpf/index.html
Jun 01 16:38:00 <jkridner[m]> I suppose REPL itself is different, but the assembler portion is much like BPF as I understand it.
Jun 01 16:38:11 <jkridner[m]> except this would be executed, rather than interpreted.
Jun 01 16:38:58 <Abhishek_> interesting
Jun 01 16:39:12 <vedant16[m]> If i am a kernel module, how do i load firmware in PRU and run it ?
Jun 01 16:39:34 <Abhishek_> vedant16[m]: You use the pruss_remoteproc APIs
Jun 01 16:39:36 <vedant16[m]> i mean how to do it w/o uio or rproc
Jun 01 16:40:30 <vedant16[m]> <Abhishek_ "vedant16: You use the pruss_remo"> But why make a kernel module then ?
Jun 01 16:40:37 <Abhishek_> vedant16[m]: At the lowest level, you parse the executable , write it to PRU code memory and reset the PRU so that it starts execution
Jun 01 16:40:50 <Abhishek_> But the pruss_remoteproc API does all this for you
Jun 01 16:41:09 <vedant16[m]> Ohhk
Jun 01 16:41:23 <Abhishek_> vedant16[m]: The pruss_remoteproc is itself a kernel module, you can call the APIs present in another kernel module from your kernel module
Jun 01 16:42:07 <vedant16[m]> <vedant16[m] "Ohhk"> ohk, but why should repl put in the kernel then ?
Jun 01 16:42:28 <Abhishek_> jkridner[m]: Interesting, so you use LLVM to compile some BPF code and that code then runs within the BPF system to filter packets
Jun 01 16:42:50 <Abhishek_> vedant16[m]: You want to be as close to the PRUs as you can
Jun 01 16:43:49 <jkridner[m]> Abhishek_: yes, this has precedent. also, PRU started its life as a network packet processor.
Jun 01 16:44:14 <vedant16[m]> Ohh, so it will be faster. If this is implemented, i will write my code to something like /firmware and it will compile in the kernel ?
Jun 01 16:44:29 <Abhishek_> Might have to split up the REPL into a part that executes in kernel space (patch running PRU firmware) and a part that's in userspace (invokes lexer/LLVM/GCC whatever)
Jun 01 16:45:55 <vedant16[m]> <Abhishek_ "Might have to split up the REPL "> So a custom kernel module which will load compiled binary directly, no need for a script to load bin/
Jun 01 16:45:59 <vedant16[m]> > <@freenode_Abhishek_:matrix.org> Might have to split up the REPL into a part that executes in kernel space (patch running PRU firmware) and a part that's in userspace (invokes lexer/LLVM/GCC whatever)
Jun 01 16:45:59 <vedant16[m]>  * So a custom kernel module which will load compiled binary directly, no need for a script to load bin.
Jun 01 16:46:39 <Abhishek_> vedant16[m]: There's already a mechanism to load files in /lib/firmware to the PRUs via remoteproc
Jun 01 16:47:39 <vedant16[m]> <Abhishek_ "vedant16: There's already a mech"> Yes I know this, sorry, I am not able to understand why will we need a custom kernel module then ?
Jun 01 16:48:39 <Abhishek_> Last I remember there's a bunch of remoteproc APIs exposed as sysfs interfaces, not sure if they're still there in 5.4
Jun 01 16:49:34 <jkridner[m]> I'm looking for portions to assemble the source to be in kernel land as to be always-available, maintained as the kernel evolves. Also, to be a resource for other kernel modules.
Jun 01 16:50:10 <jkridner[m]>  * For me, I was thinking put assembly of the source to be in kernel land as to be always-available, maintained as the kernel evolves. Also, to be a resource for other kernel modules.
Jun 01 16:50:16 <jkridner[m]> like BPF.
Jun 01 16:50:42 <jkridner[m]> but, sorry if I'm confusing things.... again, my point is I don't want this to go stale like older attempts.
Jun 01 16:51:01 <Abhishek_> same here
Jun 01 16:51:12 <Abhishek_> (to your point about older attempts)
Jun 01 16:51:54 <vedant16[m]> Ohk got it, I don't use things which keep on changing, thus it will work across several kernel.
Jun 01 16:53:08 <jkridner[m]> ...one of my unspoken reasons is if PRUSpeak analog operations existed in the code, having it be in the kernel provides a dynamic mechanism for changing the resource owner from the kernel to the PRU.
Jun 01 16:54:02 <yoder[m]> <Abhishek_ "Hi yoder, good to e-meet you her"> Abhishek_:  It's good to join, though I'm going to be in and out most of today.
Jun 01 16:54:03 <jkridner[m]> vedant16: if it gets into the mainline kernel, then if someone else breaks it, it is their responsibility to fix it....
Jun 01 16:54:20 <jkridner[m]> if it lives on its own, no one has to make sure the interfaces you use will always be compatible.
Jun 01 16:54:44 <vedant16[m]> <jkridner[m] "if it lives on its own, no one h"> Yup, agreed.
Jun 01 16:54:58 <jkridner[m]> yoder: just popping in on a frequent basis will be amazing. thanks.
Jun 01 16:55:27 <vedant16[m]> inshort a custom kernel module which will handle loading and starting pru jkridner
Jun 01 16:55:49 <Abhishek_> There are two components to your project as I see it - (i) the language implementation itself , (ii) the component that manages interaction of the user to the PRUs through the language
Jun 01 16:55:50 <yoder[m]> <jkridner[m] "yoder: howdy!"> Hey jkridner .  I'm starting work in PRUCookbook v.2.0.  I should have lots of questions for tomorrow's meeting.
Jun 01 16:56:21 <Abhishek_> yoder[m]: Hi, what have planned for Cookbook v2.0? I'd be interested to know more about it as well
Jun 01 16:56:35 <vedant16[m]> <Abhishek_ "There are two components to your"> (i) won't go stale as, it simply generates bin.
Jun 01 16:58:24 <yoder[m]> <vedant16[m] "No, I will take a look"> I found the PRU c compiler does a good job.  Generally I got good performance without assembly.
Jun 01 16:58:25 <jkridner[m]> yoder: having PRUSpeak would be awesome. update for BBAI and usage of cloud9-examples to simplify examples would be great. when v2020.08 is released on August, it'd be good to have it all staged up with a matching PDF release.
Jun 01 16:59:47 <jkridner[m]> yoder: there's also supposed to be bug fixes in am335x_pru_package, perhaps making compatible with BBAI. Right now, the TI pru support package is what is installed in /usr/share/ti and I wonder if this project will merge that.
Jun 01 17:00:31 <jkridner[m]> yoder: indeed, the clpru C compiler is pretty good. I've just started using gcc-pru and it works, but I don't think the optimization is as good.
Jun 01 17:00:37 <Abhishek_> jkridner[m]: which release is 2020.08 referring to ? rcn-ee's system image?
Jun 01 17:00:59 <jkridner[m]> yes. to be sync'd with a cloud9-examples 2020.08
Jun 01 17:01:08 <jkridner[m]> 5.4 kernel is the target.
Jun 01 17:01:20 <jkridner[m]> still Debian Buster (10), I believe.
Jun 01 17:01:45 <jkridner[m]> rolling in any of the output from the GSoC projects is a goal.
Jun 01 17:02:24 <jkridner[m]> 3-annual releases are roughly geared at April for start of GSoC, August for end of GSoC and December to catch off-cycle stuff.
Jun 01 17:03:14 <nwan[m]> Hello everyone
Jun 01 17:04:20 <Abhishek_> jkridner[m]: I want to get BeagleLogic in this time as well with properly built sigrok packages. It's up to you whether it should be present in the default system image or a separate image.
Jun 01 17:05:09 <jkridner[m]> Abhishek_: I'd guess the size isn't that big? Dropping the GUI has made space be a bit less of an immediate problem.
Jun 01 17:05:46 <Abhishek_> jkridner[m]: It's mostly the kernel module + sigrok packages, maybe 100MB max.
Jun 01 17:05:59 <jkridner[m]> Abhishek_: the BBAI image is broken out separate to include the rather large OpenCL/TIDL/DSP-compiler tools.
Jun 01 17:06:09 <nwan[m]> jkridner:  I wasnt able to get 5.4-rt running on BBAI, as I was not able to fix Oops message from yesterday. rma31 and I agreed, that it would be best to switch to a target kernel which runs smoothly on BBAI as a starting point so I do not loose so much time right now. Which target RT kernel would you prefer?
Jun 01 17:06:26 <Abhishek_> nwan[m]: try 4.19-rt?
Jun 01 17:06:54 <Abhishek_> Think 4.14 is default what the BBAI ships with
Jun 01 17:07:12 <nwan[m]> Abhishek_:  I can, but have to see which target jason would like to have
Jun 01 17:09:35 <yoder[m]> <Abhishek_ "yoder: Hi, what have planned for"> I think the first goal is to make sure everything still works while adding BBAI examples.
Jun 01 17:09:47 <yoder[m]> Looks like Jason has some ideas too.
Jun 01 17:10:59 <Abhishek_> nice
Jun 01 17:13:49 <jkridner[m]> Sorry if I slowed things down today. I'll try not to interfere with Abhishek_ 's direction. Unfortunately, I have to run for a couple of hours.
Jun 01 17:14:32 <jkridner[m]> vedant16: better to get wrong information up on the wiki than no information at this point so that we can communicate and iterate.
Jun 01 17:14:58 <Abhishek_> jkridner[m]: I appreciate your inputs, please do not hesitate to jump in here
Jun 01 17:15:02 <jkridner[m]> as you understand things better, you can clean it up. don't be shy to be wrong. it is expected at this phase.
Jun 01 17:15:49 <vedant16[m]> <jkridner[m] "as you understand things better,"> Yup, Thanks.
Jun 01 17:16:25 <Abhishek_> jkridner[m]: And also thanks for pointing to BPF, it's a TIL for me.
Jun 01 17:39:41 * zeekhuge[m] is using RiotX. It looks really good.
Jun 01 17:47:31 <Abhishek_> No iOS version for riotx currently
Jun 01 18:37:21 <nwan[m]> > jkridner:  I wasnt able to get 5.4-rt running on BBAI, as I was not able to fix Oops message from yesterday. rma31 and I agreed, that it would be best to switch to a target kernel which runs smoothly on BBAI as a starting point so I do not loose so much time right now. Which target RT kernel would you prefer?
Jun 01 18:37:21 <nwan[m]> @pdp7: do you have a recommendation?
Jun 01 19:09:55 <pdp7> re: RT Linux kernel on AI. you need to blacklist the broadcom wifi driver.  It is from the vendor and adds SoftAP but it is not RT safe
Jun 01 19:10:23 <pdp7> so better to disable it, since I doubt you care about having soft access point (we use for out of box setup)
**** ENDING LOGGING AT Tue Jun 02 02:59:57 2020