**** BEGIN LOGGING AT Wed Jun 15 02:59:58 2016 Jun 15 06:42:43 nerdboy: yeah . I am on 12-ti-r30 Jun 15 12:34:49 ZeekHuge, when you have slept :) + nerdboy : TI tree only gained those rproc changes on Monday. Well after their r30. Jun 15 12:34:59 Merge commit was : https://git.ti.com/ti-linux-kernel/ti-linux-kernel/commit/4cc71c5a52a1a9631a11b22524b2455baa3956ed Jun 15 12:37:22 any of the PRU projects referencing https://git.ti.com/pru-software-support-package ? Jun 15 12:42:00 jkridner: should they be? Jun 15 12:42:19 bradfa: not sure.... seems it has rproc examples now. Jun 15 12:42:23 jkridner: chanakya_vc is using the pru code gen tools Jun 15 12:43:22 jkridner: interesting to see that mailboxes are going away rsn... am57xx still has mailboxes... Jun 15 12:44:03 chanakya_vc: probably worth taking a look at this and seeing if the examples fit your needs better than what's in the ti linux sdk in terms of PRU interfacing Jun 15 12:44:39 jkridner: we kanged a few BSD licensed things from the ti linux sdk package (it's a pain in the rear to get installed so kanging is much easier to deal with long term, I think) Jun 15 12:45:15 * jkridner googles "kanged" Jun 15 12:46:11 got it http://www.urbandictionary.com/define.php?term=kanged Jun 15 12:46:28 jkridner: it's the proper way to use BSD licensed code :) Jun 15 12:46:51 re-writing based on use/inspection seems fine, but it would be handy to get some of it contributed to http://github.com/beagleboard/am335x_pru_package for folks. Jun 15 12:48:13 jkridner: I think the biggest thing holding back PRU development is serious lack of up-to-date information which people can just take and use directly, TI seems to keep changing interfaces around and putting out new docs but not always taking down the old ones, so it gets confusing fast (speaking as a TI customer, not gsoc mentor, but it applies to gsoc too) Jun 15 12:48:38 jkridner: there's not even detailed information that's easy to get from the am335x product page on ti.com Jun 15 12:48:49 jkridner: no idea if you can help to make this less bad or not, but thought I'd mention Jun 15 12:49:11 jkridner: the wiki.ti.com is pretty decent for what it has Jun 15 12:49:45 Hey bradfa ,Yes I checked on that.Mailboxes are going away.Instead of it would be based on A8 Jun 15 12:49:49 taking down old docs is controversial. trick is to figure out what old software works with what old docs. :( Jun 15 12:50:19 jkridner: yeah, I can understand that. But then the old docs should be ammended to add links to the new docs and say why the new doc exists Jun 15 12:50:33 bradfa: I can certainly influence some changes, but it is difficult without specific tasks... the effort is defining those specific tasks. Jun 15 12:50:47 bradfa: adding forwarding links makes a lot of sense. Jun 15 12:51:29 scanning for any pages that mention PRU and aren't the latest, then adding forwarding links to those pages seems like a comprehensible task. Jun 15 12:51:57 chanakya_vc: mailboxes are going away in future TI silicon, but TI examples are pushing everyone away from using mailboxes. So don't count mailboxes out for your needs yet Jun 15 12:52:08 chanakya_vc: on AM57xx the mailbox system is much bigger than on AM335x Jun 15 12:52:12 bradfa, Regarding the TI sdk,should I upload the entire folder or only the include folder?And now I presume the RPMsg lib would no longer be useful as things have changed? Jun 15 12:52:30 Okay got you bradfa... Jun 15 12:52:43 chanakya_vc: what do you mean "upload"? Jun 15 12:52:55 push Jun 15 12:53:13 I haven't added the TI sdk in my repo so far bradfa Jun 15 12:53:48 You said that we could since it had a BSD license right? Jun 15 12:54:55 Instead of defining the PRU_SW_PKG variable. I will do so immediately. Jun 15 12:57:19 chanakya_vc: I sent you a pull request which removes the need for having the TI linux SDK in order to compile Jun 15 12:57:35 Yes I know that bradfa Jun 15 12:58:02 I just wanted to ask that do you want me to have the include folder also in my repo? Jun 15 12:58:07 chanakya_vc: as you need more headers or a lib or two from one of the examples in the ti linux sdk, just copy the needed file into your repo (but make sure it is BSD or GPL licensed first, if it isn't then shout) Jun 15 12:58:33 chanakya_vc: yes, the include dir in my pull req is where headers should go based on your layout of files Jun 15 12:59:31 Okay got it bradfa .I think all the headers would have BSD license.I mean no dev for the PRU is possible without them. Jun 15 12:59:58 jkridner: it's interesting to see the PRU examples moving away from using the mailbox and the comments in some of the commits on the pru-software-support-package code saying that mailboxes are going away. iirc, the M4 and DSP in AM57xx don't have the interrupt interfaces that the PRUs have, they would need to use mailboxes Jun 15 13:00:19 chanakya_vc: yes. Just only copy over what you absolutely need Jun 15 13:00:23 nothing else Jun 15 13:03:53 bradfa, Many of the headers themselves have other dependencies on other others.I think it would be good to push the entire include folder(given in the TI SDK).Otherwise there is a chance that code might not compile Jun 15 13:06:57 bradfa, And I would also push the RPMsg. lib file(again given in the TI sdk folder).It would be required if we use RPMsg. Jun 15 13:10:46 chanakya_vc: just grab what you need. If you end up needing everything, then it's time to rethink the strategy of copying what you need. Jun 15 14:34:21 I wonder if it's safe to assume that the PRU C compiler will put a static array in a contiguous block of RAM? Jun 15 15:22:29 http://elinux.org/Ti_AM33XX_PRUSSv2 <= usefu; Jun 15 15:22:36 *useful even Jun 15 15:25:30 hi nerdboy ! I tried 12-ti-r30, its not the latest rpmsg in it. Jun 15 15:25:39 ds2: hi ! you there ? Jun 15 15:44:18 wtf is latest then? Jun 15 15:48:36 _av500_ alexhiam:hi, now I'm going to take an exam. I'll read irc logs when I come back. Jun 15 15:48:37 be nice to get a definitive answer... Jun 15 15:48:59 pmezydlo: good luck! Jun 15 15:49:24 thanks Jun 15 15:49:26 bye bye Jun 15 15:49:58 the rcn tree has the latest rproc stuff from TI afaik Jun 15 15:50:51 ZeekHuge: where are you seeing newer stuff than is in r30? Jun 15 15:52:19 http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=a4c5877aeb147a2d8b6f392f1fd9dd712655a2bf Jun 15 15:52:28 ARM: dts: AM33xx: Replace mailboxes with PRU system events Jun 15 15:52:33 alexhiam: ^ Jun 15 15:52:59 nerdboy: this is the newer stuff Jun 15 15:53:05 ohh, they got a branch for that Jun 15 15:53:19 ZeekHuge: you could build from that branch Jun 15 15:53:26 http://git.ti.com/pru-software-support-package/pru-software-support-package/commit/69805828df0f262fb60363c2db189d1b8d0b693c Jun 15 15:53:29 though who knows if it's working Jun 15 15:53:57 the latest pru-software package wont work anymore Jun 15 15:54:22 nice Jun 15 15:55:20 ZeekHuge: how's it not working? Jun 15 15:56:00 wow, the software support package has a bunch o' changes Jun 15 15:56:09 is there a corresponding branch/commit for cgs tools or something? Jun 15 15:56:15 would have been nice for them to do that stuff on a different branch... Jun 15 15:56:27 The older one was using interrupts from mailbox. the latest one are using interrupts from the A8 INTC itself Jun 15 15:56:53 ZeekHuge: apparently some not yet released parts from TI are getting rid of the mailbox system Jun 15 15:57:06 well that sounds like an improvement at least Jun 15 15:57:13 ZeekHuge: these new parts will have PRUs but no mailboxes, so to be generic, PRUs now always just use the INTC interface Jun 15 15:57:31 <_av500_> aloo Jun 15 15:57:36 so the interrupt numbers or system events to say, in the PRU code need to be changed . Jun 15 15:57:37 alexhiam: sure, except it doesn't work for anything but PRU. On AM57xx afaik there's only mailboxes to talk to the M4s and DSP Jun 15 15:57:55 alexhiam: and you still use mailboxes to talk to the M3 power control micro in am335x Jun 15 15:57:58 bradfa: but we are instructed to use latest images by r Jun 15 15:58:01 bradfa: are they removing mailbox support entirely or just for prus? Jun 15 15:58:03 *rcn Jun 15 15:58:17 alexhiam: not sure, I don't have docs, just the same info you guys have access to Jun 15 15:58:34 ZeekHuge: I'm just giving background, not trying to tell you waht to do Jun 15 15:58:53 okay. Jun 15 15:59:12 alexhiam: if I did know the answer about removing mailboxes, likely I'd be under NDA to not tell you, so... ;) Jun 15 15:59:59 can we ask RCN ti use the latest things and built an image ? Jun 15 16:00:05 *to Jun 15 16:00:26 looks like version 4.0.whatever has the interrupt version of examples Jun 15 16:00:33 TI hasn't merged that to their kernel tree yet Jun 15 16:00:52 rpmsg on ti-rt-linux-4.4.y is identical to rcn 4.4 Jun 15 16:01:28 which makes it pretty annoying that they updated the software support package's master branch already! :| Jun 15 16:02:09 ah, I guess that rpmsg repo is a kernel tree... Jun 15 16:02:18 but not the one rcn pulls from Jun 15 16:02:31 so what's the answer then? Jun 15 16:03:19 I'm gonna try building from that tree... Jun 15 16:03:51 which tree? kernel with new stuff? Jun 15 16:04:23 yeah Jun 15 16:04:37 git.ti.com/rpmsg/rpmsg Jun 15 16:05:02 rpmsg-ti-linux-4.4.y branch Jun 15 16:06:13 is everyone else cloning it too?? their git server seems a bit slugish right now... Jun 15 16:06:25 alexhiam: ti's git server? it's always sluggish Jun 15 16:07:06 yup Jun 15 16:07:36 one question : so this rpmsg is basically a platform specific implementation ? do things like that get mainlined ? I mean can they be pushed to linus' tree, as they only support a specific platform. further, does the two different implementation (one A8 INTC other mailbox) affect that mainlining thing ? Jun 15 16:08:10 ZeekHuge: things like this mailbox/intc interface for rpmsg can get mainlined, yes Jun 15 16:08:10 _av500_, av500: you around? Jun 15 16:08:16 <_av500_> yes Jun 15 16:08:22 <_av500_> 0) WELCOME ALL Jun 15 16:08:31 <_av500_> 1) who's here? Jun 15 16:08:35 hi all Jun 15 16:08:37 Hi Jun 15 16:08:40 hey Jun 15 16:08:40 hi Jun 15 16:09:00 <_av500_> 3 Jun 15 16:09:01 hello everyone ! Jun 15 16:09:04 <_av500_> 4 Jun 15 16:09:14 chanakya_vc: say hi Jun 15 16:09:25 hey av500 Jun 15 16:09:29 :) Jun 15 16:09:38 Morning Jun 15 16:09:40 hi bradfa :) Jun 15 16:10:13 <_av500_> no kiran? Jun 15 16:10:18 :( Jun 15 16:10:24 hmmm Jun 15 16:10:35 <_av500_> pmezydlo excused himself Jun 15 16:10:57 I saw kiran's report appear an hour ago... Jun 15 16:11:31 <_av500_> yeah Jun 15 16:13:01 <_av500_> ok Jun 15 16:13:12 <_av500_> 2) hardware shipments Jun 15 16:13:22 <_av500_> anybody still waiting for anytin[D[Dhg? Jun 15 16:13:27 <_av500_> anything Jun 15 16:13:41 PCBs should arrive next week from China Jun 15 16:14:00 <_av500_> ok Jun 15 16:14:03 jkridner: hi ! can i get the tracking number please ? Jun 15 16:14:11 no dependencies at this point however Jun 15 16:14:14 <_av500_> ok Jun 15 16:14:15 of that ADC EVM Jun 15 16:14:15 <_av500_> good Jun 15 16:15:49 okay I'll write a mail to jkridner requesting for the tracking number. Jun 15 16:15:52 <_av500_> so only ZeekHuge waiting? Jun 15 16:15:59 <_av500_> everybody else is set? Jun 15 16:16:01 let me look Jun 15 16:17:16 we have it all but the grove stuff is not well supported Jun 15 16:17:34 <_av500_> nerdboy: meaning? Jun 15 16:17:55 seems like ustream stopped a year ago after uploading a bunch of half-written python code... Jun 15 16:18:34 kinda sad, since berryimu has what they're missing Jun 15 16:18:46 <_av500_> nerdboy: I know some of these words Jun 15 16:18:55 except written for completely different imu chips Jun 15 16:19:03 <_av500_> can I conclude we are almost good on HW, only ZeekHuge waiting for shipment? Jun 15 16:19:14 ZeekHuge: you should have it today Jun 15 16:19:20 <_av500_> ok Jun 15 16:19:28 <_av500_> moving on Jun 15 16:19:31 ds2: okay Jun 15 16:19:31 <_av500_> 3) reports Jun 15 16:19:57 <_av500_> I count roughly seven Jun 15 16:20:58 nerdboy: is this for visaoni's project? if so, what are teh chips on that IMU? Jun 15 16:21:42 <_av500_> ds2: please after the meeting Jun 15 16:21:48 9250 is the main one Jun 15 16:22:16 <_av500_> nerdboy: dito Jun 15 16:22:27 'k Jun 15 16:22:34 <_av500_> 4) midterms are soon Jun 15 16:22:39 <_av500_> time flies Jun 15 16:22:45 <_av500_> 27th is the evaluation deadline Jun 15 16:22:59 <_av500_> as usual, work with your mentors Jun 15 16:23:08 <_av500_> make sure you are not blocked on anything Jun 15 16:23:13 <_av500_> shout if you need help Jun 15 16:23:18 <_av500_> dont wait for wednesday Jun 15 16:23:27 _av500_: evaluation period opens on the 20th, right? ends on 27th? Jun 15 16:23:32 <_av500_> #yes Jun 15 16:23:36 <_av500_> yes Jun 15 16:23:54 someone has not verified their hardware is working yet Jun 15 16:23:55 <_av500_> bradfa: there was a mail from google you should have Jun 15 16:24:10 _av500_: yes, found it, thanks Jun 15 16:24:24 might need replacement Jun 15 16:24:28 do the primary mentors know who they are? Jun 15 16:24:47 only one mentor is supposed to evaluate student, who should do it? Jun 15 16:25:03 <_av500_> rma_: you for your project Jun 15 16:25:13 primary Jun 15 16:25:20 <_av500_> should I send out a mail to mentors later? Jun 15 16:25:21 should be working with adc/sonic parts so not really blocked yet... Jun 15 16:25:27 ok, thx Jun 15 16:25:28 <_av500_> nerdboy: ok Jun 15 16:25:37 <_av500_> aynway, lets move on Jun 15 16:25:57 <_av500_> as said, please shout out if there is something amiss Jun 15 16:25:57 everything "grove" checks out here so far Jun 15 16:26:13 <_av500_> applies to students and mentors Jun 15 16:26:26 <_av500_> 5) anthing else before we start the status reports? Jun 15 16:27:09 <_av500_> students still here? Jun 15 16:27:23 yep Jun 15 16:27:27 Yes Jun 15 16:27:33 me too Jun 15 16:27:47 yup Jun 15 16:28:23 <_av500_> good :) Jun 15 16:28:35 <_av500_> just checking Jun 15 16:28:40 <_av500_> 6) standup reports Jun 15 16:28:49 <_av500_> I have amragaey Jun 15 16:28:56 <_av500_> and Visaoni Jun 15 16:29:02 yes Jun 15 16:29:08 <_av500_> amragaey: want to start? Jun 15 16:29:13 okay Jun 15 16:29:30 <_av500_> you have the stage Jun 15 16:29:39 hi :D Jun 15 16:29:51 My project is improving bone101 experience, currently writing javascript. Jun 15 16:30:13 I started on project by solving bugs and errors to debug html-proofer for Travis to have a passing build Jun 15 16:30:50 during this, I discovered new aspects in project and added a separate breadcrumb for bonescript examples. Jun 15 16:31:06 and I intend to fix and enhance the code of this part after finishing my project scope. Jun 15 16:31:28 I’m working now on first phase of the project, reimplementing BBUI Jun 15 16:31:47 the old version is here : http://jadonk.github.io/Beaglebone-UI/BBUI.html Jun 15 16:32:11 and I’m following the old structure to go on the new structure which consists mainly of 3 objects beside Canvas: UI, Hardware, Events. Jun 15 16:32:37 I was stuck first with canvas and dimensions as I wasn’t able to debug canvas in browser and there are no enough comments on code. Jun 15 16:33:19 But after some time I got used to it, debugging in regular JS console.. and started making progress Jun 15 16:33:45 <_av500_> good Jun 15 16:33:45 I fixed old dimensions of UI, wrote a function to draw the x-y graph, neglecting the negative voltage and rescaling the old voltage. Jun 15 16:34:26 I wrote a function for the buttons of the graph and made sure that it responds to events and changing their behavior. Jun 15 16:35:08 I have also fixed the welcome area dimensions and text. Jason told me that text is filled out of the text area, I saw this happening in firefox but normal in chrome. I fixed that yesterday and hope it’s fine now cross browsers. Jun 15 16:35:38 here are my version: http://amragaey.github.io/bone101/Support/bone101/UI/ Jun 15 16:36:14 Now the canvas object is done, the UI object which is responsible for the actual drawing in canvas is in progress, so I’ll go the next days with Events beside UI to add/integrate missing event listeners. Jun 15 16:37:47 that's all : ) Jun 15 16:38:50 <_av500_> good ;) Jun 15 16:38:57 <_av500_> thank you Jun 15 16:39:00 it says it connected to bb but didn't do anything Jun 15 16:39:14 seems like it works in ff so far Jun 15 16:39:36 nerdboy, the hardware part is not ready yet. Jun 15 16:40:04 this will be the last part as agreed with Jason. Jun 15 16:41:13 <_av500_> ok Jun 15 16:41:16 <_av500_> thank you again Jun 15 16:41:27 <_av500_> Visaoni: you are up Jun 15 16:41:31 alright Jun 15 16:41:38 hey everybody Jun 15 16:42:00 so I'm working on the sonic anemometer project Jun 15 16:42:31 as nerdboy has mentioned, I've discovered the grove stuff is not so well supported Jun 15 16:42:52 * nerdboy played local CA parts distributor Jun 15 16:43:05 indeed :) Jun 15 16:43:36 this sort of led me astray, as I mentioned in my report this week Jun 15 16:44:03 still got some Finnish board games left if anyone wants one... Jun 15 16:44:25 I've also had some problems connecting with the board. ssh/webserver access falls in and out. virtual serial does too, but seems somewhat more reliable Jun 15 16:45:07 power source still just udb port? Jun 15 16:45:13 *usb even Jun 15 16:45:30 mostly, but I have tried dedicated power Jun 15 16:45:47 the setup for that is problematic enough I haven't given it a proper test for the ssh/etc problems Jun 15 16:46:12 grove as in BBG stuff? Jun 15 16:46:17 yes Jun 15 16:46:29 that should be I2C isn't it? Jun 15 16:46:42 some of it is, some of it is just gpio Jun 15 16:47:29 at any rate, before this gets too off the rails Jun 15 16:47:35 Visaoni: will you be around this afternoon? Jun 15 16:47:40 yes, I will Jun 15 16:48:18 you still getting errors on i2c? Jun 15 16:48:34 yes Jun 15 16:49:02 before or after running i2cdetect? Jun 15 16:49:12 both Jun 15 16:49:16 slow it down Jun 15 16:49:21 check pull ups Jun 15 16:49:31 if there is no external pull ups, add one Jun 15 16:49:33 run bus at 100KHz Jun 15 16:50:11 the breakouts are supposed to have all of that afaik Jun 15 16:51:06 if i stay away from i2cdetect and just leave the standard overlay enabled they seem to work Jun 15 16:51:27 I'm not sure how I would add an external pull up to the breakouts Jun 15 16:51:31 * nerdboy using ethernet and 1 A power brick Jun 15 16:51:50 I've tried it with ethernet and a 2A brick, same problems Jun 15 16:53:23 can you try bypassing the grove connector? jumper wires and/or another i2c device? Jun 15 16:54:00 I suppose so Jun 15 16:54:13 i *think* the bus 2 pins are also accessible on the bb Jun 15 16:54:27 looks like the uart2 pins are Jun 15 16:55:07 * nerdboy guessing bad hardware Jun 15 16:55:30 how fast can we get another green? Jun 15 16:56:05 I'd probably be inclined to try it on another bus Jun 15 16:56:46 which bus are the grove connectors on? Jun 15 16:56:56 Visaoni: what kernel version? is it the image that came with it? is the universal-io overlay loaded? are you manually loading overlays for the parts? Jun 15 16:57:01 12c-2 Jun 15 16:57:05 Visaoni: what city are you in? Jun 15 16:57:06 i2c2 and uart2 (but using uart rx as gpio) Jun 15 16:57:55 Visaoni: do you have a scope so you can look for activity on the bus when you run i2cdetect? are you sure the pins are muxed right? Jun 15 16:58:51 alexhiam: I updated to the latest image from bb.org. 4.4.11-ti-r29 Jun 15 16:58:58 no scope, unfortunately Jun 15 16:59:01 <_av500_> Visaoni: thansk for the status report Jun 15 16:59:16 Visaoni: are you in the SF Bay area? Jun 15 16:59:17 <_av500_> thanks* Jun 15 16:59:24 ds2: no, I'm down south Jun 15 16:59:29 <_av500_> who did not give a report yet? Jun 15 16:59:31 doh Jun 15 16:59:31 Visaoni: that means you should have universal-io loaded by default. have you muxed the pins with config-pin? Jun 15 16:59:38 av500: kiran Jun 15 16:59:42 <_av500_> ok Jun 15 16:59:50 <_av500_> a 2nd volunteer? Jun 15 17:00:08 who went first? Jun 15 17:00:09 alexhiam: I haven't. I've tried it both with and without loading BB-I2C2 but that's about it Jun 15 17:01:08 i didn't do anything special except install some python libs Jun 15 17:01:24 mostly adafruti stuff Jun 15 17:01:36 Visaoni: I'd recommend a full power down - remove power - boot up, then use config-pin to set the i2c pins to i2c mode and try the software (no i2cdetect, it can confuse devices) Jun 15 17:01:40 *ada-tutti-frutti even Jun 15 17:02:06 * alexhiam has to run, but can help with grove debugging in a couple hours Jun 15 17:02:15 <_av500_> alexhiam: thank you Jun 15 17:02:30 <_av500_> I will send a mail for next weeks "volunteers" :) Jun 15 17:02:36 Visaoni: anything to report on adc evm? Jun 15 17:02:42 * _av500_ needs to go too Jun 15 17:02:48 <_av500_> thanks everybody Jun 15 17:02:54 <_av500_> see you next week Jun 15 17:03:04 sure :) Jun 15 17:03:07 not yet. mostly been reading/planning to make sure I don't do anything too stupid with it Jun 15 17:03:10 ok, thanks _av500_ Jun 15 17:03:23 alexhiam: great, I'll give that a shot Jun 15 17:04:09 bradfa, Got to run an errand for my mother.Be back in 20 minutes.Are you free after that today? Jun 15 17:04:42 hi, I am, easy exam Jun 15 17:04:44 ;) Jun 15 17:05:17 bradfa, I have to discuss DMA with you. Reading from here:https://github.com/hvaibhav/am335x-linux/blob/master/Documentation/DMA-API-HOWTO.txt Jun 15 17:05:26 chanakya_vc: I'll be in and out due to meeetings, but just write me and I'll see it when I'm at my desk Jun 15 17:06:58 this is what we have so far for sensor test/query => https://github.com/VCTLabs/py-sensor-test Jun 15 17:07:34 * nerdboy still needs to update readme Jun 15 17:07:50 bradfa, Okay. I am confident of getting a driver to send in information to the shared mem up by next week .After the firmware seems to working fine. Jun 15 17:08:12 chanakya_vc: ok Jun 15 17:08:33 bradfa, If I get this part right.won't take me much time to get it up with all the features Jun 15 17:08:34 the mpu6050 stuff works with 9250 parts, just not the magnetometer Jun 15 17:08:44 chanakya_vc: sounds good! :) Jun 15 17:08:49 so i did talk to the imu Jun 15 17:09:17 bradfa, Right now I am only working for sending data. I will look at parameters once I successfully complete this bit : ) Jun 15 17:09:27 chanakya_vc: ok Jun 15 17:09:55 but we can't use niko's 9250 pybbio lib since it is SPI only, and the grove breakout is i2c only Jun 15 17:10:45 * chanakya_vc goes afk. Back in 20 minutes Jun 15 17:11:30 adafruit_dht works with grove, just use uart2 pin Jun 15 17:11:49 pybbio needs more libs... Jun 15 17:16:47 ds2 : there ? Jun 15 17:24:03 on a call. something quick? Jun 15 17:24:23 hm, config-pin is telling me the pins aren't "modifyable". but they seem to be configured as i2c anyway Jun 15 17:37:36 ZeekHuge? Jun 15 17:38:41 ds2: Oh yeah ! So you were saying about the how to get data out from the ADC, so essentially you were talking about the clock ? Jun 15 17:44:00 Sorry!! Jun 15 17:44:05 Did I miss something?? Jun 15 17:44:10 is the meeting still going on? Jun 15 17:45:44 nope your late Jun 15 17:45:59 Crap!! Actually I was travelling Jun 15 17:46:11 No internet.. :( Jun 15 17:47:42 well you can look that log now and see what you missed Jun 15 17:47:51 http://logs.nslu2-linux.org/livelogs/beagle-gsoc.txt Jun 15 17:48:21 alexhiam: sorry... missed the meeting.. what shall we do about the cape? Jun 15 17:48:47 kiran4399: you are up for a report next week it looks Jun 15 17:49:11 alexhiam: yeah.. am reddy.. Jun 15 17:49:14 *ready Jun 15 18:26:02 alexhiam, There? Jun 15 18:26:16 yeah Jun 15 18:26:45 I have been reading up on DMA from here https://github.com/hvaibhav/am335x-linux/blob/master/Documentation/DMA-API-HOWTO.txt Jun 15 18:27:13 alexhiam, But I cannot yet understand how to set up DMA to a specific mem address Jun 15 18:28:00 It talks about address returned by kmalloc() and all Jun 15 18:28:33 chanakya_vc: beaglelogic uses DMA iirc Jun 15 18:29:25 https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/beaglelogic.c#L164 Jun 15 18:31:25 alexhiam, Okay got to read up on this. I have no idea regarding DMA IIRC Jun 15 18:32:08 iirc == if I recall correctly Jun 15 18:32:24 beaglelogic uses regular dma :P Jun 15 18:32:47 alexhiam, Ohh :P Jun 15 18:33:20 alexhiam, So the document whose link I gave is the right place to read about it? Jun 15 18:34:06 * chanakya_vc worried about reading outdated stuff and get confused Jun 15 18:35:46 https://github.com/beagleboard/linux/blob/4.4/Documentation/DMA-API-HOWTO.txt Jun 15 18:35:50 https://github.com/beagleboard/linux/blob/4.4/Documentation/DMA-API.txt Jun 15 18:36:01 you know those ones aren't outdated Jun 15 18:47:54 Visaoni: any luck? Jun 15 18:48:29 Visaoni: which i2c dev interface are you using? Jun 15 18:49:18 alexhiam: no luck yet. pin-config was saying the pins weren't modifiable, but listed them as already being setup for i2c Jun 15 18:49:30 i2c2 Jun 15 18:49:58 er, config-pin Jun 15 18:49:59 Visaoni: /dev/i2c-2? are you sure that's the right one? Jun 15 18:50:38 ls -l /sys/bus/i2c/devices/i2c-* Jun 15 18:51:23 will show you the base addresses of each i2c dev file, which you can cross reference with the AM335x TRM Jun 15 18:52:12 yes, and as long as the BBG docs are right then yes I'm sure Jun 15 18:52:42 you see 'devices/platform/ocp/4819c000.i2c/i2c-2'? Jun 15 18:53:23 yep Jun 15 18:53:43 k. what code are you using? Jun 15 18:53:47 and which sensors Jun 15 18:56:03 https://github.com/VCTLabs/py-sensor-test . using the grove temp/humidity pro (dht22) and grove 10DOF imu (bmp180 barometer + grove 9dof (MPU-9250)) Jun 15 18:56:57 those scripts are working for nerdboy? Jun 15 18:57:03 correct Jun 15 18:57:51 Visaoni: there's kernel drivers for all those devices, which would probably be a better way to use them Jun 15 19:00:23 we can't use spi, only i2c Jun 15 19:01:09 the inv_mpu6050 driver supports both Jun 15 19:02:06 the grove board does not Jun 15 19:02:18 I mean it's either or Jun 15 19:03:31 the grove board has one connector, with only the 4 i2c pins brought out Jun 15 19:03:58 i don't see how you could use spi without major surgery Jun 15 19:04:02 ohhh, no interrupt? that really limits what you can do with the imu :( Jun 15 19:04:40 kiran is using the 9250 over i2c, that's what's on the beaglebone blue Jun 15 19:04:47 it's working with the driver Jun 15 19:05:18 what driver? Jun 15 19:05:30 the inv_mpu6050 kernel driver Jun 15 19:05:41 the strawson stuff? Jun 15 19:05:48 needs a few patches from the iio ml to get the mag working Jun 15 19:06:10 no, the strawson stuff is all userspace Jun 15 19:06:11 yeah, 6050 is only accel/gyro Jun 15 19:06:26 and the bmp? Jun 15 19:06:28 https://github.com/beagleboard/linux/tree/4.4/drivers/iio/imu/inv_mpu6050 Jun 15 19:06:40 https://github.com/beagleboard/linux/blob/4.4/drivers/iio/pressure/bmp280.c Jun 15 19:07:04 https://github.com/beagleboard/linux/blob/4.4/drivers/iio/humidity/dht11.c Jun 15 19:07:45 the 9250 appears to have I2C_SLV0-5 in registers Jun 15 19:07:59 does the driver use that stuff? Jun 15 19:08:50 there's some patches to add support for the auxiliary i2c bus on the iio ml. Haven't been upstreamed yet, but jic23 applied them to the rcn tree on a branch here: https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/?h=experimental-beaglefun Jun 15 19:09:11 which the last handful of commits can be cherry picked from Jun 15 19:09:43 do you need the mag? you could just use the stock driver for accel+gyro only Jun 15 19:11:00 mag + barometer is basically the point of the thing :) Jun 15 19:11:38 k, then those patches would certainly be helpful Jun 15 19:25:46 alexhiam, bradfa So what I have understand of DMA,that inorder to access memory for an I/O device,it goes through a bus(which has an address).Now this bus address can be achieved by some offset from the CPU physical memory space? Jun 15 19:26:35 chanakya_vc: look at the memory map in the AM335x TRM Jun 15 19:31:13 DMA (Direct Memory Access) lets you directly access the system memory, even from code executing within a virtual memory space (like it is using GNU/Linux) Jun 15 19:34:35 needs 9250 in inv_mpu6050_hw hw_info Jun 15 19:35:19 yeah, seems to work fine with 6500 instead. The whoami register is checked, but a mismatch just generates a warning Jun 15 19:37:39 it applies the reg_set and config based on whoami Jun 15 19:38:00 9250 would need 6500 reg_set not 6050 Jun 15 19:38:17 right, 6500 is an option Jun 15 19:38:39 so like 9150 except for that Jun 15 19:39:03 i'll make a patch for that iio beagle branch Jun 15 19:39:41 this stuff should've really been ironed out before start date... Jun 15 19:39:55 this worked for me http://pastebin.com/v5hXPrwi Jun 15 19:40:42 though.. it may not work right without the interrupt... Jun 15 19:42:14 i2c doesn't need it Jun 15 19:42:45 the driver might (though it wasn't actually using it when I tried, so I guess maybe not) Jun 15 20:30:16 alexhiam, I am a bit confused again. In the AM335 TRM, pg 206 lists the Global Memory map of PRU-ICSS,This is what I have to follow? Jun 15 20:30:31 There is no offset? Jun 15 20:31:27 chanakya_vc: which version of the TRM? chapter 2 has the A8's memory map Jun 15 20:31:44 http://www.ti.com/lit/ug/spruh73m/spruh73m.pdf Jun 15 20:31:47 alexhiam, ^^ Jun 15 20:32:33 lol, they put the pru stuff back in it... Jun 15 20:32:45 that was a rev or 2 ago Jun 15 20:33:15 l just has a tiny intro Jun 15 20:33:36 chanakya_vc: how are you trying to use DMA? Jun 15 20:34:01 chanakya_vc: page 184 - the PRU_ICSS is at 0x4a300000 Jun 15 20:34:36 Abhishek_, I want to let the ARM access the shared Ram between the PRU's (12 kb one) Jun 15 20:35:30 ioremap? Jun 15 20:36:11 So alexhiam ,it gives a start address and an end address,how do I figure out the way to get to the specific RAM? Jun 15 20:37:33 I'd think dma would be better if there might be big chunks of data Jun 15 20:37:38 Abhishek_, I don't have much exp with ioremap,but I believe it essentially allows you to allocate a block of memory from a start address right? Jun 15 20:38:06 With ioremap you can get a pointer to the PRU memories Jun 15 20:38:55 Okay. Abhishek_ Jun 15 20:39:02 But there is a "proper way" to do it using the device tree i.e. the PRU start addresses and ram addresses are given in the device tree Jun 15 20:39:18 What do you think alexhiam ^^? Jun 15 20:39:26 Abhishek_: the trm doesn't seem to give much info... is it really just the whole pru memory map starting at 0x4a300000? Jun 15 20:39:33 yeah Jun 15 20:39:40 ioremap would probably be easier.. Jun 15 20:39:55 There's a "global" memory map and a "local memory map" (seen only the PRUs) Jun 15 20:40:04 in the PRU section\ Jun 15 20:40:08 But even for ioremap I need to know the start and the end address Jun 15 20:40:11 Yes Abhishek_ Jun 15 20:40:34 cool, so chanakya_vc, 0x4a300000 is your offset Jun 15 20:40:43 chanakya_vc: how does the current device tree for the PRUs look like Jun 15 20:40:53 then the global memory map stating there from the A8's perspective Jun 15 20:41:19 Abhishek_: very minimal... Jun 15 20:41:24 Okay alexhiam So 0x43a300000 0x000 1000 will be my shared RAM? Jun 15 20:41:28 can't even give a firmware name now Jun 15 20:41:41 chanakya_vc: yup Jun 15 20:42:22 Okay alexhiam So should I go with IOremap? Jun 15 20:42:26 chanakya_vc: more like 0x4a300000 + 0x00010000 Jun 15 20:42:38 Okay Abhishek_ Jun 15 20:42:44 yes, the + is important ;) Jun 15 20:42:59 chanakya_vc: the addressing will be the same either way Jun 15 20:43:01 That's why it is the offset :P Jun 15 20:43:38 Abhishek_, alexhiam http://www.makelinux.net/ldd3/chp-9-sect-4 Jun 15 20:44:45 I would imagine that the pru driver has access to the PRU memory map already Jun 15 20:44:53 This seems to be easier. Jun 15 20:44:53 as it starts/stops the PRUs Jun 15 20:45:48 Abhishek_: good point. The new kernel-space APIs are not really documented though, afaik Jun 15 20:46:56 https://github.com/beagleboard/linux/blob/4.4/drivers/remoteproc/pruss.c#L832 Jun 15 20:49:37 https://github.com/beagleboard/linux/blob/4.4/arch/arm/boot/dts/am33xx.dtsi#L946 Jun 15 20:49:49 See the memory regions in the dts? Jun 15 20:51:14 0x4a310000 0x3000 Jun 15 20:51:20 shared ram^^? Jun 15 20:51:27 https://github.com/beagleboard/linux/blob/4.4/drivers/remoteproc/pruss.c#L786 Jun 15 20:51:29 yep Jun 15 20:52:59 So I can access the shared ram by this only right?I don't get the concept of the offset earlier then?Both the addresses point to the same location? Jun 15 20:53:14 Abhishek_,alexhiam^^ Jun 15 20:53:37 Basically get a pointer to the pruss strucure Jun 15 20:53:53 So remoteproc does have direct access... Jun 15 20:54:04 It's supposed to :) Jun 15 20:55:14 Yes. But I guess it would be best to avoid Remoteproc right alexhiam ?As it is I am going with RPMsg with a heavy heart :P Jun 15 20:55:59 remoteproc is how you're loading the firmware Jun 15 20:56:08 Yes Jun 15 20:56:11 I know thta Jun 15 20:56:51 But if I am going to be using custom defined buffers Jun 15 20:56:54 alexhiam, ^^ Jun 15 20:56:55 remoteproc -> loads the firmware and boots the PRU Jun 15 20:57:01