**** BEGIN LOGGING AT Sat Mar 05 02:59:58 2016 Mar 05 06:10:25 Is there a link to older logs ? Mar 05 06:14:01 hey m_w ! you still there ? Mar 05 06:29:29 I am here for a few Mar 05 06:30:22 http://logs.nslu2-linux.org/livelogs/beagle-gsoc/ Mar 05 06:31:04 whats up? Mar 05 06:32:34 Hey :) Mar 05 06:33:02 I was asleep while reading pruss_remoteproc.c Mar 05 06:33:35 okay Mar 05 06:33:42 it is working? Mar 05 06:34:23 * ZeekHuge just got tye flash back, in which his laptop fells from his lap, while he was asleep. Mar 05 06:34:48 * ZeekHuge is checking his laptop. Mar 05 06:36:46 You have until March 25th to submit your proposal by the way. Mar 05 06:38:53 yep :) Mar 05 06:39:13 * ZeekHuge 's laptop seems to be fine . pheww... Mar 05 06:40:28 what are you planning to do with remoteproc? Mar 05 06:44:33 * m_w is wondering if ZeekHuge fell asleep again Mar 05 06:46:13 * ZeekHuge was planning about the travel. Mar 05 06:47:04 you got an answer for ds2's question? Mar 05 06:47:52 Hey ds2 ! at this point, I am trying to get the hang of it, as alexhiam said, that remoteproc is the linux way of doing almost anything with PRUs Mar 05 06:48:21 Basically, I wish to be part of GSoC 2016 Mar 05 06:48:32 doing a project based on PRUs Mar 05 06:48:54 SPI flash emulator, or Blue APIs Mar 05 06:49:25 or anything that else that would seem to be cool ! Mar 05 06:49:27 :) Mar 05 06:49:59 So, at present, I am trying to get talk to the PRUs. Mar 05 06:50:29 but as m_w would say, it seems like reinventing the wheel. Mar 05 06:51:53 * ZeekHuge 's working speed would definitely increase when he'll reach his hostel room, in about next 24 hours. Mar 05 07:01:40 ZeekHuge, Not tried PRUspeak? Mar 05 07:09:29 http://beagleboard.org/pru Mar 05 07:09:50 No, well, PRU-framework was what developed to do this. So, I took that as athe starting point. Mar 05 07:10:20 chanakya_vc: so, I didn't try PRUspeak Mar 05 07:10:55 * ZeekHuge is waiting if ds2 would like to suggest and guide him with something. Mar 05 07:33:33 m_w: would you suggest using PRUspeak? I do not have any experience with python. Mar 05 07:45:47 chanakya_vc: I think that PRUspeak is not meant for this. If it was, there would have been no need for PRU-framework as a project. If I am able to recall correctly, PRU-framework was mentored by karki_ and, he developed PRUspeak. Mar 05 07:46:27 Also, PRUspeak is just to control GPIOs using PRU. and not to ofload some processing onto PRUs. Mar 05 07:46:40 Atleast thats what my understanding is . Mar 05 07:46:46 Am I right karki_ ? Mar 05 07:49:32 ZeekHuge : pretty much. You can offload tasks alright. but currently there is no support for other kinds of IO. Primarily GPIO only. Of course that can be extended! Mar 05 08:43:53 ohk karki_ , and can it be interfaced using C ? Mar 05 08:44:34 the linux side of PRU Speak opens various interfaces including FIFO, sockets, etc Mar 05 08:44:44 so yes, you can interface it with any language. Mar 05 09:53:14 karki_: I tried building up PRU-framework on 4.1.x and, as of now, it seems the kernel do not supports RPmsg. So, can we get PRUspeak working on 4.1.x without the support of RPMsg ? Mar 05 09:53:40 PRU Speak doesn't use RPMsg Mar 05 09:54:13 although... I haven't tried getting the PRU Speak running on 4.1 myself. Mar 05 09:57:38 ohk, then I'll try to get it working on 4.1 Mar 05 09:58:23 Well, my goal is to initially get a blinky on PRU and furthur bitbang SPI . Mar 05 09:58:40 karki_: It would be possible na ? Mar 05 09:58:51 I'm guessing Mar 05 09:58:58 but why exactly are you trying Mar 05 09:59:30 Ahh .. I wish to do a PRU based project for GSkC 2016. Mar 05 09:59:39 *GSoC Mar 05 10:00:05 one like the SPI flash emulator, or Blue APIs Mar 05 10:01:09 what do you ? would it be right to gon through PRUspeak ? or getting PRU - framework working will be the way to go ? Mar 05 10:01:19 *what do you think Mar 05 10:05:12 * anujdeshpande wonders if there should be a Chrome OS port for X15 Mar 05 10:18:10 ahh great ! someone has built the Chrome OS for beaglebone already http://www.chromium.org/chromium-os/developer-guide/beaglebone Mar 05 10:39:07 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 05 10:43:03 can someone please reply to the doubt i have raised right now on google group related to project- 'processing sensor data in real time' Mar 05 14:38:29 yashoza: please keep the gsoc questions to this public channel. Answers in private messages don't benefit anyone else here. Most/all mentors here ignore pms Mar 05 14:43:43 alexhiam, I was talking to m_w and nerdboy yesterday and they said the driver would basically give the user the ability to address the PRU as an I2C device as they would do in normal Linux. Mar 05 14:44:48 alexhiam: *All mentors*. I think this should go on the channel topic. Mar 05 14:45:21 alexhiam, I was wondering that the driver would basically allow the data to be written in the shared memory space where the PRU would pick up the data Mar 05 14:45:44 chanakya_vc: right - the Linux kernel already has a standardized interface for I2C, SPI, etc., so you'd definitely want to follow that Mar 05 14:46:12 alexhiam, Like the shared memory would basically behave for example as an SPI data register? Mar 05 14:46:19 Abhishek_: +1... though does anyone read the channel topic? :| Mar 05 14:46:25 chanakya_vc: Yes, that shared memory interface is what you have to come up with. Mar 05 14:48:25 chanakya_vc: right. The driver would essentially be the same as the drivers for the built-in serial peripherals, but the interface that it's using needs to be implemented in the PRU using that shared mem like the other drivers use the peripherals' registers Mar 05 14:49:29 chanakya_vc: The idea is to do it in a very standard kind of way, so that other people can follow the pattern and build their own drivers. Mar 05 14:51:03 chanakya_vc: and now that there's an I2C slave interface spec in mainline, you'd want to follow that for the slave mode: https://www.kernel.org/doc/Documentation/i2c/slave-interface Mar 05 14:52:11 Abhishek_: have you looked much into mainlining PRU stuff? Mar 05 14:52:19 i.e. where would the PRU firmware go Mar 05 14:52:56 Not since a while. I need to release a new software image for BeagleLogic which I've been putting off for 2 weeks now. Mar 05 14:54:08 alexhiam, Abhishek_ So what I understand is that I would basically have to code the driver for PRU(for writing in shared mem) and while doing so follow the specs given for I2C slave in the mainline? Mar 05 14:54:53 The driver has to work alongside PRU remoteproc and be a "subsystem" driver. Mar 05 14:55:18 So it appears as a SPI device if it's a SPI driver Mar 05 14:55:56 i.e. /dev/spidevX.X Mar 05 14:56:34 yep Mar 05 14:56:44 alexhiam, Abhishek_ I donot have much experience with writing drivers.nerdboy and m_w were kind enough to give me a lot sources for the same.But I am confident that I can learn that before the official coding period. Mar 05 14:57:20 chanakya_vc: in other words, it should be written in a way that any existing software that uses SPI, I2C, etc. could use the PRU bit-banged interface without any changes at all Mar 05 14:57:37 chanakya_vc: You should focus your efforts at this stage to break up the problem into weekly sub-goals. Mar 05 14:58:11 chanakya_vc: and learn whatever you need to do this within the application period. Mar 05 14:58:42 chanakya_vc: yeah, those are all great links and a good place to start. Note that Derek Molloy has some great kernel dev info specific to the beaglebone black Mar 05 14:59:28 Okay the next question is that when you say a subsystem driver ,it will be basically a part of remoteproc? Mar 05 14:59:35 +1 - come up with a timeline that shows what the discrete steps of the project could be as soon as you can and post it on the mailing list Mar 05 15:00:22 Okay will do that in a couple of days. Mar 05 15:01:55 Currently i have been studying about SPI,I2C.And i found the problem regarding bitbanging in linux.Basically consumes a lot of valuable CPU cycles which is a problem in a non-interrupting OS like linux Mar 05 15:02:59 Software overheads. Mar 05 15:03:05 right - bitbanging an SPI or I2C device in Linux is pretty much always a bad idea. That's why the PRU would be doing it Mar 05 15:03:30 the PRU is an entirely separate core, so it has no effect on the Linux scheduler Mar 05 15:04:04 Yes so we either use an RTOS or offload to PRU Mar 05 15:04:24 In case of BBB that is. Mar 05 15:05:37 rtos? The motivation for this project is that there's two powerful PRUs sitting there, so why not use them to provide a couple more serial interfaces. It's not the case that the beaglebone is short in hardware serial peripherals Mar 05 15:06:30 an RTOS would be in place of GNU/Linux, and isn't really related here Mar 05 15:06:35 alexhiam, Yes that I was going for .Cannot use RTOS. :) Mar 05 15:07:00 Sorry for the confusion Mar 05 15:08:24 ok, you just meant in terms of when bitbanging is appropriate? Yeah, I guess an rtos could be helpful if you needed to bitbang an I2C interface, though you're still using a lot of CPU cycles, and an rtos is it's own can o' worms in a lot of ways Mar 05 15:08:55 but yeah, real-time is the key here Mar 05 15:15:33 Yes. So as Abhishek_ mentioned my focus right now should be to writing the timeline and posting to the ml.I am confident about writing the codes for bitbanging I2C and SPI(Although I would still have to see the PRU firmware) Mar 05 15:16:20 Would it be okay if I put this investigating period in the coding period? Mar 05 15:16:40 *investigating Drivers in linux Mar 05 15:17:47 yup. The timeline will help us to make sure you're on the right track, and will also help you figure out where you're missing pieces. Ideally you would have some experience already by the start of coding, e.g. at least building a hello. world driver and getting a LED blinking from the PRU Mar 05 15:18:39 gsoc goes by very quickly, so ideally coding should start pretty much right away Mar 05 15:19:38 Okay.Got it.And the project expects UART as well? Mar 05 15:20:20 I'd think I2C, SPI and UART would be achievable Mar 05 15:23:05 I have used PRU speak for blinking LED's and stuff and I performed an experiment in my lab in which i measured the difference of performance between the CPU and PRU,switching on and off a pin w/o delay and seeing the response on an oscilloscope Mar 05 15:23:52 great. Have you just used pruspeak, or have you use PRU assembly? Mar 05 15:24:24 I imagine the firmware will probably need to be done in assembly, or at least parts of it Mar 05 15:24:40 PRUspeak. Mar 05 15:24:57 That will be no problem.I have some idea about assembly Mar 05 15:25:40 a while back I put together some simple and fairly documented demos: https://github.com/alexanderhiam/PRU-stuffs Mar 05 15:25:56 haven't updated it to use remoteproc yet though Mar 05 15:29:17 Okay will go through that.One more thing ,basically when i write these drivers,they would be stream mainlined to linux.What i don't yet understand is how will the user invoke it?Like in PRUspeak,when we want to send commands we have to run run.sh? Mar 05 15:30:09 So I mean if the user decides that today he wants to use the PRU as an I2C slave,how would he do it? Mar 05 15:32:06 Like the driver is already a part of the but how would the user choose when to use it or when not to?I still don't get that.How do you invoke a driver? Mar 05 15:32:16 the standard nowadays would be to have a device tree block that loads the firmware Mar 05 15:32:19 *linux Mar 05 15:32:43 see Abhishek_'s beaglelogic device tree overlay: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts Mar 05 15:33:24 then modprobe to load the driver Mar 05 15:34:28 If you do a modprobe without loading the appropriate overlay, it's likely that the module would not start Mar 05 15:35:14 Abhishek_: does the overlay enable the driver? Mar 05 15:35:27 https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts#L204 Mar 05 15:35:31 it causes the module to be probed. Mar 05 15:35:57 nice. I really need to play more with remoteproc Mar 05 15:36:41 See: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/beaglelogic.c#L1241 Mar 05 15:37:05 and https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts#L209 ... Mar 05 15:37:19 and https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts#L16 . Mar 05 15:38:22 oh right, that's just a standard DT thing isn't it Mar 05 15:38:33 * alexhiam needs to do more kernel dev... Mar 05 15:39:12 yeah Mar 05 15:40:37 Abhishek_: maybe you have some example code to mcspi? Mar 05 15:40:45 So as i understand it,for every driver an Overlay is required?In my case,my driver would just provide a window to write to the shared memory space and tell the PRU to use a certain section of its firmware? Mar 05 15:41:24 So I don't get how an overlay fits into this picture? Mar 05 15:45:16 So,if today the user decides to use SPI,he would first load the Overlay for the SPI driver and then proceed to modprobe the required the driver for SPI.And then my driver would open a terminal for writing to the shared mem? Mar 05 15:46:19 pmezydlo: For the PRUs? Mar 05 15:46:58 no, I mean lkm driver. Mar 05 15:47:24 isn't it already there in the kernel tree? Mar 05 15:48:01 chanakya_vc: clarifying the terminology, a DT overlay serves to _instantiate_ device(s) including parameters....not a driver. Mar 05 15:48:48 including the required pinmuxing Mar 05 15:48:50 chanakya_vc: once a device is instantiated then a matching driver is bound Mar 05 15:49:23 Abhishek_: yeah, but i wanted something easier, Mar 05 15:49:59 pmezydlo: You'll have to explore this yourself. Mar 05 15:50:34 chanakya_vc: can you describe what you mean by a terminal? Mar 05 15:51:51 Abhishek_: do you happen to know which mentor is dealing with it? Mar 05 15:52:13 \mdp Mar 05 15:52:17 *bradfa? Mar 05 15:52:46 the flash emulator? yeah, that's bradfa Mar 05 15:54:42 ok thanks for reply, i already talked to him. im just trying to find as much information as possible. Mar 05 15:58:45 alexhiam, What I was going for is something like when in PRUspeak you run 'run.sh'which i think loads the kernel module and the required overlay.Then it has possibility of three terminals. Mar 05 16:00:00 ok. Terminal isn't really the right word here. What will get exposed to userland is a device file Mar 05 16:00:05 e.g. https://www.kernel.org/doc/Documentation/i2c/dev-interface Mar 05 16:00:29 alexhiam, But I guess my job is just to write the driver and not the interface in the userland ? Mar 05 16:00:39 that implements both the data transfer as well as the ioctls Mar 05 16:00:46 that's part of the driver Mar 05 16:01:43 that interface is an interface to the driver, which in this case then passes information/data to and from the PRU via the shared memory Mar 05 16:02:15 so essentially what the driver does is provide an interface between userspace and the firmware Mar 05 16:02:16 chanakya_vc: If you implement a standard I2C driver, then userland won't know the difference between a I2C-through-PRU or a real hardware I2C. Mar 05 16:02:47 that's the point, instead of defining your custom driver, use a standard subsystem driver that communicates over the PRU. Mar 05 16:03:22 when loaded it'll just get assigned the nex /dev/i2cX interface number and act like any I2C device file Mar 05 16:05:44 chanakya_vc: have you used I2C or SPI in Linux before? Mar 05 16:05:55 okay.So basically the drivers job would be to essentially allow the PRU to be listed as a I2C evice and assign it the interface number? Mar 05 16:06:08 it's also important to have a good understanding of those interfaces Mar 05 16:06:12 yeah Mar 05 16:07:05 make sure you read and fully grok https://www.kernel.org/doc/Documentation/i2c/dev-interface and https://www.kernel.org/doc/Documentation/spi/spidev Mar 05 16:08:03 and read up on ioctl if you don't know it Mar 05 16:08:45 And the preexisting interfaces in Linux for SPI and I2C would basically see the PRU as I2C slave device? And you would just use as you would normally use any I2C slave device. Mar 05 16:10:52 alexhiam, Abhishek_,I will read up on all you have given me.Will get back to you as soon as I can. And simultaneously start working on the timeline. Mar 05 16:11:07 sounds good Mar 05 16:11:28 alexhiam, Abhishek_|afk Thanks.You have been most helpful :) Mar 05 17:40:30 carpediem_: check out nishant mennons github repo, he has some beta work there for android x15. try talking to him on #beagle (not sure if he is there), or you could find him on the beagle mailing list Mar 05 17:41:04 anybody else get "100 years of Robert Johnson"? Mar 05 17:41:17 yes, I have looked at the repo Mar 05 17:41:34 It has the AOSP part, the linux kernel is missing Mar 05 17:41:47 that needs to compiled and built Mar 05 17:41:57 yeah but thats the standard part Mar 05 17:43:00 ok Mar 05 17:43:56 if you are really looking into doing something along the lines of this, you should get in touch with hendersa (the guy behind BBBAndroid) as well as Nishant. Try sending them an email with your thoughts on the same. Previous GSoCs have almost always had students finding 'outside' mentors and asking them to come here on #beagle-gsoc and the mailing list. Mar 05 17:50:11 I got in touch with hendersa :) Mar 05 17:51:14 cool. I will keep working . Will soon update you guys. Mar 05 17:51:55 try nishant too. I have been in touch with hendersa too, but he's skeptical that the work required can be done in one gsoc. So to get his vote of confidence you will have to put some work into the application :) Mar 05 17:53:42 ok Mar 05 17:56:07 a lot of stuff is doable in one gsoc if someone is actually motivated... Mar 05 17:56:23 Amen Mar 05 17:57:57 2 important points being 1) get off your ass, and 2) try it and see Mar 06 01:07:30 ! Greetings everyone ! Mar 06 02:14:31 Hey m_w ! Mar 06 02:51:54 Abhishek_: sorry for the lllaattee reply :P, should we get started on something? **** ENDING LOGGING AT Sun Mar 06 02:59:57 2016