**** BEGIN LOGGING AT Sat Mar 12 02:59:58 2016 Mar 12 04:48:10 morning all ! Mar 12 07:48:42 vvu: I got BBBlfs to work! :D The problem I had was due to wrong file permissions. Mar 12 07:51:00 The problem was that the repo had been cloned on a separate (Windows) partition with NTFS file system, which does not have support for file permissions like linux as compared to ext4 file system. Mar 12 13:38:04 alexhiam: ping Mar 12 13:51:31 alexhiam: how many pru servo ports will be there in beaglebone blue? Mar 12 13:52:30 alexhiam: are the strawson api's used for writing the ardupilot's interface to beaglebone blue? Mar 12 14:30:57 kiran4399: sayys 8 here: http://beagleboard.org/blue Mar 12 14:31:45 ardupilot would at least use interface with the same kernel drivers (e.g. through sysfs) that the API would Mar 12 14:32:25 I haven't looked in detail at ardupilot, but I assume if the C API were to get done first it could just be used in ardupilot Mar 12 15:26:11 Hey! please help, I am unable to get this DT overlayed : http://paste.debian.net/414573/ Mar 12 15:26:43 I mean, this get overlayed, but dosent makes any difference in pinmux settings . Mar 12 16:01:25 <[1]pmezydlo> hi, I'm writing simple driver usb on beaglebone, code is here: Mar 12 16:01:25 <[1]pmezydlo> http://pastebin.com/SJCBs9rs Mar 12 16:01:26 <[1]pmezydlo> and I installed with the command "insmod usb_driver.ko", Mar 12 16:01:26 <[1]pmezydlo> when I check it on linux with the command lsusb Mar 12 16:01:26 <[1]pmezydlo> Unfortunately there is no such device on my vendor id. Mar 12 16:01:26 <[1]pmezydlo> Can You help me? Mar 12 16:06:09 hey [1]pmezydlo ! Wasnt your dt similar to this : http://paste.debian.net/414573/ ? This gets overlayed but the pinmux settings do not get changed . Mar 12 16:06:57 Can you help with this ? Mar 12 16:13:18 <[1]pmezydlo> ZeekHuge: Did you disable hdmi in uenv? Mar 12 16:17:01 [1]pmezydlo, yes, i did Mar 12 16:20:59 <[1]pmezydlo> ZeekHuge: try to change 0x06 to 0x25? Mar 12 16:26:36 <[1]pmezydlo> ZeekHuge:I tested all the pins Mar 12 16:47:30 alexhiam: pru servo driver can also be used for esc's right? Mar 12 16:48:22 alexhiam: what I mean to say is... those ports can be used for connecting to esc's when we use beaglebone in quiadcopters.. Mar 12 16:48:45 kiran4399: is there any standalone ros on beaglebone black? Mar 12 16:49:11 alexhiam: is there any standalone ros on beaglebone black? Mar 12 16:50:31 alexhiam: should we make any reciever driver for bb blue which is compatable with the ardupilot reciever-transmitter system? Mar 12 18:03:08 please help me with this. Mar 12 18:03:18 I am unable to mux the pin 830 Mar 12 18:03:20 http://paste.debian.net/414601/ Mar 12 18:04:37 while, at the same time, when i am trying this (https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-UART1-00A0.dts) dt, its able to change the mux settings Mar 12 18:04:51 on its pins ofc. Mar 12 18:04:55 hey ZeekHuge Mar 12 18:05:02 Hey m_w ! Mar 12 18:05:06 Hows you ? Mar 12 18:05:14 lemme take a look Mar 12 18:05:20 please :) Mar 12 18:08:38 still using 4.1 kernel Mar 12 18:08:39 ? Mar 12 18:08:45 yes Mar 12 18:09:36 uname -a : Linux beaglebone 4.1.17-ti-rt-r48 #1 SMP PREEMPT RT Fri Feb 12 23:46:00 UTC 2016 armv7l GNU/Linux Mar 12 18:10:38 You know where the source for this kernel is? Mar 12 18:10:56 yes, I also have it on my system. Mar 12 18:12:02 git remote -v Mar 12 18:12:27 ohk link ? ... this is https://github.com/beagleboard/linux/releases/tag/4.1.17-ti-rt-r48 Mar 12 18:12:54 okay it am cloning the repo Mar 12 18:13:04 will you be installing it now ? Mar 12 18:13:30 I will be look at the source Mar 12 18:13:35 looking Mar 12 18:13:41 ohk . Mar 12 18:14:16 if I don't see anything obvious I will compile and install it on the BBB I obtained Mar 12 18:14:44 ohk, so do you think its problem in the kernel ? Mar 12 18:15:01 I mean , my steps and the dt is correct ? Mar 12 18:15:12 certainly a kernel problem Mar 12 18:16:24 you know which dts is the top level one that is used with your kernel? Mar 12 18:16:52 not exactly. Mar 12 18:17:16 there was one dts that used to get loaded on boot. I disabled it in uEnv.txt Mar 12 18:17:52 you will need at least one top level dts Mar 12 18:17:59 probably am335x-boneblack.dts Mar 12 18:19:37 yes, I can see that from the "pinmux-pins" files that some dts is there. Mar 12 18:20:07 will the uEnv.txt help ? thought everything in it is commented out. Mar 12 18:21:35 maybe Mar 12 18:27:23 why are you grepping for 830? Mar 12 18:30:51 well, I even tried 834 Mar 12 18:31:29 try a30 and see what it spits out Mar 12 18:32:44 you are muxing pin 30 in the dt overlay Mar 12 18:33:22 0x030 Mar 12 18:33:58 uEnv : http://paste.debian.net/414606/ Mar 12 18:34:00 a30 should show pin mux'd by the pruss Mar 12 18:34:07 ahh.. Mar 12 18:34:32 so what does it output? Mar 12 18:35:17 pin 140 (44e10a30.0) 00000028 pinctrl-single Mar 12 18:35:38 that is not it Mar 12 18:36:01 but, don't we use the offset to point the pin in dt ? Mar 12 18:36:31 put the whole pins output in a pastebin Mar 12 18:37:11 0x30 = 48 decimal Mar 12 18:40:20 just a second.. Mar 12 18:43:07 P8_12 is GPIO1_12 Mar 12 18:43:52 I will be back in 5 minutes . Please :) Mar 12 18:44:00 BGA pin T12 Mar 12 18:44:15 okay I will type here as I figure things out Mar 12 18:45:50 T12 pinname is GPMC_AD12 Mar 12 18:47:54 so 0x30 is the correct pin Mar 12 18:53:02 and you want to to be GPIO input or output? Mar 12 18:53:48 or pr1_pru0_pru_r30_14? Mar 12 18:56:13 isnt 830 = pr1_pru0_pru_r30_14 ? Mar 12 18:56:23 830 =0x830 Mar 12 18:56:26 0x30 Mar 12 18:56:36 not 0x830 Mar 12 18:56:46 you have it correct in the dts Mar 12 18:56:51 0x030 Mar 12 18:56:58 ;) Mar 12 18:57:30 https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP8HeaderTable.pdf Mar 12 18:57:38 that is what i am following Mar 12 18:58:40 as far as i have got it, i think 0x830 is the address from the gpios address. and the 30 is offset, wrt to 44e10800 Mar 12 18:58:49 am i right ? Mar 12 18:59:20 i think so Mar 12 19:00:26 can you just pastebin the following? cat $PINS/pins Mar 12 19:00:36 so I can see the whole output Mar 12 19:01:29 sure. http://paste.debian.net/414612/ Mar 12 19:02:00 morning Mar 12 19:02:33 Morning Abhishek_ :) (or evening acc to your time zone ) Mar 12 19:02:43 *our Mar 12 19:03:23 well no, I dint see the time. its more than 12:00 Mar 12 19:04:28 are you expecting from the pins output? Mar 12 19:06:25 also if it will help, $PINS/pinmux-pins: http://paste.debian.net/414613/ Mar 12 19:06:28 yes. Mar 12 19:06:56 it is not even changing .. Mar 12 19:07:42 http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator#dtogenerator Mar 12 19:08:28 http://stackoverflow.com/questions/25388487/beagle-bone-black-pru-device-overlay-for-fast-io-does-not-work Mar 12 19:08:33 ;) Mar 12 19:08:42 got to go for a while Mar 12 19:08:52 hope this helps Mar 12 19:11:56 ahh... that worked :| Mar 12 19:13:40 Hey Abhishek_ can you help me with this ? Mar 12 19:15:35 the dt that worked to change settings on pin p8_11 is http://paste.debian.net/414619/ Mar 12 19:16:03 and what i was trying is http://paste.debian.net/414601 Mar 12 19:16:51 so the main difference that i am able to see is the target in fragment 2 Mar 12 19:17:16 but why is it ocp ? shouldn't it be pruss ? Mar 12 19:21:43 you haven't really understood the way DTs work yet. Mar 12 19:22:55 You mean the structure of the dts file ? Mar 12 19:23:21 if you can please explain something about it . Mar 12 19:23:31 or direct me ? Mar 12 19:25:20 look at the kernel sources arch/arm/boot/dtbs Mar 12 19:25:50 *boot/dts Mar 12 19:29:30 ohk :) Mar 12 19:38:28 anybody got a good cross/arch assembler reference for my younger kid? Mar 12 19:48:08 <[1]pmezydlo> hi, I'm writing simple driver usb on beaglebone, code is here: Mar 12 19:48:08 <[1]pmezydlo> http://pastebin.com/SJCBs9rs Mar 12 19:48:09 <[1]pmezydlo> and I installed with the command "insmod usb_driver.ko", Mar 12 19:48:09 <[1]pmezydlo> when I check it on linux with the command lsusb Mar 12 19:48:09 <[1]pmezydlo> Unfortunately there is no such device on my vendor id. Mar 12 19:48:09 <[1]pmezydlo> Can You help me? Mar 12 20:39:34 ZeekHuge: see those links were of no use? Mar 12 20:39:57 what links ? Mar 12 20:40:14 the last two I sent Mar 12 20:41:18 Abhishek_, Ohk, so what I got from that repo, Is it like overidding the defined pin setup ? TI mean the node that we mention in the target gets appended/overwrote by the new configuration that the current dt writes ? Mar 12 20:41:38 Yes it did what was required . Thank you :) Mar 12 20:41:48 *it Mar 12 20:42:10 TI = that Mar 12 20:43:00 I am happy that it worked Mar 12 20:43:07 :) Mar 12 20:46:07 Abhishek_, and therefore we need to select the target, that already occupies the pin. Is it so ? Mar 12 20:57:45 pmezydlo: I think you are getting things a little backwards on how use works Mar 12 20:59:02 the driver you have will attach to a device 08f7:0002 Mar 12 20:59:21 it does not create the device magically Mar 12 21:00:18 if a device with the id 08f7:0002 is plugged in it will show on lsusb even if no driver is attached to it Mar 12 21:01:00 if your device driver is loaded and a device with id 08f7:0002 the probe will be called Mar 12 21:01:41 what are you trying to accomplish? Mar 12 21:13:27 m_w: I wanted to achieve simple communications using libusb, how do I connect the device to the controller? Mar 12 21:19:38 what exactly is the USB device and what USB does it plug into? Mar 12 21:21:41 m_w:USB is supposed to work in the simplest mode as a gadget. Mar 12 21:23:04 m_w: PC host sends data, I use LibUSB Mar 12 21:23:48 m_w:I thought that after installing the driver, usb controller finds out what is vendor id? Mar 12 21:25:02 so you want to use the BBB as a gadget and your PC as the host? Mar 12 21:28:33 here is a presentation about Linux based USB devices that saw at Linuxcon in 2014: Mar 12 21:28:36 http://events.linuxfoundation.org/sites/events/files/slides/LinuxConNA-Make-your-own-USB-gadget-Andrzej.Pietrasiewicz.pdf Mar 12 21:30:12 m_w: Yes, exactly Mar 12 21:34:23 m_w: thanks for the answer, i've been doing it all day. Mar 12 21:34:49 doing what? Mar 12 21:37:55 there is also some information on how to use gadget configfs in the kernel: Mar 12 21:37:57 https://kernel.org/doc/Documentation/usb/gadget_configfs.txt Mar 12 21:40:16 emulating a keyboard or mouse can be fun too: Mar 12 21:40:17 https://kernel.org/doc/Documentation/usb/gadget_hid.txt Mar 12 21:44:02 m_w: thanks, im starting to read Mar 12 21:44:11 m_w, what are the limitations of IIOs under linux ? Mar 12 21:46:29 ZeekHuge: how do you mean? Mar 12 21:47:34 I mean the limitations we have to make sure to overcome. Mar 12 21:48:06 the point of offloading? Mar 12 21:48:57 I mean, as jonathan said, it would be like a dma buffer. That means the should see it like a directly connected device ? Mar 12 21:50:23 the PRU would handle the lowlevel interaction and provide the result Mar 12 21:50:29 https://wiki.analog.com/_media/resources/fpga/peripherals/spi-engine3.pdf Mar 12 21:51:14 see the page "software based flow - challenges" Mar 12 21:53:48 we are trying to lower the main processor workload Mar 12 21:54:57 ohk so we will remove the "polling" part from cpu to pur's and the prus will then generate an interrupt for the cpu when necessary . like that ? Mar 12 21:55:08 yeah Mar 12 21:56:39 we can provide a way for PRU to be configured with the required protocol for access different devices Mar 12 21:57:59 have the PRU perform the tranactions and buffer could hold samples until Linux comes around to grab them Mar 12 21:59:03 the time in the interrupt content will be less and the main processor won't get swamped handling high frequency transactions Mar 12 22:00:16 ohk.. Mar 12 22:00:29 we should start with bitbanging and add the possibility of accessing the SPI/I2C hard controllers as a scretch goal or something Mar 12 22:00:41 thinking ... and ... reading ... Mar 12 22:02:11 we already have the example by malloy but we can make the PRU interface more flexible to allow users to set up for new devices with having to deal with the PRU assembly Mar 12 22:03:09 we can try to unify the access method that one would use for the FPGA and other types of realtime coprocessors Mar 12 22:04:01 it would not hurt to contact Lars-Peter Clausen and ask for some feedback and see if he has some code to look at Mar 12 22:04:35 and where can i contact him ? Mar 12 22:04:43 I now a lot of the FPGA stuff is on github but we need to look at the linux kernel/userspace Mar 12 22:05:42 he regularly supports the iio kernel subsystem Mar 12 22:06:30 send him an email at: Lars-Peter Clausen Mar 12 22:06:56 ohk, will do. Mar 12 22:07:07 cc myself and Jonathan Cameron Mar 12 22:07:33 sure. Mar 12 22:07:50 you have email address for us Mar 12 22:07:51 ? Mar 12 22:08:21 by lowlevel interaction, do you mean writing to the external devices' configuration registers ? Mar 12 22:08:29 my email ? Mar 12 22:08:49 no mine and Jonathan's email Mar 12 22:09:53 no, it isnt there on G+ Mar 12 22:10:08 and yes, the device's configuration and other registers Mar 12 22:10:27 mwelling@ieee.org, jic23@kernel.org Mar 12 22:10:35 ohk, thank you. Mar 12 22:10:51 but that would be device specific, wont it be ? Mar 12 22:11:08 and hence we'll have to add support for different devices ? Mar 12 22:11:19 it would be we want to be able to abtract the interface in some fashion Mar 12 22:12:23 handling different interfaces in a generic way is part of the challenge Mar 12 22:12:25 ohk, so the device would be available as a device file to os, and PRUs will handle the device. Mar 12 22:12:41 essentially Mar 12 22:12:48 what do you mean by different interface ? Mar 12 22:13:18 from device to device the protocol for accessing the data is different Mar 12 22:13:53 we need a way to define the protocol and generate the PRU programming Mar 12 22:14:11 or have a programmible interface built into the PRU Mar 12 22:14:58 they will be communicating over SPI, so how different interface ? Mar 12 22:15:13 they would just have different speeds. Mar 12 22:15:24 the register map for each device is different Mar 12 22:15:26 SPI or I2C Mar 12 22:15:32 ohk. Mar 12 22:16:41 the SPI or I2C code at the lowest level won't change Mar 12 22:16:48 can it be like, we provide options to user and the user will select the option suitable with the device. This would load the PRU with required code ? Mar 12 22:17:02 Ohk, i got that. Mar 12 22:17:11 but the methods for accessing the data and triggering will be device dependent Mar 12 22:17:48 yes, they will be.... Mar 12 22:18:15 I think it would be best if there was a way to describe the transactions occuring Mar 12 22:19:01 transactions ? change in values ? Mar 12 22:28:33 ZeekHuge: have you joined the BeagleBoard GSoC forum and mailed them your idea yet? Mar 12 22:28:40 https://groups.google.com/forum/#!forum/beagleboard-gsoc Mar 12 22:29:03 not yet, I want to first clear it in my head. Mar 12 22:29:31 Can you give me some links, like some practical applications .. Mar 12 22:30:07 can it be an application : https://wiki.analog.com/resources/tools-software/linux-software/colorimeter Mar 12 22:30:16 and this ? https://wiki.analog.com/resources/tools-software/linux-software/iio_oscilloscope Mar 12 22:30:40 sure those are okay Mar 12 22:32:41 http://exploringbeaglebone.com/chapter13/ Mar 12 22:32:48 and do you think https://wiki.analog.com/resources/tools-software/linux-software/libiio can be used ? Mar 12 22:33:09 this is an example of prior art and something to start from Mar 12 22:33:29 the analog link ? or chapter 13 ? Mar 12 22:33:43 chapter 13 Mar 12 22:34:00 you can probably find a way to use libiio Mar 12 22:35:18 this is after we have a based PRU iio driver Mar 12 22:35:28 yes. Mar 12 22:39:41 well send something to the list soon and hopefully they can help refine the idea Mar 12 22:40:18 and also email Lars, Jonathan, and myself Mar 12 22:40:34 I am going offline for a bit Mar 12 22:40:43 ohk . Thank you . Mar 12 22:40:51 will you be back after about Mar 12 22:40:59 5-6 hours ? Mar 12 22:41:14 not sure on the number of hours Mar 12 22:41:20 5-6 max Mar 12 22:41:29 * ZeekHuge need some sleep. Mar 12 22:41:33 Ohk.. Mar 12 22:41:41 Thank you :) Mar 12 22:41:45 sleep well Mar 12 22:41:48 Have a good day then :) Mar 12 23:12:51 Hey alexhiam , what do you think about this idea ? Mar 12 23:13:16 About implementation of an IIO engine and offloading it to PRUs ? Mar 12 23:13:48 That would basically involve defining a clear interface to communicate the IIO device. Mar 12 23:14:21 and would encapsulate support for many devices. Mar 12 23:14:32 IIO based devices. Mar 13 00:01:26 Hey alexhiam ,Just had an idea.I was looking at implementation of the I2C driver and it turns out that the parameters are basically written to different registers in the memory. Mar 13 00:02:38 So if we could just create the same registers in the shared memory,we could basically simply change the memory mapping of the existing driver for I2C in linux and make it work for our purpose Mar 13 00:02:53 What do you think? **** ENDING LOGGING AT Sun Mar 13 02:59:58 2016