**** BEGIN LOGGING AT Thu Aug 15 03:00:00 2013 Aug 15 04:16:29 ka6sox, going to be away for a few days Aug 15 15:35:54 koen: is there anyway we can have more than one usb serial gadget on the BBB? Aug 15 15:36:25 you cannot? Aug 15 15:36:28 why? Aug 15 15:36:34 hmm Aug 15 15:36:38 gadget Aug 15 15:36:39 right Aug 15 15:37:37 you could get more in theory with functionfs Aug 15 15:37:45 av500: can we? this is somewhat uncharted territory for me Aug 15 15:37:57 koen: i see Aug 15 15:38:20 "in theory"? Aug 15 15:38:40 http://lxr.free-electrons.com/source/drivers/usb/gadget/multi.c Aug 15 15:38:44 there is this multi thing Aug 15 15:40:16 * hatguy wonders if multifunction implies multiple Aug 15 15:42:02 http://lxr.free-electrons.com/source/drivers/usb/gadget/serial.c#L233 Aug 15 15:42:10 so, serial registers as a composite Aug 15 15:42:14 but only once it seems Aug 15 15:42:21 gregkh: ^^^ Aug 15 15:42:24 :) Aug 15 15:50:20 I basically need a serial port which is free from a getty spawn... Aug 15 15:51:00 hatguy: what did i miss ? Aug 15 15:51:07 anujdeshpande: nothing really Aug 15 15:51:08 hatguy: ? Aug 15 15:51:19 so dont bind a getty to the one you have Aug 15 15:51:24 or is that your debug port? Aug 15 15:51:37 av500: yeah that seems to be the best way Aug 15 15:51:50 av500: nah but multiple gadgets would be nice Aug 15 15:52:14 especially if we could incorporate it in a future production image Aug 15 16:31:54 av500: ? Aug 15 16:56:49 gregkh: a serial gadget, but several of them Aug 15 16:56:59 usb serial Aug 15 16:57:18 it registers as composite, but how can one have several serial functions? Aug 15 16:59:06 The serial-getty@.service template on my BBB has no "Install" section in it.. is it enabled by some other means / am I missing something? Aug 15 17:00:20 I disabled ttyGS0... Aug 15 17:00:24 can't get it back though Aug 15 17:00:40 edit: disabled getty on ttyGS0 Aug 15 17:26:52 gregkh: reiterating av500s point, is there anyway to get multiple usb serial gadgets? (ttyGS0, ttyGS1, ttyGS2 etc?) Aug 15 18:10:22 n_ports=foo ? Aug 15 18:12:37 hatguy, use that option and you should be set Aug 15 18:15:43 mdp: ok thanks, will try Aug 15 18:16:46 perhaps it's time for a documentation patch Aug 15 18:19:55 mdp: I get a module is in use error when I try to modprobe -r g_multi... should I blacklist it and then try to reload after reboot? Aug 15 18:21:10 to avoid reboot you need to get rid of the getty..however that's done on systemd at runtime Aug 15 18:21:49 add appropriate module options Aug 15 18:22:16 ahh of course I just re-enabled getty... stupid me Aug 15 18:23:15 btw, I don't know how exactly module options work in the world of g_multi Aug 15 18:23:32 however, the above will and does work with standalone g_serial Aug 15 18:27:12 oh well, g_multi hardcodes stuff Aug 15 18:34:45 mdp: sorry pinged out... I can't disable g_multi without loosing networking over ethernet Aug 15 18:34:57 mdp: will g_serial conflict with g_multi? Aug 15 18:34:58 understood Aug 15 18:35:48 apparently I don't have the g_serial module Aug 15 18:36:42 yes, there's a problem there Aug 15 18:36:49 and g_multi is somewhat dumb Aug 15 18:37:10 my first advice stands independent of BBB's use of g_multi Aug 15 18:37:43 av500: _av500_ ping, i`m back home now, regarding that email with new plans for the project? Aug 15 18:37:58 i see Aug 15 18:38:19 unless gregkh has a silver bullet, I'd suggest adding an option to g_multi to init N number of acm functions Aug 15 18:38:25 right now it's hardcoded to 1 Aug 15 18:44:46 hatguy, it's also worth investigating koen's idea. you take g_ffs and turn on the CDC ECM option..pass in two acm functions as parameters. Aug 15 18:45:09 you still need to mount functionfs and whack it all on, but that might be a no-kernel-hacking substitute Aug 15 18:45:24 mdp: ok, I'll need some time to investigate Aug 15 18:45:28 * hatguy is new to all this Aug 15 18:46:13 yeah, it's more flexible than it used to be..but still not quite there Aug 15 18:46:59 I'm actually using cdc ecm in g_ffs for work stuff, I can give the acm functions a quick whirl Aug 15 18:47:05 sec Aug 15 18:47:15 mdp: ahh that would be nice Aug 15 18:47:57 mdp: sorry to bug in but have you used gadgetFS with the BBB ? Aug 15 18:47:58 my config is cdc ecm + adb via functionfs, just no acm devices Aug 15 18:48:04 vvu|Log, no Aug 15 18:51:47 mdp: I don't get you... so you won't be able to test multiple acm functions? Aug 15 18:54:22 I just meant I'm not doing such a thing now Aug 15 18:54:37 * hatguy needs to read the functionfs docs Aug 15 18:54:44 and after reviewing g_ffs.c a bit more I see it has no support for serial devices atm Aug 15 18:55:05 mdp: ahh too bad Aug 15 18:55:14 only rndis/cdc Aug 15 18:55:42 the framework is there so it would be easy to have to add N serial interfaces using the in-kernel support Aug 15 18:56:14 okay.. so maybe a little bit of hacking can get us there Aug 15 18:56:35 hacking can get us everywhere Aug 15 18:57:06 true... Aug 15 18:57:17 but yes, it's an incremental change on top of either of those drivers Aug 15 18:57:19 do you think multiple gadgets will be helpful for us? Aug 15 18:57:35 yeah... Aug 15 18:57:36 g_ffs just needs a little more userspace handholding to init Aug 15 18:58:18 yes, building a composite device is how you do "multiple gadgets" Aug 15 18:58:53 no I mean for the project in general Aug 15 18:59:08 the problem ,as I understand it, is that stock BBB exposes 1 ttyACM and 1 usb0 to the host Aug 15 18:59:26 and userspace arduino wants a 2nd ttyACM exposed for its exclusive use..right? Aug 15 18:59:30 yepp Aug 15 18:59:44 we *can* disable getty on the single ttyACM Aug 15 19:00:34 that's what I thought would happen when I first suggested using the ttyGS0 for arduino uart I/O Aug 15 19:00:37 tbh Aug 15 19:01:20 if we really need two then I think a patch can be whipped up Aug 15 19:01:58 that's seems to be the easiest way out... if a serial console isn't really a necessity for the typical user Aug 15 19:02:10 mdp: yeah that's the plan Aug 15 19:02:29 tbh, I have noooo idea if anybody uses that out in beagle-land Aug 15 19:02:50 yeah, and I believe it was enabled by default only recently Aug 15 19:04:25 mdp: I think prpplague and jkridner would be better "decision makers" on this Aug 15 19:05:21 back to #userspace-arduino I guess Aug 15 19:08:06 hatguy, yep, it's probably safe to assume you can't take anything away Aug 15 19:08:36 keep in mind that for a lot of the new typical BBB user..hooking up a serial cable is something reserved for power users Aug 15 19:09:13 if they power from usb, likely they want to use console/network over usb as well Aug 15 19:09:23 yeah... a serial cable "default" would have been nice... Aug 15 19:09:51 but removing the serial console won't remove console totally will it? Aug 15 19:09:51 like I saw, the kernel patch to do this is not difficult and should be easily upstreamable Aug 15 19:09:53 we still have ssh with the network Aug 15 19:10:13 right, that's the only thing I question about the value of that ttyACM being exposed..why bother? Aug 15 19:10:30 except that as we talked about with userspace arduino..networking sucks for people Aug 15 19:10:36 and usb networking more so Aug 15 19:10:43 hmm true Aug 15 19:10:52 as host distros tend to try to break that stuff as much as possible Aug 15 19:10:58 and I think not all distributions support it do they? Aug 15 19:11:00 yeah Aug 15 19:11:12 it varies from release to release if they break it or not Aug 15 19:11:32 can we safely assume ttyGS0 will work universally? Aug 15 19:11:52 that's a fair assumption. Aug 15 19:11:59 sweet Aug 15 19:12:25 one reason I pushed for that approach with userspace arduino is that an ACM compliant port is already what real arduino exposes and support on all 3 major host OSes Aug 15 19:12:33 it's a solved problem Aug 15 19:13:20 if you can't use an ACM port for this, then you can't even use a real Uno on your host Aug 15 19:13:27 hmm... isn't that an FTDI based serial? Does that work same as an ACM compliant port? Aug 15 19:13:42 there is no FTDI on BBB Aug 15 19:13:48 what FTDI do you mean? Aug 15 19:13:59 mdp: yeah I know... I was talking about the real Arduino Aug 15 19:14:30 exposed as an ACM class device here Aug 15 19:14:44 is all that matters Aug 15 19:14:49 from my pov Aug 15 19:15:36 yeah... fair point Aug 15 19:15:48 and the advantage we have over the Arduino is that no baud rate to set and all Aug 15 19:46:06 <_av500_> vvu|Mobile: sorry, tomorrow Aug 15 21:32:06 _av500_: saw my last message? Aug 15 21:32:13 <_av500_> yes **** ENDING LOGGING AT Fri Aug 16 02:59:58 2013