**** BEGIN LOGGING AT Mon Jun 06 02:59:58 2016
Jun 06 07:36:08 <jic23> alexhiam, Kiran - just catching up with logs from weekend.  bmp280 driver does indeed support i2c - in fact the curious bit is that it doesn't support the spi interface on those parts despite being regmap based (which makes supporting different buses really easy).  Guess someone was thinking ahead, but never had a suitably wired board to check the spi side of things.
Jun 06 08:35:52 <kiran4399> alexhiam: ping :)
Jun 06 08:53:01 <jic23> kiran4399 - sorted your i2c bmp280 issue?#
Jun 06 08:55:50 <kiran4399> jic23: No not yet..
Jun 06 08:57:10 <kiran4399> jic23: did you sort out??
Jun 06 08:59:00 <jic23> it does support i2c - doesn't support spi.  All done through regmap so not that obvious if you aren't familiar with these drivers.
Jun 06 08:59:46 <jic23> I don't have one so can't test unfortunately but it's a reasonably heavily used driver.
Jun 06 08:59:54 <jic23> How is it failing?
Jun 06 09:03:21 <kiran4399> jic23: before that.. let me ask you one thing..
Jun 06 09:03:37 <kiran4399> jic23: yesterday I tested mpu 6050 with the driver..
Jun 06 09:03:53 <kiran4399> jic23: It appeared when I did i2cdetect -r X
Jun 06 09:04:10 <kiran4399> jic23: at 0x68
Jun 06 09:04:19 <kiran4399> jic23: am I doing something wrong?
Jun 06 09:04:28 <kiran4399> I did modprobe inv-mpu6050
Jun 06 09:04:37 <kiran4399> then modprobe inv-mpu6050-i2c
Jun 06 09:04:43 <kiran4399> then..
Jun 06 09:05:06 <jic23> It's got to be listed in the device tree bindings (or a board file) to tell it where to look.
Jun 06 09:05:34 <kiran4399> echo echo inv-mpu6050 0x68 > /sys/class/i2c-adapter/i2c-X/new_device
Jun 06 09:05:54 <kiran4399> jic23: but you can instantiate it right??
Jun 06 09:05:54 <jic23> Hmm. Might be enough - I usually just bodge the DT ;)
Jun 06 09:06:24 <jic23> have a funny feeling that part requires an irq to probe successfully - no way of providing one that way.
Jun 06 09:06:35 <jic23> did it give an error message?
Jun 06 09:06:58 <kiran4399> jic23: inititally when I do no error..
Jun 06 09:07:17 <kiran4399> but if I again do it: bash: echo: write error: Invalid argument
Jun 06 09:08:17 <jic23> you can't do it twice without removing the registration in between.
Jun 06 09:08:37 <jic23> Hmm. It's not terribly chatty on errors
Jun 06 09:09:35 <jic23> I think you'd just get a probe failure on this one.
Jun 06 09:09:58 <jic23> Had some patches the other day to make it operate without an irq but they were done in an odd way and presumably you do have the irq wired?
Jun 06 09:10:31 <kiran4399> http://pastebin.com/BEjAigAp
Jun 06 09:11:23 <kiran4399> jic23: I am using the strawson cape
Jun 06 09:12:01 <jic23> sure - guess that has it wired! Also, surely has a dt overlay?
Jun 06 09:13:52 <kiran4399> jic23: yeah.. it has a dt overlay.. but I did not load it.. because I thought instantiating was enough..
Jun 06 09:13:56 <jic23> using a fifo equipped chip without and interrupt line would be bonkers.
Jun 06 09:14:05 <jic23> see what else is in the overlay.
Jun 06 09:14:13 <kiran4399> jic23: https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/install_files/RoboticsCape-00A0.dts
Jun 06 09:14:14 <jic23> often need more than simply the address.
Jun 06 09:14:55 <jic23> well that isn't going to work for starters!
Jun 06 09:14:58 <jic23> time to write you own ;)
Jun 06 09:16:56 <kiran4399> jic23: but why is it not working? you can simply instantiate it right?? look at method 4..
Jun 06 09:16:58 <kiran4399> https://www.kernel.org/doc/Documentation/i2c/instantiating-devices
Jun 06 09:18:20 <jic23> https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt?h=testing
Jun 06 09:18:59 <jic23> driver cannot run without interrupt - there is work going on to get around the odd dumbass board that doesn't wire it, but it's not ready yet.
Jun 06 09:19:46 <kiran4399> jic23: so what do you suggest me to do?
Jun 06 09:20:03 <jic23> no way of providing interrupt like that.  The instantiate interface was designed for slow and dumb hardware monitoring on pc motherboards where the acpi listings frequently are wrong.
Jun 06 09:20:21 <jic23> Write a DT overlay that instantiates it properly - as per the doc above.
Jun 06 09:20:40 <kiran4399> k
Jun 06 09:21:13 <jic23> might need to go chasing wires as I haven't seen a strawson doc that says where the imu irq is wired too.
Jun 06 09:28:13 <kiran4399> jic23: did you go trough this?
Jun 06 09:28:14 <kiran4399> http://www.strawsondesign.com/#!manual-imu
Jun 06 09:36:39 <jic23> missed it ;)   P9_25
Jun 06 09:49:12 <kiran4399> jic23: do you know how to set this in the overlay for bb black?
Jun 06 09:49:14 <kiran4399> https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt?h=testing#n20
Jun 06 09:52:45 <jic23> should be very close to the example in that doc - dig around in the other overlays to find one with a gpio interrupt mapped to a driver.
Jun 06 10:36:29 <kiran4399> Does anybody know how to load a device tree overlay?
Jun 06 10:38:21 <kiran4399> in 4.4
Jun 06 10:38:22 <kiran4399> ?
Jun 06 12:29:56 <jic23> kiran4399 - sorry not me.
Jun 06 12:30:19 <jic23> I cynically just edit the main DT  :)
Jun 06 13:47:21 <alexhiam> kiran4399: it's basically the same as 3.8, it's just moved to '/sys/devices/platform/bone_capemgr/'
Jun 06 13:48:16 <alexhiam> or you can load them at boot in /boot/uEnv.txt
Jun 06 14:11:58 <alexhiam> jic23: thanks, didn't look too deep at that driver, I just assumed it would default to polling at some rate without an irg given
Jun 06 14:15:28 <alexhiam> irq*
Jun 06 15:37:51 <kiran4399> alexhiam: there?
Jun 06 15:39:57 <kiran4399> alexhiam: I try to import the Robotics overlay cape to slots..
Jun 06 15:40:08 <kiran4399> showing echo: write error: Invalid argument
Jun 06 15:41:16 <alexhiam> kiran4399: what's dmesg show?
Jun 06 15:41:47 <alexhiam> kiran4399: you will also have to disable universal-io first
Jun 06 15:43:41 <alexhiam> i.e. in /boot/uEnv.txt, change `cmdline=coherent_pool=1M quiet cape_universal=enable` to `cmdline=coherent_pool=1M quiet cape_universal=disable`
Jun 06 15:44:07 <kiran4399> alexhiam: http://pastebin.com/g98syYVd
Jun 06 15:44:09 <jic23> alexhiam - minor crisis at work today.  Will get back later, but in short that chip is complex to handle...
Jun 06 15:45:12 <alexhiam> kiran4399: have you made changes to the overlay? Otherwise it looks like it must not be compatible with the latest pru_rproc stuff
Jun 06 15:45:25 <alexhiam> jic23: no worries
Jun 06 15:46:12 <alexhiam> kiran4399: you can just remove the pruss fragment
Jun 06 15:46:31 <alexhiam> https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/install_files/RoboticsCape-00A0.dts#L390-L398
Jun 06 15:47:46 <kiran4399> https://github.com/kiran4399/bb_blue_api/blob/master/install_files/2016-05-01/RoboticsCape-00A0.dts
Jun 06 15:50:48 <alexhiam> kiran4399: are you working on the imu now?
Jun 06 15:52:09 <kiran4399> yeah.. imu and the bmp sensor from yesterday morning.. tough luck :-(
Jun 06 15:52:19 <kiran4399> alexhiam: ^^
Jun 06 15:52:43 <alexhiam> kiran4399: I'd recommend starting with a new overlay just for those
Jun 06 15:53:25 <alexhiam> less to go wrong that way
Jun 06 15:53:45 <kiran4399> alexhiam: But it is reallllllly wierd!!! Yesterday when I loaded mpu6050 and instantiated it... it displayed 68 on the 0x68 address..
Jun 06 15:53:57 <kiran4399> alexhiam: but today morning.. it did not!
Jun 06 15:54:12 <alexhiam> kiran4399: did it show a different address or just nothing?
Jun 06 15:54:15 <kiran4399> alexhiam: not sure why it is happening..
Jun 06 15:54:38 <kiran4399> alexhiam: it showed 68 at 0x68 address.
Jun 06 15:55:22 <alexhiam> but what was different this morning?
Jun 06 15:55:50 <kiran4399> Nothing!! That is the reason it is weird!!
Jun 06 15:56:05 <kiran4399> alexhiam: I thought something went wrong.. so I again flashed it..
Jun 06 15:56:15 <kiran4399> alexhiam: but even then nothing hapenned..
Jun 06 15:57:08 <alexhiam> kiran4399: I'd guess the imu has gotten into a weird state - try shutting down and pulling the power to force the imu to reboot to its default state
Jun 06 15:59:31 <kiran4399> alexhiam: btw.. the overlay I wrote is RoboticsCape-00A0.dts
Jun 06 15:59:35 <kiran4399> alexhiam: what should I echo to slots?
Jun 06 16:00:28 <alexhiam> kiran4399: you have to compile it and put it in /lib/firmware/ first, then 'echo RoboticsCape > slots'
Jun 06 16:01:11 <kiran4399> alexhiam: thats what I did..
Jun 06 16:01:31 <alexhiam> kiran4399: note that the robotics cape overlay won't help with the imu or pressure sensor
Jun 06 16:01:46 <alexhiam> it just enables the i2c bus, it doesn't load the drivers
Jun 06 16:02:12 <kiran4399> alexhiam: so should I load the drivers first and then load the dt overlay?
Jun 06 16:02:50 <alexhiam> kiran4399: the driver won't work without the interrupt, so you'll need an overlay with those properties in it
Jun 06 16:03:09 <alexhiam> The I2C1 overlay has an example in there of where you would configure a driver: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C1-00A0.dts
Jun 06 16:03:36 <alexhiam> that's where you would put this stuff: https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt?h=testing#n20
Jun 06 16:03:52 <alexhiam> I would recommend creating a new MPU6050 overlay
Jun 06 16:04:40 <alexhiam> oh, except you want I2C2: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-0A00.dts
Jun 06 16:05:06 <kiran4399> alexhiam: what is the difference between https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C1-00A0.dts#L63 line 63 and 64?
Jun 06 16:05:42 <alexhiam> described in https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt?h=testing#n8
Jun 06 16:06:27 <alexhiam> the first points to the gpio module, the second maps a pin in that module to an interrupt in the driver
Jun 06 16:06:41 <alexhiam> so in that example its pin 18 in the GPIO1 module mapped to interrupt 1
Jun 06 16:07:48 <alexhiam> P9_25 is GPIO3_21, so you'd want <&gpio3> and <21 1>
Jun 06 16:09:05 <alexhiam> and you'll need to add the pinmux for that pin as well
Jun 06 16:10:14 <chanakya_vc> hey bradfa ! Are you there?
Jun 06 16:10:24 <chanakya_vc> need some help with the makefile
Jun 06 16:11:02 <chanakya_vc> I think I have either not installed clpru package correctly or there is some problem with the makefile
Jun 06 16:11:22 <alexhiam> kiran4399: alternatively, you could leave universal-io loaded, which already enables and muxes I2C2, and mux the irq pin using config-pin
Jun 06 16:11:47 <alexhiam> then the overlay could leave out the pinctrl stuff and just add the imu
Jun 06 16:12:02 <kiran4399> alexhiam: where is the universal-io??
Jun 06 16:12:18 <alexhiam> kiran4399: it's an overlay compiled into the kernel
Jun 06 16:12:36 <alexhiam> and loaded by default on 4.x bb.org kernels
Jun 06 16:13:06 <kiran4399> alexhiam: so.. I need not add the pin mux in my overlay right??
Jun 06 16:14:06 <alexhiam> kiran4399: yeah, using config-pin first should do the trick for now I think. Eventually the boneblue dts will need to set all the pin muxing
Jun 06 16:20:56 <bradfa> chanakya_vc: there are likely problems with that makefile :)
Jun 06 16:21:02 <jic23> Alexhiam kiran4399 stuck waiting for late train so quick summary of why the inv imu driver currently insists(not very vocally) on an IRQ.
Jun 06 16:22:28 <jic23> Other than very slow polling the data flow is through a hardware Fifo into a software Fifo.
Jun 06 16:22:36 <chanakya_vc> bradfa, Eating my dinner.Be back in 20 minutes.Got to resolve this today.
Jun 06 16:22:43 <jic23> Then to userspace.
Jun 06 16:23:20 <bradfa> chanakya_vc: ok, when you have time, send me a link to your makefile
Jun 06 16:24:03 <chanakya_vc> bradfa, Sure bradfa . I have been tearing my hair out on that makefile :P
Jun 06 16:24:46 <bradfa> chanakya_vc: the ti tools install in a way that's very annoying to deal with
Jun 06 16:26:08 <chanakya_vc> Today We had a person from TI in my lab boasting about how easy it is to use TI ccs :P
Jun 06 16:26:13 <chanakya_vc> bradfa, ^^
Jun 06 16:26:38 <bradfa> chanakya_vc: TI likes to tell everyone how easy to use their softare is... they are all wrong :)
Jun 06 16:27:29 <jic23> Unfortunately iirc the hw Fifo interrupt is very simplistic.  Upshot is that when using it you get an interrupt every sample.
Jun 06 16:27:46 <chanakya_vc> bradfa,  I wish I could tell him the truth. But my prof wouldn't appreciate that I guess. TI funds our lab so :P
Jun 06 16:28:19 <jic23> Which means driver flushes whatever it can out every interrupt. Mostly one sample but sometimes more.
Jun 06 16:29:08 <jic23> Now proposal is usually to just use a high res timer to poll it.
Jun 06 16:29:55 <kiran4399> alexhiam: http://pastebin.com/qmkigrND
Jun 06 16:30:01 <kiran4399> alexhiam: still the same issue..
Jun 06 16:30:59 <jic23> Issue is that you get very little timing info. Without the hw Fifo (most chips) this is a total non starter. Even with you may get a different number of samples than you ask for.
Jun 06 16:32:03 <alexhiam> jic23: makes sense. Especially if you're running at full speed with the accel at 4kHz and the gyro at 8kHz
Jun 06 16:32:33 <jic23> So custom solution needed. Boils down to using polling of the interrupt register.
Jun 06 16:32:52 <kiran4399> alexhiam: btw.. I forgot to tell you.. I changed the frequency of am335x-boneblack.dts to 400Hz
Jun 06 16:33:07 <jic23> Or here the Fifo count which boils down to the same thing.
Jun 06 16:33:08 <alexhiam> kiran4399: what's in dmesg after loading it?
Jun 06 16:33:28 <alexhiam> kiran4399: you changed what to 400Hz?
Jun 06 16:34:17 <jic23> Could run trigger less and poll less frequently plus drop timestamp support like we would do for a Fifo with a watershed interrupt
Jun 06 16:34:45 <alexhiam> right, but of course timestamps are pretty darn important in this case
Jun 06 16:34:51 <alexhiam> or can be at least
Jun 06 16:35:00 <kiran4399> alexhiam: http://pastebin.com/jdJSrknt
Jun 06 16:35:07 <jic23> But that would be rather different to how this part is currently used.
Jun 06 16:35:26 <jic23> Quite on timestamps.
Jun 06 16:37:11 <alexhiam> kiran4399: can you push your overlay to github?
Jun 06 16:37:55 <jic23> Fifos are great but make timing just that little bit trick to establish. Can do them sort of right with a watershed interrupt if frequency known but it's a pain
Jun 06 16:40:55 <kiran4399> my base overlay where I changed bus speed: https://github.com/kiran4399/bb_blue_api/blob/master/install_files/2016-05-01/am335x-boneblack.dts#L1405
Jun 06 16:41:13 <kiran4399> alexhiam: mpu6050 overlay: https://github.com/kiran4399/bb_blue_api/blob/master/install_files/2016-05-01/BBBMPU6050-00A0.dts
Jun 06 16:41:55 <alexhiam> kiran4399: you shouldn't change it there, you should do that in the overlay
Jun 06 16:42:02 <alexhiam> https://github.com/kiran4399/bb_blue_api/blob/master/install_files/2016-05-01/BBBMPU6050-00A0.dts#L48
Jun 06 16:43:21 <alexhiam> kiran4399: it looks like there must be some other changes that haven't been back ported to the rcn tree: https://github.com/beagleboard/linux/blob/4.4/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
Jun 06 16:43:55 <alexhiam> i.e. the mount-matrix property is not documented
Jun 06 16:44:19 <alexhiam> kiran4399: so you did disable universal-io?
Jun 06 16:45:38 <jic23> Mount matrix is optional so drop it if you like. Only matter on parrots drones so far that I know of :)
Jun 06 16:46:15 <jic23> Is it a 6050?
Jun 06 16:46:33 <alexhiam> good point
Jun 06 16:47:35 <alexhiam> jic23: btw, I could not get that inv_mpu6050 patch set for the secondary i2c bus merged. It failed against the rcn tree with the back ported iio blob, and even trying a 3-way merge on mainline the last 3 patches failed
Jun 06 16:48:14 <alexhiam> may just be a shortage of linux-fu on my part
Jun 06 16:48:48 <jic23> Can"t remember if driver cares though...
Jun 06 16:49:32 <kiran4399> alexhiam: no .. I did not..
Jun 06 16:50:07 <alexhiam> kiran4399: really? I would have thought the exclusive-use would have clashed in that case...
Jun 06 16:50:26 <alexhiam> maybe they left the exclusive-use out of universal-io....
Jun 06 16:51:30 <jic23> Alexhiam probably some clashes, will take a look.
Jun 06 16:52:00 <jic23> Lot of churn on some of these drivers.
Jun 06 16:52:24 <alexhiam> kiran4399: you muxed P9_25 to an input? and you'll want to change 'mpu6050' to 'mpu9150' as jic23 pointed out (there's no mpu9250 in this version, but it should be compatible...)
Jun 06 16:52:54 <jic23> Driver doesn't care, in fact later part numbers not all listed yet.
Jun 06 16:53:13 <alexhiam> jic23: yeah, it seemed like it might have depended on a patch that hadn't been upstreamed. I didn't do much investigating though
Jun 06 16:54:19 <alexhiam> jic23: same whoami value, is that the only difference between them?
Jun 06 16:54:38 <alexhiam> looks like it
Jun 06 16:55:21 <alexhiam> only the 6500 is different
Jun 06 16:55:46 <kiran4399> alexhiam: ok.. will do it.. but the procedure which I am following is correct right??
Jun 06 16:56:55 <alexhiam> kiran4399: yeah, looks right to me. Hopefully the probe should succeed once the irq gpio pin is muxed right
Jun 06 16:57:39 <alexhiam> if it doesn't work using config-pin then I'd say the next thing to try is disabling universal-io and adding the interrupt pin mux to bb_i2c2_pins in your overlay
Jun 06 16:59:24 <kiran4399> alexhiam: alright..
Jun 06 17:02:25 <kiran4399> alexhiam: btw.. when shall we have the "more detailed plan for this project" with the other mentors?
Jun 06 17:03:00 <kiran4399> alexhiam: like.. I just want to discuss on where I am going..
Jun 06 17:03:02 <kiran4399> in general
Jun 06 17:03:45 <alexhiam> kiran4399: can you email us some times when you'll definitely be online in the coming week or so?
Jun 06 17:03:58 <alexhiam> need to find a time we're all online
Jun 06 17:04:15 <kiran4399> I'll be online everyday.. anytime..
Jun 06 17:04:28 <kiran4399> I am having holidays.. alexhiam.
Jun 06 17:04:34 <alexhiam> kiran4399: and be sure to ask on here right away if you don't know what to do next
Jun 06 17:04:38 <alexhiam> kiran4399: awesome
Jun 06 17:05:20 <alexhiam> I gotta go afk for lunch, I'll be back on in a bit...
Jun 06 17:05:39 <kiran4399> alexhiam: one more thing;
Jun 06 17:06:01 <kiran4399> can you tell me the plan for this week?
Jun 06 17:06:02 <kiran4399> alexhiam:
Jun 06 17:13:45 <jic23> hi all. I'm being a muppet. Want to grab the rcn tree you guys are using, but for some reason a pull of rcn's git hub tree isn't giving me the relevant commits.
Jun 06 17:14:01 <jic23> Any magic?  Looks a bit like github has messed up his tree entirely from ehre.
Jun 06 17:19:13 <jic23> hmm. think I got my refspec wrong.. oops.
Jun 06 17:19:31 <jic23> that and rcn leaves everything in orphaned tags. What fun.
Jun 06 17:25:34 <jic23> and boy does github like to be slow when serving a tag request... bored now.
Jun 06 17:36:47 <chanakya_vc> hey bradfa I am back. Dinner extended into a family meeting so sorry for the delay :P
Jun 06 17:38:15 <chanakya_vc> I have pushed the makefile that I am using.I corrected the paths for where the pru code generation tools and software support pkg is present
Jun 06 17:39:26 <jic23> alexhiam, kiran4399 - looking at the rcn IIO backport issues with the invensense patches.  There is a nasty here - he's not picked up
Jun 06 17:39:39 <jic23> the i2c mux changes from mainline.
Jun 06 17:39:53 <jic23> Really which rcn had broken that mega backport up into multiple patches.
Jun 06 17:40:11 <chanakya_vc> bradfa, Now What I don't understand is that I just downloaded the .sh files from the TI site and then I just installed them.I don't think it installed the clpru and all into the correct path.
Jun 06 17:40:34 <chanakya_vc> I am unable to figure this out :(
Jun 06 17:43:40 <bradfa> chanakya_vc: can you pastebin the output of running your makefile?
Jun 06 17:43:52 <bradfa> chanakya_vc: let me setup a chroot so I can try to do what you did and see if I can reproduce it
Jun 06 17:45:53 <chanakya_vc> Okay just one sec bradfa
Jun 06 17:46:23 <bradfa> chanakya_vc: it'll take me a few minutes to setup the chroot and install the ti tools
Jun 06 17:46:45 <chanakya_vc> bradfa, Okay!
Jun 06 17:47:10 <bradfa> chanakya_vc: it doesn't help that half the pru tools are built for i386 while the other half are 64 bit :)
Jun 06 17:48:04 <chanakya_vc> bradfa, True that :P . TI guys seriously need to take stock of the situation :P
Jun 06 17:48:29 <jic23> hohum. ti tree is borked if some nutter tries to build it for x86.
Jun 06 17:48:49 <bradfa> chanakya_vc: I suspsect they are two very different groups of engineers and in any big company groups don't always talk to each other even if the customers use things from both groups
Jun 06 17:51:43 <chanakya_vc> bradfa, Just reading a bit on chroot,so it basically turns the user into a sort of local root user for a particular process?
Jun 06 17:52:45 <bradfa> chanakya_vc: there's a few uses for chroot, you can also run another distro within your distro, effectively, that's what I use it for in this case.  Some background: http://www.bradfordembedded.com/2014/02/debootstrapping
Jun 06 17:52:58 <bradfa> chanakya_vc: notice what my use case was when I wrote that :)
Jun 06 17:53:22 <bradfa> chanakya_vc: where did you install the ti_cgt_pru tools? what directory path?
Jun 06 17:53:41 <bradfa> chanakya_vc: and where did you install the ti-processor-sdk tools to?  pathwise?
Jun 06 17:53:52 <bradfa> I will setup my installs the same way
Jun 06 17:55:09 <chanakya_vc> bradfa, Okay I just ./<sh > file after doing chmod +x the particular .sh file. So it got first installed/unpacked in the download directory itself I presume.
Jun 06 17:55:52 <bradfa> chanakya_vc: ok, by default the ti_cgt_pru tools wanted to install into my home dir
Jun 06 17:56:28 <chanakya_vc> bradfa, Then I copied the entire folder to my desktop and put it in a folder called pru_compiler.And then I gave the path in my makefile
Jun 06 17:56:41 <chanakya_vc> bradfa, Do you think that is the problem?
Jun 06 17:56:49 <bradfa> chanakya_vc: ok, and your ti-processor-sdk tools are installed in the same directory?
Jun 06 17:56:58 <bradfa> chanakya_vc: I don't know if that's the problem yet or not
Jun 06 17:57:09 <bradfa> chanakya_vc: just trying to match up what you've done so I can repeat your steps
Jun 06 17:57:19 <chanakya_vc> Yup.Both the folders are within the same folder.
Jun 06 17:57:26 <bradfa> chanakya_vc: ok
Jun 06 17:57:28 <bradfa> chanakya_vc: one sec
Jun 06 17:57:59 <chanakya_vc> bradfa, Before that can you give me the links from you downloaded both.So we haven't downloaded different stuff just in case?
Jun 06 18:01:54 <bradfa> chanakya_vc: http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/latest/exports/ti-processor-sdk-linux-am335x-evm-02.00.02.11-Linux-x86-Install.bin  http://software-dl.ti.com/sitara_linux/esd/PRU-SWPKG/latest/exports/pru-addon-v4.0-Linux-x86-Install.bin  http://software-dl.ti.com/codegen/esd/cgt_public_sw/PRU/2.1.2/ti_cgt_pru_2.1.2_linux_installer_x86.bin
Jun 06 18:02:07 <bradfa> chanakya_vc: it's worth putting those links into your wiki docs
Jun 06 18:03:47 <bradfa> hmmm
Jun 06 18:04:08 <chanakya_vc> bradfa, I think that I have all the three same as yours.
Jun 06 18:04:22 <bradfa> chanakya_vc: I'm finding the pru-addon doesn't want to install for me...
Jun 06 18:04:41 <chanakya_vc> bradfa, Why ? :D
Jun 06 18:07:08 <bradfa> dunno, it says my sdk directory is invalid...  http://pastebin.com/hkpdWdeG
Jun 06 18:08:48 <chanakya_vc> bradfa, I guess it wants you to select the exact directory where you installed the sdk?
Jun 06 18:08:48 <bradfa> ah! it's already in the processor sdk so the addon isn't needed any more I guess
Jun 06 18:08:59 <chanakya_vc> Ohkay
Jun 06 18:09:02 <bradfa> http://processors.wiki.ti.com/index.php/PRU-ICSS_Installer
Jun 06 18:10:54 <bradfa> chanakya_vc: ok, so when you run your Makefile, can you pastebin what the result is?
Jun 06 18:11:07 <jic23> alexhiam / kiran4399 just did a version of rcn's tree with the new invensense series on it.  Few fun corners.  Firstly you'll want to drop the final patch (as that will break the beaglebone most likely ;)
Jun 06 18:11:13 <jic23> That was just to allow me to build test it.
Jun 06 18:11:18 <chanakya_vc> Okay,here it is:http://pastebin.com/iSAkghJX
Jun 06 18:11:22 <chanakya_vc> bradfa, ^^
Jun 06 18:11:43 <bradfa> chanakya_vc: you need to ensure that your 'clpru' application is in your PATH
Jun 06 18:11:46 <jic23> https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/
Jun 06 18:11:57 <jic23> experimental-beaglefun
Jun 06 18:12:07 <chanakya_vc> bradfa, Okay how to figure that out?
Jun 06 18:12:12 <bradfa> chanakya_vc: export PATH=$PATH:/home/vc/Desktop/beagle-gsoc/compile/ti-cgt-pru_2.1.2/bin
Jun 06 18:12:45 <jic23> (IIRC experimental will zero day builder hammering it - funnily enough ti kernel doesn't meet standard tree rules that you must not break other archs)
Jun 06 18:12:58 <chanakya_vc> bradfa, So I will add this to the makefile?
Jun 06 18:13:01 <jic23> Trashes usefulness of autobuilders.
Jun 06 18:13:16 <bradfa> chanakya_vc: no
Jun 06 18:13:20 <chanakya_vc> bradfa, Why you don't see if the my file compiles and build?
Jun 06 18:13:30 <bradfa> chanakya_vc: there are many issues with your make file :)
Jun 06 18:13:35 <jic23> Anyhow, I'm not 100% sure rcn picked up the later i2c mux patches so this may well not work.  The fact it builds is encouraging though...
Jun 06 18:13:44 <chanakya_vc> Okay bradfa :p
Jun 06 18:13:46 <jic23> he last grabbed them in May which 'might' just have been recent enough.
Jun 06 18:14:26 <chanakya_vc> bradfa,  I am in a lot of hurry to see if the SPI code is working is or not :P
Jun 06 18:14:38 <bradfa> chanakya_vc: one sec, I'll fork your github and push a few changes which might help and send you apull req
Jun 06 18:14:46 <jic23> At least one DAC was borked completely in that tree due to a missing header.
Jun 06 18:14:52 <chanakya_vc> Okay bradfa
Jun 06 18:15:29 <jic23> Anyhow, off now - kiran4399 - let me know how you get on.
Jun 06 18:15:31 <jic23> bye all.
Jun 06 18:36:01 <bradfa> chanakya_vc: you have a pull request on github
Jun 06 18:36:22 <bradfa> the output binary is too big to fit, but the compielr is at least now doing the right things
Jun 06 18:36:34 <bradfa> chanakya_vc: see my note in the pull req, you should put that kind of info into a README
Jun 06 18:38:12 <bradfa> chanakya_vc: but I have to run now, if you have more questions please let me know but I'm unlikely to be able to spend more time on this today, but I'll look tomorrow morning my-time to help more
Jun 06 18:38:38 <chanakya_vc> Okay bradfa Is the code compiling?
Jun 06 18:39:01 <bradfa> chanakya_vc: yes, but it doesn't fit into the space allotted by the linker command file
Jun 06 18:39:13 <chanakya_vc> bradfa, I will install all the links again as you have given and test it myself.
Jun 06 18:39:32 <bradfa> likely you can just tweak the linker command file to make the space bigger or you need to enable other things in the compiler to get smaller output
Jun 06 18:39:58 <bradfa> chanakya_vc: you shouldn't need anything but the ti-cgt-pru tools, there's no dependency on the ti-sdk or pru-addons any longer
Jun 06 18:40:19 <chanakya_vc> bradfa, I am going to get the output on the logic analyzer,don't you worry! Thanks for your help so much
Jun 06 18:40:26 <chanakya_vc> So the last link?
Jun 06 18:40:36 <bradfa> chanakya_vc: yes just the last link is all you need
Jun 06 18:40:57 <chanakya_vc> Okay but it just installs as a folder
Jun 06 18:41:03 <bradfa> chanakya_vc: the makefile in my pull req defaults to finding the ti-cgt tools in your home directory, but you can tell it to look somewhere else as eneded as documented in the pull req
Jun 06 18:41:13 <chanakya_vc> Okay gotcha
Jun 06 18:41:20 <bradfa> sorry, gotta run now
Jun 06 18:41:24 <alexhiam> chanakya_vc: you might have a better time just ditching ccs altogether and building on the BeagleBone
Jun 06 18:41:28 <bradfa> be back tomorrow
Jun 06 18:41:34 <chanakya_vc> Thanks bradfa,meet you tomorrow
Jun 06 18:41:43 <bradfa> alexhiam: we're building with just ti-cgt on x86 host
Jun 06 18:41:48 <bradfa> no ccs, no bbb
Jun 06 18:41:54 <chanakya_vc> alexhiam, I am not using ccs.It is horrible
Jun 06 18:42:03 <alexhiam> ah, well that's good ;)
Jun 06 18:42:27 <alexhiam> still, one less step, and the firmware is small enough that there's not any real compile time difference
Jun 06 18:43:03 <chanakya_vc> alexhiam, And just today a gentleman from TI came and was praising ccs so much. I so wanted to tell him the truth but couldn't due to my professors
Jun 06 18:43:11 <chanakya_vc> :(
Jun 06 18:43:44 <alexhiam> well, there's certainly worse IDEs...
Jun 06 18:44:11 <chanakya_vc> alexhiam, It's because TI funds my lab :P
Jun 06 18:44:19 <chanakya_vc> actually :P
Jun 06 18:44:28 <alexhiam> I wish TI would fund my lab
Jun 06 18:45:42 <chanakya_vc> alexhiam, They have a university program or something where they fund labs in colleges,at least in India,don't know about US.
Jun 06 18:46:09 <alexhiam> well, my lab is in my house, so probably no program for that
Jun 06 18:48:27 <alexhiam> kiran4399: any luck with the imu?
Jun 06 18:49:08 <chanakya_vc> alexhiam, hmmn..you could ask them? Perhaps they do fund individuals?
Jun 06 18:49:53 * chanakya_vc has a TI Summer Workshop going on in his college
Jun 06 18:50:04 <bradfa> chanakya_vc: I pushed one more commit to my wip-on-spi-bradfa branch
Jun 06 18:50:17 <bradfa> may be worth looking at, still doesn't build right but closer :)
Jun 06 18:50:54 <bradfa> now really going, have to go to a meeting
Jun 06 18:50:57 <chanakya_vc> bradfa, Got it .Will look into it
Jun 06 18:51:13 <chanakya_vc> Thanks .I will be online same time tomorrow
Jun 06 19:09:27 <ZeekHuge> Hey ! part number to disable HDMI in /boot/uEnv.txt ?
Jun 06 19:10:22 <ZeekHuge> 4.4.11-ti-r29
Jun 06 19:26:13 <pmezydlo> ZeekHuge: hi, on 4.4.11-ti-r29 image HDMI is disabled from the beginning
Jun 06 19:26:48 <pmezydlo> you checked cape slots?
Jun 06 19:28:10 <jic23b> Kiran4399 - just a hunch but there was something odd in the forward port of the driver in rcn's tree. Might actually have gotten broken. You may need to debug through the steps in the probe routine.
Jun 06 19:28:56 <ZeekHuge> pmezydlo, I dont think so http://paste.debian.net/719335/, the pins are muxed.
Jun 06 19:29:02 <jic23b> Not certain it was broken through. Built fine...
Jun 06 19:29:47 <alexhiam> ZeekHuge: look in /boot/uEnv.txt
Jun 06 19:31:24 <alexhiam> ZeekHuge: looks like it's not using bone_capemgr.disable_partno anymore
Jun 06 19:31:48 <alexhiam> so 'dtb=am335x-boneblack-nhdmi-overlay.dtb' for HDMI video and audio disabled and the eMMC still enabled
Jun 06 19:32:54 <ZeekHuge> but its actually getting executed:
Jun 06 19:32:57 <ZeekHuge> root@beaglebone:~# dmesg | grep HDMI
Jun 06 19:32:57 <ZeekHuge> [    0.000000] Kernel command line: console=ttyO0,115200n8 bone_capemgr.disable_partno=BB-BONELT-HDMI root=UUID=97a2d95b-e240-4255-9101-7a8e7bb94cef ro rootfstype=ext4 rootwait coherent_pool=1M quiet cape_universal=enable
Jun 06 19:34:35 <alexhiam> ZeekHige: did you add BB-BONELT-HDMI?
Jun 06 19:34:44 <ZeekHuge> yep .
Jun 06 19:34:47 <alexhiam> I don't think that overlay even exists anymore
Jun 06 19:34:52 <ZeekHuge> okay .
Jun 06 19:39:12 <alexhiam> seems like it it uses am335x-boneblack.dts unless the dtb variable is set in there
Jun 06 20:42:28 <nerdboy> did someone dork up the project page?
Jun 06 20:42:55 <nerdboy> http://elinux.org/BeagleBoard/GSoC/2016_Projects  <=  videos in the wrong slot or is that just firefox being weird?
Jun 06 20:43:18 <nerdboy> starting with ZeekHuge project...
Jun 06 20:45:45 <nerdboy> oh yeah, i added some rcn-patched u-boot/kernel recipes to small-arm layer => https://github.com/sarnold/meta-small-arm-extra
Jun 06 20:46:02 <nerdboy> *started adding
Jun 06 20:46:40 <nerdboy> build with vct bsp manifest on yocto/poky or oe-core/meta-ti
Jun 06 20:57:55 <ZeekHuge> http://paste.debian.net/719611/
Jun 06 20:58:04 <ZeekHuge> what is it trying to do ? ^^
Jun 06 21:24:25 <nerdboy> looks like devicetree overlay
Jun 06 21:27:40 <alexhiam> ZeekHuge: looks like universal-io
Jun 06 21:27:50 <alexhiam> https://github.com/cdsteinkuehler/beaglebone-universal-io
Jun 06 21:28:04 <ZeekHuge> yep
Jun 06 21:28:25 <ZeekHuge> i just got that :)
Jun 06 21:28:31 <alexhiam> "univ-emmc" - I guess one that doesn't conflict with the eMMC
Jun 06 21:29:10 <ZeekHuge> but the pins that it misses belong to hdmi
Jun 06 21:29:31 <ZeekHuge> okay no
Jun 06 21:29:32 <ZeekHuge> sorry
Jun 06 21:29:35 <ZeekHuge> got it
Jun 06 21:29:45 <alexhiam> ZeekHuge: you get what it's doing?
Jun 06 21:29:48 <alexhiam> and why?
Jun 06 21:29:54 <ds2> where is our wind speed measuremens?
Jun 06 21:30:20 <alexhiam> hmm, good question...
Jun 06 21:30:34 <ZeekHuge> yes, its like skeleton. right ? just remove the extra bits and use what you need . right ?
Jun 06 21:30:36 <ZeekHuge> alexhiam, ^
Jun 06 21:31:42 <alexhiam> ZeekHuge: no, it's to make pinmuxing easier. The AM335x pinmuxing is done through the Control Module, whose registers can only be written from kernel space
Jun 06 21:33:05 <alexhiam> that overlay triggers the bone-pinmux-helper to create a sysfs entry for every mux-able pin on the headers, with keywords that can mux each pin to each possible mode
Jun 06 21:33:22 <ZeekHuge> ahh .. I am getting confused .. (probably sleep)
Jun 06 21:33:36 <ZeekHuge> so no need of dts now ?
Jun 06 21:33:50 <ZeekHuge> no echo BB-SOMETHING > $SLOTS ?
Jun 06 21:34:00 <alexhiam> right
Jun 06 21:37:30 <alexhiam> unless a cape is detected or another overlay is loaded in uEnv.txt, in which case there would be pin conflicts and universal-io would fail to load. Then it's back to the capemgr way
Jun 06 21:38:23 <alexhiam> ZeekHuge: that's what the config-pin utility uses (`config-pin --help` on the bone)
Jun 06 21:39:56 <ZeekHuge> Sorry it may sound a dumb question and maybe I missed it, but how long it have been there ?
Jun 06 21:40:21 <ZeekHuge> I mean all this, univ-dts
Jun 06 21:40:46 <ZeekHuge> and muxing without dts ?
Jun 06 21:40:51 <alexhiam> ZeekHuge: it's been around for a while here: https://github.com/cdsteinkuehler/beaglebone-universal-io
Jun 06 21:41:10 <alexhiam> but it got upstreamed to rcn's tree in 4.1 I think
Jun 06 21:41:47 <alexhiam> pre-3.8 (pre-DT) there was a kernel driver for muxing
Jun 06 21:41:59 <ZeekHuge> I used overlays to mux on 4.1 If i remember.
Jun 06 21:42:03 <ZeekHuge> anyways
Jun 06 21:42:07 <ZeekHuge> got it :)
Jun 06 21:42:23 <ZeekHuge> Thanks alexhiam :)
Jun 06 21:42:33 <alexhiam> ok, maybe it's only been enabled by default in 4.4
Jun 06 21:42:37 <alexhiam> np
Jun 06 21:47:17 <ds2> just do it as a proper kernel driver and be done with
Jun 06 21:47:32 <ds2> all those are security bypasses
Jun 06 21:57:18 * nerdboy jut got the adcs and receive side transducers
Jun 06 21:57:52 <nerdboy> and someone's last day of finals/school is today
Jun 06 22:00:04 <ds2> nerdboy: so that someone is working 2 weeks less?
Jun 06 22:57:11 <nerdboy> no, i'm not sure what he has to report now
**** ENDING LOGGING AT Tue Jun 07 02:59:58 2016