=== heathkid|2 is now known as heathkid | ||
=== Jack87 is now known as Jack87|Away | ||
LetoThe2nd | 'morning! | 06:38 |
---|---|---|
LetoThe2nd | whats the current recommended way fo cross-building packages, especially kernel? | 06:39 |
LetoThe2nd | is xdeb still alive? | 06:39 |
scientes | LetoThe2nd, xdeb is dead | 06:41 |
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:42 |
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:43 |
scientes | make deb-pkg | 06:45 |
scientes | please use that | 06:45 |
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:46 |
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:48 |
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:49 |
scientes | yeah you just set the cross compiler prefix variable | 06:55 |
scientes | and you can even set arch in your .config | 06:55 |
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 | 06:56 |
ogra_ | LetoThe2nd, http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/ | 07:42 |
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:43 |
ogra_ | :) | 07:44 |
LetoThe2nd | gnah. | 07:44 |
ogra_ | oh, might be gnueabihf nowadays | 07:44 |
LetoThe2nd | it is. | 07:44 |
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:45 |
ogra_ | if its really vaniall mainline you wan, there is a kernel team PPA that has daily builds iirc | 07:46 |
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:47 |
ogra_ | CROSS_COMPILE=arm-linux-gnueabihf- make deb-pkg | 07:48 |
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:49 |
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:50 |
ogra_ | dunno, but there must be a reason our kernel team takes the effort to do our own packaging ;) | 07:51 |
LetoThe2nd | possibly yes. | 07:52 |
* ogra_ shakes his head about amazon spam ... | 07:52 | |
LetoThe2nd | ogra_: pretty amazons? | 07:52 |
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 | 07:53 |
=== doko__ is now known as doko | ||
_Lucretia_ | to build opengl, is there a deb with the headers in? | 09:51 |
ogra_ | opengl ... on arm ?!? | 09:52 |
_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:53 |
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:54 |
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:55 |
_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:56 |
_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:57 |
ogra_ | else everything we build packaged for gles wouldnt work ;) | 09:58 |
alf__ | ogra_: Sure, they would work fine, but the development cycle would be horrendous (I 've been there ;) | 09:59 |
_Lucretia_ | alf__: I don't have that package in apt - where do I get it? | 10:00 |
alf__ | _Lucretia_: Let me check... | 10:03 |
_Lucretia_ | thanks | 10:03 |
* _Lucretia_ doesn't have universe active in the repo | 10:04 | |
alf__ | _Lucretia_: do you have pvr-omap4-dev? | 10:07 |
_Lucretia_ | yup | 10:08 |
_Lucretia_ | in there? | 10:08 |
_Lucretia_ | oh they're hidden away | 10:08 |
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:09 |
ogra_ | (the above is whats in the archive in "restricted") | 10:10 |
_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:11 |
_Lucretia_ | ok they can be installed side by side | 10:13 |
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:14 |
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:15 |
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:16 |
ogra_ | pvr-omap4-dev_1.7.10.0.1.21-0ubuntu1_armhf.deb | 10:17 |
ogra_ | might be that rsalveti named it differently ? | 10:17 |
_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:18 |
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:20 |
alf__ | ogra_: agreed | 10:21 |
_Lucretia_ | ogra_: ok | 10:23 |
_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:24 |
alf__ | _Lucretia_: assuming you have libgles2-sgx-omap4 (but not -dev) | 10:25 |
_Lucretia_ | libgles2-sgx-omap4 <- I don't have that | 10:25 |
alf__ | _Lucretia_: ok | 10:26 |
_Lucretia_ | I have pvr-omap4-dev | 10:26 |
_Lucretia_ | my version of ubu is precise | 10:28 |
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:31 |
_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:32 |
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:33 |
_Lucretia_ | ok, so it's possible to do that by using the alternatives then? | 10:35 |
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:37 |
_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:38 | |
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:39 |
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:41 |
ogra_ | yeah, thus lets wait for rsalveti, i'm sure he tested them ... | 10:42 |
_Lucretia_ | ta | 10:43 |
* 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:56 |
LetoThe2nd | ... better than being compressed by the bot | 10:58 |
ogra_ | heh | 10:58 |
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? | 11:26 |
ogra_ | is no_root_squash set ? (usual suspect) | 12:28 |
LetoThe2nd | ogra_: sure. its not for RFS anyways. | 12:29 |
ogra_ | hmm | 12:29 |
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:30 |
ogra_ | do you have the nfs-common stuff installed ? | 12:31 |
LetoThe2nd | yes. | 12:31 |
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:32 |
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:33 |
ogra_ | lsmod shows nfs i suppose (and /proc/filesystems) | 12:34 |
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:36 | |
LetoThe2nd | not actively decided for v4 | 12:37 |
LetoThe2nd | the exports declaration is also classically v3 | 12:45 |
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:46 |
ogra_ | tried async ? | 12:47 |
LetoThe2nd | just done. no effect. | 12:47 |
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:48 |
ogra_ | err /etc/exports line | 12:49 |
LetoThe2nd | ogra_: correct assumptions. irssi ate my tabs. | 12:49 |
ogra_ | well, smells like a bug but without any data in dmesg or syslog its hard to nail down | 12:50 |
LetoThe2nd | dmesg is dead silent | 12:51 |
ogra_ | no mount errors in syslog ? | 12:51 |
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:53 |
LetoThe2nd | hard to find. | 12:58 |
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:07 |
BV1AL | which kernel module can enable OTG as 'host mode' ? so I can set it to load first in 'uInitrd' | 13:08 |
LetoThe2nd | stgraber: only talking about post-boot, its a share i want to use for data transfer | 13:10 |
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:25 |
BV1AL | ogra_: thanks | 13:38 |
BV1AL | it seems ubuntu has poor support for these devices :( | 13:38 |
ogra_ | feel free to help out with patches :) | 13:41 |
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:42 |
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:43 |
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:44 |
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:45 |
BV1AL | so it's a proprietary developed image ? | 13:46 |
ogra_ | no, its the same image with adjustments for the blaze | 13:46 |
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:47 |
BV1AL | ok, thanks | 13:48 |
ogra_ | the panda image works on the blaze but is definitely not optimized in any way for it | 13:48 |
BV1AL | I thought I can find a kernel module and put in 'uInitrd' to force it load first during bootup and enable OTG. | 13:49 |
ogra_ | well, apparently not witzh the pandaboard kernel | 13:50 |
alf__ | rsalveti: Hi! Are there any libgl*-sgx-omap4 packages for precise armhf (not linaro)? I can only find pvr-omap4* | 13:56 |
LetoThe2nd | ogra_: after reverting to backup, mount works fine. hmh. | 14:51 |
=== morphis|away is now known as morphis | ||
=== 1JTAAA5GX is now known as jkridner | ||
ogra_ | LetoThe2nd, cosmic rays | 15:19 |
LetoThe2nd | ogra_: either that, or lack of metal mp3s on the nfs share. | 15:22 |
ogra_ | hah | 15:23 |
=== Quintasan_ is now known as Quintasan | ||
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:55 |
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. ;) | 16:59 |
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:00 |
prpplague | please add to the thread if you have time | 17:01 |
ogra_ | 2G mem ? | 17:03 |
* ogra_ just wants DRAM sockets ! | 17:03 | |
ogra_ | with no limits ! | 17:03 |
infinity | prpplague: Responded. | 17:06 |
prpplague | infinity: thanks | 17:06 |
rsalveti | alf__: the pvr-omap4 replaces the others | 17:09 |
rsalveti | alf__: because it uses alternatives | 17:09 |
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:10 |
rsalveti | prpplague: oh, cool, will check | 17:11 |
ogra_ | rsalveti, thats what i thought, thanks for confirming | 17:11 |
ppisati | prpplague: any ETA for this board? | 17:37 |
* 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:38 | |
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:39 |
ogra_ | oh, and no microSD ... | 17:40 |
ogra_ | i hate using adapters | 17:40 |
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:00 |
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:01 |
ogra_ | it made a lot of sense on the beagle ... but the more power you require the less useful it is | 18:02 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
ogra_ | (doesnt make sense to test on such old HW) | 18:13 |
prpplague | now EA1 boards might have an issue | 18:13 |
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:14 |
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:15 |
ogra_ | i'll try to replicate it her tomorrow with the boards i brought back | 18:16 |
prpplague | ogra_: interesting | 18:20 |
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:21 |
ogra_ | how would i tell ? | 18:22 |
ogra_ | (apart from not having the boxes anymore or any physical access) | 18:22 |
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:23 |
ogra_ | nobody was injured, result was good ;) | 18:24 |
prpplague | ogra_: hehe, yea, just worries me | 18:26 |
prpplague | ogra_: i'll dig around to find out if we have a BoM issue | 18:26 |
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:40 |
GrueMaster | And I have several different rev boards, from EA1 to ES B1. | 19:41 |
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:55 |
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. | 19:59 |
GrueMaster | I used mini-usb as one of the two boot methods, mainly to pull a preinstalled or netboot image to SD. | 20:00 |
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:02 |
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:08 |
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:11 |
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:12 |
* 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:13 |
infinity | ojn: And GrueMaster's squid-like one with several dongles had no way to uniquely identify the tentacles. | 20:14 |
ojn | awesome | 20:14 |
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:15 |
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:16 |
GrueMaster | If they had serial numbers in the usb device info, udev would be a no-brainer. | 20:17 |
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:18 |
stgraber | VM + usb passthrough? :) | 20:19 |
GrueMaster | stgraber: ??? | 20:19 |
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:20 |
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:22 |
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:23 |
=== jkridner_ is now known as jkridner | ||
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:24 |
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:25 |
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:26 |
GrueMaster | At my salary rate, it was cheaper to get new cables. | 20:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!