**** BEGIN LOGGING AT Wed Jul 31 02:59:58 2013 Jul 31 13:43:56 jkridner, ka6sox, I may be late / not present for today's meeting, headed to a doctor appt now and not sure of the duration Jul 31 13:53:23 k Jul 31 13:58:00 hi mluckham. Jul 31 15:26:13 Hi everybody Jul 31 15:26:32 <_av500_> ho Jul 31 15:26:35 <_av500_> jkridner: ping Jul 31 15:26:40 pong Jul 31 15:27:02 _av500_: as best I can tell, whatever funds we get for travel will go to you to go to the summit. Jul 31 15:27:25 <_av500_> jkridner: oic Jul 31 15:27:36 sorry to be so difficult to reach. 9 days of non-stop tradeshow Jul 31 15:27:58 <_av500_> np Jul 31 15:28:00 3 days of sketching in hardware, 4 days of OSCON, 2 days of Maker Faire Detroit. Jul 31 15:28:21 <_av500_> jkridner: do one in germany Jul 31 15:28:25 <_av500_> so we can have beers Jul 31 15:28:31 + 3 days of travel. Jul 31 15:28:43 so, really 12 days of shows. :( Jul 31 15:28:51 _av500_: will you make it to Rome? Jul 31 15:28:54 for Maker Faire Rome? Jul 31 15:29:17 <_av500_> Rome sounds doable :) Jul 31 15:29:19 * jkridner likes Bavarian beer and hopes they import it there. Jul 31 15:29:36 <_av500_> I can smuggle some Jul 31 15:29:38 <_av500_> when is it? Jul 31 15:29:48 Oct 3-6 Jul 31 15:30:08 damn it Jul 31 15:30:11 should be enough past October fest your hangover will be done? Jul 31 15:30:20 * jkridner kicks spell checker. Jul 31 15:30:42 <_av500_> jkridner: I dont do october fest Jul 31 15:30:46 <_av500_> I live here Jul 31 15:30:50 <_av500_> so I dont have to Jul 31 15:31:00 <_av500_> its for japanese and americans Jul 31 15:31:04 lol Jul 31 15:31:09 :( Jul 31 15:31:09 and we appreciate you for it. Jul 31 15:31:12 <_av500_> and for native bavarians Jul 31 15:33:56 meeting in ~30 minutes, right? Jul 31 15:34:07 <_av500_> 29 Jul 31 15:34:30 _av500_: do you have any inside info on archos player for 4.3? Jul 31 15:34:56 <_av500_> in teh works Jul 31 15:34:59 it seems every videoplayer capable of HD decoding on the nexus 7 broke Jul 31 15:35:12 <_av500_> they changed nothing API wise and broke everything Jul 31 15:35:26 <_av500_> my padawan has it mostly done Jul 31 15:35:46 <_av500_> join the beta community Jul 31 15:36:08 last night at midnight I heard a "VLC updated, now I can watch another episode of Dexter" from the other side of the bed Jul 31 15:36:23 <_av500_> ha Jul 31 15:38:42 <_av500_> koen: https://plus.google.com/u/0/115368099367436589759/posts/gi7P2iFkn8n?cfem=1 Jul 31 15:43:20 awesome! Jul 31 15:45:23 <_av500_> i'd rehare it if this wifi here would let me Jul 31 15:45:32 <_av500_> but gplus is basically a performance killer Jul 31 15:45:38 <_av500_> it even makes chrom suffer Jul 31 15:45:45 <_av500_> +e Jul 31 15:50:49 fn Jul 31 15:50:51 gm Jul 31 15:50:58 grabbing a bite first back in a bit Jul 31 15:58:59 gm everyone :) Jul 31 15:59:13 hey ZubairLK Jul 31 15:59:21 hi koen Jul 31 15:59:34 did you find out about the 3.11 boot thing? Jul 31 16:01:42 koen: Jul 31 16:01:58 not yet Jul 31 16:02:09 hello Jul 31 16:02:32 hello people! Jul 31 16:02:45 hello Jul 31 16:02:50 hi Jul 31 16:02:54 Evening Jul 31 16:03:24 <_av500_> hello vvu Jul 31 16:03:58 * jkridner looks for attendance Jul 31 16:04:15 * _av500_ does the atten-dance Jul 31 16:04:19 aye aye captain Jul 31 16:04:30 * jkridner notes anujdeshpande, hatguy, tcort, vvu, jj2baile, ZubairLK and vmayoral Jul 31 16:04:55 first order of business is to check on the midterms. Jul 31 16:05:03 hello everyone Jul 31 16:05:05 morning Jul 31 16:05:28 ka6sox, jj2baile: what is your status on completing mid-terms? Jul 31 16:05:41 I'll go do them right now Jul 31 16:05:57 jj2baile: when is your next status update? Jul 31 16:06:48 jkridner: my week #6 update will be in just a moment up on the blog. draft status right now Jul 31 16:06:55 I've written slides for the video, but have not actually completed the video. I had wanted to include the video in my next status update Jul 31 16:06:58 * hatguy just updated his blogs Jul 31 16:07:00 vvu: thanks. Jul 31 16:07:30 im having a bit of difficulty with the video. I know what to do in a high level, but actual implementation is, i dont know. Jul 31 16:07:34 jj2baile: please split up the task if it means you can get a report in before 7 days pass from last report. Jul 31 16:07:35 I guess ive never made a video before Jul 31 16:07:50 jkridner: Ok Jul 31 16:07:55 jkridner: Would you like to see my slides so far? Jul 31 16:08:01 I went to a GSoC meet-up at OSCON and they made it sound like I might be too easy on status reports. Jul 31 16:08:19 most of the administrators and mentors there said they required daily status reports. Jul 31 16:08:26 jj2baile: what equip r u using? Jul 31 16:08:51 *likes the way bb.org runs things* Jul 31 16:09:02 *doesn't want to go for gsoc in those orgs next summer* Jul 31 16:09:05 jj2baile: I'd be interested in you sharing your work-in-progress with the community, i.e., your blog and beagleboard-gsoc@googlegroups.com Jul 31 16:09:27 ds2: Well I have access to a video camera, but based on discussion with ka6sox, I might mainly just need the slides and a screen cap program and micrphone (and actual video for a small part) Jul 31 16:09:55 <_av500_> its not the video that is important Jul 31 16:09:59 <_av500_> its the status update Jul 31 16:10:03 Ok. Jul 31 16:10:10 +1 slides + screen cap + audio is good Jul 31 16:10:15 +1 on status report being more important Jul 31 16:10:19 alright, thanks for the confirmation Jul 31 16:10:25 jj2baile: prehaps post a draft of the slides asap? Jul 31 16:10:31 actually, +1000 on that. weekly status is a *requirement* Jul 31 16:10:39 csclub.uwaterloo.ca/~jj2baile/tex/slides.pdf Jul 31 16:10:46 video is desired. Jul 31 16:11:02 So should we try to update our blogs more often? Jul 31 16:11:03 Ok, the video was starting to get to me. Jul 31 16:11:20 jj2baile, ka6sox: what code is working? Jul 31 16:11:21 Maybe every two-three days? Jul 31 16:11:22 yes, a basic scribbling is better then silence. Jul 31 16:11:45 <_av500_> maybre a GSoC for next year should be: "how to use the BBB to make a video to report status on your GSoC" Jul 31 16:11:47 For my next blog update I'll want to compile a bunch of the instructions on building panto's kernel and my code Jul 31 16:11:51 vmayoral: yes... no later 7 days between updates. 2-3 days is quite reasonable. Jul 31 16:11:55 also perhaps a high level overview of panto's testpru code Jul 31 16:12:05 any time you make progress, you should be thinking about sharing that progress. Jul 31 16:12:13 * vvu is a bit pissed; lot of bots spam my blog Jul 31 16:12:21 or even not make progress Jul 31 16:12:32 say something went wrong Jul 31 16:12:34 if you haven't made any progress in 7 days, you should be ALARMED! Jul 31 16:12:45 jkridner: The code from linux userspace to the PRU hasn't been done yet. I need to dig into panto's stuff. Jul 31 16:12:54 agree, if you are stuck, write a blog post to say how you are stuck! Jul 31 16:13:27 i.e. tried xyz code, it crashed test chip hard. currently stumped Jul 31 16:13:37 ka6sox: yt? Jul 31 16:13:58 jj2baile: is that a today thing? Jul 31 16:14:40 Yeah. Jul 31 16:15:28 jkridner, not sure if ka6sox is present Jul 31 16:15:38 btw, vmayoral: thanks for joining the irc channel. please let me know when you cannot attend our weekly. sorry if I missed e-mails saying so. Jul 31 16:15:45 jkridner: He said he would be away for a few days Jul 31 16:15:51 In yosemite i believe Jul 31 16:16:04 when is midterms due? today? Jul 31 16:16:08 ds2: Friday Jul 31 16:16:23 Friday noon. Jul 31 16:16:34 jj2baile: has ka6sox taken care of it? Jul 31 16:16:47 ds2: he has *not* Jul 31 16:16:52 oh crap Jul 31 16:16:58 He had told me he would try to do it monday, but i'm unsure if he has actually Jul 31 16:16:59 that is the only one not yet completed. Jul 31 16:17:01 Oh. Ok Jul 31 16:17:07 It was only open to be done on Tuesday. Jul 31 16:17:24 jkridner: are you able to reassign mentors in midstream? Jul 31 16:17:27 jkridner: apologies for not joining more often :(. I definitely have to improve that Jul 31 16:17:34 all other mentor and student evaluations have been completed. Jul 31 16:17:43 *:)* Jul 31 16:17:45 IIRC, only the official one can do it. Jul 31 16:18:14 I've dropped a line to carols, since I have similar concerns for the final eval. Jul 31 16:18:35 ok. Jul 31 16:18:46 if i read the faq correctly, org admin can do it as well.. Jul 31 16:18:56 blah Jul 31 16:20:00 jkridner: i'm still waiting for the audio cape. I was supposed to start working with it this week but since i don't have it i rescheduled that. Any idea when it'll arrive? Jul 31 16:21:04 Bradfa: would u be able to swap in and do the eval if u had to? Jul 31 16:21:23 jkridner: post is up Jul 31 16:21:28 tcort: when becomes having the cape an issue for you ? Jul 31 16:21:39 ds2, I'd probably be a bad choice, panto might be a better fill-in Jul 31 16:22:08 jkridner: I'm also waiting on hardware (Weather Cape). I've got other stuff to work on for the moment, but I'd really like to get it soon. The Matt Lemire @ Carleton University address in the spreadsheet is still valid. Jul 31 16:23:19 ds2, bradfa: if I need to make you primary mentor in order to get jj2baile's evaluation done, are either of you able to do that? Jul 31 16:23:39 jkridner, I have not been a good backup mentor for jj2baile Jul 31 16:23:51 eFfeM: I should have enough to do for the next 2 or 3 weeks, but after that it becomes an issue. Jul 31 16:24:02 ok Jul 31 16:24:18 jkridner, I would like to talk with you and ka6sox about my poor mentoring at some point Jul 31 16:24:24 tcort: I can order you some i2c devices from element14 like I did for the boards. Jul 31 16:24:25 eFfeM: there are other BBB drivers I could work on, but that'd be a bit outside the original scope of my project. Jul 31 16:24:37 the BMP085 breakout is easy. Jul 31 16:24:54 jkridner: for the midterm, yes but text me. I am on limited access til thur evening. Jul 31 16:25:45 k. Jul 31 16:25:59 jj2baile: what hours r u awake? might need to spend some time to talk to u if I had to step in before fri noon. Jul 31 16:26:13 I am on via N900 right now. Jul 31 16:26:14 anybody stuck on software implementations? Jul 31 16:26:41 jkridner: sounds good. Jul 31 16:26:42 vmayoral: are you moving ahead? are you submitting Angstrom patches? Jul 31 16:26:42 * vvu sees no major issues in his project. just need to read stuff Jul 31 16:26:59 vvu: what is your next step? Jul 31 16:27:03 jkridner: s/angstrom/meta-ros/ Jul 31 16:27:09 koen: k. Jul 31 16:27:15 jkridner: at this moment i have a working eMMC flasher from Android Jul 31 16:27:32 next step is to change g_serial communication to gadgetFS Jul 31 16:27:33 vvu: is that working from "FIT" files still? Jul 31 16:27:34 software's going well for me.... tda19988 driver merged earlier this week, frame buffer enhancements are being tested, TPS65217 PMIC driver underway. Jul 31 16:27:38 jkridner: tcort can you work out together what would be a good alternative that could be obtained on short notice ? Jul 31 16:27:46 is there a .img.xz to "FIT" conversion? Jul 31 16:28:08 (although it would be nice to get the weather cape going) Jul 31 16:28:14 tcort: are you getting BeagleBoard-xM testers? Have you published the call for testing to beagleboard@googlegroups.com? Jul 31 16:28:22 ds2: Tricky question. Generally between noon and midnight EST i'm guaranteed to be awake, Probably extending to 4am EST Jul 31 16:28:34 jkridner: not sure if i am following you. now my app expects a folder on sdcard with 4 files; 3 of them i provided in an archive on my blog. the 4th one is the flash.img.xz that will be flashed Jul 31 16:28:43 eFfeM: here's some in-stock on mouser... http://ca.mouser.com/ProductDetail/CircuitCo/BB-BONE-WTHR-01/?qs=%2fha2pyFadugh6wNMONnDuMep4oPjIcGgnivcyhR0zQgrNYrVY7Et6Y4qq4eFilZG Jul 31 16:29:12 jkridner: I am planning to do the xm teesting, but it will probably be weekend before I get to it (and need to restock on sd cards) Jul 31 16:29:13 jkridner: I've got a couple of people who said they would test it. I'll try posting to the BeagleBoard google group. Jul 31 16:29:15 vvu: k, so it has to be on an SD card, not over-the-air? Are their over-the-air plans to flash-from-URL? Jul 31 16:29:38 jj2baile: til u can confirm midterm is done, can u check/stay up a little? I know most of what u did was with ka6sox so I need info if I had to take care of it. Jul 31 16:29:47 * jkridner got a Motorola dev phone at Maker Faire Detroit that could be interesting to test against. Jul 31 16:29:49 jkridner: sure, why not. can be done. but 1st i want to change everything to gadgetFS communication then i can impleement over the air thingies Jul 31 16:30:36 jj2baile: it won't be today. it should just be thu night. I am on pdt and won't have normalized access til Thu evening my time. Jul 31 16:31:12 _av500_: regarding my project do you want also to see in it a way to boot a board with a normal rootfs not small ramdisk that i have right now ? Jul 31 16:31:22 beside the flashing eMMC part Jul 31 16:31:30 vvu: k. Guess the gadgetFS implementation would work on any Linux host in addition to a phone? Why not implement on libusb which is portable to Mac/Windows? Jul 31 16:31:34 jkridner: feels good on my side. ROS is running fine and i'm collaborating with meta-ros because soon we will push an official release. I just finished today coding a ROS node that publishes the MPU-9150 to a topic. It already cross-compiles. Ill modify it a bit and post it. Jul 31 16:31:50 ok Jul 31 16:32:29 vmayoral: thanks. Jul 31 16:32:46 <_av500_> vvu: where yould the rootfs be stored? Jul 31 16:32:52 ZubairLK: what is your next step now that you have first patches staged upstream. Jul 31 16:32:53 jj2baile: thanks. Jul 31 16:32:55 jkridner: _av500_ said to take a look at gadgetFS. i need to get rid of g_serial because the serial driver buffer is 4k in size and transferring stuff is really slow Jul 31 16:33:06 _av500_: everything < 500 megs Jul 31 16:33:07 jkridner: fixes are in staging Jul 31 16:33:19 k, not continuous, etc. Jul 31 16:33:19 i'm not aware that the continuous one went in too? did they? Jul 31 16:33:29 <_av500_> vvu: so still a ramdisk Jul 31 16:33:29 jkridner: once i have the IMU and motors running through ROS ill make another little vidro Jul 31 16:33:29 *video Jul 31 16:33:32 ZubairLK: I've seen some confusion around triggers... Jul 31 16:33:45 jkridner: still waiting on em. I'll ping again. Jul 31 16:33:49 av500: is gadgetfs u refering to usb mass storage? Jul 31 16:33:51 _av500_: mhmh true...so in the same place Jul 31 16:33:54 shouldn't it be possible to trigger with a level, like what is used to generate interrupts on touchscreens? Jul 31 16:34:07 jkridner: trigger on a per sample basis? Jul 31 16:34:11 ZubairLK: Is that clear just not coming across clear in the posts? Jul 31 16:34:15 jkridner: or trigger to start the buffer Jul 31 16:34:29 per sample or to start a continuous capture... Jul 31 16:34:34 much like a scope. Jul 31 16:34:39 iio treats triggers separately. Jul 31 16:34:45 atm the driver accepts any trigger Jul 31 16:34:49 hardware should be capable of generating interrupts to start a trigger. Jul 31 16:34:51 I tested it using sysfs based Jul 31 16:35:00 there is a gpio trigger from iio I haven't tested Jul 31 16:35:09 it should work. I'll do it and make a blog post about it Jul 31 16:35:34 triggering from userspace seems of some value, but having a GPIO would help and having ADC edge/level trigger would be *most* useful. Jul 31 16:35:36 _av500_: switch to gadgetFS then work on over-the-air download .img works for you ? Jul 31 16:35:57 jkridner: shouldn't be a biggy. I'll do it and update on the blog Jul 31 16:36:03 <_av500_> vvu: yes Jul 31 16:37:02 tcort: per eFfeM, please follow-up with me on other hardware I can buy you from Farnell. Jul 31 16:37:22 anujdeshpande, hatguy: what is your next step? Jul 31 16:37:28 hatguy_: ^^^ Jul 31 16:37:30 damned connection Jul 31 16:37:53 jkridner: next steps: GPIO trigger. Resend patches on the kernel list as they didn't get any response.. Jul 31 16:38:21 ZubairLK: k. just wanting to make sure you are aware of the ADC hardware capability to generate an interrupt. Jul 31 16:38:21 jkridner, we'll be discussing next steps with prpplague this week... we need to make decision on how to go with Serial... Jul 31 16:38:37 hatguy_: are you blocked on coding? Jul 31 16:38:42 jkridner: eFfeM: okay, I'll look at Farnell's site and send you an e-mail. Jul 31 16:38:46 jkridner my work has been slightly slow this week. I've had some connectivity issues. Serials next. Followed by i2c spi Jul 31 16:38:51 tcort: thanks. Jul 31 16:39:05 jkridner: i don't understand. adc generates an interrupt? :s Jul 31 16:39:07 The driver's sampling is based on interrupts and fifos already. Jul 31 16:39:21 jkridner, I had a few bugs which didn't really block functionality but need to ironed out nonetheless Jul 31 16:39:48 ZubairLK: the ADC is able to generate an interrupt such that when the level goes to a certain point, an interrupt is generated. This is critical to reduce CPU overhead in the case of touchscreen. Jul 31 16:40:02 jkridner no issues. We've had some help with testing from Rickta59 too(apart from our mentors) Jul 31 16:40:03 _av500_: regarding coding i will be offline 4 days this month. 12th 13th 14th 15th, hope there is no issue. i will try to get the things above done until then Jul 31 16:40:38 jkridner: could you elaborate what you mean by 'level'? is it the fifo threshold? Jul 31 16:40:51 or analog signal level? Jul 31 16:41:12 <_av500_> vvu: ok Jul 31 16:41:33 jkridner, we also had contact from the admin of http://codebender.cc/ he seemed to be interested in the arduino for linux cores Jul 31 16:42:40 vvu: moving? Jul 31 16:43:01 * jkridner believes analog signal level is possible and will confirm in the TRM. Jul 31 16:43:04 ds2: going to the mountain a bit; i need to take a break for my eyes :) Jul 31 16:43:04 jkridner: *lightbulb moment* mean the oscilloscope level trigger.. Jul 31 16:43:11 hatguy_: awesome. Jul 31 16:43:57 Apologies it disconnected somehow Jul 31 16:43:57 Im vmayoral Jul 31 16:43:59 ZubairLK: yeah. Jul 31 16:44:01 jkridner: I'll check.. atm registers are configured for continuous sampling. the interrupt is generated when the fifo reaches a threshold. then samples are copied to userspace. Jul 31 16:44:02 jkridner, he wanted a sample bbb to test out stuff.. I think prpplague did send him (or intends to send him) Jul 31 16:45:55 jj2baile: please say something to me, bradfa, pantos and jkridner if u did not hear anything about midterms by say the time u goto bed on Thu. Jul 31 16:45:56 hatguy_: if not, please connect him to me and I'll send. Jul 31 16:46:10 jkridner: Can't find it in TRM.. Jul 31 16:46:14 Support for the following interrupts and status, with masking: Jul 31 16:46:16 – Interrupt for HW pen (touch) event Jul 31 16:46:18 – Interrupt for HW Pen Up event Jul 31 16:46:20 – Interrupt after a sequence of conversions (all non-masked channels) Jul 31 16:46:22 – Interrupt for FIFO threshold levels Jul 31 16:46:24 – Interrupt if sampled data is out of a programmable range Jul 31 16:46:26 – Interrupt for FIFO overflow and underflow conditions Jul 31 16:46:27 ZubairLK: follow-up with me by e-mail (copy beagleboard-gsoc@googlegroups.com). Jul 31 16:46:27 jkridner, I think he did contact you a while before but somehow his emails missed you... Jul 31 16:46:28 – Status bit to indicate if ADC is busy converting Jul 31 16:46:49 ZubairLK: out of range might do it Jul 31 16:46:55 let's wrap up the official meeting and continue technical chat. Jul 31 16:47:04 any other business? Jul 31 16:47:12 raising gavel... Jul 31 16:47:15 3.... Jul 31 16:47:18 2.... Jul 31 16:47:23 Boom Jul 31 16:47:23 1.... Jul 31 16:47:27 *slam* Jul 31 16:47:40 ZubairLK: wouldn't pen down/up events be ADC level triggers? Jul 31 16:48:11 I don't know if the trigger level is adjustable, but I assume it would be. Jul 31 16:48:35 ZubairLK: what triggers pin down/up event? Jul 31 16:48:51 pend up down might cause it to drive some pins Jul 31 16:49:04 jkridner: from my understanding of TSC. driving is needed on some AIN pins Jul 31 16:49:10 i think out of range is the level trigger Jul 31 16:49:27 resistor network makes a potential that comes as x/y coordinate Jul 31 16:49:53 anyway, all of those interrupt events should generate IIO events. Jul 31 16:50:26 jkridner: yup. out of range is the one.. thanks ds2 Jul 31 16:50:50 pen up/down should give edge triggers. Jul 31 16:51:06 pen up/down are only usable in TSC modes.. Jul 31 16:51:23 do tsc modes not provide ADC values? Jul 31 16:51:39 tsc mode needs to drive Jul 31 16:51:44 out of range interrupt has two thresholds in register Jul 31 16:51:48 Sampled ADC data is compared to this value. Jul 31 16:51:50 If the sampled data is less than the value, then an interrupt is Jul 31 16:51:52 generated. Jul 31 16:51:52 a ts is just resistors Jul 31 16:51:56 Sampled ADC data is compared to this value. Jul 31 16:51:58 If the sampled data is high than the value, then an interrupt is Jul 31 16:52:00 generated. Jul 31 16:52:05 no signal to read w/o driving. Jul 31 16:52:17 ok. i need to go. Jul 31 16:52:38 * vvu goes offline! have a great day everyone! Jul 31 16:54:25 <_av500_> vvu: ok Jul 31 16:54:28 <_av500_> see you monday Jul 31 16:54:34 <_av500_> when I am back Jul 31 16:54:49 _av500_: no problem! have a great weekend Jul 31 16:55:13 jkridner: A TSC is just 4 criss cross resistors connected to 4 AIN pins. Jul 31 16:55:18 I understand the benefits of level triggering. Jul 31 16:55:20 but there's a few bugs in there that need debugging Jul 31 16:55:50 jkridner: Jul 31 16:55:53 1 if I do a Jul 31 16:55:55 while(true) Jul 31 16:55:57 do Jul 31 16:55:59 cat in_voltage* Jul 31 16:56:01 done Jul 31 16:56:05 It registers events on the TSC.. and the TSC goes haywire.. Jul 31 16:56:07 It shouldn't do that at all. Jul 31 16:56:19 jkridner: Jul 31 16:56:21 2 Jul 31 16:56:23 If I enable continuous sampling and await a trigger. Jul 31 16:56:25 the TSC becomes completely inactive. Jul 31 16:58:08 * jkridner doesn't understand the driver implementation. Jul 31 16:58:38 perhaps Ceriand, ds2, bradfa, koen, etc. can help Jul 31 16:59:00 ZubairLK: tsc/adc. One of them *most prob adc* is messing up configuration registers along the way somewhere Jul 31 16:59:06 jkridner: i'll look into it. Jul 31 16:59:12 lol. i just pinged myself.. Jul 31 17:00:23 k Jul 31 17:50:51 jkridner, I wanted to talk with you about my mentoring (or lack there of) of jj2baile with the PRU project Jul 31 17:51:07 I've not been keeping up with the progress and I'm being quite a poor mentor Jul 31 17:51:35 I think it might be best if I focus on just one project and I've been keeping up better with the arduino userspace stuff Jul 31 17:54:23 that's fine, but if we can get Ceriand or others engaged on the PRU project, it would really help. I feel like it is a very complex project that has a long way to go to be consumable by the average user. Jul 31 17:54:54 bradfa: I've considered your view as being a good one towards having more typical developers understand how to use it. You tend to be a fairly strong communicator. Jul 31 17:55:26 anyway, any help you can provide in getting someone else engaged on the PRU project is appreciated. Jul 31 17:55:55 mdp: how are you doing at tracking the PRU project? Jul 31 17:55:59 jkridner, ok, I'm happy to bounce ideas with people on irc still Jul 31 17:58:36 jkridner, I have not been able to track the PRU project at all, completely focused on userspace-arduino Jul 31 17:58:53 k Jul 31 19:27:47 mluckham: Let's discuss the virtio interface. Jul 31 19:27:54 okay Jul 31 19:27:57 I understand at a high level what it is, however i've never used it in a linux system Jul 31 19:28:08 and as well our use of it seems different from what it seemed to be designed for? Jul 31 19:28:44 I completely agree, I was confused too because virtio is usually discussed in terms of virtual machines Jul 31 19:28:56 But I got it when I saw panto's code Jul 31 19:29:39 not virtio really, but vrings - which are a form of in-memory message buffering Jul 31 19:30:18 a block of memory is allocated, and vring code splits it into 'entities' ... think of it as a quantity of pre-allocated memory slots, empty until you use them Jul 31 19:30:50 one process gets an available entity (memory block) and puts data into it Jul 31 19:31:20 then a signal occurs, an event or interrupt, which the other process receives and knows there is something in the vring buffer to read Jul 31 19:31:43 the vrings are uni-directional ... one process writes, the other reads Jul 31 19:31:54 if you need bi-directional communication, you need a second vring Jul 31 19:32:01 hm ok. Jul 31 19:32:46 can you explain or paraphrase what I just said, in your own words? Jul 31 19:34:22 vrings are basically a way to communicate between processes using managed buffers of memory. One uses a signal between the processes to say when the data is ready Jul 31 19:34:37 that's good Jul 31 19:34:45 so rather than needing to define a new rpc method, for between the PRU and the linux host, we are using the vrings Jul 31 19:34:55 correct again Jul 31 19:35:11 So I imagine in the original context of virtio, vrings are used to communicate between the guest and host? Jul 31 19:35:53 yes - but thanks to panto's pru_rproc driver they are used to communicate between an Linux process on the ARM core, and a process on one of the PRU's which are independent processors Jul 31 19:36:24 with the added presumption that, communication can be very, very fast Jul 31 19:36:49 let's talk about what panto's pru_rproc driver does Jul 31 19:37:26 what are your questions, before we do that? Jul 31 19:37:51 So we are using the standard interrupts the PRU has acces to over r31 for the signalling? Jul 31 19:39:04 I believe so - signals are used for several purposes: from ARM->PRU that there is data in the vring, from ARM->PRU for other events (using registers, to pass parameters outside of the vrings), from PRU0->PRU1, from PRU1->PRU0 Jul 31 19:39:18 I think the signals are using the Mailbox mechanism Jul 31 19:40:50 the vring buffer itself is in one of the PRU's data memory space Jul 31 19:41:07 could be in ARM memory space, but panto chose PRU memory space Jul 31 19:42:15 some of the memory shared by the two PRUs, is used for PRU->PRU communication Jul 31 19:43:02 more questions? Jul 31 19:43:13 if the buffer was in the arm memory space that would cause a large delay, since it has to go over the slower L4 interconnect. Also possibly coherency concerns? I dont know. Jul 31 19:43:36 right, I think that's an area for further exploration and testing Jul 31 19:43:37 Which reminds me that I should investigate if there are issues with the ARM looking into the PRU space. But no, no questions. Jul 31 19:43:56 okay, pru_rproc now - it does quite a bit Jul 31 19:44:17 you'll find it in drivers/remoteproc of panto's kernel code Jul 31 19:45:18 he decided to implement, as an initial model, a generic pwm driver using the PRUs - that's what pru_rproc does currently Jul 31 19:46:07 k Jul 31 19:46:46 to do that, a Device Tree BB_BONE_PRU_04 contains all the instructions related to the pru's - GPIO configuration, also an ELF loader which loads testpro0 and testpru1 into the PRU's when you do the echo BB_BONE_PRU_04 > /sys/class/bone_capemgr.8/slots Jul 31 19:47:17 BB_BONE_PRU_04 is passed to, and interpreted by, pru_rproc. I don't know the exact mechanism, haven't studied it enough. Jul 31 19:48:10 but pru_rproc does more - it creates Linux devices when you 'echo 1 > /sys/class/pwm/export' (if I remember the naming convention correctly) Jul 31 19:48:31 it creates /sys/class/pwm/pwm1 and some symbolic directories and files under that Jul 31 19:49:13 so when you 'echo 10000 > /sys/class/pwm/pwm1/duty_ns' it winds up sending "10000" to pru0 and the testpru0 program! Jul 31 19:49:14 and so is this pwm1 one of the vring buffers? Jul 31 19:49:44 no, it is register-level - the vring appears as another device, a bi-directional serial device /dev/vport0p0! Jul 31 19:50:48 in the testpru0 program, it is used as a command-line console - it echoes 'PRU0>' and you can pipe commands into /dev/vport0p0 which are received by pru0 as commands too Jul 31 19:51:24 so there are two communication methods ARM->PRU ... register-level for small parameters, vrings for hi-throughput serial data Jul 31 19:52:10 so writing to pwm1 actually sends the data to a register in the pru? Jul 31 19:52:49 via pru_rproc and a system interrupt to pru0, yes Jul 31 19:53:00 it's very clever Jul 31 19:53:31 a general model for using the PRUs (or any independent processor) Jul 31 19:55:13 the testpru0.c and testpru1.c use the PRU C Compiler, which has certain libraries that support ARM-PRU coordination and also to pick up data from the BB_BONE_PRU_04 Jul 31 19:55:46 (not sure how that works yet, either) but you can see it in the testpru0.c code Jul 31 19:56:24 more questions, before we talk about testPRU0 and testPRU1? Jul 31 19:56:51 No Jul 31 19:57:48 ok. if you look at testpru0.c you will see that it is responsible for ARM-PRU communication - by system events and vrings - and it passes commands to testpru1.c which is the pwm signal-generator engine Jul 31 19:58:32 there are 32 i/o pins controlled by the pru's ... pru1 handles pwm1-16, and pru0 pwm17-32. Jul 31 19:58:58 they are on P8 and P9 headers, I guess each PRU controls a different header Jul 31 19:59:39 when the pwm signal-generator (testpru1) receives a command (like - duty_ns or period_ns, or enable|disable) it operates the pin states Jul 31 20:00:07 if it for the upper 16 bits, it signals pru0 and sends the pin states back there, pru0 operates it's pins that way Jul 31 20:01:39 the main loop in testpru1 is the pwm signal generator, it just counts clock cycles and toggles the appropriate gpio pins at the proper times Jul 31 20:02:23 i put one signal on the scope, it was pretty solid - a bit of jitter, I think it was 40 usec Jul 31 20:02:45 i hope those are the right units Jul 31 20:03:48 questions? Jul 31 20:04:55 Not directly. just kind of curious how pwm factors into the project, but perhaps it was just for the sake of testing the interface and communication? Jul 31 20:05:24 that's the right question - it doesn't, it's a demonstration (although a usable one!) Jul 31 20:05:44 ok Jul 31 20:06:12 what are all the things it demonstrates? Jul 31 20:07:39 that the vectors of communication between each component are reliable, and quick enough? Jul 31 20:09:17 maybe, but that's not what I meant - I was asking you to tell me in your own words, how the pieces of the model work together to create a pwm demonstration Jul 31 20:13:03 ? Jul 31 20:15:12 host os through the interface gives pru0 the requisite input, pru0 communicates with pru1, which actually does the pin manipulation Jul 31 20:15:53 so pru0 is acting kind of like a command dispatch for the host Jul 31 20:16:08 it just operates with the communications layer Jul 31 20:16:48 yes, yes, yes - and how do the programs get loaded into the pru's? Jul 31 20:18:03 i think you had say pru_rproc driver loaded these into the pru upon initialization Jul 31 20:18:07 ? Jul 31 20:19:01 not clear enough - capemgr (somehow) interacts with pru_rproc, which does the loading Jul 31 20:19:34 is it doing the loading with the standard userspace driver, or has it defined its own method/ Jul 31 20:20:07 since I don't have the answer to that, I'll let you find out and tell us :) Jul 31 20:20:35 And I didn't know the capemgr had capability to load code onto the pru. Jul 31 20:20:52 hm Jul 31 20:21:00 i guess it doesn't, but somehow it is able to find pru_rproc which performs that function Jul 31 20:21:30 remember pru_rproc is part of 'remoteproc' drivers, which are all about multi-processor Jul 31 20:23:06 the 'somehow' has apparently been compiled into the kernel by panto's patches Jul 31 20:25:32 so, what are some ways you could proceed now? Jul 31 20:29:10 ? Jul 31 20:29:11 i would want to load panto's kernel unto my device andn try to update my current code to use the interface Jul 31 20:29:41 is that the easiest and fastest approach? Jul 31 20:30:11 and, which pru(s) would you code for? Jul 31 20:31:16 PRU0, initially at least Jul 31 20:31:26 why that one? Jul 31 20:31:47 since that is what my current code is doing, and that has examples of how to communicate with the arm Jul 31 20:32:06 although, that is using C code, so I'll have to see if I can get sufficient understanding from that Jul 31 20:32:20 I have another suggestion Jul 31 20:33:10 use testpru0.c as-is, and modify testpru1.c to add the functions your assembler program does - to operate the JTAG pins Jul 31 20:33:40 I see, so transition my code to c, basically. Jul 31 20:33:45 precisely Jul 31 20:34:14 is the pru c compiler going to be made public? Jul 31 20:34:28 i guess eventually, ask kridner Jul 31 20:34:50 jkridner: ^ Jul 31 20:34:57 another interesting question, are panto's kernel patches going to make it into the main branch! Jul 31 20:35:04 hi jason Jul 31 20:35:15 it is. Jul 31 20:35:20 but, I don't know the time frame. Jul 31 20:35:22 Approximate time frame/ Jul 31 20:35:23 oh ok. Jul 31 20:35:35 thanks for providing it, for this project Jul 31 20:35:36 i think feedback on the quality is important to know what that time frame is... Jul 31 20:35:49 if you pound on it and it looks really solid, that'll accelerate its release. Jul 31 20:35:54 :) Jul 31 20:36:12 kinda chicken-and-egg a bit, but welcome to the beta-testers. :-) Jul 31 20:36:22 panto mentioned something about shared memory being corrupted, between the PRUs Jul 31 20:37:06 could that be related to code generation? Jul 31 20:38:25 so jj2baile, I suggest you do these things as a matter of priority: Jul 31 20:39:12 #1 update your blog with the information you have learned, look at the source code (and perhaps include some snippets) for testpru0.c, testpru1.c and pru_rproc.c to make sure that what I have been telling you is Truth Jul 31 20:40:02 #2 do 'something' with your video - at least make a short one, learn how to transfer it out of the camera and to the blog (or wherever it is supposed to go) Jul 31 20:40:23 #3 build panto's kernel and try the pwm functions Jul 31 20:40:44 #4 modify testpru1.c to add some of your own functionality Jul 31 20:40:54 THEN the real work starts :) Jul 31 20:41:20 acknowledged. Jul 31 20:41:48 show us that you mean business Jul 31 20:42:15 thanks mluckham Jul 31 20:43:29 jj2baile, if you have #1 and #2 done by this time tomorrow, you will be a Start Jul 31 20:43:33 (Star!) Jul 31 20:44:17 ? Jul 31 20:44:32 jj2baile, if you have #1 and #2 done by this time tomorrow, you will be a Star! Jul 31 20:51:35 jj2baile: so, are you comfortable moving your plan to C to make quick progress and completing #1 and #2? Jul 31 20:52:16 building on known-good code is always a good formula. Jul 31 20:53:07 beng-nl, thanks :) Jul 31 20:53:57 * beng-nl bows Jul 31 20:56:02 jj2baile? Jul 31 20:58:19 mluckham: yes Jul 31 20:58:26 ? Jul 31 20:58:36 oh ok i see, missed jkridner Jul 31 20:58:40 yes Jul 31 20:59:06 do you think this gets you rolling faster? Jul 31 20:59:19 more able to describe the situation and what needs to be done? Jul 31 20:59:20 jkridner: yes Jul 31 20:59:31 and yes again Jul 31 21:00:12 k. I need to see something that says you are making good progress. If you follow this advice, I think you'll be there. Jul 31 21:00:21 writing in C should probably be a little easier if anything. and R30 and R31 can still be accessed properly based on the c compiler docuemntation Jul 31 21:00:47 look at testpru1.c Jul 31 21:01:05 I presume you have that code, from panto's repository? Jul 31 21:01:06 k, I'll be looking for an update tomorrow and will avoid pinging you myself for a bit so you can make some progress. :-) Jul 31 21:01:35 mluckham: i do Jul 31 21:01:45 great :) Jul 31 21:01:53 I'll sign off now too Jul 31 21:02:05 good luck Jul 31 22:31:55 jkridner: ping Jul 31 23:06:35 is there any generic link to the latest angstrom build for BBB like *http://angstrom-distribution/demo/beaglebone/latest.img.gz*, something like this ? Jul 31 23:15:08 vvu, we used https://github.com/beagleboard/kernel Jul 31 23:15:37 i`m trying to find a way for my android app to automatically dwld the .img Jul 31 23:15:42 for the eMMC flashing Jul 31 23:17:59 http://elinux.org/BeagleBoardUbuntu has images Jul 31 23:18:31 and http://elinux.org/BeagleBoardAngstrom leads you to some Jul 31 23:20:20 .. for Beagleboard - poking around elinux.org you might find a precompiled distro for BBB Jul 31 23:24:21 vvu: pong Jul 31 23:24:29 nope... Jul 31 23:24:33 jkridner: same question as abone Jul 31 23:24:35 above Jul 31 23:24:51 but, I do have latest images at http://beagleboard.org/latest-images Jul 31 23:24:55 can`t think of an way to get the latest angstrom image automatically Jul 31 23:25:03 and I have some tags there to help you identify the link. Jul 31 23:26:09 mhmh think i need to do it like that..or at least get all the file names from the directory and see which one has multiple good tags and latest modify date Jul 31 23:26:13 vvu: I can add extra tags as needed, but I need you to parse a tiny bit to get the link. Jul 31 23:26:14 and download that one :- Jul 31 23:26:23 no problem for parsing Jul 31 23:26:36 so, that is the URL. Jul 31 23:26:39 just put some *androidBBB* something tag Jul 31 23:26:54 i can parse no problem on my side, just need some *latest* tag for the image Jul 31 23:26:54 k. let me know exactly and I'll do. Jul 31 23:27:13 just put *latest* tag to the latest angstrom image Jul 31 23:27:19 i can parse the thingie Jul 31 23:27:19 again, I won't do an exact URL, but I can place a link at this URL. Jul 31 23:27:25 yep Jul 31 23:27:27 got it :D Jul 31 23:27:39 everything on http://beagleboard.org/latest-images is the latest. Jul 31 23:27:48 I can add a tag to make sure you know which image is for what. Jul 31 23:28:12 put a tag to the 1st one, not the eMMC flasher Jul 31 23:33:11 k. what should the tag be? attribute is? value is? Jul 31 23:41:51 mhmh not an expert here with which tag you can put there Jul 31 23:42:03 put the attribute to android and value to latest Aug 01 00:43:09 jj2baile, I'm sorry I've not had time to help mentor your GSoC project much but I don't see that changing this summer, I hope you can understand **** ENDING LOGGING AT Thu Aug 01 02:59:58 2013