**** BEGIN LOGGING AT Mon Feb 16 02:59:59 2015 Feb 16 03:07:03 you just need kernel dev packages Feb 16 07:22:04 I want to contribute to beagleboard in summer of codes. Feb 16 07:23:00 It will be great if I get some guidance. Feb 16 11:59:09 vmayoral: Hi victor Feb 16 11:59:41 Wanted to know more regarding BeagleRT Feb 16 12:00:01 do ping when you are free. cheers Feb 16 12:00:20 "Android-based remote display" asks to implement sound support. From the text what I understood is, when some media file will be played on the beaglebone, the sound will come from the Android device speaker. Feb 16 12:00:52 But according to AOA protocol, AOA 2.0 includes optional support for audio output from an Android device to an accessory. Here it mentions audio output from Android device to accessory. Feb 16 12:01:26 Then how can it be possible to audio output from beaglebone to android? Am I missing/misunderstood something? Feb 16 13:51:01 Abhishek_ : I have figured a way to split the pruss driver project :) Feb 16 13:52:46 approx. how much work do you think is required in cleaning the current driver, building a driver plugin system and API, and getting it upstream ready? (From what I think, it's worth 1 GSoC) Feb 16 13:52:51 your views? Feb 16 13:55:08 alexanderhiam : ^ Feb 16 13:55:17 didn't see you there :p Feb 16 14:14:55 yo karki Feb 16 14:15:03 ho Feb 16 14:15:34 Would it be a good idea to add support for AVR, PIC and 8051 microcontrollers to the beagleboardOCD ? Feb 16 14:15:51 I think 1 GSoC + some cleanup on my side later if needed Feb 16 14:15:58 Abhishek_ : great Feb 16 14:16:07 expect a mail on tha miling list then Feb 16 14:16:11 8mailing Feb 16 14:16:13 * Feb 16 14:16:29 we'll figure out a way to create 2 projects Feb 16 14:16:31 :D Feb 16 14:16:59 hmm - I think 1 creates the userspace API and the other creates the kernel infrastructure, correct? Feb 16 14:17:07 Abhishek_ : I take it that you will focus on the upsreaming Feb 16 14:17:20 part more than userspace interface Feb 16 14:18:01 Abhishek_ : more or less, but I just tried to design 2 projects that are independent on each other Feb 16 14:18:02 :) Feb 16 14:18:10 I'll put it up Feb 16 14:18:22 we'll discuss on the mailing list Feb 16 14:18:32 so it will be better logged there Feb 16 14:18:40 * Abhishek_ had his first midsem paper today - 5 days/5 papers Feb 16 14:18:54 and I need time to put it down on paper Feb 16 14:19:14 woah, you guys don't have a break in between? Feb 16 14:19:53 this is the first time it has happened like this Feb 16 14:19:58 Would it be a good idea to add support for AVR, PIC and 8051 microcontrollers to openOCD beagle board, and do it as a GSoC project ? Feb 16 14:21:11 Abhishek_ : Best of luck :) Feb 16 14:21:16 thanks Feb 16 14:21:32 what subjects do you have? Feb 16 14:23:51 DSP, Digital Communication, Operations Research, Microcontrollers (8051 :P) and VLSI Feb 16 14:24:15 The humble 8051 Feb 16 14:25:17 karki: In how much time would the mail be up on the group? Feb 16 14:26:01 immediately? Feb 16 14:27:10 Extending openOCD support for other microcontrollers. Would it be useful for the community ? Feb 16 14:28:57 Abhishek_ : later tonight :) Feb 16 14:29:15 8051 :') Feb 16 14:29:36 any programming courses (or CS related?) Feb 16 14:51:05 Hope to see jkridner soon Feb 16 15:17:01 karki : hello Feb 16 15:45:39 hey Feb 16 15:46:40 this idea of adding support for AVR ,PIC and 8051 mcu to openOCD is interesting Feb 16 15:47:01 how can I contribute to it? Feb 16 15:47:47 Yes, but well, i was se Feb 16 15:48:14 *asking that ... But no reply yet..... Feb 16 15:49:03 they might be busy now i guess Feb 16 15:50:39 May be..... Its not an accepted idea though ! I am not sure if it is useful for the community and hence could be done as a GSoC project. Feb 16 15:52:44 well I was simply looking for ways to contribute to this commuity Feb 16 15:53:59 so if it's not a valid gsoc idea not an issue Feb 16 15:54:30 is* not an issue for me Feb 16 16:33:59 karki :hey Feb 16 16:43:54 altairpearl, ZeekHuge: the more supported architectures in OpenOCD the better, but that doesn't necessarily make sense as a BeagleBoard.org project Feb 16 16:46:25 Oh ok . thanks Feb 16 16:48:24 well I was also going through this other project "Enhance ADC driver" Feb 16 16:49:28 where can I start? how can I contribute? Feb 16 16:50:01 have you worked on kernel drivers before? Feb 16 16:51:43 No I'm learning now. But I have worked with arm,msp430,avr,pic and 8051 mcus before Feb 16 16:52:41 you'll definitely want to start by getting to know the beaglebone kernel: https://github.com/beagleboard/linux Feb 16 16:54:14 and the current adc driver https://github.com/beagleboard/linux/blob/3.14/drivers/iio/adc/ti_am335x_adc.c Feb 16 16:54:27 ok I'll definitely look in it Feb 16 16:54:32 thanks Feb 16 16:55:18 ds2 will know more than I Feb 16 16:55:41 oh ok Feb 16 16:56:06 panto has also worked on that driver, he's usually in here Feb 16 16:58:07 karki_, karki__: are you on either of these now? Feb 16 16:58:23 yeah Feb 16 16:58:29 alexanderhiam Feb 16 16:58:32 :) Feb 16 16:59:22 so do you think there's enough work on the userspace side that won't depend on the kernel framework for a whole gsoc slot? Feb 16 17:00:20 alexanderhiam : yes :) Feb 16 17:00:33 not userspace per se Feb 16 17:00:58 see, I recall panto mentioning that he wants to have a pru-rproc service Feb 16 17:01:42 and that there will be a core driver on that which will allow a plugin mechanisim Feb 16 17:01:48 for other drivers Feb 16 17:02:10 a bad example of that is the 'glue code' mechanisim me and abhishek have used Feb 16 17:02:19 in pruspeak and beaglelogic Feb 16 17:02:32 gotcha Feb 16 17:02:46 What I thought was that we could have one student working on building the service Feb 16 17:03:00 and focusing on kernel plugin api etc Feb 16 17:03:06 also the upstreaming :) Feb 16 17:03:16 right Feb 16 17:03:24 and the other one can work on the generic rpc enabled driver Feb 16 17:03:35 which plugs in to the plugin system Feb 16 17:03:44 for now it can use the legacy code Feb 16 17:03:52 like the 'glue code' system Feb 16 17:04:03 and the driver can be developed Feb 16 17:04:31 once the final pru-rproc service is ready, Feb 16 17:04:38 it plugs into that Feb 16 17:04:46 some small porting effort may be required Feb 16 17:04:59 but what I was thinking on is have a pru-service Feb 16 17:05:06 1) pru-service Feb 16 17:05:18 2) skeleton driver which allows plugins Feb 16 17:05:37 and let one of the 'plug-in' drivers be the pru-bridge Feb 16 17:06:05 sounds pretty good to me Feb 16 17:06:12 if there is a very special case like the beagle logic (lots of DMA), then a seprate plugin can be developed Feb 16 17:06:31 so there is the core driver infrastructure and a standard plugin Feb 16 17:06:44 which will expose data channels Feb 16 17:06:54 ARM <--> PRU Feb 16 17:07:13 so in most cases developers can use that Feb 16 17:07:20 including pru-speak Feb 16 17:07:22 :) Feb 16 17:07:59 so let the 1st student handle the upstreaming part Feb 16 17:08:11 and the other work on the useful plugin + client side code Feb 16 17:08:13 :d Feb 16 17:08:15 :D Feb 16 17:08:25 the terms 'service' and 'plugin' are a bit vague. I can see this as all just being done with APIs. Are you picturing a daemon process for the rproc service? Feb 16 17:08:36 not really Feb 16 17:08:58 the service is not the driver Feb 16 17:09:10 basically just pushing the rproc stuff to a library then Feb 16 17:09:19 * karki__ is kind of confused about how to put it in words Feb 16 17:09:33 panto was explaining this to us Feb 16 17:09:37 last year Feb 16 17:09:49 as a clean model for pru-rproc Feb 16 17:09:53 I don't recall Feb 16 17:10:03 Abhishek_ : you there? Feb 16 17:10:18 I'm on board with the idea, just trying to understand the implementation better Feb 16 17:10:26 Me, panto and abhishek had discussions Feb 16 17:10:28 about this Feb 16 17:10:33 but never materialized Feb 16 17:11:45 alexanderhiam : Thats why I wanted to mail this to the mailing list (need to find a way to put this on paper) Feb 16 17:12:04 service is kind of like an API which the drivers use internally Feb 16 17:12:20 it's not a process on it's own.... Feb 16 17:12:33 my memory is rather rusty on this one Feb 16 17:13:40 but the key point I want to highlight is that the 'pru-bridge' can be a plugin driver, not patched onto the main pru-rproc driver Feb 16 17:13:58 generally developers can and will use pru-bridge Feb 16 17:14:22 but for special needs, develop their own plugin driver Feb 16 17:14:40 so does the user write a simple custom kernel driver using the pru-rproc API to load their pru firmware, or does the user simply have to write their pru firmware using the right API and format, then there's a tool to load it and automatically setup any plugin stuff like pru-bridge Feb 16 17:16:00 so what the user has is this : Feb 16 17:16:19 pru-bridge is the defacto way of talking to the pru Feb 16 17:16:49 ('pru-bridge' itself is a plugin to the skeleton driver) Feb 16 17:17:18 they don't have to write any driver to use the PRU if they use pru-bridge Feb 16 17:17:51 (firmware loading, communication, signals included. all handled by pru-bridge) Feb 16 17:17:59 *but* Feb 16 17:18:17 let's say for a specific application the pru-bridge does not cut it Feb 16 17:18:41 then the developer develops his/her own plugin driver Feb 16 17:19:12 gotcha Feb 16 17:19:15 how he writes the plugin is defined by the interface the skeleton driver provides Feb 16 17:19:21 so plain and simple Feb 16 17:19:58 basicall what I did was, I separated the concept of the core PRUSS driver and PRU-Bridge Feb 16 17:20:22 making PRU-Bridge itself a plugin into the driver system simplifies a lot of things Feb 16 17:20:26 and decouples them Feb 16 17:20:41 so one student can work on the bridge Feb 16 17:21:13 and later the 'glue code' (lesser than 50 lines) can be made to fit the new plugin system Feb 16 17:21:15 :) Feb 16 17:24:10 just a thought... it would be cool to call that pru-bridge layer a transport, then be able to add protocol plugins built on top of that transport layer, e.g. an rpc protocol, a message bus protocol, etc. If the APIs are well designed then the same protocols plugins could be used with any transport layer, e.g. pru-bridge (basically serial), dma, etc. Feb 16 17:25:07 I might be making that too complex though Feb 16 17:25:09 alexanderhiam : you mean plugins over pru-bridge? Feb 16 17:25:14 right Feb 16 17:25:24 we, should keep that in mind Feb 16 17:25:36 while we discuss the idea further Feb 16 17:25:50 no clue how complex it will be for a GSoC student Feb 16 17:26:03 basically just breaking the plugin into two parts Feb 16 17:26:34 might be unnecessary though Feb 16 17:26:40 I see that, what I was thinking was chaining functionality Feb 16 17:27:07 like the pru-bridge plugin will expose different protocols Feb 16 17:27:12 via different Feb 16 17:27:15 sysfs files Feb 16 17:27:21 or something of sort Feb 16 17:27:48 sysfs_1 acts as char stream Feb 16 17:27:53 sysfs_2 dma Feb 16 17:27:56 etc Feb 16 17:28:17 but plugin makes more sense in terms of neatness Feb 16 17:28:27 but no clue of the complexity overhead Feb 16 17:28:28 :p Feb 16 17:30:53 it would be great if the driver detected the protocol used when it loaded the firmware, e.g. by looking in a particular shared memory address, then automatically created the appropriate sysfs entries Feb 16 17:31:23 in other words everything is defined in the PRU firmware and there's no need for any other setup Feb 16 17:32:49 which could be as simple as putting a '#define PRU_BRIDGE' before '#include ' Feb 16 17:33:50 ^ in the PRU firmware Feb 16 17:34:39 yes Feb 16 17:34:46 That should be possible Feb 16 17:34:50 :) Feb 16 17:34:51 driver loads firmware, looks in shared memory space, sees the pru-bridge byte, initializes pru-bridge, then tells the pru firmware it's ready to go Feb 16 17:35:44 umm hmm Feb 16 17:35:49 seems cool Feb 16 17:36:06 I think we should definitely think about this! Feb 16 17:36:30 all we need is good students now :p Feb 16 17:36:51 yup Feb 16 17:36:51 alexanderhiam : when is mentor registration opening for GSoC? Feb 16 17:37:00 did you register or is it later? Feb 16 17:37:41 looks like it's after your org is selected Feb 16 17:38:26 you apply through melange, so the org has to be in there Feb 16 17:40:32 yeah Feb 16 17:40:35 got that Feb 16 17:42:52 so probably on the 20th Feb 17 00:58:16 karki: had dozed off Feb 17 01:24:47 Followed through the discussion but what was discussed didn't really take it forward **** ENDING LOGGING AT Tue Feb 17 02:59:58 2015