**** BEGIN LOGGING AT Tue Jun 14 02:59:59 2016 Jun 14 04:05:26 okay, if i stay away from i2cdetect the bmp085 and mpu6050 python tests work more than once... Jun 14 04:06:17 mpu one uses smbus lib interface and the bmp one uses adafruit/bbio Jun 14 04:07:00 https://github.com/VCTLabs/py-sensor-test/tree/master/python <= change bus to 2 Jun 14 04:09:55 ah Jun 14 04:13:32 not sure the static values for the 6050 are exactly correct for 9250 but it returns "reasonable" values Jun 14 04:22:48 good for a quick and dirty test Jun 14 07:33:57 alexhiam - shout when you are about if you want to look at why that 9250 ain't streaming... More than possible my hackery on the drivers borked something. Jun 14 07:35:18 Also, good to get some testing feedback back to Leonard (might poke him into doing the final version of those ahead of other stuff ;) Jun 14 12:45:54 Abhishek_: there ? Jun 14 15:27:42 hi amragaey Jun 14 15:46:46 kiran4399: how goes it? Jun 14 15:54:15 Abhishek_: ? Jun 14 15:59:03 alexhiam: good. Jun 14 15:59:17 alexhiam: did all the things you asked me to.. Jun 14 15:59:32 alexhiam: and as told to you.. led and buttons apis are done.. Jun 14 15:59:36 travis ci are setup.. Jun 14 15:59:39 *is Jun 14 15:59:57 alexhiam: applied the patch for mpu9250 in 4.4 kernel. Jun 14 16:01:36 kiran4399: awesome. I guess the next step should probably be to get the travis build passing, which probably means leaving out the pru stuff for now (we're not using prussdrv, so no point in getting it setup in travis) Jun 14 16:02:51 alexhiam: done!! Jun 14 16:03:22 kiran4399: which? Jun 14 16:03:26 I'm looking at this: https://travis-ci.org/kiran4399/bb_blue_api#L418 Jun 14 16:05:23 alexhiam: ok.. removed it. Jun 14 16:07:22 kiran4399: k. then I guess the next step is implementing the imu and pressure sensor APIs, then we can jump into the PRU stuff Jun 14 16:08:04 kiran4399: it would also be nice to break out the different sections of the API into separate files Jun 14 16:08:31 alexhiam: you mean even in the main api file? Jun 14 16:09:04 yeah, like have separate files for the imu, motor, gpio, etc. Jun 14 16:09:30 not essential, but would make it a lot cleaner looking, and a bit nicer to test and debug Jun 14 16:09:49 hi jkridner Jun 14 16:10:01 jkridner, do you use firefox ? Jun 14 16:13:35 * alexhiam goes afk Jun 14 16:14:54 alexhiam: what I thought was like it would be advantageous for the user if you put everything in one file becuase he has to just use 1 header file.. Jun 14 16:19:20 alexhiam missed his chance last year to get mpu9250 module with i2c interface... Jun 14 16:19:54 not sure that's in scope for anemometer Jun 14 16:23:57 amragaey: no, I use Chrome. Jun 14 16:27:12 Need boy, beagle on a balloon for really inaccurate anemometer calibration :) Jun 14 16:27:40 Nerdboy, hate autocorrect on phone Jun 14 16:37:53 hey bradfa!There? Jun 14 16:38:37 hi chanakya_vc Jun 14 16:39:37 bradfa, Read your mail. I am really sorry for the binaries bit.It was pointed out to me earlier Jun 14 16:39:45 chanakya_vc: it's ok Jun 14 16:39:59 chanakya_vc: I sent you a pull request Jun 14 16:40:18 chanakya_vc: I dislike having a dependency on the ti linux sdk, it's a pain in the butt to deal with Jun 14 16:40:19 I have put the file in .gitignore .So It will never happen again in the future Jun 14 16:40:40 chanakya_vc: since all your generated files now go in the gen/ directory, just put the gen/ directory in the gitignore Jun 14 16:41:23 Yes I did that. Jun 14 16:41:58 ok Jun 14 16:42:22 I did not about the compatibility of BSD 3 with gplv2. Jun 14 16:43:04 chanakya_vc: see: https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses and https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean Jun 14 16:43:55 chanakya_vc: "Modified BSD License" is what gnu.org calls the 3 clause BSD license that is on the headers from TI Jun 14 16:47:32 Okay bradfa Got it. Jun 14 16:50:14 In the makefile you have not given any path to LIBS?.Also when you say ./include/ this implies it will search in the current folder? Jun 14 16:50:21 bradfa, ^^ Jun 14 16:50:41 Also were you able to compile and test my code? Jun 14 16:50:42 chanakya_vc: correct, you were not linking against any libs Jun 14 16:50:53 chanakya_vc: I have compiled, but haven't been able to run it yet Jun 14 16:50:59 job keeps getting in the way of gsoc... Jun 14 16:51:10 np bradfa Jun 14 16:51:14 chanakya_vc: I trust the logic analyzer plogs you and alexhiam have taken Jun 14 16:51:37 alexhiam: thanks for your help! :) Jun 14 16:51:52 I did ask alexhiam to evaluate my code again?Did you get a chance? Jun 14 16:52:02 For case 3? Jun 14 16:52:42 bradfa, Did you get a chance to go through my latest mail? Jun 14 16:52:58 About 12 shared RAM? Jun 14 16:53:00 chanakya_vc: not the latest one but all those before it Jun 14 16:53:18 chanakya_vc: can you make a proposal about how to have the shared ram? Jun 14 16:53:32 chanakya_vc: also, be sure to send status report today (if you haven't yet) Jun 14 16:53:48 Okay bradfa,yes I have written about it in the mail Jun 14 16:54:06 chanakya_vc: ok, I'll read it today, have to get a few things done first sorry :( Jun 14 16:54:19 If you think it is okay,I will go ahead and code it before tomorrow's meeting Jun 14 16:54:26 bradfa, ^^ Jun 14 16:54:40 chanakya_vc: yes, please do Jun 14 16:55:05 I am confident of starting with the driver by thursday bradfa Jun 14 16:55:41 morning Jun 14 16:56:06 Hopefully by next week Friday we will be actually able to send data from userland and see it on a logic analyzer Jun 14 16:56:19 chanakya_vc: I believe even the libs you were going to use for rpmsg in the pru are BSD-3 licensed, so you can copy those into your repo, too Jun 14 16:56:22 bradfa, ^^ Jun 14 16:56:30 chanakya_vc: sounds good :) Jun 14 16:57:01 i might not go for RPMsg bradfa ^^ Jun 14 16:57:03 Custom buffers Jun 14 16:57:20 In the shared RAM Jun 14 16:57:24 Or addresses Jun 14 16:58:43 If you are busy today bradfa I could possibly code through the night and maybe you could check out my repo tomorrow? Jun 14 16:59:51 chanakya_vc: don't completely discount rpmsg, you will still likely need a way to send messages back and forth unrelated to the data for MISO/MOSI Jun 14 17:00:17 such as the clock frequency and CPOL/CPHA and interrupt back to the ARM Jun 14 17:04:00 ZeekHuge: what's up? Jun 14 17:05:37 Hi Abhishek_ ! did you see those pics ? Jun 14 17:06:54 http://postimg.org/image/6eysheu9j/ Jun 14 17:07:02 http://postimg.org/image/lhb0s3et3/ Jun 14 17:07:05 Abhishek_: ^^ Jun 14 17:07:36 What's 1 vertical division? Jun 14 17:08:26 Is 2.48V between the two markers? Jun 14 17:09:46 Abhishek_: yes. between those two lines . Acc to alexhiam thats not the correct reading and the probes are causing that decrease. Jun 14 17:10:20 unfortunately thats what i have got. Jun 14 17:12:20 Abhishek_: ? Jun 14 17:14:42 Abhishek_: you still there ? Jun 14 17:15:14 .... Jun 14 17:22:23 alexhiam: modprobe: FATAL: Module pru_rproc not found.?? Jun 14 17:22:29 I got this error message.. Jun 14 17:26:14 kiran4399: weird... how did you build the kernel? Jun 14 17:27:23 Kiran4399 check you have pru_rproc.ko under /lib/modules/4.4whatever where last bit matches what is uname -a gives you. Jun 14 17:27:47 Chances are you have a subtle mismatch such as a plus symbol... Jun 14 17:28:47 If so modules or kernel probably not correctly installed... Jun 14 17:29:23 Happens all the time when you modify a version tagged kernel... Jun 14 17:29:41 If config is set to do it... Jun 14 17:32:21 bradfa, Sorry network issues here. Jun 14 17:32:47 bradfa, Maybe you are right.I could use the mix of both RPMsg and shared mem Jun 14 17:33:01 chanakya_vc: something to consider Jun 14 17:33:43 bradfa, Okay let me research on this a bit and get back to you with a solid plan Jun 14 17:35:11 Data could be written to the shared mem to reduce latency but parameters could certainly come via RPMsg Jun 14 17:35:31 chanakya_vc: did you see the latest caps I pus in an issue on your repo? Jun 14 17:36:09 bradfa, The only problem is that I am not too sure about how master driver will talk to RPMsg core. Jun 14 17:36:47 chanakya_vc: there's some docs on that somewhere Jun 14 17:36:47 alexhiam, I haven't. I will. Jun 14 17:41:00 Actually alexhiam I would removing the part rpmsg_pru which writes to this char dev file /dev/rpmsg_pruN Jun 14 17:41:13 http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg Jun 14 17:41:16 bradfa, ^^ Jun 14 17:41:36 * chanakya_vc goes to have dinner. Will be back in 10-15 mins Jun 14 17:42:19 chanakya_vc: yes, just like that Jun 14 17:42:21 chanakya_vc: https://www.kernel.org/doc/Documentation/rpmsg.txt Jun 14 17:56:54 alexhiam, bradfa I could write the driver like the example they have given... Jun 14 17:58:12 Seems to be easy.Instead of dumping the message to console,I could write it to file right? Jun 14 17:58:21 For say spidev to read? Jun 14 18:02:08 chanakya_vc: what do you mean? Jun 14 18:02:36 chanakya_vc: to start, yes, you could do that, but eventually you'll want to expose the interface within the kernel as a normal SPI master does Jun 14 18:04:21 ah, I see Jun 14 18:07:05 alexhiam, bradfa This has not been clear to me since the proposal time. spidev is userland driver..so it writes to a character dev file? Jun 14 18:08:13 Then the SPI Core calls on the protocol driver to read from such a file and transmit via the master right? Jun 14 18:09:31 When you say bradfa expose an interface inside the kernel,what do you exactly mean by that? Jun 14 18:13:59 chanakya_vc: make your PRU-SPI master look just like McSPI does to protocol drivers Jun 14 18:14:31 chanakya_vc: spidev is basically just a userland protocol driver Jun 14 18:15:08 chanakya_vc: spidev is like libusb, you can write your "driver" in userspace code rather than in the kernel itself, which adds flexibility but brings with it other things which may be less desireable Jun 14 18:18:04 don't forget your weekly reports! the time to post them is now Jun 14 18:28:56 just got a box full of stuff from TI Jun 14 18:29:19 hmm... my mpu9250 isn't responding anymore :/ Jun 14 18:29:33 what did you do!? Jun 14 18:30:15 i didn't do nothing, I swear! Jun 14 18:30:32 maybe my cat lay on it and fried it Jun 14 18:30:38 cats are good for esd testing Jun 14 18:30:57 that is odd Jun 14 18:31:22 probably a dumb user error... Jun 14 18:31:42 jiggle the cable Jun 14 18:31:54 turn it off and then back on again Jun 14 18:32:00 everything is connected, using the same overlay and module that worked fine last night, have powered down completely twice Jun 14 18:32:32 the module gets probed and I see a write request to the right address with no ACK Jun 14 18:34:03 its dead Jim Jun 14 18:34:15 ¯\_(ツ)_/¯ Jun 14 18:35:06 where did you get the 9250 module? Jun 14 18:35:33 ebay Jun 14 18:36:19 link? Jun 14 18:36:48 http://www.ebay.com/itm/272210139103?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT Jun 14 18:37:09 it's got an american flag, so you know it must be a good one Jun 14 18:38:20 is there a schematic? Jun 14 18:38:47 none that I can find Jun 14 18:39:36 awesome Jun 14 18:39:53 looks like a tiny regualator up top Jun 14 18:40:13 yeah.. though no level shifting on the pins Jun 14 18:41:16 the voltage ranges are confusing Jun 14 18:42:10 can you measure the voltage on the big yellow capacitor real quick? Jun 14 18:42:11 oh interesting, hadn't actually looked at that electrical char Jun 14 18:42:37 m_w, Did you too get stuff from Cathy wicks? Jun 14 18:42:48 3.3V, which is what I'm giving it from the bone Jun 14 18:42:51 that must be VDD Jun 14 18:43:21 chanakya_vc: it just showed up from Harte-Hanks Inc Jun 14 18:44:36 alexhiam: is the VCC pin slightly higher voltage? Jun 14 18:44:37 ah ok, the regulator looks like a 3.3V LDO - I'm actually getting 3.4 from the bone and 3.3V on the output Jun 14 18:44:46 okay Jun 14 18:45:09 pointless to have without level shifting... Jun 14 18:45:18 bradfa, Okay. So spidev is something you can just write in the terminal and it will open an interface for you to transmit via SPI. In my case,the master driver will be accessed by userland drivers like spidev right? Jun 14 18:45:55 bradfa, alexhiam And would you classify spidev as a protocol driver? Jun 14 18:46:26 chanakya_vc: spidev is not accessible directly from the prompt Jun 14 18:47:25 you need a C program or similar Jun 14 18:47:49 m_w, Ohkay. So its just written in userspace code.That's the only special thing about it? Jun 14 18:48:00 not really Jun 14 18:48:06 just a few ioctls Jun 14 18:48:08 https://github.com/mwelling/spi-test Jun 14 18:48:26 this is a little cmd line utility that I wrote Jun 14 18:48:47 there are python libs and other examples out on the net Jun 14 18:49:06 mine is the best ;) Jun 14 18:49:13 because I wrote it Jun 14 18:49:25 I'm a fan of my own ;) https://graycat.io/docs/serbus/ Jun 14 18:49:49 Haha alexhiam m_w Jun 14 18:50:28 One day I also hope to write stuff like this :P Jun 14 18:50:32 well well well looks to be a library Jun 14 18:51:15 * alexhiam can't help writing libraries Jun 14 18:51:16 you should add my spi program to your examples :) Jun 14 18:51:51 m_w: you just have to convert it to using serbus first :P Jun 14 18:52:36 So alexhiam You have basically written a C API that would let people access drivers like spidev? Jun 14 18:52:46 I already converted it from another SPI kernel API that predates spidev Jun 14 18:52:59 lol Jun 14 18:53:16 chanakya_vc: yeah, as a roundabout way to write a python library to do that... Jun 14 18:53:28 * chanakya_vc is amazed by alexhiam and m_w work.I wish I could write stuff like this Jun 14 18:53:38 the "standard" spi and i2c python libraries really suck Jun 14 18:54:11 you certainly can and will Jun 14 18:54:20 mine was 30 minutes and a cup of coffees worth of code Jun 14 18:54:44 spidev stuff is just reading and writing files Jun 14 18:55:17 Okay. Got it. when you say standard libraries,wouldn't they depend upon the underlying driver they are trying to access? I Jun 14 18:55:24 alexhiam, m_w ^^ Jun 14 18:55:36 alexhiam, Thanks. I do hope so : ) Jun 14 18:55:59 yeah Jun 14 18:56:02 chanakya_vc: the spidev interface is generic - it works with all spi drivers Jun 14 18:56:52 https://www.kernel.org/doc/Documentation/spi/spidev Jun 14 19:02:39 So m_w spidev is just a way of writing a protocol driver in userspace? Jun 14 19:02:42 alexhiam, ^^ Jun 14 19:03:30 it's a way to directly cofigure, tx and rx from userspace Jun 14 19:03:46 it can be used to make userspace device drivers, or just for testing Jun 14 19:04:01 Okay so concept of protocol driver or master in this case? Jun 14 19:04:19 alexhiam, ^^ Jun 14 19:04:47 neither.. it's just another component of the Linux SPI driver framework Jun 14 19:06:08 But alexhiam It must go through the kernel to configure tx and rx.Like if you need send messages to a slave you do need a prtocol driver right? Jun 14 19:08:31 * chanakya_vc cannot fathom a way to communicate to the slave without protocol and Master driver Jun 14 19:09:26 right, yeah, each /dev/spidevX.Y file interfaces with a specific bus through its protocol driver Jun 14 19:17:29 Hmmn,so the userspace driver is just a means to let the users(via API's ) access the underlying protocol+master? Jun 14 19:17:33 alexhiam, ^^ Jun 14 19:18:40 yeah. For each spi protocol driver there's an interface to it provided in kernel space (to use for device drivers) and one in userspace (that's spidev) Jun 14 19:32:31 what is this driver trying to do ? Jun 14 19:33:40 is it really like calling a function that is inside PRU from kernel space https://github.com/RobertCNelson/linux-stable-rcn-ee/commit/71711c3509d8a6d76609444624e7906caa4da6fb ? Jun 14 19:33:57 Wormo: alexhiam ^ Jun 14 19:34:18 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.11-ti-r29/drivers/rpmsg/rpmsg_rpc.c Jun 14 19:34:38 coool Jun 14 19:34:49 rpc = remote procedure call Jun 14 19:34:59 woh ! its so cool ! Jun 14 19:35:01 really ! Jun 14 19:35:28 oh, that's pretty old though Jun 14 19:37:16 yeah but why no one is using it ? Jun 14 19:37:40 does it work with the new rproc framework? Jun 14 19:37:42 though i see this ;) https://gist.github.com/alexanderhiam/e9237b835feae932d973 Jun 14 19:38:37 lol, oh yeah. we were talking about doing something like that last gsoc I think Jun 14 19:40:47 * alexhiam goes afk Jun 14 19:44:19 its getting probed successfully http://paste.debian.net/739247/ Jun 14 20:29:52 Hi ZeekHuge Jun 14 20:30:11 Hi Wormo :) how are you ? Jun 14 20:30:55 did you see the example ? https://github.com/ZeekHuge/BeagleScope/tree/master/examples/kernel_examples/n-blinky Jun 14 20:31:03 a bit boggled with work atm, but happy to see you're making progress Jun 14 20:31:56 :) thanks Jun 14 20:32:44 also apart that i found a remote procedure call driver too https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.11-ti-r29/drivers/rpmsg/rpmsg_rpc.c Jun 14 20:33:19 And i think we can us the 2 approaches to make it more efficient Jun 14 20:37:19 driver was written by Suman Anna who works for TI on omap Jun 14 20:37:26 https://patches.linaro.org/project/linux-omap/list/?submitter=1831 Jun 14 20:42:06 He's still working on remoteproc, just not pulled into RCN yet: http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=summary Jun 14 20:42:59 the RCN version is from 2014, latest commits to rpmsg repo are within a few days Jun 14 20:51:49 yeah, but I dont think we can do anything with that. We were instructed to use kernel at http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_iot Jun 14 20:52:05 and we already have the latest. Jun 14 20:52:41 yes but it's good to know still being worked on, and can probably backport stuff if you run into problems Jun 14 20:53:50 also we might look for a TI mailing list with discussions on the driver Jun 14 20:54:53 yep okay. Jun 14 21:00:18 and is probably where we need to mail to subscribe to the mailing list c6swlib_dev@list.ti.com Jun 14 21:14:38 RPC on PRUs sounds interesting Jun 14 21:15:29 Wormo, just caught up with logs. RCN tree further forward than you would think. He is pulling the ti 4.4 tree. For rpmsg and rproc they are pretty close to current. Jun 14 21:16:04 Mind you RCN seems fond of direct bulk back ports! Jun 14 21:17:01 Abhishek_: yeah ! We can use it ! Jun 14 21:17:40 looks like a sophisticated version of downcall concept Jun 14 21:18:02 Abhishek_: I was going through the fw code to make so as to be able to make it compatible with rpmsg framework Jun 14 21:18:28 Isn't it using rpmsg already? Jun 14 21:18:47 fw code = beaglelogic's fw Jun 14 21:19:29 jic23: the rpmsg_rpc.c file in particular looks much fresher in the rpmsg tree, mentions fixing potential memory leaks... Jun 14 21:19:36 https://github.com/RobertCNelson/linux-stable-rcn-ee/commits/4.4.11-ti-r29/drivers/rpmsg/rpmsg_rpc.c Jun 14 21:19:38 Wormo. RCN tree looks to be 8 patches behind current ti tree. Jun 14 21:19:55 and rpc is very sophisticated . It first queries the number of functions to declare and then queries each function ! all using a format of rpmsg messages Jun 14 21:20:00 Abhishek_: ^ Jun 14 21:20:29 Just pull them and add as decencies of any new stuff being sent to rcn Jun 14 21:20:36 yeah, it's not as lightweight. Jun 14 21:21:08 Ah RPC is mainlined perhaps? Jun 14 21:21:21 jic23: the 'pull them' part makes sense, not following what else you said... Jun 14 21:22:07 Abhishek_: okay so about the beaglelogic fw. i think the pru0 code will have to be rewritten completely managing the two interrupts, one from MBX other from PRU1 Jun 14 21:22:11 Nope, not mainlined... Jun 14 21:22:34 http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=history;f=drivers/remoteproc;h=549605689e562abfdb8624abb1d0c1934ecf73b4;hb=HEAD Jun 14 21:22:45 yup, I'll have to do an "impact assessment" Jun 14 21:22:47 Recent rproc history from ti Jun 14 21:22:58 jic23: decencies? Jun 14 21:23:02 Abhishek_: and what is that fw_magic bit there in the code ? Jun 14 21:23:20 Equiv from RCN https://github.com/RobertCNelson/linux-stable-rcn-ee/commits/4.4.11-ti-r29/drivers/remoteproc Jun 14 21:23:21 jic23: also, what mailing lists would you recommend subscribing to Jun 14 21:23:37 Dependencies. Can't type! Jun 14 21:23:46 it's a known value loaded at a known location into the PRU firmware to verify that it's indeed beaglelogic firmware that's been loaded. Jun 14 21:24:08 For rproc? No idea all ti internal, more or less Jun 14 21:24:27 too bad Jun 14 21:24:39 ZeekHuge: So essentially a very basic "integrity check" that the firmware is compatible with the kernel driver Jun 14 21:24:49 Abhishek_: okay. Jun 14 21:24:53 Otherwise the kernel driver will not load Jun 14 21:25:13 Abhishek_: yeah okay so its like a key to probe the driver Jun 14 21:25:52 it's more like a key to "stop probing the driver" if the firmware does not have those magic bits Jun 14 21:26:09 Abhishek_: got it. Jun 14 21:27:40 Abhishek_: So anyway since we are going to use RPmsg, that would be done by "channel name" in the firmware code. Do you think there will be significant changes in pru1 code ? Jun 14 21:28:48 Abhishek_: apart from making it sample parallel data ? Jun 14 21:28:56 The PRU1 signals to PRU0 that a buffer is available through an interrupt Jun 14 21:29:07 that interrupt needs to be intact\ Jun 14 21:29:34 Wormo, in theory there is linux-remoteproc@vger.kernel.org no idea how busy it is though! Jun 14 21:30:49 no archives of linux-remoteproc@vger.kernel.org no idea how busy it is though! Jun 14 21:30:59 oops mispaste Jun 14 21:31:02 Has 10 subscribers :) Jun 14 21:31:20 no archives of linux-remoteproc@vger.kernel.org so I'm guessing not much happened there Jun 14 21:32:33 they got cc on this message https://lwn.net/Articles/688621/ Jun 14 21:32:51 Indeed. Hmm didn't know you could find out subscriber numbers 171 for IIO :) Jun 14 21:33:13 Lots of lurkers I guess Jun 14 21:35:38 well maybe linux-remoteproc@ would be a good place for GSoC questions, not so high activity that it would get lost... Jun 14 21:36:06 Yup :) Jun 14 21:36:12 no archive, can't complain about asking FAQs ;) Jun 14 21:37:54 Anyhow bye for now. Jun 14 21:37:59 thx, later Jun 14 21:51:24 Abhishek_: you did you map the channels ? i am unable to see the use of HMRm register ? Jun 14 21:51:42 I can see that PRU1 is generating interrupt number 17 Jun 14 21:52:03 but then what channel is it mapped to > Jun 14 21:52:04 ? Jun 14 21:52:19 *how did you Jun 14 21:55:33 oh its probably the CMRm register. back to the code Jun 14 21:56:47 it is complex...there are 2 interrupt controller/routers in play Jun 14 22:01:06 ds2: Hi ! 2 INTC ? Jun 14 22:01:39 the other from the ARM ? Jun 14 22:01:54 yeah.. the one for the A8 and one on the PRUSS end Jun 14 22:02:17 so the A8 INTC is to be seen by the driver right ? Jun 14 22:02:21 messing with the one on the A8 end can get uncomfortable quick. mistakes there can take down the system, including the serial console Jun 14 22:02:29 yes Jun 14 22:03:28 okay so you are saying about the upcalls ? the way PRU signals ie interrupts the A8 ? Jun 14 22:03:53 ??? do not understand what you are asking Jun 14 22:04:10 upcalls/downcalls is an creation of software Jun 14 22:04:37 events/irqs are created by writing to one of the r3x registers either r31 or r30 Jun 14 22:04:50 events are received by polling the register Jun 14 22:04:55 the INTC of the A8 will come into play only when a PRU generates an interrupt for the A8 right ? Jun 14 22:05:01 what you decide to do or not do with them is entirely up to you Jun 14 22:05:30 ZeekHuge: yes. or more accurately, the INTC of the A8 will come into playonly when the PRU generates an irq AND the A8 needs to receive it Jun 14 22:07:30 yes So to get beaglelogic code working for us and going along the RPmsg what we just need to remove all the code on PRU0 (the one that generates INTR for ARM ) . And then we just leave the INTR from PRU1 to PRU0 intact. right ? Jun 14 22:08:20 I guess that is one way of saying it Jun 14 22:09:04 the code should largely be writes and reads to the r3x register Jun 14 22:12:29 yeah but RPmsg on PRU just have one single function rpmsg_send() to send the data in the buffer given as an argument. And if we are going to use RPMsg and with the 2 PRUs , I was thinking to do as beaglelogic did it. Use the PRU1 for sampling and PRU0 for communication. Jun 14 22:13:21 and using rpmsg for communication would only require caring about the interrupt from PRU1 about the data buffers getting full . Jun 14 22:13:43 Please correct me if I am getting all this wrong. Jun 14 22:13:53 ds2: ^ Jun 14 22:14:11 hmmmmm rpmsg BETWEEN the PRUs? Jun 14 22:14:22 who's idea was it to do that? Jun 14 22:14:24 no no ! Jun 14 22:15:16 interrupt between the PRUs to indicate buffer getting full. Jun 14 22:15:34 and RPMsg on PRU0 to communicate to the A8 Jun 14 22:15:43 unless they really changed the rpmsg code; you should be able to largely ignore the interrupt details Jun 14 22:16:15 Okay - keep in mind there is no such thing as an interrupt between the PRU in the traditional sense Jun 14 22:16:57 PRUn can signal PRU(n+1)%2 but PRU(n+1)%2 needs to be polling for the event Jun 14 22:19:07 yea and its the 30 and 31st bit in R31 they need to be polling to for interrupts from host 0 and host 1 respectively Jun 14 22:20:41 so iirc, mailbox interrupts are routed to host 0 and as i can see in beaglelogic , the interrupt generated by pru1 is also routed to host 0. We need to worry about that i think ? Jun 14 22:20:44 ds2: ^ Jun 14 22:21:24 *mailbox interrupts in RPMSG Jun 14 22:25:32 I haven't looked at beaglelogic specifically... I have only looked at the old rpmsg stuff Jun 14 22:25:57 going by memory - I think the rpmsg drivers should take care of that Jun 14 22:26:13 it (at least the old version)uses a silly name service Jun 14 22:33:29 http://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/examples/am335x/PRU_RPMsg_Echo_Interrupt0/main.c#line99 Jun 14 22:33:35 https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-firmware/beaglelogic-pru0-core.asm#L32 Jun 14 22:34:01 and bit 30 in R31 is connected to the same host 0. Jun 14 22:34:05 ds2: ^ Jun 14 22:35:49 * nerdboy still documenting "platform" stuff Jun 14 22:40:21 ds2: do you think we will have to change the mapping of either of the two interrupts ? Jun 14 22:42:27 ds2: and i found this remote procedure call driver too :D ! https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.11-ti-r29/drivers/rpmsg/rpmsg_rpc.c Jun 14 22:43:14 ZeekHuge: I don't we have to touch the mapping. never had to for anything I did so far (both w/UIO and rproc/rpmsg) Jun 14 22:43:35 s/I don't/I don't think/ Jun 14 22:45:07 okay so after noticing an interrupt , we should check the status register to see what interrupt was actually there ? Jun 14 22:45:47 SRSR0 and SRSR1 registers. Jun 14 22:47:16 for rpmsg? Jun 14 22:47:29 IIRC - the library does that for you Jun 14 22:48:13 oh ! okay ! and then Jun 14 22:48:32 again, basing it on the old version of rpmsg Jun 14 22:48:38 but beaglelogic does not. Jun 14 22:48:46 https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-firmware/beaglelogic-pru0-core.asm#L32 Jun 14 22:49:00 its just checking the 30th bit Jun 14 23:06:36 They did this 25 days ago ! I was having an older package :( Jun 14 23:06:54 http://git.ti.com/pru-software-support-package/pru-software-support-package/commit/69805828df0f262fb60363c2db189d1b8d0b693c Jun 14 23:09:07 and that means the rpmsg kernel driver also has changed, but its not pulled yet by rcn, 4.4.11-ti-r29 is the latest, and its working with the older examples that are using mailbox :( Jun 14 23:16:51 rpmsg has changed too now ! :( Jun 14 23:16:53 http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=a4c5877aeb147a2d8b6f392f1fd9dd712655a2bf Jun 14 23:17:04 ARM: dts: AM33xx: Replace mailboxes with PRU system events Jun 14 23:17:32 ahhh .. Jun 14 23:17:53 ds2: after all this ^ i really need your help here .. Jun 14 23:17:59 ZeekHuge: try 4.4.12-ti-r30 Jun 14 23:18:00 http://git.ti.com/pru-software-support-package/pru-software-support-package/commit/69805828df0f262fb60363c2db189d1b8d0b693c Jun 14 23:19:11 ds2: this commit says that it uses 16,17,18 and 19 sys events, none of these events can be generated by ARM as per the arm reference manual Jun 14 23:19:35 that one looks to be the latest ti/ti-rt tag Jun 14 23:19:44 just tagged a few days ago even Jun 14 23:20:13 just apt-get install it Jun 14 23:20:25 apt-get install linux-firmware-image-4.4.12-ti-r30 linux-headers-4.4.12-ti-r30 linux-image-4.4.12-ti-r30 Jun 14 23:21:05 yeah I noticed that too. It was one hour before the last meeting iirc. Jun 14 23:21:19 but then, its source is not there https://github.com/RobertCNelson/linux-stable-rcn-ee/releases?after=4.6.2-bone3 Jun 14 23:21:30 and I need source too to work along Jun 14 23:22:23 ds2: so what sys events are they talking about. Jun 14 23:22:24 source is all there Jun 14 23:22:46 rcn repo branch nnn plus linux-stable Jun 14 23:22:51 oops ! Jun 14 23:22:57 yeah ! Jun 14 23:22:59 sorry ! Jun 14 23:23:22 and there are no bone-X kernels with that driver afaik Jun 14 23:23:38 it's only in the linux-ti-dev stuff Jun 14 23:23:57 and 4.4.12-ti-r30 is the latest Jun 14 23:24:24 stop wasting time and use it Jun 14 23:24:37 yep ! Jun 14 23:25:08 it's either that or the virtio interface, take your pick Jun 14 23:26:41 for your homework, get into make menuconfig in that kernel ^^ and enable kernel sample code (under kernel hacking menu) Jun 14 23:27:20 do it now please... Jun 14 23:27:23 okay and what will it do ? Jun 14 23:27:30 try it and see Jun 14 23:27:43 ZeekHuge: events/interrupts are the same thing on the PRUSS Jun 14 23:28:16 if it is just a driver, it shouldn't be too hard to movebetween kernels Jun 14 23:29:08 ti-rfoo is actually what goes to ti-staging kernel upstream i think Jun 14 23:29:30 different set of patches than bone kernel Jun 14 23:31:15 ds2: page number 223 says int Number 16,17,18 and 19 can be generated only by pru0 or pru1 . : http://www.siue.edu/~gengel/bbbWebStuff/am335xPruReferenceGuide.pdf Jun 14 23:36:47 ZeekHuge: look at /samples/rpmsg/rpmsg_client_sample.c Jun 14 23:38:47 ZeekHuge: page 153 Jun 14 23:38:49 I was able to write a driver too https://github.com/ZeekHuge/BeagleScope/tree/master/examples/kernel_examples/n-blinky Jun 14 23:38:54 nerdboy: ^ Jun 14 23:39:11 that sample is deceptively useless, IMO Jun 14 23:39:20 the ones from the TI labs was more to the point Jun 14 23:40:11