**** BEGIN LOGGING AT Fri Apr 08 02:59:58 2016 Apr 08 06:28:33 raspberry Apr 08 06:28:53 oops. wrong textbox in focus :P Apr 08 06:29:02 :) Apr 08 06:43:28 ahh 4.1.18-ti-r55 and 4.1.18-ti-rt-r55 would have the same source code .. isnt it ? Just the compilation configuration is different . Am I right ? Apr 08 06:45:44 Though that depends on how 'rt' version in obtained ... using a PREEMPT_RT patch or the other approaches. Not aware of what is used for BB tree at github. Apr 08 06:46:09 Abhishek_: ^^ Apr 08 06:48:41 also, I don't know how other approaches work .. Apr 08 06:55:49 ZeekHuge: I don't think you need to deal with rt kernel for now, so stick with the normal one Apr 08 06:57:05 yeah .. I want to, but I am unable to find a tag for '4.1.18-ti-r55' in the tree. They have '4.1.18-ti-rt-r55' tag but not the non-rt one. Apr 08 06:58:48 what abour r54? Apr 08 07:00:32 no ... straight from 4.1.13-ti-rt-39 to 4.4.6-ti-rt-14 , all are rt. there is no non-rt version. Apr 08 07:00:45 hmm, link? Apr 08 07:01:53 ahh ... the main tree here https://github.com/beagleboard/linux ... in that above Branch/tag button ? Apr 08 07:07:13 Abhishek_: isnt that the place I should look for "what exists in stable state" sources ? Apr 08 07:07:34 ZeekHuge: it's the place where kernels for the BeagleBone images exist Apr 08 07:08:43 the pre-compiled images . Ohk got it. So I have 4.1.18-ti-r55 kernel running on my BBB. But the code is not there. Apr 08 07:10:10 Abhishek_: there it is : http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots Apr 08 07:10:31 4.1.18-ti-r56 Apr 08 08:09:02 haha ! got it working ! http://paste.debian.net/426768/ Apr 08 08:25:18 this is my /proc/iomem .. http://paste.debian.net/426780/ .. So L42 to L54 are PRUSS subsystems Apr 08 08:26:31 but how does the OS knows that ? I didnt loaded any dto. Whats the main dts file for BBB ? Apr 08 08:26:47 *I didnt load Apr 08 08:29:02 look at the boot DTS first Apr 08 08:29:24 is it the one https://github.com/RobertCNelson/ti-linux-kernel/blob/v4.1.18/arch/arm/boot/dts/am33xx.dtsi ? Apr 08 08:34:51 yup, explore around those files a bit Apr 08 08:39:38 oh ! I was looking in rcnee's github. Thats the wrong place I think (still confused about the various trees). Anyway I found it . Apr 08 08:39:41 here it is https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am33xx.dtsi#L854 Apr 08 08:40:39 so no need for this dts - https://github.com/ZeekHuge/PRU-framework/blob/master/dts/BB-PRU-FRAMEWORK-00A0.dts Apr 08 09:04:11 pruss_remoteproc used to expose sysfs entries like /sys/devices/ocp.3/4a300000.pruss/memtype , ./offset and ./datafile . But the rproc driver dose not seem to expose sysfs entries. It probably only exports some in-kern symbol ... Apr 08 09:04:33 trying to understand this commit : https://github.com/beagleboard/linux/commit/3bc4dfbdca01291167d3039339f7df37ec7ebfa3 Apr 08 09:04:39 any help on that ? Apr 08 10:21:46 Abhishek_: seriously need some help here.. Apr 08 10:22:21 why haven't they defined the _init and _exit function here https://github.com/beagleboard/linux/blob/4.1/drivers/remoteproc/pru_rproc.c ? Apr 08 10:23:59 That is why reloaded the module produces loads of error. And if in any case, it dosen't produce errors, it makes no difference. It was like never removed and loaded back .. Apr 08 10:25:47 and they seriously haven't exposed any sysfs entry. The only way to load a new fw to the pru is to reboot the device, nothing else would work. Apr 08 10:38:20 Abhishek_: should I raise this as an issue ? Apr 08 14:32:31 bradfa, I have updated the google doc and also enabled sharing.Please check and let me know what you think of it. Apr 08 14:33:07 chanakya_vc: ok, thanks! I read through your submitted PDF last night, I'll check the google doc to see what you've changed :) Apr 08 14:34:48 bradfa, I have not really changed much.You could perhaps comment on it and let me know if you would want me to change anything? Apr 08 14:35:35 bradfa,I just modified certain bits which I thought were not making sense in my proposal Apr 08 14:36:01 chanakya_vc: ok, I'll read it over and comment Apr 08 14:36:19 bradfa, Thanks a lot!! Apr 08 14:37:03 :) Apr 08 16:05:07 bradfa : can I go on and add something to the pru_rproc (https://github.com/beagleboard/linux/blob/4.1/drivers/remoteproc/pru_rproc.c) and then send a pull request ? I mean .. do you think that would be accepted ? Apr 08 16:07:52 actually the driver isn't complete, and they are probably working on it. So should i wait for them to complete it ? or try to help in the process ? Apr 08 17:19:37 ZeekHuge: I'm not sure I understand your question. But why would you not want to work on an upstreamable version? Apr 08 17:24:34 ZeekHuge: and why are the addresses of the various PRU given with fixed values in that pru_rproc.c file, shouldn't info like that go into device tree nodes? Apr 08 17:25:27 and like the firmware file name, I would expect that to be a device tree param, too, no? since every borad will have different pru fw that they'd want to load for different reasons. But maybe I'm not understanding the goals. Apr 08 17:37:23 ah, the firmware name is in dt Apr 08 17:39:29 ZeekHuge: why is the pru remoteproc code not upstream? Apr 08 17:39:50 ahh .. Apr 08 17:40:06 upstream = linus tree ? Apr 08 17:41:57 "The driver is not upstream yet, and I haven't submitted because of the churn and architecture changes it is going through to support various usecases for the TI Processor SDK releases" Apr 08 17:42:06 bradfa: ^^ this is what suman Apr 08 17:42:10 sa Apr 08 17:42:18 *Suman Anna said Apr 08 17:42:34 ZeekHuge: ah, ok Apr 08 17:42:56 ZeekHuge: would be nice to stop the internal to TI churn and get something useful upstream :) Apr 08 17:43:25 bradfa: yeah .. but why are we so much dependent on TI ? Apr 08 17:43:50 ZeekHuge: you ask a very valid question :) Apr 08 17:43:56 I mean .. why cant we use their code and ourself arrange it and then put it for upstream. Apr 08 17:44:05 ZeekHuge: that's definitely possible Apr 08 17:44:41 That is one reason why I was asking about that "add changes to the tree" question. Apr 08 17:45:39 And other reasons were.. basically i got confused . I was trying to understand the code and .. ahh well . Its comparatively clear now. Apr 08 17:56:34 ZeekHuge: if you wanted to send the existing TI code upstream, I suggest you talk more with Suman first, as TI has the copyright on that code you linked to Apr 08 17:56:52 ZeekHuge: no need to do a bunch of work if TI is going to send it up stream real soon now Apr 08 17:57:28 ZeekHuge: but if they aren't going to, then it might be worth taking the existing code and fixing it up somewhat and then trying to send it upstream, at the very least it may goad TI into doing what they want faster :) Apr 08 17:58:47 or send out your mods as a RFC pathto the list Apr 08 18:20:58 TI's open source fu is not very high... Apr 08 18:21:11 barely at the grasshopper level Apr 08 18:36:57 bradfa: Well, My project depends on pru_remoteproc. So, I just wanted it to be streamlined before the project starts (if its accepted, though I would anyway want to do that). Apr 08 18:37:18 And I am not sure what all need to be done to get it mainlined. Apr 08 18:39:37 What are the 'requirements' for a kernel module to be mainlined ? Apr 08 18:56:31 bradfa: nerdboy m_w ds2 ^^^ Apr 08 18:57:24 well firstly it must conform to the kernel coding style Apr 08 18:57:37 https://www.kernel.org/doc/Documentation/CodingStyle Apr 08 19:01:19 m_w: yep .. ohk. I have read it once as I promised ;) Apr 08 19:01:23 the next step is finding the appropriate subsystem that the driver belongs to Apr 08 19:01:42 yeah .. ohk my question seems to be really broad. Apr 08 19:02:36 we'll have to move in steps I think. Apr 08 19:04:08 here is a nice beginner guide Apr 08 19:04:11 http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel Apr 08 19:04:32 Ohk .. I'll start taking to Suman Anna about it. And .. ahh my exams will start from 26th of this month and will go on till 17th. I'll try to manage all this together. Apr 08 19:05:23 okay Apr 08 19:05:45 keep me in the loop as I may be able to help out Apr 08 19:06:05 m_w: Sure :) Apr 08 19:07:14 * ZeekHuge will be going to bed now. Has to wakeup in 4 hours for .... something .. Apr 08 19:13:42 https://kernel.org/doc/Documentation/HOWTO Apr 08 19:16:21 http://www.linuxfoundation.org/content/how-participate-linux-community-0 Apr 08 21:02:48 hi there m_w Apr 08 21:03:02 it was most excellent to hangout at ELC Apr 08 21:03:49 we wish we could have done #opticalexperiments with av500 Apr 08 21:10:20 that would have been nice Apr 08 21:10:37 there is always another conference Apr 08 21:11:36 maybe trollcon Apr 08 21:14:27 oh man! looks like trollcon is already a thing :( Apr 08 21:14:32 https://www.trolllord.com/cons/trollcon.html Apr 08 21:15:27 http://trollcon.de/ Apr 08 21:19:43 hehe :) Apr 08 21:20:12 isn't that the land of av500 ? Apr 08 21:20:54 not sure Apr 08 21:45:18 m_w: i saw your email about the mentor list. i didn't realize you had talked to jonathan cameron about the project. that's great. Apr 08 21:49:57 yup he follows my G+ Apr 08 21:51:27 after seeing my post about beagle gsoc ideas he got sucked in Apr 08 21:51:56 someone we need to add to the mentors list? Apr 08 21:52:24 he is the creator of linux-iio Apr 08 21:52:33 well done m_w Apr 08 21:52:48 he told me that he won't have the bandwidth to be a full mentor Apr 08 21:52:50 is he getting involved in mentoring? Apr 08 21:52:51 k. Apr 08 21:52:54 jic23 Apr 08 21:53:13 join the mailing list and lurking in here? Apr 08 21:53:43 yeah he was helping out a lot for a while Apr 08 21:54:04 he really helped define the beaglescope project Apr 08 21:57:36 if we mainline any IIO stuff he won't have a choice in helping ;) Apr 08 22:01:07 nice Apr 08 22:02:24 have you worked up the specs for the poo-board? Apr 08 22:06:01 looks like the lichen pub adapter already exists for the minnow Apr 08 22:06:03 https://plus.google.com/101339419642360856354/posts/UakT1difkhR Apr 08 22:22:23 hehe, i will have to think about poo-board specs ;) Apr 08 22:23:09 i wonder if breadboard adapter would be useful for beaglebone? I've always used this adafruit proto plate: https://www.adafruit.com/products/702 Apr 08 22:33:06 the beagle uses .1 inch female headers so it is not as important because you can jumper wire straight into the connectors Apr 08 22:35:22 jumpers are annoying Apr 08 22:35:53 I suppose that is true Apr 08 22:36:19 so maybe it would be useful Apr 08 22:36:26 pcbs are so easy, just make one Apr 08 22:36:35 simulate, test, verify then make it Apr 08 22:37:04 it was jumpers that was responsible for my only dead Beagle Apr 08 22:38:17 perhaps the lichen pub adapter adapter would for the beagle would be useful Apr 08 22:39:51 I personally hardly ever use breadboards Apr 08 22:40:14 breadboards as in the plug in stuff? Apr 08 22:40:43 or the perfboards with copper rings? Apr 08 22:41:05 the plug in ones Apr 08 22:41:18 those are great for short run mfg test jigs Apr 08 22:41:42 cheaper then building bed of nail fixtures Apr 08 22:42:46 how would it work? Apr 08 22:43:07 it handles the connecting the DUT Apr 08 22:43:26 this is for small boards Apr 08 22:43:38 ah Apr 08 22:45:24 assuming that is will plug in Apr 08 22:45:35 *nod* Apr 08 22:46:05 had to build like 20 little atmel microcontroller sensor boards Apr 08 22:46:28 the breadboard was the jig to test and program them Apr 08 22:46:37 cool Apr 08 22:46:58 got away with using their dev board as a programmer (jumper to a bread board) **** ENDING LOGGING AT Sat Apr 09 02:59:58 2016