**** BEGIN LOGGING AT Wed Jul 24 02:59:59 2013
Jul 24 04:43:00 <jj2baile> mmm i have not.
Jul 24 04:46:29 <ds2> have not?
Jul 24 04:47:09 <jj2baile> Built/loaded panto's kernel
Jul 24 04:48:09 <ds2> how is ur project going?
Jul 24 04:55:22 <jj2baile> Its going fine i'd say.
Jul 24 04:55:33 <jj2baile> planning to do the video this week
Jul 24 04:55:49 <ds2> how much further have you gotten beyond reading the ids?
Jul 24 04:57:19 <jj2baile> Well i've done a couple of the other protocol defined instructions, although hardcoded for the launchpad, so the next major step was to generalize the code more.
Jul 24 04:58:31 <jj2baile> Although, due to the way the protocol is defined, it seems you will need to provide the debugger a lot of the information anyway.
Jul 24 04:58:58 <jj2baile> In terms of, the encoding of the different operations, and even the length of the IR.
Jul 24 04:59:48 <ds2> cool
Jul 24 04:59:54 <jj2baile> actually I've considered one way of counting the length of the IR programmatically, but based strictly on the spec it may not be defined.
Jul 24 05:00:24 <jj2baile> the spec just specifies the lower two bits when shifting out from IR, so i take that to mean, the other bits could be whatever, even if typically they are just zero'd
Jul 24 05:00:29 <jj2baile> so that isn't something I think I would rely on.
Jul 24 05:00:32 <ds2> how are you passing info from the PRU back to the ARM?
Jul 24 05:01:28 <jj2baile> I just took the easiest path at the time, which was to just put it in the pru local storage, which can be addressed from the arm chip.
Jul 24 05:01:48 <jj2baile> I will probably need to look at a more sophisticated option later
Jul 24 05:01:50 <ds2> so basically shared memory?
Jul 24 05:02:03 <ds2> is the second half of GSoC the integration with openocd or?
Jul 24 05:02:10 <jj2baile> Yes,  basically.
Jul 24 05:02:30 <jj2baile> figuring out how best to communicate with the openocd side
Jul 24 05:02:57 <jj2baile> and there is actually PRU shared memory which is slightly different, but these spaces are all addressable by the ARM cpu anyways it seems.
Jul 24 05:03:16 <ds2> wow.. this is going smoother then I'd have guessed
Jul 24 05:03:25 <jj2baile> the pru "shared" memory is for use with sharing data between the two prus
Jul 24 05:03:33 <jj2baile> and im pretty sure the ARM chip can address this anyway
Jul 24 05:03:52 <ds2> but their might be penalties for using it?
Jul 24 05:04:36 <jj2baile> Yes, Probably. Although admittedly i have not yet looked at memory access costs from the ARM side.
Jul 24 05:05:02 <ds2> or worse, it causes delays on the PRU side
Jul 24 05:05:13 <jj2baile> hmmm, I did not think about this possibility
Jul 24 05:05:16 <jj2baile> Duly noted.
Jul 24 05:05:42 <jj2baile> however, I just needed it to tell me the results of whatever computation after the fact, so in the specific case of what i was doing, it would be a non-issue i think?
Jul 24 05:06:01 <jj2baile> but when we need to communicate with openocd this is something i should keep in mind
Jul 24 05:06:36 <ds2> well... the access from the ARM is async relative to the PRU pin toggling
Jul 24 05:06:48 <ds2> so if the ARM slows down the PRU, it can mess with the timings on the pin
Jul 24 05:07:21 <jj2baile> Well, I wait for the PRU to trigger an interrupt stating it was done, before the arm went and looked at the results
Jul 24 05:07:42 <ds2> Oh so no pipelining of commands to the PRU?
Jul 24 05:08:04 <jj2baile> Yeah, no, at that point it was just entirely the PRU.
Jul 24 05:08:35 <ds2> I know a lot of this is in the app but things can change over time as you learn more
**** BEGIN LOGGING AT Wed Jul 24 05:28:31 2013
Jul 24 05:46:15 <ka6sox> as you collapse the chain the bit count changes
Jul 24 05:46:37 <ka6sox> so I think we need to pass this from the app to the PRU and then out to the CPLD (if its shifting out)
Jul 24 05:46:49 <ka6sox> if the PRU is shifting then it has to keep count.
Jul 24 07:42:07 <panto> jj2baile, mluckham-away, I've found out that the shared dram in the PRU is not reliable
Jul 24 07:42:16 <panto> you'll have to use shared dram for that
Jul 24 13:22:31 <mluckham-away> panto, you mention shared dram twice
Jul 24 13:22:52 <panto> err, ok, shared dram off the PRUs at first
Jul 24 13:22:59 <panto> standard dram at second
Jul 24 13:24:04 <mluckham-away> shared dram 'between' the PRUs is not reliable, but shared dram between PRU and ARM 'is' reliable?
Jul 24 13:24:21 <panto> yes
Jul 24 13:24:43 <panto> at least that's what I've found out when I put the vring in the shared PRU dram
Jul 24 13:25:18 <mluckham-away> is it a timing/noise thing?
Jul 24 13:28:05 <panto> I have a hunch the arbitration just fails when both ARM + PRUs access the block
Jul 24 13:28:20 <panto> and it was only the ARM writes that failed
Jul 24 13:28:53 <panto> pretty weird, but it is what it is
Jul 24 13:29:48 <mluckham-away> I thought PRUs have their own private dram, between themselves - can ARM access that too?
Jul 24 13:30:26 <panto> yes, obviously
Jul 24 14:37:17 <ka6sox-away> mluckham-away, they are all in the ARM map too...
Jul 24 14:54:38 <mdp> panto, they want you to rely on the previously sekrit scratchpad between prus
Jul 24 14:55:12 <panto> mdp, btw, I totally use the trick accessing the other PRUs pins
Jul 24 14:55:30 <mdp> yeah
Jul 24 14:55:35 <panto> with the added complication that the other PRU might even running (so I stop it)
Jul 24 14:55:45 <mdp> heh
Jul 24 14:55:56 <panto> I don't use the scratchpad yet
Jul 24 14:56:10 <panto> this is the fastest way to do anything
Jul 24 14:56:20 <mdp> yep
Jul 24 14:56:26 <panto> I would appreciate it if you took some time to look at that testpru stuff I did
Jul 24 14:59:40 <mdp> I'm going to try. keep in mind that with my month off..I'm still on this major catch-up thing at work :-/
Jul 24 15:03:15 <ka6sox> I need to re-read that whole section on the scratchpad
Jul 24 15:33:19 <jkridner> gm all
Jul 24 15:33:28 <ka6sox> morning jkridner
Jul 24 15:33:41 <_av500_> gm jkridner
Jul 24 15:33:41 <jkridner> anybody here at oscon?
Jul 24 15:33:49 <_av500_> not me
Jul 24 15:45:16 <mluckham-away> morning jkridner
Jul 24 15:54:03 <ZubairLK> gm
Jul 24 15:55:35 <anujdeshpande> gm jkridner
Jul 24 15:55:44 <tcort> gm
Jul 24 15:56:52 <ZubairLK> general linux kernel question..
Jul 24 15:57:05 <ZubairLK> i have an irq. i want to use wait_interruptible in it. for another irq
Jul 24 15:57:11 <ZubairLK> is this madness or is it possible?
Jul 24 15:57:35 <eFfeM> gm
Jul 24 15:57:39 <ZubairLK> tried last night and got some oops error. went to sleep. havent seen it again.
Jul 24 15:57:55 <vvu> hello !
Jul 24 15:57:57 <jkridner> just a couple minutes from starting up.
Jul 24 15:58:09 <ZubairLK> sorry. it was wait_event_interruptible..
Jul 24 15:58:51 <jkridner> any pre-meeting agenda items to add?  I plan on going around the projects and checking when the last status update was, then checking on communication between mentors/students.
Jul 24 15:59:11 <ZubairLK> time for mentor evaluations.. might be worth mentioning.
Jul 24 15:59:21 <ZubairLK> there was a scary line in the email
Jul 24 15:59:41 <ZubairLK> "Please note that non-submission of a midterm evaluation means you will automatically fail the program."
Jul 24 16:00:07 <mdp> I am at oscon in spirit
Jul 24 16:00:23 <mdp> I support OS
Jul 24 16:00:51 <anujdeshpande> hehe
Jul 24 16:00:56 <bradfa> morning channel
Jul 24 16:01:11 <jj2baile> g'day
Jul 24 16:01:24 <mdp> good afternoon, highly respected bradfa
Jul 24 16:01:28 <hatguy> hello
Jul 24 16:03:08 <bradfa> ZubairLK, probably good to remind folks of midterm eval fill-out requirement at next week's meeting since then they'll be open for use
Jul 24 16:03:13 <jkridner> ZubairLK: very, very good point.  Mid-term evaluations can start being filed July 29 and are due before Aug 2.
Jul 24 16:03:31 <ZubairLK> :)
Jul 24 16:03:49 <ZubairLK> hi gregkh
Jul 24 16:03:54 <jkridner> for those at OSCON, there is a GSoC meet-up tonight, but it seems none of you are here.
Jul 24 16:04:14 <ka6sox> looks like I'll have to hike 1/2 dome just to find signal to file :P
Jul 24 16:04:15 <prpplague> gregkh: hehe, i hope you aren't upset about the "Kurgan" picture.....
Jul 24 16:04:25 * vvu is here, but writing week #5 report :)
Jul 24 16:04:29 <_av500_> we are $here
Jul 24 16:04:33 <gregkh> prpplague: I have no idea what you are talking about.
Jul 24 16:04:34 <jkridner> everyone should be approaching the amount of progress expected by the mid-terms...
Jul 24 16:04:47 <gregkh> ZubairLK: morning.
Jul 24 16:05:08 <jkridner> I want to see no fails!  (which means the work has to be done and the mentors have to be able to reproduce/know-about the work)
Jul 24 16:06:12 <anujdeshpande> sounds good
Jul 24 16:06:14 <jkridner> jj2baile: sorry to pick on you, but I don't think I've seen an update in a while. mind if we start with you?
Jul 24 16:06:48 <vvu> jkridner: week #5 update is on my blog *Sorry for writing them in the middle of the week n+1*
Jul 24 16:07:17 * jkridner reads "Ponderings on JTAG"
Jul 24 16:07:27 <jj2baile> jkridner: no problem
Jul 24 16:07:33 <jj2baile> Yeah I havent done a blog post recently
Jul 24 16:07:39 <jj2baile> I was planning to get the video done within the next couple days
Jul 24 16:07:47 <jj2baile> and then post that on the blog,
Jul 24 16:08:01 <bradfa> jj2baile, jkridner, video is required for midterm?
Jul 24 16:08:05 <jj2baile> I know where i can acquire a video camera now, so that should be fine,
Jul 24 16:08:06 <ZubairLK> *finally not worried about the video*
Jul 24 16:08:08 <jj2baile> bradfa: Oh is it?
Jul 24 16:08:22 <bradfa> jj2baile, I had thought so, jkridner is it?
Jul 24 16:08:29 <jkridner> bradfa: really should be done...  up to primary mentor if it is a requirement.
Jul 24 16:08:40 <bradfa> jkridner, ok
Jul 24 16:08:42 <jkridner> my feeling is that is should be done.
Jul 24 16:08:48 <prpplague> gregkh: https://plus.google.com/108554497183903998785/posts/M72vZ8aY3XW
Jul 24 16:08:57 <jj2baile> Well, I was planning to do it anyway
Jul 24 16:09:07 <jkridner> point is to try to inform people about the project such that more people are engaged during the execution.
Jul 24 16:09:15 <jj2baile> As well, I should probably remember to complete the evaluation.
Jul 24 16:09:31 <jkridner> jj2baile: yeah, not completing the evaluation would be *bad*
Jul 24 16:09:41 <jkridner> ie., not getting paid bad.
Jul 24 16:09:57 <ka6sox> that will happen
Jul 24 16:10:06 <ka6sox> even if I have to drive 100miles
Jul 24 16:10:06 <ZubairLK> *very bad indeed*
Jul 24 16:10:41 <jkridner> jj2baile: are you blocked in any way?
Jul 24 16:10:51 <jj2baile> jkridner: Not currently, no
Jul 24 16:11:15 <gregkh> prpplague: heh, I've been called worse before, no worries :)
Jul 24 16:11:15 <ka6sox> it works for me (his code)
Jul 24 16:11:34 <ka6sox> jkridner, his code is working fine and his instructions are good enough to use
Jul 24 16:11:57 <prpplague> gregkh: going to make it hard to watch you do a presentation now at conferences, hehe
Jul 24 16:12:24 <ka6sox> jkridner, next week is integration with vrings and basic app and thats already in progress
Jul 24 16:12:26 <jkridner> what about the vring integration? is that a show-stopper? are we comfortable this stuff is going to be reusable?
Jul 24 16:12:40 <ZubairLK> gregkh:
Jul 24 16:12:45 <ZubairLK> I'm inside a software triggered irq. but i want to wait_event_interruptible in it. condition is a boolean set by another hw irq of a fifo..
Jul 24 16:12:45 <ka6sox> thats the next step and mluckham and panto have that in hand :0
Jul 24 16:12:49 <ZubairLK> tried last night and got some random oops error. went to sleep. it is possible right?
Jul 24 16:12:50 <ka6sox> :)
Jul 24 16:12:52 <ZubairLK> anyone can answer btw..
Jul 24 16:13:58 <ka6sox> jkridner, both panto and mluckham are working on that with jj2baile
Jul 24 16:14:43 <gregkh> ZubairLK: you can't sleep in an irq, sorry.
Jul 24 16:15:10 <ZubairLK> hmm. i'll move code around then.
Jul 24 16:16:02 <jkridner> k, guess we'll move on to the next student.
Jul 24 16:16:02 <jkridner> anyone seen vmayoral?
Jul 24 16:16:02 <jkridner> koen?
Jul 24 16:16:43 <jkridner> anyone seen Khem Raj?
Jul 24 16:16:50 * jkridner forgets his IRC nick.
Jul 24 16:17:55 * jkridner invites khem #beagle-gsoc
Jul 24 16:18:46 <jkridner> I think vmayoral and koen are communicating well by e-mail, but I'm still seeking them to better engage the rest of the GSoCers.
Jul 24 16:19:20 <jkridner> ping them when you see them. I don't think we waste a whole lot of time here.
Jul 24 16:19:43 * jkridner doesn't like leaving pass/fail to chance.
Jul 24 16:20:28 <jkridner> vvu: thanks for the video
Jul 24 16:20:36 <jkridner> also got videos from anujdeshpande and hatguy recently
Jul 24 16:20:37 <vvu> jkridner: no problem :)
Jul 24 16:20:50 <hatguy> jkridner: are the videos ok?
Jul 24 16:20:53 <ZubairLK> *and me too*
Jul 24 16:21:08 <anujdeshpande> jkridner: apologies for the video quality. will do one again with a better camera
Jul 24 16:21:14 <ZubairLK> *i'm afraid of asking that question hatguy :p*
Jul 24 16:21:26 <hatguy> ZubairLK: hehe
Jul 24 16:21:38 <mdp> hatguy, I liked them ;)
Jul 24 16:21:39 <jkridner> ZubairLK: I thought yours was earlier.
Jul 24 16:21:48 <hatguy> mdp: great! :)
Jul 24 16:21:54 <ZubairLK> jkridner: yup. din receive an ack.
Jul 24 16:22:08 <ZubairLK> oops. did. you uploaded it in the blogpost.
Jul 24 16:22:12 <jkridner> your ack is at http://beagleboard.blogspot.com/ :-)
Jul 24 16:22:12 <ZubairLK> my bad
Jul 24 16:22:21 <jj2baile>  /win 13
Jul 24 16:22:30 <hatguy> jkridner: was cwicks able to use the videos?
Jul 24 16:22:39 * jkridner doesn't know.
Jul 24 16:22:42 <jkridner> all worked for me.
Jul 24 16:22:49 <hatguy> ahh ok great
Jul 24 16:23:17 <anujdeshpande> jkridner: we organized the blogs too
Jul 24 16:23:36 <anujdeshpande> jkridner: we have a getting started page, a functions a libraries supported page and a todo page
Jul 24 16:23:48 <jkridner> anujdeshpande: I use feedly.com to read them.
Jul 24 16:24:02 <anujdeshpande> jkridner: oops. meant wiki
Jul 24 16:24:04 <anujdeshpande> not blogs
Jul 24 16:24:11 <prpplague> jkridner: we are adding a project entry at bugs.elinux.org
Jul 24 16:24:12 <anujdeshpande> jkridner: http://elinux.org/Category:Userspace_Arduino
Jul 24 16:24:55 * jkridner didn't realize there was a bug tracker there!
Jul 24 16:25:12 <prpplague> jkridner: in addition, we've got kkeller testing the build, someone from the msp430 group testing, someone from the arduino group testing, and bradfa / mdp have been testing
Jul 24 16:25:14 <mdp> the library status page is planned to show BBB-specific deviations due to h/w differences in apis
Jul 24 16:25:17 <prpplague> jkridner: yea long story
Jul 24 16:25:27 <prpplague> jkridner: remind me to tell you about that so time...
Jul 24 16:26:30 <prpplague> mdp: as well as track which ones are functional and tested
Jul 24 16:26:30 <mdp> jkridner, I would also add that we are also in heavy review mode on code quality/style/error checking
Jul 24 16:26:42 <mdp> prpplague, right
Jul 24 16:27:20 <jkridner> vvu, anujdeshpande, hatguy, tcort, ZubairLK: any concerns? I feel like I am getting reasonable updates and things are moving along nicely.
Jul 24 16:27:20 <mdp> and as prpplague suggested, we're going to add checkpatch.pl into the repo to help enforce some style
Jul 24 16:27:40 <ZubairLK> jkridner: couple of patches got acked and upstreamed..
Jul 24 16:27:43 <ZubairLK> we will have one-shot adc reading in 3.11 without any patches hopefully once we move to 3.11 rc-3.
Jul 24 16:27:44 <vvu> jkridner: none pressing here, just coding issues that i need to investigate
Jul 24 16:27:56 <hatguy> jkridner: none atm... just focusing on passing mid-terms smoothly
Jul 24 16:28:00 <tcort> jkridner: no concerns here. things are progressing smoothly.
Jul 24 16:28:13 <anujdeshpande> jkridner: nope. all good
Jul 24 16:28:35 <ZubairLK> jkridner: continuous mode is a bit tricky. the TI driver doesn't play well with iio spec. i'm reworking the whole thing. am close i think
Jul 24 16:28:42 <ZubairLK> jkridner: n yea. all good too :)
Jul 24 16:29:02 <jkridner> vvu, tcort, anujdeshpande, hatguy, ZubairLK, jj2baile: are you all confident your mentors will give you passing grades at the mid-term evaluation next week?
Jul 24 16:29:06 <hatguy> ZubairLK: any idea when we could get your work into a stable image?
Jul 24 16:29:16 <jkridner> (or at least that you know what needs to be done to pass?)
Jul 24 16:29:34 <tcort> jkridner: yes
Jul 24 16:29:36 <hatguy> jkridner: yeah... we should pass :)
Jul 24 16:29:43 <ZubairLK> *hopeful about passing mentor evaluation.*  *looks at  gregkh*
Jul 24 16:29:53 <vvu> jkridner: if i make a stable build of the project and if _av500_ likes hacking the android kernel to make it work with BBB, yes!
Jul 24 16:30:09 <ZubairLK> hatguy: stable image? kernel version 3.8 is stable and has one-shot adc reading. as for continuous. might have to wait a bit..
Jul 24 16:30:35 <hatguy> ZubairLK: ok no worries...
Jul 24 16:30:38 <_av500_> vvu: I dont like it, but I dont blame you for it
Jul 24 16:30:42 <anujdeshpande> jkridner: yepp
Jul 24 16:31:02 <vvu> _av500_: then i`m a bit on luck *no jinxing here*
Jul 24 16:33:03 <prpplague> jkridner: anujdeshpande and hatguy are weeks ahead of schedule on the project and have nearly all of the major functions working
Jul 24 16:33:27 <jkridner> prpplague: sweet.
Jul 24 16:33:33 <prpplague> jkridner: i finished testing the base support on minnow board and raspi over the weekend
Jul 24 16:33:36 <koen> vmayoral is on schedule as well
Jul 24 16:33:46 <jkridner> koen: thanks.
Jul 24 16:33:49 <prpplague> jkridner: there is still some clean up that needs to be done to make sure the over all support is generic
Jul 24 16:34:01 <prpplague> jkridner: but that will come with the code review and cleanup
Jul 24 16:34:17 <jkridner> koen: any chance we can get him to participate here just to "say hi" to the other GSoCers? would be nice to make a few connections.
Jul 24 16:34:40 * jkridner tries to keep this down to 30 minutes and wants to wrap-up now.
Jul 24 16:34:42 <koen> I'll ask
Jul 24 16:34:52 <jkridner> koen: thanks.
Jul 24 16:35:21 <koen> it's not that I think you're wasting time here, it's just the time of day that I'm in the kitching cooking dinner :)
Jul 24 16:35:32 * jkridner raises the gavel....
Jul 24 16:35:32 <jkridner> 3....
Jul 24 16:35:37 <jkridner> 2....
Jul 24 16:35:43 <jkridner> 1....
Jul 24 16:35:45 <_av500_> 54
Jul 24 16:35:52 <jkridner> 54!
Jul 24 16:35:54 <jkridner> :-)
Jul 24 16:35:59 <anujdeshpande> *boom*
Jul 24 16:35:59 <ZubairLK> 0.5
Jul 24 16:36:00 <jkridner> consider the official part over.
Jul 24 16:36:11 <jkridner> koen: doh!
Jul 24 16:36:37 <jkridner> koen: would 30 minutes later work better?
Jul 24 16:37:19 <ZubairLK> *maybe he is eating his dinner now :p*
Jul 24 16:37:26 <jkridner> even if I know you and vmayoral will be joining around the end, that'd help.
Jul 24 16:37:46 * jkridner could start to schedule student "update" times a bit more narrowly.
Jul 24 16:38:13 <jkridner> I want this to be efficient and encourage logging-in in and socializing a bit in off-hours.
Jul 24 16:38:55 <jkridner> ZubairLK: cook, IRC, microwave, eat. :-)
Jul 24 16:39:57 <jkridner> anyway, we can be flexible, but interaction with other GSoCers and communicating on status is important.
Jul 24 16:40:18 <ZubairLK> :)
Jul 24 16:42:41 <jj2baile> jkridner: i think so
Jul 24 16:43:06 <jj2baile> oh my.respon
Jul 24 16:43:18 <jj2baile> perhaps came a bit late
Jul 24 16:44:38 <ka6sox> jkridner, I'm getting daily or better updates :)
Jul 24 16:47:08 * vvu is going back to his cave, serial code still needs a better inspection!
Jul 24 17:25:22 <eFfeM> tcort, you got my msg that the latest build also worked with 250 delay ?
Jul 24 17:29:07 <tcort> eFfeM: yes
Jul 24 17:29:30 <tcort> thanks for testing it again.
Jul 24 17:30:21 <eFfeM> no problem
Jul 24 17:30:49 <eFfeM> calling it a day, temp has dropped some since yesterday and now it is really nice outside
Jul 24 17:30:55 <eFfeM> catch you all later
Jul 24 17:30:57 <eFfeM> & have fun!
Jul 24 17:42:29 <ZubairLK> gregkh: turns out one of the irqs i was talking about was threaded.. it can sleep while my hw irq works its magic.
Jul 24 17:42:31 <ZubairLK> One step closer to nirvana.. :p
Jul 24 19:23:53 <mluckham> panto, ping
Jul 24 21:06:01 <mluckham> jj2baile, ping
Jul 24 21:13:12 <panto> mluckham, pong but here for very short time
Jul 24 21:13:14 <panto> *a
Jul 24 21:13:45 <mluckham> glad I caught you panto
Jul 24 21:14:00 <mluckham> i got the compiler, can build prutest1 but not prutest0
Jul 24 21:14:09 <mluckham> missing prurproc.h
Jul 24 21:14:24 <panto> mluckham, ugh
Jul 24 21:14:29 <panto> ok, let me push it
Jul 24 21:15:04 <mluckham> had to add some -I to the makefile too, I hope to the right include directories
Jul 24 21:15:06 <panto> done
Jul 24 21:15:23 <mluckham> let me try
Jul 24 21:15:24 <panto> mluckham, ok, done
Jul 24 21:15:29 <mluckham> many thanks
Jul 24 21:15:52 <panto> np
Jul 24 21:15:55 <mluckham> dumb question - I have to make another PRU loader app for these?
Jul 24 21:16:15 <panto> mluckham, http://pastebin.com/4Ndrxpkh
Jul 24 21:16:19 <panto> that's my pru env
Jul 24 21:16:27 <mluckham> you are a treasure
Jul 24 21:16:33 <panto> mluckham, err, no
Jul 24 21:16:40 <panto> what do you mean? that's all you need
Jul 24 21:16:42 <mluckham> a time-saver, at least!
Jul 24 21:17:08 <panto> just put them in /lib/firmware and it will get loaded
Jul 24 21:17:26 <panto> as described by the BB-BONE-PRU* stuff
Jul 24 21:17:46 <mluckham> at boot time?
Jul 24 21:18:46 <panto> no, at the time the prurproc device gets instantiated
Jul 24 21:18:53 <panto> i.e. echo BB-BONE-PRU-04 >slots
Jul 24 21:19:04 <mluckham> oh, like that :)
Jul 24 21:19:09 <panto> right
Jul 24 21:19:23 <panto> so now it's just like a device
Jul 24 21:19:58 <panto> there's support for re-loading without removing the device and inserting again
Jul 24 21:20:12 <panto> but it doesn't work right with PRU devices that have vrings active
Jul 24 21:20:26 <panto> so there might be some things broken in there, I don't know
Jul 24 21:20:35 <mluckham> we'll find out
Jul 24 21:20:54 <mluckham> to remove, echo -<slotnum> > /sys/devices/bone_capemgr.8/slots ?
Jul 24 21:21:01 <panto> yeah, but it will crash
Jul 24 21:21:11 <panto> cause omap devices don't like to be removed
Jul 24 21:21:23 <panto> dunno, maybe they fixed it in 3.11rc
Jul 24 21:21:29 <mluckham> is it supposed to work, just repeating the original echo <drivername> > /sys/...
Jul 24 21:21:43 <mluckham> it was my impression, the driver just got added to the next slot (also)
Jul 24 21:21:52 <panto> it is supposed to work but it doesn't usually
Jul 24 21:21:56 <mluckham> ok
Jul 24 21:22:23 <panto> as I said before, we get to exercise parts of linux that never got to be exercised before
Jul 24 21:22:32 <panto> like the removal of board level platform device
Jul 24 21:22:34 <panto> *devices
Jul 24 21:22:41 <ka6sox> Bleeding Edge
Jul 24 21:22:47 <panto> profusely
Jul 24 21:23:03 <mluckham> that's what makes this fun, I'm learning but so are you guys
Jul 24 21:23:15 <mluckham> once the build&test environment is working, things should go faster
Jul 24 21:24:32 <mluckham> the compiler only installs on x86
Jul 24 21:24:32 <panto> anyway, got to catch some zzzs
Jul 24 21:24:37 <mluckham> ok, tx again
Jul 24 21:24:39 <panto> mluckham, yes
Jul 24 21:24:48 <ka6sox> nite panto
Jul 24 21:24:54 <panto> only x86 (and for the foreseeable future)
Jul 24 21:25:10 <panto> but, you should be able to run it on arm using qemu user-level x86 emulation
Jul 24 21:25:27 <mluckham> yap - yet another project
Jul 24 21:25:39 <ka6sox> hurt me baby...make me run qemu-x86 on a BBB
Jul 24 21:25:49 <mluckham> lol
Jul 24 21:26:01 <panto> ka6sox, the maximum code size you're going to compile is 8K
Jul 24 21:26:03 <panto> you'll be alright
Jul 24 21:26:28 <panto> g'night!
Jul 24 21:26:29 <ka6sox> its just the compilications associated with that is all...just wanking...I'll be quiet now
Jul 24 21:26:39 <ka6sox> nite!
Jul 24 21:26:43 <mluckham> nite panto
Jul 24 21:55:42 <vvu> ds2: ping
Jul 24 23:08:03 <mluckham> jj2baile, ping
Jul 24 23:12:06 <mluckham> ka6sox, ping
Jul 24 23:28:26 <ka6sox> mluckham, pong
Jul 24 23:30:45 <mluckham> panto implied that his testpru0 binary would load in the same way a .dtbo is loaded from /lib/firmware
Jul 24 23:30:48 <mluckham> doesn't work for me
Jul 24 23:31:16 <mluckham> afaik uio_pruss would need to be used, to load a .bin file - as in jj2baile's demo
Jul 24 23:31:30 <mluckham> there must be more magic incantations
Jul 24 23:31:53 <mluckham> any suggestions (except, I will ask panto tomorrow)
Jul 24 23:42:25 <mluckham> remoteproc has an elf loader, in the kernel
Jul 25 00:33:24 <ka6sox> mluckham, yes, remoteproc is supposed to load and instantiate cores
**** ENDING LOGGING AT Thu Jul 25 02:59:58 2013