[06:38] <LetoThe2nd> 'morning!
[06:39] <LetoThe2nd> whats the current recommended way fo cross-building packages, especially kernel?
[06:39] <LetoThe2nd> is xdeb still alive?
[06:41] <scientes> LetoThe2nd, xdeb is dead
[06:42] <scientes> LetoThe2nd, https://wiki.ubuntu.com/MultiarchCross
[06:42] <scientes> LetoThe2nd, also this http://gsoc.sitedethib.com/posts/apt-get_install_gcc-4.7-arm-linux-gnueabihf/
[06:42] <scientes> LetoThe2nd, oh if you just want to cross-build the kernel that is easy with upstream or just from a git  using make deb-pkg
[06:43] <scientes> just set the cross-compiler prefix, and run config, and make with ARCH=arm
[06:43] <scientes> and install gcc-arm-linux-gnueabi[hf]
[06:43] <scientes> which is in ubuntu an emdebian
[06:43] <scientes> *and
[06:43] <LetoThe2nd> scientes: does make-kpkg shonour the ARCH envirnoment variable?
[06:45] <scientes> make deb-pkg
[06:45] <scientes> please use that
[06:46] <scientes> LetoThe2nd, you will know if you arch variable isn't set right, cause you will get alot of configuration questions that dont apply to arm
[06:46] <scientes> (if you have set up your .config right in the first place)
[06:46] <LetoThe2nd> scientes: ok, will check that out. thanks!
[06:48] <scientes> the ubuntu kernel packages have configs in them to start you out if you need that
[06:48] <scientes> but really you need something for your board
[06:49] <LetoThe2nd> i've got a known good kernel config i'm using for rt tests :) for a start compiling on the panda was fine, but it starts to get boring ;)
[06:55] <scientes> yeah you just set the cross compiler prefix variable
[06:55] <scientes> and you can even set arch in your .config
[06:56] <scientes> but i just run it with ARCH=arm make uImage
[06:56] <scientes> and gcc-arm-linux-gnueabihf in ubuntu or emdebian has all you need to cross-compile it
[07:42] <ogra_> LetoThe2nd, http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/
[07:43] <LetoThe2nd> ogra_: ah, the usual suspects strike again
[07:43] <ogra_> :)
[07:43] <LetoThe2nd> ogra_: but does that apply to vanilla kernels also?
[07:43] <ogra_> CROSS_COMPILE=arm-linux-gnueabi- make uImage
[07:44] <ogra_> :)
[07:44] <LetoThe2nd> gnah.
[07:44] <ogra_> oh, might be gnueabihf nowadays
[07:44] <LetoThe2nd> it is.
[07:45] <LetoThe2nd> i mean, isn't there a compact way to cross-build vanilla kernels into a deb?
[07:45] <ogra_> ah, i think they ship a way upstream but never used it
[07:46] <ogra_> if its really vaniall mainline you wan, there is a kernel team PPA that has daily builds iirc
[07:47] <ogra_> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[07:47] <LetoThe2nd> ogra_: hard to use if you want to apply rt patches and spidev enablement...
[07:47] <ogra_> that should be mainline just with the ubuntu packaging bits added
[07:47] <ogra_> ah, k
[07:48] <ogra_> CROSS_COMPILE=arm-linux-gnueabihf- make deb-pkg
[07:49] <ogra_> try that one
[07:49] <ogra_> i think thats the makefile target upstream ships for debs
[07:49] <LetoThe2nd> yes, ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make deb-pkg
[07:49] <LetoThe2nd> probably.
[07:49] <LetoThe2nd> will let you know once i've copied everything over.
[07:50] <ogra_> it wont be "proper" but at least it uses the package system
[07:50] <LetoThe2nd> will lack "properness" in terms of?
[07:50] <LetoThe2nd> so far i've just used make-kpkg on the target itself
[07:51] <ogra_> dunno, but there must be a reason our kernel team takes the effort to do our own packaging ;)
[07:52] <LetoThe2nd> possibly yes.
[07:52]  * ogra_ shakes his head about amazon spam ... 
[07:52] <LetoThe2nd> ogra_: pretty amazons?
[07:53] <ogra_> based on my recent buyings they offer me "blah" ...
[07:53] <ogra_> i just bought "blah" why would i be intrested to buy that again  ?
[07:53] <ogra_> probably from a different manufacturer than i just bought it from ... butu still, where is the logic in that
[09:51] <_Lucretia_> to build opengl, is there a deb with the headers in?
[09:52] <ogra_> opengl ... on arm ?!?
[09:53] <_Lucretia_> well, gles
[09:53] <ogra_> there are mesa headers for it, yes
[09:53] <_Lucretia_> there are mesa packages
[09:53] <_Lucretia_> right, so just install that?
[09:53] <ogra_> yes
[09:53] <_Lucretia_> it won't overwrite any gl acceleration libs - not that i can find them
[09:54] <alf__> _Lucretia_: What platform are you using?
[09:54] <_Lucretia_> pandaboard es
[09:54] <_Lucretia_> using armhf
[09:54] <_Lucretia_> have installed the sgx drivers
[09:55] <alf__> _Lucretia_: libgles2-omap4-sgx-dev (I don't remember the exact name) has the headers files you need
[09:55] <_Lucretia_> no such package
[09:56] <_Lucretia_> is it another repo i have to activate?
[09:56] <ogra_> alf__, why wouldnt mesa work ? thats what we use for package builds afaik
[09:56] <alf__> ogra_: I think that installing the mesa -dev packages would uninstall sgx
[09:57] <_Lucretia_> that's what I was thinking - also, it would be sw rendering
[09:57] <_Lucretia_> I need hw
[09:57] <ogra_> oh, that could be (no idea about the deps here, i didnt look) the resulting binaries should work just fine built against mesa though
[09:58] <ogra_> else everything we build packaged for gles wouldnt work ;)
[09:59] <alf__> ogra_: Sure, they would work fine, but the development cycle would be horrendous (I 've been there ;)
[10:00] <_Lucretia_> alf__: I don't have that package in apt - where do I get it?
[10:03] <alf__> _Lucretia_: Let me check...
[10:03] <_Lucretia_> thanks
[10:04]  * _Lucretia_ doesn't have universe active in the repo
[10:07] <alf__> _Lucretia_: do you have pvr-omap4-dev?
[10:08] <_Lucretia_> yup
[10:08] <_Lucretia_> in there?
[10:08] <_Lucretia_> oh they're hidden away
[10:09] <ogra_> https://launchpad.net/ubuntu/precise/+source/pvr-omap4/1.7.10.0.1.21-0ubuntu1 ...
[10:09] <_Lucretia_> thanks
[10:09] <ogra_> but if you used the PPA you should rather get the -dev package from there
[10:09] <ogra_> i doubt the version matches whats in the ubuntu archive
[10:10] <ogra_> (the above is whats in the archive in "restricted")
[10:11] <_Lucretia_> aye
[10:11] <_Lucretia_> i know
[10:11] <_Lucretia_> thanks
[10:11] <_Lucretia_> trying to build an app, seems to want the GL stuff as well
[10:13] <_Lucretia_> ok they can be installed side by side
[10:14] <alf__> _Lucretia_: btw, the correct name is libgles2-sgx-omap4-dev, can you install that?
[10:14] <_Lucretia_> alf__: no
[10:14] <_Lucretia_> not in my apt
[10:15] <alf__> ogra_: Do you know where ^^ is? Universe maybe?
[10:15] <_Lucretia_> i can turn on universe
[10:15] <ogra_> alf__, see the LP page ;) its in restricted
[10:16] <ogra_> (which is enabled by default ... as well as universe and multiverse usually)
[10:16] <alf__> ogra_: but pvr-omap4 source doesn't seem to produce libgles2-sgx-omap4*
[10:17] <ogra_> pvr-omap4-dev_1.7.10.0.1.21-0ubuntu1_armhf.deb
[10:17] <ogra_> might be that rsalveti named it differently ?
[10:18] <_Lucretia_> this is my sources http://pastebin.com/0b41Xi6T
[10:18] <alf__> I think that pvr-omap4* just contain the files, and libgles2/gles1/egl-sgx-* enable these using alternatives (or something like that)
[10:20] <ogra_> _Lucretia_, looks fine
[10:20] <ogra_> alf__, well, if that package is really needed we should get it in if it isnt ... but i think we should wait for rsalveti to explain
[10:21] <alf__> ogra_: agreed
[10:23] <_Lucretia_> ogra_: ok
[10:24] <_Lucretia_> so does the alternatives work for selecting mesa/pvr?
[10:24] <alf__> _Lucretia_: Can you please run 'apt-cache madison libgles2-sgx-omap4' , so we can get a hint where the libgles2-sgx packages are.
[10:25] <alf__> _Lucretia_: assuming you have libgles2-sgx-omap4 (but not -dev)
[10:25] <_Lucretia_> libgles2-sgx-omap4 <- I don't have that
[10:26] <alf__> _Lucretia_: ok
[10:26] <_Lucretia_> I have pvr-omap4-dev
[10:28] <_Lucretia_> my version of ubu is precise
[10:31] <alf__> _Lucretia_: ok, so to be clear, what happens when you try to build an app that requires gles2?
[10:31] <_Lucretia_> i haven't actually tried that yet
[10:31] <_Lucretia_> what i have tried is something that's a bit of an abomination
[10:31] <_Lucretia_> in that it still requires GL/* stuff
[10:31] <_Lucretia_> its wierd
[10:32] <_Lucretia_> but uses only the gles subset - it's a binding to it from Ada
[10:32] <_Lucretia_> tbh, it doesn't build and i'm gonna get onto the person who wrote it
[10:33] <alf__> _Lucretia_: As ogra_ mentioned before you can experiment with mesa gles1/gles2 first (e.g. on a normal desktop), and when it builds you can continue on the panda.
[10:35] <_Lucretia_> ok, so it's possible to do that by using the alternatives then?
[10:37] <alf__> _Lucretia_: You can install all of gl/gles1/gles2 at the same time
[10:37] <alf__> _Lucretia_: no need for alternatives for that
[10:38] <_Lucretia_> yes i have done
[10:38] <_Lucretia_> but i have to select which version i'm using then?
[10:38]  * _Lucretia_ is just a bit unsure how all this fits together
[10:39] <alf__> _Lucretia_: no, there are different libraries (libGL,libGLESv2...) and header file locations. It's the app's job to select what it want to use and build using that.
[10:41] <alf__> ogra_: Checking  the pvr-omap4 packages a bit more it seems they are able to work standalone. Two issues I am seeing: 1. no pkg-config files 2. They don't "Provide" libegl,libgles2 etc, I am not sure what's going on with that.
[10:42] <ogra_> yeah, thus lets wait for rsalveti, i'm sure he tested them ...
[10:43] <_Lucretia_> ta
[10:56]  * ogra_ arghs over Bug 1032535
[10:56] <ubot2> Launchpad bug 1032535 in grub2 "installArchives() failed: Setting up linux-image-3.2.0-26-generic (3.2.0-26.41) ... Running depmod. update-initramfs: deferring update (hook will be called later) Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/dkms 3.2.0-26-generic /boot/vmlinuz-3.2.0-26-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-26-generic /boot/vmlinuz-3.2.0-26-generic update-initra
[10:56] <ogra_> wow, i'm impressed the bot can handle the description
[10:58] <LetoThe2nd> ... better than being compressed by the bot
[10:58] <ogra_> heh
[11:26] <LetoThe2nd> my panda fails to mount a nfs share, it just gets stuck forever at the mount command. mounting the share from the desktop box works, nevertheless. any ideas where to start debugging?
[12:28] <ogra_> is no_root_squash set ? (usual suspect)
[12:29] <LetoThe2nd> ogra_: sure. its not for RFS anyways.
[12:29] <ogra_> hmm
[12:30] <LetoThe2nd> only thing a bit unusual is that the exported directory is a symplink in the end. but that used to be fine for a long time, even for RFS. and its still when i mount on the desktop
[12:31] <ogra_> do you have the nfs-common stuff installed ?
[12:31] <LetoThe2nd> yes.
[12:32] <ogra_> stgraber, any ideas ? ^^^
[12:32]  * ogra_ hasnt actually used nfs in years 
[12:32] <LetoThe2nd> does nfs-mounting produce any logging somewhere?
[12:32] <ogra_> syslog i would guess
[12:33] <LetoThe2nd> i can start over with a backup of the fresh install, but it'll take quite some time to copy the image back.
[12:33] <ogra_> nah, better debug it
[12:34] <ogra_> lsmod shows nfs i suppose (and /proc/filesystems)
[12:36] <LetoThe2nd> check. /proc/filesystems{nfs,nfs4,nfsd} are marked with nodev, though
[12:36] <ogra_> are you using v4 actually ?
[12:36]  * ogra_ isnt sure if you dont need nfs4-acl-tools then
[12:37] <LetoThe2nd> not actively decided for v4
[12:45] <LetoThe2nd> the exports declaration is also classically v3
[12:46] <ogra_> weird
[12:46] <LetoThe2nd> /srv/panda192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)
[12:46] <LetoThe2nd> yeah
[12:46] <LetoThe2nd> hm. IIRC i've had a lockout earlier when using another NFS mount
[12:46] <LetoThe2nd> lockup
[12:47] <ogra_> tried async ?
[12:47] <LetoThe2nd> just done. no effect.
[12:48] <ogra_> pinging the ip of the server works ?
[12:48] <LetoThe2nd> yep.
[12:48] <ogra_> (and i assume the spaces in your fstab line above were just eaten by the paste)
[12:49] <ogra_> err /etc/exports line
[12:49] <LetoThe2nd> ogra_: correct assumptions. irssi ate my tabs.
[12:50] <ogra_> well, smells like a bug but without any data in dmesg or syslog its hard to nail down
[12:51] <LetoThe2nd> dmesg is dead silent
[12:51] <ogra_> no mount errors in syslog ?
[12:53] <LetoThe2nd> also dead silent
[12:53] <ogra_> very weird
[12:53] <LetoThe2nd> i think i'll start over with the backupped image.
[12:53] <LetoThe2nd> if it still appears then, it really is a hard bug.
[12:53] <ogra_> well, we need at least some datapoints
[12:58] <LetoThe2nd> hard to find.
[13:07] <stgraber> LetoThe2nd: is it just a problem at boot time? as in, if you add "nobootwait" in the fstab and try to mount post-boot, does it work?
[13:08] <BV1AL> which kernel module can enable OTG as 'host mode' ? so I can set it to load first in 'uInitrd'
[13:10] <LetoThe2nd> stgraber: only talking about post-boot, its a share i want to use for data transfer
[13:25] <ogra_> BV1AL, http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#USB_OTG_port_on_PandaBoard_does_not_as_host_under_Ubuntu
[13:25] <_Lucretia_> back
[13:38] <BV1AL> ogra_: thanks
[13:38] <BV1AL> it seems ubuntu has poor support for these devices  :(
[13:41] <ogra_> feel free to help out with patches :)
[13:42] <BV1AL> I mean they release those 'pre-build' images for us to download, but it's unable to run
[13:42] <ogra_> ??
[13:42] <ogra_> they get tested pretty heavily before being released
[13:43] <LetoThe2nd> ogra_: i guess its the usual "we didn't you guess in advance what i need personally and implement it exactly that way"-bashing.
[13:43] <LetoThe2nd> s/we/why/
[13:43] <BV1AL> the ubuntu pre-build images just don't support OTG as host mode, so I cannot connect keyb/mouse to work on it
[13:44] <ogra_> connect to the normal USB?
[13:44] <ogra_> as i said, feel free to file a bug and submit a patch that fixes it
[13:44] <BV1AL> the Blaze has only a OTG to connect USB devices
[13:44] <ogra_> a blaze isnt a pandaboard
[13:45] <BV1AL> i knew
[13:45] <ogra_> if you have a blaze you should also have a contract with TI ... they provide ubuntu images adjusted for blazes
[13:46] <BV1AL> so it's a proprietary developed image ?
[13:46] <ogra_> no, its the same image with adjustments for the blaze
[13:47] <ogra_> i.e. a different kernel that has OTG enabled i suppose
[13:47] <ogra_> ask your TI representative ;)
[13:47] <BV1AL> this mean I have to find my contract, then ask TI for the image to download ?
[13:47] <ogra_> i guess so
[13:48] <BV1AL> ok, thanks
[13:48] <ogra_> the panda image works on the blaze but is definitely not optimized in any way for it
[13:49] <BV1AL> I thought I can find a kernel module and put in 'uInitrd' to force it load first during bootup and enable OTG.
[13:50] <ogra_> well, apparently not witzh the pandaboard kernel
[13:56] <alf__> rsalveti: Hi! Are there any libgl*-sgx-omap4 packages for precise armhf (not linaro)? I can only find pvr-omap4*
[14:51] <LetoThe2nd> ogra_: after reverting to backup, mount works fine. hmh.
[15:19] <ogra_> LetoThe2nd, cosmic rays
[15:22] <LetoThe2nd> ogra_: either that, or lack of metal mp3s on the nfs share.
[15:23] <ogra_> hah
[16:55] <prpplague> just fyi, there is an omap5 pandaboard wishlist thread up on the mailing list - feel free to post complaints as well - https://groups.google.com/forum/#!topic/pandaboard/mQxpEEDM6Ww
[16:59] <GrueMaster> Sata, 1Gb ethernet, 2G mem, 802.11n come to mind.?
[16:59] <infinity> Bazillions of gigs of RAM!
[16:59] <infinity> But you already have my feedback. ;)
[17:00] <GrueMaster> Sounds like someone wants to rebuild OOo.
[17:00] <infinity> prpplague: Please don't ditch the DB9 serial port, unless you ship the Panda5 with a header->DB9 ribbon, so I don't have to source one.
[17:01] <prpplague> please add to the thread if you have time
[17:03] <ogra_> 2G mem ?
[17:03]  * ogra_ just wants DRAM sockets !
[17:03] <ogra_> with no limits !
[17:06] <infinity> prpplague: Responded.
[17:06] <prpplague> infinity: thanks
[17:09] <rsalveti> alf__: the pvr-omap4 replaces the others
[17:09] <rsalveti> alf__: because it uses alternatives
[17:10] <rsalveti> ogra_: LetoThe2nd ^
[17:10] <rsalveti> so we don't have the libgl* packages anymore
[17:10] <prpplague> rsalveti: your feedback would greatly appreciated as well
[17:11] <rsalveti> prpplague: oh, cool, will check
[17:11] <ogra_> rsalveti, thats what i thought, thanks for confirming
[17:37] <ppisati> prpplague: any ETA for this board?
[17:38]  * prpplague can't make any statements on that
[17:38] <prpplague> ppisati: but any info you post on the list would be extremely helpfu;
[17:38] <prpplague> helpful
[17:38] <prpplague> brb need food
[17:38] <ppisati> prpplague: i don't have any info, i want info :)
[17:38]  * ogra_ is in line with maens on the rs232 :)
[17:39] <ppisati> prpplague: ram sockets, sats and pci-e
[17:39] <ppisati> prpplague: that would be perfect
[17:39] <ogra_> prpplague, and after spending two days to work around the USB powering (which is there for no good reason really) please done make it power through any mini USB ports
[17:40] <ogra_> oh, and no microSD ...
[17:40] <ogra_> i hate using adapters
[18:00] <prpplague> ogra_: i did not understand your statement about usb powering
[18:00] <ogra_> prpplague, you didnt read my blogpost then :)
[18:00] <prpplague> ogra_: url?
[18:00] <ogra_> http://ograblog.wordpress.com/2012/08/06/the-bamboo-feeder-automating-continuous-arm-image-tests/
[18:01] <ogra_> the mini USB doesnt give enough current to run the board unless you roll a custom embedded kernel anyway ...  i would just drop that "feature" in the new board
[18:02] <ogra_> it made a lot of sense on the beagle ... but the more power you require the less useful it is
[18:04] <prpplague> ogra_: yes that is why we recommend the dual usb cable, similar to whats used on external HD's and cdroms
[18:04] <prpplague> ogra_: but i am not understanding your "power cycle" issue
[18:04] <ogra_> prpplague, the boards are sitting in a rack you cant really access ... the power supplies are connected to a web controlled power strip
[18:05] <ogra_> if i power off the PSU, the boards stay on
[18:05] <ogra_> pulling their power from mini usb
[18:05] <prpplague> ogra_: they shouldn't be as long as you have the barrel jack inserted
[18:05] <ogra_> well, they are
[18:06] <prpplague> ogra_: even when the barrel jack is inserted?
[18:06] <ogra_> well, the web controlled power strip has no robot arm attached, so yes :)
[18:06] <prpplague> ogra_: well i didn't know if you were powering the board via the expansion header or via one of the other power points
[18:06] <prpplague> ogra_: 4430 or 4460?
[18:07] <ogra_> all of them
[18:07] <ogra_> from EA1 to ES B1
[18:07] <ogra_> i havent found a model that would power off in this setup
[18:07] <prpplague> ogra_: i suspect there is something in your setup that i do not understand, because i regularly test panda for this specific condition
[18:08] <ogra_> there is nothing to understand, use the std PSU and a usb->miniUSB cable
[18:08] <prpplague> ogra_: i wish you had checked with me sooner on this
[18:08] <prpplague> ogra_: yea thats how we test it
[18:08] <ogra_> prpplague, i only discovered it during this project last weeks monday
[18:09] <ogra_> but i can always reproduce, even with my pandas at home
[18:09] <ogra_> as long as mini usb is attached they recieve power
[18:09] <ogra_> no matter if i pull the barrel connector or the wall plug
[18:09] <ogra_> anyway, i worked around i, works fine now :)
[18:10] <ogra_> s/i/it/
[18:10] <prpplague> ogra_: yea that bothers me, because we specifically test for that
[18:10] <ogra_> if its actually supposed to have a switch through the barrel connector i'll happily test an EA board of omap5 if you have one :)
[18:10] <prpplague> ogra_: i just tested two boards here, neither show that issue
[18:10] <ogra_> funny
[18:11] <prpplague> ogra_: the board is specifically designed to not allow that to happen
[18:11] <prpplague> ogra_: no mods done to your boards?
[18:11] <ogra_> well, what should i say
[18:12] <ogra_> nope, they came freshly out of the boxes or out of bubblewrap ....
[18:12] <prpplague> ogra_: interesting
[18:12] <ogra_> we have several different models there
[18:12] <prpplague> ogra_: i'll grab some off the assembly line for testing
[18:12] <ogra_> i kept the EA1 though
[18:13] <ogra_> (doesnt make sense to test on such old HW)
[18:13] <prpplague> now EA1 boards might have an issue
[18:14] <ogra_> well, thats why i kept it out of the loop ;)
[18:14] <ogra_> the others are all ES
[18:14] <ogra_> different versions though (dont ask me which, i remember an A1 and a B1, all that are in now have black PCBs)
[18:15] <prpplague> ogra_: i'll rerun a bunch of tests to see if can replicate the issue
[18:15] <ogra_> it works fine as it is now and i wont be able to tear it apart anymore
[18:15] <ogra_> (beond me being 4000 miles away from it)
[18:15] <prpplague> but i need to know why you were having that problem
[18:16] <ogra_> i'll try to replicate it her tomorrow with the boards i brought back
[18:20] <prpplague> ogra_: interesting
[18:21] <prpplague> ogra_: i just tested A1-A4 of pandaboard
[18:21] <prpplague> ogra_: all work properly
[18:21] <ogra_> and let me guess, you dont get the issue
[18:21] <ogra_> fun
[18:21] <prpplague> ogra_: i am wondering if all of yours were made by either circuitco or svtronics
[18:22] <ogra_> how would i tell ?
[18:22] <ogra_> (apart from not having the boxes anymore or any physical access)
[18:23] <ogra_> as i said, i can test tomorrow ... now GF calls and she will slay me if dinner gets cold ...
[18:23] <prpplague> ogra_: no worries
[18:23] <prpplague> ogra_: i suspect there has been an incorrect placement of a resistor on your boards
[18:23] <ogra_> oh, i'm not worried, the setup works fine :)
[18:23] <ogra_> and i really enjoyed doing the hw hack ...
[18:24] <ogra_> nobody was injured, result was good ;)
[18:26] <prpplague> ogra_: hehe, yea, just worries me
[18:26] <prpplague> ogra_: i'll dig around to find out if we have a BoM issue
[19:40] <GrueMaster> ogra_: My pandarack at home had the power going to the barrel connector.  I had a single AT power supply connected through a serial controlled relay.  I also had all mini-usb connectors plugged into a powered hub which was connected to my serial console server.  I used this setup to test the configuration for the build rack that davidm built, and continue to use it now (although for SETI work).
[19:41] <GrueMaster> And I have several different rev boards, from EA1 to ES B1.
[19:55] <ojn> GrueMaster, did you use udev to keep the machines at a stable console device number, or did you not care that they could get renumbered on reboots?
[19:55] <ojn> that's my current pain point with usb-to-serial controllers as console server
[19:59] <GrueMaster> ojn: for my serial console setup, I have an 8-port PCI serial interface.  Always enumerates from com4-com11 and each 9-pin end is numbered.
[19:59] <GrueMaster> I didin't use the mini-usb.  OTG was too unstable between kernel rev's.
[20:00] <GrueMaster> I used mini-usb as one of the two boot methods, mainly to pull a preinstalled or netboot image to SD.
[20:02] <GrueMaster> I had too many issues with usb-serial cables.  1 per system is fine, 2+ becomes a headache.  I even have a 4-port usb-serial cable, but even it re-enumerates each port randomly.
[20:08] <ojn> yeah. having udev handle numbering of ttyUSB* the same way ethernet interfaces are handled wouldn't be a bad idea, renaming them to new numbers and keeping them stable. :)
[20:08] <ojn> seems quite doable, just never got high enough on the todo list
[20:11] <infinity> ojn: It's not even remotely doable with most USB->Serial dongles, actually.
[20:11] <infinity> ojn: Most have no unique identifier.
[20:11] <infinity> (Unless you intentionally buy several different brands)
[20:12] <scientes> just look at all the insanity in gpsd cause gps devices actually look like serial dongles
[20:12] <scientes> and gpsd has to bind to all of them and figure out if they are gps devices
[20:13]  * infinity vomits a little.
[20:13] <ojn> infinity, hmm, i was pretty sure the ones I looked at had serial numbers. Grmbl.
[20:13] <infinity> I thought I escaped modems 20 years ago.
[20:13] <infinity> Apparently not.
[20:13] <infinity> ojn: None of mine do.
[20:14] <infinity> ojn: And GrueMaster's squid-like one with several dongles had no way to uniquely identify the tentacles.
[20:14] <ojn> awesome
[20:15] <infinity> It makes perfect sense, really.
[20:15] <infinity> USB->serial dongles are a high-marging, low-cost part that have no REASON for someone to burn a unique ID into each one, so why would the manufacturers bother?
[20:16] <infinity> The tiny subset of their customers that might care (ie: us) really aren't enough to worry about.
[20:16] <infinity> s/marging/margin/
[20:16] <GrueMaster> Yea, my "squid" cable was esentially a hub in the center with 4 individual serial chips (pl2303 iirc) on the ends.
[20:17] <GrueMaster> If they had serial numbers in the usb device info, udev would be a no-brainer.
[20:18] <GrueMaster> But I have now experienced a worse condition.  Here in my new job, I have to suffer with Windows 7.  I have two different brands of serial usb cables, neither of which have the driver cd's.  They both work in Linux w/o issues.  Windows doesn't recognise them at all.
[20:19] <stgraber> VM + usb passthrough? :)
[20:19] <GrueMaster> stgraber: ???
[20:20] <GrueMaster> Straight Windows.  Sadly, I have had to revert to running Linux in a VM.  Only way to do decent coding.
[20:20] <GrueMaster> (and ensure my boss doesn't powercycle my Linux dev system...again.
[20:22] <stgraber> GrueMaster: You could run a VM on Windows using the USB passthrough feature of vmware/virtualbox to forward to the Ubuntu VM, then if the software is Windows-speciifc, run it in wine ;)
[20:22] <stgraber> then no more serial driver problem
[20:22] <stgraber> (though probably a whole lot of other problems)
[20:23] <GrueMaster> The Windows software has a slew of incompatibilities with Wine.  Doesn't even like to run in a Windows VM (I tried).
[20:23] <GrueMaster> The different programs I have to deal with are...interesting at best.
[20:23] <infinity> stgraber: That's just disgusting. :P
[20:24] <stgraber> infinity: well, the alternative being to write a proper universal usb serial driver for Windows, I think I prefer to use a VM and wine ;)
[20:24] <GrueMaster> Meh.  I've done worse things (like running a dos envirounment in a vm under an emulator.
[20:24] <infinity> I suspect said proper driver might already exist, and the "driver disks" are nothing more than .inf files.
[20:25] <GrueMaster> True.  But without that inf file, you're hosed.
[20:25] <infinity> Surely, the Internets can provide.
[20:25] <GrueMaster> And since there are no markings on said cable, no way to look up the vendor.
[20:25] <infinity> Or you can yank the USB IDs from Linux and write an INF file. :P
[20:26] <GrueMaster> I looked, but all I could find were malware sites with "We can identify what drivers you need" crapware.
[20:26] <GrueMaster> Still need the dll for the actual serial chip.  MOStech, iirc.
[20:26] <GrueMaster> In the end, I threw the cable in the trash and went across the street to buy two new Trendnet cables.
[20:27] <GrueMaster> At my salary rate, it was cheaper to get new cables.