**** BEGIN LOGGING AT Mon Feb 02 02:59:58 2015
Feb 02 17:40:07 <karki_> does the linux mainline support remoteproc for the pru?
Feb 02 17:44:38 <alexanderhiam> karki_: I would love to have a PRU remote precedure call / shared varialbe interface that worked like this: https://gist.github.com/alexanderhiam/4310934a026b79fc8c65
Feb 02 17:45:25 <alexanderhiam> kark_: you think that would make sense with pruspeak, or is rpc outside of the scope of botspeak?
Feb 02 17:45:32 <karki_> alexanderhiam : https://github.com/deepakkarki/pru_serial
Feb 02 17:45:42 <karki_> this was a more basic API I was looking at
Feb 02 17:46:02 <karki_> What you mentioned can be built over it
Feb 02 17:46:04 <karki_> I need to update the readme though
Feb 02 17:46:06 <alexanderhiam> rpc could always be built on top of that
Feb 02 17:46:11 <karki_> pretty old...
Feb 02 17:46:46 <karki_> but yeah, thats what I wanted while I started pruspeak
Feb 02 17:47:36 <karki_> rpc integration with pruspeak is something interesting!
Feb 02 17:47:58 <karki_> I'll have to think about it though.... (how it will be implemented and stuff)
Feb 02 17:48:16 <alexanderhiam> I guess we would first need to implement functions!
Feb 02 17:48:29 <alexanderhiam> I had some ideas about that
Feb 02 17:51:30 * karki_ is open ears :D
Feb 02 17:52:35 <alexanderhiam> I'm forgetting them now though....
Feb 02 17:52:44 <Abhishek_> alexanderhiam and karki_ : Have a look at the idea I posted in the GSoC Ideas section
Feb 02 17:53:22 <karki_> I will be posting my idea in a few min
Feb 02 17:53:23 <Abhishek_> wiki page
Feb 02 17:53:33 <Abhishek_> http://elinux.org/BeagleBoard/GSoC/Ideas
Feb 02 17:55:50 <alexanderhiam> Abhishek_: looks great
Feb 02 18:38:29 <Abhishek_> interesting
Feb 02 18:47:51 <karki_> alexanderhiam : updated the ideas page :)
Feb 02 18:48:38 <Abhishek_> :)
Feb 02 18:49:46 <karki_> Abhishek_ : I think we need to merge our ideas
Feb 02 18:49:51 <karki_> upto some level
Feb 02 18:49:54 <karki_> atleast
Feb 02 18:51:23 <alexanderhiam> agreed. Perhaps 'PRUSS Support for the newer kernels' could be broken into two projects, one of which being the userspace interface
Feb 02 18:51:30 <Abhishek_> I'm currently thinking of splitting it into two
Feb 02 18:51:36 <Abhishek_> alexanderhiam was faster
Feb 02 18:51:40 <alexanderhiam> ;)
Feb 02 18:51:41 <karki_> ;)
Feb 02 18:51:45 <Abhishek_> one would look on the python/nodejs side
Feb 02 18:51:47 <karki_> again!
Feb 02 18:51:50 <Abhishek_> and the other on the kernel side
Feb 02 18:51:55 <karki_> nah
Feb 02 18:52:04 <karki_> it isn't woth 2 GSoC's
Feb 02 18:52:23 <karki_> but it isn't easy for 1 either.....
Feb 02 18:52:33 <alexanderhiam> it could be. The userspace side could include a bunch of examples
Feb 02 18:52:49 <Abhishek_> yup, as mentioned
Feb 02 18:53:16 <karki_> but there is minimal challenge there, and I could do that myself along with the student (I anyway have to..... for pruspeak)
Feb 02 18:53:19 <karki_> so...
Feb 02 18:54:06 <alexanderhiam> I see what you're saying karki_
Feb 02 18:54:22 <alexanderhiam> the real bulk of the work is in building that API
Feb 02 18:54:29 <karki_> I guess we can decide that later based on how many students are interested
Feb 02 18:54:36 <Abhishek_> yup, as mentors, we will be actively involved in porting our own projects as well
Feb 02 18:54:49 <karki_> but those are file ops alexanderhiam
Feb 02 18:55:14 <karki_> how complicated could they get? (am I missing something here?)
Feb 02 18:55:38 <alexanderhiam> I'm imagining an API on both sides, abstracting all the actual shared memory, upcall and kernel driver stuff
Feb 02 18:55:46 <Abhishek_> According to me the *real* issue is getting into the mainline
Feb 02 18:56:37 <alexanderhiam> e.g. a function in the PRU API to register a callback on a particular event (which requires defining and implementing said event)
Feb 02 18:56:49 <Abhishek_> the kernel API will be a lot of hard work
Feb 02 18:57:43 <karki_> that is easily handled via channels
Feb 02 18:58:07 <karki_> each sysfs entry corresponds to a channel
Feb 02 18:58:09 <alexanderhiam> might be nice to have a friendly API for writing kernel drivers as well, then a 'default' driver that just extends that API to userspace
Feb 02 18:58:25 <karki_> user writes "echo 1 > file4"
Feb 02 18:58:34 <karki_> it corresponds to event 4
Feb 02 18:58:51 <karki_> it's quite simple from the PRU side.....
Feb 02 18:58:59 <alexanderhiam> kakri_: I want it to be smarter than that!
Feb 02 18:59:42 <karki_> alexanderhiam +1 for driver API
Feb 02 19:00:04 <karki_> but I don't get what you mean by "smarter"!
Feb 02 19:00:18 <Abhishek_> Yup, something like how BeagleLogic and botspeak attach themselves to the rproc driver
Feb 02 19:00:45 <alexanderhiam> e.g. define a function in the PRU with a set of arguments, register it as callable-from-userspace, then have that information on the kernel side so that you can see from userspace what functions are callable remotely in the current running firmware and what args they take
Feb 02 19:01:00 <karki_> what we do now feels like cello-tape :p we need something robust, not developer defined.
Feb 02 19:01:13 <Abhishek_> more like post-its :P
Feb 02 19:01:34 <karki_> :D
Feb 02 19:02:38 <karki_> alexanderhiam : but the point is that then the projects are not independent, if the student working on the driver messes up, the other student is screwed as well
Feb 02 19:03:06 <karki_> and the userspace API's can start only after there is some sort of a driver
Feb 02 19:03:11 <Abhishek_> what I'm thinking right now is that I am looking at the complete problem from a kernel developer perspective, while karki_ and alexanderhiam are from the front-end levels
Feb 02 19:03:33 <Abhishek_> We need both these perspectives to complement each other
Feb 02 19:04:18 <karki_> Abhishek_ : thats because we need the kernel driver to solve some problems for us. So first look at what we want to solve, then decide what the driver should have.
Feb 02 19:05:23 <karki_> The thing is if we have effective data communications and RPCs built in, then we don't need to write custom drivers at all
Feb 02 19:05:24 <Abhishek_> The kernel driver becomes an API in itself as well, and has to play by the rules of the kernel developers. Else this solution won't make it into the mainline
Feb 02 19:05:29 <karki_> atleast in most cases
Feb 02 19:06:15 <karki_> There is absolutely no point getting a kernel driver into the mainline if it does not solve our purpose.
Feb 02 19:06:25 <alexanderhiam> I would love something like this: 'cat /path/to/pru_rpc' prints 'setSpeed(motor_speed)' and then 'echo > "setSpeed(100)" > path/to/pru_rpc'. That's all PRU firmware/kernel driver work. The userspace side would just be trivial examples using that interface
Feb 02 19:06:44 <karki_> once we know what we need, we can implement it in a way it can be moved into mainline
Feb 02 19:07:52 <Abhishek_> I think this is the point we disagree on. While you would like to develop it first and move it into the mainline. I would like to develop a mainline-friendly solution from the beginning
Feb 02 19:08:12 <karki_> uuh, no
Feb 02 19:08:22 <karki_> I never said anything about developing first
Feb 02 19:08:33 <karki_> I'm talking about designing what we need it to do
Feb 02 19:08:45 <karki_> then develop it in a way that will take it  to LKML
Feb 02 19:09:08 <karki_> no point worrying about how to develop if we don't know what to develop
Feb 02 19:09:29 <karki_> yes, so even  I would like to develop a mainline-friendly solution from the beginning
Feb 02 19:09:32 <Abhishek_> I see
Feb 02 19:10:03 <karki_> but decide on what the mainline friendly driver should do first :)
Feb 02 19:10:16 <karki_> I'm not even talking about implementation yet
Feb 02 19:11:17 <karki_> alexanderhiam, what you said has more to do with the PRU firmware than driver, right?
Feb 02 19:11:38 <karki_> or do you want the kernel to support RPC out of the box
Feb 02 19:11:42 <karki_> ?
Feb 02 19:12:17 <alexanderhiam> hmm...
Feb 02 19:12:37 <Abhishek_> (i) Starting with the PRU firmware
Feb 02 19:13:02 <Abhishek_> Remember some syscall files which we had to include?
Feb 02 19:13:11 <karki_> yeah
Feb 02 19:13:46 <karki_> alexanderhiam : All botspeak commands are essentially RPC's
Feb 02 19:14:14 <karki_> when you "echo SET DIO[0], 1", it is internally calling a function
Feb 02 19:14:34 <karki_> more like the callback dio_handler()
Feb 02 19:14:44 <karki_> along with supplying the arguments
Feb 02 19:15:01 <karki_> so it's more or less what you want, just a different form factor
Feb 02 19:15:04 <alexanderhiam> right, the difference is I'm imagining an API to let you easily define and register your own callable functoins
Feb 02 19:15:42 <alexanderhiam> which could probably be built on top of / into pruspeak
Feb 02 19:15:51 <karki_> exactly :)
Feb 02 19:15:58 <Abhishek_> I could add something like "Software defined peripherals"
Feb 02 19:16:15 <karki_> and for PRUspeak to be robust, I need this pru-bridge
Feb 02 19:16:30 <karki_> or rather a standard remote-proc driver
Feb 02 19:16:50 <karki_> Abhishek_ : could you explain a bit more?
Feb 02 19:17:15 <Abhishek_> something like set a few registers and go, and the PRU clocks out a bitstream
Feb 02 19:17:34 <Abhishek_> this is a very high level use case
Feb 02 19:17:57 <Abhishek_> these registers can be located in shared memory or manipulated using sysfs entries
Feb 02 19:18:11 <karki_> thats an addon planned for pruspeak
Feb 02 19:18:31 <karki_> so the firmware on pru1 is supposed to handle all this
Feb 02 19:18:58 <karki_> eg. have chunk of data to be written via soft uart
Feb 02 19:19:16 <karki_> pru0 gets the botspeak commanf
Feb 02 19:19:30 <karki_> the shared memory area is pre defined
Feb 02 19:19:57 <karki_> pru0 tells pru1 that 'x' amt of data exists at 'y' loc
Feb 02 19:20:03 <karki_> pru1 does the magic
Feb 02 19:20:09 <karki_> as you said
Feb 02 19:20:19 <karki_> by setting a few registers in b/w
Feb 02 19:20:23 <Abhishek_> I see
Feb 02 19:20:29 <karki_> (thats how pru0 and pru1 communicate
Feb 02 19:20:43 <karki_> pru0 is the actual pruspeak firmware
Feb 02 19:20:49 <karki_> pru1 is changable
Feb 02 19:21:06 <karki_> i.e. pru1_pwm gives you 8 channel soft pwm
Feb 02 19:21:23 <karki_> or pru1_uart gives you bit banged soft serial port
Feb 02 19:21:25 <karki_> et
Feb 02 19:21:28 <karki_> *etc
Feb 02 19:21:43 <karki_> so pru0 is the high level interface
Feb 02 19:21:48 <karki_> I wanted to do all that
Feb 02 19:21:59 <karki_> but first thing is to cleanup the kernel driver
Feb 02 19:22:24 <karki_> I guess same case for you
Feb 02 19:22:35 <karki_> waiting to clean up stuff and push to LKML
Feb 02 19:23:50 <karki_> okay, I have to sleep now.
Feb 02 19:24:06 * karki_ 's batteries are low :(
Feb 02 19:24:19 * karki_ zzz..... zzz.....
Feb 02 19:24:28 <karki_> we'll continue discussion tomorrow
Feb 02 19:24:50 <Abhishek_> sure
Feb 02 19:24:52 <Abhishek_> g'night
Feb 02 19:25:33 <alexanderhiam> gn
Feb 02 19:36:28 <Abhishek_> I didn't just want to restrict the concept to the BotSpeak language though. The user could write his own firmware for the PRU pretty quickly using the same framework and develop it alongside the userspace framework
Feb 02 19:40:13 <alexanderhiam> I was thinking the same thing
Feb 02 19:41:14 <Abhishek_> It will be very interesting to see how we bring this thing up
Feb 02 19:41:20 <alexanderhiam> pruspeak could run on top of said framework
Feb 02 19:41:44 <Abhishek_> looking forward to jkridner to add his views to what we've said so far
Feb 02 19:42:19 <alexanderhiam> yeah, I'm really liking this idea, but it certainly needs some refining
Feb 02 19:45:06 <Abhishek_> yup
Feb 02 20:00:59 <Abhishek_> rcn-ee: I'm unable to compile newer versions of sigrok on the Bone as the glib version requirement has been bumped from the version already bundled in wheezy images
Feb 02 20:01:49 <Abhishek_> Could you suggest a way I could distribute the latest version of sigrok on the newer Bone images?
Feb 02 20:02:28 <rcn-ee> Best thing to do is probally upgrade to the Jessie image, and install the 3.8 kernel...
Feb 02 20:04:45 <rcn-ee> Abhishek_, in about a week, we will have the final "wheezy" image, ship it off, and then only focus on Jessie. ;)
Feb 02 20:08:02 <alexanderhiam> rcn-ee: the wheezy image will ship with 3.8?
Feb 02 20:09:01 <rcn-ee> The wheezy image will still only have 3.8.... Jessie.. both 3.8/3.14 will be installed.....
Feb 02 20:09:40 <alexanderhiam> ok thanks
Feb 02 20:10:23 <rcn-ee> We weren't going to sneak a big kernel upgrade into wheezy and be done with it...  It's basicly a roll up all fixes with the 3.8 kernel..  Should be nice and stable...
Feb 02 20:10:37 <rcn-ee> (over the May 2014 release)
Feb 02 20:12:11 <alexanderhiam> awesome
Feb 02 20:20:41 <Abhishek_> I was planning a "BeagleLogic edition" image, which would ship with HDMI disabled and all the BeagleLogic and sigrok niceties installed
Feb 02 20:21:07 <Abhishek_> and configured, ready to go
Feb 02 20:22:21 <Abhishek_> although there are some cleanups I would need to do to that end, but what would be a good time to coincide this image with your (rcn-ee) release schedule?
Feb 02 20:27:17 <rcn-ee> So the build will be fired off this up-coming sunday.. (I'll actually be gone on a vacation) Jason has a few bone101 changes he wants to push this week.. So there's not a whole lot of chagnes going to happen this week. ;)
Feb 02 22:17:24 <ds2> hmmm
Feb 03 01:01:42 <Abhishek_> hi jkridner
**** ENDING LOGGING AT Tue Feb 03 02:59:58 2015