**** BEGIN LOGGING AT Wed Mar 23 02:59:59 2016 Mar 23 06:23:57 Salut , what is the outlook of the organisation about gesture recognition using signals ? Mar 23 07:11:00 Hello everyone! Can someone please review my proposal ? I have shared the draft of GSOC website. Mar 23 07:18:51 alexhiam: How can we include support for PyBBIO in cloud9 IDE? If PyBBIO support is added to cloud9, Bone101 can be improved a lot by focussing on the IDE(examples, walkthrough tutorials) instead of the current code injection method via the browser. Mar 23 07:19:28 alexhiam: Any ideas you had in store for PyBBIO and Bone101? Mar 23 08:16:25 Hello Mar 23 08:26:36 Morning. Mar 23 10:33:10 morning Mar 23 13:27:55 jkridner: can you please review my propoal? Mar 23 13:42:34 carpediem: cloud9 already supports python, and there's some PyBBIO examples that ship in there on the BeagleBone Mar 23 13:42:57 carpediem: the one thing I can think of that could use some improving there is how it kills python programs Mar 23 13:43:30 currently it kills the terminal running the process, which doesn't give it a chance to exit gracefully Mar 23 13:44:08 would be nice if it did something like send a kill signal a second or so before killing the terminal Mar 23 13:58:43 alexhiam: ok. will look into it. Mar 23 14:36:52 alexhiam, Just had a doubt regarding RPMsg.It says that Messages are written in buffers in DDR memory.This refers to the shared mem only, right? Mar 23 14:39:16 alexhiam, I think all memory devices these days use Double data rate right? Mar 23 15:01:01 chanakya_vc: not sure what you're asking Mar 23 15:03:02 that means it's using the external DDR3 ram on the BeagleBone, and not the (limited) DRAM in the PRUSS Mar 23 15:04:09 it also means both ARM and PRU access is by way of the L3 Mar 23 15:09:41 The L3 interconnect connects the external DDR ram? Mar 23 15:10:49 yeah Mar 23 15:11:00 I thought it connected the shared mem to the PRU and ARM. Or both are the same things? Mar 23 15:11:40 both can access the DDR memory, so that's typically used for that. There is no dedicated shared memory Mar 23 15:12:58 Ohh.So when we say the shared mem,we actually refer to this DDR ram right? Mar 23 15:13:52 yeah, or more accurately it's referring to a software construct that uses the DDR Mar 23 15:16:40 But I don't think that the entire DDR is accessible from the PRU side? Mar 23 15:16:54 yeah, I don't think so Mar 23 15:18:50 * alexhiam goes afk Mar 23 15:22:46 alexhiam, I think there would specific memory addresses which are.Would have to figure those out. Mar 23 15:55:05 brb Mar 23 15:56:13 I cannot access the livelogs for some reason Mar 23 15:56:29 did you server go down? Mar 23 15:56:35 your Mar 23 15:57:49 yeah.. same with me Mar 23 15:59:11 is the mentor meeting going to be here? Mar 23 16:00:33 m_w: yes, iirc Mar 23 16:01:14 it starts now right? Mar 23 16:01:22 m_w: in theory Mar 23 16:01:59 Hi Mar 23 16:02:08 On the road today Mar 23 16:02:48 jkridner_: please tell me you aren't drive texting Mar 23 16:03:45 Nope Mar 23 16:04:26 okay well me and bradfa are here Mar 23 16:04:56 is the meeting here? Mar 23 16:04:56 Hi all. Mar 23 16:05:25 Yes Mar 23 16:05:45 Well, and in #beagle-mentors Mar 23 16:05:57 okay Mar 23 16:05:58 Which is invite only Mar 23 16:06:28 Am mentor, how to get invited? Mar 23 16:07:04 channel op has to do it... Mar 23 16:07:15 ok, thx. Mar 23 16:07:25 who isn't here apparently Mar 23 16:08:13 do have an "agenda" for today? Mar 23 16:10:35 No agenda Mar 23 16:11:07 Av500? Mar 23 16:11:17 not here today Mar 23 16:11:32 he said he has a meeting Mar 23 16:11:34 he had competing meeting schedules i think Mar 23 16:12:01 Doh Mar 23 16:12:34 no wormo either Mar 23 16:13:03 cool anyways to be able to say hi to everyone ;) Mar 23 16:13:39 got a q in fact, will students who propose X15 projects get one of the rev 1's Mar 23 16:14:16 or will the rev. 2 arrive in time? Mar 23 16:18:49 not sure about x15 status Mar 23 16:31:46 sorry y'all, was running late, just got back to the keyboard Mar 23 16:32:01 what students are here? Mar 23 16:34:02 anyone?? Mar 23 16:34:07 me Mar 23 16:34:13 Hey Mar 23 16:37:49 only 2 students here :( Mar 23 16:39:33 alexhiam, What happened? Mar 23 16:39:47 Kartik, kiran4399, udayansinha: ping? Mar 23 16:39:59 well, there's supposed to be a meeting now... Mar 23 16:40:23 last one before the app deadline, so seemed like a good chance for students to ask some final questions... Mar 23 16:40:44 FYI the weekly meetings moving forward are a requirement Mar 23 16:43:27 here Mar 23 16:43:58 sorry....I have exams on till tomorrow....trying to multi-task and manage both this and that so I might be a little clumsy in replying Mar 23 16:45:55 yeah.. Mar 23 16:46:21 alexhiam: I'm there. Mar 23 16:46:47 alexhiam: you had asked for some code samples for device drivers....I'll be uploading a simple char based driver in an hour or so....it is by no means complete but I'll build on it as I learn more Mar 23 16:46:56 well, now's a good chance if y'all have any questions, want to poke us to comment more on your proposals, etc. Mar 23 16:47:16 udayansinha: great Mar 23 16:47:56 alexhiam: I still don't find that pwm driver.. I've looked up in the remoteproc in drivers.. Apart from all the other parts which are clear enough.. I am little confused about this thing.. Mar 23 16:48:25 alexhiam, My proposal is still a work in progress.You wouldn't comment on our proposals after this meeting? Mar 23 16:48:43 alexhiam: the thing I am not clear is.. is the pwm driver there or is it that I've to implement it using the modified remoteproc framework? Mar 23 16:49:24 kiran4399: oh, no, the one n there is for the AM335x PWM subsystem, which is totally different than the PRU soft PWM Mar 23 16:49:39 but you would want to adhere to any Linux PWM standards Mar 23 16:49:43 chanakya_vc: will do Mar 23 16:50:24 I heard last year about the soft pwm and hard pwm using pru.. but I quite forgot.. Mar 23 16:50:58 alexhiam: are there any linux pwm standards?? should I use soft or hard? Mar 23 16:52:16 well the blue is set up to use the PRU for soft PWM... Mar 23 16:52:41 because there's only 6 or so hard PWM outputs Mar 23 16:54:12 alexhiam: it is 8 servo + 4 dc out.. Mar 23 16:54:27 alexhiam: so which one for soft and which one for hard? Mar 23 16:54:45 well doesn't the PRU firmware do all 8? Mar 23 16:55:33 alexhiam: not sure.. Mar 23 16:56:05 alexhiam: is it that.. 4 pwm for each pru.. so 4X 2 pru is 8?? Mar 23 16:56:22 not sure Mar 23 17:04:43 any audio q's? Mar 23 17:07:36 [iamharshit] don't know how someone can be so insensitive to help someone @alexanderhiam Mar 23 17:09:51 [alexanderhiam] @iamharshit excuse me? I answered your question on your github issue and in the PyBBIO gitter.... I'll say it again, there's no timer interrupt in PyBBIO. I don't think there's any spare timer modules, and userspace on a GNU/Linux system is never gonna be real-time enough to be very improved using a timer interrupt over just using the timing tools provided by the OS or Python Mar 23 17:10:27 [alexanderhiam] and if it's not related to GSoC, this probably ain't the place to ask about it... Mar 23 17:11:13 I am here ! Mar 23 17:12:53 if the meeting is still on .. Mar 23 17:13:42 * ZeekHuge is running really late on his "proposal schedule" coz of some college stuff Mar 23 17:13:48 one question .. Mar 23 17:14:32 can a mentor, if he thinks the student deserve to, open the proposal submission window ? beyond the extend date ? Mar 23 17:14:53 *beyond the submission date Mar 23 17:15:21 * ZeekHuge thinks this was possible last year .. Mar 23 17:15:47 ZeekHuge: that was possible with melange, but I don't think it is with the new system Mar 23 17:16:52 they said it was a hard date afaik... Mar 23 17:17:14 [iamharshit] sorry , @alexanderhiam ,didn't meant that from heart ,just needed ur attention because i am in a real problem . i wanted to know to get the data of an rpm encoder , if not timer interrupt do u have any suggestions ? Mar 23 17:17:54 mentor part of mtg is wrapping up i think Mar 23 17:18:20 [iamharshit] @alexanderhiam please ans that and i asure you i will leave Mar 23 17:18:33 So no extension ? ahh .. Need to cut the sleeping time then .. Mar 23 17:19:43 [alexanderhiam] @iamharshit have you looked at the eQEP module, as I mentioned on the github issue? https://github.com/graycatlabs/PyBBIO/wiki/RotaryEncoder Mar 23 17:20:30 sorry for the noise y'all, not sure why that conversation is happening in the beagle-gsoc mirror gitter room... Mar 23 17:20:42 [iamharshit] @alexanderhiam ok,let me look at that , between thanks Mar 23 17:21:12 [alexanderhiam] @iamharshit and switch back to the PyBBIO gitter if you have further questions Mar 23 17:21:42 [iamharshit] @alexanderhiam sure master Mar 23 17:21:54 [alexanderhiam] hmm... Mar 23 17:23:14 * alexhiam may need to hire some customer service... Mar 23 17:23:23 so mentor concerns in general revolve mainly around scope/effort and the assumptions buried in some of the high-level tasks Mar 23 17:25:16 there'll be a list email on that shortly, so start looking at your task scope and try and make it more detailed Mar 23 17:26:24 in some cases (for example) there probably needs to be some time for algorithm/library testing and a backup plan if plan A blows up completely Mar 23 17:27:45 also should probably not assume writing something non-trivial from scratch is the best plan when there are already tested/proven implementations Mar 23 17:28:31 +1000 Mar 23 17:30:20 so when it starts to look bigger than you thought you'll want to look at trimming down your baseline and maybe moving some tasks to "stretch" goals, either post-GSoC or if you have time Mar 23 17:30:24 make sense? Mar 23 17:31:10 *time during gsoc schedule because your tests are awesome and things Just Work... Mar 23 17:34:57 For those doing kernel stuff in particular beware of timing on mainline if intended... It can take a lot of time! I bounced back the guy who did the am335x ADC driver a lot of times and far from all of those were down to his code. Mar 23 17:35:37 Mainlining that is... And all upstream projects will have some element of this! Mar 23 17:37:53 Of course mentors will help with this! Mar 23 17:44:08 I am unable to access the logs. Mar 23 17:44:33 Can anyone help about that ? Mar 23 17:44:44 yes log server hostname won't resolve today Mar 23 17:45:18 ZeekHuge: the gitter mirror has the history as well: https://gitter.im/beagleboard/beagle-gsoc Mar 23 17:50:38 m_w: what's your github username? Mar 23 17:50:43 mwelling Mar 23 17:52:21 okay . thank you alexhiam ! Mar 23 17:57:12 alexhiam: Here's the sample code: https://github.com/UdayanSinha/GSoC_Beagleboard Mar 23 17:58:03 I put two source files....one's a basic hello world...the other's a simple char driver to read and write characters to the memory....noob stuff :) Mar 23 17:59:34 udayansinha: how about a Makefile? Mar 23 18:02:03 has this: obj-m := hello_world.o memory.o Mar 23 18:02:11 should I post this file as well? Mar 23 18:04:10 yeah, and build and run instructions ftw Mar 23 18:06:42 alexhiam: okay hold on Mar 23 18:08:14 autotools > make > other crap Mar 23 18:14:21 jic23: I actually specifically left mainline out of my idea on the ideas page since it's not realistic in the timeframe of GSoC (for that project) Mar 23 18:14:36 jic23: even though that's an important end goal Mar 23 18:17:36 thus, mainlining previous stuff is current "project" ;) Mar 23 18:20:26 maybe a staging patch would be a good entry barrier for kernel related projects Mar 23 18:21:17 get them used to the workflow Mar 23 18:21:39 alexhiam,m_w, Would you want me to include mainlining stuff in my timeline ? Mar 23 18:21:52 Yes though patches elsewhere would be fine :) Mar 23 18:22:25 chanakya_vc: only as a stretch goal Mar 23 18:22:29 jic23b, I am actually not familiar with how exactly this is done. Mar 23 18:22:33 nerdboy: indeed Mar 23 18:22:34 alexhiam: I added a file showing how to make and load the module, write stuff to it, read stuff from it, and finally unload it Mar 23 18:22:36 m_w, Okay Mar 23 18:22:45 That is what you asked for right? Mar 23 18:22:46 I would expect any driver developed to at least adhere to all Linux standards with the expectation of future mainlining, but I don't think it makes sense to except mainlining to happen during gsoc Mar 23 18:23:25 yes it is best to follow the kernel coding standards anyways Mar 23 18:23:28 alexhiam: a great way to put it...basically, it should be worthy of a first post Mar 23 18:23:59 https://www.kernel.org/doc/Documentation/CodingStyle Mar 23 18:24:01 Just switched to laptop. Mar 23 18:24:06 udayansinha: not quite on the Makefile, see https://www.gnu.org/software/make/manual/html_node/Introduction.html#Introduction Mar 23 18:24:13 Okay. And alexhiam, I had written a hello world driver and uploaded it to my github account.Would you want to have a look at it? Mar 23 18:24:30 udayansinha: and the instructions can go right in the README Mar 23 18:24:31 Coding style is one thing, but some of these projects should be looking to at least post a v1 in their gsoc timeline and get an idea of whether they are heading down the wrong path. Mar 23 18:24:47 yes I have not added commands to clean after making Mar 23 18:25:21 that's why I mentioned that it's far from complete.....I'm still reading up stuff and improving Mar 23 18:25:28 Agreed to the first post comment. Mar 23 18:25:33 anything "worthy" *could* go to rcn patch set first... Mar 23 18:25:35 (on kernel mainlining) Mar 23 18:26:10 chanakya_vc: link? Mar 23 18:27:16 absolutely, though a couple of things here need to be proposed at least against true mainline. Certainly the spi / i2c drivers and zeekhuge's stuff. Mar 23 18:27:30 oh, I think upstreaming to beaglebone/linux could be a good goal for all the kernel stuff Mar 23 18:28:12 It's good practice and gets students familiar with full process. Mar 23 18:28:19 you mean bb-kernel patches and onward? Mar 23 18:28:32 alexhiam, https://github.com/chanakya-vc/BBB-Gsoctry/tree/master/Drivers Mar 23 18:28:41 yeah Mar 23 18:29:02 alexhiam, It is a very simple driver but I guess a good starting point Mar 23 18:29:04 alexhiam: will try to add an improved makefile before Fri....this is very bare bones I know Mar 23 18:29:55 https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel <= i would target these versions/branches, ti-dev or bb-kernel Mar 23 18:30:26 udayansinha: yeah, not a valid Makefile as is Mar 23 18:30:29 ti-dev 4.1 goes to denys ti-staging i believe Mar 23 18:30:33 I'd be tempted to encourage a submission upstream first - only put them in bb-kernel to speed things up / or because they have dependencies that are in bb kernel. Mar 23 18:30:39 for starters, the 'M' needs to be capitalized ;) Mar 23 18:31:22 Well if slave spi happens, that will need to be based on 4.4 I think... (possibly 4.3...) Mar 23 18:31:33 jic23: you mean rcn's bb-kernel? ^^ those are the bleeding edges afaik Mar 23 18:31:45 yup, rcn's is good. Mar 23 18:31:48 It's what I'm running. Mar 23 18:32:08 ti-dev might be better for this Mar 23 18:32:21 well, another factor is community usage. Pushing to rcn means it'll ship on beaglebones Mar 23 18:32:30 exactly Mar 23 18:32:53 ti-staging gets "shipped" with openembedded Mar 23 18:33:14 where do ti-staging patches get sent? Mar 23 18:33:14 push it those places and then submit to kernel staging maybe Mar 23 18:33:38 eventually from ti to mainline, not very fast though Mar 23 18:33:45 have to ask denys Mar 23 18:33:53 nothing that has been proposed yet is vaguely staging material. Never target staging with new drivers... Mar 23 18:34:26 they'd need to work and not break other stuff first Mar 23 18:34:27 Or almost never anyway and certainly not for stuff like i2c / spi master drivers.... Mar 23 18:34:35 absolutely ;) Mar 23 18:35:03 thus rcn => beagleboard for user "testing" Mar 23 18:35:41 are patches to the rcn kernel sent via mailinglist like the mainline development? Mar 23 18:36:17 * nerdboy can push them to gentoo-arm if they're at a testable state Mar 23 18:36:27 where does the review come in? Mar 23 18:36:36 need to ask robert Mar 23 18:37:06 i think a lot of it is him doing his digikey thing Mar 23 18:37:15 Certainly interesting to know. Hmm. TI kernel being at 4.1 is a pain... Mar 23 18:37:17 good question tho... Mar 23 18:37:18 m_w: either ml preferred, or github pull requests Mar 23 18:37:49 without a ml the review process is going to be limited Mar 23 18:37:50 use ti-dev-4.4 maybe? Mar 23 18:38:36 m_w: I would expect ml patches only for gsoc. If anything it's good practice for proper patch submission Mar 23 18:38:37 i think the meaty reviews come after rcn testing maybe Mar 23 18:38:51 ah I'd missed that 4.4 kernel.... Mar 23 18:39:25 their git repo is a mess! Mar 23 18:39:40 :( Mar 23 18:40:07 the rcn u-boot/kernel stuff is probably easiest to use with latest dto stuff Mar 23 18:40:32 uEnv config for enable/disable, etc Mar 23 18:40:46 alexhiam, Did you see it?I got disconnected so Mar 23 18:41:20 chanakya_vc: yup, looks fine Mar 23 18:41:34 okay, i take that back, at least his doc points to capemgr: v4.1.x+ Mar 23 18:42:21 https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md Mar 23 18:42:41 new capemgr/dto is 4.1, old is 3.8 Mar 23 18:42:52 alexhiam, It is a very simple one.I am currently working on the assembly code for blinking LED's.What else what you want me to do? Mar 23 18:43:05 assuming that's still current Mar 23 18:44:08 v4.4 branch - "This branch is 44310 commits ahead, 4952 commits behind 4.1." Mar 23 18:44:29 students might want follow that doc and build u-boot/kernel, make their own card... Mar 23 18:44:37 Interestingly there is a whole load of new rproc stuff in that 4.4 ti tree... Mar 23 18:45:23 maybe it's usable? i just built that one two days ago... Mar 23 18:46:25 rproc_pru is gone... Mar 23 18:47:02 there in 4.1 (which is what robert's patches pull from that for rproc) Mar 23 18:47:02 what are you looking at? patches or kernel tree? Mar 23 18:47:10 Tree. Mar 23 18:47:22 http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=tree;f=drivers/remoteproc;h=badfc26278a7fccb7f0cc6a670f13768f848b396;hb=refs/heads/ti-linux-4.4.y Mar 23 18:47:27 chanakya_vc: blinky driver sounds good Mar 23 18:47:49 that pulls from rcn i believe Mar 23 18:48:22 what a mess Mar 23 18:48:43 have you ever looked at their "open source" packages? Mar 23 18:48:59 alexhiam, You would want me to write a driver for it? Mar 23 18:49:05 lol, at least you can actually get their code Mar 23 18:49:11 for blinking led's? Mar 23 18:49:33 chanakya_vc: oh, misread, thought you said driver. PRU blinky sounds good too! Mar 23 18:49:44 * nerdboy has classic OS distributor disdain for most vendor contributions... Mar 23 18:49:45 https://github.com/beagleboard/linux/tree/4.4 <== is this really the official tree? Mar 23 18:50:10 m_w: i have no idea Mar 23 18:50:13 alexhiam, Okay ;) Mar 23 18:50:14 rcn is already building 4.4? Mar 23 18:50:20 pretty sure it's stale Mar 23 18:50:20 * alexhiam is still on 3.8 :o Mar 23 18:50:57 i mean, some kind of "official" is correct, i just don't think it's all that current Mar 23 18:51:36 and I was told that the was close to mainline Mar 23 18:51:43 alexhiam: updated the makefile and put the build instructions in the README.md Mar 23 18:51:47 rcn is building 4.4 but with 4.1 patches for some stuff. Mar 23 18:51:49 i take that all back Mar 23 18:51:51 I added clean this time Mar 23 18:51:54 it's current Mar 23 18:52:05 and "M" :P Mar 23 18:53:11 should I write sample codes for PRU too? I don't have a Beaglebone Black though to test it Mar 23 18:53:23 sample codes = blinky Mar 23 18:53:24 udayansinha: you're running 2.6.8?? Mar 23 18:53:26 it looks current as far as rcn patches (based on what criteria i have no idea) just not sure where it falls in the "pipeline" Mar 23 18:53:36 my university computer does :P Mar 23 18:53:56 hence my slow speed...the computer's ancient Mar 23 18:54:31 m_w: "close" to mainline is less than optimal when i build default yocto for bbb Mar 23 18:55:00 udayansinha: go for it Mar 23 18:55:07 their kernel commit might be updated infrequently Mar 23 18:55:14 the new makefile's okay though? Mar 23 18:55:25 *build commit for yocto bsp Mar 23 18:55:31 cool...blinky on the way Mar 23 18:55:45 well, it looks like a Makefile now, so that's good :P Mar 23 18:56:14 if they've bumped master to 4.4.something then maybe it's better now Mar 23 18:57:01 Looks like TI went from 4.1 to 4.4 Mar 23 18:57:04 haha okay :) Mar 23 18:57:11 not soooo bad.. Mar 23 18:57:42 patches with HACK: in the subject :D Mar 23 18:57:43 https://github.com/beagleboard/linux/commit/9515e9cb415c61b5bf0b3607b40407fc02bfc196 Mar 23 18:58:59 the pipeline must look like a spaghetti bowl Mar 23 18:59:14 i meant yocto bsp build setup (using straight yocto mainline kernel) Mar 23 18:59:42 alexhiam: wrt submitting to rcn's tree..agreed. and that lines up with "first post" quality stuff that has an experienced mentor guiding it. that level is generally always ready for rcn's tree from my experience. Mar 23 18:59:57 beaglebone is one of their "reference" machines in yocto reference bsp Mar 23 19:00:08 alexhiam: and then ideally they're motivated enough to want to upstream it afterwards Mar 23 19:00:22 yup Mar 23 19:01:17 I'm chuckling thinking of the 2-3 unfinished upstream series *I* have atm. ;) Mar 23 19:04:02 I'll give some 'standard' reviews if wanted as well - I promise to be good and not 'too' rude ;) Mar 23 19:04:17 do as the mentor says, not as they do... Mar 23 19:06:25 I moan at people for not dealing with their drivers in staging all the time and rely on the fact no one checks the authors of the other drivers ;) Mar 23 19:06:52 That and hide from Greg KH who mysterious wants to know when they will all be out of there ;) Mar 23 19:07:54 just send a patch removing iio from staging and see who cries Mar 23 19:08:04 me for starters ;) Mar 23 19:08:38 though now Lars is getting vicious with the stuff he has gotten lumped with things are speeding up. Mar 23 19:09:19 I'm trying to find the commit where TI dropped rproc_pru... but they really need to repack their kernel trees from time to time! Mar 23 19:10:03 I think that things aren't linear Mar 23 19:10:33 Also if we take all our rubbish out of staging, where can we point new developers? Mar 23 19:11:15 umm Mar 23 19:11:21 :) Mar 23 19:11:22 jic23, TI dropped rproc_pru? Mar 23 19:11:47 Really? Mar 23 19:11:53 Driver itself doesn't seem to be in their 4.4 tree. Might have been moved / renamed - trying to find it... Mar 23 19:12:15 Looks like they have done a fairly large rewrite of rproc so maybe they just haven't finished that one yet... Mar 23 19:12:18 i think it might mean 4.1 really is the "latest" usable set of modules/interfaces Mar 23 19:12:42 The whole PRU ICSS is built around rproc pru. Mar 23 19:12:46 yup, rcn kernel forward ports that stuff fine anyway to 4.4 if people need the rest of the kernel up to date. Mar 23 19:13:11 I donot think they would do that all of a sudden? :( Mar 23 19:13:22 yeah, I'm guessing TI 4.4 really ins't ready yet. Their have been a lot of commits in the last week. Mar 23 19:13:25 are you saying it's in there now? Mar 23 19:13:27 there... (sp out today) Mar 23 19:13:57 The files aren't there in ti 4.4 - or at least not where they are in 4.1. Mar 23 19:14:00 in rcn 4.4 (one or the other) Mar 23 19:14:11 But - lots of new stuff is. Mar 23 19:14:35 If I could clone their tree a spot quickers we might find some relevant commit messages.... Mar 23 19:15:03 They are pulling rproc from https://git.ti.com/rpmsg/remoteproc Mar 23 19:15:42 wonderful out of tree driver Mar 23 19:16:40 specific path is:https://git.ti.com/rpmsg/remoteproc/trees/7352f73a59775b0b42b7fb9f1d1678b1c4467cd9/drivers/remoteproc Mar 23 19:16:41 so confused as to how the TI kernel development works Mar 23 19:17:09 who say it works :) Mar 23 19:17:29 seems like a design-by-committee situation Mar 23 19:17:29 ha Mar 23 19:17:56 got the clone - now just waiting for my useless laptop to check it out... Mar 23 19:17:56 * Abhishek_ was an intern at TI India last year summer Mar 23 19:18:17 cool - so how does it work then? Mar 23 19:18:22 and no I didn't work on kernel drivers. Mar 23 19:18:30 :( Mar 23 19:18:47 * Abhishek_ added DMA to the CC3200 SDK Mar 23 19:19:00 Met Denys a long time ago now (just as I was starting out) he seemed good and approachable. Mar 23 19:19:37 I think sumananna handled the last rproc driver, is he still doing that? Mar 23 19:19:48 But that is rproc core right? Mar 23 19:19:59 looks like it. Mar 23 19:23:12 dratt. rproc_pru was never in the git repo for 4.4 rproc. Guessing they are doing a rewrite and it's not done.... Nothing like a moving target :) Mar 23 19:23:36 that is what I expected Mar 23 19:23:44 Anyhow, got to go now. Back tomorrow. Mar 23 19:23:54 good to know it will probably totally change after all the gsoc projects are done :P Mar 23 19:24:42 Will at somepoint have a look at what they've changed. There are dma buffers in rpmsg now which is interesting. Mar 23 19:31:34 okay, i guess if i read far enough the answer is there Mar 23 19:34:20 are the livelogs ever going to come back up? Mar 23 19:36:06 if not maybe we should link add a link to gitter instead Mar 23 19:39:54 m_w, is this that link : https://gitter.im/beagleboard/beagle-gsoc ? Mar 23 19:40:33 m_w: there's slack as well Mar 23 19:40:59 [abhishek-kakkar] here is me Mar 23 19:41:37 gcl-bot likes to be useful Mar 23 19:41:54 yeah Mar 23 19:43:00 [mwelling] testing testing 1 2 Mar 23 19:43:19 [abhishek-kakkar] 3 4 5 6 Mar 23 19:44:32 as long as I can go back and read the previous chat I am cool Mar 23 19:44:46 yup Mar 23 19:50:38 * alexhiam goes afk Mar 23 19:53:31 assuming the readme is current, we want either bb-kernel 4.4 or ti-dev 4.1 Mar 23 20:31:28 alexhiam,The bus driver for I2C could use the data structures and methods described in i2c core.h right? Mar 23 20:34:19 alexhiam, As far as I have figured out,the core driver consists of a data structure that defines the name and algorithim used by the adapter.But it seems it exposes an sysfs file. Mar 23 20:34:54 there is a variable to store the name of a sysfs file Mar 23 20:52:24 It's providing some baseline sysfs files for the sysfs for associated sysfs dir for i2c client devices. See how it is used in i2c_new_device and where that is called from. Mar 23 20:53:01 Gah should read before sending. Drop the repeated text! Mar 23 20:54:33 In beagle it'll be called on registration of the adapter by reading devicetree to fill it in. Mar 23 20:58:12 Ultimately called from i2c_add_adapter in the relevant i2c master driver. Mar 23 21:00:23 On i2c on PRU would be interesting to explore a general bit banging core (kind of beagle logic in reverse) and doing the protocol handling in the kernel driver... Mar 23 21:01:58 So PRU just dumps a precomputed parallel (2-3) lines bitstream and then ships back the result to be unwound in kernel. Mar 23 21:02:44 Not good for every feature though as not going to do clock stretching that way. Anyhow, just idle thoughts! Mar 23 21:04:03 Also no good for offloading more complex comms which is where I think soft spi gets interesting! Mar 23 21:07:35 As an aside kernel i2c bit banging algo doesn't do multiple masters... Mar 23 21:34:13 he's got all of his kernels packaged in there... Mar 23 21:34:29 so only install -bone or -ti kernels Mar 23 21:39:00 uname -a on beagle to see which kernel it's running: Linux arm 4.4.6-ti-r11 #1 SMP Mon Mar 21 18:02:59 PDT 2016 armv7l armv7l armv7l GNU/Linux Mar 23 21:39:36 again,, only install -bone or -ti kernels please... Mar 23 22:01:23 jic23b, We cannot give support for multiple masters in i2c in bitbanging? Mar 23 22:02:34 stretch goal maybe? kind of a corner case of i2c Mar 23 22:02:58 alexhiam, Could do that. Mar 23 22:05:14 jic23b, by master driver you mean the core driver right?I am a bit confused. Mar 23 22:05:23 alexhiam, ^^ Mar 23 22:07:39 i2c_add_adapter is in the core driver Mar 23 22:10:06 Yes.Yes I saw that function.It is basically called by the core driver with a struct i2c adapter as a parameter Mar 23 22:10:47 This struct i2c adpter contains all the details of our adapter and algorithm driver,I guess? Mar 23 22:11:12 Ch- we probably can but the kernel implementation doesn't bother (there is a fixme comment :) Mar 23 22:11:26 right. It's not called in the core driver, it's a routine in the core driver called by a bus driver to register it Mar 23 22:11:51 alexhiam, Okay. Mar 23 22:12:11 jic23b, I will probably have this as my second goal Mar 23 22:12:37 For historical reasons i2c uses the term adapter for what is master on most similar buses.. Mar 23 22:12:57 The device in control of the comms Mar 23 22:13:13 Sure - stretch goal! Mar 23 22:13:47 Probably other things of more interest to look at before that! Mar 23 22:14:15 jic23b, Also wanted to ask you regarding the data width in SPI.I believe that this would depend upon the SPI shift register right?And in my case wouldn't the size of the shift register depend upon the slave PRU is talking to? Mar 23 22:14:28 Anyone on here ever actually encountered a multimeter spi bus. Mar 23 22:15:07 chanakya_vc: that's a parameter provided by the user Mar 23 22:15:19 it just always shifts in or out that number of bits Mar 23 22:15:22 Too tired.. Multimaster i2c bus! Mar 23 22:15:25 i.e. that number of clock cycles Mar 23 22:15:53 I've probably put my multimeter on a spi bus, but certainly never seen multimaster i2c Mar 23 22:15:59 ;) Mar 23 22:17:03 alexhiam, So I would take that from the user and accordingly code the firmware to send those many bits at one time right? Mar 23 22:17:14 right Mar 23 22:17:35 Spi width often changes depending on what you are doing with a device... Some devices have a rigourous register format, many are way more ad-hoc or do 'burst reads' of as long as you spi master can cope with. Mar 23 22:18:18 Your... I should give up now! Mar 23 22:18:38 alexhiam, Also,I have trouble figuring out the theoretical speed SPI or I2C would offer.ds2 asked me to write that down in my proposal Mar 23 22:19:28 well.. given a particular frequency and bits/word, how much time is there between bits? Mar 23 22:19:40 one could call it the 'bit period' even... Mar 23 22:20:19 Well the problem is how would one figure out the exact frequency? Mar 23 22:20:28 For range of spi devices go from an eeprom through a complex imu such as adis1640 to an ADC that will clock off the spi clock as the read message hits it. Mar 23 22:20:43 the user tells you the frequency... Mar 23 22:21:03 either from the DT or an ioctl Mar 23 22:21:05 ohh okay Mar 23 22:21:18 Max is 200M/cycles needed per bit for spi. Mar 23 22:22:15 I2c has overhead of iirc about 3 clocks cycles per byte + defined speeds anyway. Mar 23 22:22:16 note that, especially with spi (which is a very broad spec), all the parameters, like frequency, clock mode, word length, etc., can change at any time Mar 23 22:22:37 Slow i2c is 100khz Mar 23 22:22:46 so the firmware should be designed accordingly, i.e. not one-time configured at initialization Mar 23 22:22:49 Fast 400khz. Mar 23 22:22:58 But even if the user gives a frequency much lesser than that,I do not think it is possible to achieve all such frequencies below 200 Mhz? Mar 23 22:23:06 jic23b: nice rule of thumb Mar 23 22:24:06 Actually a good stretch goal would be the crazy quick i2c spec that lots of i2c ADCs support but I have never found an adapter supporting... Mar 23 22:24:25 oh yeah, that would be awesome Mar 23 22:24:29 See max1363 data sheet for example. Mar 23 22:26:25 Good example of advantages of soft i2c implementation. Mar 23 22:26:39 alexhiam, According to what you said,we would have to know the number of bits the user is going send before hand? Mar 23 22:26:49 Only then we can get speed. Mar 23 22:27:06 well yeah, that's part of the config for spi Mar 23 22:27:18 bits? hmmm? Mar 23 22:27:45 and because it's such a loose spec, there's almost always some difference between devices on a bus, so it can change from transaction to transaction Mar 23 22:28:05 ds2: spi bits/word Mar 23 22:28:44 ds2,Hey! I mean to calculate the speed,you would either have to know the number of bits the user would send in one particular cycle. Mar 23 22:28:57 alexhiam: what does that matter? Mar 23 22:29:04 ??? Mar 23 22:29:18 wait, yeah, that has nothing to do with the frequency Mar 23 22:29:30 which is essentially bits/sec Mar 23 22:29:36 spi is very simple Mar 23 22:29:44 did I say it did before? Mar 23 22:29:50 on a given edge of the clock, the data line changes Mar 23 22:30:04 here we are talking about clock frequency right? Mar 23 22:30:14 the clock rate is approximate. as long as you are master, it is brain dead Mar 23 22:30:35 yeah, the clock frequency is one configurable parameter Mar 23 22:30:46 which is typically given as the max frequency Mar 23 22:31:17 as spi devices often have a lower max frequency than the max of the spi spec, due to sampling times or whatever Mar 23 22:31:25 If playing games with mark space ratio of clock may need to be a little careful. Mar 23 22:31:39 so the speed is basically related to clock frequency because the number of bits sent in one second would be basically the number of times edge rises/falls Mar 23 22:31:56 Some devices also have a min frequency... Mar 23 22:32:01 the speed IS the clock frequency Mar 23 22:32:26 yes Mar 23 22:32:38 1 edge = 1 bit Mar 23 22:32:44 clock freq is rate of edges Mar 23 22:32:46 Indeed data rate is dependent on device protocol over spi. Mar 23 22:32:56 So the speed wouldnot depend at all at the rate at which we would be writing to the shared mem? Mar 23 22:33:33 no Mar 23 22:33:37 code is for (i = 0; i < 7; i++) { set dataline; clk_edge(); delay_clock_period(); } Mar 23 22:33:45 Because using Rpmsg would induce certain delay IMO because of the extra rpmsg core driver Mar 23 22:33:53 It will but beagle logic showed 100mhz easy enough. Mar 23 22:33:59 rpmsg needs to transfer the entire transaction at once Mar 23 22:34:06 for (i = 0; i < bits_per_word; i++) ;) Mar 23 22:34:23 cuz you need to hold down CS Mar 23 22:34:34 right Mar 23 22:34:48 alexhiam: fine.. off by one... AFAIK, support for 8 bit "words" will cover a lot of cases Mar 23 22:34:50 (unless it's in that other mode where CS is toggled between every word) Mar 23 22:35:06 All hard controllers have a max length just make sure yours is as big. Mar 23 22:35:09 cuz of the way SPI works, longer word sizes aren't really needed (there are no word "boundaries") Mar 23 22:35:16 ds2: yeah, most. Even a lot of devices where the datasheet says it should be something else Mar 23 22:35:48 non multiples of 8 is very troublesome (a lot of HW will have issues) Mar 23 22:35:55 I've certainly run into some devices where it does matter though Mar 23 22:36:00 Sometimes burst reads do require hold if cs for 10s of bytes. Mar 23 22:36:28 so define the CS toggle to happen at transaction boundary Mar 23 22:36:29 the beaglebone McSPI driver crashes with some odd values Mar 23 22:36:32 ds2,Would you want code for any random word size? Mar 23 22:36:54 Because I thought of only 8,16,32 bits Mar 23 22:36:54 chanakya_vc: I think the min and max might be defined in the spi spec... Mar 23 22:36:56 chanakya_vc: I don't really care for anything other then 8 bit Mar 23 22:37:02 16/32 are optimizations Mar 23 22:37:07 Can almost always get away with cunning padding to bytes Mar 23 22:37:18 some sensor I was using a while back needed 12-bit words I think Mar 23 22:37:24 if you look at the wire, 16 looks exactly like 2 x 8 Mar 23 22:37:28 and 16-bit didn't work :( Mar 23 22:37:31 Spi spec? :) good luck finding it Mar 23 22:37:35 lol Mar 23 22:37:40 alexhiam: one of those microchip jobs? Mar 23 22:37:44 spi wiki page is what I mean Mar 23 22:37:50 ds2: can't remember Mar 23 22:37:51 :) Mar 23 22:38:03 might have been some small niche manufacturer Mar 23 22:38:15 seen HW that cna't handle non 8 bit aligned stuff Mar 23 22:38:18 There is no standards body or spec so anything goes. Mar 23 22:38:43 A lot of adapters can't do non byte multiples. Mar 23 22:39:08 of course with soft spi it's pretty trivial to do arbitrary word sizes Mar 23 22:39:12 if it is really an issue - this is a PRU Mar 23 22:39:18 change the damn firmware !#$!@#!#%@#!@!@ Mar 23 22:39:26 lol, good point Mar 23 22:39:33 don't need to cover everything from the start Mar 23 22:39:45 I'll worry about it when they make versions with OTP PRU firmware ;) Mar 23 22:39:47 Extend the firmware and send your extension upstream. Mar 23 22:39:50 :) Mar 23 22:40:27 ds2,alexhiam,So i should say that the max in spi is 100 MHz as jic23b pointed out can be achieved? Mar 23 22:40:38 sure Mar 23 22:41:07 100MHz for a word or 100MHz for a transaction? Mar 23 22:41:16 good question... Mar 23 22:42:09 100mhz for a bit! Mar 23 22:42:11 might also need a maximum transaction size defined for that 100MHz spec Mar 23 22:42:38 Need to do the bit bang on 200mhz pru Mar 23 22:42:44 AFAICT, the only way to do 100MHz half duplex is to unroll things Mar 23 22:43:04 I think 100Mhz is the clock speed?100M falling/rising edges in one second? Mar 23 22:43:10 so it would be am impressive feat to do 100MHz for a full transaction even if you ignore having to drive CS Mar 23 22:43:36 even dealing with MISO will mess up 100MHz Mar 23 22:43:42 100MHz stretch goal ;) Mar 23 22:43:49 So wouldn't that imply that amount of bit speed? Mar 23 22:44:10 40MHz is more realistic (IMO) Mar 23 22:44:17 like clock speed=transfer speed? Mar 23 22:44:24 Good point on half dup. Need to read as well. So slower by a chunk. Agreed 40mhz Mar 23 22:44:25 *frequency Mar 23 22:44:29 chanakya_vc: yes Mar 23 22:45:15 beaglelogic cheats in a lot of places to get the higher datarate Mar 23 22:45:25 ohh.. Mar 23 22:45:52 Theoretical would be 1/3 200M I think with uneven matkspace Mar 23 22:45:57 Markspace Mar 23 22:46:51 Still quickish should be possible! Mar 23 22:46:54 But in the end it just depends upon the clock frequency right ?It is only limited upon our ability to generate higher clock frequency from PRU? Mar 23 22:47:25 Off now, bye Mar 23 22:48:22 it may be advisable to aim for something like 10MHz for an initial firmware; get the rest of the drivers working; then come back and work on getting the higher clock rates Mar 23 22:51:06 Okay. So to get 10Mhz,I would just have to get my firmware to generate a 10 MHz clock right? Mar 23 22:51:25 while clocking out data Mar 23 22:51:31 that's the tricky part about getting timing right Mar 23 22:51:47 a low data rate would give a lot more slack for suboptimal code Mar 23 22:52:26 Okay. I now get your point about CS .I mean the time complexity of the code should be such that it actually toggles the clock at 10 Mhz right? Mar 23 22:53:23 So holding down CS would actually add to this time right? Mar 23 22:53:30 are there any good examples of "tight" pru code? Mar 23 22:53:52 besides a few assembly instructions... Mar 23 22:56:30 ds2,The speed for I2C would be somewhere in kilohertz I believe then? Mar 23 22:57:08 100Khz-200Khz? Mar 23 23:01:55 * nerdboy 's butt says spi tops out around 400 k/sec and i2c about 50 k/sec Mar 23 23:02:09 transfer speed, not clock rate Mar 23 23:03:04 in theory "ultra" i2c or whatever it is goes to 3.4MHz? Mar 23 23:03:12 is that correct? Mar 23 23:04:24 oh, it's high speed mode beaglebone only does standard/fast on the built-in 12c buses Mar 23 23:05:01 yeah, 3.2MHz I think Mar 23 23:05:10 ultra is 5MHz Mar 23 23:05:13 and weird Mar 23 23:08:38 alexhiam, For I2C, does 100khz to 200 khz sound okay? Mar 23 23:09:06 i2c doesn't use arbitrary clock rates Mar 23 23:09:22 well, I guess technically it can Mar 23 23:09:29 since the master controls the clock Mar 23 23:09:53 what would you suggest then? Mar 23 23:09:58 isn't 100kHz pretty limiting? Mar 23 23:10:09 ideally it would run at 400kHz Mar 23 23:11:09 spi claims data rates up to 50 Mbps Mar 23 23:11:40 Well I can start with 200-300 Khz and say that goal is to reach 400 khz? Mar 23 23:12:12 *my goal is to saturate the bus and see what happens... Mar 23 23:12:20 I think it is just a question of optimizing the firmware code for better time complexity? Mar 23 23:12:46 I guess i2c does allow arbitrary values. Yeah, 100MHz-200MHz sounds fine as an initial goal Mar 23 23:13:12 not sure how unfeasible 400kHz would be though Mar 23 23:13:29 might not really be a problem Mar 23 23:13:57 and I would say supporting clock stretching is probably a must Mar 23 23:14:33 back to task scope, make sure it looks sane... Mar 23 23:14:52 Okay.I will have to research a bit on code optimization.By clock stretching you mean running the clock at higher frequencies? Mar 23 23:14:59 * nerdboy instinctively breaks the doubling rule Mar 23 23:15:11 Like on user demand of higher frequency? Mar 23 23:15:11 no, it's a part of the i2c spec Mar 23 23:15:20 i think he means stretching a cycle? Mar 23 23:15:38 Okay will have to go through that. Mar 23 23:15:56 the slave can hold the clock line down for a little bit if it needs time to take a sample or something Mar 23 23:16:28 kinda like adding a leap-second... Mar 23 23:16:45 I am almost done with my proposal. I will submit it by tomorrow evening(in my time zone) Mar 23 23:16:54 nearly 4 am here Mar 23 23:17:03 which means the master has to tri-state the clock every rising edge and wait for it to go high Mar 23 23:17:37 oh wait.... the PRU pins are only inputs or outputs.... Mar 23 23:17:47 how is i2c gonna work? Mar 23 23:17:56 I mean they're not muxed Mar 23 23:18:11 good reason not to hard-code a fixed cycle time... Mar 23 23:19:43 you know the primary ardupilot/mavlink position messages are fused sensor solution Mar 23 23:19:47 PRU pins are not muxed? Mar 23 23:20:03 it has kalman filters and everything Mar 23 23:20:08 ds2: have you thought about muxing for i2c? Mar 23 23:20:47 chanakya_vc: only through the control module muxes, the PRU signals are fixed to ins and out I think... Mar 23 23:21:46 right? Mar 23 23:22:29 alexhiam, Doesn't the DTO configure the pinmux register? Mar 23 23:22:39 I am not sure. Mar 23 23:24:10 So the problem is basically with the tristate part (with the clock) right? Mar 23 23:24:55 with the clock for clock stretching support, but also with the data line Mar 23 23:25:00 which is bidirectional Mar 23 23:25:41 Is there a particular format for submitting the proposals? Mar 23 23:26:21 Cause all of the previous years proposals are in a particular format, and I'm not able to find that info anywhere! Mar 23 23:27:14 yashoza: https://summerofcode.withgoogle.com/organizations/4817552005922816/ Mar 23 23:27:23 (scroll down) Mar 23 23:27:32 file format is google doc for draft and pdf for "final" Mar 23 23:27:39 and submit ASAP! Mar 23 23:28:07 Yes,that would be a problem.For this the PRU firmware should be able to do pinmuxing? Mar 23 23:28:20 I donot think that is possible Mar 23 23:28:35 about 48 hrs left? Mar 23 23:28:36 Thanks alexhiam! Mar 23 23:28:48 well, it needs GPIO pins that can be inputs and outputs Mar 23 23:29:08 or some external hardware Mar 23 23:29:13 I have also replied to your comments! Take a look when possible! Thanks! Mar 23 23:30:32 yashoza: looking now - you should definitely submit to summerofcode.withgoogle.com now Mar 23 23:30:48 ohhhh nvm, you did :P Mar 23 23:30:56 yep! just filling up the details! Mar 23 23:31:08 :D Mar 23 23:31:13 so many google docs! Mar 23 23:35:50 i didn't see any ranting/cursing... email okay? Mar 23 23:36:53 alexhiam, Perhaps we feed SDA into two pins.One would read SDA for any incoming data and if the SDA dataline is not low,the other could transmit on the same line? Mar 23 23:38:12 alexhiam, ds2 ,I do not see any other way of doing it.Unless there is some way to change the muxing of the pins on the go?I believe only DTO can do it? Mar 23 23:38:23 chanakya_vc: the output will be driving it at 3.3V or 0V Mar 23 23:39:46 Yes the SDA could be kept high at 3.3 V? Mar 23 23:40:23 Although this would create problems with the other devices on the bus. Mar 23 23:40:39 which would then keep it at 3.3V the whole time Mar 23 23:41:00 basically equivalent to wiring the data line to the 3.3V regulator output Mar 23 23:41:26 Yes.I think in i2c,the master that transmits last has the duty of keeping SDA high? Mar 23 23:41:28 it would work, as long as you were expecting every bit to be 1... Mar 23 23:41:52 the pull-up resistor keeps SDA high Mar 23 23:43:10 I don't think there's any way to do it except an external mux Mar 23 23:44:27 Ohh.Let me research a bit and get back to you. Mar 23 23:45:38 You would get an external multiplexer for it? Mar 23 23:46:36 well, you basically need some external hardware to let you switch the SDA line between an input and an output Mar 23 23:47:02 as well as the clock if supporting stretching Mar 23 23:47:07 Okay. Mar 23 23:47:23 and it needs to have appropriate slew rate and switching speed **** ENDING LOGGING AT Thu Mar 24 02:59:58 2016