**** BEGIN LOGGING AT Wed Mar 02 02:59:59 2016
Mar 02 07:13:09 <ibrahiminfinite> hi
Mar 02 07:14:32 <ibrahiminfinite> who all are here participating for GSoC ?
Mar 02 07:20:36 <kartik_> hi everyone
Mar 02 07:21:23 <kartik_> i am very excited to work on implementing optical flow using image processing on ardupilot
Mar 02 07:21:56 <kartik_> i have submitted my ideas on google grroup
Mar 02 07:22:22 <kartik_> with the name Interested in PRU related project - kartik nighania
Mar 02 07:23:34 <kartik_> and i think by implementing a camera with the PRU will make image processing smooth and fast for other robotics project using image processing algos
Mar 02 07:26:52 <nerdboy> start with stereo images and see what performance is like
Mar 02 07:27:02 <nerdboy> better ask for a blue
Mar 02 07:30:46 <kartik_> rightnow im using opencv library for implementing above..
Mar 02 07:31:11 <kartik_> and soon will compile the code on the beaglebone black and see the result
Mar 02 07:32:07 <ibrahiminfinite> any mentors here ?
Mar 02 07:35:06 <kartik_> nerdboy: can u please help me with the camera specs to be used
Mar 02 07:35:45 <nerdboy> check the references
Mar 02 07:36:04 <nerdboy> http://arxiv.org/pdf/1412.6153.pdf <= robot avoidance version using stereo image processnig
Mar 02 07:36:13 <nerdboy> http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-117.pdf
Mar 02 07:40:50 <kartik_> nerdboy: thanks a lot sir .. ill get back to you soon
Mar 02 07:41:33 <ibrahiminfinite> i want to propose a new project , a new platform on the beagle board
Mar 02 07:42:10 <ibrahiminfinite> it is a project that  i am contributing to currently , from MIT Media lab
Mar 02 07:42:41 <ibrahiminfinite> the platform currently is adapted to the Raspberry pi and arduino Yun
Mar 02 07:43:46 <ibrahiminfinite> i would like to make it for beagleboard black ( it is an IoT application and requires ntetwork , wirelss prefered)
Mar 02 07:49:24 <nerdboy> get the right cape
Mar 02 07:50:48 <ibrahiminfinite> nerdboy: can you point me to where i should start
Mar 02 07:51:06 <nerdboy> <shrug>
Mar 02 07:51:28 <nerdboy> proto cape and parts or one of the wifi/bt capes
Mar 02 07:51:50 <nerdboy> google is your friend => beaglebone black capes
Mar 02 07:56:54 <ibrahiminfinite> nerdboy : thanks for that,  is it possible for me to apply to GSoC with this idea ?
Mar 02 07:57:22 <nerdboy> sure, if it involves enough software
Mar 02 07:57:34 <nerdboy> as in new/modified code
Mar 02 08:02:17 <ibrahiminfinite> nerdboy : yes it does , the openhybrid is a platform ( server ) it runs on any linux system , what i plan to do is to make a harware interface code for it
Mar 02 08:02:40 <ibrahiminfinite> to enable the use of GPIO with openhybird
Mar 02 08:02:48 <ibrahiminfinite> openhybrid*
Mar 02 08:04:36 <ibrahiminfinite> currently ,i have not worked with a beagleboard before, so have to wait till i receive a board if i get selected
Mar 02 08:05:12 <ibrahiminfinite> this is the site www.openhybrid.org
Mar 02 08:07:16 <ibrahiminfinite> i have posted a posted it in the google group also
Mar 02 09:50:01 <Abhishek_> morning
Mar 02 10:45:14 <kartik> nerdboy
Mar 02 10:45:19 <kartik> sir
Mar 02 10:47:11 <kartik> nerdboy: what about optical flow implementation using imageprocessing by camera attached to the pru? does the project deals with having both stereo as well as optical flow implemented
Mar 02 11:00:21 <Abhishek_> kartik: you don't have to address anyone as "sir" here, just use the IRC channel names.
Mar 02 15:29:40 <sacha> How many students will be taken this year??
Mar 02 15:29:58 <av500> we dont know yet
Mar 02 15:30:12 <av500> assume 6-8
Mar 02 15:31:43 <sacha> ok
Mar 02 15:45:27 <sacha> av500: I am interested in "Linux Kernel support for embedded devices".I am not a guru.But using Debian for 2 years.I have basic knowledge in kernels,Pyhton,Digital Electronics,Microprocessors,DLX arch,MIPS.Can I hope a place in bbgsoc'16?
Mar 02 15:47:38 <hv9> BBB-based Serial Terminal Server: I'd love to help out with that.
Mar 02 16:08:07 <_av500_> sacha: please sign up on the mailing list and introduce yourself
Mar 02 16:09:25 <sacha> av500:ok
Mar 02 16:43:06 <anujdeshpande> alexhiam: we should play rock paper scissors to pick who replies :-D
Mar 02 16:44:14 <alexhiam> lol. You beat me by a few seconds :(
Mar 02 17:01:58 <nerdboy> kartik: first, ardupilot only does sensor fusion, not vision processing
Mar 02 17:02:34 <nerdboy> and you should ask in public, there are a lot of mentors here...
Mar 02 17:03:47 <nerdboy> all the vision stuff is done on the "host" side, assuming there is a host and not just an autopilot
Mar 02 17:04:29 <nerdboy> in this case the beaglebone is both the autopilot controller and the host
Mar 02 17:04:50 <kiran4399> alexhiam: do you want to me to fork the linux repo and write the drivers for imu and baro in the "drivers folder" ?
Mar 02 17:05:07 <nerdboy> but you have 2 PRUs to offload some tasks
Mar 02 17:05:37 <nerdboy> the main question is "how fast?" can it process images in real-time
Mar 02 17:06:35 * nerdboy wondering why nobody looks at sonic anemometer...
Mar 02 17:06:57 <anujdeshpande> Some people do have reservations about running application code like image processing, web servers, etc. on the same board as the one that is running the autopilot.
Mar 02 17:08:22 <nerdboy> depends on optimization, but there's a reference showing decent performance on bbb without any PRU help
Mar 02 17:08:55 <nerdboy> http://arxiv.org/pdf/1412.6153.pdf
Mar 02 17:09:17 <nerdboy> decent stereo image processing
Mar 02 17:11:21 <kartik> Yes sir,  i have already gone through the above pdf
Mar 02 17:11:33 <kartik> And is working on with the other one
Mar 02 17:14:03 <nerdboy> that was an answer for anujdeshpande ...
Mar 02 17:14:16 <kartik> nerdboy: i am getting exactly what u r saying.. Thanks.
Mar 02 17:15:43 * nerdboy discovering the joys of breaking software he never heard of while rebuilding everything with LTO
Mar 02 17:17:45 <kartik> Nerdboy: right now due to hardware requirements,  ill have to choose between stereo imaging and optical flow sensing.  i have searched some good quality CMos cameras
Mar 02 17:17:55 <alexhiam> kiran4399: first look for what drivers already exist - I know there's some out there for the IMU, and likely for the barometer as well
Mar 02 17:18:10 <nerdboy> the optical flow stuff is probably too much overhead on bbb but stereo vision should be doable
Mar 02 17:19:39 <nerdboy> one camera can possibly be used to capture random images, second one for stereo
Mar 02 17:22:25 <kartik>  nerdboy: right sir. And then maybe ill have to take the images in parts due to the 12Kb memory constraint. And then use another linux host app that will use OpenCV image orocessing functions
Mar 02 17:24:45 <nerdboy> wel, the key thing would be partitioning the problem to take advantage of both
Mar 02 17:25:32 <nerdboy> as long as it's "separable" it could work...
Mar 02 17:26:02 <alexhiam> is there a rule of thumb refresh rate for depth maps? I guess it depends on the vehicle speed..
Mar 02 17:26:59 <nerdboy> that's part of it i think, need at least 5-10 Hz performance for usability
Mar 02 17:27:30 <alexhiam> so in theory the PRU doesn't need to process every frame then
Mar 02 17:29:23 <nerdboy> cheap cameras don't have a great framerate anyway...
Mar 02 17:30:12 <alexhiam> what would be the target camera? Webcams would be easiest, but needing a USB hub is a bit of a bummer
Mar 02 17:31:36 <nerdboy> the mavlink stuff uses usb input, image bus, shm processing
Mar 02 17:39:11 <alexhiam> nerdboy: on the optical flow sensor side, I imagine that could just be a kernel driver for the ADNS3080, which ardupilot already supports
Mar 02 17:44:45 <AndChat|231636>   nerdboy: as for now ordering and  making a cheap stereo camera will take time.. What else can i do to show my skills and move forward
Mar 02 17:48:01 <kartik> Opencv code is under process
Mar 02 17:51:55 <nerdboy> you just need two small ones and mount them
Mar 02 17:56:07 <alexhiam> seems like there could be some bandwidth issues with 2 webcams on the same usb 2.0 controller
Mar 02 17:56:24 <alexhiam> depending on the resolution
Mar 02 17:57:08 <kartik> Alesxhiam: sir we would be using the PRU unit for it for real time image processing
Mar 02 17:57:45 <alexhiam> I mean for the capture
Mar 02 17:58:53 <nerdboy> needs testing...
Mar 02 17:59:07 <nerdboy> http://www.sersc.org/journals/IJSIP/vol6_no4/16.pdf <= another optical flow paper
Mar 02 17:59:22 <alexhiam> though, what's the max resolution at which you could fit 2 images in the shared memory...
Mar 02 18:00:20 <nerdboy> http://people.inf.ethz.ch/lomeier/publications/IROS_2012_realtime_optical_flow_stereo.pdf <= here's the mavlink one by Meier
Mar 02 18:00:41 <kartik> Alexhiam: yes sir,  captured data input by PRU
Mar 02 18:01:35 <alexhiam> no... the images will be captured from the webcams by Linux... you certainly don't want to start by implement a USB host on the PRU to capture video...
Mar 02 18:05:38 <alexhiam> hmm... I hope they got that message...
Mar 02 18:10:08 <alexhiam> kartik: did you see my last message?
Mar 02 18:10:59 <kartik> Alexhiam: yes sir,  sorry fot the delay.. Network isnt working quite well here
Mar 02 18:12:16 <alexhiam> no prob, just making sure you saw that because it's important, implementing a camera interface in the PRU is not part of the project
Mar 02 18:15:26 <nerdboy> seems like plenty of evidence using the bbb
Mar 02 18:16:47 <alexhiam> for which part?
Mar 02 18:16:50 <kartik> Alexhiam: i was thinking about using the one one cmos sensors having the breakout pins..
Mar 02 18:17:12 <nerdboy> multiple usb camera inputs
Mar 02 18:17:19 <alexhiam> kartik: but what's the point when you have USB and Linux??
Mar 02 18:17:26 <kartik> Which can be connected for getting data
Mar 02 18:17:47 <alexhiam> nerdboy: cool. I hadn't really looked into it
Mar 02 18:18:16 <alexhiam> I'd guess the shared mem will be a bandwidth bottleneck before the usb controller anyways
Mar 02 18:19:13 <nerdboy> it will probably take a bit of profiling/performance optimization
Mar 02 18:19:13 <alexhiam> kartik: the short answer is there's no point, and implementing a cmos camera interface in the PRU would take up a huge amount of the gsoc time
Mar 02 18:19:39 <nerdboy> separate project?
Mar 02 18:20:39 <alexhiam> maybe... but don't we want the depth mapping done on the PRU? I guess in theory one PRU could do input and the other processing
Mar 02 18:21:02 <kiran4399> alexhiam: I've seen different drivers in the mainline linux repo...
Mar 02 18:21:09 <alexhiam> but it seems silly when the webcam/Linux method is well proven
Mar 02 18:21:17 <kiran4399> alexhiam: But I am not able to know where to start..
Mar 02 18:21:19 <nerdboy> the bare cmos widget uses gpio pins?
Mar 02 18:21:28 <kartik> Right sir..  I thought maybe using that we can get much higher speed. Which even now i think will only add up to unnecessary trouble
Mar 02 18:21:55 <kartik> Nerdboy: yes sir,  gpios only
Mar 02 18:22:06 <nerdboy> i just meant "general" use for that kind of cmos sensor would free up the other interfaces
Mar 02 18:22:16 <kiran4399> alexhiam: last year.. as part of beagleboard project I tried compiling a vanilla linux kernel.. so I am quite familiar with compiling kernels for bb black.
Mar 02 18:22:22 <nerdboy> what it's worth i have no idea...
Mar 02 18:22:34 <alexhiam> kartik: I'd consider that optimization for later. The stereo processing can be done with webcams
Mar 02 18:22:52 <kiran4399> alexhiam: Can you give me some initial goals to get me started?
Mar 02 18:24:21 <alexhiam> kiran4399: I guess you could start by building the beaglebone kernel (4.1) with existing drivers for the IMU, etc. enabled
Mar 02 18:27:31 <kartik> Alexhiam: okae sir, ill use the usb port..  What can i do for now to prove my skills..?
Mar 02 18:28:45 <kartik> For now stereo filters, triangulation, opencv library functions and other things related to it is what i am studying
Mar 02 18:30:33 <alexhiam> sounds good. If you can get a hold of two webcams you could also start looking at possibly mocking up a prototype of the stereo processing with opencv, maybe in Python to make it quick to implement
Mar 02 18:32:19 <alexhiam> kartik: and a post on the beagle-gsoc google group with an outline of what the project steps might be would be great
Mar 02 18:46:15 <kiran4399> alexhiam: I don't find the imu driver in 4.1..:-(
Mar 02 18:47:04 <roni> Hi
Mar 02 18:47:11 <alexhiam> where are you looking? in the kernel config?
Mar 02 18:47:41 <alexhiam> there might not be one upstreamed yet, so you might have to manually add it
Mar 02 18:48:29 <roni> Is there any mentor available for project "IIO debugging tools" from last year ideas?
Mar 02 18:51:06 <Abhishek_> What do you know about IIO?
Mar 02 18:59:08 <roni> It is a subsystem for doing ADC and DAC. Mainly on SPI/i2c devices. I don't have any experience in IIO. I have some kernel programming experience. I was just looking at code of IIO subsystem.
Mar 02 19:00:10 <roni> I looked into evtest tool code.
Mar 02 19:02:25 <utkagr1610_> How can i show my cross compiling skill here
Mar 02 19:09:59 <alexhiam> utkagr1610_: http://elinux.org/BeagleBoard/GSoC/Ideas#General_requirements
Mar 02 19:10:07 <alexhiam> #8
Mar 02 19:25:00 <mdp> roni_: wasn't the from 2014? the description is a bit odd as there's been a generic iio_event_monitor in the kernel tree for some time.
Mar 02 19:25:42 <mdp> roni_: however, there might be interest in an updated proposal that incorporates use of libiio.
Mar 02 19:25:57 <mdp> I suggest you take a look at libiio capabilities and propose something based on that.
Mar 02 19:31:08 <roni> ok
Mar 02 19:31:50 <roni> That was in the idea page of both 14 and 15.
Mar 02 19:31:55 <roni> I will try.
Mar 02 19:35:13 <mdp> ahh, ok. didn't find 2015..but if the description is the same then yeah, needs a little update. Take a look at tools/iio/iio_event_monitor.c in the kernel tree and then https://github.com/analogdevicesinc/libiio
Mar 02 19:38:28 <mdp> there's some clever possibilities for host-based control using  iiod. of course, this overlaps at bit with sigrok's support for generic- iio as well, which is worth looking at too when considering this type of project.
Mar 02 20:59:48 <m_w> anyone out there?
Mar 02 21:12:21 <m_w> hello
Mar 02 22:31:56 <m_w> testing 1 2
Mar 02 23:21:16 <ZeekHuge> Hey ! I need gnu/stubs-soft.h file. What package should i install ?
Mar 02 23:21:44 <ZeekHuge> 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 02 23:28:40 <m_w> Are you compiling on the target?
Mar 02 23:28:53 <ZeekHuge> yes. On BBB.
Mar 02 23:30:13 <ZeekHuge> m_w, These files are required for cross-compiling, if I am correct. But the make gives the error indicating this file as missing .
Mar 02 23:31:03 <m_w> can you providing the error line?
Mar 02 23:33:22 <m_w> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
Mar 02 23:34:23 <m_w> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099
Mar 02 23:36:04 <ZeekHuge> I am trying to make the PRU-framework cloned from https://github.com/shubhi1407/PRU-framework. There were many errors while making it ... it is one of them : http://paste.debian.net/411184/
Mar 02 23:38:11 <m_w> It looks like you are trying to use soft floating point on a hard floating point filesystem.
Mar 02 23:39:43 <ZeekHuge> ohk so I should try -mfloat-abi=hard ? as filt3r suggested ?
Mar 02 23:40:14 <m_w> yes
Mar 02 23:48:06 <m_w> What distro are you using?
Mar 02 23:50:01 <ZeekHuge> ah.. debian
Mar 02 23:55:36 <ZeekHuge> m_w, distro : Distributor ID:Debian Description:Debian GNU/Linux 8.3 (jessie) Release:	8.3 Codename:	jessie
Mar 02 23:59:23 <m_w> gcc -v
Mar 03 00:00:00 <ZeekHuge> No, the PRU-framework uses clpru by TI
Mar 03 00:00:06 <m_w> ah
Mar 03 00:00:24 <ZeekHuge> heres the Makefile  http://paste.debian.net/411188/
Mar 03 00:02:23 <ZeekHuge> btw, m_w , if everything goes right, the project should not need stubs-soft.h .right ?
Mar 03 00:04:29 <m_w> I believe so
Mar 03 00:07:38 <m_w> I think that you are mixing the clpru and gcc includes
Mar 03 00:09:17 <ZeekHuge> yes !
Mar 03 00:09:26 <ZeekHuge> Oh ! yes ! you are right !
Mar 03 00:09:43 <ZeekHuge> Let me fix it !
Mar 03 00:11:28 <m_w> I assume you did this:
Mar 03 00:11:33 <m_w> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#TI_PRU_Code_Generation_Tools
Mar 03 00:12:54 <ZeekHuge> yep. Already did :)
Mar 03 00:17:45 <pmezydlo> are we going to have a group chat with mentors tonight?
Mar 03 00:18:40 <nerdboy> debian is hardfloat now i thought...
Mar 03 00:19:53 <nerdboy> gentoo is hf by default for armv6 and above but you do have to tune yocto a bit
Mar 03 00:20:55 <nerdboy> TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard cortexa8"  <= call convention needs tweakage
Mar 03 00:21:39 <m_w> I think there was some compiler confusion going on here
Mar 03 00:22:42 <nerdboy> wrong toolchain?
Mar 03 00:22:59 <m_w> well he is trying to compile the PRU firmware
Mar 03 00:23:13 <pmezydlo> bradfa: i wrote my proposition on the mailing list, so if you have some time, please reply. thanks,
Mar 03 00:23:23 <nerdboy> which still needs cgt
Mar 03 00:24:02 <m_w> clpru
Mar 03 00:26:27 <m_w> well ZeekHuge jumped ship, hopefully he figured it out
Mar 03 00:54:29 <m_w> whois ZeekHuge_
Mar 03 00:54:38 <m_w> sorry
Mar 03 00:54:45 <ZeekHuge_> :)
Mar 03 00:55:24 <m_w> so you are back, did you get it to compile?
Mar 03 00:56:16 <ZeekHuge_> I am stuck with another error now .
Mar 03 00:56:29 <m_w> still with the firmware?
Mar 03 00:57:27 <ZeekHuge_> yes ,  rproc-pru0-fw successfully compiled. but theres problem with rproc-pru1-fw
Mar 03 01:00:09 <_ZeekHuge> m_w, the make now says : http://paste.debian.net/411212/
Mar 03 01:01:35 <m_w> interesting
Mar 03 01:03:02 <Zeekhuge> and when i am commenting out that function. it generates a lot more arrors
Mar 03 01:03:08 <Zeekhuge> *errors
Mar 03 01:04:21 <m_w> I am wondering where else it is defined
Mar 03 01:04:44 <m_w> what does your Makefile look like now?
Mar 03 01:05:32 <Zeekhuge> i am compiling it with  /lib/modules/4.1.17-ti-rt-r48/build/include/config/pruss/remoteproc.h
Mar 03 01:06:07 <Zeekhuge> will that be wrong ?
Mar 03 01:06:12 <Zeekhuge> Makefile : http://paste.debian.net/411214/
Mar 03 01:07:31 <m_w> I don't see the use of /lib/modules directory in the original Makefile
Mar 03 01:09:56 <Zeekhuge> it would complain about missing remoteproc.h then.
Mar 03 01:10:37 <Zeekhuge> btw I found the "already declared" definition
Mar 03 01:10:56 <Zeekhuge> it is inside syscall.h
Mar 03 01:11:25 <Zeekhuge> inside /root/Projects/PRUProjects/PRU-framework/firmware/src/include
Mar 03 01:12:27 <Zeekhuge> initially, pru_vring.h was missing. I googled and found this repo https://github.com/pantoniou/testpru
Mar 03 01:12:50 <Zeekhuge> so i cloned it, and transferred *.h files to the includes.
Mar 03 01:13:03 <m_w> okay
Mar 03 01:13:29 <Zeekhuge> should i go on and delete the definition from syscall.h?
Mar 03 01:14:08 <Zeekhuge> its exactly the same, so i am deleting it.
Mar 03 01:14:19 <Zeekhuge> *commenting out it
Mar 03 01:14:25 <m_w> is it the same function?
Mar 03 01:14:33 <m_w> codewise
Mar 03 01:15:23 <Zeekhuge> its exactly the same
Mar 03 01:15:38 <m_w> then delete the local copy
Mar 03 01:15:55 <m_w> not the one in the header
Mar 03 01:16:03 <Zeekhuge> ohk ..
Mar 03 01:18:33 <Zeekhuge> well, a lot more errors. in both the cases of deleting definition.
Mar 03 01:19:27 <Zeekhuge> errors : http://paste.debian.net/411227/
Mar 03 01:21:40 <Zeekhuge> so, thats error in the code ..
Mar 03 01:24:51 <m_w> it looks like incompatible versions or something
Mar 03 01:35:19 <Zeekhuge> m_w, can it be a problem with /lib/modules/4.1.17-ti-rt-r48/build/include/config/pruss/remoteproc.h being included ?
Mar 03 01:37:34 <m_w> maybe
Mar 03 01:37:47 <m_w> I am digging into the code now
Mar 03 01:37:59 <m_w> lemme see if I can get it to compile
Mar 03 01:38:14 <Zeekhuge> Sure :)
Mar 03 02:10:30 <m_w> wow what a pain
Mar 03 02:11:24 <m_w> I got it to compile with much pain
Mar 03 02:13:14 <Zeekhuge> How ?
Mar 03 02:13:30 <Zeekhuge> did you get these errors ?
Mar 03 02:13:55 <m_w> Try adding #include <rsc_types.h> to the top of pru_vring.c
Mar 03 02:14:37 <m_w> above  #include "pru_vring.h"
Mar 03 02:16:20 <Zeekhuge> HaHa !
Mar 03 02:16:28 <Zeekhuge> How did you find that ?
Mar 03 02:17:22 <m_w> well I kept adding things until I got the same error as you
Mar 03 02:17:36 <m_w> then fixed it
Mar 03 02:18:20 <m_w> now there is no gauranteed that the firmware like work but at least it compiles
Mar 03 02:20:34 <Zeekhuge> ohk so the correct definition of fw_rsc_vdev_vring was in <rsc_types.h>
Mar 03 02:20:46 <m_w> yes
Mar 03 02:20:55 <m_w> grep found it for me
Mar 03 02:20:55 <Zeekhuge> but how did you came to know that ? i mean ? how ? :)
Mar 03 02:21:09 <Zeekhuge> ohk ! Cool ! gotcha !
Mar 03 02:21:52 <Zeekhuge> Thank you ! let me go ahead and try to run the example. Will let you know the result :)
Mar 03 02:22:10 <m_w> excellent glad I could help
Mar 03 02:35:15 <Zeekhuge> m_w, unfortunately, the fw seems not to be working .
Mar 03 02:36:29 <m_w> can you try it with the binaries on the bin directory?
Mar 03 02:46:50 <Zeekhuge> no ! they are none of them working.
Mar 03 02:47:22 <m_w> is the pru enabled in the kernel?
Mar 03 02:47:39 <Zeekhuge> acc to lsmod, yes
Mar 03 02:48:15 <m_w> what happens when you try to run something?
Mar 03 02:48:55 <Zeekhuge> Well, i am trying to run the example as is in the README. the poll-write example
Mar 03 02:49:42 <Zeekhuge> on executing ./poll, it shoule wait for execution of ./write, bur in my case, it is returning immediately
Mar 03 02:49:49 <Zeekhuge> *should
Mar 03 02:50:43 <m_w> any kernel messages?
Mar 03 02:52:17 <Zeekhuge> no, nothing in dmesg or kern.log
Mar 03 02:53:02 <m_w> then it is likely not probing the driver
Mar 03 02:53:02 <Zeekhuge> I think the problem can be with pruss_remoteproc module
Mar 03 02:53:34 <m_w> did you add a devicetree entry for the module?
Mar 03 02:54:25 <Zeekhuge> ahh.. no .
Mar 03 02:54:53 <m_w> well you will need a device tree overlay to enable the PRU
Mar 03 02:55:32 <Zeekhuge> so the one that worked with prussdrv ?
Mar 03 02:56:26 <m_w> if you look at the driver you will need to register ti,am335x-pruss
Mar 03 02:56:47 <Zeekhuge> but it isnt metioned in the README, infact the README says :
Mar 03 02:56:52 <Zeekhuge> 2. Load driver by using modprobe pruss_remoteproc.
Mar 03 02:56:59 <Zeekhuge> 3. This will load the pru firmwares and boot the remote processors.
Mar 03 02:57:30 <m_w> well it isn't that easy
Mar 03 02:57:55 <Zeekhuge> Device tree do not have a precise definition . isnt it ?
Mar 03 02:58:11 <Zeekhuge> It is used for variety of functions .
Mar 03 02:58:25 <m_w> yes
Mar 03 02:59:23 <Zeekhuge> The initial being, routing the functionalities of different SoC components to the headers present on the board . Am i correct ?
Mar 03 02:59:51 <Zeekhuge> different SoC components =  PRUs, UARTS etc
**** ENDING LOGGING AT Thu Mar 03 02:59:58 2016