**** BEGIN LOGGING AT Fri Jun 13 02:59:59 2014 Jun 13 05:59:57 panto : I've been *very* sick whole of yesterday, and my bad luck seems to be continuing today, hopefully I'll get back to coding tomorrow :) Jun 13 06:36:57 morning ! Jun 13 06:37:07 morning vvu Jun 13 06:38:19 how is it going ? Jun 13 06:38:57 * Abhishek_ would be tinkering with the PRU firmware today Jun 13 06:40:40 goodie Jun 13 06:40:55 the last 2 days i'm tinkering with the BBB also insted of doing my "supposed work" :) Jun 13 06:55:37 did you get your wpa-supplicant thing working? Jun 13 06:58:08 nop, did not try much Jun 13 06:58:16 just hooked up an android phone and thether a bit Jun 13 06:58:38 i tried to bridge my ethetnet with usb on my Win machine but my account does not let me do that Jun 13 07:01:21 at least i am thanking my university for having a VPN and i can access IRC freely Jun 13 07:50:58 vlc500: jumped some release numbers i see Jun 13 07:54:27 :) Jun 13 09:24:27 karki Abhishek_ praveendath92 what do you guys do to update to the latest kernel version on the bbb? Jun 13 09:24:57 I didn't update mine. Jun 13 09:25:00 rseethamraju: I'm still running 3.8.13 (custom built kernel) Jun 13 09:25:34 ok. I did * cd /opt/scripts/ Jun 13 09:25:35 * git pull Jun 13 09:25:36 * sudo ./tools/update_kernel.sh Jun 13 09:25:36 * sudo reboot (You MUST reboot!!!!!) Jun 13 09:25:53 voltvisionsteve suggested that Jun 13 09:26:36 well I did that and at reboot it get stuck Jun 13 09:27:01 rseethamraju: did you do that with eMMC or SD Card image? Jun 13 09:27:07 it boots ok from the emmc flash though so I gues I’ll work with that for now Jun 13 09:27:16 Abhishek_: SD card Jun 13 09:27:33 it doesn’t work for that? Jun 13 09:28:09 rseethamraju: Sometimes my beaglebone black boots from eMMC inspite of the SD Card being present, at times I have found that a fsck on the card and a subsequent reboot gets it to boot from SD Jun 13 09:28:21 I don't know exactly why it happens Jun 13 09:28:33 no its trying to boot from the SD card and gets stuck Jun 13 09:28:40 like all the LEDs stay on Jun 13 09:28:50 when I remove the SD card it boots Jun 13 09:28:57 ah, you have the flasher image on the SD card? Jun 13 09:29:15 the one that flashes the eMMC on boot? Jun 13 09:29:33 no. I used the same image that used to work b4 I updated Jun 13 09:29:42 it worked Jun 13 09:30:03 then I updated that again and it stopped on reboot Jun 13 09:30:25 anyway I don’t need it for SPI so I’ll work the prev one for now Jun 13 09:30:43 are you switching to a new kernel for USB issues? Jun 13 09:31:10 I only just realized I need the latest the for eQEP driver Jun 13 09:31:18 I’ll come back to that later Jun 13 09:31:31 I see Jun 13 09:32:00 I’ll look into the USB driver thing once I do the SPI Jun 13 09:32:20 Abhishek_: thanks anyway =) Jun 13 09:32:39 k, the 3.8.13 kernel has USB hotplug issues with the bigger USB port Jun 13 09:32:47 IIRC Jun 13 09:32:48 power cuts are horrible now aren’t they Jun 13 09:33:54 it hasn't rained in Hyd yet? Jun 13 09:34:10 it has but power cuts are still going on Jun 13 09:34:33 I’m in the Captal and we had 3 and a half hrs of no power!! Jun 13 09:34:41 where do you live? Jun 13 09:35:00 currently at Jakarta, Indonesia Jun 13 09:35:14 oh! nice Jun 13 09:36:08 it's about to rain here Jun 13 09:36:16 lucky you Jun 13 09:36:23 its too hot here Jun 13 09:37:02 anyway thanks for the heads up on the USB driver Jun 13 09:37:17 my battery’s almost dead so ttyl Jun 13 09:44:48 panto: is it ok to move the beaglelogic-specific code into a new module leaving behind a little "glue code" for IRQ and downcall routing? Jun 13 09:48:40 also, right now my device appears in /sys/devices/virtual/misc/beaglelogic, can it be made to appear in say, /sys/devices/beaglelogic ? Jun 13 09:48:58 (while still being a misc device) Jun 13 10:15:05 back Jun 13 10:15:29 Abhishek_, move it out Jun 13 10:39:43 vlc500: have some time to take a look at a device driver ? Jun 13 10:39:57 usb code :( Jun 13 10:44:05 ok panto, moving it out Jun 13 10:44:50 do you have any structures in mind for the "glue"? Jun 13 10:45:12 I mean, exported functions? Jun 13 10:55:39 panto: My code currently uses these functions from rproc: pru_downcall_idx, pru_da_to_va_block and pru_handler. I also need access to the device tree as I have set some custom attributes to it: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/bb-beaglelogic.dts#L203] Jun 13 11:04:09 Abhishek_, just get it working for now Jun 13 11:04:22 this whole bunch of code is up for a major refactoring Jun 13 11:30:54 ds2: ping Jun 13 11:31:56 might be sleeping now Jun 13 11:33:29 0430 PST Jun 13 11:34:06 vvu: not today, i'm in paris Jun 13 11:34:13 meetings all day Jun 13 11:35:53 enjoying meeting like a boss in paris, anyway got the code working Jun 13 11:36:07 now need to find praveen Jun 13 12:21:42 panto: can I get the underlying struct device * pointer from the inode structure passed to fopen? Jun 13 12:28:28 yeah Jun 13 12:28:53 look in drivers/misc Jun 13 12:40:47 panto: I just got a misc driver that sets up a high-speed char device interface to read data from 4 FPGAs [drivers/misc/carma.c] Jun 13 12:42:49 it's similar Jun 13 12:43:21 everything is misc Jun 13 14:16:17 * vvu likes so much to hack on windows...much excitment Jun 13 14:27:19 * Abhishek_ realizes that dev_set_drvdata on misc devices sets the miscdevice as the drvdata by default, he was doing it wrong till now Jun 13 14:29:10 Abhishek_: no worries, i stayed 2 hours figuring out that i had 2 arguments shifted...and being same type no warnings no nothing Jun 13 16:22:26 alexanderhiam: everytime I write the kernel image onto my SD card (which is 8 GB) it partitions the card into a 1. BEAGLEBONE of 100MB 2. disk1s2 with 1.68 GB and 3. free space thats 6.17 GB Jun 13 16:22:57 rseethamraju: that's normal Jun 13 16:23:05 and then when I do an apt-get update && apt-get upgrade it says not enugh space Jun 13 16:23:11 rseethamraju: you mean the Debian image? It has to support 2G eMMC Jun 13 16:23:27 rseethamraju, are you using the new debian image? Jun 13 16:23:27 rseethamraju: /opt/scripts/tools/grow-partition.sh and reboot Jun 13 16:23:27 rseethamraju: http://inspire.logicsupply.com/2014/06/expanding-file-system.html Jun 13 16:23:54 Abhishek_: oh, didn't know that was there Jun 13 16:24:00 ya from the latest images page on elinux Jun 13 16:24:31 Abhishek_: ok trying that Jun 13 16:33:28 praveendath92: ping Jun 13 16:34:39 rcn-ee: what's your feeling on cape overlays moving past 3.8? Will they be obseleted in favor of something like the universal overlay? Jun 13 16:35:51 (I'm sure there's a discussion on this somewhere, but I can't find it) Jun 13 16:36:43 alexanderhiam, we've been talking a lot about the universal overlay in our weekly bb.org meeting. ;) As long as we have video/eMMC/etc on first boot and easy to for users to change things, I'm all for pushing it as the default. ;) Jun 13 16:37:30 in theory it should also work with non "overlay" v3.8+ kernel's, as it just a pinmux change.. Jun 13 16:37:42 will there still be a way to alter the tree on the fly? Jun 13 16:38:22 it's more about having everything enabled, but 'changing' the pinmux on the fly to get what you want enabled.. Jun 13 16:39:36 right... I suspect there'll have to be a few trade offs though Jun 13 16:39:53 power managment might be a big one. ;) Jun 13 16:42:29 :P Jun 13 16:43:58 rcn-ee: so what's on the todo list for making that happen? More drivers to handle all the subsystems? Jun 13 16:45:12 "todo list" what's that? ;) Jun 13 16:46:29 I'd say, start with the universal overlay, make it work as the main *.dtb, then try running it with v3.15.x (finding bugs has they happen) Jun 13 16:47:40 rcn-ee: Have the PRU drivers (remoteproc) and UIO been tested with the latest kernels beyond 3.8? Jun 13 16:47:49 no, they don't work Jun 13 16:48:17 Abhishek_, someone ported it to v3.12.x (never heard if it worked) Jun 13 16:48:20 ok, I might do just that. I'd like to get a head start on compatibility both with PyBBIO and the cape's I've designed Jun 13 16:50:13 alexanderhiam, tell we have a solution that 100% replaces the v3.8 tree, we will still have that old v3.8 tree... Jun 13 16:50:48 right Jun 13 17:04:35 Abhishek_ alexanderhiam It worked. Thanks! Jun 13 17:04:53 rseethamraju: great! Jun 13 17:05:08 :) Jun 13 17:05:34 with the power cuts and this today was bad! Thnakfully I have the night left! Jun 13 18:12:58 vvu: pong (late) Jun 13 18:16:14 no worries Jun 13 18:16:17 solved Jun 13 18:16:29 had some trouble with an usb device driver Jun 13 18:16:39 oh ok Jun 13 18:16:55 will u be around next week? Jun 13 18:17:02 nope Jun 13 18:17:08 I'll be out next week and the week following. Jun 13 18:17:08 okidokie Jun 13 18:17:30 email me... if you need me during that time Jun 13 18:17:42 maybe a small framebuffer question Jun 13 18:17:47 if i cannot solve it Jun 13 18:18:15 just email me.... might be slow but I'll see what I can do Jun 13 18:18:21 thx Jun 13 19:52:23 alexanderhiam: where should I add the SPI C extension link? Jun 13 19:52:51 rseethamraju: what do you mean? Jun 13 19:53:56 alexanderhiam like we added the C extension for kernelfileio to the util folder Jun 13 19:54:19 but karki’s i2c.py is inside beaglebone Jun 13 19:54:40 oh gotcha, I guess in that util folder as well for now Jun 13 19:55:36 I'll reorganize a bit this weekend to make it pip/apt-get distributable, so that may change Jun 13 19:56:39 hopefully by Monday I will have switched from Apache 2.0 to the MIT license so we can officially redistribute that Jun 13 19:59:24 alexanderhiam: for what reasons are you switching license [just curious]? Jun 13 20:00:25 alexanderhiam: that C extension library has methods for read, write, open, close and transfer Jun 13 20:01:34 Abhishek_: Apache 2.0 and MIT are pretty darn similar, and we're looking at redistributing a Python module that's under GPL 2.0. We can't do so with Apache 2.0 and we can with MIT Jun 13 20:01:47 so really because I'm lazy ;) Jun 13 20:02:22 hmm yes, Apache is compatible with GPLv3 and not with GPLv2 Jun 13 20:02:28 rseethamraju: does it do multi-byte transmission? Jun 13 20:02:36 alexamderhiam: and all of that works with simple functions like open(), close() and stuff Jun 13 20:02:56 Abhishek_: yeah, GPLv2 is a bit weird Jun 13 20:03:00 yes Jun 13 20:03:46 there are 2 kinds for tranfer : 1 in which the chip select is on throughout Jun 13 20:04:10 and the other where the CS is switched on and off between blocks Jun 13 20:04:29 rseethamraju: are CPOL and CPHA supported? Jun 13 20:04:54 I think you set that in the mode. Yes Jun 13 20:05:15 rseethamraju: can it transmit without driving a CS line? i.e. let the user control their CS lines themself Jun 13 20:05:26 alexanderhiam: you have to send the bytes in a list Jun 13 20:05:50 not the way he wrote it Jun 13 20:06:27 I mean its written in internal methods that we could expose to give that control Jun 13 20:06:51 ah ok, I think that might be good Jun 13 20:07:33 or at least have the user pass in the CS line as a PyBBIO GPIO variable, like GPIO1_7 Jun 13 20:07:36 I mean in the PyMethodDef he only gave open , close, transfer, read and write Jun 13 20:08:25 so how is the CS line controlled? Jun 13 20:08:30 I think you have to set the cs line when you create the object Jun 13 20:09:03 no wait Jun 13 20:09:39 you have to open the specific devices file and then he keeps using the same fd everywhere Jun 13 20:11:12 ok I'm looking at the file now Jun 13 20:13:42 ok, so it only supports the SPI module's buitlin CS signal, so it's up to us to control other CS signals Jun 13 20:15:12 so maybe if you pass a GPIO pin in for CS to our transfer method we would control it with digitalWrite(), and if it's not passed in then we just assume that the device is using the modules CS signal Jun 13 20:16:39 hmm, I'm wondering if we should implement that in that C extension to speed up the GPIO toggling for CS Jun 13 20:16:53 alexanderhiam: would it be a good idea to assume manual control if no pin is given? Jun 13 20:18:46 Abhishek_: the user can still do that, and I'm not sure if we can disable the CS signal with the SPI driver Jun 13 20:19:38 alexanderhiam: in the C extension Jun 13 20:20:59 alexanderhiam hes just changing the values the struct spi_ioc_transfer Jun 13 20:21:05 oh does it have a CS disabled mode? Jun 13 20:23:11 thats the only difference. The values for the struct are refreshed within the loop and outside the loop Jun 13 20:23:32 alexanderhiam: what do you mean by CS disabled mode? Jun 13 20:24:07 can you have it transmit without changing the state of the SPI module's CS signal? Jun 13 20:25:15 yes thats what it does in xfer2 Jun 13 20:25:56 in xfer it enables nad disables in between blocks Jun 13 20:26:21 Blocks is waht he said but thats each single item in the list Jun 13 20:29:12 right, but what I mean is if you have a device who's CS signal is attached to a GPIO pin and not the SPI module's built-in CS pin, then you don't want the module's CS pin to go low at all Jun 13 20:29:48 alexanderhiam: wouldn't changing the pinmux of the CS pin do that? Jun 13 20:30:25 Abhishek_: yeah, but that's a bit of a hack Jun 13 20:30:56 ya we’d have to do that in the device tree file Jun 13 20:31:20 I guess yes Jun 13 20:32:13 alexanderhiam: so when you create the object we can make the cs pin high Jun 13 20:32:24 I guess we could have a custom SPI overlays that let us change the mode between CS | pullup anf GPIO | pullup Jun 13 20:32:28 and* Jun 13 20:32:49 oh so you’re saying no xfer atall Jun 13 20:33:23 with that method we'd need to switch quickly between modes in case you have one device on the module's CS line and another on a GPIO pin Jun 13 20:33:34 the hardware IP as documented in the SoC datasheet says it supports non-CS asserting transfers, so it could be possible Jun 13 20:34:28 alexanderhiam: set_mode Jun 13 20:34:59 __SPI_set_mode Jun 13 20:42:00 rseethamraju: well let's not worry about that yet, let's get it working in the normal mode with the pre-existing SPI overlays for now Jun 13 20:43:19 that means load the overlay, create the object and that C extension will do everything else? Jun 13 20:49:29 you could have a wrapper class as well which has an begin() method that loads the appropriate overlay and instantiates an SPI object from the C extension. That way we could already have instances of the wrapper class called SPI0 and SPI1 (like how it's done for the serial ports: https://github.com/alexanderhiam/PyBBIO/blob/master/bbio/platform/beaglebone/serial_port.py#L152) Jun 13 21:06:16 alexanderhiam: ok I’ll put that up tomorrow. Its 2:30 now so I’m going to sleep Jun 13 21:51:56 panto: what can I do to access the pruproc structure maintained by the pru_rproc_driver from outside it, is there a better way of doing that other than maintaining a static copy of the pruproc structure in the pru_rproc module and then exporting a function to retrieve that static pointer? Jun 13 22:49:08 Hmmm **** ENDING LOGGING AT Sat Jun 14 02:59:58 2014