**** BEGIN LOGGING AT Fri Mar 04 02:59:58 2016 Mar 04 06:19:27 Hi I interested to participate in GSOC 2016 Mar 04 06:19:46 I am pursuing Master degree in Embedded system in India Mar 04 06:20:20 I would like to work on project that is not listed on gsoc ideas page Mar 04 06:21:02 I am interested to develop SPI driver for Beagle bone black for Freebsd Mar 04 06:22:12 Can I take this project this year ? please give suggestions Mar 04 06:28:30 How do you go about doing it? Mar 04 06:34:50 I have read am335x TRM Mar 04 06:35:53 I have also gone through I2c subsystem of minix as well Mar 04 06:36:27 what about the freebsd subsystems ? Has SPI been implemented on other SoCs there? Mar 04 06:39:50 Sorry I have not checked it yet. But here https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack Mar 04 06:40:04 I have read it is yet to be implemented Mar 04 06:41:40 I can let you know whole proposal after reading freebsd subsystem related SPI and I2c Mar 04 06:43:07 you'd have to get a mentor from FreeBSD as well Mar 04 06:43:38 reach out to them and see if somebody would be interested to mentor you, only then would perhaps this proposal move forward? Mar 04 06:43:44 s/?/. Mar 04 06:44:01 I have mailed on mailing list but did not get any reply yet. Mar 04 06:45:17 I asked in mailinglist if someone ready to guide me then its okay . Mar 04 06:45:33 otherwise I can even manage with one mentor from here Mar 04 06:46:45 I'm not sure who'd be able to help you with FreeBSD here. Hang around here, when it's morning in the West coast more mentors would appear. Mar 04 06:47:24 Okay Thanks Abhishek Mar 04 06:48:20 Linux kernel support for embedded devices and interfaces Mar 04 06:48:34 I interested in this also Mar 04 06:48:54 But don't know what are the improvement I have to include in my proposal Mar 04 06:49:22 Would you please suggest if you have idea ? Mar 04 06:51:12 Ping ds2 or mdp when they are online. Mar 04 06:54:05 okay Thank you Mar 04 07:34:42 Hi,I never used Beagleboard or RaspberryPi.But I have basic knowledge in Digital Electronics,Python,C.Is there any chance to contribute to Beagle board? Mar 04 07:37:11 Why do you want to contribute to BeagleBoard? Mar 04 07:39:46 I have interest in Kernel development,PyBIBO Mar 04 07:40:57 have you ever compiled a kernel before? Mar 04 07:41:29 I did it for installing wifi driver in kali-linux Mar 04 07:42:21 I dont know Kernel hacking...but I want to start it now.... Mar 04 07:47:33 Abhishek:I need some help.How to start working on Beagleboard? Mar 04 07:51:43 gentoo has a couple book packages Mar 04 07:51:47 app-doc/linux-kernel-in-a-nutshell Mar 04 07:52:08 app-doc/linux-device-drivers Mar 04 07:52:35 read those and see if it's really what you want Mar 04 07:52:56 maybe something that uses pybbio would be good Mar 04 07:53:27 nerdboy:Thanks...for info Mar 04 11:15:02 join Mar 04 13:14:14 Hey guys I am new here can anyone guide me? Mar 04 13:42:11 Can you please tell if I am working in the right direction, because the current situation seems quite overwhelming Mar 04 13:42:45 sorry, posted that by mistake Mar 04 16:02:03 I'd love to work on the BBB-based Serial Terminal Server project Mar 04 16:27:59 carpediem_: please stick to the public channel here for gsoc questions - if you ask in private no one else in the community can benefit, plus I don't know the first thing about android on beagleboards ;) Mar 04 16:29:57 got it. Mar 04 16:33:13 to build the 4.1 kernel... should I follow the steps to build a generic bbb kernel? Mar 04 16:34:17 carpediem_: the mentors list will tell you which mentors are into android projects: http://elinux.org/BeagleBoard/GSoC/Ideas#Mentors Mar 04 16:40:01 kiran4399: yeah, just build on the 4.1 branch. There's a number of tutorials out there on building the bbb kernel if you get stuck Mar 04 16:40:12 tutorials for 3.8 will still apply Mar 04 16:40:43 alexhiam: cool!! Mar 04 16:46:14 alexhiam: BTW.. where can I find the patch of 4.1? Mar 04 16:47:21 what do you mean? Mar 04 16:47:34 http://elinux.org/Beagleboard:BeagleBoneBlack_Rebuilding_Software_Image Mar 04 16:47:58 https://github.com/beagleboard/linux Mar 04 16:48:35 oh, are you trying to build it from mainline 4.1 kiran4399? Mar 04 16:48:52 you definitely want to clone https://github.com/beagleboard/linux and build from that Mar 04 16:49:56 oh right, I've seen you're fork of beagleboard/linux on github Mar 04 16:50:13 http://elinux.org/BeagleBoardDebian#Debian_Configuration Mar 04 16:51:49 alexhiam: But I created a bb_blue branch and I am working in that.. is it ok? Mar 04 16:54:00 sure, it's good to work on a separate branch for testing, then generate a patch for the 4.1 branch from that Mar 04 16:55:07 e.g. 'git format-patch origin/4.1' from your branch Mar 04 16:56:03 alexhiam :getting this error.. Mar 04 16:56:09 you could also work on the 4.1 branch and submit a github pull request to beagleboard/linux, but it's probably better to do it the standard linux-y way with signed off patches Mar 04 16:56:10 alexhiam: make: *** No rule to make target `uImage-dtb.am335x-boneblack'. Stop. Mar 04 16:56:32 pastebin of the whole error? Mar 04 16:56:44 this mpu9150 driver does not confirm to the kernel coding style conventions Mar 04 16:56:50 https://www.kernel.org/doc/Documentation/CodingStyle Mar 04 16:57:47 alexhiam: That is the only error.. Mar 04 16:58:04 how are you invoking make? Mar 04 17:01:41 alexhiam: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage-dtb.am335x-boneblue Mar 04 17:01:51 alexhiam: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage-dtb.am335x-boneblack Mar 04 17:02:00 alexhiam: the second one.. Mar 04 17:03:54 uImage-dtb.am335x-boneblack is not a make target Mar 04 17:04:09 you have you configure the kernel Mar 04 17:04:20 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig Mar 04 17:04:31 then build it Mar 04 17:04:38 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- Mar 04 17:06:02 https://github.com/kiran4399/linux/blob/bb_blue/arch/arm/configs/beaglebone_blue_defconfig Mar 04 17:06:30 it looks like you already have a configuration file Mar 04 17:06:44 m_w: yeah.. Mar 04 17:10:06 before that command.. I am running.. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage dtbs LOADADDR=0x80008000 Mar 04 17:10:27 and it builds? Mar 04 17:10:28 it is taking 20 seconds to run that.. and the output is right.. Mar 04 17:10:34 okay Mar 04 17:11:11 to create the concatenated uImage dtb you have to do it manually Mar 04 17:11:38 http://pastebin.com/MFxbwWR9 Mar 04 17:12:21 cat arch/arm/boot/{uImage,dts/am335x-boneblack.dtb} > uImage-dtb.am335x-boneblack Mar 04 17:13:21 you have to build the dtbs first though Mar 04 17:13:28 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- dtbs Mar 04 17:14:11 oh wait you already did that Mar 04 17:14:36 then just the cat command Mar 04 17:21:02 moin Mar 04 17:21:35 hv9: did you get your questions answered? Mar 04 17:22:31 and who's the (theoretical) mentor for serial bbb? Mar 04 17:23:45 bradfa entered the idea Mar 04 17:23:50 m_w: did the cat command.. Mar 04 17:24:18 so now you have a file called uImage-dtb.am335x-boneblack Mar 04 17:24:28 m_w: yeah.. Mar 04 17:24:35 do you have a board to load it on? Mar 04 17:25:00 m_w: I have it.. but is shorted out recently.. :-( Mar 04 17:25:40 you know I may be wrong about the formation of the cat'd dtb image Mar 04 17:26:11 you might have to cat the dtb to the zImage and then run mkimage Mar 04 17:27:07 I would just use cat'd zImage dtb if your bootloader supports it Mar 04 17:27:21 m_w: just tell me one thing.. Mar 04 17:27:30 m_w: where is the patch.sh for 4.1? Mar 04 17:28:04 don't think they do it that way anymore Mar 04 17:31:02 the tree incorporates the necessary patches Mar 04 17:35:21 the 3.8 tree explains how the uImage-dtb.am335x-boneblack is made in the Makefile Mar 04 17:35:24 https://github.com/kiran4399/linux/blob/3.8/arch/arm/boot/Makefile#L90 Mar 04 17:35:43 this is not available in the 4.1 kernel Mar 04 17:36:24 cat arch/arm/boot/{zImage,dts/am335x-boneblack.dtb} > zImage-dtb.am335x-boneblack Mar 04 17:38:29 nerdboy: you have questions about the bbb serial terminal server? Mar 04 17:39:03 somebody else did, well, me too... Mar 04 17:39:14 bradfa: are you mentoring that one? Mar 04 17:39:33 mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n kernel -d zImage-dtb.am335x-boneblack uImage-dtb.am335x-boneblack Mar 04 17:39:34 nerdboy: I proposed that idea, I'm not sure what I'm going to be mentoring yet Mar 04 17:39:59 we have a (customer) use case for that... Mar 04 17:40:03 I like the serial terminal idea Mar 04 17:40:07 nerdboy: likely I will only be able to mentor one project Mar 04 17:40:19 but i'm probably on the hook for begalesat/uav stuff Mar 04 17:41:01 m_w: do you have questions I could answer? Mar 04 17:41:15 i *might* be able to co-mentor on the serial thing... Mar 04 17:41:29 well not really Mar 04 17:41:39 we need to sort out who's available for what i guess Mar 04 17:41:40 I am working as a mentor Mar 04 17:42:03 and could take the serial monitor if required Mar 04 17:43:02 * nerdboy would like to see a cape with a set of pins and db9's, each one selectable... Mar 04 17:43:34 the current capes i've seen only have one :/ Mar 04 17:44:34 how many serial ports you want? Mar 04 17:44:45 m_w: my really like that idea too, i might be able to talk her into co-mentor Mar 04 17:44:51 *my boss even Mar 04 17:45:04 i want it all Mar 04 17:45:44 simultaneous or one at at time? Mar 04 17:46:57 use case is up to 5 controller boards Mar 04 17:47:04 simultaneous Mar 04 17:47:58 easy enough Mar 04 17:48:30 with usb we need serial numbers Mar 04 17:49:00 ftdis or cp-blah Mar 04 17:49:27 seems reliable enough so far Mar 04 17:49:45 * nerdboy a little leery of usb serial performance/reliability Mar 04 17:50:38 I used an FDTI on robomezzi Mar 04 17:51:28 using the bb uarts would be cleaner/simpler than udev and tracking usb serial numbers... Mar 04 17:51:44 does the boneblack expose the SoC EBI? Mar 04 17:52:08 I used a memory mapped UART chip on the SOM-3354 Mar 04 17:53:03 depending on overlay i think Mar 04 17:54:24 actually that's a good question... Mar 04 17:55:39 http://elinux.org/CircuitCo:BeagleBone_Memory_Expansion Mar 04 17:57:03 maybe that is for the one beagle bone Mar 04 17:57:15 http://nullr0ute.com/2016/03/lipstick-on-a-pig-aka-the-raspberry-pi-3/ Mar 04 17:58:38 :) Mar 04 18:02:35 I would like to design a 64bit beagle product Mar 04 18:02:44 TI got any chips? Mar 04 18:04:56 nope Mar 04 18:09:36 Hey m_w ! so, that PRU-framework was not working because it was not meant for 4.1.x Mar 04 18:10:59 ah Mar 04 18:11:14 is there a newer framework perhaps? Mar 04 18:12:25 what are you trying to accomplish with the PRU? Mar 04 18:12:33 I don't think so. According to Abhishek_, the last year GSoC student tried it. but i guess wasn't able to complete it. Mar 04 18:13:37 I wish to take do one of the PRU based projects, under GSoC. So that will definitely need remoteproc . I want to get the hang of it, Mar 04 18:14:06 What do you think ? Am I in the right direction ? Mar 04 18:15:17 Also, alexhiam suggested to use code of beagleLogic and try bit-banging SPI using PRU. Like the one that would be required for the SPI flash emulator project . Mar 04 18:18:12 m_w, can you guide me with that ? using beagleLogic code, to initially make a blinky using PRUs ? Mar 04 18:20:20 perhaps Mar 04 18:20:40 I really would need a bbb to start Mar 04 18:22:36 ohk, so can you, like just make a bullet instructions or points I should follow ? Mar 04 18:22:48 and do you think I am on the right track ? Mar 04 18:23:10 sure Mar 04 18:24:03 * ZeekHuge is thinking about the second question "and do you think I am on the right track ?" Mar 04 18:24:12 I think so Mar 04 18:24:25 Ohk :) Mar 04 18:24:29 you just need to get the driver to probe Mar 04 18:25:12 did you try the devicetree overlay from the link I sent? Mar 04 18:28:07 well it is lunch time for me Mar 04 18:28:32 bringing myself out to lunch for employee apprecriation day. :) Mar 04 18:29:18 Sure :) Mar 04 18:30:15 Yes i tried that devicetree overlay from the gist of the PRU-framework. But, that produced some error . Let me show it to you. Mar 04 18:33:20 heres the dmesg, when i loaded the dt and modprobed the module : http://paste.debian.net/411354/ Mar 04 18:34:53 acc to gists of the projecta and the output ofc. It was clear that something went wrong. I asked Abhishek_ and he said that the framework would only compile on 3.14 and porting it to 4.1.x would be a project in itself. Mar 04 18:48:56 I am still getting the same error.. make: *** No rule to make target `uImage-dtb.am335x-bone'. Stop. Mar 04 19:17:28 bradfa:Do you know whether it is possible to allocate tables using kobject? Mar 04 19:18:11 kiran4399: which kernel? Mar 04 19:19:07 yes Mar 04 19:19:48 sorry nevermind, i thought you were asking me Mar 04 19:33:32 * nerdboy grooves to t-bone walker... Mar 04 19:34:46 ZeekHuge: It looks like there is another driver using the mailbox already Mar 04 19:37:08 * nerdboy has a fresh t-staging-4.1 kernel but they are behind a bit on bleeding-edge robert patches... Mar 04 19:37:18 kiran4399: It is because the make target does not exist in the kernel you are using. Mar 04 19:37:47 http://www.gentoogeek.org/files/arm-bb_yocto/ Mar 04 19:38:27 if anyone has a requested version/config i can make another one Mar 04 19:38:47 3.14/4.1/4.4 anyone? Mar 04 19:39:41 that is built from the ti-staging defconfig Mar 04 19:39:59 not the most optimal depending on your needs Mar 04 19:41:08 that particular core-image has a bunch of tools, profiling/ptest packages, etc Mar 04 19:42:04 that's also up for grabs if anyone needs extra stuff Mar 04 19:43:13 kiran4399: The two commands that I gave earlier create the uImage that is created by uImage-dtb.am335x-bone in the 3.8 version Mar 04 19:43:37 cat arch/arm/boot/{zImage,dts/am335x-boneblack.dtb} > zImage-dtb.am335x-boneblack Mar 04 19:43:44 mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n kernel -d zImage-dtb.am335x-boneblack uImage-dtb.am335x-boneblack Mar 04 19:44:14 do people still need 3.8? Mar 04 19:44:32 and you can just use the zImage directly if bootz is built into the U-Boot that you have on your target Mar 04 19:45:24 true, recent u-boot should do both Mar 04 19:46:00 we should probably focus on the newest kernels Mar 04 19:46:48 well, recent anyway Mar 04 19:47:15 there are reasons for 3.14 and 4.x Mar 04 19:47:36 what is 3.14 needed for? Mar 04 19:47:52 m_w, is it ? Mar 04 19:47:53 3.8 seems a little dated at this point, since nobody should need a cape that old for gsoc Mar 04 19:48:36 m_w: kind of assuming it is right now, since it's still actively maintained Mar 04 19:49:03 ZeekHuge, Is what? Mar 04 19:49:37 I mean , where is it ? the driver using mailbox for PRUs? Mar 04 19:49:47 bb/sitara/other is still on 3.14 "stable" with 4.1 "testing" is what it looks like Mar 04 19:50:19 ZeekHuge, lemme see Mar 04 19:51:10 cloning beagleboard linux Mar 04 19:51:23 may take a few Mar 04 19:51:42 * nerdboy would probably start with 4.4x ti branch (as a student) except all the packages/recipes are for 4.1 Mar 04 19:51:57 because now there's capemgr on the 4.x kernels, there is *really* no reason to use 3.8 for new projects Mar 04 19:52:02 so 4.4 is manual build Mar 04 19:52:09 change status of 3.8.x kernel to "NRND" Mar 04 19:56:06 alexhiam, I have been doing a bit of research.Regarding the question of problems of using I2C slave mode using Linux.It consumes a lot of CPU cycles that could ahve been used for other processes Mar 04 19:59:56 alexhiam, There are software overheads in operating system like Ubuntu,which is a non-interrupting OS.So basically it will have an effect on the real time response of our system Mar 04 20:01:31 ZekeHuge, can you try this devicetree overlay instead? Mar 04 20:01:35 https://gist.github.com/shubhi1407/1abb1c8f8334a2551a98 Mar 04 20:02:26 chanakya_vc, Could the PRU offload the I2C slave interface? Mar 04 20:02:39 alexhiam,So basically we would give this task to PRU which has no such OS problems.What I was thinking was that maybe the data to be bitbanged could be stored in the shared memory space Mar 04 20:03:09 nevermind then :) Mar 04 20:04:01 bradfa: I could be interested in co-mentoring the terminal server project Mar 04 20:04:34 i think hv9 asked about it... Mar 04 20:08:31 SC16IS752 or similar may be a good alternative to USB or EBI interfaced UARTs Mar 04 20:09:22 m_w, Yes.The only thing I am confused about is writing the driver for the same.By driver,one basically means that we would give terminal window which would allow us to write data into the shared memory? Mar 04 20:09:23 it is a dual i2c/spi to uart chip Mar 04 20:10:08 chanakya_vc: something like that Mar 04 20:10:25 12c is less bandwith than spi right? Mar 04 20:10:40 typically yes Mar 04 20:10:47 how many spi devices can you have? Mar 04 20:11:10 multiple slaves i guess? Mar 04 20:11:14 m_w, Something like when in PRUspeak we run run.sh file and send commands to the PRU right? Mar 04 20:11:22 with my magical gpio chip select patch up to 4 on spi0 Mar 04 20:11:58 and each one of those has 2 serial uarts? Mar 04 20:12:07 the SC16IS752 thing Mar 04 20:12:11 chanakya_vc: I am new to the PRU stuff myself but am looking into how it works Mar 04 20:12:19 8 ports would be nice... Mar 04 20:12:25 yes 2 serial ports per spi chip select Mar 04 20:13:08 operationally you would have to chip-select between each device to use the ports? Mar 04 20:13:18 you may be able to do more with GPIO chip selects but I have proven the use of 4 Mar 04 20:13:48 i mean simultaneously or "serially" Mar 04 20:14:20 * nerdboy not the firmware expert guy... Mar 04 20:14:22 m_w, did you see that dmes I send the link of ? Mar 04 20:14:38 yes Mar 04 20:14:54 ohk, was just confirming :) Mar 04 20:15:27 is that with the original jist I sent? Mar 04 20:15:50 m_w, Ohh.Thanks anyway! Mar 04 20:16:01 pmezydlo: allocating tables? what kind of tables? like a kitchen table? :) Mar 04 20:16:34 nerdboy the driver would handle the SPI transactions and present the UARTs Mar 04 20:16:35 no no ! I am asking about the pastebin link . The one that was from my BBB, on modprobing pruss_remotrpoc . Mar 04 20:16:57 m_w: do you have a link to the SPI->UART chip you mention? Mar 04 20:17:12 http://www.nxp.com/documents/data_sheet/SC16IS752_SC16IS762.pdf Mar 04 20:17:17 m_w: there are only 3 usable SPI CS pins on BBB Mar 04 20:17:42 ah but there are more chip selects Mar 04 20:17:53 because of my patch Mar 04 20:18:02 m_w: you are doing gpio chip selects? Mar 04 20:18:10 m_w, this is what i am talking about : http://paste.debian.net/411354/ Mar 04 20:18:10 m_w: those are going to be slow Mar 04 20:18:20 "slow" Mar 04 20:18:25 no Mar 04 20:18:39 m_w: ok Mar 04 20:19:06 ZeekHuge: that is when modprobing the driver? Mar 04 20:19:49 yes. Mar 04 20:19:54 m_w: thanks for the link to the NXP SPI->UART chip, didn't know such things existed :) Mar 04 20:21:18 m_w, Just curious.When you say that you have written a patch for more chip select pins,are you employing bitbanging?Like I imagine there are only three such dedicated SPI CS pins? Mar 04 20:22:06 the GPIOs are toggle in the SPI driver when registered Mar 04 20:22:12 m_w: where is this patch? Mar 04 20:22:27 actually I mainlined it Mar 04 20:22:33 is it in any of the kernel builds now? rcn's maybe? Mar 04 20:22:42 4.4 stable has every thing Mar 04 20:22:58 so it's not in 4.1? Mar 04 20:23:07 not in 4.1 Mar 04 20:23:11 http://dev.iachieved.it/iachievedit/gpio-chip-selects-with-the-beaglebone/ Mar 04 20:23:28 I could backport it if you guys are interested Mar 04 20:24:41 https://github.com/beagleboard/linux/commits/4.4/drivers/spi/spi-omap2-mcspi.c Mar 04 20:25:31 m_w: it's nice to have gpio cs lines in mcspi, thanks :) Mar 04 20:25:34 Hey Abhishek_, what is this about ? : https://gist.github.com/shubhi1407/6f525aa1a2cc2a05d663. I mean, wasn't the framework only for 3.18 ? Mar 04 20:25:34 might be worth it if it's not to much effort Mar 04 20:25:47 *too much even Mar 04 20:26:06 i can put it in the 4.1 recipes Mar 04 20:26:46 lets see how far behind the 4.1 branch is Mar 04 20:28:16 it has none of my patches Mar 04 20:28:37 maybe i should just make 4.4 recipes Mar 04 20:28:51 that would be easier Mar 04 20:29:44 m_w, i have already tried the dt from shubhi1407's gist . and the shared dmesg was from there only. Mar 04 20:29:58 the current meta-ti and koen's fork of meta-beagleboard are only 4.1 Mar 04 20:30:19 now trying the dt from abhishek-kekkar's gist. Mar 04 20:37:04 http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend Mar 04 20:38:42 something tells me that this is closer to a mainline kernel Mar 04 20:39:03 m_w, Could you please guide me about writing drivers for linux?Like any idea on how I should begin? Mar 04 20:39:34 chanakya_vc: LDD3 Mar 04 20:39:50 http://www.makelinux.net/ldd3/ Mar 04 20:40:09 what kind of driver you looking to make? Mar 04 20:40:31 http://kernelnewbies.org/ Mar 04 20:42:41 m_w, I have chosen to do the project for exposing the PRU as I2C and UART device.So alexhiam told me that a driver would have to written for the same which would on user request interface with the PRU firmware Mar 04 20:43:13 m_w, And expose itself as an I2C device Mar 04 20:43:46 m_w, To the userland. Mar 04 20:43:56 have you written a driver before? Mar 04 20:44:40 m_w, No I haven't.But alexhiam said that it would be based on the remote proc Mar 04 20:45:24 well I am working ZeekHuge to attempt build remote_proc Mar 04 20:46:01 I would get familarized with device driver first though Mar 04 20:46:01 m_w, Been studying the remoteproc.I think I can learn to write driver before the official coding period. Mar 04 20:46:22 get the gregkh book Mar 04 20:46:27 it's free Mar 04 20:48:44 gregkh?It's related to writing drivers? Mar 04 20:48:52 ldd3 Mar 04 20:49:18 I gave the link above Mar 04 20:49:19 okay will check that out. Mar 04 20:49:46 nerdboy, m_w Thanks for your help! Mar 04 20:49:51 http://www.kroah.com/lkn/ Mar 04 20:50:40 the books are a bit dated but should get you going Mar 04 20:51:06 http://www.oreilly.com/catalog/linuxdrive3/ and http://lwn.net/Kernel/LDD3/ Mar 04 20:52:27 kernelnewbies is also a very good resource Mar 04 20:52:47 hi Mar 04 20:53:04 I have been digging around for android on Beagleboard x15 Mar 04 20:53:32 Okay. But again I would have to ask Alexhiam,what does exposing as an I2C device means.What I am assuming is that it will basically give user the ability to tell the PRU to behave as an I2C device and send any data it receives from the shared memory Mar 04 20:53:45 and i think it might be possible to define a GSOC timeline for this project Mar 04 20:54:11 I had a few doubts Mar 04 20:54:19 sounds like the interface should loo like any 12c device Mar 04 20:54:23 the rowboat project- where do i get it from> Mar 04 20:54:24 ? Mar 04 20:54:28 *look like even Mar 04 20:54:49 and i2c even Mar 04 20:55:20 and how to build recent android versions (like lollipop or marshmallow) while the rowboat project only supports building for linux 3.2 kernel Mar 04 20:55:41 chanakya_vc, you would load firmware on the PRU and then load a driver the provides access to the I2C in standard Linux fashion Mar 04 20:55:42 recent android versions are built upon linux 3.10 or even 3.18 Mar 04 20:55:44 so it gets a an ID and i2c device driver/command interface Mar 04 20:58:56 here is the i2c driver for the standard omap i2c controller for an idea of what a bus driver would look like. Mar 04 20:59:03 https://github.com/beagleboard/linux/blob/4.1/drivers/i2c/busses/i2c-omap.c Mar 04 20:59:15 Okay so as I understand it,the code for bitbanging goes into the firmware.Then there is the driver which basically will open a terminal and allow the user to write data to an I2C device as they would do in normal Linux? Mar 04 20:59:35 yup Mar 04 21:01:57 m_w, Okay will go through that as well.I am confident about the code for bitbanging,just never had much experience with drivers. Mar 04 21:02:38 I guess I will start from the link about basics that you and nerdboy have given. Mar 04 21:02:51 m_w, nerdboy Thanks once again1 Mar 04 21:02:55 ! Mar 04 21:03:09 you are welcome Mar 04 21:09:10 carpediem_: see if this could help https://github.com/hendersa/bbbandroid-build-aosp-lollipop_p2 Mar 04 21:15:55 Thanks a lot. Mar 04 21:41:59 chanakya_vc: there's a simple driver in beaglesat repo from last year i think Mar 04 21:43:01 https://github.com/nvisnjic/BeagleSat/tree/master/LKM/inoutlkm Mar 04 21:43:39 not currently used in the project but some kind of example anyway Mar 04 21:44:25 http://www.derekmolloy.ie/ <= and yet-another-kernel-reference Mar 04 21:47:07 nerdboy, Will check all of these out. It's going to take me a lot of time going through so many sources :) Mar 04 21:47:23 nerdboy, But Thanks a ton! Mar 04 21:50:08 *lot Mar 04 22:02:51 m_w, I think we got it working, partially. Trying to get more close to completely working condition. Mar 04 22:14:15 excellent news Mar 04 22:26:20 * ZeekHuge has been r Mar 04 22:28:05 * ZeekHuge has been traveling and hence haven't slept in last 40 hours. His brain is working slower, but still trying to get pruss_remoteproc working. Mar 04 22:34:49 m_w, the image i am working with, has the RPMsg support built in . Right ? Mar 04 22:35:31 not sure Mar 04 22:36:18 and that can be a reason why its not working even when pruss_remoteproc has been loaded correctly ? Mar 04 22:36:57 m_w my 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 04 22:39:40 it looks like its not the RPmsg is not included into it. If it was, then there should have been /dev/rpmsg_pru30 and 31 present. Isnt it ? Mar 04 22:42:40 I think so Mar 04 22:43:17 what is the output of the kernel messages? Mar 04 22:44:30 have you seen this? Mar 04 22:44:31 https://drive.google.com/file/d/0B_NI2VDamOOfM0MyYXNnSmNNLXM/view?pli=1 Mar 04 22:45:10 and this? Mar 04 22:45:11 http://processors.wiki.ti.com/index.php/PRU_Training:_PRU_PID_Motor_Demo Mar 04 22:57:15 http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs Mar 04 22:57:32 m_w, Thank you for those resources Mar 04 22:58:12 sorry for not knowing more, I am learning this PRU stuff as I go Mar 04 22:58:40 So, acc, to what i got out of them. I'll have to compile the kernels to enable the RPmsg ? Mar 04 22:58:57 yeah Mar 04 22:59:33 and, unless its enabled in the kernel, modprobing rpmsg_pru wont do anything Mar 04 22:59:47 not even produce any dmesg output :) Mar 04 22:59:58 well no Mar 04 23:00:22 does the rpmsg_pru module load? Mar 04 23:00:28 lsmod Mar 04 23:00:46 yes it did . Mar 04 23:01:27 yes it *does Mar 04 23:02:09 how about virtio_rpmsg_bus or pruss_remoteproc? Mar 04 23:04:00 but according to this http://processors.wiki.ti.com/index.php/RPMsg_Quick_Start_Guide it seems that if the kernel supports RPMsg, the rpmsg_pru30 and 31 device should show up. Mar 04 23:04:47 pruss_remoteproc is loading up correctly. With correct dmesg . Mar 04 23:05:52 virtio_rpmsg_bus? Mar 04 23:07:48 that was already loaded into the kernels and is being used up by rpmsg_pru Mar 04 23:08:22 root@beaglebone:~/Projects/PRUProjects/PRU-framework# lsmod | grep virtio Mar 04 23:08:24 virtio_rpmsg_bus 13437 1 rpmsg_pru Mar 04 23:09:02 * ZeekHuge thinks what a mysterious world it is : : Mar 04 23:09:47 try following the Hands on lab from scratch and see if it uncovers anything Mar 04 23:10:45 and that would include building the image with RPmsg support ? Mar 04 23:11:16 whatever it tells you to do Mar 04 23:11:21 or is it already supported in the current image ? Mar 04 23:11:26 oh ! ohk Mar 04 23:12:14 btw m_w, just asking, what time will you go to sleep ? after how many hours ? Mar 04 23:12:28 go to sleep = leave Mar 04 23:12:33 well it depends on the night Mar 04 23:12:43 it is 5:12PM here now Mar 04 23:13:01 4:42 AM here :) Mar 04 23:13:18 maybe you should sleep ;) Mar 04 23:13:58 I think a fresh start will make things much easier Mar 04 23:14:09 Ahh, Yes, I hope that would uncover some of those mysteries. Mar 04 23:16:38 I think we are reinventing the wheel a bit. Mar 04 23:16:47 * ZeekHuge has to travel tomorrow also, and then finally will settle at place for next 3-4 months. Mar 04 23:17:14 yeah, I just hope thats the right direction. Mar 04 23:17:21 what time zone you going to be in tomorrow? Mar 04 23:17:36 I am from India. Mar 04 23:17:56 whereabouts? Mar 04 23:18:30 In india ? Mar 04 23:18:38 yeah Mar 04 23:18:59 Ah, Well, My college is in the state of Madhya Pradesh Mar 04 23:19:04 Have you been here ? Mar 04 23:19:24 sadly no I have never left the US Mar 04 23:19:47 but my good friend is back in Mumbai now Mar 04 23:19:59 Ohk :) cool ! Mar 04 23:20:53 well hit the list with any progress you make Mar 04 23:20:56 Well, I'll reach my hostel room on day-after tomorrow morning, my time. Mar 04 23:21:04 Sure. Mar 04 23:21:11 Am i working slow ? Mar 04 23:21:38 no you are doing fine Mar 04 23:21:53 I mean with only about 10 days left for the proposal date to come, we haven't got the wheel moving ? Mar 04 23:23:20 just do your best and a project will find you Mar 04 23:24:06 Hahaha ! That was cool line ! "project will find you" :) Mar 04 23:24:37 and remember to sleep Mar 04 23:25:55 ahh, yeah :) btw i'll be going to sleep after about an hour, due to some reasons. So will have a look at the hands on lab. Mar 04 23:42:41 m_w, the dmesg when loading pruss_remoteproc is http://paste.debian.net/411927/ Mar 04 23:43:03 the modprobe msgs start from line 12 Mar 04 23:43:50 and that "vring irq not handled" in the end, keeps on repeating. Mar 04 23:45:37 looks like you are filling the mailbox Mar 04 23:45:48 I am doing nothing . Mar 04 23:45:58 I just modprobed the module Mar 04 23:46:12 the remoteproc1 is filling the mailbox Mar 04 23:47:08 ahh .. so ? Mar 04 23:53:10 https://summerofcode.withgoogle.com/organizations/4817552005922816/ Mar 04 23:53:20 i love the missing icons... Mar 05 00:11:38 ZeekHuge: did you try the write and poll userspace apps now that the driver loads? Mar 05 01:20:27 hmm Mar 05 01:20:34 quiet friday **** ENDING LOGGING AT Sat Mar 05 02:59:58 2016