**** BEGIN LOGGING AT Sun Mar 06 02:59:58 2016 Mar 06 03:02:12 Question regarding applications and mentors: should we have a mentor arranged/commited before we submit applications? Or will mentors choose project applications they would like to work with after the deadline? Mar 06 04:48:57 hey ZeekHuge how is it going? Mar 06 04:50:03 Hi m_w ! Alls good ! Reached my place today morning ! Mar 06 04:50:10 excellent Mar 06 04:50:28 and now back to work. Mar 06 04:50:47 well I dont know much python myself Mar 06 04:51:13 we should stick with the remoteproc stuff Mar 06 04:51:31 check this out Mar 06 04:51:52 so, m_w , would it be better to choose an idea myself and work towards that ? or just go on the way i am going and let mentors decide a it ? Mar 06 04:52:17 the project is your choice Mar 06 04:53:03 mentors are here to give ideas and help you achieve your goals Mar 06 04:53:12 So, I'll have to choose a project anyway. I cant just go to mentors and ask them to give me a project ? Mar 06 04:53:38 https://plus.google.com/+MichaelWelling79/posts/inp2PYdpPQg Mar 06 04:54:27 you have to submit a proposal but it is probably best to shoot it past the mentor group to see if anyone is a good match for the project Mar 06 04:55:30 what do you think of the idea that Jonathan Cameron had? Mar 06 04:56:39 essentially you have the PRU control one of the peripheral interfaces and handle low level transactions Mar 06 04:57:18 Yes, that looks cool ! Mar 06 04:58:42 see if you can ellaborate on that idea a bit Mar 06 04:58:59 Yeah, will have to do a bit of research . Mar 06 04:59:27 Will be ready with doubts and thoughts when you are back on your next day. Mar 06 04:59:44 check out the link I posted for the FPGA framework for Analog Devices Mar 06 05:00:04 I am going to watch a movie and chill for now Mar 06 05:00:12 :) Mar 06 05:00:19 I will check in after it is over Mar 06 06:55:21 * m_w has been kicking around the idea of a PRU based PPM/PWM encoder/decoder Mar 06 06:55:51 haven't the ArduPilot/Dronecode guys already done it? Mar 06 06:56:21 probably Mar 06 06:57:26 https://groups.google.com/forum/#!topic/beagleboard/_XF6HKYLyps Mar 06 06:59:10 http://copter.ardupilot.com/wiki/common-ppm-encoder/ Mar 06 06:59:49 sigh... stop wasting the PRU Mar 06 07:00:27 wasting it?!? Mar 06 07:03:11 how about the PRU SPI device offload project? Mar 06 07:05:08 wouldn't that be limited to slow speeds? Mar 06 07:05:22 how so? Mar 06 07:05:31 I mean, it 200 MHz and you need at least a couple on instructions to clock out data Mar 06 07:06:11 Oh nvm, I think speeds like 50 MHz may be achievable Mar 06 07:06:44 you thinking of bitbanging SPI? Mar 06 07:06:45 assuming you generate the entire SPI waveform in-memory and stream it out of the PRUs Mar 06 07:06:48 yep Mar 06 07:07:04 that'd be BeagleLogic, in reverse. Mar 06 07:07:04 this is taking it to another level Mar 06 07:07:27 using the SPI controller from the PRU if possible Mar 06 07:08:02 abstracting the SPI transaction to be performed in the PRU Mar 06 07:08:50 performing ADC transactions for instance Mar 06 07:11:28 "wasting" the PRU instead of the main CPU :) Mar 06 07:12:20 ds2 would count that as PRU abuse Mar 06 07:12:54 then what is it good for? Mar 06 07:15:55 it seems everyone is buzzing around the PRU but nobody is doing anything but bitbanging Mar 06 07:16:23 the PRUs are highly optimized for that I guess. Mar 06 07:17:01 no pipelining and all Mar 06 07:20:58 ds2: what is your killer app for the PRU? Mar 06 07:21:43 PRUduino? ;) Mar 06 07:23:40 that horse has already been beaten Mar 06 07:44:50 it appears that the SPI controller is not accesible from the PRU Mar 06 07:50:39 all snark and no bite Mar 06 11:37:04 hey anyone there? Mar 06 11:37:56 .. Mar 06 11:38:05 ktx: hi Mar 06 11:38:17 hi! Mar 06 11:38:42 so this is the place to talk about projects right? Mar 06 11:38:53 ktx: yepp Mar 06 11:39:02 cool Mar 06 11:39:55 so, i've been pondering over an idea and i wanna make it work. Mar 06 11:40:49 and i wonder if its good enough, whether i can submit it to the organizers Mar 06 12:11:21 Hi, I have been trying to flash my BBB using the BBBlfs program Mar 06 12:11:49 And I am struck at building the file Mar 06 12:12:14 Whenever I run ./autigen.sh , it says command not found Mar 06 12:12:33 *(./autogen.sh) Mar 06 12:13:07 I have installed the required dependencies as well after googling the error, still not working Mar 06 12:13:21 Please help if possible. Thanks. Mar 06 16:03:08 chmod +x ./autogen.sh Mar 06 16:03:19 maybe Mar 06 17:09:22 Hey ! I have a question. Mar 06 17:09:50 Why are there so many projects trying to bit-bang some bus protocol using PRUs? Mar 06 17:10:39 are they trying to overcome some limitations of the SPI under linux ? Mar 06 17:11:54 I don't think so Mar 06 17:12:21 just augment with additional interfaces Mar 06 17:13:37 Hey m_w ! You mean just to one more " me too" SPI port to the board ? Mar 06 17:13:54 yup Mar 06 17:14:53 the PRU could have protocol to devices as well Mar 06 17:15:38 ZeekHuge: there's also some things, like the 1-wire protocol for WS2812 LED drivers, that you can't really do from Linux because of its non-realtime nature Mar 06 17:16:00 offloading it from the main processor Mar 06 17:17:17 ohk alexhiam . Then why isnt any project trying to incorporate that into the PRU ? Mar 06 17:17:51 it's already been done a few times, e.g. ledscape Mar 06 17:18:36 though all 2812 PRU projects I've seen are a bit outdated and could use some improvement, so it could be a possible part of a project, but not enough to be its own project alone Mar 06 17:20:34 is there a list of PRU projects anywhere? Mar 06 17:20:58 was about to ask that ! Mar 06 17:21:54 searching "pru" at http://beagleboard.org/project/ yields a few Mar 06 17:22:10 but certainly far from complete Mar 06 17:23:35 http://processors.wiki.ti.com/index.php/PRU_Projects Mar 06 17:24:32 nice Mar 06 17:24:43 * alexhiam forgot about pru forth! Mar 06 17:25:09 forth is good for old timers Mar 06 17:25:28 forth is good for everyone Mar 06 17:26:02 :) Mar 06 17:28:37 nixie-tubes ? are they still used ? Mar 06 17:29:33 for a good time ;) Mar 06 17:58:06 m_w, with very limited knowledge, i think that SPI can be accessed from PRUs. Mar 06 17:58:47 and if I am able to recall correctly, the PRU constant table already has the entry for the two SPI modules Mar 06 17:58:55 let me check .. Mar 06 18:04:59 here it is http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#Constants_Table Mar 06 18:09:23 * nerdboy is swapping in and out... Mar 06 19:03:52 cool Mar 06 19:04:57 can you confirm on the target? Mar 06 19:11:04 You mean trying it ? Mar 06 19:11:09 on BBB ? Mar 06 19:11:16 yeah Mar 06 19:11:43 ahh, well . The wheel isnt running yet ;) Mar 06 19:12:49 blink some leds yet? Mar 06 19:13:51 did you notice that the pru-software-support-package has example inside of it? Mar 06 19:14:27 yes i did. but the pruss_remoteproc isnt working as it should on 4.1 Mar 06 19:14:58 :-/ Mar 06 19:15:51 Will try tonight, building as was said in the hands on lab Mar 06 19:50:51 carpediem_: had any luck with bbblfs ? Mar 06 19:51:07 sorry Mar 06 19:51:13 tried again and again Mar 06 19:51:21 you need to install automake Mar 06 19:51:23 and autoconf Mar 06 19:51:25 for all the tools Mar 06 19:51:28 I installed them Mar 06 19:51:38 so why is it not building now ? Mar 06 19:51:45 a pastebin would be useful Mar 06 19:51:52 and the error is definitely one caused due to missing dependencies Mar 06 19:52:06 ok, will try and post Mar 06 20:12:39 alexhiam, I am a bit confused regarding Device tree overlays.I read that basically the kernel cannot discover devices on running time and hence cannot initiate the required drivers. Mar 06 20:13:50 alexhiam, So basically in my case I would have to write the DT overlay describing the PRU as a SPI,I2C device and then when the user would load the necessary dt overlay,the kernel would load the required driver? Mar 06 20:14:50 alexhiam, Am I correct in my reasoning? Mar 06 20:19:29 chanakya_vc: sort of - the DT overlay tells the kernel to load pru-rproc which configures and enables the pru, and also to load the specific rproc extension driver Mar 06 20:20:13 during initialization, the driver then creates the dev file interface, e.g. a spidev file Mar 06 20:20:33 Such a dt overlay would already exist I suppose.Would just have to modify it? Mar 06 20:20:55 the beaglelogic overlay is a good example Mar 06 20:21:37 but you would want to make sure you have a good understanding of how the DT works, and what all the config stuff in there does Mar 06 20:23:10 Okay. Will do that.I could use the Beaglelogic as a base right? Mar 06 20:23:29 beaglelogic overlay Mar 06 20:24:01 for sure. Just be sure to adhere to the gplv3 license and maintain copyrights and all that Mar 06 20:27:13 So finally,the entire project involves writing the Dt overlay(for each I2C,SPI,UART).This overlay would then load the PRU-rproc(which the Beaglelogic overlay already does) and the required extension driver to the rproc,which i would write for all the three protocols Mar 06 20:28:34 write, plus the PRU firmware for each protocol Mar 06 20:28:44 and then the driver would form an interface between userland and shared memory. Mar 06 20:28:51 yes Mar 06 20:28:55 yup Mar 06 20:29:18 the overlay also loads the appropriate firmware to the pru: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts#L232 Mar 06 20:29:19 Finally got the hang of the entire project :) Mar 06 20:29:41 okay i thought the driver was responsible for that Mar 06 20:30:35 and, just as important as all that coding (if not more important), is good documentation of everything, and some example programs that use each Mar 06 20:37:32 I read that there can be only one Device tree binary per one board? Mar 06 20:38:22 alexhiam, So I would have push my changes into the existing DTO for beaglebone and then recompile it? Mar 06 20:39:30 right - there's the base Device Tree description of the BeagleBone - but then there's a mechanism for loading Device Tree overlays, which make run time changes to the base DT Mar 06 20:41:08 so you'd write it as an overlay, like the beaglelogic one is, and that could either be applied manually at run time, or at boot time by enabling it in uEnv.txt Mar 06 20:41:43 http://linux-sunxi.org/UEnv.txt Mar 06 20:43:05 Okay.Got it. One more thing regarding the firmware.When not loaded where is it located? I have some idea i guess about UEnv.txt.It is basically the file that contains all the environment variable set up by the bootloader right? Mar 06 20:44:46 yeah, uEnv.txt is basically a config file for the bootloader. The compiled PRU firmware lives in /lib/firmware Mar 06 20:45:45 that's the standard place the kernel looks when a driver requests firmware Mar 06 20:46:06 https://www.kernel.org/doc/Documentation/firmware_class/README Mar 06 20:46:44 Again the same question regarding the firmware,I would have to recompile all of it?Or or some other way?And we would be using TI's compiler for the same? Mar 06 20:48:13 what do you mean recompile all of it? Mar 06 20:49:24 during the build phase the firmware would be compiled by the TI pru compiler (which would be invoked in a Makefile), then the compiled binary would be deployed (i.e. copied) to /lib/firmware Mar 06 20:51:02 Okay got it.Is TI's compiler free for anyone to use? Mar 06 20:51:09 yup Mar 06 20:52:14 So basically there would be three such firmware binaries.And each would be loaded according to which driver is making the request? Mar 06 20:52:41 right Mar 06 20:52:44 And we would be cross-compiling right? Mar 06 20:53:47 or the compiling will be done natively on the board i guess since we are using makefile Mar 06 20:53:56 either way Mar 06 20:54:47 not hard to support both in the Makefile with some variables Mar 06 20:56:50 for dev it'll be easier to do compile natively Mar 06 20:57:03 because it's quicker to test Mar 06 20:57:43 Okay.I think I have understood the entire project.I think the biggest challenge for me is to learn how to write drivers. Mar 06 20:58:47 I will come out with a detailed timeline on the ml. Mar 06 20:59:00 yeah, so start with a "hello, world" driver on any linux box and build up from there Mar 06 20:59:10 sounds good Mar 06 20:59:50 In about two-three days.Thanks for your help! Mar 06 21:00:41 When you say a hello world driver what would it do? Mar 06 21:01:32 it would say "Hello, world" (the standard 'first programming task'). e.g.: http://www.tldp.org/LDP/lkmpg/2.4/html/c147.htm Mar 06 21:02:11 Ohh.Like just print that to standard ouput :) Mar 06 21:03:05 right, except it'll print it to the kernel because there is no user-facing stdout ;) Mar 06 21:04:26 Didn't know that drivers also had a 'hello world' equivalent. Mar 06 21:04:58 Thanks.Will do that.But I guess for now will work on the timeline. Mar 06 21:40:44 carpediem_: did a fresh git clone and works...can you chmod +x autogen.sh and then try again Mar 06 21:45:32 Still same error, I guess a system reboot is required Mar 06 21:46:15 will try once again after reboot and get back to you **** ENDING LOGGING AT Mon Mar 07 02:59:58 2016