**** BEGIN LOGGING AT Wed Feb 27 02:59:56 2019
Feb 27 05:24:07 <zeekhuge[m]> praked:  Will try to get back, maybe today evening. Quite busy here.
Feb 27 05:25:14 <praked[m]> <zeekhuge[m] "praked:  Will try to get back, m"> Sure not a problem
Feb 27 06:02:23 <Utkarsh> hey!
Feb 27 15:43:18 <praked[m]> <praked[m] "Hi, thanks for the help again, f"> hendersa: can you please take a look? It seems zeekhuge is busy today.
Feb 27 15:47:59 <hendersa> I have a meeting in about 10 minutes here at work. What am I looking at?
Feb 27 16:37:13 <Guest79507> Not able to attend these meetings, if any of the students would like to discuss an idea with me, please send an email first and then I can find you on IRC later and set up a time to discuss
Feb 27 16:55:03 <praked[m]> <freenode_hen "I have a meeting in about 10 min"> I have just put up some thoughts in the parallel bus idea.
Feb 27 17:04:13 <hendersa> OK. Where are these thoughts located? On a wiki? On the BeagleBoard GSOC mailing list?
Feb 27 17:06:25 <praked[m]> I guess you need to go to yesterday's log
Feb 27 17:07:52 <praked[m]> http://logs.nslu2-linux.org/livelogs/beagle-gsoc/beagle-gsoc.20190227.txt
Feb 27 17:10:40 <hendersa> Using an IC like the 74F299 is what we're interested in. It is common and straightforward to work into a design.
Feb 27 17:11:38 <hendersa> I prefer to avoid muxing the control signals if possible. Keep it as straightforward as possible, since you're already losing a lot of cycles on shifting.
Feb 27 17:12:16 <hendersa> Also, what would happen if the 299 is expecting a low/high signal and you've got the signal muxing into a z-state since it isn't connected?
Feb 27 17:13:30 <praked[m]> Aren't we then using more pins to connect to I2c and UART devices
Feb 27 17:14:02 <praked[m]> 74F299 seems to be discontinued by TI, thats what the datasheet says
Feb 27 17:17:46 <hendersa> The datasheet says that, but looking at Digikey I can see a lot of 299 chips listed as active and not obsolete.
Feb 27 17:19:32 <hendersa> The SN74F299N is the active one for a DIP IC.
Feb 27 17:19:44 <hendersa> But the pinout and behavior is the same as on the datasheet.
Feb 27 17:21:46 <hendersa> Remember, this is intended to be a reference design. We want to keep things *simple*, both for people building the circuit connecting to the board and for the software driving it.
Feb 27 17:22:31 <hendersa> Ideally, I'd like to see just the 299 chip (and maybe a line-level converter on the control/data lines) in the circuit itself.
Feb 27 17:22:46 <hendersa> Just enough to get people moving forward with their own designs.
Feb 27 17:25:32 <praked[m]> I just thought of mutiplexing because you mentioned using the parallel interface for old gaming cartridges like NES 72 with will increase the no. of selection lines. But if we just want to make things simple only using 299 makes sense.
Feb 27 17:25:38 <praked[m]> :)
Feb 27 17:26:43 <hendersa> If you chain the overflow bit into the input bit of the register, you can chain together a series of 299 chips. They all use the same signal lines.
Feb 27 17:27:56 <hendersa> So you still have the same number of control lines no matter how many 299s you have chained together.
Feb 27 17:28:08 <praked[m]> Yes definately something like a Full adder
Feb 27 17:28:37 <hendersa> Same idea.
Feb 27 17:30:57 <hendersa> A good workflow would be to get a few 299s hooked together, use a userspace Linux C program to set the control, clock, and data lines, and then monitor the signal coming out on the parallel bus.
Feb 27 17:31:20 <hendersa> Then, move that to a kernel driver or PRU assembly.
Feb 27 17:32:22 <hendersa> We want to give the users a reference design that says "Here, build your circuit like this and link this code into your application, and you can use this bus design quickly and easily."
Feb 27 17:33:16 <hendersa> The mentors can assist in the basics, but it is up to the student to get everything talking correctly.
Feb 27 17:34:45 <praked[m]> I have already gone through 299 datasheets, PRU doc at zeekhuge's blog, video from bob birkett and kernel.org docs of remoteprof and rpmsg, some videos from derek molley. I will see if I can get my hands on a couple of 299 and hookit up with some MCU for some experiments.
Feb 27 17:37:38 <hendersa> A proposal with details of a hardware prototype you have working would be good. But, getting the hardware set up would be "week 1" of this project. All GSoC projects are software projects at their core.
Feb 27 17:39:47 <praked[m]> I have some experience with LKMs specially GPIO on a RasPi
Feb 27 17:43:32 <puranjaymohan[m]> Hi, sorry for interrupting. I want to work on the usb configfs project and I have been working on device tree overlays and reading about USB subsystem, could you point me towards a few good resources about device tree overlays.
Feb 27 17:45:01 <praked[m]> https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree
Feb 27 17:45:34 <praked[m]> https://www.kernel.org/doc/Documentation/devicetree/overlay-notes.txt
Feb 27 17:46:12 <praked[m]> I think this will help
Feb 27 17:47:41 <puranjaymohan[m]> Thank you, I have read the first one and will read the second one now , Also whom should I contact for this project.
Feb 27 17:47:50 <hendersa> puranjaymohan[m]: Did you go through all of the material I mentioned on 21 February? http://logs.nslu2-linux.org/livelogs/beagle-gsoc/beagle-gsoc.20190221.txt
Feb 27 17:48:03 <puranjaymohan[m]> Yes
Feb 27 17:48:26 <hendersa> Did you see where I told you that Robert Nelson is the point of contact for that project?
Feb 27 17:49:02 <puranjaymohan[m]> Yes I found him on the beagle board slack channel
Feb 27 17:49:24 <hendersa> And have you asked him specific questions that you have?
Feb 27 17:49:27 <puranjaymohan[m]> And messaged him but he didn't reply
Feb 27 17:50:01 <hendersa> Do you have access to an ARM-based system like a BeagleBone or Raspberry Pi that you can try building a kernel and device tree?
Feb 27 17:50:13 <puranjaymohan[m]> I explained him my current state and asked him about how I should proceed forward.
Feb 27 17:50:25 <puranjaymohan[m]> I have raspberry Pi 3b
Feb 27 17:50:47 <hendersa> The best way to learn this stuff is to start working with it. Most of the mentors are very busy and will help you if you have specific technical questions.
Feb 27 17:51:13 <hendersa> Demonstrate that you understand the basics and have worked with it by asking specific technical questions that focus the scope of the project for your proposal.
Feb 27 17:52:04 <hendersa> Then, mentors will be much more likely to respond to your questions.
Feb 27 17:52:26 <puranjaymohan[m]> I have tried Playing with the GPIO API of the kernel using the repository provided here some days ago. I also completed the cross compilation challenge and added a pull request
Feb 27 17:53:04 <puranjaymohan[m]> I tried the LKM for GPIO and tested it on raspberry pi
Feb 27 17:54:07 <hendersa> Have you modified and built a new device tree that contained an entry for your driver?
Feb 27 17:54:49 <hendersa> Working through that process (change the device tree, troubleshoot it, test it) is a lot of the time-consuming work that you should have a basic grasp of prior to GSoC.
Feb 27 17:56:08 <puranjaymohan[m]> I am new to Device tree and trying to do that for raspberry Pi, I am looking for a few code examples specifically for the raspberry Pi.
Feb 27 17:57:32 <puranjaymohan[m]> I have a basic gras of cross compilation and Linux kernel modules, and I will learn device tree quickly.
Feb 27 17:59:25 <hendersa> I gave you a few tutorials for the device tree, and you asked for a few more a little while ago. I'd suggest that you review the ones I provided before again, as they will teach you much of what you need to know.
Feb 27 18:00:04 <hendersa> I have to attend another meeting here at work, but will be watching the channel later on when I am back at my desk.
Feb 27 18:01:56 <puranjaymohan[m]> Thanks a lot, I will get back to you with updates and will try to implement some Device tree entries for USB as suggested by you.
Feb 27 18:01:57 <puranjaymohan[m]> Best regards.
Feb 27 18:23:15 <jkridner[m]> sorry I was unable to join. In Europe at a tradeshow.
Feb 27 18:23:26 <jkridner[m]> let’s meet again next week!
Feb 28 00:40:11 <pratimugale[m]1> Hi, my name is Pratim Ugale. With respect to the "PRU User Space API", what exactly has to be done? Do we have to generate Host Code and PRU Code from another programming language or do we have to use pypruss? Please guide me so that I can learn more about the project.
Feb 28 00:41:32 <pratimugale[m]1> I also have completed the Cross Compilation Task and opened a pull request by the username 'pratimugale'
**** ENDING LOGGING AT Thu Feb 28 02:59:57 2019