**** BEGIN LOGGING AT Thu Mar 03 02:59:58 2016 Mar 03 03:00:07 yup Mar 03 03:01:15 well, then for the above example, we are not using any header pin, why do we need it then ? Mar 03 03:01:52 booting and initialization of clocks is the work of the driver ? is it ? Mar 03 03:02:19 because it tells where the pru is mapped Mar 03 03:03:33 ohk so why cant we hardcorde that into the driver ? the pruss driver is a dedicated one, so that shouldnt be a problem. Mar 03 03:04:35 the probe will never be called without a devicetree entry Mar 03 03:08:59 https://gist.github.com/abhishek-kakkar/63c8cf007c892bf7e476 **** BEGIN LOGGING AT Thu Mar 03 05:30:09 2016 Mar 03 05:40:28 650 W. Olive Ave. Mar 03 05:51:03 hello Mar 03 05:52:41 what are some most useful projects for the organisation Mar 03 05:52:42 ? Mar 03 06:07:08 is anyone there? Mar 03 06:08:16 you should see the ideas page, you will find the answer of your question there. Mar 03 06:09:31 blah Mar 03 06:10:03 basher: what are you skills? Mar 03 06:11:56 I know java and c++ from my basic course Mar 03 06:12:10 Well a little bit of android too Mar 03 06:28:05 9 Mar 03 06:28:19 hmm Mar 03 08:15:15 hi Mar 03 08:15:35 do you have somebody who already knows that he might be the mentor for the low=latency multi-channel audio system stuff? Mar 03 10:26:02 Hi!! Mar 03 10:26:15 can anyone send me the latest def_config file for beaglebone black? Mar 03 10:58:08 Hey ! I think there some problem with dtc. I tried reinstalling it on my BBB, but it says: Mar 03 10:58:09 -bash: /usr/local/bin/dtc: cannot execute binary file: Exec format error Mar 03 10:59:08 uname -a is : Linux beaglebone 4.1.17-ti-rt-r48 #1 SMP PREEMPT RT Fri Feb 12 23:46:00 UTC 2016 armv7l GNU/Linux Mar 03 12:28:37 Hi Mar 03 12:28:50 I am interested in doing GSOC under Beaglebone Mar 03 12:29:52 I have created the pull request for Cross Compiling Beaglebone as required Mar 03 12:30:38 What should I do next? Mar 03 12:51:31 hey Abhishek_, i am trying to get the PRU-framework work on my BBB Mar 03 12:51:57 its uname -a is Linux beaglebone 4.1.17-ti-rt-r48 #1 SMP PREEMPT RT Fri Feb 12 23:46:00 UTC 2016 armv7l GNU/Linux Mar 03 12:53:42 and the dmesg shows this http://paste.debian.net/411354/ Mar 03 12:54:35 acc to this gists of the project, there definitely something wrong. but what ? Mar 03 12:55:56 is it the already present /bus/platform/devices/480c8000.mailbox thats causing the pru to be released ? Mar 03 13:27:13 ZeekHuge: You should use 3.14 to compile the last year's GSoC project Mar 03 13:55:33 Abhishek_: Can you give me the def_config file for beaglebone black in 4.1 kernel? Mar 03 13:55:53 isn't it already there in the kernel sources? Mar 03 13:57:33 Abhishek_: is it https://github.com/beagleboard/linux/blob/4.1/arch/arm/configs/bb.org_defconfig ? Mar 03 13:57:45 kiran4399: correct Mar 03 14:01:42 Abhishek_, ahh alexhiam told me that it would also run on the latest jessie image. Mar 03 14:01:51 is there a way we can fix it ? Mar 03 14:02:10 well, that could be a project Mar 03 14:02:45 bradfa: just thinking out loud here... what if the flash emulator project were done in a general enough way that it could be used to simulate other devices besides memory? e.g. that BGA sensor you're thinking about using but don't want to deal with hand soldering up a prototype quite yet Mar 03 14:03:29 bradfa: and if someone does an I2C slave for the PRU then that could be used to simulate I2C devices as well Mar 03 14:03:43 alexhiam: there's already a generic I2C slave ability in mainline linux Mar 03 14:03:53 you just write a protocol-like driver, iirc Mar 03 14:04:10 ohk so it will strictly need 3.18. thank you Abhishek_ Mar 03 14:04:29 haven't tried, but seems like there'd be some timing issues Mar 03 14:04:37 alexhiam: emulating a spi flash I think will easily consume an entire GSoC Mar 03 14:05:02 sure, I just mean trying to do it in a modular way from the get go so it could be extended Mar 03 14:05:20 alexhiam: yeah, the modular bit will be trying again to get a generic SPI slave framework into linux Mar 03 14:05:35 I'm trying to think how it could be generalized more to be more beneficial to the beagleboard community at large Mar 03 14:05:51 I feel like just emulating SPI flash is a bit on the niche side Mar 03 14:06:16 alexhiam: it depends, it's niche but is very common in developing actual embedded systems Mar 03 14:06:56 right. It may just be that I've never needed one so it's not that exciting to me yet :P Mar 03 14:06:57 alexhiam: for example, on minnowmax u-boot goes into a SPI flash, so developing u-boot for E38xx can be much less painful using an emulator (yes, I know, not a TI part but still an example) Mar 03 14:07:34 ah, that's a good example use case Mar 03 14:07:46 alexhiam: likely my next work project will be using SPI flash as the main NVM, likely a 512 Mb part, so programming that using existing tools like flashrom and spi hook or SF100 will take forever Mar 03 14:08:14 right Mar 03 14:08:14 setting aside 64 MB of RAM in a BBB to emulate such a flash is no problem at all to do and programming it via USB should only take a few seconds Mar 03 14:09:05 whether flashrom can be adapted to work well with an emulator is not clear to me, but it would be a decent platform to start using for the "host programmer" side of the SPI flash emulator Mar 03 14:09:44 there'd be some out of band way to tell the emulator what kind of spi flash it should emulate, ie part number and loading of status register details, likely that would be outside of flashrom's perview Mar 03 14:10:48 bradfa: alexhiam: keeping the scope in limit is important Mar 03 14:10:53 the actual hardware to enable actually emulating a spi flash should be separate from gsoc Mar 03 14:10:56 so go for SPI first and generic later Mar 03 14:11:22 av500: yes, agreed Mar 03 14:11:23 av500: for sure Mar 03 14:12:04 bradfa: so use the AM35x SPI to talk to the fake PRU SPI? Mar 03 14:12:14 all you need are 3 jumper wires Mar 03 14:12:18 er, 4 Mar 03 14:12:53 av500: yes, but likely PRU is not the right choice Mar 03 14:13:01 ? Mar 03 14:13:17 bitbang? Mar 03 14:13:21 on GPIO? Mar 03 14:13:22 av500: PRU does not seem to have hardware enablement to output bits from its internal shift register based on an external clock Mar 03 14:13:36 av500: and bitbanging likely can't go much faster than the McSPI in slave mode Mar 03 14:13:47 adding complexity of PRU doesn't seem to be worth it right now to me Mar 03 14:13:48 hmm Mar 03 14:13:54 I thought it was PRU Mar 03 14:13:55 av500: but I could be convinced otherwise Mar 03 14:14:00 so its just SPI in slave mode? Mar 03 14:14:12 4 wires and 4 lines of DT? Mar 03 14:14:12 av500: it started out PRU, then I did some reading and it seemed not really to be the best fit as I understood it Mar 03 14:14:21 so just mcSPI controlled from kernel space? Mar 03 14:14:33 av500: and then generic spi slave driver code along with a protocol driver to emulate spi flash Mar 03 14:14:41 ah Mar 03 14:15:04 the upstreamable part is the generic framework, trying that again, and then an example protocol driver which could also be upstramed Mar 03 14:15:05 well, if a SPI slave driver gets mainlined through this that's a win right there Mar 03 14:15:29 alexhiam: odds are unlikely to be good that it would actually get upstreamed on the first or second try, but yes :) Mar 03 14:15:43 of course Mar 03 14:15:59 bradfa: ok understood Mar 03 14:16:02 it could at least get upstreamed to beagle/linux :P Mar 03 14:16:31 I assume there's existing spi slave frameworks to start from, then take the criticisms and fix those, and then enable for spi flash emulation, and write example protocol driver Mar 03 14:17:21 with a student who is committed, I think this could fit into a GSoC and have a good result Mar 03 14:17:38 whether it's really the best fit for beagleboard.org's gsoc could easily be debated Mar 03 14:17:53 * bradfa just really likes spi flash for some strange reason :) Mar 03 14:18:34 bradfa: next year we can add a project to swap to SPI RAM: ) Mar 03 14:18:42 whats the latest image with kernel 3.14 ? need to run the PRU-framework . Have been trying it on 4.1.17-ti-rt-r48 , but came to know that it not meant for only kernel 3.14. Mar 03 14:18:56 *that its meant Mar 03 14:19:17 ZeekHuge: it should be easily adaptable if it doesn't already run on 4.1 Mar 03 14:19:33 3.14 images shouldn't really be used for anything.. Mar 03 14:19:59 Abhishek_ said that porting it to 4.1 could be a project in itself Mar 03 14:20:23 av500: definitely, SPI SRAM is the best SRAM :) Mar 03 14:20:46 ZeekHuge: ugh.. in that case I'd say just pull the remoteproc code out of beaglelogic or something Mar 03 14:21:26 ohk :) Mar 03 14:21:46 Abhishek_: has that much really changed between 3.14 and 4.1 that remoteproc drivers need lots of work to port?! Mar 03 14:22:24 how'd we let them use 3.14 for that project last year :( Mar 03 14:35:47 alexhiam: shubhangi made an attempt to get it running on 4.x, I should have that somewhere. Mar 03 14:37:30 hello everyone Mar 03 14:37:40 alexhiam Mar 03 14:38:19 alexhiam : sir i have throughly googled the net to somehoe connect two usb cameras on the same usb port Mar 03 14:39:12 and either we can use external hardware circuitary to switch between the two multiplexed lines of webcam Mar 03 14:39:25 kartik: ...usb hub? Mar 03 14:39:50 yes sir. but probably there is going to be bandwidth issues Mar 03 14:40:31 and sir about the pru idea i mentioned. here is a link related to it https://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/08/18/bbb--imaging-with-a-pru-connected-camera Mar 03 14:42:17 the bandwidth might be an issue at hd resolutions, but I suspect the shared memory will be the bottleneck anyways Mar 03 14:42:29 usb 2 is pretty fast Mar 03 14:42:42 its 2 fast Mar 03 14:44:57 then i will try for that at much lesser resolution. it will take me few days to get the necessary hardware so will take some time for implementation Mar 03 15:03:04 hi jkridner Mar 03 15:03:12 howdy! Mar 03 15:04:15 i am very much interested in both the projects. one for optical flow processing and the other for stereo imaging. cant decide which one will be better to submit as a potential gsoc project which can be useful llater for others. Mar 03 15:06:25 Do you have the sensors with you? Have you ever used them? Mar 03 15:08:36 yes sir. i have used my hd c270 hd camera before a lot for image processing with opencv. but have never mounted two cameras and calibrated them for stereo imaging. Mar 03 15:09:18 like I said once before, no need to call anyone "sir" here. Mar 03 15:09:40 have you tried two cameras on your PC? Mar 03 15:10:06 no. not yet. Mar 03 15:11:02 what about the optical flow sensors? Mar 03 15:15:05 that too using my webcam. by opencv opticalflowpy library function and later feature detection Mar 03 15:17:53 There are special optical flow sensors available for autopilots that are much faster. Mar 03 15:18:14 right. but have never used them Mar 03 15:21:07 should i buy the hardware and start implementing on the pixhawk hexacopter i have using ardupilot Mar 03 15:27:02 those are very expensive here in india. Mar 03 15:30:31 jkridner , av500 : can you add me as a mentor in the gsoc page Mar 03 15:30:44 I can't even seem to log in properly Mar 03 15:31:00 karki_: have you chatted with wmat on the #elinux channel? Mar 03 15:31:15 no Mar 03 15:31:24 What for exactly ? Mar 03 15:31:48 I meant the google page Mar 03 15:31:52 not elinux page Mar 03 15:32:05 I've added myself on elinux ideas page Mar 03 15:35:31 ah. ok, I'll send an invite. Mar 03 15:36:08 Sry i got logged off Mar 03 15:43:13 Abhishek: right now i would not be able get hands on an optical sensors but can start implementation on stereo image processing Mar 03 16:37:36 hi Mar 03 17:08:21 alexhiam: I added the mpu9150 source code and am editing the Makefile.... Mar 03 17:08:41 alexhiam: BTW.. I am using the default bb.org defconfig file from 4.1... Mar 03 17:08:46 kiran4399: where's the driver from? Mar 03 17:09:08 and can you push to a clone of beagleboard/linux on github? Mar 03 17:09:12 alexhiam: well.. victor wrote it for beaglebone black.. Mar 03 17:09:36 ok, I saw that one Mar 03 17:10:39 so I think the first step would be to make a patch for that against beagleboard/linux Mar 03 17:10:54 alexhiam: https://github.com/kiran4399/linux/tree/bb_blue/drivers/iio/imu/inv_mpu6050 Mar 03 17:10:55 once it's tested and working of course Mar 03 17:12:17 alexhiam: sorry... Mar 03 17:12:24 alexhiam: wrong link posted.. Mar 03 17:12:28 alexhiam: https://github.com/kiran4399/linux/tree/bb_blue/drivers/iio/imu/inv_mpu9150 Mar 03 17:14:00 oh ok, so victor didn't write then Mar 03 17:14:49 alexhiam: no...no.. victor did not write the driver... he wrote an application for ros which consisted of this driver.. Mar 03 17:15:28 hmm, seems like the repo it came from is gone Mar 03 17:15:34 https://github.com/Pansenti/linux-mpu9150 Mar 03 17:16:14 alexhiam: yeah.. Mar 03 17:17:51 hmm, the 9150 is not recommended for new designs... I wonder if they're using the 9250 on the blue... Mar 03 17:18:44 I have successfully used the mpu6050 driver in linux-next with the mpu9250 Mar 03 17:18:50 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/iio/imu/inv_mpu6050 Mar 03 17:19:09 good to know Mar 03 17:19:17 is the register map identical? Mar 03 17:19:25 for calibration and everything Mar 03 17:19:35 not quite Mar 03 17:19:48 but for the most part it is Mar 03 17:20:15 perhaps a better starting point for a new driver Mar 03 17:20:34 it is Mar 03 17:20:37 https://plus.google.com/+MichaelWelling79/posts/PdmGysBfZp4 Mar 03 17:21:08 with a few modifications it should be good Mar 03 17:21:29 awesome Mar 03 17:22:11 alexhiam: are you sure that they are using mpu 9250 on bb blue? Mar 03 17:22:30 kiran4399: no, but if I was designing it I certainly would... Mar 03 17:23:07 so what shall I build the kernel with? Mar 03 17:23:16 9250 or 9150? Mar 03 17:23:49 how about both? :) Mar 03 17:23:57 ok.. Mar 03 17:24:21 well, you can make sure it builds with that 9150 driver for now. jkridner may know what part they're using, when he's online next Mar 03 17:24:52 but the 9150 doesn't seem to be stocked anywhere, clearly moving towards end of life Mar 03 17:25:08 alexhiam: 9150 is on the strawson robotics cape.. Mar 03 17:25:32 right, but that was probably made before invensense started phasing it out Mar 03 17:25:42 m_w: the link which you posted... it is the mpu6050 right?? where is 9250? Mar 03 17:26:03 switching to the 9250 would be a logical update Mar 03 17:26:39 I used the 6050 driver without any changes on the 9250 Mar 03 17:27:31 kiran4399: considering that, if it is the 9250 on the blue I'd lean towards starting with the 6050 driver, which is already in mainline, and developing a 9250 driver from that Mar 03 17:28:59 who is designing the blue? Mar 03 17:31:16 Hi, is the idea of Common bootloader for different all the BeagleBone/BeagleBoards still valid for this year's GSOC? Mar 03 17:31:20 I assume circuitco Mar 03 17:32:44 or maybe UCSD Mar 03 17:34:31 and what about "Cross Platform USB Boot for Windows"? Mar 03 17:37:19 carpediem_: the first was ds2's idea, the second vvu. Not sure if either are online right now, but they're probably the ones to ask about those Mar 03 17:37:48 ? Mar 03 17:38:14 alexhiam: I am little confused what to add in the root Makefile.. Mar 03 17:38:23 what's the question, carpediem_? Mar 03 17:40:20 Are these ideas feasible for this year's GSOC or they have been completed? Mar 03 17:41:18 alexhiam: BTW.. what is this armv7a-vfp-neon-poky-linux-gnueabi? Mar 03 17:41:47 kiran4399: don't change the root makefile, just run make menuconfig to enable the driver Mar 03 17:42:18 sounds like a yocto cross compiler... Mar 03 17:45:50 kiran4399: you want to be using gcc-arm-linux-gnueabi Mar 03 17:48:29 alexhiam: but it is using yocto cross compiler right? Mar 03 17:52:35 kiran4399: no, beagleboard.org's images aren't built with yocto Mar 03 17:54:33 OK.. Mar 03 17:54:40 you want arm-linux-gnueabi-* Mar 03 17:55:17 e.g. 'make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- bb.org_defconfig' Mar 03 17:58:02 alexhiam: one more thing.. Mar 03 17:59:40 alexhiam: what is the glue directory? Mar 03 17:59:54 alexhiam: what is its use? Mar 03 18:01:34 looks like it's just some util functions used in the example programs Mar 03 18:03:32 * alexhiam goes afk for lunch... Mar 03 19:59:17 isn't there also a arm-linux-gnueabihf version? Mar 03 20:07:20 Hey, is there a project which simplifies the development process on a Beaglebone? Simplification, as in, as simple as development on Arduino? Mar 03 20:09:43 yoct/oe plus toaster/hob? Mar 03 20:10:16 carpediem_: bonescript and pybbio come to mind Mar 03 20:10:20 Or we could have a project? Mar 03 20:10:40 yeah, but still it is not as simple Mar 03 20:11:11 well, it's a much more complex system... Mar 03 20:11:13 Bonescript definitely provides a good deal of abstraction Mar 03 20:12:11 Please correct me if I am thinking in the wrong direction, but would it be possible to develop an IDE, abstracting the cross-compilation and linux layer? Mar 03 20:12:29 already has cloud9 Mar 03 20:15:05 carpediem_: there used to be Userspace Arduino too. to run Arduino code as is on the Black, hasnt been maintained for quite some time though :/ Mar 03 20:15:14 yeah Mar 03 20:15:17 I looked it up Mar 03 20:15:29 You built that for your GSOC :) Mar 03 20:15:52 with prpplague and hatguy :D Mar 03 20:16:32 theres loads to do in that too, especially now that x15 is almost here. Plus Arduino guys were working on it too, for Tre (or so I heard) Mar 03 20:16:51 Improving the existing Userspace Arduino and Bonescript libraries is also a potential project Mar 03 20:17:05 * anujdeshpande wonders if there will be interest for Android on BBB this year too ! Mar 03 20:17:14 But I am not very clear on what you guys expect out of that Mar 03 20:17:20 Android on X15 would be crazy good .. Mar 03 20:17:41 Is it just debugging and optimization or extension of the existing libraries? Mar 03 20:18:52 Well there are a lot more libs to add, more docs and example for the libs that are already there. Adding support for PRUs would be the number one task i think. adding support for displays, CAN. Mar 03 20:19:15 this is BBB+X15 specific. Mar 03 20:19:32 if you look at the hardware on the x15, then theres loads more I guess Mar 03 20:20:05 x15 is altogether different league :D Mar 03 20:20:31 true that Mar 03 20:21:08 what does the ideas page say ? x15 projects are a go right ? Mar 03 20:21:34 oh yees Mar 03 20:24:03 * anujdeshpande just asked hendersa to return as a mentor for BBBAndroid ! go x15 Mar 03 21:28:49 Hello, I am interested in the BeagleSat Integration Platform Mar 03 21:31:19 MalikTaylor45789: great. A good first step is to post on the beagleboard-gsoc google group introducing yourself, giving some details of what you'd like to do, and asking any questions you may have Mar 03 21:31:20 https://groups.google.com/forum/#!forum/beagleboard-gsoc Mar 03 21:45:22 did anyone invite marshall this year? Mar 03 22:46:04 does anybody know robert manzke? it seems he is not on irc Mar 03 22:46:15 wonder if I should just write him an email tomorrow Mar 03 22:47:15 sure, go ahead **** ENDING LOGGING AT Fri Mar 04 02:59:58 2016