**** BEGIN LOGGING AT Mon May 12 02:59:59 2014
May 12 06:34:41 <Abhishek_> karki: How many exams left?
May 12 06:54:09 <karki> 2 exams. + 4 pracs
May 12 06:54:50 <vvu|Log> when do you finish karki ?
May 12 07:37:30 <Abhishek_> mranostay: Is the "new" kernel the one by Koen Kooi you mention in your lighting example?
May 12 07:57:58 <karki> vvu|Log : theory finishes by 15th, pracs are going to eat into the first week of GSoC (20th, 22nd and 24th - So I won't be working those three days of the week)
May 12 07:58:31 * vvu|Log is feeling so bad everybody finishes before him exams :(
May 12 08:01:41 * karki consoles vvu|Log
May 12 08:23:35 * Abhishek_ just realised that VLC Media Player can also record screencasts!
May 12 12:21:00 <Abhishek_> morning
May 12 12:35:03 <vvu|Log> Abhishek_: what GMT are you ?
May 12 12:35:38 <Abhishek_> That's UGT. I'm on +0700.
May 12 13:28:34 <praveendath92> vvu|Log: Zello !
May 12 13:43:12 <vvu|Log> praveendath92: hello there
May 12 13:43:25 <praveendath92> Yep :)
May 12 13:44:00 <vvu|Log> how is it going ?
May 12 13:44:20 <praveendath92> It's going good.
May 12 13:44:49 <praveendath92> Too much travel actually. From tomorrow I will start with coding.
May 12 13:44:57 <praveendath92> Did you get my updates ?
May 12 13:45:01 <praveendath92> About the video ?
May 12 13:45:07 <vvu|Log> yep, really good the video
May 12 13:45:13 <vvu|Log> just looked 2 days ago or when u pinged
May 12 13:46:00 <praveendath92> Hmm. I had to apply noise reduction for audio.
May 12 13:46:21 <vvu|Log> good enough, it is understandable
May 12 13:46:45 <Abhishek_> I could sense that from the audio, it was too clean to be recorded from a laptop actually ;)
May 12 13:46:55 <praveendath92> :) When will the boards reach us ?
May 12 13:47:05 <vvu|Log> have no clue here
May 12 13:47:08 <vvu|Log> ping jkridner about that
May 12 13:47:14 <praveendath92> Yeah. I thought the initial quality is just fine.
May 12 13:47:27 <Abhishek_> Audacity?
May 12 13:47:29 <jkridner> In India, boards are expected later this week.
May 12 13:47:38 <praveendath92> But vmayoral set the bar too high ;)
May 12 13:47:50 <praveendath92> Abhishek_: yep.
May 12 13:47:59 <praveendath92> jkridner: that's good news :)
May 12 13:48:31 <praveendath92> I have a board but it's a friend's board and everyone is leaving.
May 12 13:48:36 <karki> jkridner : when is the revision C coming ;)
May 12 13:48:48 <jkridner> now.
May 12 13:49:11 <Abhishek_> jkridner: The PRU compiler 2.0.0B2 breaks a lot of existing code, mranostay's and panto's code no longer compiles
May 12 13:49:40 <Abhishek_> I guess your pruduino example won't too
May 12 13:50:13 <karki> pruduino is a virtual repo.... (or so I thought)
May 12 13:50:28 <karki> There isn't any implementation...
May 12 13:51:38 <praveendath92> vvu|Log: As a start I will get back on to the module for setting BB into ADK mode.
May 12 13:51:40 <karki> jkridner : I should be done with my video in a couple of hours, just want to check that PRU Speak is an ok name for my project, right?
May 12 13:52:09 <praveendath92> Need to pick up work done during proposal days.
May 12 14:02:59 <jkridner> karki: not "BotSpeak for PRU"?
May 12 14:03:10 <jkridner> karki: check out http://botspeak.org?
May 12 14:18:21 <karki> jkridner : I have checked out the website :) and about the project name, I thought I'd go for something short, and PRUSpeak seemed nice.
May 12 14:19:19 <karki> jkridner : do you have a problem with PRU Speak? My presentation actually goes like "PRU Speak - BotSpeak for the BBB PRU"
May 12 14:19:44 <karki> but for the repo name I wanted something short.
May 12 14:20:10 <jkridner> k.
May 12 14:20:16 * jkridner isn't a fan of "BBB"
May 12 14:20:28 <jkridner> doesn't show up in search terms well. :-)
May 12 14:21:52 <Abhishek_> Some one pointed me out that PRU applies to both BB(W) and BBB so it's better to call the thing AM335x PRU
May 12 14:21:55 <mranostay> jkridner: PRU_C_DIR <-- B2 not using that anymore?
May 12 14:22:23 <jkridner> mranostay: I'd think it'd be using something like that, if not that.
May 12 14:22:31 <jkridner> anything in the release notes?
May 12 14:22:50 <Abhishek_> https://gist.github.com/abhishek-kakkar/9b5f6bc58f1d0c86b7cb
May 12 14:25:35 <Abhishek_> Mysterious that the README to B2 ^ hasn't been bumped and still reads 2.0.0B1
May 12 14:48:53 <karki> alexanderhiam : hello!
May 12 14:48:58 <alexanderhiam> hey
May 12 14:49:09 <karki> hows PyBBIO going?
May 12 14:50:06 <alexanderhiam> going good, rseethamraju is woring on moving the file IO code to C extensions to speed things up a bit
May 12 14:50:26 <alexanderhiam> I think SPI will be next
May 12 14:51:18 <karki> Great! targeting C bindings for PWM as a part of GSoC?
May 12 14:52:42 <alexanderhiam> I actually ditched mmap altogether recently, so we're doing C bindings for kernel drivers for all IO
May 12 14:53:15 <karki> sysfs?
May 12 14:53:22 <alexanderhiam> yeah
May 12 14:54:02 <alexanderhiam> and reading and writing files is sloooooow in Python
May 12 14:54:36 <karki> you mean the normal read and write functions?
May 12 14:55:24 <alexanderhiam> yeah, much quicker to open-read-close or open-write-closed all in a compiled C extension
May 12 14:55:58 * karki wonders how open-read-write is implemented in python!
May 12 14:56:20 <karki> I had a couple of doubts related to my project, particularly related to device driver related
May 12 14:56:36 <karki> ^ignore the last word
May 12 14:56:39 <alexanderhiam> oh?
May 12 14:57:12 <alexanderhiam> oh right, you mean what we were talking about with the beaglepilot stuff?
May 12 14:57:54 <karki> yeah, that day with the uio and sys events and stuff
May 12 14:58:15 <karki> but my doubt is far away from beagle pilot today!
May 12 14:58:19 <alexanderhiam> what's the concern?
May 12 14:59:15 <karki> see after some chat with panto, I figured that the remote proc driver does not have a sys call interface that can be accessed from the user space on linux
May 12 14:59:49 <karki> So I spent the day reading about kernel modules and basics of drivers
May 12 15:00:18 <alexanderhiam> wait, what do you mean ny sys call?
May 12 15:00:55 <alexanderhiam> by*
May 12 15:01:10 <karki> open - close - write etc.
May 12 15:01:35 <alexanderhiam> oh, to sysfs drivers?
May 12 15:03:00 <karki> the thing is I'm not sure what I'm dealing with here.... this is what I do know :
May 12 15:03:35 <karki> 1. device nodes are created with the help of mknod
May 12 15:03:59 <karki> the /dev/mydevice is associated with a major number
May 12 15:05:18 <karki> the driver responsible exposes the sys call interface, so that I can access the vfs entry of the device as I would access a normal file (as in the same open, close, read, write ... and whatever the driver chooses to support!)
May 12 15:05:52 * karki 's knowledge on device drivers is limited :(
May 12 15:06:31 <karki> alexanderhiam : Implementation wise, I don't really know where sysfs fits in!
May 12 15:07:55 <alexanderhiam> well the question is how will the PRU control the IO. If it's through the kernel drivers then I think there are two options:
May 12 15:08:36 <alexanderhiam> A. it sends a signal through virtio to the user space side, which then accesses the driver through sysfs or similar
May 12 15:09:13 <Abhishek_> karki: If BotSpeak needs to do SPI, would the PRU bitbang the SPI, correct?
May 12 15:09:31 <Abhishek_> *omit would
May 12 15:09:55 <alexanderhiam> right, that's the other way
May 12 15:10:10 <alexanderhiam> ignore the kernel drivers all together
May 12 15:11:39 <karki> alexanderhiam : the kernel drivers don't really come into play  unless there is communication between ARM and PRU
May 12 15:12:05 <karki> so if the PRU uses a peripheral, then it ought to be mentioned in the device tree
May 12 15:12:20 <alexanderhiam> right
May 12 15:12:25 <karki> Abhishek_ : yes, looks like that
May 12 15:12:45 <Abhishek_> okay, does it mean that if I wanna do SPI, the PRU accesses the SPI peripheral by itself or bitbanging SPI over the PRU?
May 12 15:13:16 <alexanderhiam> no bitbanging!
May 12 15:13:17 <karki> Abhishek_ : I don't think the PRU has access to the SPI (ocp)
May 12 15:13:46 <alexanderhiam> the question is how does it access the SPI module in a way that doesn't screw up the kernel drivers
May 12 15:13:55 * Abhishek_ opens the Bible to check
May 12 15:14:13 <karki> that should be the work of the device tree ;)
May 12 15:14:38 <karki> Abhishek_ : never mind, I think that the PRU can access any ocp
May 12 15:14:52 <karki> check the global memory map
May 12 15:15:09 <alexanderhiam> that's right
May 12 15:15:58 <alexanderhiam> karki: have you talked to panto about this?
May 12 15:16:10 <karki> To this detail : no
May 12 15:16:28 <karki> I wanted to, but couldn't catch him for the past two days
May 12 15:17:28 <alexanderhiam> yeah, he's probably the one to talk to about how to keep the kernel drivers happy
May 12 15:17:59 <karki> Till now panto was helping me figure out the current resources available. So we talked about what we needed. and that is a 'user space to kernel to pru bridge'
May 12 15:18:10 <karki> never talked about how to go about it!
May 12 15:18:22 * karki is freaking out!!
May 12 15:18:43 <alexanderhiam> don't freak out, we're not even to the first week of coding yet!
May 12 15:18:59 <alexanderhiam> Isn't that going to be through virtio?
May 12 15:19:59 <karki> Kernel<--> PRU could be virtio, but that still leaves me with the problem of figuring out user land <--> kernel space
May 12 15:20:20 <alexanderhiam> you could use that virtio virtual serial port, that doesn't need to be very fast right?
May 12 15:20:44 <Abhishek_> like ranostay's lighting example?
May 12 15:20:55 <alexanderhiam> yeah
May 12 15:21:24 <karki> what exactly is the "virtio virtual serial port"? I saw mranostay use it, but panto asked me not to fret about it right now!
May 12 15:21:33 <Abhishek_> I need to figure out the virtual SPI bridge with which it connects to OLA.
May 12 15:21:49 <Abhishek_> karki: I think it's like semihosting
May 12 15:21:58 <karki> semihosting?
May 12 15:22:27 <karki> I recall panto mentioning a serial <--> virtio driver
May 12 15:23:45 <alexanderhiam> karki: it's just some code on the pru side and some code on the kernel side that creates a virtual serial port (/dev/vport0p0)
May 12 15:24:14 <alexanderhiam> the data is passed through two virtio vrings, one for each direction
May 12 15:24:14 <Abhishek_> In STM32 applications (the microcontrollers I worked with), you could implement a virtual COM port over the JTAG debugger connected to the microcontroller, wherein the MCU would place a string it wants to display in some part of the memory and signal the debugger to pick it up and then, well you should get the idea
May 12 15:25:05 <Abhishek_> I don't know if the analogy is correct.
May 12 15:25:27 <alexanderhiam> in this case it's just an already written abstraction that makes communication through virtio from user space easy
May 12 15:26:11 <alexanderhiam> Abhishek_: what are you doing with ola?
May 12 15:26:52 <karki> alexanderhiam : so the driver should implement functions such as open, read, write etc so that the minicom can communicate with /dev/vport0p0?
May 12 15:27:57 <alexanderhiam> what do you mean by driver? /dev/vport0p0 would be a file you could write to from user land and that data would be sent to the PRU
May 12 15:28:04 <Abhishek_> Not really OLA, I want to know how that interface (virtual SPI bridge) is connected to the PRU firmware for high speed applications. (m)ranostay mentioed ioctl and syscalls today morning
May 12 15:28:10 <Abhishek_> *mentioned
May 12 15:29:33 <alexanderhiam> Abhishek_: is that virtual SPI bridge to the PRU something that's been done befre?
May 12 15:30:30 <Abhishek_> I do not know yet
May 12 15:33:55 <karki> alexanderhiam : /dev/vport0p0 is a device file, right? so it would have a major number associated with it, which signifies the driver responsible for that dev file. and that device driver should give implementations for open, read, write etc. right?
May 12 15:36:43 <alexanderhiam> but if you use the virtio serial driver that's all taken care of already
May 12 15:37:59 <alexanderhiam> (yes, it will provide the appropriate hooks)
May 12 15:38:05 <karki> :)
May 12 15:38:40 * karki apologizes for being so ignorant about drivers...
May 12 15:39:17 <alexanderhiam> don't apologize!
May 12 15:39:28 <alexanderhiam> you're just learning it now
May 12 15:39:43 * alexanderhiam doesn't know all that much about them himself
May 12 15:42:28 <karki> Thanks alexanderhiam! I'll now have to start reading for my exam tomorrow. [time to pull an all nighter ;) ]
May 12 15:42:47 <alexanderhiam> bummer!
May 12 15:43:24 <karki> G'nite : alexanderhiam , Abhishek_ ; Hello Books ;)
May 12 15:43:38 <alexanderhiam> good luck
May 12 15:43:38 <Abhishek_> all the best karki ;)
May 12 16:15:50 <Abhishek_> ds2: I know you have explained it to me once before, but want to clarify again, Is the number of cycles an SBBO operation from a register on PRU0/1 to DDR take deterministic? It goes through the L3F interconnect, correct?
May 12 17:10:53 <ds2> *yawn*
May 12 17:39:19 <Abhishek_> ds2: I just sent a mail
May 12 17:41:02 <ds2> Abhishek_: saw that... short answer is DDR accesses are best effort
May 12 17:41:09 <ds2> it may take a LONG LONG LONG LONG time
May 12 17:41:31 <ds2> even local SRAM access is not completely single cycle...
May 12 17:41:46 <ds2> it is like 1 cycle per 32bit word something along those lines. this is in the manual
May 12 17:42:54 <Abhishek_> 1 extra cycle?
May 12 17:44:51 <ds2> I think so
May 12 17:44:59 <ds2> let me spend 2 minutes to see if I can find that section
May 12 17:52:36 <panto> anything out to DDR is not deterministic
May 12 17:52:54 <panto> even the L3F interconnect can incur cycle stalls IIRC
May 12 17:53:02 <panto> so plan for them
May 12 17:54:16 <Abhishek_> if there's no stall (best case), how much time an SBBO R31.w0, Rx, 0, 2 would take to complete? (Rx = address in DDR RAM)
May 12 17:54:42 <ds2> arrgg
May 12 17:54:49 <ds2> can't find it
May 12 17:54:55 <ds2> yeah... what he said :D
May 12 17:58:17 <Abhishek_> panto: is that (L3F stalls part) given in the AM335x reference manual? I would like to refer to that part
May 12 18:29:19 <Abhishek_> G'night
May 12 18:31:59 <Abhishek_> mranostay: one question before I leave, in your lighting example, you mention BB-BONE-PRU-05 but I can only find till BB-BONE-PRU-04 in github/beagleboard/linux tree
May 12 18:32:22 <Abhishek_> where's the overlay for the last one?
May 12 18:33:57 <alexanderhiam> Abhishek_: I was just looking at that: https://github.com/koenkooi/kernel/blob/3.8/patches/capes/0022-Add-PRU-DTS-for-lighting-cape.patch
May 12 18:34:28 <Abhishek_> thanks alexanderhiam!
May 12 18:34:47 <alexanderhiam> no prob
May 12 18:37:38 <Abhishek_> alexanderhiam: look here: https://github.com/koenkooi/kernel/blob/3.8/patches/capes/0021-remoteproc-PRU-lighting-remoteproc-support.patch , the SPI virtual device and ioctls to be found here
May 12 18:39:13 <alexanderhiam> nice
May 12 19:13:06 <mranostay> seems i need update the codes for my lighting stuff.. damn TI
**** ENDING LOGGING AT Tue May 13 02:59:59 2014