**** BEGIN LOGGING AT Mon Apr 28 02:59:59 2014
Apr 28 03:05:49 <karki> sidbh : ping :)
Apr 28 03:08:43 <karki> alexanderhiam : ping
Apr 28 03:20:16 <karki> sidbh : how big was the download when you ran patch.sh on koen's kernel?
Apr 28 03:20:41 <karki> mines running to approx 2GB!!!
Apr 28 03:44:12 <karki> mranostay : do I have to recompile whole of koen's kernel and boot the BBB with that or is there some way to update the angstrom image I'm already using?
Apr 28 03:51:56 <sidbh> karki: pong
Apr 28 03:55:32 <sidbh> karki: why are you using angstrom not debian :)
Apr 28 03:58:16 <karki> sidbh : had quite a few tools installed on angstrom, so didn't change to debian!
Apr 28 03:58:28 <sidbh> karki: i guess "opkg update" and "opkg upgrade" to be used to upgrade already installed angstrom
Apr 28 03:58:58 <karki> sidbh : how did you go about getting koen's kernel?
Apr 28 04:00:15 <karki> or did debian already have all the new drivers?
Apr 28 04:00:52 <sidbh> karki: which drivers you need?
Apr 28 04:01:40 <karki> remote proc for mranostay 's example
Apr 28 04:01:47 <karki> and panto 's example too
Apr 28 04:03:07 <sidbh> any kernel i guess with 3.8 + has it i guess.
Apr 28 04:03:17 <sidbh> what version are you running now
Apr 28 04:03:30 <karki> 3.8.something
Apr 28 04:03:53 <karki> sidbh : so you didn't bother with getting koen's kernel
Apr 28 04:03:55 <karki> ?
Apr 28 04:05:34 <karki> because I thought the new drivers were still not in the mainline ( I doubt they are - the last modification for remote proc pru was 19 days ago by panto )
Apr 28 04:05:48 <sidbh> it should work i have tried running PRU+uio with angstrom img, it works fine after that i made transition to debian img
Apr 28 04:06:21 <karki> yeah, UIO works. I just don't understand remote proc :p
Apr 28 04:06:33 <sidbh> PRU+rproc works fine under debian as far as i have tested
Apr 28 04:09:12 <sidbh> I recommend you to shift to debian asap, it is better than angstrom :)
Apr 28 04:09:30 <karki> sidbh : affirmative ;)
Apr 28 04:11:55 <sidbh> karki: have you received the PRU compiler from jkridner
Apr 28 04:12:14 <karki> sidbh : yes
Apr 28 04:12:25 <sidbh> which version
Apr 28 04:12:35 <karki> sidbh : http://beagleboard.org/latest-images/ right? the eMMC flasher
Apr 28 04:13:30 <karki> sidbh : jason gave me a link which gave me a list of images to download. don't remember the version!
Apr 28 04:13:49 <sidbh> yeah, use SD card one
Apr 28 04:14:42 <sidbh> more flexible when you are playing rough, easy to reformat and make changes
Apr 28 04:14:58 <karki> so you didn't try the flasher?
Apr 28 04:15:07 <karki> so first option, right?
Apr 28 04:15:27 <sidbh> right
Apr 28 04:17:00 <sidbh> karki: version of PRU compiler is imp panto and mranostay's work won't compile in 1.1.0B1+
Apr 28 04:19:00 <karki> I know. but I didn't compile it yet. still trying to figure out how remote proc and virt io works!
Apr 28 04:19:39 <sidbh> cool
Apr 28 04:19:41 <karki> and i have a list of versions, so thats no problem. I'll pick out the ones that work.
Apr 28 04:20:08 <karki> I'll most probably try compiling tomorrow or day after. will keep you updated.
Apr 28 04:21:00 <sidbh> ok great
Apr 28 04:21:19 <sidbh> i have to run now see u later
Apr 28 06:07:34 <sidbh> panto: ping
Apr 28 07:06:18 <panto> morning
Apr 28 08:34:34 <karki> panto : ping :)
Apr 28 08:36:13 <karki> panto : is there a user space interface to remoteproc driver? or can the remote proc functions be called only from other parts of the kernel?
Apr 28 09:54:26 <panto> karki, pong
Apr 28 09:54:39 <panto> karki, remote proc is a kernel interface
Apr 28 09:54:43 <panto> that's what you need to do
Apr 28 10:07:40 <karki> panto : how would I go about it? where do I look. I haven't dived deep into the kernel before!
Apr 28 10:09:48 <karki> panto : If I have to expose an user space interface, is it not like developing a dev driver?
Apr 28 10:33:28 <panto> karki, it's not as simple as a 'driver'
Apr 28 10:33:37 <panto> you have to think what you want to achieve first
Apr 28 10:33:49 <panto> the driver is an implementation detail
Apr 28 10:40:30 <karki> how have you loaded the code in your example?
Apr 28 10:50:33 <karki> how come you used remote proc without any userspace interface?
Apr 28 11:17:45 <panto> karki, cause I use it as a kernel interface
Apr 28 11:17:58 <panto> the example provides a number of pwm channels as a standard pwm driver
Apr 28 11:18:13 <panto> the pwm driver class has a standard pwm interface
Apr 28 11:18:47 <karki> how did you load the firmware on the PRU?
Apr 28 11:19:37 <karki> okay! it behaved like a driver, a pwm driver ?
Apr 28 11:20:35 <panto> yes
Apr 28 11:20:58 <panto> the PRU dts fragment just contains the name of the firmware file to load
Apr 28 11:21:05 <panto> karki, yes
Apr 28 11:21:21 <karki> Ah! Thanks :)
Apr 28 11:22:37 <karki> panto : this is where the driver is, right? 3.8/drivers/remoteproc/pru_rproc.c
Apr 28 11:22:43 <panto> yes
Apr 28 11:23:16 <karki> Good. looks like I was going through the right piece of code!
Apr 28 11:23:27 <panto> that's always helpful
Apr 28 11:42:18 <karki> panto : I haven't done any driver programming before. will that be too big a problem or can I whatever is required quickly? [In a week]
Apr 28 11:58:08 <panto> err, no
Apr 28 11:58:11 <panto> a week is not enough
Apr 28 11:58:30 <panto> why do you need to do it in a week?
Apr 28 12:04:01 <karki> I wasn't talking about the development of the software itself, but rather learning the prerequisites in a week
Apr 28 12:04:41 <panto> you can't 'learn' whatever you need before hand
Apr 28 12:04:46 <panto> just dive in
Apr 28 12:04:53 <panto> if you get stuck you can always ask
Apr 28 12:05:08 <karki> okay :)
Apr 28 12:08:35 <karki> panto : one more thing. Why is remote proc better than UIO?
Apr 28 12:09:21 <karki> mranostay said it was more transparent (and sexier). what exactly is transparent?
Apr 28 12:11:11 <panto> remote proc is the preferred kernel interface for attaching supplementary processors
Apr 28 12:11:39 <panto> UIO sort-of-works
Apr 28 12:12:21 <panto> so it's the difference between a prototyping implementation and a real production ready one
Apr 28 12:12:47 <panto> for instance UIO doesn't handle data consistency at all
Apr 28 12:13:06 <panto> if you have a shared memory area you can't reliably use it for communication
Apr 28 12:15:22 <Abhishek_> morning
Apr 28 12:15:33 <karki> panto : data consistency in what sense?
Apr 28 12:15:49 <karki> like race conditions ?
Apr 28 12:16:03 <karki> or something else?
Apr 28 12:18:01 <panto> the PRU and the ARM are capable of accessing the same memory areas
Apr 28 12:18:10 <panto> but that doesn't take into account the caches of the ARM
Apr 28 12:18:48 <panto> so even though user-space might access some memory area, without explicit cache management instructions, those changes are not visible to the PRU
Apr 28 12:19:09 <panto> on the flip-side, changes from the PRU will not be reflected in the ARM cache contents
Apr 28 12:21:22 <karki> I see. problems with stale data.
Apr 28 12:59:12 <DiegoTc> hi ds2
Apr 28 12:59:16 <DiegoTc> hi dschelt
Apr 28 12:59:24 <dschelt> hello DiegoTc
Apr 28 12:59:40 <Abhishek_> morning dschelt
Apr 28 12:59:48 <Abhishek_> morning DiegoTc
Apr 28 12:59:50 <dschelt> morning Abhishek_
Apr 28 13:00:10 <DiegoTc> morning guys :)
Apr 28 13:00:18 <DiegoTc> Abhishek_: did you did the elinux wiki?
Apr 28 13:00:43 <Abhishek_> I have not filled it in completely
Apr 28 13:01:04 <Abhishek_> uploading video after 1st May
Apr 28 13:01:41 <DiegoTc> Abhishek_: checking site and noticed there's information
Apr 28 13:01:42 <DiegoTc> http://elinux.org/BeagleBoard/GSoC/2014_Projects
Apr 28 13:02:07 <Abhishek_> yes, that has been filled in by default using our proposal data
Apr 28 13:02:51 <karki> alexanderhiam : ping!
Apr 28 13:04:21 <DiegoTc> dschelt: di you read Jason idea about the "card idea"
Apr 28 13:33:41 <DiegoTc> Hi VoltVisionSteve
Apr 28 13:34:13 <VoltVisionSteve> DiegoTc, Good morning!
Apr 28 13:36:12 <DiegoTc> Morning VoltVisionSteve, I worked yesterday on the htm template
Apr 28 13:36:32 <DiegoTc> Send an email, today I will check well the books, to add more tutorials
Apr 28 13:37:02 <DiegoTc> have to edit the CSS, is to pinky :p
Apr 28 13:39:59 <VoltVisionSteve> DiegoTc, sounds great.  I am going through emails now.  Let me know if there is anything urgent you would like to talk about...otherwise, look for my email response soon.
Apr 28 13:40:07 <VoltVisionSteve> Thx!
Apr 28 13:40:37 <DiegoTc> not really just informing. I'm going to wait :)
Apr 28 13:46:24 <VoltVisionSteve> DiegoTc, did you update the hardware requirements for the tutorials?  I know we are still "building the list"...so lets have you and I go back and forth on different tutorial ideas.  The sooner we get the hardware list to jkridner, the better.
Apr 28 13:46:42 <VoltVisionSteve> Did you see my recent updates to the list?
Apr 28 13:47:36 <karki> panto : how do upcalls and down calls work? (I know what they are, but how exactly do they work? )
Apr 28 13:48:15 <panto> the both work by trapping
Apr 28 13:48:22 <karki> panto : I could not find many online resources for upcall/downcall stuff.
Apr 28 13:48:29 <panto> cause there isn't any
Apr 28 13:49:10 <karki> okay, so ARM --INT --> PRU is a downcall and vie versa is a upcall?
Apr 28 13:49:24 <panto> on a downcall the ARM sends a signal that it want to call, the PRU acknowledges and halts
Apr 28 13:50:06 <panto> the ARM picks up the trap, configures registers as if a normal PRU function call was done, and releases the PRU to execute
Apr 28 13:50:34 <panto> on return from the function call, another trap is taken, and the ARM picks up the return value
Apr 28 13:50:50 <panto> the upcall is similar,
Apr 28 13:53:10 <karki> panto : I didn't quite understand the "ARM picks up the trap" part.
Apr 28 13:55:12 <panto> the ARM decodes the register contents and the trapping instruction and converts it to a function on the host to call
Apr 28 13:59:40 <DiegoTc> VoltVisionSteve: I saw what you add
Apr 28 13:59:45 <DiegoTc> I haven't update the list
Apr 28 13:59:53 <DiegoTc> no permission to view the spreadsheet
Apr 28 14:08:22 <karki> panto : got it :D (or so I think)
Apr 28 14:08:54 <VoltVisionSteve> DiegoTc, I am referring to the GoogleDoc that you shared with me.  We have a working list of tutorial ideas...then on the same page, we should have a list of hardware ideas that we need.
Apr 28 14:09:28 <VoltVisionSteve> ...once we all agree on the list, then jkridner can put the info into his official system.
Apr 28 14:09:56 <VoltVisionSteve> ...but first we have to understand each other and agree.
Apr 28 14:12:04 <DiegoTc> ahh ok
Apr 28 14:12:39 <DiegoTc> VoltVisionSteve: I'm going to work on this today. We can talk of this tomorrow.
Apr 28 14:12:44 <DiegoTc> what do you think?
Apr 28 14:14:25 <alexanderhiam> hi karki
Apr 28 14:18:14 <karki> alexanderhiam : hi :) I'll be back in a 15 min (dinner time ;) )
Apr 28 14:18:41 <VoltVisionSteve> DiegoTc, Sounds great!  Also, did we ever setup a weekly meeting with you and the mentors?  I did this with my other team (PyBBIO).  We are meeting every Tue.
Apr 28 14:22:40 <DiegoTc> VoltVisionSteve: that sounds cool. I can on g+ from 19:00 your time location or IRC anytime
Apr 28 14:23:20 <DiegoTc> I don't if you and the mentors can at that hour?
Apr 28 14:29:12 <VoltVisionSteve> DiegoTc, next time I talk with jkridner I will ask him if he sees value in a weekly meeting.
Apr 28 14:37:50 <DiegoTc> ok
Apr 28 14:38:01 <karki> alexanderhiam : I wanted to know why 35 is written to r31 in the PRU to signal the ARM core
Apr 28 14:38:24 <karki> I went through the PRU INTC doc, but couldn't figure out how that number was got
Apr 28 14:40:29 <karki> the sys event generated is 18. ( but how is this mapped to host interrupt 3 viz PRU_EVTOUT_0 for the ARM )
Apr 28 14:40:30 <alexanderhiam> where's that?
Apr 28 14:40:46 <karki> The last line of almost all PRU codes
Apr 28 14:41:06 <karki> where 19 + 16 is written to r31.b0
Apr 28 14:41:21 <alexanderhiam> oh right, give me a minute...
Apr 28 15:03:56 <alexanderhiam> karki: sorry, had a phone call
Apr 28 15:04:10 <alexanderhiam> got spruh73c handy?
Apr 28 15:05:04 <karki> alexanderhiam : gimme a sec
Apr 28 15:06:34 <karki> alexanderhiam : The arm A8 TRM?
Apr 28 15:06:52 <karki> I have it with me now!
Apr 28 15:07:09 <alexanderhiam> ok, section 4.5.2.2.2
Apr 28 15:07:17 <alexanderhiam> page 244
Apr 28 15:08:15 <karki> yeah!
Apr 28 15:10:13 <alexanderhiam> so if you write a 1 to bit 5 of R31, then then bits 0-4 get mapped to the ARM's INTC interrupts 16-31
Apr 28 15:10:47 <karki> ARM's?
Apr 28 15:11:13 <alexanderhiam> yeah, table 6-1 on page 522
Apr 28 15:11:18 <karki> http://elinux.org/PRUSSv2_Interrupts
Apr 28 15:11:37 <karki> I thought 16-31 was for PRU's INTC itself
Apr 28 15:11:56 <alexanderhiam> yeah
Apr 28 15:12:46 <alexanderhiam> ok that's the right table
Apr 28 15:13:17 <karki> The PRU host 2-9 map to 8 interrupt numbers of the ARM
Apr 28 15:14:28 <alexanderhiam> what docs are you looking at?
Apr 28 15:14:38 <alexanderhiam> I'm way behind on PRU docs
Apr 28 15:14:56 <karki> a lot of them :/ including jasons slides
Apr 28 15:15:11 <karki> http://processors.wiki.ti.com/index.php/PRU_Interrupt_Controller
Apr 28 15:15:20 <karki> This is the old PRU stuff
Apr 28 15:15:32 <karki> but the first half is still valid!
Apr 28 15:18:32 <alexanderhiam> I'm still not entirely sure of the mapping of those interrupts in uio
Apr 28 15:19:18 <karki> it's even been used in mranostay 's code
Apr 28 15:19:27 <karki> mranostay : ping.
Apr 28 15:19:29 <alexanderhiam> oh nevermind, forgot they don't mean anything in uio
Apr 28 15:19:49 <alexanderhiam> you trap them by number: prussdrv_pru_wait_event(PRU_EVTOUT_0);
Apr 28 15:21:07 <alexanderhiam> so when you write (16+19)=0b100011 to R31, that maps to PRU interrupt 0, which line waits for
Apr 28 15:21:20 <alexanderhiam> which that* line waits for
Apr 28 15:22:37 <karki> But how does it map to that interrupt? I don't get that part!
Apr 28 15:22:41 <alexanderhiam> I'm not sure why people (including myself) always start with 19 as the base for the interrupt then add to it, it would make more sense to define PRU0_ARM_INTERRUPT as 1<<5 then OR the interrupt number with it
Apr 28 15:23:03 <karki> exactly what I was thinking
Apr 28 15:23:27 <karki> the interrupt number +15 defines the system event
Apr 28 15:23:48 <karki> in case of 19+16; it is 15+3 ==> sys event 18
Apr 28 15:23:51 <alexanderhiam> +16, 100000 maps to 16
Apr 28 15:24:54 <karki> 100011 - right ?
Apr 28 15:25:07 <karki> oh! yeah
Apr 28 15:25:10 <karki> okay
Apr 28 15:25:43 <karki> I can't believe I wasted so much time on an addition error :(
Apr 28 15:25:49 <alexanderhiam> yeah, sys event 19, which still doesn't seem like it would be PRU_EVTOUT_0 on the uio side...
Apr 28 15:26:39 <alexanderhiam> oh, that's just how uio maps it: http://lxr.free-electrons.com/source/drivers/uio/uio_pruss.c#L46
Apr 28 15:27:14 <alexanderhiam> not sure what 16-18 do
Apr 28 15:41:17 <karki> alexanderhiam : 16-22 are used here
Apr 28 15:41:18 <karki> https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.hp
Apr 28 15:43:08 <alexanderhiam> ok, so they're used for PRU0<->PRU1 interrupts
Apr 28 15:55:29 <karki> alexanderhiam : why is PRU_EVTOUT0 --> 3 again?
Apr 28 15:57:43 <alexanderhiam> I think the idea is when they wrote the PRU uio driver they decided to reserve 0-2 (16-18) for sending interrupts between the PRUs
Apr 28 15:57:46 <karki> also on the PRU side, HOST line 2 maps to ARM INT number 20 and HOST line 9 maps to ARM INT num 27
Apr 28 15:58:10 <karki> oh! so its a uio decision.
Apr 28 15:58:47 <alexanderhiam> I think
Apr 28 16:00:15 <karki> but '3' in itself has no significance for the ARM side, right. All ARM cares about is that INT number 20-27 are from the PRU. will it know which sys event in the PRU is causing the interrupt?
Apr 28 16:00:59 <karki> alexanderhiam : pg 522 TRM : bottom note - pr1_host_intr[0:7] corresponds to Host-2 to Host-9 of the PRUSS INTC.
Apr 28 16:02:39 <alexanderhiam> ah, so not a uio decision then, I guess 16-18 are not mapped to host interrupts
Apr 28 16:37:55 <karki> alexanderhiam : but why is it waiting for '3' to '10' in the UIO code
Apr 28 16:38:12 <karki> should it not be something like 20-27 or something?
Apr 28 16:40:44 <alexanderhiam> that mapping just goes by offset from 16
Apr 28 16:49:58 <karki> alexanderhiam : but that is internal to the PRU, all that the ARM knows is which HOST line did it get the interrupt from (as there is a one is to one mapping between pr1_host_intr[0:7] <---> Host-2 to Host-9 on PRU's INTC )
Apr 28 16:51:22 <karki> eg : sys event 23 can also be mapped to host2, viz pr1_host_intr[0] on ARM.
Apr 28 16:51:47 <karki> mapping can be changes with a few PRU inst.
Apr 28 16:52:03 <karki> so what the ARM should care about is the host line, right >?
Apr 28 17:14:00 <panto> do not mess with the event/irq mappings until you know exactly what you're doing
Apr 28 17:14:20 <panto> use what ever configuration works for now
Apr 28 17:14:26 <panto> cause it's not easy to get it right
Apr 28 17:14:36 <karki> panto : what are the default mappings ?
Apr 28 17:15:15 <karki> are they given anywhere? docs and stuff?
Apr 28 17:15:35 <panto> there are no default mappings
Apr 28 17:15:40 <panto> you have to configure
Apr 28 17:15:47 <panto> but instead of doing it from scratch
Apr 28 17:15:56 <panto> use one of the configs that is known to work
Apr 28 17:18:55 <karki> oh, okay.
Apr 28 17:19:22 <panto> it is not easy to figure those things out
Apr 28 17:20:23 <karki> panto : but for the simple PRU programs where they write 19+16 to r31.b0 to signal the ARM,  I didn't see any configs done. so I thought there was a default mapping!
Apr 28 17:20:50 <karki> panto : I agree with you it's quite irritating to figure it out!
Apr 28 17:25:38 * ds2 chants DMA DMA DMA
Apr 28 17:26:11 * Abhishek_ causes a buffer overrun
Apr 28 17:26:19 <panto> karki, someone, somewhere, configured things
Apr 28 17:26:30 <panto> there's no such thing as a free lunch
Apr 28 17:27:30 <ds2> panto: that's what the people hired at the silicon makers are suppose to do, right? :D
Apr 28 17:31:36 <panto> ds2, rofl
Apr 28 17:36:10 <karki> panto : thanks a lot for your help today! I have a couple more doubts specific to your code - pru_rproc one, I'll ask you tomorrow. I have to prepare for some presentation now.
Apr 28 17:36:48 <karki> alexanderhiam : thanks a lot for helping me figure out most of the interrupt stuff! I'll catch you tomorrow :)
Apr 28 17:37:50 <alexanderhiam> no problem, it was helpful for me too ;)
Apr 28 20:30:49 <bradfa> joel_, to clarify, we'll have mmc meeting at 11am EDT on Wednesdays and main beagle-gsoc meeting at 12pm EDT on Wednesdays, right?
Apr 28 23:13:26 <mranostay> bradfa: speak in the true timezone please
**** ENDING LOGGING AT Tue Apr 29 02:59:58 2014